There's been a lot of action on the MS08-067 front over the weekend, so we thought we'd bring you up to date on the bug in general, and how Snort and ClamAV are providing specific detection. Interestingly, things are rolling out about the way we expected them to. We happened to be visiting a Snort class here in Columbia to field some questions last Thursday, and one of the students asked about how long it takes to move from binary patching to a POC. Our answer was as little as two hours. As it turns out, one private research organization reported EIP a little over two hours after patching for MS08-67 was released. That patch window is getting pretty small.

Snort Update

Of course, when you're dealing with 0-day, the patch window is an invalid concept. The VRT just finished up working through the actual pre-patch attack worm. We're pretty pleased with the outcome of our testing. After doing some reverse engineering and writing a quick DLL loader, Alain Zidouemba and Lurene Grenier were able to trigger the original, 0day attack in a controlled environment. We were able to get a pcap of the attack, and here are the test results from an all-rules load of Snort against that pcap:

[0-Day attack]

Alerts:122:3:0 (portscan) TCP Portsweep Alerts: 11:7218:8 NETBIOS SMB srvsvc NetrPathCanonicalize WriteAndX little endian overflow attempt Alerts: 33:14809:1 NETBIOS SMB srvsvc NetrpPathCononicalize little endian path cononicalization stack overflow attempt Alerts: 31:7238:8 NETBIOS SMB srvsvc NetrPathCanonicalize little endian overflow attempt Alerts: 31:1394:8 SHELLCODE x86 NOOP Alerts: 42122:1:0 (portscan) TCP Portscan Alerts: 53:14783:1 NETBIOS DCERPC NCACN-IP-TCP srvsvc NetrpPathCononicalize little endian path cononicalization stack overflow attempt Alerts: 3

We're happy to see that our newly published rules: SID 14809 and SID 14783. But there are a couple of more important things to notice here. We see plenty of evidence of "bad", with 42 alerts from the x86 NOOP rule from SHELLCODE. This would certainly give a skilled analyst a shot of detecting the 0-day attack. But the most important alerts are SID 7218 and SID 7238. These are from our detection set for MS06-040, a vulnerability from the same function as MS08-067. Because the attackers chose to use the same string that provided the overflow to also deliver the payload, they tripped the overlly long string check in our MS06-040 detection. So customers who had protection enabled from either SID 1394 or SID 7238 and SID 7218 had 0-day protection from this attack.

After the release of the binary patch, it can take a while to make a reliable exploit, and it wasn't until this weekend that public exploits began to appear. The first PoC up on Milw0rm was interesting. From a quick look at the source code, and in looking at how it behaves against our sensors, we actually believe that this POC is triggering the ms06-040 vulnerability, as opposed to the MS08-067 one. The PoC was actually up on Thursday, 10/23, and the first Milw0rm remote entry didn't show up until the 26th. Here is the testing output from the PoC and the

Remote:
[Milw0rm PoC]

Alerts:3:14817:1 NETBIOS SMB srvsvc NetrpPathCononicalize unicode little endian path cononicalization stack overflow attempt Alerts: 11:1923:9 RPC portmap proxy attempt UDP Alerts: 21:7224:8 NETBIOS SMB-DS srvsvc NetrPathCanonicalize unicode little endian overflow attempt Alerts: 13:14783:1 NETBIOS DCERPC NCACN-IP-TCP srvsvc NetrpPathCononicalize little endian path cononicalization stack overflow attempt Alerts: 1

[Milw0rm Remote]

Alerts:3:14817:1 NETBIOS SMB srvsvc NetrpPathCononicalize unicode little endian path cononicalization stack overflow attempt Alerts: 11:7209:8 NETBIOS SMB srvsvc NetrPathCanonicalize unicode little endian overflow attempt Alerts: 13:14783:1 NETBIOS DCERPC NCACN-IP-TCP srvsvc NetrpPathCononicalize little endian path cononicalization stack overflow attempt Alerts: 1

