About Goole Authenticator

为增强Google网站账户的安全性，谷歌开发了一款名为Google Authenticator的动态口令验证器。此功能需要服务器端和客户端的支持。服务器负责密钥的生成及验证，客户端实则为动态口令生成器。

Google Authenticator常被用于二次验证的位置,并且因为不依赖任何第三方，所以Google开源了该项目:

https://github.com/google/google-authenticator/

https://github.com/google/google-authenticator-libpam

Goole Authenticator的特点

Google Authenticator在线双因素认证解决方案,特点是:不再依赖于短信、邮件、商用的动态令牌等，即可实现双因素认证.

Google Authenticator实际是一种基于时间的加密算法(TOTP)的一次性密码(HOTP, RFC/4226)，它会不间断的每隔30秒生成新的验证码，意味着验证码的有效期仅为30秒，极大的保证了验证码被重复利用的风险。Authenticator允许将认证码备份到云端和你的其他设备上，通过你设置的密码对其进行加密。然后可以在新的设备上对备份的验证码进行恢复。即使手机丢失或者不在身边，可以使用电脑来生成验证码。

Goole Authenticator工作原理

Google Authenticator工作的原理是，当用户在需要进行二次认证的应用上创建账户时，服务端会同时生成一个种子密钥，该密钥通过扫描二维码的方式传递给用户，这样在应用和用户设备上均存有该种子密钥，用户可以使用Goole Authenticator工作的客户端并利用基于TOTP(RFC 6238)的加密算法结合该种子密钥每隔30秒生成一个新的6位认证码。

碰撞漏洞发现过程

我在做Code review的时候，发现代码里2FA流程相关的东西没有任何限制，基于shen透工程师的敏感立即想到了存在暴力的可能。

然后在和程序员沟通的时候，程序员说,每一秒实际有三个可用的Google Authenticator Code。

分别是前一个，当前，和下一个。因为是基于时间的加密算法，所以必须要考虑到用户时钟和服务端有小差异，并且用户输入该Code也需要花费时间。

继续Code review，并总结Google Authenticator规律:

1.每个Code的存活时间为30秒

2.一共3个有效,分别为: 前一个,当前和后一个

3.更大存活时间60秒

4.最小存活时间30秒

说到这里，我就知道密码肯定是可以碰撞出来的了,Google Authenticator是一个6位的数字Code，也就是说只有一百万种可能，当每存在三个可用Code的时候，我每次请求正确的Code的成功率为 100万/3，大约33万次就能成功。

再加上该Code30秒会变动一次，10分钟大概会出现20个可用Code，实际成功率预计会远远小于33万次

基于shen透工程师的职业抄手，于是我进行了测试:

首先是抓包，账号密码登陆之后，随便输入了一个2FA Code。

然后发送到Burp Intruder模块，设置GoogleCode参数为爆破变量

模式设置为Sniper
Payloads设置为数字

尽量模拟真实环境，线程设置为了30
结果：

跑了大概不到一个小时（没盯着，所以不知道准确时间），发送了11万次请求，就碰撞出了Code

利用方式：

修改自己浏览器的Cookie值，这个时候就能直接登陆后台。（内部项目，不方便给图，抱歉）

完了么？没有，我可是甲方，自己挖的坑，要自己想办法填。

修复

随即找到程序猿，用事实证明了该处确实存在问题。并把自己测试结果甩给他看。
由于版本发布时间比较急，所以和该猿商量的结果是做频率限制，每分钟每个账号，只能错四次。
完整的做法应该是有每个账号的错误限制和频率限制，整个系统有个全局的错误次数限制。
该行为是明显的恶意行为，当多次触发限制，应锁账号，并通知管理员和用户。
完整的做法我还是单独写个需求故事吧 :)

总结

利用条件：

服务端未做请求限制和错误限制

知道账号密码

在没限制的情况下,Google Authenticator存在碰撞漏洞。

在理想情况下(不考虑 *** 限制，服务端压力，使用分布式多线程暴力轮训)，预估10分钟之后就能碰撞出Code，使用了该功能的请检查一下有没有限制吧。

实际大家可以检查一下使用了该功能的开源项目，说不定能发现CVE哦 :)