Rule release for today - October 22nd, 2009

A few modifications in this release, most notably a fix for a false positive issue that raised it's ugly head from the Microsoft Tuesday release.

Microsoft Security Advisory (MS09-059):
A vulnerability in the Microsoft Local Security Authority Subsystem Service (LSASS) may allow a remote attacker to cause a Denial of Service (Dos) against an affected system.

A previously released rule to detect attacks targeting this vulnerability has been modified to reduce the incidence of false positive events. It is included in this release and is identified with GID 3, SID 16167.

As always, changelogs: http://www.snort.org/vrt/advisories/2009/10/22/vrt-rules-2009-10-22.html

Snort 2.8.5.1 Release

Hot on the heels of the Snort 2.8.5 release, a new Snort tarball is now available that fixes a few issues:

• Fixed syslog output when running on Windows.
  
• Fixed potential segfault when printing IPv6 packets using the -v option. Thanks to Laurent Gaffie for reporting this issue.
  
• Fixed segfault when additional policies were added during a configuration reload.

There's nothing particularly pressing with any of these issues, but as always you should download and install now.

Rapid7 make bold statement acquiring Metasploit Project

Normally the acquisition of an Open Source product by a commercial product wouldn’t make the VRT blog, but in this case I believe this acquisition is going to cause some interesting developments in the threat landscape and in the vulnerability management space. I also think this is a very bold endeavor for a vulnerability management company like Rapid7, more on that in a bit.

First up a quick Troll shoot.

• The license for Metasploit stays BSD.
  
• Metasploit continues to be a community driven project.

Next up, why this is interesting to the threat landscape.

• When an Open Source project gets commercial backing the developers on that project don’t need day jobs anymore. They also get resources, tools, and budgets. This in my opinion means a lot of new code for this project in a short period of time. I saw exactly this when I started with Sourcefire almost 7 years ago, no more small releases just big old feature releases.
  
• Faster exploit development. If you have resources and people you can quickly setup development environments, test things, reverse things, and build Metasploit modules. I’m guessing the number of exploits in Metasploit will quickly eclipse CORE and Immunity within a 6-month timeframe. I’m guessing this will follow the same course as with the Sourcefire VRT; go from 3k rules to 5k rules overnight.
  
• Stability and Reliability. If you buy something you want it to work and if you’ve got resources your Open Source users expect a higher quality product. I’d assume they are going to hit this area first.

So what does this have to do with the threat landscape? Well two things, the first is more exploits, the second is a more reliable assessment platform which means I now have a much better way to pen-test my network. Pen-testers, network admins, systems administrators and security guys are going to get a better tool for finding vulnerabilities, determining if they are real, and being able to prove it to the boss man. At the same time, my own day job gets a little busier as everything they crank out I will need to investigate for detection purposes.

On the Vulnerability Management side, I think this changes the game for guys like nCircle and Tenable as Rapid7’s NeXpose™ product will be the only Vulnerability Management tool that can actually prove what it is reporting. It also gives Rapid7 the interesting advantage of being able to live test mitigation strategies and defenses. This is something that other vulnerability management solutions can’t do out of the box. That said it is going to be interesting to see how this integration takes place, and how many people are willing to click the “exploit host” button if that is how it is done.

Outside all that, I always loving seeing Open Source products make it into the commercial game as it continues to show the value of Open Source in the enterprise, and that just because software is free doesn’t mean it’s not worth more than the sum of all its license text.

Vulnerability Report now available via iTunes

Yes, that's right, our monthly vulnerability report is now available for your convenience, via iTunes. To subscribe, hit up this link: http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=336370330

Note that the video is large due to it being in high definition, we'll be making adjustments as we move forward to make sure the download size is more reasonable.

Additionally, there is now a Sourcefire application for the iPhone/iPod Touch that will keep you up to date with the happenings on our blog, snort.org and the top 10 malware threats from ClamAV.

Get it here: http://appstore.iphonedownloadblog.com/app/sourcefire/

Rule release for today - October 20th, 2009

A maintenance release this week, with several new rules in web-client, specific-threats, web-misc, oracle, smtp and dos rule sets.

As always, the changelogs are available here:

http://www.snort.org/vrt/advisories/2009/10/20/vrt-rules-2009-10-20.html

October 2009 Vulnerability Report

Sourcefire VRT Vulnerability Report October 2009 from Sourcefire VRT on Vimeo.

Sourcefire VRT Vulnerability Report

This month's report covers the Microsoft Tuesday advisories, including IIS FTP vuln, SMBv2 remote code execution and Adobe patch Tuesday.

How does malware know the difference between the virtual world and the real world?

