How I Bypassed 2FA and Hijacked User Accounts

[chushpan]

In this article, I will tell you how, during a pentest, I discovered a number of vulnerabilities in one web service, which ultimately gave me access to any user accounts. I will briefly describe each vulnerability, and then we will look at what needs to be done to close such holes.

Pentest Award​

This article won first place in the Pentest Award 2024 in the Web Penetration category. This competition is held annually by Awillix.

Warning​

The article is for informational purposes only and is intended for security specialists conducting testing under contract. The author and editors are not responsible for any damage caused by using the information provided. Distribution of malware, disruption of systems, and violation of the privacy of correspondence are prosecuted by law.

List of users​

• Danger level: medium

The site I tested had the ability to log into a personal account. And on the login page, there was an option to go through users and see the server's response: if a user with the entered name exists, the server responds differently.

If we specify an existing account, we get the message "Incorrect password entered" or "The number of login attempts with an incorrect password has been exceeded". If there is no user with such a login, the server's response will be the message "Your data was not found in the system. Check the correctness of the data entered".

I ran an automated dictionary search and found a number of valid logins.

Password Spraying​

• Danger level: medium

Then I found a way to pick up passwords of the found users using a dictionary — again, using the server's response to the entered data. This is a password spraying attack. I tried new passwords every 30 minutes, since the blocking period did not increase after each subsequent incorrect entry of credentials. As a result, I managed to pick up passwords for three users of the service.

Bypass 2FA​

• Hazard level: critical

It was not possible to log into your personal account right away because the service was checking the second authentication factor and asking you to enter the code from the SMS.

Having studied the code of this page, I found an interesting parameter — mode4. Here it has the value sms.

GET request parameters for the SMS code entry page

I went through the possible values of this parameter and found several that do not redirect us back to the login and password entry page.

Interesting values that the mode4 parameter can take

The most interesting value here is mode4=registration, which redirects to the registration completion page in the personal account. There, the user sets a login and password, but has already set and confirmed the phone number.

We enter and confirm the password of one of the previously received users, and we are able to enter the personal account, bypassing two-factor authorization. Also, if you change the login on the same page, it remains changed.

Account theft​

• Hazard level: critical

So, we entered the system without registration and SMS. But of course, we will not stop the research and continue digging.

My attention was drawn to the cookie on the password change page. It turned out that the page content does not depend on any values except UserStatus. And this value is permanent and unique for each user.

Cookie UserStatus

What happens if you replace the UserStatus of one user with the same value of another? We leave the login and password the same. After sending the request, a response comes that everything was successful. We calmly extract from it a new cookie, login, password and UserToken, but for the session of another user - the one whose UserStatus was used. A redirect also comes back to the login page. If the change was not successful, these parameters from the cookie would be assigned the values deleted and a redirect would also occur.

Now we can log in again - using the new login and password. 2FA will try to stop us again, that is, a request for a code from an SMS. But we already know what to do in this case, and we can easily penetrate the personal account of the user whose UserStatus we used.

Changing the username and password

We don't know the UserStatus for other users, but we can try to guess this value. It's 40 bits long. That's 240 options, or about 1.1 trillion values. Too many to try!

But if we analyze any UserStatus value we know bit by bit, we can see what it consists of. Half of each byte defines a field, and the other half defines the value of that field.

Bitwise parsing of UserStatus cookie values

Now we can only pick values of 20 bits. The number of options is reduced to 220, or about 1.05 million possible values for the UserStatus variable.

Result of exploitation: several accounts hijacked, potential to hijack all user accounts in just over a million requests.

Conclusions​

So, we realized that it is possible to change the logins and passwords of all users whose UserStatus contains the same fields as those known to us. Then we can authenticate on behalf of these users, bypassing 2FA. During testing, I managed to capture several accounts and establish that it is possible to gain access to any account with just over a million requests.

Here is what I recommended the customer to do to eliminate the vulnerabilities:

• User Enumeration: Unify server response when valid and invalid credentials are entered.
• Password Spraying: Increase the account lockout time each time an incorrect login and password is entered.
• Bypass 2FA: after the user has registered, do not redirect him to his personal account, but redirect him to the login and password entry page.
• Account hijacking: Use a combination of several parameters that uniquely identify a user.

Source