Beyond the Desktop: Exploiting a Leaked Token for API

Introduction

Recently, I undertook a penetration testing project targeting a desktop application used internally by employees. The goal was to identify security vulnerabilities and assess the overall security posture of the application. The application was designed for managing documents on users machines, with a single built-in user role (admin) interacting with an external API.

Let's get started

Findings

Hard-Coded API Link and API Credentials

Using dnSpy to decompile the application, I discovered a hard-coded API link and API credentials embedded within the source code. This link was used by the application to send HTTP requests to an external server. Hard-coding such links and sensitive information is a bad practice as it exposes critical endpoints and can be easily discovered by anyone with access to the application binaries.

HTTP Requests Analysis

I utilized Wireshark to monitor the network traffic between the application and its API. It was evident that numerous HTTP requests were being sent to the API endpoint discovered in the source code. The use of HTTP instead of HTTPS was a significant security flaw, exposing the application to potential man-in-the-middle (MITM) attacks where an attacker could intercept and manipulate the traffic.

As you can see the application interacts with the API and the JWT is also leaked in the HTTP requests

But this was not all 🙂 I kept digging and found another place that we can get the active JWT for the application.

Memory Leakage of Sensitive Information

During runtime analysis using Process Hacker, I detected that the application leaked sensitive information into memory. Among the leaked data was a JWT token used by the application to authenticate with the API. This token, found in plain text, represented a serious security risk as it could be easily extracted and reused by an attacker.

After this finding we should now interact with the API and enumerate all api endpoints.

JWT Token Analysis

The JWT token extracted from memory was analyzed using jwt.io. The token belonged to the administrator account, the sole user role configured for this application. This confirmed that the application did not implement any form of multi-user authentication or role-based access control, relying solely on a single administrative user.

Setup the proxy

For an easy interact with the api, I've made a local proxy on my machine that redirects the HTTP traffic to Burpsuit.

Now, let's dig in 😈

Exploiting Broken Access Control

Armed with the administrator JWT token, I proceeded to test the API for potential access control vulnerabilities. As expected, the token granted unrestricted access to the API, allowing me to perform a variety of actions on behalf of other users. This exposed significant flaws in the application's access control mechanisms, where the administrative token could be used to execute unauthorized actions.

After some enumeration for the api endpoints, i've found endpoint that leaks critical information about user's documents

Now, let's enumerate other people's documents on other machines

Recommendations

To address these vulnerabilities, I recommend the following:

1. Avoid Hard-Coding Sensitive Information: Use secure methods to store and retrieve API links and other sensitive data.

2. Implement HTTPS: Ensure all communications between the application and the API are encrypted using HTTPS to prevent MITM attacks.

3. Secure Memory Handling: Avoid storing sensitive information like JWT tokens in memory. Use secure methods to manage and protect such data.

4. Implement Role-Based Access Control: Introduce multi-user authentication and role-based access controls to prevent a single token from granting unrestricted access.

5. Enhance Token Security: Use short-lived tokens and implement secure methods to store and manage them.

Hope you enjoyed reading.

Follow me on

LinkedIn | Facebook | GitHub