🐛[Bounty] - Lack of Authentication on IPFS Proxy: Potential for Financial DoS and Official Phishing Hosting

[Hornan7]

Context

Received via the security mailbox. I’m logging it here so we have proper tracking in place.

1. Executive Summary

I have identified a High-severity security vulnerability in the GovTool backend that allows any unauthenticated user to host files on the project's official infrastructure.

In simple words: The application provides a "Free Hosting Service" at the project's expense. Because the IPFS upload endpoint lacks any authentication, an attacker can use your server as their own private storage locker, forcing the project to pay for the storage and bandwidth cost while using your reputation to host potentially malicious content.

2. Vulnerability Details

• Vulnerability Type: Unauthenticated Arbitrary File Upload / Resource Exhaustion
• Severity: High (7.5 - 8.5)
• Justification: The vulnerability allows unprivileged remote users to abuse project-paid resources (Pinata) and host arbitrary content (Phishing/Malware) on official infrastructure. This falls under "Unauthorized access to data/resources" and "Resource Exhaustion" in the BBP criteria.
• Affected Component: govtool/backend (Haskell)

3. Technical Description & Root Cause

The vulnerability stems from a lack of authentication middleware in the backend API definition and the subsequent use of a privileged service token for untrusted user input.

• API Route Definition: In VVA.API.hs, the VVAApi type definition (Line 94) exposes the upload endpoint without any AuthProtect or Header requirements:

"ipfs" :> "upload" :> QueryParam "fileName" Text :> ReqBody '[PlainText] Text :> Post '[JSON] UploadResponse

• Privileged Token Misuse: The upload function (Line 121) retrieves the internal pinataApiJwt from the global vvaConfig. It then acts as a blind proxy, using this master JWT to authorize the Ipfs.ipfsUpload call for untrusted fileContentText provided by the unauthenticated user.
• Insufficient Filtering: The only existing guard is a size check (BSL.length fileContent > 1024 * 512). There are no checks for file type, content safety, or user identity, allowing for arbitrary content hosting at the project's expense.
  Location: VVA/API.hs:L121

Steps to reproduce

4. Proof of Concept (PoC)

I have verified that an unauthenticated user can successfully pin a file to the project's account.

Step 1: Send unauthenticated upload request:

curl -v -X POST "http://localhost:9999/ipfs/upload?fileName=pwn_report.html" \
  -H "Content-Type: text/plain;charset=utf-8" \
  -d "<script>alert('Vulnerable')</script>"

Step 2: Verification of hosting:
The backend successfully processed the request and returned a valid IPFS CID: {"ipfsCid": "bafkreiaj55rba2g636bjtcsqxqfgbopnxqsge5s5ny4e7kyell4iipgwbm"}

Production Footprint: I probed https://be.gov.tools/ipfs/upload and confirmed it responds with 415 Unsupported Media Type (matching the vulnerable code behavior) rather than 401 Unauthorized, indicating the live production system is currently exposed.

Actual behavior

5. Impact Analysis

• Financial & Resource Exhaustion (Cost DoS): Attackers can script thousands of uploads to instantly deplete the project's Pinata storage and bandwidth quotas. This creates an immediate financial liability and shuts down legitimate governance functions that require IPFS uploads.
• Reputation Damage (Official Phishing): Attackers can host scam pages or malicious scripts on your official IPFS gateway. By leveraging the project's trust, attackers can more effectively steal user credentials or wallet keys.
• Domain Blacklisting: Hosting malware on the project's account can lead to the entire gov.tools domain being flagged as malicious by browsers and security providers.

Expected behavior

6. Remediation

Immediate Technical Fix:

• Authentication: Update the VVAApi type definition in VVA.API.hs (Line 94) to include an authentication wrapper (e.g., AuthProtect or Header "Authorization" Text). The upload function must verify a valid user session before utilizing the vvaPinataJwt.
• Input Validation: Implement strict file-type whitelisting in the upload function. Explicitly reject executable or web-renderable formats like .html, .js, or .svg.

Operational Safeguards:

• Rate Limiting: Implement per-IP and per-user rate limits on the /ipfs/upload endpoint to prevent cost-based resource exhaustion attacks.
• Storage Monitoring: Configure alerts on the Pinata account for unusual spikes in storage usage or bandwidth consumption.