[Introduction]
The emergence of large-scale network attack and defense competitions in recent years proceeds in a practical manner, which is a commendable approach. It promotes defense through attack (as the saying goes: âtalk is cheap, show me the shellâ). Participating large enterprises are more concerned with actual security threats and find ways to mitigate them. This has objectively prospered the security industry. For a time, related security services and products were in high demand, especially IDS/IPS with real-time detection and blocking capabilities.
Thus, large enterprises are purchasing and deploying security protection products like IDS, IPS, and WAF, which compress the attack surface. This brings about two issues: 1) Is there still an opportunity in the direction of penetration testing? Some penetration testers have expressed perplexity about the future in a popular Zhihu post [1]; 2) Should security vulnerabilities in systems behind protected devices still be addressed after deploying IDS/IPS equipment? Donât rush to answer, letâs look further into the text.
[Principles of IDS/IPS Protection and Bypass Strategies]
IDS operates at the network layer, deployed in a non-inline mode, detecting attacks by capturing and analyzing network traffic. IPS usually operates similarly at the network layer with blocking capabilities as an upgraded version of IDS. It can cover both the network and application layers. A WAF safeguards against web attacks at the application layer, generally interfacing with the web access layer, capable of both inline and non-inline deployment but only covers the application layer. For detailed technical principles and practices, refer to this TSRC blog article [2]. For convenience in this article, network layer non-inline protection devices are uniformly considered as IPS.
Security experts have extensively discussed methods to bypass WAF at the application layer [3]. The TSRC blog will also release an article on WAF bypass shortly, so to avoid repetition, weâll dive into network layer strategies.
Upon inspection, the bypass principle for IPS is quite simple. Its classic representative, like the open-source Snort, analyzes traffic on the network, masquerading as the server to respond to the client when detecting traffic that meets certain rules to achieve blocking or replacement, which is a typical form of link hijacking. Common scenarios include blocking websites (like illegal sites), altering webpage content (such as ISPs inserting ads), blocking port scans, and vulnerability attacks. The implementer of link hijacking must control a section of the network.
Using an image from the old work, âAnalysis and Thoughts on Traffic Hijacking in an E-commerce Websiteâ [4], it illustrates how an attacker forges a response after sniffing traffic with specific characteristics. In this instance, an HTTP response was forged (for page alteration). If just blocking, it would involve forging an RST packet to disrupt the TCP handshake or connection.
Why is IPS mostly non-inline rather than inline? Serial processing of extremely high traffic poses a huge challenge to device performance. You can try it; I believe you will agree with my opinion.
Since IPS is deployed non-inline, it can only interfere with normal communication by sending forged packets. The actual packets will still reach the client and server. However, once processed by the operating system, identical sequence number packets are deemed erroneous and discarded.
Therefore, bypassing IPS can be approached from two directions: 1) In detection, if IPS cannot detect attack signatures within traffic, it will take no further action; 2) In blocking, normal packets can still reach the server, just delayed. If there is a way to invalidate the forged packets, blocking will not occur.
[Instances of IPS Bypass]
Common IPS blocking scenarios exist in four types:
1) Ability to establish a TCP connection, inspecting client HTTP request features, issuing RST for blocking or HTTP response replacement upon match, used for domain name blocking or web attack protection;
2) Preventing TCP connection establishment, where IPS returns RST as the client sends a SYN packet. Subsequent ACK packets, if any, will be met with bidirectional RST blocking for access control or port blocking;
3) DNS query scenarios, forging DNS responses, hijacking domain names for blocking or phishing attacks;
4) In UDP transmission scenarios, forging ICMP responses indicating the UDP port is unreachable.
For scenario 1, two approaches are viable: At the application layer, typically exploiting differences in IPS and web serverâs understanding of HTTP syntax; at the network layer, exploiting differences in IPS and OS protocol stackâs handling of TCP/IP â discussed further down. For scenario 2, the exploit surface is narrower, making bypass somewhat challenging but not impossible. Scenario 3 can be addressed by changing the DNS server. The industry has effective solutions against DNS hijacking, not elaborated here. Scenario 4 is analyzed further down.
Below are some commonly used network layer bypass techniques, all tested:
[ TCP Fragmentation ]
Some IPS perform byte-level packet inspection and lack TCP fragmentation reassembly capabilities, allowing for covert delivery by splitting keywords into two TCP packets. Below is a Perl implementation of TCP fragmented HTTP request with the keyword âwww.bad.comâ split across two TCP packets.
As shown in the image, bypassing via TCP fragmentation returns a 200 (if TCP fragmentation isnât performed, it returns 302).
Slow down! What if the IPS can reassemble TCP fragments? Good question. Look closely at the code, thereâs a sleep in there for a reason: some IPS can reassemble TCP fragments but wonât wait endlessly â thereâs a timeout. Set the sleep duration longer than the IPS fragmentation reassembly timeout but shorter than the OS and web server timeout, thus achieving bypass.
[ IP Fragmentation ]
Similar to TCP, IP packets support fragmentation, requiring the use of Pythonâs Scapy component to construct IP packets. After TCPâs three-way handshake, using Scapyâs fragment function to split the IP fragment packets into 600-byte segments (including the SYN packet), the code is as follows:
See the effect:
The principle of bypassing IP reassembly timeout is like TCP, needing no further elaboration. Note that TCP fragmentation is more universal, but IP fragmentation might be subjected to reassembly or discard mid-transit by network devices, affecting outcomes.
Notoriously, the scanner Nmap features an FW/IDS evasion capability via IP fragmentation for port scanning, parameterized as -f. The âmtu option can set fragment size, with the smallest value being 8. However, testing shows some routes drop IP packets with small MTU sizes.
[ Program Bugs / Performance Issues ]
Programs always have bugs, particularly in traffic processing applications, where numerous packets are processed simultaneously under various conditions. Small oversights can cause anomalies. To ensure business continuity, protection devices aim to maintain it in the event of anomalies. Generating anomalous packets that the IPS cannot respond to quickly can facilitate bypass. Previously, our Zeus Shield DDoS protection system faced unintentional core dumps due to minor considerations during traffic processing, which were troublesome.
When testing an IPS, after establishing a TCP connection, sending a large number of erroneous sequence ACK packets then sending correct packets, the IPS bug manifested by responding with RSTs that had incorrect sequence numbers, resulting in bypass.
You can also transmit a large volume of invalid packets, depleting the IPS performance. Once it slows down, legitimate packets arriving later offer bypass opportunities.
Such anomalies can be discovered via protocol fuzzing [5]. Scapy is a good protocol fuzz generation tool, worthwhile to try.
Additionally, many network devices on the link handle TCP/IP protocols differently, potentially causing bypass or other issues. For instance, current operating systems specify sequence accuracy for RST packets down to precision, while some NAT devices still overlook sequence, maintaining ârstbloodâ issues.
[ Forging TCP State ]
While testing an IPS, discovering it was a seasoned system, all previous bypass strategies failed, even layering various setups at the application level without success. Notably, it wasnât implementing packet filtering but state tracking â indicating further testing to determine detection mode. It didnât establish TCP connections directly sent HTTP requests, if any response from IPS suggested packet filtering, but otherwise state tracking.
Ironically, its flaw was in state tracking itself: upon establishing a TCP connection, sending a crafted TTL RST packet could pass through the IPS without reaching the server. The IPS would assume the TCP connection ended based on state, ceasing packet inspection, while the server continues awaiting ACK packets.
It turns out, in the current environment, setting TTL to about 12 allows RST to pass the IPS without reaching the server, hence our critical code is written as follows:
Perfect bypass:
This TTL construction bypass issue (which I call âfake-TTLâ attack) may be a common problem among network devices employing state tracking.
[ Bypassing Handshake Flaws ]
Letâs delve into scenarios blocking the three-way handshake.
When a client sends a SYN packet, the IPS pretends to be the server returning an RST, feigning a closed port. However, if the port is indeed open, the serverâs SYN-ACK packet still reaches the client. Since the identical sequence RST precedes, the SYN-ACK arriving later gets discarded by the OS. Simple solution: the client ignores the forged RST packet, accepts SYN-ACK, and sends an ACK to establish the three-way handshake. At this point, IPS will return RST in both directions (if your IPS does not act, consider switching brandsâŠ). Note that your ACK must arrive at the server before the IPSâs RST and be executed by the application â in one blind shot, suitable for specific scenarios of vulnerability probing and exploitation.
If seeking perfect bypass, find methods to nullify the second RST; for perfect defense, ensure the first RST is effective. Delve into TCP/IP for condition-specific analyses or attempt to fuzz.
[ IPv6 ]
With the increasing adoption of IPv6, more devices support it (transition period with IPv4/6 dual stack). However, existing IDS/IPS/WAF might not support it, permitting unhindered passage.
Browsers support direct IPv6 access: https://[IPv6-address]/xxxx
Current Windows systems support IPv6 by default, but firewall rules may remain IPv4-only, allowing IPv6 addresses to traverse freely. As demonstrated, a firewall restricts all IPv4 ports, yet allows access via IPv6, with remote desktop login visible as follows:
Take this as a reminder: Check if all security systems have enabled IPv6 support.
[ Encrypted Protocols ]
IPS generally cannot decrypt SSL traffic and thus doesnât inspect it, making HTTPS a potential bypass method. In this scenario, the application-layer WAF exhibits its advantages. Similarly, HTTP/2, QUIC, WebSocket, and other new web protocols can evade IPS.
Since these protocols can bypass IPS, leveraging them on the server-side provides defense against link hijacking, both ensuring the communication isnât tampered with and protecting user information from network interception [5]. The best practice is deploying HTTPS to prevent link hijacking. Although hijacking HTTPS isnât impossible, the difficulty increases significantly. The high-profile GitHub hijacking incident attracted industry attention due to incorrect SSL certificates revealing the hijackingâs occurrence [6].
[ Blocking UDP ]
UDP communication is connectionless, making blocking more challenging.
IPS employs ICMP packets indicating port unreachable to block UDP. However, effectiveness is limited: depending on client recognition of such packets varies by application code [8]; and these ICMPs might not survive through various routers and firewalls along the path.
[Solution]
Understanding the specific techniques allows easy derivation of optimization strategies, which readers can summarize themselvesâthis is how âattack promotes defense.â Of course, having issues isnât fearful; ignorance or refusal to acknowledge them is.
[Epilogue]
I believe the questions mentioned in the introduction have been answered through the preceding discussion. Based on the depth of defense principles, security vulnerabilities should be promptly addressed regardless of protective equipment presence.
Rest assured, this article isnât aimed at highlighting many IPS problems, but to demonstrate that security is a dynamic process. Defense isnât perpetually effective, requiring ongoing operations and optimizations. Itâs vital to monitor the effectiveness of security protection systems themselves. In red-blue team exercises, focus not only on penetration targets but the entire security defense system. Thanks to the ball head of Zeus Shield and Niu Chang for joint testing of this codenamed â007â project, further traffic analysis will be followed up by him.
Lastly, as usual, weâre hiring across foundational security domains, particularly in flow security analysis. Interested candidates can submit resumes. No contact details provided, but you can surely locate me.
[Appendix]
[1] Is penetration testing still promising as websites become harder to infiltrate?
[2] WAF Construction, Operation, and AI Application Practices
[3] Comprehensive Soft WAF Bypass Strategies
[4] Analysis and Thoughts on Traffic Hijacking in an E-commerce Website
[5] Fuzzing Vulnerability Exploration
[6] Is âTraffic Hijackingâ Really Stealing Your Information?!
[7] GitHub Allegedly Suffered Man-in-the-Middle Hijacking, Users Report Access with Certificate Errors