Full Report
James Kettle published research on exploiting race conditions more relably by putting things in the same packet. However, the author of this post ran into a limitation of this - the allowed for size of TCP and other size limits. They looked on how to bypass this limitation. The single packet packet has a 1500 byte limit, each means that only 20-30 requests can be made at a time. This limitation is because of the Ethernet's maximum frame size of 1518 bytes. What's weird though, is that TCP supports 65535, but how? IP fragmentation can be used to divide the original packet into different Ethernet frames but be processed together since the packet won't be processed until all data has been received. Even with this, the packet size is limited. How else can we expand this? TCP is ordered with a sequence number. By reversing the order of packets to account for this, all packets will be processed at the same time - genius! Using this, we can make packets be infinite in size without worrying about timing issues. HTTP/2 puts a wrench into this, sadly. There is a maximum amount of concurrent streams open in most settings that is under 250 for Apache, Nginx and Go but unlimited for NodeJs and some others. How do we configure this stuff to happen? First, they configured their IP tables to not send RST packets. Then, they just wrote their own client to change the ordering of TCP. Using this, it's possible to exploit limit overrun rate limiting issues as well. The tool is a little rough right now. It doesn't support HTTPs over HTTP, TCP window updating or any proxy tools. Overall, an awesome post to hype up the possibility of race conditions and other issues.
Analysis Summary
# Tool/Technique: First Sequence Sync (Enhanced Single-Packet Attack)
## Overview
First Sequence Sync is an advanced exploitation technique designed to perform large-scale race conditions by bypassing the physical and conceptual size limits of traditional "single-packet" attacks. While original single-packet attacks are limited by the Ethernet MTU (approx. 1,500 bytes), this technique leverages IP fragmentation and TCP sequence number reordering to synchronize thousands of HTTP requests (e.g., 10,000+) to be processed by a server at the exact same moment.
## Technical Details
- **Type:** Technique / Network Exploitation Tool
- **Platform:** OS-independent (Requires low-level network stack control, typically Linux for `iptables` manipulation)
- **Capabilities:** Bypasses MTU limits, exceeds the 65,535-byte TCP packet limit, and synchronizes high-volume requests to bypass rate limits or exploit "limit-overrun" vulnerabilities.
- **First Seen:** August 2, 2024 (Published by Flatt Security)
## MITRE ATT&CK Mapping
- **[TA0006 - Credential Access]**
- **[T1110.001 - Brute Force: Password Guessing]** (Specifically bypassing rate limits for PINs/Tokens)
- **[TA0040 - Impact]**
- **[T1499.002 - Endpoint DoS: Service Exhaustion]** (Simultaneous processing of massive requests)
- **[TA0001 - Exploitation]**
- **[T1212 - Exploitation for Privilege Escalation]** (Race conditions in logic/auth)
## Functionality
### Core Capabilities
- **IP Fragmentation:** Splits a large logical TCP packet into multiple IP fragments. The target OS kernel buffers these and does not pass them to the application layer until the entire packet is reassembled.
- **TCP Sequence Reordering:** Sends the "first" sequence of a data stream last. Since TCP ensures ordered delivery, the server's TCP stack holds all subsequent data in a buffer until the missing "first" piece arrives, triggering the simultaneous release of all requests to the application.
- **MTU Bypass:** Overcomes the 1,500-byte limitation that previously restricted race conditions to only 20-30 requests per synchronization attempt.
### Advanced Features
- **RST Packet Suppression:** Uses `iptables` to prevent the host OS from sending Reset (RST) packets when the custom tool engages in raw socket manipulation.
- **HTTP/2 Stream Multiplexing:** Utilizes HTTP/2 concurrent streams to pack thousands of requests into a single buffered TCP session (effective against Node.js and systems with high `SETTINGS_MAX_CONCURRENT_STREAMS`).
## Indicators of Compromise
- **File Names:** Custom exploitation scripts (e.g., `race-client`).
- **Network Indicators:**
- High volume of IP fragments arriving for a single TCP session.
- Out-of-order TCP segments where the initial sequence number is missing until the very end of the burst.
- Extremely high density of HTTP requests (e.g., 10,000+ requests) arriving within a millisecond timeframe (approx. 166ms duration).
- **Behavioral Indicators:** `iptables` rules configured to drop outbound RST packets to specific targets.
## Associated Threat Actors
- Research-driven (RyotaK of GMO Flatt Security). No known APT attribution yet, but highly applicable for actors targeting MFA/OTP bypasses.
## Detection Methods
- **Behavioral Detection:** Monitoring for high rates of TCP reassembly timeouts or an unusual amount of buffered out-of-order segments.
- **Network Inspection:** Identifying HTTP/2 connections with unusually high concurrent stream counts or headers that exceed typical "Last-Byte Sync" patterns.
- **Log Analysis:** Detecting a massive spike of requests (e.g., 5,000+ per second) arriving from a single source IP with identical timestamps.
## Mitigation Strategies
- **Server Configuration:**
- Lower the `SETTINGS_MAX_CONCURRENT_STREAMS` in Nginx, Apache, or Go (default 100-250 is generally safe).
- Limit the maximum size of the TCP receive buffer.
- **Rate Limiting:** Implement rate limiting at the application layer that persists across sessions and is updated atomically.
- **Network Layer:** Use WAFs or Load Balancers that normalize TCP traffic and reassemble fragments before passing them to the backend.
## Related Tools/Techniques
- **Single-Packet Attack:** The original technique by James Kettle (PortSwigger).
- **HTTP/2 Last-Byte Sync:** The predecessor technique focused on synchronizing the final byte of a request.
- **IP Fragmentation Attacks:** Historically used for IDS bypass; here repurposed for synchronization.