Yesterday was all abuzz about a new vulnerability patch from Microsoft, released out of their normal schedule of Patch Tuesday. MS08-067: Vulnerability in Server Service Could Allow Remote Code Execution (958644) was released at 1pm US Eastern to address very major issues. Everyone should review the patch, do some testing, and update ASAP. We’re hearing some reports of WiFi driver issues post patching, so do your prep work on this one. We know the issue affects all of the major, common versions of Windows:
Windows XP
Windows 2003
Windows Vista
Windows 2008 Server
The patch was made out of the normal cycle because malcode was on the loose using the vulnerability to spread. Specifically, this vulnerability is a buffer overflow in an unauthenticated Windows SMB file sharing session on TCP ports 139 or 445 in the Windows API call NetPathCanonicalize(). A malicious client can bind to the service and issue a request with an overly long argument, overflowing a buffer and possibly executing arbitrary code on the vulnerable server. This is how the malcode is getting onto systems.
The vulnerability is on TCP ports that see a lot of scanning, but we can baseline the activity to look for spikes. Here’s 30 days of activity for TCP ports 139 and 445 from ATLAS; we’re not seeing a huge scanning spike:
TCP port 139 scanning activity
TCP port 445 scans
While highly wormable — on by default, exploit code is now out, etc — it’s not a Sasser-like situation. Thankfully. This is likely to be mitigated by things like the default firewall in XP SP2 and the like. But we are seeing some malcode on that service.
The Gimmiv family of malware is propagating by exploiting MS08-067. We first received samples related to this family of malware on 2008-10-08 using reports from a trusted partner, so this was fully two weeks before the patch release. Samples we have analyzed are NOT packed with any Windows PE packer, which is more uncommon these days. Once the malcode is on the system, it drops the following files:
C:\Documents and Settings\LocalService\Local Settings\Temporary Internet Files\macnabi.log
C:\WINDOWS\system32\wbem\basesvc.dll
C:\WINDOWS\system32\wbem\syicon.dll
C:\WINDOWS\system32\wbem\winbase.dll
It then contacts three HTTP servers with GET requests:
doradora.atzend.com
perlbody.t35.com
summertime.1gokurimu.com
The malcode then creates several new files:
C:\Documents and Settings\User\Local Settings\Temp\FPMOOWRB.bat
C:\WINDOWS\system32\wbem\sysmgr.dll
C:\WINDOWS\system32\basesvc.dll
C:\WINDOWS\system32\inetproc02x.cab
C:\WINDOWS\system32\install.bat
C:\WINDOWS\system32\scm.bat
C:\WINDOWS\system32\syicon.dll
C:\WINDOWS\system32\winbase.dll
C:\WINDOWS\system32\winbaseInst.exe
The Windows Batch File above is run using cmd.exe. It also sends an ICMP Echo Request packet to multiple IP addresses, using a unique payload: “abcde12345fghij6789″. This is done via the Win32 API call IcmpSendEcho().
Finally, it shuts down the System Manager service using a shell command (calling out to cmd.exe).
The malware’s main purpose is to steal information from the infected user’s host.
Static analysis of the malcode binaries reveals additional interesting data. First, the malcode contains multiple IP addrseses hardcoded into it: 212.227.93.146, 64.233.189.147, and 202.108.22.44. The malode references some VBS files, msrclr40.vbs and nkzclear.vbs, and contains some VBS strings:
WScript.Sleep 5
Dim oFS
set oFS = WScript.CreateObject("Scripting.FileSystemObject")
oFS.DeleteFile "%s"
oFS.DeleteFile "%s"
oFS.CreateFolder "%s"
%s\%s
WScript.Sleep 5
Dim oFS
set oFS = WScript.CreateObject("Scripting.FileSystemObject")
oFS.DeleteFile "%s"
oFS.DeleteFile "%s"
%s\%s
WScript.Sleep 5
Dim oFS
set oFS = WScript.CreateObject("Scripting.FileSystemObject")
oFS.DeleteFile "%s"
oFS.CreateFolder "%s"
oFS.CopyFile "%s", "%s\"
oFS.DeleteFile "%s"
oFS.DeleteFile "%s"It also contains a CLSID for the credentials DLL, consistent with a credential theft tool. This has been used to grab decrypted passwords from MSN Messenger, for example. This format string batch is also present, suggesting a possible log structure:
===============Outlook Express===============
===============Credential Info================
============Protected Storage Info=============
ID:
Pass:
URL:In short, not a hugely wormy piece of software, but instead a typical infostealer Trojan.
What’s very interesting about this malcode, even from a quick review of it, is that the malcode doesn’t make use of a lot of Windows APIs consistently, suggesting this was quickly mashed together. Why use “/c reg delete “HKLM\SYSTEM\CurrentControlSet\Services\%s” /f” when you can use the Windows Registry API directly? This doesn’t jive with the notion that the idea that the author(s) were able to develop a new, 0day functional exploit, even from fuzzing. This leads me to suspect they stole it from someplace else and bolted it - crudely - into this malcode. If that’s true, then there’s someone using this as a 0day prior to this patch release and all of this attention. Anyone have attack logs that would suggest 0day activity outside of this malcode? |
|
1.JPG (2008-10-26 18:02, 24.31 K,下载次数： 30)