It is no secret that the Information Security industry takes advantage of virtualization software in order to research security threats. VMWare, Sandboxie, Virtual PC, Anubis, CWSandbox, JoeBox, VirtualBox, Parallels, QEMU are just just of few of these virtual machines. The cornucopia of virtual environments gives the security professional the opportunity to observe and analyze malicious software in a convenient and easily reproducible manner. This presents an issue for malware writers and because of this, they often include code in their binaries to make it more difficult for computer security professionals to analyze their executables in those virtual environments. Here are some of the most frequent anti-virtualization techniques:

Check for the presence of virtualized hardware:

Virtual environments have virtual network interfaces. Just like any network interface, they are assigned a unique MAC address that usually includes the manufacturer's identification number. For example, a network interface for VMware Workstation will have a MAC address that starts with 00:50:56 or 00:0C:29 (VMware has more than one organizationally unique identifier or OUI). Malware can check for the presence of certain OUIs and choose to behave differently or not to display any malignant behavior whatsoever in a virtual machine.

It is also possible to check for the presence of GUIDs that give away the fact that it's being run in a virtual environment. Eg: MD5: 0151c5afde070a7b194f492d26e9b3ef (Trojan.Agent-124243 by ClamAV):

.text:004012EA                 jz      short loc_40130E
.text:004012EC                 push    104h            ; size_t
.text:004012F1                 push    offset a76487644317703 ; "76487-644-3177037-23510"
.text:004012F6                 lea     ecx, [ebp+var_104]
.text:004012FC                 push    ecx             ; char *
.text:004012FD                 call    _strncmp
.text:00401302                 add     esp, 0Ch
.text:00401305                 test    eax, eax
.text:00401307                 jnz     short loc_40130E

The presence of HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ProductId 76487-644-3177037-23510 shows that the host environment is CWSandbox.

Each virtual machine is associated with specific device drivers, registry values that give away their nature. For instance:

Hard drive driver (VMware):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE\DiskVMware_Virtual_IDE_Hard_

Drive___________00000001\3030303030303030303030303030303030303130\FriendlyName VMware Virtual IDE Hard Drive

Video driver (VMware):
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000\DriverDesc VMware SVGA II

Mouse driver (VMware):
%WINDIR%\system32\drivers\vmmouse.sys

Any of these can be used by a malware writer to detect the presence of a virtual machine.

Descriptor Table Registers check:

There is only one Interrupt Descriptor Table Register (IDTR), one Global Descriptor Table Register (GDTR) and one Local Descriptor Table Register (LDTR) per processor. Since there are two operating systems running at the same time (the host and the guest), the virtual machine needs to relocate the IDTR, GDTR and LDTR for the guest OS to different locations in order to avoid conflicts. This will cause inconsistencies between the values of these registers in a virtual machine and in the native machine. The instructions SIDT, SGDT and SLDT are assembly instructions that can respectively be used to retreive the values of IDTR, GDTR and LDTR.

Eg: MD5: b27d73bfcbaec49a95f23b45e9cf9310 (W32.Virut-54 by ClamAV)

UPX2:3142A03A loc_3142A03A:              ; CODE XREF: sub_3142A02E+2 j
UPX2:3142A03A                 push    eax
UPX2:3142A03B                 sidt    fword ptr [esp+var_6+4]
UPX2:3142A040                 pop     eax
UPX2:3142A041                 mov     eax, [eax+6]
UPX2:3142A044                 shl     eax, 10h
UPX2:3142A047                 jns     short sub_3142A021

The IDT is at:

0x80ffffff in Windows
0xe8XXXXXX in Virtual PC
0xffXXXXXX in VMware

Backdoor I/O port:

VMware uses the I/O port 0x5658 ("VX" in ASCII) to communicate with the virtual machine. A piece of malware could detect the presence of that port by doing the following:

mov EAX, 564D5868h ; VMXh
xor EBX, EBX  ; set EBX to anything but 0x564D5868 (in this case 0)
mov CX, 0Ah   ; Backdoor command. 10: Get VMware version
mov DX, 5658h  ; VX
in EAX, DX  ; Read from port VX into EAX
cmp EBX, 564D5868h ; EBX should have the magic number VX is VMware is present. If not, EBX=0

Basically, the magic number 0×564D5868 ("VMXh") is copied to EAX and EBX is set to anything but 0x564D5868. A backdoor command is loaded into CX and finally the I/O port number 0x5658 ("VX") is loaded into DX. Then the "in" instruction is used to read from port 0x5658 into EAX. Outside of VMware (on a native host), a privilege error occurs. Under VMware, the magic number 0x564D5868 is returned to EBX (yes, in this case EBX is affected by in EAX, DX) hence the CMP instruction.

Exit if being debugged:

