312-50 Question 347
Single answer▪ Web API, Webhooks, and Web ShellDuring an authorized assessment of a company’s CI/CD environment, you discover a public-facing webhook endpoint used by a source-code platform to notify an internal deployment API whenever code is pushed. The deployment API accepts JSON and then invokes a shell script with a value taken from the webhook payload’s branch field. The developers tell you they rely only on the webhook URL being hard to guess and do not verify any signature headers. You are asked to identify the most likely exploit path that could lead to remote command execution and a web shell on the deployment server.
- A
Send a forged POST request directly to the webhook endpoint with a manipulated branch value containing shell metacharacters so the deployment script executes attacker-controlled commands and drops a web shell
- B
Perform a SQL injection attack against the webhook endpoint because webhook receivers typically store every payload in a database before processing it
- C
Use DNS zone transfer against the source-code platform to retrieve the secret webhook token, then replay a valid event to execute commands on the deployment server
- D
Exploit reflected cross-site scripting in the deployment API response so the server-side shell script runs in the administrator’s browser context and creates a web shell
Show answer and explanation
Correct answer: A
Explanation
The best answer is the forged webhook request leading to OS command injection. In real environments, webhook receivers should verify authenticity using a shared secret and platform-provided signature mechanism, such as HMAC-based signatures provided by common platforms like GitHub and GitLab. Relying on a hard-to-guess URL is weak security because endpoints can be discovered, leaked, or brute-forced. Separately, any value taken from webhook JSON and passed into system commands must be strictly validated, allowlisted, or handled through safe APIs that avoid shell interpretation. The scenario combines two practical issues CEH candidates should recognize: unauthenticated or weakly authenticated webhooks and command injection in backend automation. If exploited, command injection can be used to place a web shell on the target server, giving the attacker ongoing remote control through HTTP. Relevant best practices include validating webhook signatures, enforcing least privilege for deployment services, avoiding shell invocation where possible, and sanitizing or allowlisting user-controllable input before it reaches system commands.
- A. Correct.
Correct. This is the most direct and realistic exploit chain in the scenario. If the webhook receiver does not validate an HMAC or signature header from the source platform, an attacker can forge webhook requests. If the application passes the branch field into a shell command without safe parameterization or strict allowlisting, shell metacharacters such as ;, &&, |, or command substitution may trigger OS command injection. That can be used to write a server-side web shell into a web-accessible directory, resulting in persistent remote command execution.
- B. Incorrect.
Incorrect. SQL injection is possible only if there is actually unsafe database interaction. The scenario specifically describes JSON processing and shell invocation based on the branch field, which points to command injection rather than SQL injection. Assuming that webhook handlers always persist payloads to a database is a common but unsupported leap.
- C. Incorrect.
Incorrect. DNS zone transfer is unrelated to how webhook signing secrets are managed. Webhook shared secrets are normally configured in the source platform and webhook receiver, not published through DNS. Even if a valid event were replayed, the main weakness described is missing signature verification and unsafe shell execution, not token retrieval via DNS.
- D. Incorrect.
Incorrect. Reflected XSS affects client-side code running in a victim’s browser, not server-side shell execution. A browser-based script cannot directly cause the deployment server’s shell script to execute unless there is a separate server-side vulnerability. This option mixes client-side and server-side execution models, which is a common misconception.