PT0-003 · Question #136
SIMULATION A penetration tester performs several Nmap scans against the web application for a client. INSTRUCTIONS Click on the WAF and servers to review the results of the Nmap scans. Then click on…
SSRF Attack Simulation - Exam Explanation Overall Goal The simulation tests your ability to read Nmap scan results, identify a realistic attack vector, and select appropriate mitigations. The key insight is that a WAF/CDN sitting in front of an app server creates a trust…
Question
SIMULATION A penetration tester performs several Nmap scans against the web application for a client. INSTRUCTIONS Click on the WAF and servers to review the results of the Nmap scans. Then click on each tab to select the appropriate vulnerability and remediation options. If at any time you would like to bring back the initial state of the simulation, please click the Reset All button. Answer:
Most likely vulnerability: Perform a SSRF attack against App01.example.com from CDN.example.com. The scenario suggests that the CDN network (with a WAF) can be used to perform a Server-Side Request Forgery (SSRF) attack. Since the penetration tester has the pentester workstation interacting through the CDN/WAF and the production network is behind it, the most plausible attack vector is to exploit SSRF to interact with the internal services like App01.example.com. Two best remediation options:
Restrict direct communications to App01.example.com to only approved components. Require an additional authentication header value between CDN.example.com and App01.example.com. Restrict direct communications to App01.example.com to only approved components: This limits the exposure of the application server by ensuring that only specified, trusted entities can communicate with it. Require an additional authentication header value between CDN.example.com and App01.example.com: Adding an authentication layer between the CDN and the app server helps ensure that requests are legitimate and originate from trusted sources, mitigating SSRF and other indirect attack vectors. Nmap Scan Observations:
CDN/WAF shows open ports for HTTP and HTTPS but filtered for MySQL, indicating it acts as a filtering layer. App Server has open ports for HTTP, HTTPS, and filtered for MySQL. DB Server has all ports filtered, typical for a database server that should not be directly accessible. These findings align with the SSRF vulnerability and the appropriate remediation steps to enhance the security of internal communications.
Exhibits
Explanation
SSRF Attack Simulation - Exam Explanation
Overall Goal
The simulation tests your ability to read Nmap scan results, identify a realistic attack vector, and select appropriate mitigations. The key insight is that a WAF/CDN sitting in front of an app server creates a trust boundary - and if that trust boundary is exploitable via SSRF, an attacker can use the CDN as a proxy to reach internal services that wouldn't be directly accessible from outside.
Why SSRF Is the Correct Vulnerability
The Nmap results tell the story:
| Host | HTTP/HTTPS | MySQL |
|---|---|---|
| CDN.example.com (WAF) | Open | Filtered |
| App01.example.com | Open | Filtered |
| DB Server | Filtered | Filtered |
The CDN has open HTTP/HTTPS ports facing the internet, and App01 also has open HTTP/HTTPS. This means CDN can talk to App01 over HTTP. In a SSRF attack, the attacker tricks the CDN/WAF into making HTTP requests to internal hosts (App01) on their behalf - bypassing any perimeter controls that would block the attacker's own IP.
The database having all ports filtered is the expected defense-in-depth posture: the DB isn't directly reachable, but App01 likely can reach it - making SSRF a stepping stone to deeper compromise.
Step-by-Step Breakdown
Step 1 - Review Nmap scans on WAF and servers
This is the evidence-gathering phase. Without reading the scan results, you're guessing. The open/filtered port states reveal the trust relationships between network zones (internet -> CDN -> App01 -> DB). Skipping this means you'd be selecting a vulnerability without supporting evidence, which is both wrong on the exam and wrong in real pentest methodology.
Step 2 - Click the Vulnerability tab
Navigational, but deliberate: you can't select the vulnerability until you're on the right tab. Doing this before reviewing scans would mean you're choosing blind.
Step 3 - Select "Perform a SSRF attack against App01.example.com from CDN.example.com"
This is the correct answer because:
- The CDN is Internet-facing with open HTTP ports
- App01 is reachable from the CDN (open HTTP/HTTPS)
- An attacker who can influence requests through the CDN (e.g., via a vulnerable URL parameter) can force the CDN to make requests to App01 - an internal host not directly accessible
- SQL injection, RCE, etc. are not suggested by port states alone; SSRF is specifically implied by the CDN-to-App01 open HTTP relationship
Step 4 - Click the Remediation tab
You must identify the vulnerability before selecting remediations, because the correct remediations are specific to SSRF. Going here first would force you to guess which remediations apply without context.
Step 5 - Select both remediation options
- Restrict direct communications to App01 to only approved components: Implements allowlisting so that even if SSRF is triggered, the CDN can't reach unauthorized internal services. This is network-level defense.
- Require an additional authentication header between CDN and App01: Even if an attacker forces the CDN to make a request to App01, App01 won't process it without a valid internal auth token. This is application-level defense.
These two remediations work in layers (defense-in-depth). A single control can fail; both together significantly reduce the SSRF attack surface. Selecting only one is partial credit at best.
What Goes Wrong If Steps Are Skipped
- Skip Step 1: You lack the evidence to justify your vulnerability choice - you might pick SQL injection or a scanning-based attack instead of SSRF.
- Skip Step 3 before Step 5: You'd be selecting remediations for an unknown vulnerability, likely picking generic answers that don't address SSRF specifically.
- Select only one remediation: You'd miss the defense-in-depth principle. Network restriction alone doesn't stop a compromised CDN; auth headers alone don't stop a misconfigured network path.
Memory Tip
"CDN opens the door, SSRF walks through it."
Whenever you see an internet-facing proxy/CDN with open HTTP talking to an internal app server, think SSRF. The WAF filters inbound external traffic - but it can be abused as a forwarder to internal hosts. The two remediations map to: who can knock (allowlist) and proving it's really you (auth headers).
Topics
Community Discussion
No community discussion yet for this question.