本文为翻译文章，受个人知识所限部分内容可能存在偏差或曲解。原文链接：https://sensepost.com/blog/2021/duo-two-factor-authentication-bypass/

前期准备工作

作为我们为客户进行评估准备工作的一部分，我很喜欢阅读这些曾经的报告。其中的一份报告介绍了Duo的双因素认证绕过的细节。尽管我对这个漏洞是否仍然存在表示怀疑，但我还是被这种潜在的可能性吸引住了。我兴致勃勃地开始进行评估，但很快就发现这个绕过方式已经失效了。实际上，现在该应用的请求和服务器响应都已经与之前这份报告中的十分不同了。不过我还是抛开了这个问题，继续测试应用程序的其他部分。

挖掘最初的绕过

在仔细观察Burp中生成的HTTP流量时，我决定应该重新研究一下Duo的问题。好在我们有额外可用于测试的应用账户，这一点很重要，很快你就会明白这是为什么。在平常的认证流程中，用户最终都会触发双因素认证验证，并通过POST请求发送到Duo端点，如下所示：

（截图1：发往Duo API的请求）

我用我的攻击者账号登录该应用，并捕获了上述双因素认证请求。复制该请求（从Cookie头开始的所有内容）后将其抛弃。接下来，我用第二个受害者账户登录。在截获双因素认证请求后，我用之前攻击者账户的请求替换了当前请求中的内容。然后提交这个应该会发送给攻击者账户设备的双因素认证请求。结果竟然请求成功了！但是，我现在是以受害者账户的身份登录的。而双因素认证的验证码已经被发送到攻击者的设备上了。

我对它的成功感到有点震惊。我想这当中或许是存在着一丝丝的侥幸，所以我们用其他的账号和设备再次进行测试。

结果表明，攻击者需要在其控制的设备上启用Duo的有效应用账户，并且在获取到受害者登录凭证（这里一般指用户名/密码等）的前提下，才能成功绕过这一流程。

第一次优化

接下来的这一步是为了确定哪个请求参数能起到识别请求推送通知用户的作用。我们首先尝试使用Cookie值。对若干请求中的Cookie值进行比较和复制，以确定其中是否存在可能用来识别用户的任何部分。但在这一步中我们并没有取得任何成果。

接下来，我们检查了请求主体中的sid参数。我们再次查看了若干的请求，试图确定sid中的任何部分是否可以作为标识符。由于没有明确指出我们需要sid的哪一部分，我们只是复制了整个值。然后发现这样也能请求成功！所以，我们现在可以通过单纯的复制sid的值而并非整个请求的内容就可以实现绕过双因素认证的效果了。

下面的截图中显示了一个请求流程绕过的示例：

（截图2-原始的受害者推送通知请求）

（截图3-将sid替换为攻击者sid的受害者请求）

简而言之，攻击者首先登录应用程序，要求向其控制的设备发送双因素认证推送通知。请求中的sid被复制后就将该请求抛弃，这样该请求就永远不会到达Duo，推送通知也不会被触发。接下来，攻击者用受害者的登录凭证进行登录，并请求发送双因素认证的推送通知。将该请求拦截，把请求中的sid被替换为之前复制的攻击者的sid。这样就会导致推送通知被发送到攻击者的设备上，并且允许他们接收双因素认证的提示。

既然我们可以在该客户的应用程序上成功的复现该绕过方式，一位同事建议我们在另一个我们可以使用的Duo实例上进行尝试，以确认问题是出现在Duo上还是出现在客户的应用实现上。经过一系列的测试后，我们发现该绕过方式在第二个Duo实例上也能成功，这就说明这并不是一个应用实现上的错误。

挖掘另一个变种绕过方式

第一种绕过方法非常的不稳定，而且经常会利用失败，因为sid存在主动超时的问题，这就导致该绕过变成了一个时间敏感型的手段，如果你花了太长时间去复制/粘贴的话，就会导致绕过失败。于是在发现了这种可靠性不佳的绕过方法后，Michael Kruger决定尝试去寻找另一种方法。

当请求双因素认证验证码时，会返回一个事务ID（txid）。这个令牌会被持续轮询，以确认用户是否接受该推送请求。

（截图4-服务器响应中的事务ID）

（截图5-发往用户设备的推送通知）

（截图6-用户接收推送通知后并且登录许可通过）

上面的截图说明，当用户请求推送通知时，服务器会返回一个txid。然后，该txid被用于随后的请求中，用来查询状态。通过在一台设备上接收推送，再抛弃该请求，然后将txid复制到第二个用户的请求中，你就可以欺骗Duo，使其认为第二个用户已经接受了验证推送。

而这种方法被证实为是更稳定的。它还允许用户在使用txid之前就接受推送。

漏洞报告

我们起草了一份报告，详细的说明了绕过的情况，并将其发送给Duo Security。他们迅速作出了回应，并修复了该漏洞。我决定再次尝试绕过，以确认临时修复是否有效。我尝试使用了sid和txid值的方法，但现在这两种方法都已经不起作用了。

（截图7-受害者的2FA请求）

（截图8-带有攻击者txid的受害者请求）

每次尝试绕过时，服务器都会以“Invalid txid（无效的txid）”作为响应。

时间线

11/12/2020 – 漏洞发现

14/12/2020 – 上报给 Duo Security

18/12/2020 – Duo 确认该修复方案已经实施了一些日子，我们自己也证实了这一点确实有效。

07/04/2021 – 漏洞公开披露