UPDATED X1 : OpenSSL.org Defaced by Attackers Gaining Access to Hypervisor
By now, most of you have heard that the openssl.org website was defaced. While the source code and repositories were not tampered with, this obviously concerned people. What is more interesting is that the attack was made possible by gaining access to the hypervisor that hosts the VM responsible for the website. Attacks of this sort are likely to be more common as time goes on as it provides easy ability to take over a host without having to go through the effort of actually rooting a box. (Social engineering credentials is easy, ask the Syrian Electronic Army... actual penetrations take effort).
The key takeaways are to obviously protect the Hypervisor from unauthorized access. Beyond that, protect your VMs as if they are physical machines and as feasible use a BIOS password, boot password, disable DVDROM and USB storage. Don't trust the hypervisor or VM host to secure your machine for you. For additional reading, see this NIST Guide to Security for Full Virtualization Technologies.
More on the openssl.org defacement as it develops.
UPDATE 1: OpenSSL has released an updated version of their statement saying that the Hypervisor used an insecure password which is how the attackers gained access. Contrary to other media reports, no special ninja tricks were used or undisclosed vulnerabilities.
--
John Bambenek
bambenek \at\ gmail /dot/ com
Bambenek Consulting
Scans Increase for New Linksys Backdoor (32764/TCP)
We do see a lot of probes for port 32764/TCP . According to a post to github from 2 days ago, some Linksys devices may be listening on this port enabling full unauthenticated admin access. [1]
At this point, I urge everybody to scan their networks for devices listening on port 32764/TCP. If you use a Linksys router, try to scan its public IP address from outside your network.
Our data shows almost no scans to the port prior to today, but a large number from 3 source IPs today. The by far largest number of scans come from 80.82.78.9. ShodanHQ has also been actively probing this port for the last couple of days.
https://isc.sans.edu/portascii.html?port=32764&start=2013-12-03&end=2014-01-02
| Date | Records | Targets | Sources | TCP/UDP*100 |
| Dec 5th | 10 | 2 | 3 | 90 |
| Dec 9th | 11 | 2 | 5 | 100 |
| Dec 10th | 17 | 5 | 6 | 100 |
| Jan 2nd | 15068 | 3833 | 3 | 100 |
We only have 10 different source IP addresses originating more then 10 port 32764 scans per day over the last 30 days:
+------------+-----------------+----------+ | date | source | count(*) | +------------+-----------------+----------+ | 2014-01-02 | 080.082.078.009 | 18392 | | 2014-01-01 | 198.020.069.074 | 768 |<-- interesting... 3 days | 2014-01-02 | 198.020.069.074 | 585 |<-- early hits from ShodanHQ | 2014-01-02 | 178.079.136.162 | 226 | | 2013-12-31 | 198.020.069.074 | 102 |<-- | 2014-01-02 | 072.182.101.054 | 74 | +------------+-----------------+----------+
[1] https://github.com/elvanderb/TCP-32764
-----
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Comments