Again, we detect both on the MS06-040 rules and our newly provided MS08-067 rules. Because the attackers chose to put payload in the same string as the attack, they trigger the overflow check in our prior MS06-040 rules. This won't always be the case, as payload can be placed outside the stub, but we would still alert on the "path cononicalization stack overflow attempt" rules.

We've also verified coverage against Core Security Technologies' Core Impact module that exploits this vulnerability. Not surprisingly, this was a reliable attack mechanism against machines that are shown by Microsoft's documentation to be vulnerable to this attack. Again, it triggers prior coverage on our MS06-040 rules:

[Core Impact]

Alerts:1:1390:6 SHELLCODE x86 inc ebx NOOP Alerts: 23:14809:1 NETBIOS SMB srvsvc NetrpPathCononicalize little endian path cononicalization stack overflow attempt Alerts: 21:7235:8 NETBIOS SMB-DS srvsvc NetrPathCanonicalize little endian overflow attempt Alerts: 21:1923:9 RPC portmap proxy attempt UDP Alerts: 101:648:9 SHELLCODE x86 NOOP Alerts: 23:14783:1 NETBIOS DCERPC NCACN-IP-TCP srvsvc NetrpPathCononicalize little endian path cononicalization stack overflow attempt Alerts: 2

Because this is a well formed attack, we see a couple of additional things in this detection. The RPC portmap alert is triggered as the attack determines the attack vectors available to it. We also see indications of NOP sleds through SID 1390 and SID 648. Depending on how the attacker chooses to lay out the attack, NOP sleds can be an important component of attack detection, particularly in 0-day cases. I would strongly recommend that you leave active as many SHELLCODE rules as you can, to give your analysts a chance in 0-day cases. In this case though, we have solid detection, both in the form of SID 7235, our MS06-040 detection, and our MS08-67 specific set of detection.

Finally, we just finished up coverage testing for HD Moore's ms08-067 module for Metasploit. There is a lot of interesting things going on here, which we'll be covering in an upcoming white paper release. But for now, here is the Snort detection output:

[Metasploit]

Alerts:3:14793:1 NETBIOS SMB srvsvc NetrpPathCononicalize WriteAndX little endian path cononicalization stack overflow attempt Alerts: 11:7250:8 NETBIOS SMB-DS srvsvc NetrPathCanonicalize WriteAndX little endian overflow attempt Alerts: 23:14783:1 NETBIOS DCERPC NCACN-IP-TCP srvsvc NetrpPathCononicalize little endian path cononicalization stack overflow attempt Alerts: 1

Again...ms06-040 coverage plus our update coverage. Note the absence of other identifying traffic (shellcode, scanning, etc...) without targeted coverage, you would miss this attack.

As a final take away, notice that in three attacks, we have several different alerts. Because of the time Brian Caswell and the VRT have put towards handling a variety of NetBIOS attack vectors, Snort is able to provide broad, comprehensive detection for attacks. This leads to a larger number of rules to provide this coverage, so I strongly encourage you to upgrade to at least Snort 2.8.2, when we introduced the binary tree structure to the rule parsing process. This provides a significant performance increase to the large, but well formed for a binary tree, NetBIOS ruleset.

ClamAV Update (Courtesy of Alain Zidouemba)

A number of files by the name of n[x].exe (where [x] denotes a integer number) have been observed to be a payload as a result of the MS08-067 vulnerability. The Trojans are usually 388KB in size. Once executed, n[x] starts off by trying to ping the server 202.108.22.44. A whois of this IP address reveals that the machine is on a Chinese domain.
n[x].exe then drops the file %SYSTEMROOT%\system32\wbem\sysmgr.dll on the hard drive and registers the service “System Maintenance Service” that points to sysmgr.dll.
The following registry keys are created as well:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\sysmgr\ParametersServicedll = %SystemDir%\wbem\sysmgr.dllServicemain = servicemainfunc

