Project

General

Profile

Actions

Security #4710

closed

tcp: Bypass of Payload Detection on TCP RST with options of MD5header

Added by Chang Zedd over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Label:
Needs backport to 5.0, Needs backport to 6.0
Git IDs:

50e2b973eeec7172991bf8f544ab06fb782b97df

Severity:
HIGH
Disclosure Date:

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

poc.py (1.65 KB) poc.py A python script to play the evasion technique Chang Zedd, 09/26/2021 02:56 AM
test.rule (101 Bytes) test.rule A http rule that detects the string "ultrasurf" Chang Zedd, 09/26/2021 02:56 AM
with_evasion.pcapng (2.15 KB) with_evasion.pcapng A client which sends the string "ultrasurf" to a linux apache server (kernel 5.4.0) with this evasion technique Chang Zedd, 09/26/2021 02:56 AM
without_evasion.pcapng (984 Bytes) without_evasion.pcapng A client which sends the string "ultrasurf" to a server without any evasion technique. Chang Zedd, 09/26/2021 02:56 AM
tcpao.pcap (2.47 KB) tcpao.pcap Philippe Antoine, 10/08/2021 10:06 AM

Related issues 2 (0 open2 closed)

Copied to Suricata - Security #4726: tcp: Bypass of Payload Detection on TCP RST with options of MD5headerClosedShivani BhardwajActions
Copied to Suricata - Security #4727: Bypass of Payload Detection on TCP RST with options of MD5headerClosedJeff LucovskyActions
Actions #1

Updated by Victor Julien over 2 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
Actions #2

Updated by Chang Zedd over 2 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!

Actions #3

Updated by Jeff Lucovsky over 2 years ago

  • Copied to Security #4726: tcp: Bypass of Payload Detection on TCP RST with options of MD5header added
Actions #4

Updated by Jeff Lucovsky over 2 years ago

  • Copied to Security #4727: Bypass of Payload Detection on TCP RST with options of MD5header added
Actions #5

Updated by Victor Julien over 2 years ago

  • Description updated (diff)
Actions #6

Updated by Victor Julien over 2 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.

Actions #7

Updated by Victor Julien over 2 years ago

  • Status changed from New to Assigned
  • Assignee set to Victor Julien
  • Severity changed from MODERATE to HIGH
  • Affected Versions git master added
Actions #8

Updated by Philippe Antoine over 2 years 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

Actions #9

Updated by Philippe Antoine over 2 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

Actions #10

Updated by Victor Julien over 2 years ago

  • Status changed from Assigned to Closed
  • Git IDs updated (diff)
Actions #11

Updated by Victor Julien over 2 years ago

  • Private changed from Yes to No
Actions #12

Updated by Chang Zedd over 2 years ago

CVE-2021-45098

Actions #13

Updated by Victor Julien over 2 years ago

  • CVE set to 2021-45098
Actions

Also available in: Atom PDF