While this is not, per se, a anti-virtualization technique, it remains a a popular check performed by malware to see if a user-land debugger is present on the operating system. That's because more often than not a debugger will be installed in a virtual image used for malware analysis.

Eg: MD5: 74ab05d1ebdba509fd68711b360c1235 (Trojan.IRCBot-3475 by ClamAv)

.text:004050F8                 push    offset aZwquerysystemi ; "ZwQuerySystemInformation"
.text:004050FD                 push    [ebp+hModule]   ; hModule
.text:00405100                 call    ds:GetProcAddress
.text:00405106                 mov     [ebp+var_4], eax
.text:00405109                 push    offset aZwqueryinforma ; "ZwQueryInformationProcess"
.text:0040510E                 push    [ebp+hModule]   ; hModule
.text:00405111                 call    ds:GetProcAddress
.text:00405117                 mov     [ebp+var_14], eax
.text:0040511A                 cmp     [ebp+var_4], 0
.text:0040511E                 jz      short loc_405147

.text:00405120                 push    0
.text:00405122                 push    2   ; SystemInformationLength
.text:00405124                 lea     eax, [ebp+var_8]
.text:00405127                 push    eax ; SystemKernelDebuggerInformation
.text:00405128                 push    23h
.text:0040512A                 call    [ebp+var_4] ; ZwQueryInformationProcess
.text:0040512D                 test    eax, eax
.text:0040512F                 jnz     short loc_405147 ; process is being debugged

For the Windows API function ZwQuerySystemInformation, setting the value of SystemInfoClass to 2 (SystemKernelDebuggerInformation) retrieves system information on the presence of a user-land debugger.

NTSTATUS WINAPI ZwQuerySystemInformation(
__in       SYSTEM_INFORMATION_CLASS SystemInformationClass,
__inout    PVOID SystemInformation,
__in       ULONG SystemInformationLength,
__out_opt  PULONG ReturnLength
);

For the Windows API function ZwQueryInformationProcess, setting the value of ProcessInformationClass to 7 (ProcessDebugPort) retrieves the port number for the debugger of the process. A value other than 0 indicates that the process is being run through a user-land debugger.

NTSTATUS WINAPI ZwQueryInformationProcess(
__in       HANDLE ProcessHandle,
__in       PROCESSINFOCLASS ProcessInformationClass,
__out      PVOID ProcessInformation,
__in       ULONG ProcessInformationLength,
__out_opt  PULONG ReturnLength
);

How to thwart virtual machine detection:

For starters, do not install tools provided by the virtual machine in your guest OS. For example, VMware provides a set of tools called VMware Tools that enhances the overall user experience with the guest OS. The drawback is that installing VMware Tools in a Windows guest OS will leave many clues easily detectable by a piece malware that it is being run in a virtual machine.

The next step is to edit your VMware .vmx file. When you create a new virtual image with VMware, settings about it are stored in a configuration file with the .vmx extension. The file contains information about networking, disk size, devices attached to the virtual machine, etc...and is usually located in the directory where you created your virtual image. With your guest OS stopped, edit the .vmx file and append the following:

isolation.tools.setPtrLocation.disable = "TRUE"
isolation.tools.setVersion.disable = "TRUE"
isolation.tools.getVersion.disable = "TRUE"
monitor_control.disable_directexec = "TRUE"
monitor_control.disable_chksimd = "TRUE"
monitor_control.disable_ntreloc = "TRUE"
monitor_control.disable_selfmod = "TRUE"
monitor_control.disable_reloc = "TRUE"
monitor_control.disable_btinout = "TRUE"
monitor_control.disable_btmemspace = "TRUE"
monitor_control.disable_btpriv = "TRUE"
monitor_control.disable_btseg = "TRUE"

Now start your virtual machine. This will allow you to run (with very little effort) more vmware-aware malware than before.

I'll point out that:

1. monitor_control.disable_directexec = "TRUE" will usually thwart descriptor table registers checks. This setting will make VMware interpret each assembly instruction instead of executing them directly on the processor. Therefore a the result of a sidt instruction will not be an address in the 0xffXXXXXX range as one would get without this setting.
2. isolation.tools.getVersion.disable = "TRUE" will thwart the backdoor I/O check.

Now, what if after all this, your piece of malware still detects that it is being run in a virtual machine? I would go through the code, find where virtual machine checks are being performed and patch the code with NOPs (0x90).

Finally, if that's too hard or not possible for whatever reason, run your sample on a native system! :-) (you can always use system backup and restore software to quickly revert the machine to its original state without reinstalling the OS)

Microsoft Tuesday Coverage for October 2009

Bumper crop of vulnerabilities patched this month by Microsoft and Adobe.

Microsoft Security Advisory (MS09-050):
A vulnerability in the way that Microsoft Windows systems process SMBv2.0 transactions may allow a remote attacker to execute code on a vulnerable system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 16168.

