Box flaw allowed to bypass MFA and takeover accounts

A vulnerability in the implementation of multi-factor authentication (MFA) for Box allowed threat actors to take over accounts.

A vulnerability in the implementation of multi-factor authentication (MFA) for Box allowed attackers to take over accounts without having access to the victim’s phone, Varonis researchers reported.

Box develops and markets cloud-based content management, collaboration, and file-sharing tools for businesses. The platform supports 2FA based on an authenticator application or SMSs.

Varonis Threat Labs researchers disclosed the vulnerability via HackerOne and the company fixed it in November 2021. 

Upon attempting to log into a Box account, the platform sets a session cookie and redirects the user to a form where they need to provide the time-based one-time password (TOTP) generated with an authenticator app (at /mfa/verification) or a code received via SMS (at /2fa/verification).

The researchers pointed out that if the user does not navigate to the SMS verification form, no SMS message will be sent despite the session cookie having been generated. A threat actor can provide the user’s email and password to get a valid session cookie bypassing SMS-based 2FA.

An attacker can easily obtain login credentials for a targeted user from past data breaches or through phishing attacks.

When the user adds an authenticator app, the eBox platform assigns a factor ID and, at login, they are required to provide a one-time password generated by the app along with the credentials.

The experts devised a method to bypass MFA for accounts where SMS-based MFA is enabled by abandoning the SMS-based verification process and initiating TOTP-based MFA instead, technically mixing the MFA modes.

The attacker could access the victim’s account using the correct username and password, but providing a factor ID and code from a Box account and authenticator app associated with an account under his control.

“After the cookie is generated, the threat actor can abandon the SMS-based MFA process (which is what the user is enrolled in) and instead initiate the TOTP-based MFA process—thus mixing MFA modes.” reads the analysis published by Varonis.

“The attacker completes the authentication process by posting a factor ID and code from their own Box account and authenticator app to the TOTP verification endpoint using the session cookie they received by providing the victim’s credentials.” Box did not verify whether the victim was enrolled in TOTP verification and did not validate that the authenticator app used belonged to the user that was logging in. This made it possible to access the victim’s Box account without the victim’s phone and without notifying the user via SMS.”

Below are the attack flow devised by the experts:

1. Attacker enrolls in multi-factor authentication using an authenticator app and stores the device’s factor ID.
2. Attacker enters a user’s email address and password on account.box.com/login.
3. If the password is correct, the attacker’s browser is sent a new authentication cookie and redirects to: /2fa/verification.
4. The attacker, however, does not follow the redirect to the SMS verification form. Instead, they pass their own factor ID and code from the authenticator app to TOTP verification endpoint: /mfa/verification.
5. The attacker is now logged in to the victim’s account and the victim does not receive an SMS message.

The platform did not check whether the user was indeed to be the one that was enrolled in TOTP-based MFA or whether the authenticator app belonged to the account that is attempting to log in.

This trick allowed an attacker to log into the victim’s Box account, bypassing SMS-based 2FA.

“We want to underscore that MFA implementations are prone to bugs, just like any other code. MFA can provide a false sense of security. Just because MFA is enabled doesn’t necessarily mean an attacker must gain physical access to a victim’s device to compromise their account,” Varonis concludes.

Follow me on Twitter: @securityaffairs and Facebook

[adrotate banner=”9″]

[adrotate banner=”12″]

Pierluigi Paganini

(SecurityAffairs – hacking, authentication)

[adrotate banner=”5″]

[adrotate banner=”13″]