SEO Code Injection

Gunter Ollmann posted an excellent article explaining SEO Code Injection attacks at http://technicalinfo.net/papers/SEOCodeInjection.html. This is one of the best explanations of the attack I've read. Go read it. NOW!

SEO code injection attacks have been gaining popularity by those evil malware authors as a way to get unsuspecting victims to their attack pages. A few highly publicized attacks were done earlier this year which resulted in alot of head-aches for some major sites. Dancho Danchev has alot of excellent information on these attacks on his blog.

Slow site == attack

I help run a few websites and saw one was running slow today. I jumped on the server and ran top, to no avail. The hosting provider had locked it down so I fell back on my sys admin days and did the next best thing: tail -f /var/log/messages:

Jun 9 20:28:56 ysdc sshd(pam_unix)[12973]: check pass; user unknown
Jun 9 20:28:56 ysdc sshd(pam_unix)[12973]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=pool-71-182-88-2.ptld
or.fios.verizon.net
Jun 9 20:28:59 ysdc sshd(pam_unix)[12975]: check pass; user unknown
Jun 9 20:28:59 ysdc sshd(pam_unix)[12975]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=pool-71-182-88-2.ptld
or.fios.verizon.net
Jun 9 20:29:02 ysdc sshd(pam_unix)[12979]: check pass; user unknown
Jun 9 20:29:02 ysdc sshd(pam_unix)[12979]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=pool-71-182-88-2.ptld
or.fios.verizon.net
Jun 9 20:29:05 ysdc sshd(pam_unix)[12984]: check pass; user unknown
Jun 9 20:29:05 ysdc sshd(pam_unix)[12984]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=pool-71-182-88-2.ptld
or.fios.verizon.net

This repeated itself approximately 2900 times in the log. Brute force attack. Suspecting what was up, I did a netcat connection to port 22 on the attacking host and confirmed my suspicion:

SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2

Looks like the kiddies are out doing their brute force of the OpenSSH Debian keys attack from a few weeks ago. Make sure you have your machines patches and re-keyed!

EDIT: Here's a breakdown of the hosts performing SSH brute force attacks since yesterday:

7202 rhost=210.118.178.184
5601 rhost=72.249.190.130
2898 rhost=pool-71-182-88-2.ptldor.fios.verizon.net
1235 rhost=220.225.200.185
364 rhost=190.9.128.108
139 rhost=61.7.150.74
52 rhost=pe26501.lrdns.com

Critical VMWare Vulnerabililty

Well, it finally happened. A critical vulnerability in VMWare that allows someone to break into the host operating system was announced today. It was only a matter of time.

Virtual machines, such as VMWare, have two levels:

1) the host operating system which runs the actual virtual machine software (the physical machine)
2) the guest operating system(s) which run within the virtual machine software (the virtual machines)

For the most part, the host and guest operating systems are separate and the guest operating system is not able to access anything on the host OS, unless specifically allowed through services offered on the host OS. Commonly, access to files on the VMWare host OS is given through "Shared Folders" - essentially the same thing that you see when you share a folder within Windows.

Up until now, the majority of attacks against virtual machines have been to detect them. This is useful for malware to do because many analysts examine malware within a virtual machine. If the malware detects a VM, it can alter its execution path or stop running altogether. (You have to wonder when malware authors are going to realize corporations are beginning to use virtualization more and they are missing a huge target base by doing this.)

The only publicly-announced success of breaking out of a virtual machine (that I am aware of) is from a presentation given by Tom Liston and Ed Skoudis on some work they performed. While they showed their programs working they did not reveal details on how they were able to break out of the guest OS.

This latest VMWare vulnerability appears to be from Core Security. There aren't many details available at this time. However, it looks like if you are running VMWare with a Windows host OS and you have Shared Folders enabled, then a directory traversal attack is possible which would allow an attacker to read or write arbitrary files on your host OS. Not good.

While these circumstances may seem unlikely, they really aren't. Shared Folders is enabled by default in many versions of VMWare, and while you still need to have at least one shared folder mapped, many VM installations do.

This could allow an attacker to arbitrarily read or write files on the host OS (although I am unsure right now if execution is possible). With this ability, an attacker could trojan or infect system executables, rewrite the VM configuration file, read the SAM database, etc. Fortunately, the workaround is to just disable Shared Folders until you patch.

VMWare Advisory
ISC SANS Diary Entry
CVE Entry - CVE-2007-1744
Core Security Advisory including Proof of Concept Exploit