Re: HttpInpsect/HTTP preprocessor: false positives + parsing of header/body?

[Bram <bram-fabeg () mail wizbit be>]

Hi,

I understand it you mean:

preprocessor stream5_tcp: policy first, ports both 80 8080


Changing the config to that does indeed case the false positives to go away.

However: this means that every HTTP port needs to be listed in the  
stream5_tcp preprocessor and that this is not enforced..
Is that expected?

Looking at the default snort config shows that the ports '1741' and  
'8181' are listed as ports for the http preprocessor but are not  
listed as server ports for the stream5 preprocessor.. (they are listed  
as client ports but I don't think that sufficient).
Shouldn't these port be listed as 'both'? since otherwise it will  
results in false positives when connecting to servers on that port...


Best regards,

Bram



Quoting Russ Combs <rcombs () sourcefire com>:

> Bram - looks like your tcp config is missing the client | server | both
> keyword between ports and 80.  Consequently, 80 is being lost and
> reassembly is set to both for 8080 only.  Changing to this:
>
> preprocessor stream5_tcp: policy first, ports 80 8080
>
> prevents the false positives you encountered.  I'll file a bug to get that
> error detected.
>
> Thanks
> Russ
>
> On Mon, Aug 12, 2013 at 8:50 AM, Bram <bram-fabeg () mail wizbit be> wrote:
>
> > Hi,
> >
> >
> > There appear to be several false positives in the HTTP preprocessor.
> >
> > Attempting to find the source of the false positives led me to the
> > 'HttpResponseInspection' in preprocessors/HttpInspect/**
> > server/hi_server.c.
> >
> > What *appears* to be happening is that 'HttpResponseInspection' makes the
> > distinction between header and body based on the first five bytes in the
> > buffer.
> > When the buffer starts with 'HTTP/' then it seems to parse the packet as
> > HTTP Headers, when it does not start with 'HTTP/' then it seems to parse
> > the packet as HTTP Body.
> >
> > This looks incorrect... there is no reason for all the HTTP headers to be
> > in a single packet nor is there a reason for the HTTP body to be in a
> > separate packet...
> > The end of the HTTP header is indicated by an empty line.. (i.e., a line
> > with nothing preceding the CRLF)
> >
> >
> > Configuration used:
> >         dynamicpreprocessor directory /usr/lib/snort_**
> > dynamicpreprocessor/
> >         preprocessor stream5_global: \
> >            track_tcp yes, \
> >            track_udp no, \
> >            track_icmp no
> >         preprocessor stream5_tcp: policy first, ports 80 8080
> >
> >         preprocessor http_inspect: global iis_unicode_map unicode.map 1252
> > compress_depth 65535 decompress_depth 65535
> >         preprocessor http_inspect_server: server default \
> >             http_methods { GET POST PUT SEARCH MKCOL COPY MOVE LOCK UNLOCK
> > NOTIFY POLL BCOPY BDELETE BMOVE LINK UNLINK OPTIONS HEAD DELETE TRACE TRACK
> > CONNECT SOURCE SUBSCRIBE UNSUBSCRIBE PROPFIND PROPPATCH BPROPFIND
> > BPROPPATCH RPC_CONNECT PROXY_SUCCESS BITS_POST CCM_POST SMS_POST
> > RPC_IN_DATA RPC_OUT_DATA RPC_ECHO_DATA } \
> >             chunk_length 500000 \
> >             server_flow_depth 0 \
> >             client_flow_depth 0 \
> >             post_depth 65495 \
> >             oversize_dir_length 500 \
> >             max_header_length 4096 \
> >             max_headers 100 \
> >             max_spaces 0 \
> >             small_chunk_length { 10 5 } \
> >             ports { 80 7000 8080 } \
> >             non_rfc_char { 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 } \
> >             enable_cookie \
> >             extended_response_inspection \
> >             inspect_gzip \
> >             normalize_utf \
> >             unlimited_decompress \
> >             normalize_javascript \
> >             apache_whitespace no \
> >             ascii no \
> >             bare_byte no \
> >             directory no \
> >             double_decode no \
> >             iis_backslash no \
> >             iis_delimiter no \
> >             iis_unicode no \
> >             multi_slash no \
> >             utf_8 no \
> >             u_encode yes \
> >             webroot no
> >
> >         alert ( msg: "HI_SERVER_INVALID_STATCODE"; sid: 2; gid: 120; rev:
> > 1; metadata: rule-type preproc ;  )
> >         alert ( msg: "HI_SERVER_NO_CONTLEN"; sid: 3; gid: 120; rev: 1;
> > metadata: rule-type preproc ;  )
> >
> >         output alert_fast: stdout
> >
> >
> > Running it:
> >         $ snort -v -l /var/log -c /etc/ips/snort.conf --daq-dir /lib/daq/
> > -r /tmp/120_2_1.cap 2>&1 | grep '120:'
> >         07/15-15:27:54.244754  [**] [120:2:1] (http_inspect) INVALID
> > STATUS CODE IN HTTP RESPONSE [**] [Priority: 0] {TCP} 192.168.173.1:80 ->
> > 192.168.173.153:54940
> >
> >         $ snort -v -l /var/log -c /etc/ips/snort.conf --daq-dir /lib/daq/
> > -r /tmp/120_3_1_A.cap 2>&1  | grep '120:'
> >         08/18-16:46:53.189936  [**] [120:3:1] (http_inspect) NO
> > CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE [**] [Priority: 0]
> > {TCP} 192.168.173.1:80 -> 192.168.173.153:43674
> >
> >         $ snort -v -l /var/log -c /etc/ips/snort.conf --daq-dir /lib/daq/
> > -r /tmp/120_3_1_B.cap 2>&1 | grep '120:'
> >         08/18-16:54:58.860230  [**] [120:3:1] (http_inspect) NO
> > CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE [**] [Priority: 0]
> > {TCP} 192.168.173.1:80 -> 192.168.173.153:43675
> >
> >
> > Capture files:
> >
> > 120_2_1.cap:
> >         This triggers the 'HI_SERVER_INVALID_STATCODE' alert.
> >         The dump consist out of 1 request and 1 response.
> >         'Special' about the response is that the HTTP body happens to
> > contain the string 'HTTP/2.0' and this happens to be at the start of a TCP
> > packet.
> >         [This false positive was detected due to a visit to the HTTP/2.0
> > draft, which contains the string 'HTTP/2.0' many times]
> >
> >         Analyzing it with gdb and breaking on hi_server.c line 1480 (right
> > before '/*If this is the next expected pac ...') shows:
> >         * packet 6: data starts with 'HTTP/1.1', expected_pkt is 0 =>
> > parsed as HTTP headers => OK
> >         * packet 7: data starts with 'HTTP/2.0', expected_pkt is 0 =>
> > parsed as HTTP headers => NOT OK, this is part of the body
> >
> > 120_3_1_A.cap:
> >         This triggers the 'HI_SERVER_NO_CONTLEN' alert.
> >         In the dump the HTTP Headers are split over two TCP packets.
> >         The first packets consist of 'HTTP/1.1 200 OK', the second packet
> > contains the remainder of the headers, the third packet contains the body
> >
> >         Analyzing it with gdb and breaking on hi_server.c line 1480 (right
> > before '/*If this is the next expected pac ...')
> >         * packet 8: data starts with 'HTTP/1.1', expected_pkt is 0 =>
> > parsed as HTTP headers => OK
> >         * packet 10: data starts with 'Content-Length...', expected_pkt is
> > 1 => parsed as HTTP body => NOT OK, this packet contains headers
> >         * packet 12: data starts with 'foo', expected_pkt is 1 => parsed
> > as HTTP body => OK
> >
> > 120_3_1_B.cap:
> >         This triggers the 'HI_SERVER_NO_CONTLEN' alert.
> >         In the dump the HTTP Headers are split over two TCP packets.
> >         The first packets consist of 'HTTP/1.1 200 OK' while the second
> > packet contains the remainder of the headers + the body
> >
> >         Analyzing it with gdb and breaking on hi_server.c line 1480 (right
> > before '/*If this is the next expected pac ...')
> >         * packet 8: data starts with 'HTTP/1.1', expected_pkt is 0 =>
> > parsed as HTTP headers => OK
> >         * packet 10: data starts with 'Content-Length...', expected_pkt is
> > 1 => parsed as HTTP body => NOT OK, this packet contains a part of the
> > headers and a part of the body
> >
> >
> >
> > Best regards,
> >
> > Bram



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel

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