[Oisf-users] shellshock conundrum
Russell Fulton
r.fulton at auckland.ac.nz
Mon Sep 29 03:14:32 UTC 2014
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.
More information about the Oisf-users
mailing list