TL;DR-A walkthrough on how to exploit multi-factor authentication, using Burpsuite and a few other automation tools.
Multi-Factor Authentication is getting to be more and more prevalent in everyday websites. It provides a more secure account access policy and can reduce your chances of being hacked, specifically, bruteforced.
It’s also referred to as 2FA sometimes, which is 2 different methods of authentication (ex. email/password, AND SMS code). MFA is multiple factors and includes 2FA and higher. 3FA adds biometrics like fingerprints or face IDs to the previous iteration’s factors.
Some sites don’t implement this properly though, without using best practices. This might make it vulnerable to hackers, and in this article, I’ll do a full walkthrough on exploiting one of these vulnerabilities. If you’d like to see the walkthrough and skip past learning how everything works (not recommended), scroll down to ‘Methods of Bypass’.
How it works →
The three factors that can be used for 2FA are the following:
Knowledge Factor →
This is something you know. It can’t be physically lost or found, but it can be copied — like a password or PIN code.
Possession Factor →
This is something you have that can’t be easily copied but can be stolen — like an ID, or bank card.
Inherence (Biometrics) Factor →
This is something you are, which can’t be easily faked — like a fingerprint or face ID.
2FA requires two of these three factors. MFA may use all three — or IP geolocation services to confirm your location.
This prevents hackers from getting into your account if they have both your username and password, but not the required additional factor. There are two main types of MFA communication:
- Using a text message, or email
Most web apps will use public APIs to send SMS messages but have their own code for the generation and verification of the code. Remember, repetition is one of the fundamental concepts that allow for hacking.
If you have different/complicated passwords (ex. ‘C0mPl!c4t3d’) on different accounts, you’ll be more secure against bruteforcing attacks than someone with an eight character lowercase password (ex. ‘hello123’) that they use for every account.
If each of the sites that use MFA has a different code for creating and verifying the user-supplied code, it may take a bit more time to exploit a specific login page.
2. Using a third-party authentication app (Google Authenticator, Authy)
These can be sent directly from the web app’s login function, as most popular MFA third-party apps will be able to integrate well into the authentication mechanism.
It’s important to recognize that this method does require the client device to have internet access in some way, due to the requirement of synchronization across all cloud, client, and web app interfaces.
Step-by-step →
1. App Authentication
2. Login (username/password)
3. OTP generation
4. OTP delivery
OTP, or (One Time Password), will generate authentication tokens on demand.
There are 3 types of tokens sent to the client that will determine the authentication mechanism code. Those token types include
Event-Based Token (HOTP):
Generates a token based on a combination of random values, offset with a dynamic value like a counter so that it can’t be predicted. These tokens may be valid for a limited amount of time, or they could be valid indefinitely.
Time-Based Token (TOTP):
The OTP system generates a new token at timely intervals, and also uses a dynamic parameter such as a counter to offset the token value. It’s a division of HOTP and uses a time-based parameter as well, such as the current time of day. Usually valid for 30 or 60 seconds.
Challenge-Based Token (OCRA):
Upon each new user login, the authentication server provides a unique challenge key, and then this is passed as a parameter into the token generation. Usually valid for a few minutes, instead of 30 seconds like the others.
Methods Of Bypass:
What everyone’s been waiting for. Now that you understand more about what’s behind the actual application, you’re ready to find vulnerabilities and exploit the code.
- HTTP Response Body Manipulation
This is a very common vulnerability in MFA and occurs whenever a website fails to validate a response. Websites will check whether or not the MFA code is valid, and if it is, return {“success”:true}. If it isn’t, return {“success”:false}.
However, the application only checks to proceed if {“success”:true}, which allows us to modify responses and send them back. In this scenario, an attacker can intercept the response and change the boolean “success” from false to true and bypass MFA.
Invalid OTP Request (pay attention to the OTP info at the bottom):
POST /login-otp
HOST: target.com
<EXAMPLE HEADERS:
GET /login-otp HTTP/1.1
Host: website.com
Sec-Ch-Ua: "Chromium";v="103", ".Not/A)Brand";v="99"
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.53 Safari/537.36
Sec-Ch-Ua-Platform: "macOS"
Accept: */*
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: script
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Connection: close>{"otp":82693}
Original Response (Accessed using the Proxy tab, ‘Intercept’, ‘Action’, ‘Do intercept’, ‘Response to this request’, forward request and you’ll see the ‘post’ response):
Basically:
200 OK
<Returns Headers/Browser Info>{"success":false}
We’ll use Burpsuite to modify our response→
Modified Response (with the same wrong OTP, but manually changed parameters):
200 OK
<redacted>{"success":true}
If the application successfully logs in, it implies that the bypass was successful.
- HTTP Response Status Code Manipulation
If there is a status code, such as
403 Forbidden
Change it in the response to
200 OK
This method may also bypass MFA.
- Forceful Browsing
This is when you essentially force your way onto a specific site path, bypassing the actual authentication.
INTENDED workflow →
- The user navigates to website.com/login.php and enters the login credentials.
- The application redirects the user to the website.com/login-otp.php page and asks to provide OTP.
- Now, when the user provides a valid OTP, the user is redirected to the website.com/profile.php page and can access other parts of the application as well.
EXPLOITED workflow →
- The user navigates to website.com/login.php and enters the login credentials.
- The application redirects the user to the website.com/login-otp.php page and asks to provide OTP.
- Utilizing a tool such as Burpsuite, instead of giving some random OTP on the website.com/login-otp.php site, the user redirects themselves to website.com/profile.php
This forces the webpage after the login credentials are validated, and then forces the profile webpage even if the MFA was not completed.
- Lack of Brute Force Protection
If there isn’t a rate limit or some sort of protection on the MFA page, 4 to 6-digit codes are trivial to bypass. 10,000 combinations for 4-digit codes are nothing to a computer brute force program. One’s even included in Burpsuite called ‘Intruder’.
100,000 combinations for 6 digits with TOTP increase the time to about 3 days depending on a few factors like level of security and speed of devices. In this case, I’d recommend a Meet-ITM (not Man-In-The-Middle) attack.
This is where the hacker will run parallel OTP requests while running the brute-force attack. The OTP will (eventually) match for an instance and bypass the restriction.
- Source Code Leakage
You might find that the request leaks odd information or possibly useful information. There may even be unusual changes in the actual webpage itself. Investigate this, as it may lead to finding useful source code that can be further hacked and exploited.
