Security #4710
closedtcp: Bypass of Payload Detection on TCP RST with options of MD5header
50e2b973eeec7172991bf8f544ab06fb782b97df
Description
Description
While configuring Suricata on inline mode, it is possible to bypass/evade any http based signature by faking a RST TCP packet with random TCP options of md5header from the client side.
After the three-way handshake packet, it's possible to inject a RST ACK with a random TCP md5header option. Then the client can send http GET request with forbidden URL.
The server will ignore the RST ACK and send the response http packet of the client's request.
These packets will not trigger Suricata reject action.
This strategy both work on 6.0.3 RELEASE and Github latest commit(7.0.0-dev a480ec2ba 2021-09-22)
Server:
apachectl -v
Server version: Apache/2.4.29 (Ubuntu)
Server built: 2021-06-18T11:06:22
Attached
You can find attached :
- test.rule : A http rule that detects the string "ultrasurf"
- without_evasion.pcap : A client which sends the string "ultrasurf" to a server without any evasion technique. It will trigger suricata test.rule REJECT action and receive RST.
- with_evasion.pcap : A client which sends the string "ultrasurf" to a linux apache server (kernel 5.4.0) with this evasion technique
- poc.py : A python script to play the evasion technique
Files
Updated by Victor Julien about 3 years ago
- Tracker changed from Bug to Security
- Private changed from No to Yes
- Severity set to MODERATE
- Label Needs backport to 5.0, Needs backport to 6.0 added
Updated by Chang Zedd about 3 years ago
Hi, perhaps I chose the wrong target version. This security issue is verified on both Suricata version 6.0.3 RELEASE and Github latest commit(7.0.0-dev a480ec2ba 2021-09-22). Is there anything I need to do? Thanks!
Updated by Jeff Lucovsky about 3 years ago
- Copied to Security #4726: tcp: Bypass of Payload Detection on TCP RST with options of MD5header added
Updated by Jeff Lucovsky about 3 years ago
- Copied to Security #4727: Bypass of Payload Detection on TCP RST with options of MD5header added
Updated by Victor Julien about 3 years ago
- Description updated (diff)
RFC explaining the option http://www.networksorcery.com/enp/rfc/rfc2385.txt
Updated by Victor Julien about 3 years ago
- Subject changed from Bypass of Payload Detection on TCP RST with options of MD5header to tcp: Bypass of Payload Detection on TCP RST with options of MD5header
It looks like that Suricata will not have all the needed info to correctly calculate the hash:
1. the TCP pseudo-header (in the order: source IP address,
destination IP address, zero-padded protocol number, and
segment length)
2. the TCP header, excluding options, and assuming a checksum of
zero
3. the TCP segment data (if any)
4. an independently-specified key or password, known to both TCPs
and presumably connection-specific
Point 4 here is the problem. We don't have a way to get this info from traffic as it is out of band. We also don't have a facility to feed this type of info to Suricata in real time currently.
I think the only way we can address this issue currently is by simply rejecting the RST if it has any md5header option.
Updated by Victor Julien about 3 years ago
- Status changed from New to Assigned
- Assignee set to Victor Julien
- Severity changed from MODERATE to HIGH
- Affected Versions git master added
Updated by Philippe Antoine about 3 years ago
- File tcpao.pcap tcpao.pcap added
tcpao is the same kind of evasion using option kind 29 from rfc5925
Another way to get such a pcap with option kind 29 is simply to edit the original pcap with your favorite hex editor and change from 0x13 to 0x1d the right byte
Updated by Philippe Antoine about 3 years ago
By the way, this does not work against my raspberry pi, even if it works locally...
That is my raspberry pi sends a RST after the GET request
Updated by Victor Julien almost 3 years ago
- Status changed from Assigned to Closed
- Git IDs updated (diff)