How incorrect API development can lead to user deletion

We will tell you how a combination of vulnerabilities was discovered in the web application of one company, which allowed any registered user to be deleted from the system.

Initial analysis

The application we investigated was a classic system of remote user access to application resources. To begin with, we checked the functionality that was available to the user without authentication. The system allowed registration by the user's phone number. This became the starting point in the analysis of the application.

When trying to register by phone number, we found that after entering the full name and number, a request is sent to the endpoint /api/v1/users?query=eq (phone_number,string:phoneNumber).

This endpoint checked for registered users with the same phone number.

When requesting a random phone number, the application, depending on the presence of the user in the system, revealed part of the user's attributes and a test token in Basic format.

There were no other interesting findings, so we moved on to user rights analysis.

Collecting the vector

During the API reconnaissance, we noticed that the application uses several handles to access user account information. This endpoint caught our attention:

In this case, the application referred to some identifier that suspiciously resembled those we saw when iterating over phone numbers.

Guided by this idea, we tried to combine the two parts of the puzzle and achieve the ability to obtain user attributes. However, we were unsuccessful:

The application was checking the token, which prevented us from easily iterating over identifiers. We decided not to abandon the idea and to see what API versions might be available besides version 3. As it turned out, the application also had a v2 version, but it was already inaccessible with the standard token.

However, when making a request with a test token, which was discovered in the first step, access was still available.

We decided to try the available HTTP methods for this endpoint.

The result was pleasantly surprising: this endpoint supported the DELETE method. The only requirement was to specify the instanceId

This could be seen among those obtained when iterating through phone numbers:

In general, all the parts of the puzzle were already in place — we just needed to check if we could actually delete an account. We had a spare account for access testing — this was the one we decided to use for the test.

The request was sent to the server without issues and returned a correct response.

To check if the user was still in the system, we tried querying the API again to get user data by phone number:

The user was successfully deleted:

As a result, we are able to delete any user from the system. All that is needed is the user's phone number.

Implementation of the Attack Chain

The following vulnerabilities were used to demonstrate the attack:

1. disclosure of a test token;

2. ability to retrieve the user identifier by phone number;

3. access to an alternative API version with the test token;

4. available DELETE method at the /api/v2/users endpoint.

This case is indicative of the fact that vulnerabilities, seemingly of low criticality, can lead to the realization of a tangible business risk for the company if they are combined into a chain.

Lessons Learned

To protect your application from such attacks, you should adhere to the following practices:

1. Conduct application checks for development traces: test tokens, API endpoints, etc.

2. Disable unsafe HTTP methods such as DELETE, or allow their use only to privileged accounts.

3. Avoid providing users with the ability to obtain account identifiers by any attributes, such as phone number or email address.

4. Segregate access based on JWT tokens or cookies, rather than identifiers.

Author: Nikita Raspopov, vulnerability analysis specialist at UCSB