Monday, July 30, 2012

Phishing Games

It's no surprise that, as the 2012 London Olympic games approach, cybercriminals are using the event as bait for a variety of scams. Sure, there are plenty of 419 scams revolving around the games - but we'll assume that none of the readers of this blog are dumb enough to fall an online lottery scam or the like. I'll focus today on a pair of different phish we've seen with more dirty tricks - one with an attached RTF file exploiting CVE-2010-3333, and one with a fairly standard link off to an exploit kit.

The email with the attached RTF has come in from several different sources, and all of them were classic "please read the attached file to do the thing we think you're interested in" sorts of phish. For those foolish enough to be opening random documents from strangers out of their email, an intriguing little sequence of events occurred.

After exploiting a bug in Microsoft Office (which has plenty of public exploits, and which has been actively expoited in the wild since shortly after its release in November of 2010), the included shellcode drops a file with a random name into C:\Documents and Settings\< User >\Local Settings\temp\< random >.exe, whose contents are wholly contained within the initial RTF. The extracted file is then executed; its sole purpose appears to be to drop antoehr file named cydll.dll, which is then set up as a Windows service. Once connected to its C&C server, this malicious service sends out a GET request with a very strange HTTP header named "Extra-Data-Bind". This, along with "Extra-Data-Space" and "Extra-Data" - the last of which contains what is most likely the initial beacon indicating a newly compromised host - make for easy IDS detection; SIDs 21964 and 22095 cover this traffic. The RTF itself is detected by SIDs 22101 and 22102.

The phishing message with links in it was also fairly primitive in terms of design - but likely will get people clicking on it anyway:

This particular theme comes as no surprise, given similarly-themed scams seen by other researchers. Clicking any of the links in this email leads you off to - surprsie! - a Blackhole exploit kit, which then drops multiple binaries on the target machine. In the process, the kit lit up Snort like a pinball machine - SIDs 23171, 21041, 20669, 21042, and 15306 all generated alerts on our packet capture from visiting the site.

Clearly, the best way to stay safe as this year's Olympics approach is to be suspicious of any email you get regarding the games, especially if the email offers something too good to be true. If, of course, you've got users who fall for every trick in the book - the good news is that the VRT has you covered.

Tuesday, July 24, 2012

Don't Panic

Probably the very last thing I think about when I settle down to a nice cup of tea and an electronic book is that my Kindle is being owned.  Here I am, enjoying the satiric humor of Douglas Adams and suddenly it occurs to me, "I'm not sure I remember the ingredients for my favorite pan-galactic drink."  So off I go to some, unbeknownst to me, nefarious website and just as the page loads...WHAM.  My kindle is owned.  The story is the same, as technology grows, so do weaknesses in software.  As it turns out, a new feature of the Kindle Touch browser is support for NPAPI, a common scriptable plugin API.  This is great news for plugin writers for Kindle, but poses serious security risks for the browser, as the API has full root privileges on the device.  It is possible in version 5.1.0 of the device to call the API in an <embed> tag, and then use the "lipc.set" method to inject shell commands with root privileges!  The specifics I omit here, but for those of you keeping score at home don't panic!  The VRT has you covered with SIDs 23616 and 23617.



Friday, July 20, 2012

fast_pattern is fast

A fairly new reconnaissance tool called Skipfish was brought to our attention earlier this week. I wanted to take a few minutes and demonstrate a case where multiple rules using fast_pattern can be more efficient than a single rule with a regular expression.

Taking a quick look through the Skipfish source code shows there are four predefined user-agent strings with a version (2.07b) appended to the end. There is a default and then three that are intended to resemble typical user-agent strings.

Default


Firefox


MSIE



iPhone






Each of the strings has "SF/" so a regular expression can be used to detect all four variations:

pcre:"/User-Agent\x3a[^\r\n]+?SF/[0-9]{1}\.[0-9]{2}[a-z]/smi";

I used the tool and generated some traffic with each of the User-Agent strings and this rule had an Avg/Check of 92.5 microseconds.

Now using the fast pattern matcher the rule for the default User-Agent string looks like this.

content:"User-Agent: Mozilla/5.0 SF/"; fast_pattern:only;

The 'only' modifier to fast_pattern means this is only evaluated by the fast pattern matcher and not as a rule option. Since there are no other rule options this rule is evaluated entirely in the fast pattern matcher, and never enters the core Snort engine. This rule had an Avg/Check of 2.3 microseconds; none of the other three rules written this way were over 3.5 microseconds.

This demonstrates a significant performance advantage to running four separate rules instead of a single regular expression.