The file attempts to ping 64.233.189.147 which is a computer part of the google.com domain. The Trojan very likely pings google.com to verify network connectivity. The assembly code for sysmgr.dll reveals that the Trojan then checks the registry for the presence of the following registry keys:

HKLM\Software\JiangminHKLM\Software\KasperskyLabHKLM\Software\KingsoftHKLM\Software\Symantec\PatchInst\NISHKLM\Software\Microsoft\OneCare ProtectionHKLM\Software\risingHKLM\Software\TrendMicro

All these registry keys are related to prevalent desktop security solutions.

Upon receiving a reply to its PING packet from google.com, the Trojan has the confirmation it needs to say that it has access to the Internet, it then proceeds to try to download more malware from 59.106.145.58, a server located in Japan. In fact, an HTTP GET request is sent to 59.106.145.58 with the following request URI:

test2.php?abc=value1?def=value2

with value1 being information on the antivirus software installed on the host and value2 being operating system information.
The Trojan also sends a cookie named ac to the server along with the GET request. The cookie is contains AES encrypted data about the user. Here is an example of the type of data it attempts to capture:

Outlook Express credentials
Protected Storage credentials
MSN Passport.Net credentials

As a result of a successful GET request, %SystemDir%\inetproc02x.cab is downloaded to the infected machine. This .cab file contains the following files:

winbase.dll
install.batwinbaseInst.exe
syicon.dll

After extraction from the .cab file, the batch file install.bat, copies all the files that were contained in the .cab to the folder %SystemDir%\wbem.
WinbaseInst.exe is then run which creates another service called "Windows NT Baseline" that points to basesvc.dll. The following registry keys are created in conjunction with the service:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BaseSvc\ParametersServicedll = %SystemDir%\wbem\ basesvc.dllServicemain = servicemainfunc

WinbaseInst.exe is thereafter deleted by install.bat.

We took a look at basesvc.dll in a disassembler and recognized in the .text section of this PE file, the following strings:

l 4b324fc8-1670-01d3-1278-5a47bf6ee188 is the Universally Unique Identifier, or UUID, that the vulnerable server service registers

l 199.166.133.90 is the IP address for a computer belong to the company TransCanada Pipeline. It's on the transcanada.com domain

l 139 is the TCP port for Netbios Session Service. This is the port that is used to connect file shares

What we have is an attempt by this piece of malware to exploit the computer at IP address 199.166.133.90 by sending it malformed DCE-RPC requests and relying on the vulnerable server service that is registered with UUID 4b324fc8-1670-01d3-1278-5a47bf6ee188. However, we were not seeing on the network traffic that showed that the routine above was actually called.
The .dll file exports the following 3 functions:

DllStartFunc
ServiceMainFunc
DllEntryPoint

Towards the end of the function ServiceMainFunc, a subroutine is invoked. This subroutine pauses the execution of the program for a long period of time. This is usually done to make reverse engineering difficult but also so that the Trojan will not attract attention immediately upon being executed.

Armed with these pieces of information, we edited this .dll file to change the sleep time to 1 ms and to change the target of this attack to an internal IP address. Finally, in order to call the desired function in basesvc.dll, we wrote a small loader. We edited ServiceMainFunc in our slightly modified .dll (we do not want to attack the computer system for TransCanada Pipeline) this function then seeks out potentially vulnerable Windows machines on our local network. Upon finding a vulnerable Windows machine, shellcode that is embedded in the Trojan is executed on the target machine. This shellcode instructs the newly compromised machine to contact IP address 59.106.145.58 in order to download a sample or variant of the Trojan.Gimmiv.

ClamAV detects these malcious files under the Trojan.Gimmiv (Trojan.Gimmiv-{1...7}) family.

It is worth nothing that none of the files associated with this Trojan are packed in any shape or form. Was this written by an inexperience coder or is this a deliberate taunt of the security community? The verdict is out on this one. Packing is a technique widely used by malware authors to prevent antimalware researchers from easily reversing malware binaries.