利用语音信箱绕过两步验证，轻松入侵他人账户

两步验证（2-Factor-Authentication，下文简称 2FA）是 Google 为提高安全性而设计的登录验证功能，在传统的「账号加密码」基础上，新增了「移动端生成或接收随机验证码」步骤。

早在 2010 年 9 月，Google 就对 Google Apps 付费用户开放了两步验证机制，到 2011 年初，Google 向所有用户开放此机制，随后被 Facebook、LinkedIn、Yahoo、WSJ、Tumblr 等网站借鉴过去。

2011 年中，撒汉姆·沙（Shubham Shah）就写过一篇《你的语音信箱会被入侵吗？Optus、Telstra 和 Vodafone 有话说》，时隔大约三年，撒汉姆 发现 这个漏洞依然存在——

记得两年前 2FA 开始变得流行起来，当时我才 16 岁，我感觉这是个天才的创意，是用户的最佳防火墙，能有效防御包括钓鱼在内的许多攻击，为数据安全提供绝佳保障。

但最近我改变了看法，尽管 2FA 还是能够提供较好的保护，但我绕过了许多网站的 2FA——它们都把验证码通过语音邮件发送给使用者。其中一个是澳大利亚移动运营商 Optus 公司，有超过 959 万用户使用 Optus 的服务。

下面我来详细说明。

1. 2FA 机制分析，漏洞原理

2FA 机制分析

当我把 2FA 当做一个整体来分析时，我发现验证流程中有许多可用来攻击的点，比如一开始，我列出了下面这几条：

• 暴力破解验证码，受影响的网站：苹果，验证码只是 4 位数字，对于试错次数也几乎没有任何限制。

• 找一个不需要 2FA 的登录入口。

• 寻找验证码生成规律。

• 偷取「会话信息」，即通过 2FA 登录后的缓存、链接等，这样就直接绕过 2FA 登录网站。

这些方法理论上都可行，但现实中很难实现，因为它们太「正统」，所有网站都有相应防御措施。

在否决这些方法后，我进一步分析 2FA 整个流程，发现了一个安全系数低的环节： 语音信箱 。

也许看到这里，有些读者回想起 2009 年与语音信箱有关的丑闻——《卫报》、《纽约时报》揭发《世界新闻报》记者为获取新闻在同行竞争中胜出，入侵名人语音信箱进行窃听。《世界新闻报》记者的「入侵」方式 有些弱 ：直接用邮箱默认密码登录，记者在得知一个人手机号码后，向他拨号，如果没人接听，语音信箱就自动启动，然后输入密码，进入邮箱寻找线索。

还有一个很相似的案例，Cloudflare CEO 米歇尔·扎特林（Michelle Zatlyn）同样被入侵了语音信箱，但是入侵者显然要 更高明一些 ，过程也更复杂。入侵者欺骗了 AT&T 公司职员，让后者把米歇尔的邮件自动转发至另一个邮箱中。

至于我使用的方法，其实已经出现已久，早有 文档记载 ，不算复杂。

尽管语音信箱这样那样的漏洞引起了较高关注度，但相当一部分国家的绝大多数网站都没有做出实质性改善。

漏洞原理

作为一名攻击者，你需要满足以下 4 个条件，才能绕过 2FA 入侵某个账户：

• 知道用户名和密码。

• 知道账号 2FA 服务绑定的电话号码。

• 能够伪装手机号码。

• 能够远程访问语音信箱。

现实中，一名专业入侵者满足这些条件并不难，任何传统的攻击方法都能获取账号密码信息，电话号码现如今也比较好找了。至于号码伪装，也有不少便宜的服务，只需要随手用 Google 搜索就能找到。另外，如果不想注册这些服务，VoIP 同样能实现号码伪装，效果没有任何区别。

绕过 2FA 入侵第一阶段步骤如下：

1. 在网站上输入账号密码登录，弹出 2FA 页面。

2. 给受害者手机打电话，拖住大约 20-30 秒。

3. 同时在 2FA 页面选择「另一种方式」，「通过电话发送验证码」。

4. 因为受害者手机正在通话中，所以验证码信息会发送至语音信箱。

这里利用了一个缺陷，我假设「通话时语音验证码会发送至语音信箱」，也许有人会反对，认为这个假设并不一定总会成立。这个设定确实存在，它能够方便少部分人，但同时带来了巨大风险，考虑到近几年语音信箱广受诟病的安全性，我觉得很多时候都不需要下面提到的第二个缺陷就能成功入侵——在受害人未接听时，语音信息会发送到语音信箱中。

