Tuesday, May 29, 2012

Flame Malware, Targeted Attacks, and You

It seems no good holiday goes by without some quality new malware being dropped, and this year's Memorial Day was no exception. Announced in posts by Kaspersky, Symantec, the Iranian National CERT and the Budapest University of Technology and Economics, a targeted piece of malware called Flame has been snooping on private networks throughout the Middle East, sending back data ranging from audio recordings and screen shots to secret documents and emails, via a covert SSL channel since as early as March 2010, perhaps earlier.

The good news for your average network security guy is that the likelihood of seeing this malware on your network is exceptionally low. Unlike the newest Flash 0-day or the recent PHP-CGI issue, this particular attack won't be appearing in the latest exploit kit, and isn't going to be compromising thousands of hosts across the globe; to date, according to Kaspersky, it's been limited to a total of just 382 systems across 7 different countries in the Middle East. While it's of course possible that Flame has, or will, be used in other locations, the chances of you being impacted directly by it are probably as great as getting hit by Stuxnet.

That said, Flame has some surprisingly easy-to-detect behaviors, and since there will be plenty of CTOs who hear about "one of the most complex threats ever discovered" (per Kaspersky) as more and more media pick up the story, the VRT has you covered detection-wise. SIDs 23019 through 23038 look for C&C communications. You can see a sample of this traffic here, in a PCAP that the VRT gathered using live samples we've obtained this morning. ClamAV coverage has been delivered as Worm.Flame, Worm.Flame-1, and Worm.Flame-2.

We'll be watching this closely for further developments, and will add any further rules as necessary. In the meantime, we'd like to send a special compliment to the good folks of the Budapest University's Laboratory of Cryptography and System Security, whose writeup (linked above) is exceptionally detailed and helpful for those wishing to study this malware further.

Wednesday, May 23, 2012

PHP-CGI Leads To C99 Shell

While reviewing the events on one of the network the VRT monitors, we decided to do some digging on an event triggered by scan for the recently released PHP-CGI vulnerability. Knowing what attackers were actually trying to drop onto vulnerable systems would be itneresting, we figured. Since we could ensure proper coverage at that stage of the attack as well if we found something novel, we decided to go take a look.

The URL of the scan was:


Nothing particularly surprising there. What was interesting, through, was the "info3.txt" file, which contained only:

< ? php
? >
Confused as to how that would help an attacker, we did the logical thing and looked for "info2.txt". Not only did it exist, it had a much more interesting bit of code:

(Full copy of info2.txt)

Even without reading the Russian, it's pretty obvious what's going on here; the "c99.php" gives it away as the C99 Shell, a common backdoor tool used for easy control via a web interface once a box has been popped. Doing a quick bit of Google Translate, the comments are simple notes around file creation. The only part that doesn't make sense is the exploit writer's proud declaration of his own masculinity - but then again, it's not like we need to be this guy's psychiatrist in order to block him.

So the question from there is - how do we block this? Going after the actual encoded data is the simplest and most reliable way, so we decoded the rather large chunk of Base64 data to see what we were looking at. The data that popped out began with:

Encoder : AROHA PHPencoder ver. 1.04
WEB : 
//add php tags before usage
*                                       c99shell.php v.1.0 beta (?? 21.05.2005)

The "c99shell.php v" bit is the obvious target there, as it's least likely to change; SID 23016 looks for the encoded version of that string.

While detecting the specific attack is one thing, looking for generic obfuscations or other indicators common to many exploits is another.  It can sometimes lead to detecting unknown or little known attacks, since they might have an exploit you don't know about but reuse the same technique as an attack you do know about.

That in mind, we realized that we should have a rule that looks for "eval(base64_decode(", which was at the very bottom of the script, as well - not only has SID 15363, which looks for eval/unescape in JavaScript, found a ton of malicious activity in the wild, a quick bit of searching for "eval(base64_decode(" shows pages and pages of hits on hacked web sites, and nothing at all on legitimate use. SID 23018 now looks for that bit of nasty.

Just to round things off, we've also included SID 23017 for the big, bold "I'm a man!" string. Much like SIDs 21548, 21539, 21549, 21876, and 22039 - which all look for variants on Blackhole and Cutwail's classic "Loading ... please wait", this should never show up in legitimate traffic, and may catch different tools associated with this particular group.

In the meantime, we've been able to confirm that our existing rules for the use of an installed C99 shell work well; we suggest that customers concerned about this sort of traffic consider enabling SIDs 16613 - 16628, 18686 - 18690, and 22917 - 22936. We'd love to hear your feedback on the rules, so don't be shy about dropping us a note if you see anything around them.

Wednesday, May 16, 2012

Resurgence of Virut?

It seems like the infamous virus Virut is making a comeback. Over the past 10 days, one of our most popular ClamAV signatures has been HTML.Iframe-63:

HTML.IFrame-63 signature

Virut is a file infector that has been around for over 5 years. It typically connects to its C&C servers at brenz.pl or trenz.pl. It also adds an iFrame script to HTML files on your machine that looks like this:

Brenz.pl iframe

This iFrame will redirect anyone who opens that HTML page in a web browsers to brenz.pl/rc .
Do not navigate to that website.  Historically, it has been used to distribute malware. As of 5/16/2012, Google Safe Browsing warns that brenz.pl has been used in the past 90 days to infect several domains.

On the Snort side, SID 22940 will keep your web servers from serving infected HTML pages to your users.

Tuesday, May 8, 2012

PHP-CGI vulnerability - exploits in the wild and Snort coverage

