Suricata

Hello, team!

During an investigation of this PCAP dump:
hxxps://www.joesandbox.com/analysis/95831/1/pcap (also attached as original.pcap)
an interesting problem has been found

Please, look at the Scapy script: poc.py
It's logic is:
- make a tcp 3whs with a server
- send a simple GET request to the server
- send a FIN/ACK packet just after previous query before a reply from the server will be received
- send a RST/ACK packet after the server replies to the GET request

You need to simulate a slow network connection, overload the HTTP server or use something more powerful than Python for the next important condition: FIN/ACK packet should be sent BEFORE a GET-response from the server will be received

After that let's test following rules on attached pcap dump poc.pcap:

alert tcp any any -> any any ( \
msg:"Test, tcp"; \
content:"GET"; \
pcre:"/index\.html/"; \
classtype:trojan-activity; \
sid:1; rev:1;)

alert http any any -> any any ( \
msg:"Test, http, no modifiers, no options"; \
content:"GET"; \
pcre:"/index\.html/"; \
classtype:trojan-activity; \
sid:2; rev:1;)

alert http any any -> any any ( \
msg:"Test, http, content modifier, no options"; \
content:"GET"; http_method; \
pcre:"/index\.html/"; \
classtype:trojan-activity; \
sid:3; rev:1;)

alert http any any -> any any ( \
msg:"Test, http, content modifier, pcre option"; \
content:"GET"; http_method; \
pcre:"/index\.html/U"; \
classtype:trojan-activity; \
sid:4; rev:1;)

We've used 4.0.3 and 4.1.2 Suricata versions. Here are results:

sid,4.0.3,4.1.2
sid:1,noalert,noalert
sid:2,noalert,noalert
sid:3,noalert,alert
sid:4,alert,alert

It's not strange that both versions detect a pcap with the most described rule (sid:4)
But both versions don't detect 'tcp' and 'http' rules without special modifiers or options
A situation with 'sid:3' is funny :-)

It's typical situation when you need to use 'content/pcre' in HTTP protocol without modifiers/options
If you'll make a HTTP query as described above - detection will be bypassed in some cases
Despite the fact that FIN/ACK and RST/ACK packets are wrong - the initial HTTP request will be successfully processed by a server

Could you confirm that?

Thank you
Sincerely yours, Alexey Vishnyakov