Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: [Snort-sigs] Substitute for removed MS04-028 exploiting jpeg rule? |
|---|---|
| Date: | Wed, 24 Nov 2004 13:43:49 -0500 |
Thanks for the extra information. Good to know where we are.
Matt
Matt,
You've beat me to the punch pointing out that there are Sourcefire rules to be used here. That's what I get for being buried in OpenSSL/ASN.1 junk this morning. :-)
In any case, as to the rules' accuracy -- in a nutshell, the Sourcefire rules are going to catch more cases and have less false positives, but they're still not perfect. Let me outline quickly the cases where they do better detection (and why), and then the reasons why they still have issues:
* You'll note that the header matching -- for "Content-Type" -- allows for space evasions and makes the "e" in "jpeg" optional. This last bit is crucial, since Content-Type: image/jpeg and Content-Type: image/jpg are both valid.
* The Sourcefire rules check for 0xE1, 0xE2, 0xED, or 0xFE following the 0xFF in the JPEG header instead of just 0xFE. This is important, since any of these bytes following the 0xFF can be used in a valid exploit.
* Using PCRE is helpful in that it allows us to combine two rules -- one for a length of zero, one for a length of one -- into one rule.
* Flowbits allow us to catch exploiting JPEGs that come later down a stream -- for example, if a packet boundary happens to happen between the Content-Type and the actual malicious JPEG.
There are two problems that still remain with these rules. First and foremost, flow_depth must be turned off (set to 0) in order for proper detection to occur; depending upon the volume of traffic you're inspecting, this can cause performance issues. Second, this is prone to false positives if these bytes appear in the data section of an HTTP request (which could happen with a web page where someone was describing the exploit, for example); there's just not a good way to validate that we're in the header section for the Content-Type match.
YMMV with these rules...but you're free to turn them on and see what happens. :-)
Alex Kirk
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [Snort-sigs] netbios rules, Tim Slighter |
|---|---|
| Next by Date: | Re: [Snort-sigs] sig 2671, Matthew Watchinski |
| Previous by Thread: | Re: [Snort-sigs] Substitute for removed MS04-028 exploiting jpeg rule?, Chris Kronberg |
| Next by Thread: | [Snort-sigs] netbios rules, Tim Slighter |
| Indexes: | [Date] [Thread] [Top] [All Lists] |