Mohamed Elbadry | Blog
  • About Me
    • Acknowledgement
  • Dangling DNS
    • Amazon Web Services
      • Dangling DNS: Amazon EC2
      • Dangling DNS: Amazon EC2 IPs (Current State)
    • Vulnerable Services
      • Dangling DNS: Worksites.net
      • Dangling DNS: Announcekit
  • Write-ups
    • Fuzzing
      • Automate Cache Poisoning Vulnerability - Nuclei
      • How I built the PoC for the Log4j zero-day security vulnerability
Powered by GitBook
On this page
  • Intro
  • Approach
  • Unkeyed Inputs
  • Creating Template
  • Testing Template
  • Scanning
  • Success Case
  • Vulnerability Report
  • Payload
  • Impact

Was this helpful?

  1. Write-ups
  2. Fuzzing

Automate Cache Poisoning Vulnerability - Nuclei

Inspired by James Kettle's research on Web Cache Poisoning in 2018

PreviousFuzzingNextHow I built the PoC for the Log4j zero-day security vulnerability

Last updated 2 years ago

Was this helpful?

Intro

I started my regular night, as usual, checking my inbox, Twitter, and HackerOne, soon after I received a message on discord from my friend , who asked if we could create a template for to detect web cache poisoning, so we started to check if it's even possible, turned out It's a perfect idea. If cache poisoning is a new term for you, I suggest this by James Kettle.

Approach

We started to tear down the detection process into small pieces. Khaled came out with common unkeyed inputs headers which were extracted from previously disclosed reports and write-ups.

Unkeyed Inputs

X-Forwarded-Prefix: cache.melbadry9.com
X-Forwarded-Host: cache.melbadry9.com
X-Forwarded-For: cache.melbadry9.com

It's known that triggering cache poisoning requires two requests, one of which will cause the server to cache our poisoned response, and the second request will retrieve our poisoned response. Based on this behavior, we built our template.

Creating Template

Putting it all together, we came out with the following Nuclei-Template.

id: cache-poisoning    

info:
  name: Cache Poisoning
  author: melbadry9 & xelkomy
  severity: low

requests:
  - raw:
      - |
        GET /?mel=9 HTTP/1.1
        X-Forwarded-Prefix: cache.melbadry9.com
        X-Forwarded-Host: cache.melbadry9.com
        X-Forwarded-For: cache.melbadry9.com

      - |
        GET /?mel=9 HTTP/1.1

    req-condition: true
    matchers:
      - type: dsl
        dsl:
          - 'contains(body_2, "cache.melbadry9.com") == true'

You can see that we used mel=9 as cache-buster so we don't end up poisoning everyone in case of vulnerable subdomain.

Testing Template

After testing, our template worked and detected cache poisoning in the vulnerable lab.

Scanning

After I woke up, I checked the scanning output file. To my surprise, scanning generated a few hits, and I had to determine which header was causing cache poisoning and then check for possible exploitation scenarios.

Success Case

After scanning generated, some hits turned out that only one of them is exploitable and worth reporting. I reported it to the private program, launched in 2016, and led to a $1500 bounty.

Vulnerability Report

Payload

X-Forwarded-For: cache.melbadry9.com"></script><script>alert(document.domain);</script>

Impact

  • Stored XSS, which leads to stealing login credentials

  • Web defacement and DDoS attack

At this point, we have created a theoretical template that has to be tested, so we used PortSwigger to test our template, specifically this .

I started collecting my targets which include public bug bounty programs and private programs, using this . By the end of this process, I ended with a list containing 4957145 subdomains. Then I fired my VPS and started Nuclei, and went to sleep.

Khaled
Nuclei
article
Labs
lab
tool
About Me
Testing Template on Vulnerable Lab