Recently, a blind SSRF was identified and patched in TruffleHog, and we want to take a moment to acknowledge the power and importance of community contributions in open-source software development, as well as the steps we've taken to address this issue.

The Blind SSRF: An In-Depth Look

The vulnerability, reported by security researcher Karan Bamal, arose from how some detectors in TruffleHog handled verification processes. Specifically, these detectors would capture an endpoint from the data being scanned and then send a GET request to this endpoint during the verification process. It has been patched in v3.81.9.

This issue was compounded by the default behavior in Go’s HTTP library, which automatically follows redirects in GET requests. This allows an attacker to set up a redirector to give more control over the path and parameters, which makes blind Server-Side Request Forgery (SSRF) possible in cases where TruffleHog might straddle internal networks. SSRF occurs when an attacker can manipulate a server to make requests to internal or external systems on its behalf, potentially leading to unauthorized access to sensitive data or services, and blind SSRF is when an attacker is unable to read the responses from these requests.

Prior to the patch, specific conditions needed to be met for an exploit to occur. For an attacker to successfully exploit this issue, the following conditions must be present:

1. Vulnerable Endpoint: The victim must have an unauthenticated endpoint on their internal network that responds to GET requests and performs state-changing actions—something that is generally considered an anti-pattern in web development and it being unauthenticated is a vulnerability in itself.

2. Payload Injection: The attacker must be able to inject a malicious payload into data that the victim will be scanning and the vulnerable endpoint must be reachable from where it is scanned.

   
   

The need for chaining this vulnerability with an already vulnerable, unauthenticated, state-changing GET endpoint sets the Common Vulnerability Scoring System (CVSS) score for this issue to a low severity. While the potential for exploitation exists, the complexity, interaction and prerequisites involved make it a low-severity vulnerability.

Mitigation and Patch Implementation

To mitigate this vulnerability, we've implemented several key changes:

1. New HTTP Clients: For detectors that involve matching on domains and URLs, we have created new HTTP clients that do not follow redirects by default. This change prevents the automatic redirection behavior that could be utilized by the attacker to have more control in SSRF attacks.

2. URL Stripping and Reconstruction: We now ensure URLs are stripped of paths and parameters and reconstruct them with only the necessary endpoint for verification. This ensures that unnecessary or potentially dangerous parts of a URL are not processed during verification.

3. Internal Host Protection: We've disabled URI (basic auth) secret verification on internal hosts. This protection will remain in place until we can safely re-enable it, likely as an opt-in feature, ensuring that only those who explicitly need it will use it.

   
   

The Power of Open Source

This vulnerability was brought to our attention by a member of the security community, highlighting the incredible value of open-source collaboration. We want to express our sincere gratitude to Karan Bamal for his contribution. His diligence in reporting this issue allowed us to quickly address the vulnerability and enhance the security of TruffleHog.

Open source is more than just a software development model—it's community, and Karan is a great champion of the TruffleHog community. The collective effort and thought of countless contributors, from developers to security researchers, drives the continuous improvement and hardening of software that the world relies on today.

Thank you to all who contribute to the ongoing success and security of TruffleHog. 

If you're using TruffleHog, we encourage you to update to v3.81.9 or later to benefit from these security enhancements and the continuous improvements we make. For more details on how to stay secure and contribute to the project, visit our GitHub repository.