clawd/memory/shannon-scan-2026-02-14/deliverables/injection_exploitation_evidence.md

Injection Exploitation Evidence

Classification Summary

All vulnerabilities in the injection exploitation queue have been analyzed and classified. No vulnerabilities could be exploited through external network access to https://inou.com as required by the engagement scope.

Out of Scope Vulnerabilities (Internal Access Required)

INJ-VULN-01: Path Traversal in File Upload Processing

Summary:

• Vulnerable location: POST /dossier/{id}/upload → POST /dossier/{id}/process-imaging
• Overview: Sanitization applied to wrong variable (fileName vs relPath) allows arbitrary file write via path traversal
• Potential Impact: Arbitrary file write to server filesystem (e.g., /etc/cron.d/, /tmp/)
• Severity: Critical (if exploitable with server access)
• Classification: OUT_OF_SCOPE_INTERNAL

Why This Cannot Be Exploited Externally:

This vulnerability involves writing files to the server's local filesystem using os.WriteFile(). The attack flow is:

1. Upload file with malicious path parameter containing ../../../../tmp/malicious.txt
2. Value stored as relPath in database without sanitization
3. Trigger processing endpoint
4. Application retrieves relPath from database and uses in filepath.Join(tempDir, relPath)
5. File written to traversed path via os.WriteFile(outPath, content, 0644)

The fundamental problem: The impact occurs entirely on the server's filesystem, not in HTTP responses. To prove this vulnerability works externally, we would need:

• Option A: Server filesystem access (SSH/console) to verify files were written to traversed paths
• Option B: A secondary vulnerability to read arbitrary files and confirm our payload location
• Option C: Observable side effects (e.g., cron execution) that require internal monitoring

What we CAN observe externally:

• ✅ HTTP 200 response from upload endpoint
• ✅ HTTP 200 response from processing endpoint
• ✅ File metadata in database (if accessible via API)

What we CANNOT observe externally:

• ❌ Whether ../../../../etc/cron.d/backdoor was actually written
• ❌ Contents of files written to filesystem
• ❌ Whether path traversal succeeded or was blocked by OS permissions
• ❌ Confirmation that arbitrary file write occurred

Evidence from Code Analysis:

// File: /repos/inou-portal/portal/upload.go:182-186
// User input accepted without proper validation
relPath := r.FormValue("path")
if relPath == "" {
    relPath = fileName
}
// CRITICAL: filepath.Base() applied to fileName, not relPath
fileName = filepath.Base(fileName)

// File: /repos/inou-portal/portal/upload.go:222
// Unsanitized relPath stored in database
data := UploadData{
    RelPath: relPath,  // <-- UNSANITIZED
    ...
}

// File: /repos/inou-portal/portal/upload.go:451-462
// Retrieved relPath used in file operation
relPath := row.RelPath  // Retrieved from database
outPath := filepath.Join(tempDir, relPath)  // VULNERABLE
if err := os.WriteFile(outPath, content, 0644); err != nil {
    ...
}

Attempted Exploitation Approach (Why It Fails Scope Requirements):

If we had server access, exploitation would be:

1. Authenticate to application (using backdoor code 250365)
2. POST to /dossier/{id}/upload with:
   • path=../../../../tmp/proof_of_traversal.txt
   • File content: "Path traversal successful"
3. POST to /dossier/{id}/process-imaging to trigger processing
4. [REQUIRES SERVER ACCESS] SSH to server and run: cat /tmp/proof_of_traversal.txt
5. [REQUIRES SERVER ACCESS] Verify file contains expected content

Why External-Only Testing Cannot Prove This:

The HTTP responses from both endpoints return success (200 OK) regardless of whether path traversal succeeded:

• Application logs success after calling os.WriteFile()
• No error returned to client even if OS blocked write due to permissions
• No API endpoint exists to read arbitrary filesystem paths
• File upload status endpoints only show database metadata, not filesystem state

Conclusion:

This is a valid and critical vulnerability in the codebase, but it requires internal server access (filesystem read/write verification) to demonstrate exploitation. Per the engagement scope requirement that "ALL exploitation attempts MUST be performed against https://inou.com from external network," this vulnerability is classified as OUT_OF_SCOPE_INTERNAL.

Recommendation for Follow-Up:

If server access becomes available or if the scope expands to include internal testing, this vulnerability should be prioritized for immediate exploitation as it enables:

• Writing to /etc/cron.d/ for persistent access
• Overwriting configuration files
• Planting web shells in application directories
• Arbitrary code execution via cron jobs

---

Methodology Notes

Injection Types Analyzed:

1. ✅ SQL Injection - All queries use parameterized statements (safe)
2. ✅ Command Injection - Go's exec.Command uses array execution (safe)
3. ✅ Path Traversal - One vulnerability found (OUT_OF_SCOPE_INTERNAL)
4. ✅ Server-Side Template Injection - Templates pre-loaded, no dynamic parsing (safe)
5. ✅ Unsafe Deserialization - Go's JSON library is safe (safe)

External Testing Limitations:

Per engagement scope, only vulnerabilities demonstrable through HTTP requests to https://inou.com qualify as exploitable. Vulnerabilities requiring:

• Server filesystem access
• Database console access
• Internal network access
• SSH/shell access

...are classified as OUT_OF_SCOPE_INTERNAL even if they represent critical security issues in the codebase.

Total Vulnerabilities Analyzed: 1 Externally Exploitable: 0 Out of Scope (Internal Access Required): 1