Additionally, a previously released rule to detect attacks targeting this issue has been updated with the appropriate reference information and is included in this release and is identified with GID 1, SID 15930.

Microsoft Security Advisory (MS09-051):
A vulnerability in Windows Media Runtime may allow a remote attacker to execute code on a vulnerable system.

Rules to detect attacks targeting this vulnerability are included in this release and are identified with GID 3, SIDs 16157 and 16158.

Microsoft Security Advisory (MS09-052):
A vulnerability in the Windows Media Player may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 16156.

Microsoft Security Advisory (MS09-053):
A vulnerability in the FTP service for Microsoft Internet Information Services may allow a remote attacker to execute code on an affected system.

Previously released rules to detect attacks targeting this issue have been updated with the appropriate reference information and are included in this release, they are identified with GID 1, SIDs 1973, 2374 and 15932.

Microsoft Security Advisory (MS09-054):
Microsoft Internet Explorer contains programming errors that may allow a remote attacker to execute code on an affected system.

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

Microsoft Security Advisory (MS09-055):
A vulnerability in the way that ActiveX controls are handled may allow a remote attacker to execute code on a vulnerable system.

Rules to detect attacks targeting this vulnerability are included in this release and are identified with GID 1, SIDs 16159 through 16166.

Microsoft Security Advisory (MS09-056):
A vulnerability in the way that SSL certificates are handled by the Microsoft CryptAPI may allow a remote attacker to spoof a genuine certificate.

Rules to detect attacks targeting this issue are included in this release and are identified with GID 3, SIDs 16180 and 16181.

Microsoft Security Advisory (MS09-057):
A vulnerability in the Internet Explorer indexing service may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 16155.

Microsoft Security Advisory (MS09-059):
A vulnerability in the Microsoft Local Security Authority Subsystem Service (LSASS) may allow a remote attacker to cause a Denial of Service (Dos) against an affected system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 16167.

Microsoft Security Advisory (MS09-060):
Multiple vulnerabilities in the Microsoft Active Template Library (ATL) ActiveX controls for Microsoft Office may allow a remote attacker to execute code on an affected system.

Previously released rules to detect attacks targeting this issue have been updated with the appropriate reference information and are included in this release and are identified with GID 1, SIDs 15638, 15639, 15670, 15671, 15904 and 15905.

Microsoft Security Advisory (MS09-061):
Multiple vulnerabilities in the Microsoft .NET Common Language Runtime may allow a remote attacker to execute code on an affected system.

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

Microsoft Security Advisory (MS09-062):
Multiple vulnerabilities in Microsoft GDI+ may allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 3, SIDs 16153, 16154, 16177, 16178 and 16184 through 16186.

Additionally, previously released rules that also detect attacks targeting these vulnerabilities have been updated with the appropriate reference information and are included in this release, identified with GID 3, SID 13878 and GID 1, SID 6700.

Adobe Vulnerabilities:
Multiple products from Adobe corporation contain vulnerabilities that may allow a remote attacker to execute code on an affected system.

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

Changelogs are available here: http://www.snort.org/vrt/advisories/2009/10/13/vrt-rules-2009-10-13.html

Rule release for today - October 8th, 2009

The Sourcefire VRT is aware of a vulnerability affecting Adobe Acrobat and Reader. This is currently being exploited in the wild.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 16146.

See here: http://www.snort.org/vrt/advisories/2009/10/08/vrt-rules-2009-10-08.html

Rule release for today - October 6th, 2009

Lots of additions and modifications to web-client, specific-threats, web-misc, misc, backdoor and spyware-put rule groups in this release.

Check it out here: http://www.snort.org/vrt/advisories/2009/10/06/vrt-rules-2009-10-06.html

Rocket Pig still images

We also took some still photos of the Rocket Pig launch from last week. Here is Rocket Pig getting launched:



And the construction and firing of the Mk 1 Big Rocket.

Matt Olney, Alex Kambis and Ryan Pentney constructing the rocket:



Matt Olney checking the rocket motors are securely held in place using state of the art sticky tape technology:



Placing the rocket on the launch pad:



Ryan making sure the connections from the firing mechanism to the rocket motors are good:



Ready for launch:



Launch:



In flight, showing the laser straight trajectory:



We'd like to show photos of the rocket after the flight, unfortunately though, we can't do that because, well, we lost it somewhere. It may be in orbit or it may be in someones backyard, we're not sure which. What we do know is that NASA is really jealous of the fact that we can launch rockets into space using one billionth of their budget.

Rocket Pig

Here it is, for your pleasure, Rocket Pig....



BUT WAIT, there's more....



We have bigger plans, stay tuned.