饶过 2FA 入侵第二个步骤是「语音信箱入侵」。

上面图标有许多是澳大利亚的主要移动服务运营商，本文描述的内容也主要适用于它们。如图所示，左边是完全符合入侵条件的，右边是受到一定影响，或是完全未受影响的。

另外必须一提的是，由英国媒体 The Register 报道确认 ，英国移动服务运营商 Three 和 EE 也属于左边群体。

什么叫做完全符合入侵条件？

这些运营商通过「号码识别系统」，或者说来电显示，来识别一个号码是否是语音信箱主人。 如果号码一致，系统就不会要求输入邮箱密码。

美国运营商不是这样，它们不会管呼入者号码多少，而是统一要求输入密码。但澳大利亚是这样， 据我了解，这些澳大利亚运营商的用户对于号码欺骗无能为力，只有等运营商自身改正这些问题。

第二个步骤详细流程如下：

1. 找一个号码欺骗服务，独立的服务或者能定制号码的 VoIP 都行。

2. 把呼出号码设置成：+610411000321。

3. 设置「显示号码」为受害者手机号。

4. 如果你用的号码伪装服务是 SpoofCard，它会给你个转接电话和转接码，拨打电话，然后输入转接码。

5. 这时你就是在用受害者号码，给他自己的语音信箱拨号了，输入账号和密码。

为什么拨出号码是 +610411000321？因为澳大利亚有三大主要移动运营商，Telstra、Optus 和 Vodafone。它们能转售自己的服务，所以衍生出了不少经销商性质的运营商。这些经销商（上图中 Optus 下面的就是）和上级运营商用的服务完全相同，客服热线和语音信箱服务都一模一样。所以攻击者可以直接这么设置，覆盖绝大部分用户。

注：这个漏洞已经被 Optus 修复了。

右边那些部分满足条件、或者完全不受影响的？

在图中，Telstra、Virgin 和 Vodafone 属于这部分，我没有完整地测试入侵这些运营商用户，阶段性测试结果如下：

• Telstra：强制要求输入密码，这阻止了号码欺骗攻击。

• Vodafone：如果用户没有设置语音信箱密码，系统会要求用户设置，这对于号码欺骗攻击无能为力。

• Virgin：尚未测试，不过它属于 Optus 的一部分，极有可能受到影响。

2. Google 安全团队对此的反应

Google 是最早采用 2FA 保护用户数据安全的网站之一，用户可以为自己所有 Google 服务都开启 2FA。如果用户手机号码的运营商安全措施很到位，2FA 就能很好地保护他们的数据安全，但实际上，运营商没那么靠谱。

如果你读完了上文描述，你就知道，Google、Facebook、Yahoo 和其他采用了 2FA 机制的网站，都提供了「若无法接听电话则发送验证码至语音信箱」的选项，单独看起来这只是个小问题，但它带来的连锁反应形象地说明了「千里之堤溃于蚁穴」。

• 语音信箱行业并不集中，它的安全机制如此，每家移动运营商都有自家的语音信箱管理系统。

• 语音信箱的安全机制由运营商管理，而非 Google。

• 一旦 2FA 验证码/一次性密码通过语音邮件发送，攻击者就有很大可能进入受害者的 Google 服务，不需要对 Google 这端做任何手脚。

不过这样做动静有些大，入侵者在登录受害者 Google 账户之后，受害者很有可能会收到一条登录提示的短信，这回引起警惕。

在我向 Google 安全团队提交了这个漏洞后，他们是这么回复的：

你好！

感谢提交漏洞，我们仔细地看了你说的内容，我们认为这不是 Google 产品的安全问题。这种攻击的前提是受害者 Google 账户密码已经泄露了，而且入侵者能够进入他的账户，也是在运营商们对电话号码语音信箱保护不力之下才做到的。我们建议你直接向移动运营商提交这个漏洞。

这个回复说的没错，确实是移动运营商的安全机制有问题，但我觉得 Google 也需要承担部分责任——把 2FA 验证码发送给语音信箱，这个选项本身就带来了很高风险，有许多其他支持 2FA 机制的网站都没有提供这个选项。

因此，我又回复了这封邮件：

你好！

