[Emerging-Sigs] Snort's http_inspect and http_header - New Gotcha

Joel Esler jesler at sourcefire.com
Thu Oct 14 18:21:27 EDT 2010


I think http 1.1 stuff is uri. But I'm on my phone and can't confirm right now.

Should send this to snort-sigs.

J

On Thursday, October 14, 2010, Eoin Miller
<eoin.miller at trojanedbinaries.com> wrote:
>   So I spent a good deal of time today trying to troubleshoot some sigs
> for ZeuS and I think I finally figured out what was going wrong. The
> http_header content modifier doesn't quite work completely like I think
> it does and others may have the same mindset so I figured this may be
> good info for others writing sigs that make user of its functionality.
>
> Here is the packet we will be going over:
> ========================================================================
> 0000   50 4f 53 54 20 2f 71 77 65 2f 77 65 72 74 2e 70  POST /qwe/wert.p
> 0010   68 70 20 48 54 54 50 2f 31 2e 31 0d 0a 41 63 63  hp HTTP/1.1..Acc
> 0020   65 70 74 3a 20 2a 2f 2a 0d 0a 55 73 65 72 2d 41  ept: */*..User-A
> 0030   67 65 6e 74 3a 20 4d 6f 7a 69 6c 6c 61 2f 34 2e  gent: Mozilla/4.
> 0040   30 20 28 63 6f 6d 70 61 74 69 62 6c 65 3b 20 4d  0 (compatible; M
> 0050   53 49 45 20 38 2e 30 3b 20 57 69 6e 64 6f 77 73  SIE 8.0; Windows
> 0060   20 4e 54 20 35 2e 31 3b 20 54 72 69 64 65 6e 74   NT 5.1; Trident
> 0070   2f 34 2e 30 3b 20 2e 4e 45 54 20 43 4c 52 20 32  /4.0; .NET CLR 2
> 0080   2e 30 2e 35 30 37 32 37 3b 20 2e 4e 45 54 20 43  .0.50727; .NET C
> 0090   4c 52 20 33 2e 30 2e 30 34 35 30 36 2e 33 30 3b  LR 3.0.04506.30;
> 00a0   20 2e 4e 45 54 20 43 4c 52 20 33 2e 30 2e 34 35   .NET CLR 3.0.45
> 00b0   30 36 2e 32 31 35 32 3b 20 2e 4e 45 54 20 43 4c  06.2152; .NET CL
> 00c0   52 20 33 2e 35 2e 33 30 37 32 39 3b 20 49 6e 66  R 3.5.30729; Inf
> 00d0   6f 50 61 74 68 2e 32 29 0d 0a 48 6f 73 74 3a 20  oPath.2)..Host:
> 00e0   69 65 6a 74 75 71 75 74 71 65 2e 63 6f 6d 0d 0a  iejtuqutqe.com..
> 00f0   43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20  Content-Length:
> 0100   32 39 33 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a  293..Connection:
> 0110   20 4b 65 65 70 2d 41 6c 69 76 65 0d 0a 43 61 63   Keep-Alive..Cac
> 0120   68 65 2d 43 6f 6e 74 72 6f 6c 3a 20 6e 6f 2d 63  he-Control: no-c
> 0130   61 63 68 65 .. .. .. .. .. .. .. .. .. .. .. ..  ache
> ========================================================================
>
> Now we know the order of the buffers in this is http_method (POST):
> ========================================================================
> 0000   50 4f 53 54                                      POST
> ========================================================================
>
> http_uri (/qwe/wert.php):
> ========================================================================
> 0000 2f 71 77 65 2f 77 65 72 74 2e 70       /qwe/wert.p
> 0010   68 70                                            hp
> ========================================================================
>
> http_header should be rest of bytes in the example packet right? Well
> not so fast, it appears the next few bytes |20|HTTP/1/1|0D 0A| is
> actually not part of the http_header. In reading the docs, I am not sure
> this is part of any http_inspect buffer at all. This was causing me some
> heartburn when trying to work on those ZeuS sigs over the last two days
> because I was using that to ensure that the content matches were at the
> exact top of the http header. So the rest of the bytes in the buffer for
> http_header should look like the following (in theory):
> ========================================================================
> 0010   .. .. .. .. .. .. .. .. .. .. .. .. .. 41 63 63               Acc
> 0020   65 70 74 3a 20 2a 2f 2a 0d 0a 55 73 65 72 2d 41  ept: */*..User-A
> 0030   67 65 6e 74 3a 20 4d 6f 7a 69 6c 6c 61 2f 34 2e  gent: Mozilla/4.
> 0040   30 20 28 63 6f 6d 70 61 74 69 62 6c 65 3b 20 4d  0 (compatible; M
> 0050   53 49 45 20 38 2e 30 3b 20 57 69 6e 64 6f 77 73  SIE 8.0; Windows
> 0060   20 4e 54 20 35 2e 31 3b 20 54 72 69 64 65 6e 74   NT 5.1; Trident
> 0070   2f 34 2e 30 3b 20 2e 4e 45 54 20 43 4c 52 20 32  /4.0; .NET CLR 2
> 0080   2e 30 2e 35 30 37 32 37 3b 20 2e 4e 45 54 20 43  .0.50727; .NET C
> 0090   4c 52 20 33 2e 30 2e 30 34 35 30 36 2e 33 30 3b  LR 3.0.04506.30;
> 00a0   20 2e 4e 45 54 20 43 4c 52 20 33 2e 30 2e 34 35   .NET CLR 3.0.45
> 00b0   30 36 2e 32 31 35 32 3b 20 2e 4e 45 54 20 43 4c  06.2152; .NET CL
> 00c0   52 20 33 2e 35 2e 33 30 37 32 39 3b 20 49 6e 66  R 3.5.30729; Inf
> 00d0   6f 50 61 74 68 2e 32 29 0d 0a 48 6f 73 74 3a 20  oPath.2)..Host:
> 00e0   69 65 6a 74 75 71 75 74 71 65 2e 63 6f 6d 0d 0a  iejtuqutqe.com..
> 00f0   43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20  Content-Length:
> 0100   32 39 33 0d 0a 43 6f 6e 6e 65 63 74 69 6f 6e 3a  293..Connection:
> 0110   20 4b 65 65 70 2d 41 6c 69 76 65 0d 0a 43 61 63   Keep-Alive..Cac
> 0120   68 65 2d 43 6f 6e 74 72 6f 6c 3a 20 6e 6f 2d 63  he-Control: no-c
> 0130   61 63 68 65 .. .. .. .. .. .. .. .. .. .. .. ..  ache
> ========================================================================
>
> So yea, that was a bit of a PITA, but I think I am able to create some
> sigs that still use http_inspect content modifiers despite this. I'll
> keep monkeying around with stuff and update/create a new more in depth
> blog post about this for everyone with color coded buffers that should
> be nice and easy to understand.
>
> -- Eoin
>
>
>
>
> _______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs at emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>
> Support Emerging Threats! Get your ET Stuff! Tshirts, Coffee Mugs and Lanyards
> http://www.emergingthreats.net/index.php/support-et-and-buy-et-schwag.html
>


More information about the Emerging-sigs mailing list