Project

General

Profile

Actions

Security #2770

closed

TCP FIN/ACK, RST/ACK in HTTP - detection bypass

Added by Alexey Vishnyakov about 5 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Label:
Git IDs:

d8634daf74c882356659addb65fb142b738a186b

Severity:
Disclosure Date:

Description

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


Files

poc.pcap (1.05 KB) poc.pcap Alexey Vishnyakov, 01/14/2019 11:51 AM
poc.py (1.67 KB) poc.py Alexey Vishnyakov, 01/14/2019 11:51 AM
original.pcap (268 KB) original.pcap Alexey Vishnyakov, 01/14/2019 11:57 AM

Related issues 1 (0 open1 closed)

Copied to Suricata - Bug #2825: TCP FIN/ACK, RST/ACK in HTTP - detection bypass (4.0.x)ClosedVictor JulienActions
Actions

Also available in: Atom PDF