46

终端安全产品存在远程命令注入风险,看我如何测试

 5 years ago
source link: https://www.freebuf.com/articles/terminal/199702.html?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

前言

近期,我们在一款热门的终端安全产品(Heimdal Thor)中发现了一个命令注入漏洞,通过利用该漏洞,将导致产品以及客户PC暴露在安全风险之中。

但是在我们上报漏洞之后,Heimdal也迅速修复了相关问题,不过值得一提的是,这个漏洞已经在一年之内影响了65万台以上的PC了。

CVE漏洞信息:【 传送门

Heimdal官方公告:【 传送门

但是,Heimdal在公告中貌似并没有提到这个远程命令注入漏洞….

YzqqEnF.jpg!web

漏洞的发现

这个漏洞是我们在一次自动化IoT渗透测试的过程中发现的。在硬件测试的过程中,我们通常会搭建一个WiFi访问点,并尝试通过拦截代理(例如Burp Suite)来重定向设备的网络通信流量。为什么呢?因为现在很多的嵌入式设备并不会对服务器的“真实身份“进行验证,这里就会存在实现中间人攻击的可能性。

一般来说,如果你用Windows笔记本连接我们的这些WiFi访问点,你将会收到大量SSL/TLS等证书错误信息,而且应用程序也会无法连接网咯,这样就存在安全风险了。现在,大多数软件开发人员都已经意识到了,检查通信对象跟加密通信流量是同等重要的。

中间人攻击-MitM

在硬件测试的过程中,我对Burp Suite流量进行了深入分析。不出所料,测试的设备果然没有对通信服务器的身份进行验证,这将允许我篡改设备固件的更新过程。但是接下来,我发现了一个“与众不同“的请求,这个请求很明显包含了Windows设备的详细信息:

6FVB32N.jpg!web

就在此时,我们客户的一个员工用他的笔记本连接了我们的WiFi访问点之后,又发现了另一个问题。在此期间,他设备中的大多数软件都捕捉到了尝试篡改网络流量的行为,并中断了网络通信。

但是,大多数,并不意味着全部!

我们发现,设备进行通信的域名为coreservice.heimdalsecurity.com,很明显“罪魁祸首”就是 Heimdal Thor ,而它们似乎还整合了终端保护和自动化软件更新等方面。

HeimdalThor在进行自动软件更新时,我发现了它会从一个JSON列表下载软件,其中包含了URL、版本信息等等。在这个列表中有“beforeInstallScript”和“afterInstallScript”这两个参数。

Jr2y6nr.jpg!web

因此,当客户端更新该软件时,嵌入的命令将会被执行:

bIr2UvV.jpg!web

客户端上的任意命令执行

终端保护产品拥有高级权限,所以当攻击者拦截了设备与服务器间的通信流量后,他们就可以控制你的设备了。

没错,首先攻击者需要拦截通信流量,而最理想的地方就是公共开放WiFi访问点了。或者说,攻击者也可以入侵家庭WiFi网络(弱PSK密钥?),然后入侵家庭网络环境中的PC。

这就很尴尬了,因为导致用户陷入安全风险的正是这些“安全保护产品”。

漏洞分析

那么这里到底出现了怎样的问题呢?

HeimdalThor是一款能够以高等级权限运行在用户设备上的安全软件,但我们认为这款产品的安全等级和标准还远远不够…

证书验证的问题应该更早被发现:

1、 很多证书验证实例中存在的安全问题应该在代码审计阶段就应该被发现了,而且有些问题在产品研发过程中已经被发现了很多次,但是在实际部署的时候又没有进行修复。

2、 应该对软件的重大升级或更新进行多次测试,证书验证的有效性也应该定期自动进行核查。

除此之外,我还发现Heimdal Thor在进行更新时下载的不是常规的可执行文件,而是.enc文件。经过分析后,我们发现这种文件是经过加密处理的。但它们是如何进行加密的呢?

应用程序采用的是.NET开发,因此反编译过程会比较麻烦,努力后我们终于找到了解密代码:

bIbiYzj.jpg!web

上述代码中的Rijndael基于的是AES加密算法,通过分析函数引用,我们发现这个函数主要的作用就是解密文件,密钥和IV分别设置为了“CryptingConstants.Key”和“CryptingConstants.IV”。

不出所料,密钥和IV都是静态的,而且在所有Heimdal Thor产品中都是相同的:

rUBfiqj.jpg!web

RijndaelManaged继承的是SymmetricAlgorithm,而这个算法默认使用的是CBC模式。这种模式没有提供身份验证机制,因此我们修改密码文本是不会被发现的。

我们还发现,服务器端返回的JSON数据中,有一个“checksum”参数,这是一个MD5校验码,它可能可以帮助我们校验更新文件的有效性,但攻击者是可以轻松绕过这种校验机制的,因为他们只需要生成一个新的MD5并替换掉之前的就可以了。

总结

总之,这款终端安全保护产品即不能提供机密性保护,也不能对数据的真实性提供有效的验证功能。

在我们看来,这款产品所采用的加密机制从设计和规范阶段就已经注定了它的失败。产品貌似看起来能够提供安全保护,但实则不然。就设计安全保护系统来说,从一开始就必须要设定好明确的安全目标,因此我们建议这款产品可以推倒从头再来了。

* 参考来源: tuisec ,FB小编Alpha_h4ck编译,转载请注明来自FreeBuf.COM


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK