Re: Question about Content-Disposition, Content-Type, etc. and http_header buffer

[Joel Esler <jesler () sourcefire com>]

Well, from the looks of the "dump" (or whatever you sent below) it looks like there are multiple carriage returns in 
there.

If the "header" of an http session has |0d 0a 0d 0a|, according to the RFC which states that character sequence 
indicates the end of the header, and the start of the packet data.  In which case the http_inspect preprocessor will 
move onto the http_client_data buffer.

Hence why I asked for the pcap, to see if this is true.  We can create a pcap that looks like yours below, but I know 
the exact behavior of the preprocessor in this case.

If you wanted to test it, you could do a 
content:"Content-Type"; http_header; content:"Content-Disposition"; http_header; distance:0;

which you indicated doesn't work.

then test by doing:

content:"Content-Type"; http_header; content:"Content-Disposition"; http_client_body;

and if that fires, then there's your problem.  Broken RFC adherence by whatever program is generating that traffic.

--
Joel Esler
Senior Research Engineer, VRT
OpenSource Community Manager
Sourcefire


On Oct 17, 2012, at 11:45 AM, Mike Cox <mike.cox52 () gmail com> wrote:

> Hey Joel, thanks for the quick response.  Right now I don't have a pcap ... the info I got was reproduced from what I 
> saw on a screen while helping our guys/gals track down an issue/RCA in the "Temptest" (SOC) room and I can't get any 
> data out of there and if I could, it would be breaking many laws (well, internal "laws" but there could be 
> international intel impact and NDA lawsuits if you know what I mean :)
>
> However, I think that the information provided is sufficient to illustrate this issue and it should be trivial for 
> VRT to create necessary pcaps for their testing, if that is what you want.
>
> I can cook up a pcap but as earlier implied, I don't think it is is necessary for me to provide this at this point 
> and I certainly do not want to insult VRT by spoon-feeding them data that they can easily and more completely create 
> on their own with minimal effort.
>
> I believe that I have outlined the issue and provided the necessary data to accurately describe the problem.  Even 
> without a pcap, I think the info provided is sufficient for a good discussion.  Has anyone else experienced this 
> challenge with their snort installs?  If so, how do you deal with this nuance of HTTP and the current state of 
> http-inspect?
>
> Please let me know if you are unclear on anything or need more information regarding this issue.
>
> Thanks all.
>
> -Mike Cox
>
>
>
> On Tue, Oct 16, 2012 at 4:51 PM, Joel Esler <jesler () sourcefire com> wrote:
> Can you send me a pcap?
>
> --
> Joel Esler
> Senior Research Engineer, VRT
> OpenSource Community Manager
> Sourcefire
>
> On Oct 16, 2012, at 5:18 PM, Mike Cox <mike.cox52 () gmail com> wrote:
>
> > I've noticed that in some multipart/form-data POSTs, data that is normally in the HTTP header gets sent in the body 
> > of the message and not parsed by http-inspect as part of the http_header buffer.  Specifically, the headers 
> > "Content-Type", "Content-Disposition", and "Content-Transfer-Encoding", although there could be others.  For example:
> >
> > POST /blackhole/safe.php HTTP/1.1
> > Host: snort.org
> > Content-Type: multipart/form-data, boundary=---dG91Y2hteXNub3J0
> > Content-Length: 8675309
> >
> > ---dG91Y2hteXNub3J0
> > Content-Disposition: form-data; name="name"
> >
> > Joshua
> > ---dG91Y2hteXNub3J0
> > Content-Disposition: form-data; name="play_a_game"
> >
> > True
> > ---dG91Y2hteXNub3J0
> > Content-Disposition: form-data; name="file"; filename="GLOBAL_THERMONUCLEAR_WAR.pdf"
> > Content-Type: application/pdf
> > Content-Transfer-Encoding: binary
> > ...
> >
> > So a snort rule looking for a specific filename in a Content-Disposition header wouldn't match if it were written as 
> > you would expect it to be written.  For example, this wouldn't match the above:
> >
> > alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Bad PDF File Upload"; flow:established,to_server; 
> > content:"Content-Disposition"; http_header; content:"filename="; distance:0; http_header; content:".pdf"; 
> > distance:0; within:100; http_header; sid:1234567;)
> >
> > What is the best way to match this and not incur the overhead of using global content matches?  Is there a plan for 
> > the http-inspect pre-processor to account for this?
> >
> > Thanks.
> >
> > -Mike Cox
> > ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_sfd2d_oct_______________________________________________
> > Snort-sigs mailing list
> > Snort-sigs () lists sourceforge net
> > https://lists.sourceforge.net/lists/listinfo/snort-sigs
> > http://www.snort.org
> >
> >
> > Please visit http://blog.snort.org for the latest news about Snort!

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct

_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs
http://www.snort.org


Please visit http://blog.snort.org for the latest news about Snort!