Two-factor authentication bypass for Duo

initial preparation work

As part of our preparation for our clients' assessments, I have enjoyed reading these past reports. One of the reports presented details of Duo's two-factor authentication bypass. Although I'm skeptical that this vulnerability still exists, I'm intrigued by the potential. I enthusiastically started to evaluate, but soon found that this bypass method was no longer effective. In fact, the app's requests and server responses are now quite different from those in this report. But I put that aside and moved on to testing other parts of the application.

Dig the initial bypass

While looking closely at the HTTP traffic generated in Burp, I decided I should revisit the Duo issue. Luckily, it's important that we have additional app accounts available for testing, and you'll see why shortly. In the usual authentication process, the user will eventually trigger the two-factor authentication verification and send it to the Duo endpoint through a POST request, as shown below:

Requests sent to the Duo API

(Screenshot 1: Request to Duo API)

I logged into the app with my attacker account and captured the above two-factor authentication request. Duplicate the request (everything from the Cookie header onwards) and throw it away. Next, I logged in with the second
victim account . After intercepting the 2FA request, I replaced the current request with the previous request from the attacker account. Then submit this two-factor authentication request that should be sent to the attacker account device.
In the end, the request was successful! However, I am now logged in as the victim account. The verification code for two-factor authentication has already been sent to the attacker's device.

I'm a little shocked by its success. I thought there might have been a fluke, so we tested again with other accounts and devices.

The results show that the attacker needs to enable Duo's valid application account on the device under his control, and obtain the victim's login credentials (here generally refers to username/password, etc.) to successfully bypass this process.

first optimization

The next step is to determine which request parameter can be used to identify the user who requested the push notification. We first try to use the cookie value. The cookie values ​​across several requests are compared and copied to determine if any of them might be used to identify the user. But we didn't achieve anything in this step.

Next, we inspected sidthe parameters in the request body. We looked again at several requests to try to determine sidif any part of it could be used as an identifier. Since it wasn't clear sidwhich part we needed, we just copied the entire value. Then I found that this can also request success! sidTherefore, we can now achieve the effect of bypassing two-factor authentication by simply copying the value instead of the entire request content.

An example request flow bypass is shown in the screenshot below:

Raw victim push notification request

(Screenshot 2 - Original Victim Push Notification Request)

Replace the victim sid with the attacker's

(Screenshot 3 - will sidbe replaced with attacker sid's victim request)

In a nutshell, an attacker first logs into an app that asks for two-factor authentication push notifications to devices they control. After the request sidis copied, the request is discarded, so the request never reaches Duo and the push notification is not triggered. Next, the attacker logs in with the victim's login credentials and requests push notifications for two-factor authentication. Intercept the request, and replace the one in the request sidwith the previously copied attacker's sid. This results in a push notification being sent to the attacker's device and allows them to receive a prompt for two-factor authentication.

Now that we were able to successfully reproduce the bypass on the customer's app, a colleague suggested that we try it on another instance of Duo that we had available to see if the issue was with the Duo or the customer's application implementation. After a series of tests, we found that the bypass method was also successful on the second Duo instance, which shows that this is not a bug in the implementation of the application.

Digging for another variant bypass

The first bypass method is very unstable and often fails due to sidthe active timeout problem, which makes the bypass a time-sensitive means, if you take too long to copy/ If you paste it, it will cause the bypass to fail. So after discovering this unreliable bypass method, Michael
Kruger
decided to try to find another method.

When a two-factor authentication verification code is requested, a transaction ID ( txid) is returned. This token will be continuously polled to confirm whether the user accepts the push request.

Transaction ID in server response

(Screenshot 4 - Transaction ID in server response)

Push notifications sent to user devices

(Screenshot 5 - Push notification sent to user's device)

The user receives the push and is allowed to log in

(Screenshot 6 - After the user receives the push notification and the login permission is passed)

The screenshot above illustrates that when a user requests a push notification, the server returns one txid. This is then txidused in subsequent requests to query status. By receiving the push on one device, discarding that request, and copying it txidto the second user's request, you can trick Duo into thinking the second user has accepted the verification push.

However, this approach proved to be more stable. It also allows users txidto accept pushes before they are used.

bug report

We drafted a report detailing the bypass and sent it to Duo
Security. They responded quickly and fixed the bug. I decided to try the bypass again to confirm that the temporary fix worked. I tried using sidthe and txidvalue method, but now neither of those methods work anymore.

Victim's request for two-factor authentication

(Screenshot 7 - Victim's 2FA request)

Victim request with attacker txid

(Screenshot 8 - txidVictim request with attacker)

Every time a bypass is attempted, the server responds with "Invalid txid".

Network security engineer enterprise-level learning route

At this time, of course you need a systematic learning route

If the picture is too large and compressed by the platform, you can download it at the end of the article (free of charge), and you can also learn and communicate together.

Some of my collection of self-study primers on cyber security

Some good video tutorials I got for free:

The above information can be obtained by [scanning the QR code below] and shared for free

Guess you like

Origin blog.csdn.net/text2201/article/details/129950764