MFA (Multi-Factor Authentication)

MFA

Multi-factor authentication is when you use two or more authentication. factors to verify your identity. These factors include Something you know, such as a password, passphrase, or personal identification number (PIN) Something you have, such as a token or smartcard.

A key way to hack MFA is to look for weeknesses in the entire authenication process from identity registration,authencation screate storage, authenication and storage.

MFA types,

1. Push send Authenications
2. OTP Authenications
3. Email Authenications
4. 3rd party Authenicators and many more…..!!!!!

Basics on MFA

Identity

An identity is an unique label for identifying a specific subject. An identity may be such as username,EmailAddress,Passwords etc

Authenciation

Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system.

Authorization

Authorization is a process by which a server determines if the client has permission to use a resource or access a file.

Methods for Bypassing MFA`s

Disabling/Weakening Multifactor Authentication

This occurs when an attacker modifies a configuration to outright disable or weaken an organization’s ability to enforce MFA policies, such as modifying trusted IP configurations.

OTP Code Reusability

When the application doesn’t invalidate a previously used OTP and the expiration time-frame is considerable say 1 day. It can be abused by an attacker to brute-force or guess for a valid (even complex) OTP and bypass the restriction. To check if this issue is present, the following steps can be carried out:

a. Attacker requests an OTP and uses it. b. Now, in the next iteration, the attacker uses the same old OTP and if the OTP is accepted as valid, the issue is present.

Bypassing 2fa using conventional session management

This method is about bypassing the two-factor authentication mechanism using password reset functions. In almost all web applications the password reset function automatically logs the user into the application after the reset procedure is completed

Bypassing 2fa via brute force

Usually, the length of the 2fa code is 4 to 6 characters which often a number, and that makes to a possibility 151,800 which in a real-world scenario is easily brute force able using a normal computer

Bypassing 2fa using race conditions (RARE)

An attacker can utilize previously used or unused values of tokens to verify the device. However, this technique requires the attacker to have access to the previously generated values, which can be done via reversing the algorithm of the code generation app or intercepting a previously known code.

Bypassing 2fa using response manipulation

Enter correct OTP -> Intercept & capture the response -> logout -> enter wrong OTP -> Intercept & change the response with successful previous response -> logged in

Bypassing 2fa using Activation link (RARE)

Able to login with an activation link ( Activation link is vulnerable and token not expiring)

Bypassing 2fa using backup code request & response (Try your logic kinds of stuff)

I quickly moved to the backup code generation part. So at the account setting page, the following sample API request is used to get back up codes.

So the above API request fired in 2nd case of session scenario (defined above) since we are logged in to account. Now, what if we fire the same API request using 1st session scenario i.e. when the user provides valid email and password but not 2FA code.

So I quickly logged out and logged in again with valid email and password. As expected bountyplease.com redirected me to the 2FA page. This time I provided the wrong OTP code and captured the request and made the following two changes in request -

Replace the original Destination to POST /API/totp_auth HTTP/1.1 2. Replace the original parameters to {“action”:”backup_codes”,”clusterNum”:”000",”accountId”:”test123",”email”:”test123@gmail.com”}

CSRF & Clickjacking to Disable MFA

Assume that the application has functionality for authenticated users to disable the MFA and there is no password/authentication verification on it.

Assuming that if the application is also vulnerable to Cross-Site Request Forgery (CSRF) or Clickjacking, the attacker can utilize these attacks to trick victim user to turn off their MFA and remove the blocker & use the compromised credentials to access the victim account.

Missing Integrity Checks on OTP

This attack is fairly simple. When the application just checks for a valid OTP but doesn’t check valid for which user, this can be leverage. Steps are as simple as the following:

a. Attacker requests a valid OTP from his account. b. Attacker uses the request OTP of his account to login to the Victim account. c. If the application doesn’t perform for which user the OTP is valid but just check if the OTP is valid or not, this can be leveraged to bypass the MFA restriction.

Bypassing 2fa Via OAuth mechanism ( Mostly not Applicable one )

As it is observed that in this process flow there is no intervention of 2fa. An attacker can potentially abuse this mechanism and utilize an OAuth integration to log into the web application rather than using the username and password.

For this bypass to work the attacker must have access to the OAuth integration account to log in on behalf of the user

Site.com requests Facebook for OAuth token > Facebook verifies user account > Facebook send callback code > Site.com logs a user in

Small Example of MFA bypass

Once logging into the application, a request was sent to the registered phone number as:

POST api/sms-enroll
Host: example.com
Authorization: Bearer
eyJhBGci0iasnjuvuygaBsdjiI9asdIasdOd0dsgh………

{“phone_number”:”1212112322”}

Now by the POST request, we can understand that a request was sent to the mobile number requesting for OTP. The phone_number was modified and the request was replayed such that the OTP was now sent to the attacker’s device. The response had the status 200 indicating the request was submitted successfully and the OTP had been sent to the attacker’s device. As the new OTP sent to the attacker matches the latest OTP in the application, the check was indirectly bypassed helping the attacker gain hold of victims account.

This submission is triaged as a medium priority bug as the attacker needs to know the credentials of the user beforehand, via credentials stuffing or various other methods to phish the user.

1 more example for MFA

HTTP Response Status Code Manipulation

Similar to the above-described technique, if the application relies upon checking the HTTP Response Status Code for proceeding further, it is possible to manipulate the response code and bypass the restriction.

Original Request with Invalid OTP:

POST /otp-verify
HOST: target.com
<redacting_required_headers>
{"otp":82693}

Original Response:

403 Forbidden
<redacted>
{"error":true, "message":"Invalid Token"}

Modified Response — Status Code(with same wrong OTP):

200 OK
<redacted>
{"success":true}

Remediations

1. Ensure that the OTP verification logic is not happening at the client-side and OTP/OTP Generation Logic is not stored on the client-side.
2. Ensure that the OTP is not leaked in Response Body returned from the Server.
3. Make sure the application performs the integrity checks and check for From which user the valid OTP is coming.
4. Ensure that the OTP can not be reused and the expiration time is relatively short such as 15 minutes.
5. Ensure that the strong OTP is used and the application implements proper brute-force & rate-limiting protections.
6. Make sure that the MFA Disabling feature requires a user to verify the password in order to prevent disabling MFA if the attacker tries to chain it with issues such as Clickjacking or CSRF.
7. Ensure that all the authorization checks are in place and the user is not able to directly request the authenticated endpoint after providing a valid login password to bypass the MFA page.
8. Make sure that the application doesn’t rely upon the response status code or response body returned by the server and properly validates against response manipulation in order to avoid any potential bypass.

Suggestions are most welcomed,

Please write a mail to Akash.venky091@gmail.com, Also you can follow me here for more updates on Security, Ethical hacking Akash Venky or contact me @ https://www.linkedin.com/in/akash-h-c-4a4090a7/