一起绕过双因子验证的实际入侵案例
作者: 日期:2016年03月01日 阅:4,815

上周,云服务提供商Linode发布了一篇博文,描述了其云服务客户PagerDuty的服务器被入侵的过程。

网络入侵事件已经泛滥,但此事值得关注的是,攻击者是通过Linode的管理面板进入PagerDuty的服务器的,而想要做到这一点,攻击者必须绕过安全性极高的双因子身份验证(2FA)。

在典型的2FA应用中,用户身份验证一般遵循以下过程:

用户在网站或其他服务器上输入用户名和口令时,用户的终端设备上会运行TOTP算法产生一次性的服务器口令,用户再将此口令输入服务器。服务器端也会运行TOTP来验证输入的一次性口令,想要验证成功,用户设备的时钟需要和服务器的时钟大致同步。用于后续所有身份验证会话的单一密钥,必须在之前通过安全信道在服务器和用户设备之间共享。

640.webp (18)

谷歌认证器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已经更换了另一家云服务提供商。

 

申明:本文系厂商投稿收录,所涉观点不代表安全牛立场!


相关文章