Wednesday, September 30, 2009

Rocket Pig

Just to add a little impetus to the twitter voting, here is the rocket pig...

 
Posted by Picasa


 
Posted by Picasa


If you want to see the video of this pig in action, retweet this blog post.

Tuesday, September 29, 2009

of Pigs and Rockets

It was a quiet day at Sourcefire World Domination Headquarters and somebody wasn't keeping a close eye on the stock of squishy pigs that we give out at trade shows. The VRT had just finished some intensive work and it was a fine Friday afternoon in September. We had some model rocket motors laying around and we got to thinking, "What can we do with these pigs we just acquired and those rocket motors?".

First, we took a small rocket motor and attached it to the rear end of a pig, cut up a water bottle to use as a launching pad, took it out to the parking lot and fired it up. It went reasonably well. Then we took a larger rocket motor, cut up another water bottle to make a larger launch pad and let that go. Finally, we dissected a rocket motor, took the fuel out and hollowed out another pig. We filled the cavity with the fuel and set that off.

Here are the results:



We weren't completely satisfied with the height we got with the rocket motor powered pigs, so we built a launch pad, made a better rocket, added fins and placed the pig on top. If you want to see the results, hit us up on twitter and if we get enough requests, we'll post the video.

Update:
The exploding pig in slow motion.

Thursday, September 24, 2009

Bamboo -> angel tongue

Here's a quickie exploitable linux program from our Fundamentals of Exploitation class. How many vulns can you find and exploit?

#include <stdio.h>

struct newClass {
char type;
int size;
char *data;
void (*printer)(char*);
};

void painter(char *input) {
char buf[4096];

memcpy(buf, input, sizeof(buf)<strlen(input)?sizeof(buf):strlen(input));
return;
}

void initStruct(char *input) {
struct newClass myClass;

myClass.type = *((char *)(input));
myClass.size = *((int *)(input+1));
myClass.data = ((char *)(input+5));

if (myClass.type == 1)
myClass.printer = (void *)printf;
if (myClass.type == 2)
myClass.printer = (void *)putchar;
if (myClass.type == 3)
myClass.printer = (void *)puts;
if (myClass.type > 3)
exit(1);

myClass.printer(myClass.data);
}

int main(int argc, char **argv) {
if (argc < 2)
exit(1);
painter(argv[2]);
initStruct(argv[1]);

return (0);
}

Thursday, September 17, 2009

Rule release for today - September 17, 2009

Maintenance release that adds support for shared object rules for the Snort 2.8.5 release. Also, additions to the web-client, specific-threats, web-misc, misc, oracle and exploit rule sets.

More information and changelogs here

Wednesday, September 16, 2009

Snort 2.8.5 Release

We warned you in the August Vulnerability Report that Snort 2.8.5 was almost ready to be released. Well, today is the day. Snort 2.8.5 is now available for download.

All VRT Certified rule releases will now be 2.8.5 compliant and we will cease to support 2.8.4 (in 90 days) in favor of this latest release. Here are some highlights from the release notes:


  • Ability to specify multiple configurations (snort.conf and everything it includes), bound either by Vlan ID or IP Address. This allows you to run one instance of Snort with multiple snort.conf files, rather than having separate processes. See README.multipleconfigs for details.
  • Continued inspection of traffic while reloading a configuration.
    Add --enable-reload option to your configure script prior to building. See README.reload for details.
  • Rate Based Attack Prevention for Connection Attempts, Concurrent Connections, and improved rule/event filtering. See README.filters for details.
  • SSH preprocessor is no longer experimental
  • Multiple performance improvements


The full release notes are available here.

We strongly suggest you upgrade your snort installations. Here's some notes you might want to read when upgrading software.

Tuesday, September 15, 2009

Rule release for today - September 15, 2009

Mostly a maintenance release, we added multiple rules in the specific-threats, dns, web-client, dos, ftp and misc categories.

Details here.

Monday, September 14, 2009

Vulnerability Report September 2009



This month's report covers three of the Microsoft Tuesday advisories, a remote code execution vulnerability in SMBv2, a vulnerability in the IIS FTP module and information on Dojocon

Thursday, September 10, 2009

SMBv2 <air quotes> DoS </air quotes>

