tcp: Bypass of Payload Detection on TCP RST with options of MD5header
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 version: Apache/2.4.29 (Ubuntu)
Server built: 2021-06-18T11:06:22
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
Updated by Victor Julien over 1 year 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 Philippe Antoine over 1 year ago
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