本文讲的是 一起绕过双因子验证的实际入侵案例,上周，云服务提供商Linode发布了一篇博文，描述了其云服务客户PagerDuty的服务器被入侵的过程。
网络入侵事件已经泛滥，但此事值得关注的是，攻击者是通过Linode的管理面板进入PagerDuty的服务器的，而想要做到这一点，攻击者必须绕过安全性极高的双因子身份验证(2FA)。
在典型的2FA应用中，用户身份验证一般遵循以下过程：
用户在网站或其他服务器上输入用户名和口令时，用户的终端设备上会运行TOTP算法产生一次性的服务器口令，用户再将此口令输入服务器。服务器端也会运行TOTP来验证输入的一次性口令，想要验证成功，用户设备的时钟需要和服务器的时钟大致同步。用于后续所有身份验证会话的单一密钥，必须在之前通过安全信道在服务器和用户设备之间共享。
TOTP算法的安全取决于共享密钥的保密性。密钥一旦被盗，无论是从服务器端还是从客户端流出的，TOTP都会功效全失，因为攻击者手握密钥也就拥有了产生一次性密码的能力。Linode将基于时间的一次性口令(TOTP)作为第二个身份验证因子。
下面我们来看看攻击者是怎样利用Linode上的配置问题入侵该客户的：
在这起入侵事件中，攻击者获取到了一名PagerDuty雇员的Linode凭证，其中就包含有2FA，可以登录Linode管理界面。通过此界面，攻击者登入了PagerDuty托管在Linode的服务器。
但怪异的是，PagerDuty确信被盗凭证的源头并非是客户端（例如：某些手机恶意软件），因为该雇员根本就没有2FA凭证，他的手机在事件发生前几个月就被清空了。随后，PagerDuty向Linode通报了被黑事件，并提交了用于攻击的服务器IP地址。令人惊讶的是，攻击服务器也托管在Linode，因此，Linode可以对该服务器的完整镜像做彻底的检查。
结果最终发现，该服务器上存放有所有用于破解Linode的TOTP算法的工具和数据。其中包括：可用TOTP密钥产生TOTP口令的软件，能解密TOTP密钥防护机制的软件和密钥。命令行历史记录中还发现了成功产生一次性口令的命令。
使用云服务提供商自己托管的服务器来攻击通常不是个好主意，因为这样云服务提供商就能够彻查攻击主机了（正如Linode最终所做的一样）。而如果攻击者的机器是另一个提供商托管，那这种彻查就不太可能了。因此可以猜测，攻击者出于某些原因才不得不在Linode托管的服务器上发起攻击。
一个可能的解释是：Linode的某个内部漏洞只能从Linode内部被触发。Linode安全团队在其Lish Shell的SSH网关中发现了一个漏洞，可能被用于获取在攻击者机器镜像上发现的那些信息。该漏洞详细情况并未被透露，不过，博文中指出，Linode在被黑事件后做出的第一个改进，就是限制Lish对凭证信息的直接访问：“我们的很多应用（比如Linode Manager和Lish）都执行用户身份验证。之前，这些应用直接访问数据库来获取凭证信息。”
总结一下：Linode/PagerDuty被黑事件的一个合理的技术性解释就是，攻击者利用了Lish的直接数据库访问功能，获取到存储在同一个数据库中的其他用户凭证（比如通过SQL注入）。但是，要想利用Lish，攻击者不得不在Linode系统内部进行操作，从Linode托管的服务器上发起攻击。
当双因子合二为一
大多数情况下，管理账户凭证是此类安全事件中最弱的一环。Linode双因子身份验证只在客户端有意义，因为它要求客户脑子里知道的（口令）和手里拿着的（内嵌密钥的手机App）同时有效。然而，在服务器端，这两种因子融合成了一个，即口令和TOTP密钥都可以用单个应用访问，而且很可能就保存在同个数据库的同一行里。
云环境引入了机会的同时也引入了风险。云服务提供商必须将安全放在首位，云客户在购买服务时应将安全作为主要关键因素进行考量。
据悉，因为被黑事件，PagerDuty已经更换了另一家云服务提供商。
原文发布时间为：三月 1, 2016
本文作者：nana
本文来自云栖社区合作伙伴安全牛，了解相关信息可以关注安全牛。
原文链接：http://www.aqniu.com/threat-alert/13953.html