感谢回复，我正在寻求渠道向他们反应这个漏洞。

很大一部分澳大利亚和英国的移动运营商语音信箱密码都只能是 4 位，而且对于输错密码的情况没有任何限制，也就是说，用 VoIP 服务配合一些脚本、多线程运行，就能够在短时间内暴力破解用户的语音信箱密码。

没错，这在很大程度上是运营商的问题，而且不仅澳大利亚和英国用户受到影响，世界上其他国家的用户也会受到影响。

但我认为 Google 可以做出改进，把验证码通过邮件发至用户语音信箱并不是个好选择。这带来的风险不能怪 Google，而 Google 确实把敏感信息发到了并不那么安全的地方。

我找 Duosecurity、Authy 两家专注于 2FA 的公司谈了谈，他们没有像 Google 一样让用户能选择「直接通过语音邮件发送验证码」，而是这样解决问题的：

• 设计了在发送验证码之前与使用者进行交互的机制。

• 不在语音邮件中留下明文密码。

• 要求用户对语音作出反馈作为验证。（用户接通 2FA 电话，电话中提示「按下数字 X 以继续」）

希望这些措施能够让贵团队有所触动。

Google 很快作出了回应：

你好！

感谢你对此问题作出详细解释。

正因为这不是 Google 方面的技术问题，我不能保证我们能做到多少，但我会向我们安全部门反馈。

如果你想看到我和 Google 安全团队的邮件对话全文，可以 戳这里 。

截至目前为止，我没有想出什么绝妙的解决方案，我能想到的是暂停 2FA 机制中短信和电话部分，让 Google 身份验证器（Google Authenticator） 替代 。

另外有未经证实的 消息 称，用户能够通过 2FA 找回 Google 账户，我个人测试并未成功，但 Cloudflare CEO 米歇尔的账户就是这样被入侵的。

3. Facebook 安全团队对此的反应

直到前几天，我才想起 Facebook 也有这么个 2FA 机制，叫做「登录许可」（Login Approvals），据官网介绍，登录许可带来了「非常高的安全性，和登录通知相似，但多了一个安全步骤。」

利用上面说的方法，入侵者可以轻松绕过 Facebook 的两步验证。

流程如下：

1. 登录账号。（此时受害者会接收到一条带有验证码的短信）

2. 点击「发送验证码短信给我」，出现了「电话告知验证码」选项。

3. 打电话给受害者，或者等 ta 在通话中时，点击「电话告知验证码」。

4. 然后 2FA 验证码就会出现在语音信箱了。

还可以直接向 这个链接 提交表格数据「method_requested=phone_requested」，配合本地反向代理则效果更佳，把参数从「sms_requested」改成「phone_requested」，用户连第一个短信都收不到了。（注 1）

如果你有兴趣，可以点击 这里 查看漏洞报告邮件全文，Facebook 的回应是这样的：

你好，

我们暂时禁止了「给手机发送验证码短信」的功能，我们会进一步调查和研究安全机制。目前我们的打算是在电话中新增一些与用户互动的环节，防止它被发送到语音邮箱中，然后再把验证码交给用户。

感谢你！

Facebook 反应极快，也非常果断。

4. LinkedIn 安全团队对此的反应

就像 Google 和 Facebook 一样，在错过了系统自动打去的电话后——不论是未接听，还是正在通话中——LinkedIn 一样会把 2FA 验证码发送到受害者们的语音信箱里。

在我 报告了 漏洞之后，LinkedIn 完全关闭了通过电话的 2FA 验证。

你好，

感谢你的提醒，我们能够在此漏洞被公开前暂时堵住它。

尽管未曾有用户汇报受到了影响，但我们决定暂时关闭 2FA 中的电话获取验证码功能。我们正在和合作伙伴们共同解决这个问题，在解决之后，我们会考虑重新开启此功能。

感谢你！

5. Yahoo 安全团队对此无反应

Yahoo 所有提供了 2FA 验证机制的服务几乎都受到影响，而且比前面几个网站要更严重，因为 Yahoo 用户不太可能知道有人登陆了自己账户。

一般来说网站启用 2FA 后，用户在非常用地点登陆时，网站就会立刻给用户发送一条短信。但 Yahoo 不一样，而是会弹出一个窗口，让用户选择验证发送方式是短信还是电话。

用户不会立刻知道有人登陆了自己的账户，所以，入侵者能够有更长的时间来做想做的事。

