312-50 Question 287
Single answer▪ Web Server AttacksDuring an authorized assessment of a public-facing Linux web server, you discover that directory listing is enabled and the site exposes a writable upload function for images. After reviewing the application, you suspect the server may execute files placed in the web root if they use a server-parsed extension. You want to validate the risk of remote code execution without causing damage or altering system configuration. Which action is the MOST appropriate next step?
- A
Upload a small server-side test file with a permitted extension bypass technique and use it to execute a harmless command such as printing the current web-server user
- B
Run a full denial-of-service test against the web server to confirm whether the upload function can be abused under load
- C
Modify the web server configuration to disable script execution in the upload directory and then verify whether the issue is fixed
- D
Attempt password spraying against the server's SSH service to obtain shell access and confirm the web server account permissions
Show answer and explanation
Correct answer: A
Explanation
This question focuses on practical validation of a web-server attack involving insecure file upload and possible execution of uploaded files. In real environments, attackers often exploit weak upload validation, double extensions, parser behaviors, or misconfigured execution permissions in web-accessible directories to achieve remote code execution. From a CEH perspective, the correct approach is not to jump to destructive testing or unrelated services, but to safely confirm exploitability with the smallest possible proof of concept. Industry best practices in penetration testing emphasize scope control, minimal impact, and preservation of the client environment. Relevant defensive references include OWASP guidance on File Upload security risks and secure handling, as well as web-server hardening practices for Apache and similar platforms, such as disabling script execution in upload directories, restricting allowed file types based on content validation rather than extension alone, and preventing directory listing where not needed.
- A. Correct.
Correct. In a controlled, authorized CEH-style assessment, the best way to validate suspected web-server remote code execution is to safely demonstrate limited code execution using a non-destructive proof of concept. Uploading a minimal server-side script through a permitted-extension bypass or parser misconfiguration, then executing a harmless command such as 'whoami' or printing environment details, confirms the vulnerability while minimizing impact. This aligns with common penetration-testing practice: prove exploitability with the least intrusive method necessary.
- B. Incorrect.
Incorrect. A denial-of-service test is not the appropriate next step for validating suspected code execution through file upload. It tests availability, not whether the server executes uploaded content. It also introduces unnecessary operational risk and is usually tightly scoped or explicitly prohibited unless separately authorized.
- C. Incorrect.
Incorrect. Changing server configuration would alter the target environment during the assessment and would prevent you from properly validating the existing vulnerability state. Ethical hackers generally document the issue and recommend mitigation rather than making production changes unless remediation testing is explicitly part of the engagement and approved by the client.
- D. Incorrect.
Incorrect. Password spraying against SSH is unrelated to confirming whether the web application upload feature leads to remote code execution on the web server. It broadens scope unnecessarily, increases risk, and tests a different attack path. The scenario specifically points to a web-server attack vector, so the appropriate action is to validate that vector directly and minimally.