SSRF & URI Validation Bypass in 2FAuth

In this blog post, we will dig into another vulnerability autonomously discovered by XBOW in an open-source project called 2FAuth. This web app is designed for managing two factor authentication (2FA) accounts and generating security codes. The vulnerability, an SSRF in the OTP preview feature, identified as CVE-2024-52598 was addressed in 2FAuth v5.4.1.

This Server-Side Request Forgery (SSRF) vulnerability allows attackers to bypass network security measures and access control, which can lead to sensitive information access, especially in cloud environments. It’s not uncommon for this type of vulnerability to be exploited in the wild, such as reaching out to a Metadata Service to obtain critical credentials.

We invite you to explore the full trace showcasing XBOW’s ability to bypass MIME filtering, abuse the OTP Icon preview feature, and exploit the SSRF. In our walkthrough, we’ve highlighted the most impressive steps involved in uncovering this vulnerability.

Identifying interesting endpoints

XBOW was tasked with examining a DockerHub image with a clear objective: identify an SSRF vulnerability in the target. To minimize potential false positives, we set up a server to listen for any requests and return a specific flag, serving as our internal target in the attack environment, also known as a sheriff server.

The first logical step was to analyze the code to understand how URLs are handled and how inputs are processed across all endpoints. This led to the discovery of a potential attack vector through the fillWithURI() method, which is invoked across multiple endpoints.

The focus then shifted to the QR code functionality, specifically within the TwoFAccountService.php endpoints, which appear to manage the migration of 2FA accounts. The endpoints in question—/api/v1/twofaccounts/migration and /api/v1/twofaccounts/preview—process external input in various forms, providing a potential entry point for an SSRF vulnerability.

Mixing static and dynamic analysis to reach the vulnerable endpoint

XBOW decided to transition from a static analysis approach to a dynamic one by making an unauthenticated request to gauge the authentication requirements and response format, which indicated that registration was necessary.

Embracing the challenge, XBOW developed a strategic plan:

• Gain Authenticated Access: Secure authenticated access to test the potential SSRF vulnerability in the preview endpoint.
• Explore the Registration Process: Analyze the registration process and identify any security controls in place.
• Obtain Authentication Tokens: Acquire valid authentication tokens to facilitate further testing.
• Fame and Glory

Observe Orient Decide Act

The first speed bump come during the registration process. XBOW identified that the target was built using the Laravel framework and initially attempted to register an account using the standard API endpoints typically associated with it.

XBOW, unafraid by challenges, embarked on an OODA loop methodically testing various authentication flows. Despite initial failures and setbacks, which included inspecting JavaScript code and digging deeper into the source, XBOW persisted. Finally, it uncovered the correct sequence: accessing the register endpoint, logging in, and obtaining the CSRF token necessary to reach the vulnerable endpoint.

Attacking SSRFs

Now equipped with proper processing for authentication requests, XBOW made some initial attempts to exploit SSRF on the preview endpoint using the icon parameter, but these attempts returned NULL. Determined to uncover the vulnerability, XBOW decided to explore different strategies to trigger the SSRF.

All previous attempts failed, prompting XBOW to return to the drawing board and conduct more dynamic and static analyses. This led to a crucial Eureka moment: the earlier SSRF attempts might have been unsuccessful due to the absence of a valid image MIME type.

Success! XBOW server received a connection from the target, confirming the presence of an SSRF vulnerability. However, we were unable to inspect the content of the file, hinting at a potential MIME type validation barrier. XBOW’s initial intuition suggested that the MIME type validation might be the culprit. Consequently, multiple attempts were initiated using common bypass patterns to avoid the validation by appending parameters such as ?type=image/png#.png or icon.png#/flag.txt.

In light of this, XBOW shifted its focus to bypassing MIME type validation using SVG files, exploring their potential as a workaround to access the desired content.

Success! Utilizing the parameters ?type=image/svg%2bxml#.svg successfully bypassed the MIME type validation. PHP uses the full URL to perform the HTTP request; however, it’s important to note that anything after the ”#” character is not transmitted to the server by the client. Despite this, the PHP code incorrectly extracts the file extension from the portion after the ”#”, using it to determine how the local copy of the retrieved file is stored. For certain content types, the code defaults to inferring the MIME type from the extension, which inadvertently bypasses the MIME type validation.

Now it’s time to assemble all the pieces of the puzzle:

1. Log In and Obtain a CSRF Token: Authenticate and retrieve the necessary CSRF token.
2. Trigger the SSRF: Use the image parameter of the /api/v1/twofaccounts/preview endpoint to initiate an SSRF, employing type=image/svg%2bxml%23.svg to circumvent the MIME validation.
3. Retrieve the SVG File: Download the created SVG file, which contains the content of the external request, effectively completing the exploitation process.

We collaborated with the 2FAuth team to address this vulnerability, and they did an outstanding job in identifying and fixing it, as detailed in their security advisory.

This vulnerability was assigned the identifier CVE-2024-52598.

We hope you enjoyed this series of technical blog posts and stay tuned for more vulnerability walkthroughs coming soon.