March 23, 2020

Icnanker, 一个使用了SHC技术的木马下载器

背景介绍 2019年8月15日,360Netlab恶意流量检测系统发现一个通过SSH传播的未知ELF样本(5790dedae465994d179c63782e51bac1)产生了Elknot Botnet的相关网络流量,经分析这是一个使用了”SHC(Shell script compiler)”技术的Trojan-Downloader,作者是老牌玩家icnanker。icnanker其人于2015年被网络曝光,擅长脚本编程,性格高调,喜欢在脚本中留下名字,QQ等印记。 此次攻击,在我们看来没有太多的新颖性,因此并没有公开。 2020年3月12日,友商IntezerLab将一变种(6abe83ee8481b5ce0894d837eabb41df)检测为Icnanker。我们在看了这篇文档之后,觉得还是值得写一笔,因为IntezerLab漏了几个有意思的细节: SHC技术 Icananker的分类及其功能 Icananker分发的业务 概览 Icnanker是我们观察到的第一个使用SHC技术的家族,针对Linux平台,其名字源于脚本中作者的标识“by icnanker”字串。 目前Icnanker的样本按照功能可以分成2大类: Downloader Downloader用于DDos,Miner等业务,目前下载的业务样本有Elknot Botnet, Xor Botnet, XMRMiner等,在Icnanker相关的HFS服务器上我们可以看到下载量已达20000+,且以每天500+的速度增长。 Protector Protector用于保护样本不被删除,目前用于保护Miner。 Downloader的主要功能如下: 持久化 隐藏自身 删除系统命令 […]
March 23, 2020

Icnanker, a Linux Trojan-Downloader Protected by SHC

Background On August 15, 2019, 360Netlab Threat Detecting System flagged an unknown ELF sample (5790dedae465994d179c63782e51bac1) which generated Elknot Botnet related network traffic. We manually took a […]
March 27, 2020

一些网站https证书出现问题的情况分析

20200326下午,有消息说[1]github的TLS证书出现了错误告警。证书的结构很奇怪,在其签发者信息中有一个奇怪的email地址:[email protected]。明显是一个伪造的证书。 为了弄清楚其中的情况,我们对这一事件进行了分析。 DNS劫持? 出现证书和域名不匹配的最常见的一种情况是DNS劫持,即所访问域名的IP地址和真实建立连接的IP并不相同。 以被劫持的域名go-acme.github.io为例,我们的passiveDNS库中该域名的IP地址主要使用如下四个托管在fastly上的IP地址,可以看到其数据非常干净。 对该域名直接进行连接测试,可以看到,TCP连接的目的地址正是185.199.111.153,但其返回的证书却是错误的证书。因此github证书错误的问题并不是在DNS层面出现问题。 劫持如何发生的? 为了搞清楚这个问题,可以通过抓取链路上的数据包来进行分析。为了有较好的对比性,我们先后抓取了443端口和80端口的数据。如下图 TCP三次握手中的服务器应答对比 左边的数据包为https连接,右边的数据包为http连接。可以看到https的服务器应答TTL为53,http的则为44。一般来说,在时间接近的情况下,连接相同的目标IP,数据包在链路上的路径是是近似的。https的TTL显著的大于http的TTL,看起来很有可能是在链路上存在劫持。 有意思的是 在https后续的连接中其TTL值并不稳定,比如在响应证书的数据包中,其TTL变成了47,介于44和53之间,更接近于http链路的情况。作为对比,http的后续数据包的TTL值则一直稳定在44。这是一个有意思的现象。 因此,结合https会话过程中这种TTL值的异常,我们猜测是在链路上发生了劫持。 证书是怎么回事? 事实上,从我们DNSMon系统的证书信息来看,这个证书(9e0d4d8b078d7df0da18efc23517911447b5ee8c)的入库时间在20200323早上六点。考虑到数据分析的时延,其开始在大网上使用最晚可以追溯到20200322。 同时可以看到,这个证书在证书链上的父证书(03346f4c61e7b5120e5db4a7bbbf1a3558358562)是一个自签名的证书,并且两者使用相同的签发者信息。 虚假证书信息 受影响的域名及时间 从上图中可以看到,该证书的影响不仅仅在github,实际上范围非常大。通过DNSMon系统,我们提取出了受影响的域名共14655个。 通过DNSMon系统查看这些域名的流行度,在TOP1000的域名中,有40个域名受影响,列表如下: 1 www.jd.com 5 www.baidu.com 10 www.google.com […]
March 27, 2020

DrayTek Vigor企业级路由器和交换机设备在野0-day 漏洞分析报告

本文作者:马延龙,叶根深,刘宏达 背景介绍 从2019年12月4开始,360Netlab未知威胁检测系统持续监测到两个攻击团伙使用DrayTek Vigor企业级路由器和交换机设备0-day漏洞,窃听设备网络流量,开启SSH服务并创建系统后门账号,创建Web Session后门等恶意行为。 2020年12月25号,我们在Twitter[1][2]上披露了DrayTek Vigor在野0-day漏洞攻击IoC特征,并给相关国家CERT提供技术支持。 2020年2月10号,厂商DrayTek发布安全公告[3],修复了该漏洞并发布了最新的固件程序1.5.1。 漏洞分析 我们根据Firmware Total系统[4] 进行DrayTek Vigor在野0-day漏洞定位和模拟漏洞验证。其中2个0-day漏洞命令注入点keyPath,rtick已经被厂商修复,它们均位于/www/cgi-bin/mainfunction.cgi程序中,对应的Web Server程序为/usr/sbin/lighttpd。 keyPath 命令注入漏洞分析 漏洞类型:未授权远程命令执行漏洞 漏洞原因:DrayTek Vigor网络设备在登陆时支持2种账号密码传输方式,分别为明文传输和RSA加密传输。 当使用RSA加密传输时,交互逻辑为: Web前端使用RSA公钥对用户名和密码进行加密,并用keyPath字段指定RSA私钥的文件后缀,发起登陆请求; /www/cgi-bin/mainfunction.cgi程序中的formLogin()函数检测到keyPath字段不为空时,开始进行解密操作; formLogin()函数根据keyPath字段,拼接如下路径/tmp/rsa/private_key_<keyPath>作为RSA私钥; formLogin()函数分别对用户名、密码字段进行Base64解码,并写入到/tmp/rsa/binary_login文件中,然后拼接如下命令并通过openssl命令解密; openssl rsautl […]