Duo的双因素验证绕过 – 作者:大学新生Bai-安全小百科

本文为翻译文章，受个人知识所限部分内容可能存在偏差或曲解。原文链接：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实例上也能成功，这就说明这并不是一个应用实现上的错误。