Bug #2655

Updated by Victor Julien over 4 years ago

Hello, Team! 
 We've run into troubles with a few threats variants. 
 Let's imagine some sort of malware which tries to steal a user information. 
 There are several methods, but one of them is simply send a data via POST request: 

 POST _POST /... HTTP/1.1 
 Host: ... 
 Content-Type: application/x-www-form-urlencoded 
 Content-Length: 22 

 </pre> login=foo&password=*bar*_ 

 Below is a simple rule example: 
 alert _alert http any any -> any any ( \ 
 msg:"TEST 'no Content-Length' vs http_client_body"; \ 
 flow:to_server,established; \ 
 content:"login=foo&password=bar"; http_client_body; \ 
 classtype:trojan-activity; \ 
 sid:1; rev:1;) 
 </pre> rev:1;)_ 

 Let's imagine that a threat actor will manualy remove the 'Content-Length' option from HTTP header: 

 POST _POST /... HTTP/1.1 
 Host: ... 


 In this case according to HTTP specification a request will be wrong. 
 But from a network transport side it's not a problem and a packet will be successfully transferred. 

 The same can be done with GET method although this technique is not recommended. 

 I've attached two pcap dumps as example. 
 I've also played a bit with 'Content-Type' and 'Content-Length' options in each session. 
 As a result, Suricata doesn't detect the body content with 'http_client_body' modifier in cases when 'Content-Length' is absent. 
 We'll have the same result if just change the 'Content-Length' value to a smaller one: Content-Length: 22 -> Content-Length: 20 

 A default HTTP server will return an error because it will not resolve a 'login=foo&password=bar' combination as HTTP method of a new request. 
 But it's up to us how we'll configure our HTTP server. 

 I believe that removing or reducing the 'Content-Length' field value is a quite easy trick to bypass Suricata detection with http_client_body modifier for a pattern. 
 I suggest to improve a body length recognizing logic and not to be based on 'Content-Length' value only. 

 Thank you. 
 Sincerely yours, Alexey Vishnyakov