我在 HackerOne 上向 Yahoo 反应了 这个问题 ，至今已经有 14 天，但是还没收到回复，也没有见到 Yahoo 补上这个漏洞。

6. Authy 和 Duosecurity：专业的毕竟是专业的

我很快想到了这两家提供商业化 2FA 服务的公司，不过很可惜、也很可喜，它们在 24 小时内就回复了邮件，不约而同表示很早之前就知道这个漏洞，对语音信箱相关的安全问题也考虑了许久。

Authy 的 解决方案 是留下空白语音邮件，而 Duesecurity 则是在通话中 增加了 用户互动环节。

7. 降低安全威胁的方法 & 向移动运营商的反馈结果

如果你想知道自己是不是处于这种风险当中，你可以参照上文说的流程，把拨号换成你运营商语音信箱号码，进行测试。请把测试结果告诉我，邮件和评论都可以。

至于降低安全威胁的方法，其实上面已经都说过了：

• 要求用户在电话中互动，以确认是真人在接听。（推荐这条）

• 通过检查语音邮件系统，来判定是否要拨打其号码。（这可能会出现误判）

• 直接暂停「通过电话发送验证码」功能。（这会降低用户体验）

这些并不是全部方法，专业机构应该会设计出更好的机制。

Optus

我和本·格拉布一同向 Optus 提交这个漏洞（他是《悉尼先驱晨报》和《时代报》时代报的科技编辑），我们两各有所长、相互补充，漏洞提交过程非常顺利。

当我首次发现 Optus 有这个漏洞时，我写了一篇 《你的语音信箱会被入侵吗？Optus、Telstra 和 Vodafone 有话说》 ，其中有这么两段——

「Optus 对于客户隐私非常重视，每个用户的语音信箱都有独立密码，当客服代表重置这个密码时，他们会要求用户把密码修改成自己能记住的独立字符串。」

「对于号码欺骗问题这个新兴的行业威胁，我们正在考虑不同的解决方案，包括科技手段和对客户进行安全常识教育。」

这篇文章的发表日期是 2011 年 7 月 22 日，至今已经快三年了，这个问题依然存在，带来了巨大的隐私风险。

2014 年 5 月 2 日，我和格拉布向 Optus 提交漏洞报告，那之后大概一周左右，Optus 修复了这个问题。

然而， 就在漏洞修复后几个小时之内，我又找到了绕过 2FA 的方法，再次能够访问任意一名 Optus 用户的语音信箱。 Optus 正在修复这个漏洞，所以这里我就不详细描述了，但必须强调的是，如果你是 Optus 或是它下级运营商的用户，请注意你语音信箱的安全，定期修改密码。

8. 最后的话

就像我之前对验证码、SSRF（Server-side Request Forgery，服务端请求伪造攻击，注 2）和使用率限制痴迷一样，我觉得语音信箱，以及整个移动运营商安全问题会是我未来一段时间的研究方向——所有人都知道移动运营商的服务不安全，但几乎没有人指出，运营商们也不会主动去发现和修补漏洞，直到重大案例出现，我们才知道这些漏洞有多严重。

如果你想追踪「语音信箱」这个话题，请 Follow 我的 Twitter 账户，我会及时更新与运营商的沟通情况。

这些服务也很可能「被绕过」2FA 验证，不过我没有完整地检测过：Snapchat，Amazon，Airbnb，Elance，Discover……

希望你看到这里能有收获。

注释

注 1：用户访问 http://bigc.at/readme，但 bigc.at 上并不存在 readme 页面，他是偷偷从另外一台服务器上取回来，然后作为自己的内容吐给用户这里所提到的 bigc.at 这个域名对应的服务器就设置了反向代理功能。结论就是反向代理正好相反，对于客户端而言它就像是原始服务器，并且客户端不需要进行任何特别的设置。客户端向反向代理的命名空间（name-space）中的内容发送普通请求，接着反向代理将判断向何处（原始服务器）转交请求，并将获得的内容返回给客户端，就像这些内容原本就是它自己的一样。（ 大猫の意淫筆記 ）

注 2：利用这个漏洞，可以从漏洞服务器发出伪造的请求到目标服务上，目标服务可以是内网的各类服务，可以使用不一样的协议，并根据回显来判断攻击是否成功（如果是盲打的话，就不用回显了:)）。（ EVILCOS ）