原文：
https://sensepost.com/blog/2021/duo-two-factor-authentication-bypass/
Duo双因素认证绕过
开测之前
作为测试的一部分，我先阅读了一份老的DUO双因素绕过报告，我想知道他们修没有修。快速测试了一下，发现已经修补，而且现在的响应和请求都改变了。
初步发现
我们搞了一个应用程序用于测试。在典型的身份验证流程中，用户最终将触发通过POST请求发送到Duo端点的两因素身份验证验证，例如：
请求Duo API
我使用攻击者帐户登录该应用程序，并捕获了上述2FA请求。我复制了请求（从Cookie标头向下的所有内容）并删除了该请求。接下来，我使用第二个受害者帐户登录。拦截该请求后，我将其替换为攻击者帐户请求。做到了！将发送2FA请求的提交到攻击者帐户的设备。但是，我现在以受害者帐户身份登录。2FA验证已发送到攻击者的设备！
我感到有些震惊，因为它奏效了。我以为可能是偶然，所以我们用其他帐户和设备对其进行了测试。
第一次优化
下一步是确定哪个请求参数标识了请求推送通知的用户。我们首先尝试使用Cookie值。比较并复制了多个请求的Cookie值，以识别其中的任何部分，这些部分可用于识别用户。那没有结果。
接下来，sid检查请求正文中的参数。我们再次查看了几个请求，以尝试确定的任何部分sid是否为标识符。在没有明确指示需要哪一部分的sid情况下，我们只是复制了整个值。做到了！现在，我们仅使用sid值而不是完整请求就可以绕过2FA 。
下面的截图显示了绕过请求的示例流程：
原始受害者推送通知请求
受害者sid替换为攻击者的sid
概括而言，攻击者登录到应用程序，并请求将2FA推送通知发送到攻击者控制的设备。sid复制请求中的from并删除请求，以使其永远不会到达Duo且不会触发推送通知。接下来，攻击者使用受害者的凭据登录并请求2FA推送通知。该请求被拦截，sid请求中的替换为先前复制的攻击者sid。这将导致将推送通知发送到攻击者的设备，使他们可以接受2FA提示。
现在我们可以在客户端的应用程序上可靠地复制旁路，一位同事建议我们在我们可以访问的另一个Duo实例上尝试该旁路，以确认问题出在Duo还是客户端的实现上。经过一些测试，我们发现旁路也可以在Duo的第二个实例上使用，这意味着这不是实现错误。
发现攻击变体
第一种方法非常不稳定，通常会失败，因为sid会激进地超时，使其对时间非常敏感，并且如果您花费太长时间进行复制/粘贴，则将失败。发现一个半可靠的旁路后，迈克尔·克鲁格（Michael Kruger）寻找了另一种方法。
请求2FA验证时，txid返回了交换ID（）。连续轮询此令牌以确认用户是否已接受推送请求。
服务器响应中的事务ID
发送到用户设备的推送通知
用户接受的推送通知和登录已批准
上面的屏幕截图显示了txid当用户请求推送通知时从服务器返回的。将txid随后在后续请求用于查询状态。通过在一个设备上接受推送，丢弃请求，然后将其复制txid到第二个用户的请求中，您可以欺骗Duo以为第二个用户已经接受了该推送。
这种方法被证明是更稳定的。它还允许用户在使用之前接受推送txid。
漏洞时间表
2020年12月11日 –漏洞发现
2020年12月14日–报告给Duo Security
2020年12月18日– Duo确认修复已进行了几天。我们为自己确认了这一点。
2021年4月7日–公开披露
译者按：作者通过更换cookie发现了DUO绕过双因素的漏洞,然后一步一步分析到底是哪个参数是和漏洞相关的，最后发现是SID参数。然后又仔细的分析了请求，发现txid也是又问题的。最后提出了更加稳定的利用方案。像DUO双因素认证这种技术，其实已经很成熟了。但是开发人员在实现上，最会出现各式各样的问题，一方面可能是开发人员的安全意思不到位，另一方面可能是对这个技术理解的不透彻。
本文迁移自知识星球“火线Zone”
