[Oisf-users] Suricata Cookie Header Questions

[Duane Howard]

Also, somewhat related:
Are these parsed irrespective of direction? For example, if a bonkers
server sent "Cookie:" or a bad client set "Set-Cookie:" would those both
still map to the cookie buffer?

On Thu, Apr 14, 2016 at 2:36 PM, Duane Howard <duane.security at gmail.com>
wrote:

> Thanks Victor,
>
> The example response on the wiki page doesn't make it clear that
> 'Set-Cookie:' also applies here. In fact it includes 'Set-Cookie:' in the
> http_header, http_raw_header definition.
>
> On Thu, Apr 14, 2016 at 1:53 PM, Victor Julien <lists at inliniac.net> wrote:
>
>> On 14-04-16 22:16, Duane Howard wrote:
>> > According
>> > to:
>> https://redmine.openinfosecfoundation.org/projects/suricata/wiki/HTTP-keywords
>> > """Although cookies are sent in an HTTP header, you can not match on
>> > them with the http_header keyword. Cookies are matched with their own
>> > keyword, namely http_cookie."""
>> >
>> > I had a couple of questions about this:
>> >
>> >  1. Is this documentation still accurate?
>>
>> Yes.
>>
>> Note that it also applies to Set-Cookie.
>>
>> >  2. Does this mean that Suricata will effectively strip the 'Cookie:
>> >     foo=120398' out from the http_header buffer? Or will it still
>> >     contain 'Cookie:' for example? [0]
>>
>> It is stripped (or actually not included in reconstruction):
>>
>> https://github.com/inliniac/suricata/blob/master/src/detect-engine-hhd.c#L165
>>
>> >  3. If above is true, is the correct way to perform relative matches of
>> >     'Cookie: foo=12398' to other header fields to use a plain content
>> >     match, and not the http_header buffer?
>>
>> Use http_raw_header. It does include the cookie headers.
>>
>> >
>> > If my understanding of this is correct I think there's at least one ET
>> > rules that are probably not working as intended, since I see content
>> > negations of 'Cookie|3A|'; http_header; as well as Cookie value checks
>> > against http_header. Example rule from ET Open[1]
>> >
>> > [0] Does this:
>> > GET /foo.js HTTP/1.1
>> > Host: no.evil.com <http://no.evil.com>
>> > Cookie: UID=17220493a47a2391519d61c144a531063; UIDR=1649534063; CP3=4
>> > Connection: keep-alive
>> > Cache-Control: max-age=0
>> > Accept: */*
>> > User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML,
>> > like Gecko) Chrome/49.0.2623.110 Safari/537.36
>> > Referer: http://www.referme.com
>> > Accept-Encoding: gzip, deflate, sdch
>> > Accept-Language: en-US,en;q=0.8
>> >
>> > yield this for http_header?
>> > Host: no.evil.com <http://no.evil.com>
>> > Connection: keep-alive
>> > Cache-Control: max-age=0
>> > Accept: */*
>> > User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML,
>> > like Gecko) Chrome/49.0.2623.110 Safari/537.36
>> > Referer: http://www.referme.com
>> > Accept-Encoding: gzip, deflate, sdch
>> > Accept-Language: en-US,en;q=0.8
>> >
>> > Example of ET Rule that's probably broken:
>> > [1] alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET
>> > CURRENT_EVENTS DRIVEBY EgyPack Exploit Kit Cookie Set";
>> > flow:established,from_server; *content:"Cookie|3a| visited=TRUE";
>> > http_header;* *content:"Cookie|3a| mutex="; http_header;*
>> > reference:url,www.kahusecurity.com/2011/new-exploit-kit-egypack/
>> > <http://www.kahusecurity.com/2011/new-exploit-kit-egypack/>;
>> > reference:url,
>> www.vbulletin.com/forum/forum/vbulletin-3-8/vbulletin-3-8-questions-problems-and-troubleshooting/346989-vbulletin-footer-sql-injection-hack
>> > <
>> http://www.vbulletin.com/forum/forum/vbulletin-3-8/vbulletin-3-8-questions-problems-and-troubleshooting/346989-vbulletin-footer-sql-injection-hack
>> >;
>> > reference:url,
>> blog.webroot.com/2013/03/29/a-peek-inside-the-egypack-web-malware-exploitation-kit/
>> > <
>> http://blog.webroot.com/2013/03/29/a-peek-inside-the-egypack-web-malware-exploitation-kit/
>> >;
>> > classtype:bad-unknown; sid:2014407; rev:3;)
>> >
>>
>> Looks like this is indeed broken.
>>
>> --
>> ---------------------------------------------
>> Victor Julien
>> http://www.inliniac.net/
>> PGP: http://www.inliniac.net/victorjulien.asc
>> ---------------------------------------------
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20160414/51732026/attachment-0002.html>