Here's the dirty dirty dirt dirt. (All addresses SP2)

If you send an SMBv2 packet off to Vista SP1 or SP2 that specifies the NEGOTIATE command, and the ProcessIDHigh word is not set to 0x0000, you do not in fact get a DoS. What happens, is this: (Note that we control eax, and esi points to our packet)

  1. 9914d6b7 8b048570521699 mov eax,dword ptr [ValidateRoutines + eax*4]
  2. 9914d6be 85c0 test eax,eax
  3. 9914d6c0 7507 jne 9914d6c9
  4. 9914d6c2 b8020000c0 mov eax,0C0000002h
  5. 9914d6c7 eb03 jmp 9914d6cc
  6. 9914d6c9 53 push ebx
  7. 9914d6ca ffd0 call eax


In this code, the eax in line 1 is in fact our ProcessIDHigh from the NEGOTIATE packet, and ValidateRoutines is a small dispatch table in the srv2.sys driver. After this dispatch table which is about 0x13 addresses long, (I didn't really count) there are several global variables specifying max values for certain things that I found to be uninteresting. The interesting thing is that if ValidateRoutines is at 0x99165270 and srv2.sys ends at 0x9916efff and 0xffff * 4 is 0x03FFFC, then we have quite a lot of space to go looking for pointers; not just in srv2.sys, but also in the immediately proceeding driver.


Now you have the problem of finding useful executable code to get you to esi, and also finding a pointer to this code within the space you have (0x03FFFC from ValidateRoutines). You can go about this in one of two ways. Firstly, you can find all of the jmp esi, call esi, and push esi -> ret calls in executable kernel memory, then search through the list of pointers in the range to see if they point at any of these instructions. This is very time consuming. The alternative is that you can use HD Moore's method of looking at all the possible pointers in this range, checking their symbols, and seeing if any of them point at anything executable and controllable. This method netted the following solution.


In the case of Vista SP1, the driver occupying the next address space is srvnet.sys. This is lucky because inside srvnet.sys (near the top) there is a pointer to a global variable which can be controlled by an external user: srvnet!SrvNetStatistics. In SP2, srvnet is loaded before srv2.sys so we cannot make use of the same global. However, we get lucky here as well in that there is a pointer srv!pSrvStatistics which also points to srvnet!SrvNetStatistics, and counts the number of requests that have been made to a specific call (as well as other things).


So the technique here is to firstly increment srvnet!SrvNetStatistics to be ffe6, ffd6, or 56c3 (jmp esi, call esi, push esi -> ret). Then we set ProcessHighID to a value that when multiplied by four and added to the base address of ValidateRoutines pushes us outside of srv2.sys and into srvnet.sys where we then end up dereferencing the pointer to srvnet!SrvNetStatistics. This now transfers control to the data in our packet which we can massage to gain execution.


. The problem here is that we don't know how many times things have been called before we got to the target. One way to handle this is to build our opcode with the GET_PRINT_QUEUE undocumented command. This SMBv2 command is in the dispatch table (just like NEGOTIATE) but it is undocumented and unimplemented, immediately calling a function which logs that it was called, and exits after incrementing a value in srvnet!SrvNetStatistics. We can safely assume that we're the only ones calling this function, and increment this counter value until it becomes an opcode that puts esi into eip. Note that this will require you to send a number of GET_PRINT_QUEUE requests equal to the opcode of the instruction you want. For push esi, ret, this will require you to send 0x56c3 requests. Thankfully, though, this can be done effectively in just a couple of minutes. If you'd like to be more stealthy, you can string it out over many days.


There are a few other hurdles to jump over, such as the possibility that somewhere else in functions have been called in such a way that the values in srvnet!SrvNetStatistics are opcodes that screw up esi or eax as well as the fact that esi points directly to our packet, not to fully controllable data. Currently, no one to my knowledge has a reliable remote exploit for this vulnerability finished. This said, I'm fairly confident that this method will become 100% reliable for remote code execution in the future.

Wednesday, September 9, 2009

Rule release for today - September 9, 2009

A quick release for an update to SID 15930 to address the possibility of remote code execution for the Microsoft Windows SMBv2 processing vulnerability.

Information is available on snort.org here

Tuesday, September 8, 2009

Microsoft Tuesday Coverage for September 2009

Microsoft Security Advisory (MS09-045):
The Microsoft JScript scripting engine contains a programming error that may allow a remote attacker to execute code on an affected host.

Microsoft Security Advisory (MS09-046):
The Microsoft DHTML Editing Component ActiveX control contains a programming error that may allow a remote attacker to execute code on an affected system.

Microsoft Security Advisory (MS09-047):
A programming error in the way that Microsoft Windows systems parse certain types of Windows media files, may allow a remote attacker to execute code on an affected system.

Microsoft Security Advisory (MS09-048):
A vulnerability exists in the Microsoft Windows TCP/IP stack that may allow a remote attacker to execute code on an affected system.

Microsoft SMB2 Denial of Service (DoS):
A vulnerability in the way that Microsoft Windows systems process SMB2.0 transactions may allow a remote attacker to cause a Denial of Service (DoS) against a vulnerable machine.

More information is available here.

Wednesday, September 2, 2009

Microsoft IIS FTP Vulnerability - bad detection

Yesterday, we wrote about the Microsoft IIS FTP stack overflow. (here) Since then, we've seen some folks try to come up with detection for attacks targeting this vulnerability.

Here's some things to think about when detecting this attack:

  1. We saw some rules that detected the SITE command as the vulnerable condition for exploitation, this is not where the problem lies. Its in the NLST command when it parses long directory names. The SITE command in the released exploit (archived on milw0rm) is used to store shellcode into memory, so it can be egghunted later when the exploit is triggered. While looking for the SITE command will detect attempts to use this particular exploit, there are plenty of other ways to store your shellcode in memory before triggering this vulnerability, which would evade anything using the SITE method for detection.

  2. One of the things that all snort rule writers should remember is that to keep performance of the engine up, you need to look for ways to "fail" your rule as quickly as possible. Before doing something like a "not content" check at some distance into the packet, use something like isdataat to determine if the packet is actually that big before doing the check. We've seen rules for this vulnerability that don't do this, even though you're talking about microseconds for one rule, if you have lots of rules that don't conform to this then the effect is cumulative. Performance can then become an issue.

Tuesday, September 1, 2009

Rule release for today - September 1, 2009

Microsoft IIS FTP Buffer Overflow: The Microsoft FTP module for Internet Information Services (IIS) contains a programming error that may allow a remote attacker to execute code on an affected system. The problem occurs in the processing of specially crafted directory names which an attacker can leverage to cause a stack-based buffer overflow.

Previously released rules will detect attacks targeting this vulnerability and are identified with GID 1, SIDs 1529, 1973, 2374 and 3441. Additionally, the FTP Telnet preprocessor will detect attacks targeting this vulnerability. These events are identified with GID 125, SIDs 3, 6 and 8.

(see this blog post: http://vrt-sourcefire.blogspot.com/2009/09/microsoft-iis-ftp-vulnerability.html)

Additionally, as a result of ongoing research, the Sourcefire VRT has added multiple rules to the web-activex, web-client, specific-threats, shellcode and bad-traffic rule sets to provide coverage for emerging threats from these technologies.

More info and changelogs here: http://www.snort.org/vrt/advisories/2009/09/01/vrt-rules-2009-09-01.html

Microsoft IIS FTP Vulnerability

We saw some exploit code posted to milw0rm yesterday that relates to a vulnerability in the Microsoft IIS FTP module. Basically, it exploits a vulnerability where the server doesn't correctly parse directory names. The attacks makes use of the FTP NLST command which will cause a stack overflow to occur when the name of the directory contains certain characters. The exploit itself uses the directory name w00t$port but this should not be relied upon for detection purposes, also the shellcode should not be used for detection either.

Fortunately, Snort has detection dating back over 5 years for this issue.

The following Snort rules will catch this attack:
2374 - FTP NLST overflow attempt
3441 - FTP PORT bounce attempt
1973 - FTP MKD overflow attempt
1529 - FTP SITE overflow attempt

Also, the FTP/Telnet preprocessor will also generate events for this attack:
125:3:1 - FTP Parameter Length Overflow
125:6:1 - FTP Response Length Overflow
125:8:1 - FTP Bounce