In early 2022, security researchers uncovered a serious vulnerability affecting Juniper Networks’ Junos OS running on SRX Series Gateways. Tracked as CVE-2022-22157, this bug allows attackers to bypass Juniper's Deep Packet Inspection (JDPI) rules and potentially access unauthorized networks or resources. The underlying issue relates closely to how the firewall processes TCP flows when the 'no-syn-check' feature is enabled.

In this exclusive long read, we’ll break down what went wrong, who is at risk, how exploitation works, and what you can do to protect your network.

What Is CVE-2022-22157?

Juniper firewalls (SRX Series) are popular for enterprise-grade protection, and their JDPI engine is designed to inspect traffic at a fine-grained, application-aware level. But if administrators configure the firewall with set security flow tcp-session no-syn-check, a bug in JDPI’s flow classification lets attackers slip through the cracks.

The Vulnerability

- Root Cause: When JDPI sees out-of-state asymmetric TCP flows (essentially, packets that don't follow the normal SYN, SYN-ACK, ACK handshake), it should deny them or mark them as UNKNOWN. Instead, if 'no-syn-check' is enabled, JDPI marks them as INCONCLUSIVE.  
- Why is INCONCLUSIVE a problem? The INCONCLUSIVE state is more permissive than UNKNOWN, meaning traffic is more likely to be allowed through the firewall—even if it would normally be blocked.

Affected Devices and Software Versions

This bug specifically affects Juniper Networks Junos OS on SRX Series devices, and only when the no-syn-check flag is enabled.

Not affected: Releases prior to 18.4R1

> For the full list and specifics, see the Juniper Security Advisory.

Firewall Flow and JDPI Classification

When traffic comes into a Juniper firewall, the JDPI engine tries to identify which application or protocol is in use. If it doesn't recognize the flow, it classifies it as UNKNOWN, and most policies block this traffic. However, due to the bug, out-of-state TCP packets are instead tagged as INCONCLUSIVE, which often slips through policy checks designed for UNKNOWN.

Malicious Client Sends Asymmetric TCP Packet:

- Sends packets that are NOT part of a valid three-way handshake (e.g., sending ACK, PSH, or data packets without a SYN)

Sample Firewall Policy Logic (Pseudocode)

if flow.state == "UNKNOWN":
    deny()
elif flow.state == "INCONCLUSIVE":
    allow()  # Vulnerable path
else:
    process_normally()

> Note: Real JDPI policy is more complex, but this illustrates the logic flaw.

Proof of Concept: Exploiting the Vulnerability

DISCLAIMER: Only test this in a controlled lab environment with devices you own!

no-syn-check;

}

Send ACK packet to trigger out-of-state flow

pkt = IP(dst="SRX_PUBLIC_IP")/TCP(dport=80, flags="A")

To send an ACK-only packet using netcat and hping3

hping3 -c 1 -A -p 80 SRX_PUBLIC_IP


If the backend service responds or logs a hit, the vulnerability is present.

Evade standard intrusion detection

Mitigation is critical, especially if your organization has enabled no-syn-check for interoperability purposes, asymmetric routing, or legacy systems.

References

- Juniper Security Advisory JSA69848
- National Vulnerability Database Entry CVE-2022-22157
- Juniper SRX Documentation

Conclusion

CVE-2022-22157 is a good reminder that even enterprise firewalls aren’t immune to subtle implementation bugs. If your SRX devices use no-syn-check, your firewall could allow dangerous traffic that should be blocked. Check your configs, update your software, and keep your networks safe!

For regular updates on security best practices, follow us and stay ahead of the next threat.

Timeline

Published on: 01/19/2022 01:15:00 UTC
Last modified on: 01/28/2022 20:00:00 UTC