While the VRT is constantly monitoring for new tools being used in the field, we happily accept tool submissions from the field for creating new Snort rules. If you come across other tools like this that you want rule coverage for, please send them to us, research < at > sourcefire < dot > com. For those keeping score at home, the SIDs for the new Skipfish rules are 23601 - 23604.

Tuesday, July 17, 2012

The Power of Open Source Intelligence

Last week, an email came into the main VRT email account, entitled "New Malicious Javascript." The note inside was from Mr. Brett C., a Sourcefire customer who'd stumbled across an interesting chunk of heavily obfuscated JavaScript that was the first page in a chain of events leading to a BlackHole exploit kit. While SIDs 21041, 21492, and 21646 alerted him to the presence of the exploit kit, this new chunk of JavaScript was of interest, because it looked nothing like BlackHole redirect pages we'd seen before.
Operating only on a single sample, it was immediately apparent that this new JavaScript was up to no good, based on the level of randomization:


Mr. C. had done an excellent bit of research, and had submitted the de-obfuscated version of the code as well. It was redirecting off to another site, which finally dropped the user off at the live BlackHole kit. Since it didn't look anything like the standard BlackHole redirection stuff we see - or really, like any of the other kits we're tracking that do redirection - even with this excellent pile of intelligence, it was tough to say what exactly we could base a signature on, as it was difficult to tell what parts of the kit would remain static, vs. which ones would be randomized on the next pass through.

Wanting to not leave a customer hanging when he'd provided such an interesting chunk of data, I wrote up a pair of rules around the fact that a pair of JavaScript calls in the page - to setTimeout() and addEventListener() - had mixed ASCII characters and hexadecimal escape sequences. Generally speaking, doing so on a randomized basis is one of the hallmarks of malicious code - if you've got nothing to hide, there's no reason to go to the effort to put some of your characters in randomly as hexadecimal. Sure, there are exceptions - non-US English character sets will contain hexadecimal sequences for special characters, and sometimes paranoid programmers will obfuscate their JavaScript so that you can't steal their work - but those tend to be exceptions to the rule, and obvious to differentiate from evil traffic. Mr. C. volunteered to deploy them on his system and report back to me on false positives vs. real hits, to see if the rules would be useful for general public release.
While the rules quickly produced a pile of false positives - it seems that Google, among others, like the hex-escape quote marks in those calls on a regular basis - some hits on malicious pages popped up as well. In fact, in one such case, SID 21845 - which looks for the TDS Sutra redirection software - triggered after my experimental rules had fired, on the way off to further nefarious content. In the process, Mr. C was able to collect a second sample of the kit in action - which helped me figure out which parts stayed static across multiple runs, and which parts were being obfuscated at runtime.

There appear to be a few artifacts left over by the kit that could probably be used for very speficic detection, and the VRT will be watching for other instances of this kit going forward to see if we can hit those artifacts specifically. In the meantime, however, my initial instinct about obfuscated JavaScript calls proved to be working well - especially if I required to hexadecimal escapes within the first argument to those calls, and required that one be not the first character in (i.e. an escaped quote). Deploying that update to the rule on Mr. C's systems and some of the VRT's other sensing networks, the new revision of the rules proved to have a few false positives left - but still had a high enough signal-to-noise ratio that many administrators would find them worth deploying.

As a result, we've added SIDs 23841 and 23842 to the VRT rule set, in our new INDICATOR-OBFUSCATION category. The rules are off by default in all policies, as they will produce some level of noise on any given network - but administrators who are willing to review events and look for obviously evil JavaScript are encouraged to turn them on and see what they find.

The best part about this entire process, however, came when we sat down to ensure ClamAV coverage for these new malicious files. Since we weren't sure what the kit here was, we ran the samples through VirusTotal, to see what other vendors might be calling it (since the world of antivirus naming is so unstandardized, we try to at least go with the community naming consensus where available). The first sample that was sent in was detected by precisely zero of forty-two antivirus vendors; the second sample, which we received yesterday, was detected by two vendors (Microsoft, as Trojan.JS/IframeRef.G, and ESET, as JS/Agent.NGK).

The newly-minted ClamAV signature which covers both samples is called JS.Obfus-218; however, the kit itself, for now at least, appears to be nameless. That said, if you recognize this kit, or just have a good idea for a cool name (whoever came up with "BlackHole" obviously had a mind for evil marketing genius), let us know - and we'll either start calling it by its proper name, or take advantage of being early enough in the detection game to name what appears to be a brand-new chunk of exploit kit code.

Wednesday, July 11, 2012

