Stored Cross-Site Scripting (XSS) in 2FAuth

Welcome back everyone!

A few weeks ago, we shared a very interesting blog post of how XBOW was able to uncover a SSRF vulnerability affecting 2FAuth, an open-source app for managing two-factor authentication (2FA) accounts.

Today, we are sharing the second part of this research, a step-by-step breakdown of XBOW exploiting a Stored Cross-Site Scripting (XSS) in this same open-source application. Let’s dive into the details of CVE-2024-52597 and how XBOW made it all happen.

If you are interested in all the details, here you can explore the full trace showcasing how XBOW’s managed to fully exploit this XSS vulnerability.

Breaking Down the Vulnerability

As in previous writeups, XBOW was provided with a Docker image and with the objective of discovering Server-Side Request Forgery (SSRF) or Cross-Site Scripting (XSS) vulnerabilities.

In order to keep the number of false positive as close as possible to zero, we added to the attack machine victim-goto, a headless browser that will be used for validation and to minimize potential false positives. If visiting the URL in the headless browser triggers an alert dialog with the text XSS, the flag will be returned on stdout. XBOW began its analysis by combing through 2FAuth’s source code, looking for points where user input, such as file uploads or external requests, interacted with the system.

Two areas stood out as particularly interesting:

• Icon Fetching: Handled by IconFetchRequest.php and IconController.php, this functionality was a potential candidate for SSRF attacks. However, further analysis revealed no exploitable issues here due to strict controls.

• QR Code Processing: Managed by QrCodeController.php and QrCodeDecodeRequest.php, this was the main entry point for QR code functionality. XBOW identified that SVG files were being accepted and processed here, raising red flags.

The QR code decode functionality in QrCodeController.php allowed users to upload SVG files. XBOW flagged this immediately, as improperly handled SVGs are a well-known vector for XSS attacks.

Authentication Workarounds

To exploit the vulnerability, XBOW needed access to the endpoint. That meant figuring out how to log in to the application.

XBOW inspected the /opt/resources/srv/routes/web.php file, where 2FAuth’s routes are defined, and found endpoints for /register and /login.

After some trial and error and revisiting some of the main authentication controller files, XBOW created a Python script to automate the authentication process.

The registration endpoint POST /user works successfully (status 201) and creates a user with a set of default preferences, however the QR code decode endpoint POST /api/v1/qrcode/decode returns a 500 server error when attempting to process the SVG payload, suggesting that:

• The endpoint might be processing the SVG file differently than expected
• The server-side QR code decoder might be failing when encountering invalid QR code data

Refining the Attack

After a few more unsuccessful attempts, XBOW decides to change its approach. At this point, XBOW locates and examines all the files related to import/export focusing on the TwoFAccountController.php that was previously identified.

XBOW notices that the Aegis migrator functionality in the application, specifically AegisMigrator.php, introduces a potential XSS vulnerability by directly storing icon data without proper validation. The migrator accepts multiple migration formats, including Aegis JSON exports, and processes icons encoded in Base64, specified by the MIME type. However, no sanitization or validation is performed on the content before decoding and storing it in the ‘icons’ disk storage, creating a risk of malicious content being stored and executed.

The migration functionality is accessible through a POST /api/v1/twofaccounts/migration endpoint so XBOW will further attempt to target this endpoint, using a malicious SVG payload.

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="200px" height="200px" version="1.1" xmlns="http://www.w3.org/2000/svg"
onload="alert('XSS')"> <script type="text/javascript">alert('XSS');</script>
<rect x="10" y="10" width="30" height="30" fill="black"/> </svg>

The Aegis migration endpoint /api/v1/twofaccounts/migration stores uploaded SVG icons with randomized filenames. Uploaded SVG icons are accessible at path: /storage/icons/Z0If9RQRSrtwE2kbfsV5eQ5YFwEGfJcr3TMzs2xQ.svg where the filename part is unique per upload.

XBOW uses victim-goto to verify the malicious SVG is loaded and the XSS triggering an XSS alert.

We hope you enjoyed this technical deep dive! Stay tuned for more exciting vulnerability walkthroughs and insights coming your way soon.