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
That's a good question. We removed the 2 bleeding snort rules from
Chas Tomlin with this comment made by myself:
------
Removed, sids 2705, 2706, 2707 in the snort.org rulesets cover this
nicely
------
The original rules we had were:
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any
(msg:"BLEEDING-EDGE WEB-CLIENT MS04-028 exploiting jpeg";
flow:to_client,established; content:"Content-Type\: image/jpeg";
content:"|FF FE 00 00|"; classtype:attempted-user; sid:200326; rev:1;)
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any
(msg:"BLEEDING-EDGE WEB-CLIENT MS04-028 exploiting jpeg";
flow:to_client,established; content:"Content-Type\: image/jpeg";
content:"|FF FE 00 01|"; classtype:attempted-user;sid:2001327; rev:1;)
I don't think we had any serious problem with these rules, but I don't
recall exactly.
The snort.org rules that replaced these are:
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"WEB-CLIENT
JPEG parser heap overflow attempt"; flow:from_server,established; co
ntent:"image/"; nocase;
pcre:"/^Content-Type\s*\x3a\s*image\x2fp?jpe?g.*\xFF\xD8.{2}.*\xFF[\xE1\xE2\xED\xFE]\x00[\x00\x01]/smi";
reference:bugtraq,11173; reference:cve,2004-0200;
reference:url,www.microsoft.com/security/bulletins/200409_jpeg.mspx;
classtype:attempted-admin; sid:2705; rev:4;)
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"WEB-CLIENT
JPEG transfer"; flow:from_server,established; content:"image/";
nocase; pcre:"/^Content-Type\s*\x3a\s*image\x2fp?jpe?g/smi";
flowbits:set,http.jpeg; flowbits:noalert;
classtype:protocol-command-decode; sid:2
706; rev:2;)
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"WEB-CLIENT
JPEG parser multipacket heap overflow"; flow:from_server,established
; flowbits:isset,http.jpeg; content:"|FF|";
pcre:"/\xFF[\xE1\xE2\xED\xFE]\x00[\x00\x01]/";
reference:bugtraq,11173; reference:cve,2004-0200;
reference:url,www.microsoft.com/security/bulletins/200409_jpeg.mspx;
classtype:attempted-admin; sid:2707; rev:2;)
Which I just realized I have had commented out for a while. I don't
recall if there were problems when I dropped them way back when, so
I'm turning them back on to see how they do.
Can anyone comment on their accuracy?
Matt
Chris Kronberg wrote:
Hi,
Has anyone a working rule for that gdi exploit? I've seen
that the two rules once on bleedingsnort have been removed
(good thing as they produced tons of false positives). Yet
I failed to see any alternative. Any idea how the virus
scanners find those jpegs without too much false positives?
Cheers,
Chris Kronberg.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Snort-sigs mailing list
Snort-sigs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
