[Snort-sigs] Question about Content-Disposition, Content-Type, etc. and http_header buffer

Mike Cox mike.cox52 at ...2420...
Wed Oct 17 11:45:47 EDT 2012


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 at ...435...> 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 at ...2420...> 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 at 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!
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20121017/694d1a1c/attachment.html>


More information about the Snort-sigs mailing list