lilloX's blog

Overview

Multi-factor Authentication (MFA) is an authentication method that requires the user to provide two or more verification factors to gain access to a resource such as an application, online account, or a SaaS tool. MFA is a core component of a strong identity and access management (IAM) policy.

Rather than just asking for a set of credentials, MFA requires one or more additional verification methods, which should decrease the likelihood of a successful cyber-attack.

The main benefit of MFA is it will enhance security by requiring users to identify themselves with more than a simple credential. While important, usernames and passwords are vulnerable to brute force attacks and can be stolen. Phishing campaigns are an example of this. Enforcing the use of an MFA factor means increased confidence that your organization will stay safe from cybercriminals.

This is the default setup for LastPass Enterprise and Duo:

1. The user requests to login on the LastPass page and insert the credentials
2. If the credentials are valid then LastPass app requests an MFA validation to the DUO API endpoint
3. The user accepts the push notification
4. The DUO endpoint returns the authentication token
5. The user accesses the password vault

So far so good, from a theoretical point of view the LastPass/DUO integration seems to guarantee the security of the LastPass account. This is fundamental as the Master Password is used for login, which is the key with which passwords in LastPass are encrypted. In the absence of an MFA, therefore, if the master password is compromised so are all passwords in the LastPass vault.

Security issues arise from the default settings set during integration.

Two points, in particular, are critical: the use of WebSDK and domain whitelisting. Both options are not active by default and this results in the DUO MFA not acting as a Push-Based 2FA (more secure) but as a simple OTP (not secure, phishable).

The default setting (WebSDK=False) means that all types of clients see the same LastPass Duo prompt, the authentication process is driven by LastPass backend and basically, there is no control on the source of the 2nd-factor authentication request.

When WebSDK is not in use you'll see the LastPass Duo prompt and at the same time a push authentication request appears on your mobile device if you've activated Duo Mobile

This configuration allows for a Man in the Middle (MITM) attack using a reverse proxy. Since, as previously mentioned, the decryption activity of LastPass vault is at client level, with this attack it is possible to decrypt the whole vault and access all credentials.

With this setup we do not interfere with the DUO mechanism, so the token returned in step 4 will be valid and therefore it will be possible to intercept the traffic.

Configuring the integration to use WebSDK means that the authentication iframe is handled directly by DUO, so the process is direct between the user's browser and the DUO backend.

This configuration is still vulnerable, as the DUO backend does not check, by default, the domain it is responding to in step (4)

So:

This is where the option of domain whitelisting comes in. Without control over who initiated the authentication process, it is still possible to use the reverse proxy and capture the vault.

In this way, when the user in step 3 accepts the push, the DUO backend will check if the host (in practice, the address in the URL bar of the browser, or the parent of the iframe) that requested authentication is among the authorized domains, otherwise it will refuse the connection.

This is the example I used for confirm the issue resolution:

The phishing domain lastpassonline.com is not an authorized domain, so the authentication process was stopped.

This work is based on pberba's PoC showing the vulnerability of the LastPass/DUO/Yubikey integration, instead we show the vulnerability of the DUO Push integration in its default implementation.

The attack

As noted before, this configuration allows to do a Man in the Middle attack using a reverse proxy.

To do the MITM attack a domain is needed to be used. For the test, lastpasspro.com was used as the domain. In a phishing scenario, this could trick some users. Evilginx2 was used as the reverse proxy, using the pberba's lastpass phishlet.

Then the attack machine, the domain, and the reverse proxy were configured:

When the target clicks on the phishing URL https://lastpasspro.com/ac=1&lpnorefresh=1&customer=GUQeAEFw (the real login page is very similar: https://lastpass.com/?ac=1&lpnorefresh=1) they will be redirected to the reverse proxy, then the reverse proxy will open the communication with the true lastpass.com domain. Aside from the wrong domain, nothing is different in respect to the true LastPass login page. This because of the reverse proxy.

When credentials are entered, the DUO dialog appears as expected and the push notification is sent. The domain is still lastpasspro.com.

Looking at the IP/Location one can see the IP and the position of the MITM server, as expected. This is a minor issue, in the phishing perspective, because often people interact with the push requests without opening the notification or using a wearable device that usually displays only the "accept" and "reject", without further information.

After accepting the push request, the reverse proxy will present all the credentials captured.

The username and the password AND “all authorization tokens” were give. In this case, the token is the encrypted vault.

Using a publicly available tool the vault was able to be decrypted, all the credentials, secure notes, and so on, that were stored in the user’s vault were able to be accessed.

The resolution

The solution to this problem is basically to enable options that DUO leaves disabled by default for some reason.

1. Enable the DUO Web SDK policy, which will prevent LastPass from managing the DUO interactions
2. Whitelist lastpass.com as the only authorized domain to start an MFA request

The whitelist mechanism only works if the Web SDK is enabled, otherwise it is ignored.

In the DUO documentation there is no indication that the implementation without the Web SDK is inherently insecure, while domain whitelist is only mentioned in the test section of the installation .

Vendor response: DUO has been informed of this issue and acknowledged that the configuration change would solve the problem, and that users should use site whitelisting and WebSDK as a fix for the issue. They also said that they are in the midst of a complete redesign of the login and that this sort of attack will not be an issue going forward, however there was no schedule for when this will be implemented.

Comments, suggestions Tweet to @lilloX_74