Security #7657
closed
tcp: syn resend with different seq leads to detection bypasss
Added by Angelo Mirabella 6 months ago.
Updated 8 days ago.
Description
When performing SYN flooding, followed by an HTTP transaction, suricata is not able to detect the application layer protocol, leading to a false negative.
Tested in latest master with default configuration.
Attaching signature (test.rule) and 2 pcaps: syn_flood.pcapng and exploit.pcapng.
The first one contains the SYN flooding + HTTP transaction that should trigger the signature (but it does not trigger).
The second one contains only the HTTP transaction and correctly triggers the signature.
Files
- Subject changed from Suricata is not able to detect the app layer protocol when performing SYN flooding to tcp: syn resend with different seq leads to detection bypasss
- Status changed from New to Assigned
- Assignee changed from OISF Dev to Victor Julien
- Target version changed from TBD to 8.0.1
- Private changed from No to Yes
It looks like the generic session reuse logic doesn't handle syn resends, as it is supposed to be handled by the regular logic at the syn_sent state. However, the logic there to handle resends seems to ignore the sequence number (isn), so it's not leading to a correct matching up of the last syn (pkt 24) and the syn/ack that matches it.
I do have a scapy reproducer now, does use TCP DNS, but same issue.
- Affected Versions 8.0.0 added
- Affected Versions deleted (
git main)
- Tracker changed from Bug to Security
- Severity set to MODERATE
- Label Needs backport to 7.0 added
- Label deleted (
Needs backport to 7.0)
- Status changed from Assigned to In Review
- Severity changed from MODERATE to HIGH
- Status changed from In Review to Resolved
- Status changed from Resolved to Closed
- Private changed from Yes to No
Also available in: Atom
PDF