[Oisf-users] Suricata Cookie Header Questions
Victor Julien
lists at inliniac.net
Fri Apr 15 09:25:25 UTC 2016
On 14-04-16 23:38, Duane Howard wrote:
> 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?
Cookie is only excluded from http_header when sent in the TOSERVER
direction.
Set-Cookie is only excluded from http_header when sent in TOCLIENT
direction.
See
https://github.com/inliniac/suricata/blob/master/src/detect-engine-hhd.c#L170
Btw, the check for those headers is case insensitive, so cOoKiE would
also be excluded.
The http_cookie *only* looks at Cookie when sent TOSERVER and only looks
at Set-Cookie when sent TOCLIENT
See
https://github.com/inliniac/suricata/blob/master/src/detect-engine-hcd.c#L154
So if you want to match on a Cookie header in the TOCLIENT direction you
can use http_header.
In all cases you can use http_raw_header, although there you can't make
assumptions about some things like end of line characters, etc. It's not
normalized.
Cheers,
Victor
>
> On Thu, Apr 14, 2016 at 2:36 PM, Duane Howard <duane.security at gmail.com
> <mailto: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
> <mailto: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> <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> <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/>
> > <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>
> >
> <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/>
> >
> <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
> ---------------------------------------------
>
>
>
--
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------
More information about the Oisf-users
mailing list