[Oisf-users] shellshock conundrum
Victor Julien
lists at inliniac.net
Mon Sep 29 12:01:23 UTC 2014
On 09/29/2014 05:14 AM, Russell Fulton wrote:
> Hi
>
> I am currently running two IDS systems in parallel:
>
> i/ suircata running on Dell 16 cores with 48GB memory — 10Gb NIC
> ii/ very old version of snort on a 12 core Dell with 16GB - 1Gb NIC.
>
> The suri system is connected to a CPacket device which is delivering about 2 Gbps of traffic — the older box is fed directly off a mirrored router port and must therefore be dropping a fair portion of the traffic.
>
> looking at the results of the detects (as they got in to the database) for
>
> Suricata base sensor:
>
> Time Window for this screen: Sat Sep 27 10:25:34 2014 to Mon Sep 29 14:54:50 2014
>
> Src Sig name Total Events Proto
> 104.131.115.120 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 5 6
> 144.76.75.73 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 2 6
> 149.255.97.119 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 2 6
> 183.16.111.67 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 1 6
> 184.173.253.58 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 2 6
> 192.99.247.174 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 2 6
> 193.107.16.123 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 2 6
> 194.150.168.95 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 1 6
> 5.45.64.30 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 2 6
> 54.251.83.67 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 68 6
> 70.42.149.69 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 761 6
> 75.127.84.182 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 78 6
> 82.221.105.197 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 33 6
> 83.166.234.133 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 8 6
> 85.25.242.250 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 3 6
>
> old snort based sensor:
>
> Time Window for this screen: Fri Sep 26 16:41:53 2014 to Mon Sep 29 12:54:12 2014
>
> Src Sig name Total Events Proto
> 104.131.115.120 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 10 6
> 104.192.103.6 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 19 6
> 149.255.97.119 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 1 6
> 170.75.162.132 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 6 6
> 173.45.100.18 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 34 6
> 176.31.248.153 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 17 6
> 177.11.17.183 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 1 6
> 183.16.111.67 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 2 6
> 184.173.253.58 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 4 6
> 185.56.8.31 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 3 6
> 193.107.16.123 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 2 6
> 194.150.168.95 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 3 6
> 195.154.226.66 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 1 6
> 195.3.144.110 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 2 6
> 198.58.106.99 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 4 6
> 201.174.78.62 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 1 6
> 212.68.34.237 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 3 6
> 218.12.43.170 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 12 6
> 23.92.16.160 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 3 6
> 46.246.34.82 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 1 6
> 5.45.64.30 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 19 6
> 54.251.83.67 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 427 6
> 61.160.224.130 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 1074 6 <<<<<<<<<
> 69.38.149.214 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 1 6
> 70.42.149.69 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 842 6
> 75.127.84.182 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 534 6
> 80.249.81.130 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 5 6
> 82.221.105.197 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 319 6
> 83.166.234.133 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 10 6
> 85.25.242.250 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 32 6
> 91.201.53.25 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 1 6
> 94.102.60.177 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 5 6
> 94.23.193.131 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 1 6
> 97.114.83.155 ET WEB_SERVER Possible CVE-2014-6271 Attempt in Headers 2 6
>
> Snort picked up a *lot* more hits than suri in spite of not seeing half the packets. I have verified that the packets are getting to the sensor that suri is running on. One thing I note is that the suri version of the rules relies on http parsing! “content:"|28 29 20 7b 20|"; http_header; “.
>
> I know the traffic is hitting the sensor because I am running streamdb (full packet capture like timemachine) on the same box. When I dumped out the streams for the most obvious differnce (marked by <<<<<<<) what I got was “http parsing error” on the inbound stream and the content of the response.
>
> I did a little hacking and got streamdb to dump the offending buffer:
>
> rful011 at secmonprd01:~$ perl -I streamdb-svn/web/ streamdb-svn/web/sdb --srcip 61.160.224.130 --start "2014-09-26" --dstip 130.216.190.19 --dstport 80 --limit 10
> * WARN [2014/09/29 15:43:55] streamdb-svn/web//StreamClient.pm (732) StreamClient::_parse_http 43787 Parse error: status: -2 state: header data left: 100
> * WARN [2014/09/29 15:43:55] streamdb-svn/web//StreamClient.pm (736) StreamClient::_parse_http 43787 objects:
> GET / HTTP/1.1
> Host: 130.216.190.19
> Cookie: a:language=cn
> T: () { :;}; echo SCAN: 360adlab-scan
> * WARN [2014/09/29 15:43:55] streamdb-svn/web//StreamClient.pm (732) StreamClient::_parse_http 43787 Parse error: status: -2 state: header data left: 77
> * WARN [2014/09/29 15:43:55] streamdb-svn/web//StreamClient.pm (736) StreamClient::_parse_http 43787 objects:
> GET / HTTP/1.0
> Host: 130.216.190.19
> T: () { :;}; echo SCAN: 360adlab-scan
>
> 2014-09-26 18:13:10 61.160.224.130:56845 <- 130.216.190.19:80 3s 149 bytes RST 400 ASCII text, with no line terminators
> oid=1643-2685654208-149-0
>
> 400 Bad Request
> Connection: close
> Date: Fri, 26 Sep 2014 06:13:12 GMT
> Content-Length: 20
> Content-Type: text/html
> X-HTTP-Version: 1.1
>
> <h1>Bad Request</h1>
>
> 2014-09-27 00:21:03 61.160.224.130:60768 <- 130.216.190.19:80 3s 149 bytes RST 400 ASCII text, with no line terminators
> oid=1646-3427582969-149-0
>
> 400 Bad Request
> Connection: close
> Date: Fri, 26 Sep 2014 12:21:04 GMT
> Content-Length: 20
> Content-Type: text/html
> X-HTTP-Version: 1.1
>
> <h1>Bad Request</h1>
>
> +_+_+_+_+_+_+_+_+_+_+_++_+_+_+_++__+++_+_+_+
>
> Could it is the invalid header “T:” which caused suricata, streamdb and the webserver all to reject this request.
>
> Fine for the webserver to reject it out of hand but I wonder if this sort of thing should stop suricata alerting on what is clearly malicious traffic.
>
> There were a bunch of sites scanning with various invalid headers and like this scanner splitting the request over two packets.
>
> In other case both sensors alerted for a scanner but snort logged many more alerts than suri — 75.127.84.182 hrtoolbox.com being the most obvious example.
>
> BTW I have notice differences nothing quite this bad.
>
> Any ideas about where to start looking for problems.
Can you (privately) share a pcap?
It may be related to this issue here:
https://redmine.openinfosecfoundation.org/issues/1275
--
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------
More information about the Oisf-users
mailing list