Skip to content

Lab 04 — Exploit a Real CVE in Your Lab

Hands-on lab · ← Back to the module concept

Setup

git clone https://github.com/plaintext-security/plaintext-labs
cd plaintext-labs/offensive/04-exploitation
make up      # builds Apache httpd:2.4.49 victim + Python exploit container
make demo    # exploits CVE-2021-41773 (path traversal + RCE)
make down

Victim: Apache httpd 2.4.49 with mod_cgi enabled and Require all granted on the document root — the exact configuration that makes CVE-2021-41773 exploitable. Exploit container: Python stdlib only (no external deps).

Authorization: this app is yours — attack it freely. The habit still matters everywhere else: only test systems you own or have explicit written permission to test (DVWA, PortSwigger Academy, targets you own).

Scenario

Module 03 assessed CVE-2021-41773 (CVSS 9.8, in CISA KEV) as P0. The target is running Apache 2.4.49 on port 80. Exploit it — read a sensitive file, gain a shell, and document what a defender would see.

Do

  1. [ ] Run make demo. Read the exploit output: what path does the URL traversal use, and which HTTP method enables the RCE step?

  2. [ ] CVE-2021-41773 was patched in 2.4.50 within 24 hours of disclosure. Explain exactly what %2e is and why Apache 2.4.49's path normalizer failed to catch the traversal. (Hint: when does Apache decode %2e vs. when it checks for ..?)

  3. [ ] Read the Sigma detection rule in Step 4. What log field is being monitored? Where would this rule need to be deployed (WAF, SIEM, or endpoint)?

  4. [ ] Modify exploit.py to also read /proc/self/cmdline and /proc/net/fib_trie (the running process command and network routes). What does this tell a real attacker about the environment?

  5. [ ] A Metasploit module also exists for CVE-2021-41773: exploit/multi/http/apache_normalize_path_rce. From the container shell (make shell), install Metasploit (apt-get install -y metasploit-framework) and run the module against target. Compare the MSF approach to the manual PoC.

Success criteria — you're done when

  • [ ] You can explain the %2e URL-encoding bypass at a technical level.
  • [ ] You read /etc/passwd and ran id on the victim via the PoC.
  • [ ] You identified the defender-visible artifact and know where to alert on it.

Deliverables

exploitation.md: the CVE/CWE, the traversal path explained, proof of access (id output), the defender-visible artifact, and your Sigma rule annotation.

AI acceleration

Have a model explain the URL normalization bug — then verify against the Apache 2.4.50 release notes and the NVD entry. Models describe this CVE correctly; still verify the path encoding specifics against primary sources.

Automate & own it

Required. With AI drafting and you reviewing every line: extend exploit.py to enumerate /proc/net/tcp (open network connections in the container) and /proc/sys/kernel/hostname. Commit the extended script as a reproducible PoC.

Connects forward

Module 10 (Linux privilege escalation) starts where this ends: you have a shell as daemon/www-data — now escalate to root. Module 12 (pivoting) uses the network enumeration (/proc/net/fib_trie) from this lab to find internal hosts.

Marketable proof

"I exploit real, CVE-specific vulnerabilities — manually and with Metasploit — and can walk through the exact technical mechanism and the forensic artifacts each step leaves."

Stretch

  • CVE-2021-42013 (Apache 2.4.49–2.4.50) extends the same bug. After running the 2.4.49 exploit, update the victim Dockerfile to FROM httpd:2.4.50 and confirm the original payload is patched. Then test whether CVE-2021-42013's double-encoding (%%32e instead of %2e) bypasses 2.4.50's fix.

Comments

Sign in with GitHub to comment. Choose the type: Feedback (errors or suggestions on this page) · Hints (help for fellow learners — no spoilers) · General (anything else).