It's not the Dalai Lama's birthday, oh and you got owned

A number of recent targeted attack campaigns have centered around the Dalai Lama, including purported plans for his birthday and calls to action for democracy in Tibet. These attacks use several popular exploits and even include attacks on Mac OS X. While investigating samples of these attacks, Alain Zidouemba and I discovered a few that were using CVE-2012-0158, which exploits a bug in the Mscomctl activex control. Observed in the wild embedded within RTF, DOC or XLS documents, RTFs are the weapon of choice for most of these attacks.

While the vulnerability was originally patched in April, attacks in the wild have evolved since then. Originally, detection consisted of identifying the following elements:

  1. The magic code for a stream header
  2. The magic codes for either listview or treeview
  3. The vulnerable record

Once at the record, the size of data variable had to be checked for overflows. A few extra checks could also be implemented to make sure we were in the right place, but all in all it was pretty straightforward detection. However, the latest samples that claimed to be CVE-2012-0158 did away with the surrounding structures and magic, keeping only the vulnerable record with overflowed value. The resulting file still manages to deliver the attack while leaving a smaller footprint for detection. The observed result of opening one of these malicious RTFs is that MS Office crashes and re-opens immediately to recover the file.

Detection for this exploit had to be rewritten, excluding the extraneous checks and focusing on the single record and making sure we are in the right part of the file. While we're happy to announce updated coverage, this vulnerability highlights the difficulty of playing defense - if we hadn't found these new samples, we could have easily continued to rely on the old detection, which appeared to be perfectly valid based on exploits originally observed in the wild. Making sure that detection finds all working exploits is an important part of our jobs here in the VRT, and it's why we continue to look for new attacks in any place we can find them on the Internet.

For those who are concerned about this vulnerability, it can be detected with Snort SIDs 21896 - 21093, 21905, 21937, and 23305. It is also picked up by ClamAV signature BC.Exploit.CVE_2012_0158-3.

Monday, July 9, 2012

CVE-2012-1723: New Java Attack Added to Blackhole

Word began to emerge last week of the addition of a new vulnerability to the Blackhole Exploit Kit. The bug in question - CVE-2012-1723 - is a complex Java issue, which thankfully has patches available from Oracle already. Of course, just because a patch is available doesn't mean it's been applied - most exploit kits thrive off of reliable exploits of bugs that are often two or more years old - so adding a new, current attack to the Blackhole arsenal will only make it that much more dangerous. Since there are now public writeups, including proof-of-concept exploits, this bug is likely to be a pain in defenders' sides even outside the context of Blackhole.

Like so many other attacks we see these days, we've seen a sample that came in via a reasonably well-done LinkedIn phish:


The new exploit was actually the third attack delivered after the initial landing page was hit - malicious Flash and PDF files came first - but it was very clear based on the nature of the code that came down and the name observed in the request ("soo.jar", which lines up with what other researchers have seen) that this was the new Java exploit in the wild.

The good news is that the initial exploits that have been released make use of some very odd strings, particularly around file names encoded inside the JAR file. This means that the VRT has very reliable detection of all variants that we've observed in the wild (use SIDs 23273 - 23277). We'll be monitoring this exploit closely, as well as the Blackhole Exploit Kit itself, to watch for updated obfuscations, and will update detection as necessary.

Tuesday, July 3, 2012

Banking Trojan Spread Via UPS Phish Uses 0xDEADBEEF Beacon

In addition to collecting phishing emails directly, the VRT often receives malicious email and associated binaries through the ClamAV submission page. Today's post is about a sample that was attached as a zip file in a fake UPS notification email campaign seen in the wild late last week.

The actual phish itself wasn't particularly interesting:



We've seen many similar messages, and this one is riddled with subtle errors that would tip off anyone paying close attention. Of course, people continue to fall for traps like this, so the attached malware is always worth analyzing.

Looking at the strings contained in the binary, it's clear that this particular trojan's main purpose is to steal banking credentials. We found 78 distinct strings related to banking web sites, from Chase through the Bank of East Asia. Again, this is not interesting on its own; there are plenty of banking trojans aroung the globe.

What made this especially interesting was the initial C&C communications we observed, a POST with the hex value "DE AD BE EF".  This is an interesting value to see in network traffic since it is normally used to mark memory; it's often used as a joke signifying that a given system has been compromised.


We've written Snort rule 23262 to detect this type of request. What we would love to know, though, is what motivated a banking trojan author to use such an easily spotted, well-known string in what is an otherwise well-obfuscated communications protocol. Are they taunting us, or do they just think that it's their own private joke that no one will ever notice?