You've probably heard about the PHP-CGI command-line parameter vulnerability (CVE-2012-1823) released last Thursday, especially if you're defending a PHP-based web application environment. While it makes use of a non-default configuration for exploitation, for users who choose to run PHP through a CGI wrapper, the implications are very important, including potential source code disclosure and remote code execution.

Since this bug is now being actively exploited in the wild, and has had a Metasploit module developed to exploit it, it's worth a note to Snort users explaining the nature of the vulnerability and the state of our coverage, so that IDS analysts can act appropriately on the issue.

At its core, the issue here is fairly simple. When PHP is run in CGI mode, certain arguments will not be escaped before being passed to the PHP binary, which then interprets them as command-line arguments. For example, "-s", will cause the PHP binary to return the source code of the script being run, and not the output of that script. A much more serious case comes when the "-d" flag is used in conjunction with "auto_prepend_file"; by specifying a remote file with PHP code, arbitrary command execution in the context of the PHP binary can be trivially achieved.

There are three signatures for this vulnerability:
  • SID 22063, which covers the remote command execution case used by Metasploit and being exploited in the wild. This rule is enabled in the balanced and security policies by default.
  • SID 22064, which looks for source code disclosure when files include a ".php" in their name. This rule is enabled in the balanced and security policies by default.
  • SID 22097, which looks for source code disclosure against PHP files executed as directory indexes (i.e. http://www.vuln.com/own_me/). This rule is enabled in no policies by default due to performance considerations, but should be enabled manually by those who are protecting known-vulnerable installations.
The VRT is actively monitoring for signs of other abuse cases or obfuscations, and will update rules as appropriate.

Monday, May 7, 2012

ClamAV and Snort coverage for Flashback and Sabpub

Being the resident VRT Apple fanboy that I am, I frequently am assigned every piece of Apple malware and Apple-related vulnerability research that comes through the office.  Luckily that's not very much.  (Fanboy jabs with his right!)

However, lately, the variants of Flashback (some AV vendors are calling it Flashfake) and "Sabpub" have kept me busy.

While Sabpub got a lot of press, there were only 3 variants of it; ClamAV detected all of them with one name (OSX.Subpub).  Flashback had many more variants to it; officially we are up to Flashback.K (11 variants). Most of the Flashback variants going around seem to be based off of two "masters", which were the most copied, changed, and redistributed.  ClamAV calls these two OSX.Flashback-8 and OSX.Flashback-12.

As of the writing of this blog post I've written 20 signatures for Flashback and only one for "Subpub".  More variants will come in, I'm quite sure, and we'll keep our eye for them.

In the meantime, it might be a good idea for you to install ClamAV on OSX.  Information on our "On Access" Scanner is here, with instructions on how to install ClamAV to properly use the on access scanner.  There are a lot of people out there that use the "ClamXav" tool for OSX to use ClamAV on their Mac, which is great for scheduled scans, however, right now, I don't believe that tool has been updated to use the "On Access" tool we've written.  Hopefully they will and we'll be able to see even greater adoption in the usage of ClamAV on OSX.  All of these tools and installs are totally FREE.

For a couple of good articles on Subpub and Flashback, check out this article, Fsecure's take on Subpub, and another article from Fsecure on Flashback.

Make sure you download the Flashback removal tool from Apple: http://support.apple.com/kb/DL1517.  Upon install it'll remove flashback for you, you don't have to run the tool manually or anything.

As far as coverage for Snort goes, we've had it covered for the same amount of time as ClamAV.

Sid: 21877 covers Sabpub (Subpub)
Sid: 20762, 21755, 21756, 21757, 21758,  and 21910 cover Flashback

Good luck out there.  Don't install anything if you don't know where it came from.  Hopefully Gatekeeper will help stem the tide of this nonsense.

Tuesday, May 1, 2012

Razorback 0.5.0 released

The Razorback team has released version 0.5.0. You can find the new version of Razorback here:  http://sfi.re/JlWZ0U.  We have also updated the virtual machine, which you can get here: http://sfi.re/IAW1oa.

This release adds support for running inspection nuggets on Windows. At this time we have tested on Windows 7, but XP support should be coming in the future. You can download the Windows installers here: http://sfi.re/JZ3MEI  Along with the Windows support we have created a number of new nuggets that use it. Here are all of the nuggets that we currently support on Windows:
  • AVG Nugget - AVG Antivirus scanning that works with the free version of AVG.
  • Avast Nugget - Avast Antivirus scanning that requires non-free Avast Pro.
  • Avira Nugget - Avira Antivirus scanning that will work with the free version of Avast with the command line scanner extension installed.
  • Kaspersky Nugget - Kaspersky Antivirus scanning that requires a licensed Kaspersky install.
  • FileInject - Command line file submission tool.
To install Razorback on Windows you will first need to install the Razorback-API MSI, and then the masterNugget MSI. After this all the other nuggets should install after the dependent AV software has been installed.
Along with this we have also added multi-threaded inspection to the inspection API. This allows for a masterNugget to spawn up a configurable number of worker threads for each nugget that is loaded which can significantly improve the throughput of certain nuggets.The dispatcher now has the ability to remove the data files from the file system after inspection has completed. It can be configured to delete blocks in many different ways:
  • Delete only if inspection determines files to be good
  • Delete all data from disk post inspection no matter what the result
  • Do not delete any data post inspection
Other nuggets have had bugs fixed, notably PDFFox has had a number of serious issues resolved.  Script nugget has also had some issues fixed such as unregistering scripts if they are removed from disk.