在开始分析之前，我们得先了解一下DNP3协议的规约，以便我们在下文更容易的分析其DNP3存在的安全问

    在开始分析之前，我们得先了解一下DNP3协议的规约，以便我们在下文更容易的分析其DNP3存在的安全问题以及构造出攻击DNP3协议的EXP，文中难免出现错误地方，如有不对的地方，还望大家斧正。

为了能够更详细的表达出DNP3规约，所以在本文分析中大量引用了原DNP3规约的描述文档

DNP3.0规约的文本共分为三个部分：数据链路层、传输层、应用层。

一、数据链路层规约

数据链路层规约文件规定了DNP3.0版的数据链路层，链路规约数据单元(LPDU)以及数据链路服务和传输规程。数据采用一种可变帧长格式: FT3

FT3 帧长格式：

一个 FT3帧被定义为一个固定长度的报头，随后是可以选用的数据块，每个数据块附有一个16位的CRC校验码。固定的报头含有2个字节的起始字，一个字节的长度 (LENGH) ，一个字节的链路层控制字(CONTROL) ，一个16位的目的地址，一个16位的源地址和一个16位的 CRC校验码。

05 64 为数据开始的字节,也可以说是报文头

12为长度，这里Dnp3的长度计算有些不一样，它包括链路报文头中的5个字节，加上传输层和应用层的长度以及除去CRC校验码字节。

c4 链路控制字节

　　第一位为 表明发送的方向

　　第二位为 表示发送的设备是主设备还是从设备

　　第三位为 如果是请求则为纠错，如果是回应则为保留位

　　第四位为 这一位是说明第三位是否有效、在图上为0则为未开启。

　　后四位为 功能码

　　　　对于主设备来说

0，链路重置

1，进程重置

3，请求发送数据

4，直接发送数据

9，查询当前链路的状态

　　　　对于从设备来说

0，同意

1，拒绝

11，回应当前链路状态

03 00 目的地址

04 00 源地址

15 2d 校验码

二、传输层规约

这部分定义对于DNP数据链路层充当伪传输层的传输层功能。伪传输层功能专门设计用于在原方站和从方站之间传送超出链路规约数据单元 (LPDU) 定义长度的信息。其格式如下：

TH传输层报头：

第一位是final，标识是否为最后一个包

第二位是first，标识是否为最后一个包

后六位为seq，表明当前是第几个包

数据块：

应用用户数据1-249个字节由于数据链路层FT3 帧格式中的长度字的最大限制255，因此传输层数据块的最大长度为255-5(链路层control + source + destination）-1（TH）= 249。

当应用用户数据长度大于249 字节时，传输层将以多帧报文方式传送，并每帧前加TH控制字。如1234=249+249+249+249+238, 分5帧进行传送。

三、应用层规约

本文本定义了应用层报文(APDU)的格式。

主站被定义为发送请求报文的站，而从站则为从属设备。被请求回送报文的RTU或智能终端 (IEDS)是事先规定了的。在DNP中，只有被指定的主站能够发送应用层的请求报文，而从站则只能发送应用层的响应报文。

应用报文格式：

1. 应用响应报文格式:

请求(响应)报头：标识报文的目的，包含应用规约控制信息(ACPI)

对象标题：标识随后的数据对象

数据：在对象标题内的指定的数据对象

2．应用报文报头字段的定义：

请求报头有两个字段。每个字段为8位的字节，说明如下：

响应报头有三个字段。前两个字段为8位的字节，第三个字段为两个字节，说明如下：

应用控制：一个字节的长度，格式如下：

FIR ：此位置“ 1” , 表示本报文分段是整个应用报文的第一个分段

FIN ：此位置“ 1” , 表示本报文分段是整个应用报文的最后一个分段

CON ：此位置“1” , 表示接受到本报文时，对方须要给予确认，为“0”则不需要

序号：表示分段的序号，1-15

功能码：标识报文的目的，一个字节的长度

例如：请求报文：

0x01 -- 读，请从站读所指定的数据对象

0x02 -- 写，向从站写入指定的数据对象

……

上图数据包分析此处为写信号write (0x02)

内部信号：

共两个字节， 16位，每一位分别表示从站的当前的各种状态。

3．对象标题 (Object Header)：

报文的对象标题指定包含在报文中的数据对象或是被用来响应此报文的数据对象。格式如下：

对象（ Object）：

两个字节，指定对象组以及跟在标题后面的对象的变化。对象段的格式如下：

对象段规定一个对象组和在该组内的对象变体。对象的组别与变体结合起来可以唯一的规定报文所指定的对象。对象组指定数据的基本形式（如：模拟输入

)，对象变体指定数据的形式(如16位模拟输入或32位模拟输入)。

下图可以看到数组为1个，所以为0x01

32 01 这里表达的意思为要读取的数据的基本类型，上图的数据包为Time的类型

07 为限定词。限定词为一个 8位的字节段，规定交程段的意义。变程说明数据对象的数量，起点和终点的索引成所讨论的对象的标识符。

限定词段的格式如下：

R：保留位，置为零。

索引规模（ Index Size)：

3个Bits，规定前置于每个数据对象的索引规模或对象的规模。

在请求报文中，当限定词码 (Qualifier Code) 等于 11时,1、2、3分别代表数据对象前的索引是1、2、4个字节。0无效。 4、5、6、7保留。

限定词码 (Qualifier Code) ：

4个Bits，用以规定变程 (Range) 意义。当限定词码取值 0～5时，变程段包含1个开始范围 (Start Range) 和1个结束范围 (Stop range)。当限定词码取值 6时，则 Range 段的长为零 (即无变程段 )，因为所指定的是所要求的数据类型的全部数据对象。当限定词码取值为 7～ 9 时，则变程段由一个计数值所组成，它指明所讨论的数据对象的数目。

限定词段中限定词码和索引规模的有效组合主要有“0x00，0x01，0x02，0x03，0x04，0x05，0x40，0x43，0x51， 0x54，0x62，0x65，0x07，0x17，0x27，0x37，0x08，0x18，0x28， 0x38，0x09，0xl9，0x29，0x39，0xlb，0x2b，0x3b。

上图可以看到，此处的限定词码(Qualifier Code)为0x07

我们用一张图来概括

好了，到这个地方，DNP3协议规约大致就是这样，那么下面我们来看看它的安全问题。

安全风险分析：

DNP3协议和大多数工控协议一样，在TCP上进行传输时都是未作加密处理的，所以存在中间人攻击和数据重放攻击等安全风险。

本文以文件读取为例子，来讲讲通过协议构造任意文件读取。

通过下图我们可以知道，读取文件的函数操作码为0x19

按照读取文件的大致过程为

打开文件(Open)->读取文件(Read)->关闭文件(Close)

所以，我们需要发送三次完整的数据包就可以读取到文件了，

现在我们来构造数据包

前10个字节为固定字节，所以我们分成两段，第一段定义为Header，第二段定义为Body

Header为:数据头(0564)+数据包总长度(后面总长度)+链路控制c4+目的源地址+校检码

Body这个地方只有几处需要注意的地方，其他的地方直接置0即可，然后就是一些固定的格式操作码，我们不用改变它，所以构造出来的格式就为

链路控制c1+打开文件操作码(19)+数组01+后面字节总数+文件名偏移地址+文件名长度+文件句柄+文件操作码+文件缓冲区+文件名

解决完这些格式之后呢，我们就只需要再解决CRC校检的问题就可以了

DNP3使用的是dnp16的校检，也就是每隔16位就检查一次，我们这里用python来解决这个，在python里面有个包叫做crccheck，它里面已经有了dnp16这个校检函数，所以我们可以直接拿来用，最后根据规约格式，就可以很轻松编写出代码来

我们打开DNP3服务器，将开放20000端口

利用我们写好的工具进行测试，就可以成功读取win.ini文件，这里只能读取一部分文件，想要读取全部文件需要计算偏移

通过抓包，我们可以看到具体的流量情况

具体的通信过程为：

1. 请求打开文件

2. 然后DNP3服务器返回文件句柄等信息

3. 我们拿着这个句柄去读取文件的内容

4. 最后返回我们读取的文件信息

5. 关闭文件句柄

总结

通过对DNP3协议的大致分析，我们可以知道，DNP3在TCP上传输时如果通信双方没有约定一定的加密技术，那么很容易被发包伪造数据，对设备进行攻击。

引用：

https://github.com/wireshark/wireshark/blob/master/epan/dissectors/packet-dnp.c

https://www.anquanke.com/post/id/187221

https://www.docin.com/p-630530021.html?docfrom=rrela

阅读原文

跳转微信打开

环境： win7 x86一、 概要前面的文章写了，要实现一个exploit的编写，分析的方向就要放在漏洞点

环境： win7  x86

一、 概要

前面的文章写了，要实现一个exploit的编写，分析的方向就要放在漏洞点的下半部分，

本文写的是通过IOCL对象进行的池溢出，参考的是b2ahex的文章，因为别的都是利用是BITMAP进行布局。

二、 自己对Exploit的理解

要写一个Exploit，首先就要梳理以下几点：

1. 目前该漏洞的利用方向是什么（好像大多数都是提权）。

2. 根据利用方向再寻找利用的位置，以及该位置的元素（参数）是否可控。

因为CVE-2018-8120的利用点是任意读写，最大利用就是提权。因此我们从提权的角度开始研究。

1. 首先要明白的事情是何为提权？

用语言描述就是权限提升，从普通用户权限提升到了管理员权限。那么对应到代码的世界是什么呢？其实就是cs、ss、EIP和ESP（也诠释了各种门的设计）（微观角度），如果在加上一条那便是ACL机制-常用就是TOKEN）（宏观角度）的控制。

举个列子：

从应用层代码到了内核层，但是由于通过漏洞我们控制了cs、ss、EIP和ESP，从而执行了我们预先安排好的代码，创建了CMD进程，并进行了token的替换，在用户层使用whoami指令查看用户，就会发现是管理员权限。

(1) 从上面自己的看法中，因此编写这个程序分为两点去考虑。

① 微观的把控，其实就是寻找可以任意读写的位置，通过这个位置，执行指定位置的shellcode。

② 宏观的把控，修改ACL的规则，常用的就是替换Token。

(2) 通过中断门实验看待这2点，我觉得可以得出，宏观的把控是为了上层更好的利用，以及简便的考虑，其实微观的把控才是最重要的。因为中断门就是把控了微观的角度，从而让R3某个函数具有R0的权限。

2. 简而言之，exploit就是对微观和宏观控制的诠释。

三、 分析

1. 找到可以利用的位置

从漏洞点的位置出发，可以看到敏感函数 qmemcpy，那么它是否就是利用点呢？还要看它的参数是否能被我们控制。

从上图不难看出，它的第一个参数V4的来源于V3，V2的参数来源于这个函数本身的参数。于是焦点就变成了这个函数的两个参数是否可控，那便就要看上一层。

这个函数的v2来源于GetProcessWindowStation函数，对于分析过这个漏洞的人，应该知道这个是可控的，而V4来源于V1。此时我们可以可以断定qmemcpy就是利用位置。

2. 顺序分析注意的点

为什么要进行这一步呢？这是因为为了保证构造的数据要走到漏洞利用的位置。

由上图可知，参数1+0x14(为NULL)+0x2c(填充目的位置)+0x48(为NULL)，满足这几个条件才可以走到我们的利用点的位置。

3. 总体流程图

由于可以控制读写的位置，所以控制这个位置到池的位置，覆盖池的某些位置来达到触发shellcode代码。

其实主要是为了溢出池中对象头的TypeIndex。通过构造TypeIndex=0（这里涉及到使用零页面），通过对象执行某些回调函数，来达到执行shellcode的目的。

常见的方法就是通过closehandle来执行相应的回调。

四、 代码编写思路

采用的方式是池溢出：

池喷射最重要的就是构造池的布局，为了稳定性，可以选择泄漏内核地址（NtQuerySystemInformation）

其次池的布局已经构造完毕，但是由于只能拷贝0x15c个字节，所以我们要计算从相邻的空闲池的哪个位置开始复制。

推导公式:

开始复制的地址  +0x15c  = 泄露的内核地址 -0xC +1(+1是为了将这个地址重写了，而不是刚好到这里)

公式:   开始复制的地址 = 泄露的内核地址 - 0xC +1 - 0x15c  =    泄露的地址-0xC-0x15b

由于要覆盖 POOL_HEADER + OBJECT_HEADER_QUOTA_INFO + OBJECT_HEADER（中的TypeIndex） ，计算大小为 0x23个字节， 因此需要构造UserBuffer最后0x23 个字节。

代码见附件1

五、 BUG调试

刚开始我的代码是构造了一个裸函数来进行残根函数调用，但是总是堆栈总是会少一个值，需要自己push一下，才可以堆栈平衡。这是因为裸函数外部也会实现一个 add esp,4。

后来我也尝试了一下b2ahex的方法，但是发现他会push两次，比较好奇，我尝试了push一次，那么就直接BSOD。为什么会导致这个问题呢？其实可以通过分析系统写的函数来观察这个堆栈。

以ZwOpenProcess为例：

堆栈是这样的：

但是如果少压入一个值的话，堆栈就会变成：

其实这样的堆栈只会影响R0拷贝R3的参数：

在KiFastCallEntry的时候会将参数拷贝过去，但是会从残根函数返回地址+8（esp）的位置进行拷贝，如果我们不压入一个值，那么拷贝的就是随机值，就会导致蓝屏。

验证这个结论：

这是拷贝一个参数的过程。

从下图可以看出来，esp+8，才等于参数。

从上面的KiFastSystemCall函数可以看出，进入内核给edx备份一下esp,方便后续使用edx进行拷贝参数。此时的esp指向残根函数的返回地址。

通过分析，我们会发现进行拷贝的时候会将edx+8，这也告诉我们微软在设计的时候，就指定了R3进入内核前存放参数的位置。

通过源码再探池管理机制

如果想了解内核池的管理和分配，那么就要分析一下InitializePool、MiAllocatePoolPages和ExAllocatePoolWithTag的函数了。

由于ExAllocatePoolWithTag比较长，后续给出完整的流程。这个函数主要就是网上写的分配的流程，先从Lookaside、再ListHead，其次才分配大页。

先看InitializePool初始化池的函数。

此函数为指定的池类型初始化池描述符。一旦初始化，该池可用于分配和释放。

在系统初始化期间，应针对每种基本池类型调用一次此函数。

每个池描述符包含一个用于空闲块的列表头数组。每个列表头保存的块是POOL_BLOCK_SIZE的倍数。列表[0]上的第一个元素将大小为POOL_BLOCK_SIZE的空闲条目链接在一起，第二个元素[1]将POOL_BLOCK_SIZE * 2，第三个POOL_BLOCK_SIZE * 3等的条目链接在一起，最多可容纳一个页面的块数。

首先会计算PoolTrackTableSize的大小，获取的办法有两种，一种是注册表指定，一种是使用默认的值。

计算完大小后，就为其分配内存空间。

其次会使用Hash算法为这块内存初始化tag标签。

接下来，使用同样的算法，申请PoolBigPageTable表，PoolBigPageTable申请后，会有一个初始化过程。也就是将其中va成员置为0x1，以表示空闲。

其次插入到PoolTrackTable中，这个表通过分析，其实就是用来记录非分页和分页池的使用情况。也可以通过结构观察到其用途。

最后一步就是初始化非分页池的描述符，用来管理非分页池的使用情况。

总结一下：

InitializePool函数就是先初始化了一个空间用来管理各种池的分配情况，接下来就是初始化了PoolBigPageTable结构，最后就是初始化了非分页的描述符。PoolBigPageTable结构的用途目前还不清楚。

MiAllocatePoolPages函数的分析：

这个函数主要是用来分配池页面的。

首先会对输入的大小进行向上取整并+1。

BASE_POOL_TYPE_MASK  = 1，说明了 0 和 1才是基础的池类型，同时也验证，只有非分页池和分页池才是基础类型。

当要分配的页面小于1（页）时，首先是从单链表中获取。

如果需要的空间 大于4096（1页），那么就在空闲的非分页池链表中分配，

MmNonPagedPoolFreeListHead链表有四个，要从哪个链表中开始分配是由 需要的页数决定的。（注意：这里是开始分配）

找到指定的链表后，判断其大小，如果满足就开始进行分配

得出的结构就是 这个池的 开始地址为 0x825c900。

从这个算法可以看出，池页面是从最后一个地址开始分配的（也可以反向推导），分配完之后有一个摘链和插链的操作。这一步操作其实是调整链表，因为4个链表是1、2、3为同一个类型，分配对应的大小，当大于等于4时，就会从最后一个链表分配。所以有种情况就是当第4个链表分配后所剩的页数不足4页时，那么就要将其插入到前面的三个链表中。

分配完毕后，调整一下记录空闲非分页池的全局变量。

虚拟地址分配了也要在物理地址（PFN）标识一下，这里可以看出在PFN中标识了起始分配置位，以及结束分配位置。

总结一下：

MiAllocatePoolPages函数就是找到空闲的结点，通过这结点计算分配的位置，最后在物理地址（PFN）上标记一下。

阅读原文

跳转微信打开

一、 概述 1．CVE-2018-8120 是通过一个空指针解引用达到任意读写的漏洞。其实个人感觉单凭空指针

一、 概述

1．CVE-2018-8120 是通过一个空指针解引用达到任意读写的漏洞。其实个人感觉单凭空指针 解引用的危害就是 BSOD，但是利用方面还是要配合任意读写漏洞，如果单纯的只是 BSOD 那可能充其量算一个 BUG，但是如果能配合任意读写（全称：Write What Where）那么才算 是漏洞。通过思考得出的结论就是漏洞 = BUG+利用。

二、 初识空指针解引用 

1．空指针解引用的伪代码 （1）解引用，顾名思义，其实就是对一个指针进行访问其中的值，那么空指针解引用就代 表了这个指针是 NULL，所以伪代码如下：

（2）用户层 如果这段代码身处在用户层环境，那么就是访问异常，0xC0000005 错误，这是因为操 作系统的顶层异常替我们处理了，所以只会弹出来错误对话框显示出错误码。

（3）内核层 如果这段代码身处在内核层环境，那么就会直接 BSOD，因为操作系统在派发两次异常 后发现没有人能处理，那么直接蓝屏。这也体现了操作系统对于内核层的容错性很低。

（4）0xC0000005 或 BSOD 原因 这是因为 NULL 处的地址并没有进行挂 PTE，只是单纯了挂了 PDE（如下图），简而言 之就是没有对应的物理页。此处让我想起了操作系统划分地址空间的时候，都是将虚拟地址 当做是空头支票，实际干活的时候还是得靠物理地址。

2．空指针解引用到任意读写

（1）空指针解引用到任意读写的这一步，就是锦上添花扩大战果的一步。如果从空指针解引用这一句代码为分界线，那么此前的很多代码就是造成空指针的原因，此后的代码就是是 否能够任意读写的关键（这里有点不严谨，因为还要看是否有可控的元素）。

三、 通过 HEVD 看空指针解引用

因为不太懂得漏洞什么，所以先挑选一个比较简单的漏洞环境来进行探一探究竟。这 有点初时不识君难免有些羞涩的味道。

1. 源码角度分析

(1) 漏洞的成因 漏洞原因就是没有对申请的结构体 NullPointerDereference 判断是否为 NULL，直接调用 了其中的函数。

(2) 利用分析 

我们已经知道了漏洞的原因是直接对一空指针进行解引用，并且利用了空指针进行了一 个函数的调用。那么我们让此处的空指针变成不是名义上空的指针，并且在该指针调用的函 数偏移处进行放置我们的 shellcode，那么达到漏洞利用的效果。

1. 申请 0 地址页面内存 调用 NTDLL.NtAllocateVirtualMemory 函数进行为地址为 1 的位置申请内存，为什么不直接写 0 呢？这是如果写 0 的话就由系统确定你的内存从哪里开始申请。如果写 别的值，那么这个函数内部会自动向下取整一个页面大小。

这也就说明了我们写 0x1-0xFFF，都会帮我们分配到 0-0xFFF 这个虚拟地址空间的 内存。其次要想这个函数真正内部做了什么东西（以后详细分析，这里简述）。其实这个函数并没有直接帮我们申请到物理页面，我们通过可以分析后可知，这个函数调用完之后，并没有帮我们挂上PTE，那么它到底做了什么呢？其实它只是帮我们申请了虚拟地 址，也在虚拟内存中申请一个 VAD 来保留一段空间。当我们真正使用的时候操作系统 才会帮我们挂上物理页面。

2. 在特定位置放置 shellcode 这一步，其实就是挂上了 PTE，并在调用的函数偏移处写上我们 shellcode 的地址。

3. 提权代码 

提权代码，其实就是将 system 系统进程的 token 令牌替换到我们进程中的 token 结构体中，这种就间接的提升了权限。（这里是操作系统的安全机制，目前不是很了解）

现在对空指针解引用有了初步的了解，当时觉得算是理解了，分析了CVE 后，发现自己以为的真的是自己以为的，这大概就是理想与现实吧！接下来看看 CVE 的分析。

四、 CVE-2018-8120 分析 

1. 定位漏洞位置通过对比补丁前后，查看漏洞所在位置。

（可以使用工具BinDiff 或者Diaphora 来对比分析),这里就直接查看漏洞函数 win32k!SetImeInfoEx。打补丁前：

打补丁后：

2. 漏洞的原因分析 接下来从如下几个角度进行审视，进而确定它为漏洞而不是 Bug。

(1) 漏洞位置是否可控？这个自我感觉是很重要的，因为之前有点和 rootkit 混淆，漏洞是利用系统留给用 户的接口来进行攻击，有点像用正当的手法做最不正当的事情，而 rootkit 这种就是大 肆的破坏。通过使用 IDA 对 SetImeInfoEx 函数进行交叉引用后，会发现第一个参数是来自于 NtUserSetImeInfoEx 函数中的 GetProcessWindowStation 函数的返回值，因此这个值是可控的。

(2) 是否可以扩大影响？对于扩大影响，我们则需要查看 SetImeInfoEx 这个函数的漏洞点以下的部分。通过查看，我们发现了此处有个 qmemcpy 函数，并且目的参数与漏洞点的指针有些间接的关系，如果可以控制这个位置，那么就可以达到任意读写从而使其 bug 变为漏洞。

(3) 为什么会存在这样的问题？站在代码编写的角度来想，编写者可以潜意识的认为这个地址不可能为 NULL，所以没 有进行更深层次的检验。这可能是因为是结构与代码组合时，没有想到过多个 WindowStation 的问题，因为我查看了当前桌面的 WindowStation，发现它并不是为 NULL，但是如果是新建 一个，默认是为 NULL 的。 

3. 漏洞的 POC 编写 

(1) 分析用户层到漏洞点的路径 通过 IDA 一路交叉引用，找到最终的 Nt 开头的函数，它的执行路径如下：Ntdll!NtUserSetImeInfoEx --> Win32k!NtUserSetImeInfoEx --> Win32k!SetImeInfoEx

(2) 代码编写

1. 创建自己的 WindowStation，并且查看（tagWINDOWSTATION*）pwinsta->spklList 是否为 NULL。通过调用 CreateWindowStationA 创建的 WindowStation，pwinsta->spklList 默认是为 NULL。

2. 调用 Ntdll!NtUserSetImeInfoEx，这一步，我们可以模仿 NTDLL 中的残根函数写法，自己调用。完整代码如下：

4. 漏洞的利用编写 POC 的编写是研究如何走到漏洞点，exploit 的编写是从漏洞点如何走下去。

(1) 分析当前可利用的区域

通过查看 qmemcpy 第一个参数的来源，我们发现它来自于 v3 的一个指针，由此可知 ，我们可控的区域就是 4 个字节，控制了这 4 个字节，就可以进行任意的读写。

(2) 如何利用这个区域 1 池喷（Pool Spraying）的可行性。查看 qmemcpy 的第一个参数，可以发现该地址是位于内存池的，因此，我们可以通过池喷射的技术来利用漏洞。

可以发现这个地址来自于池里面，所以我们利用池喷进行内存句柄，进而控制住指针。

2. 池喷射

先研究一下池喷射，这个就根据 HEVD 的池溢出漏洞来进行研究。

1) 漏洞点构造

2) 临界值观察 a. 首先我们将利用的代码中 Size 修改为和缓冲区刚刚好的大小。查看 一下池的布局。这里设置为 0x1F8 个字节。

为什么上面的设定是 0x1F8 个字节呢？而不是别的。这是因为_POOL_HEAD 占 8 个 字节，所以总共加起来刚好 0x200 个字节，够一个 Lookaside 中的大小。 

接下来，查看一下 pool 的布局，通过查看会发现如果用户输入的大小超过 0x1f8， 那么就会覆盖掉下一个池头。

3) 寻找利用点 a. 由上面可知，可以控制溢出到池头，那么必然我们的利用点得利用池 头中的某些成员来进行控制EIP。

通过查看，池头部和池配额结构体，都没有发现可以利用地方，但是考虑到这是非分页池，那么里面就存放了很多内核对象结构体。（这里思考的比较久，已经看很多网上的文章都是一路 dt 下去，找到了内核对象，都没有说这块内存是用来干嘛的。那是 不是如果是非分页池了，就不能这么使用了。）

于是我们可以尝试探索一下，查看里面是不是存放的是内核对象，由于某一个内核 对象都会有一个头部（_OBJECT_HEADER），所以可以试探性的搜寻是否可以找到对应的 BODY。

这也就是为什么国外的文章，直接使用 dt _OBJECT_HEADER 这个地址。

是不是内核对象，还得在通过其中的 TypeIndex 来进行验证。操作系统将所有的内核对 象定义成了一个全局数组 nt!ObTypeIndexTable，而 TypeIndex 就是数组的索引。这个数组的类型是 OBJECT_TYPE 类型，如果这个索引可以到这个数组中寻找到，那么必然是内核对象。

查看对象模板中的 _OBJECT_TYPE_INITIALIZER，会发现很多回调函数，都可以进行利用， 但是最好利用应该就是 CloseProcedure 了，只需要通过调用 closeHandle 函数来触发。

4) 内存布局 内存布局的话，可以通过申请大量的内核对象，这里选择的 Event 对象，这个 和这个对象的大小刚好为 0x40 个字节（释放 8 个就是 0x200），申请大量的 Event 对象将 Lookaside 和 ListHeads 占用了，然后通过申请新页来分配内存， 进而释放内存的时候可以进行合并成想要的大小。（因为分配 Pool 内存的时 候循序为，lookaside-->ListHeads -->申请新页）

这个漏洞可以利用的关键点还在于 Win7 系统可以申请 NULL 页面。所以将 TypeIndex 修改为 0（溢出的位置），然后将 NULL 页面 +0x60 偏移处修改为 shellcode 的位置，就可以在 CloseHandle 的时候触发 shellcode 代码。5) 攻击过程综述 a. 进行内存布局，制造出 0x200 的空隙，控制位置

b. 申请 0 页面，构造shellcode

c. 触发

3 研究 Bitmap 布局的可行性。

阅读原文

跳转微信打开

今天天空阴沉沉的，还下了点小雨，我坐在公司天台的秋千上，抽着烟思考着人生。正在这时，手机响了一下，我拿起手机

今天天空阴沉沉的，还下了点小雨，我坐在公司天台的秋千上，抽着烟思考着人生。正在这时，手机响了一下，我拿起手机晃了一眼，啥东西？

  定眼一看，原来是一条只有一个网址的短信，以我这个安全从业多年的经验来看，肯定又是啥钓鱼短信，人生等会来思考，我现在只想看看钓鱼者是怎么套路我的，想到这里，我的嘴角开始露出邪恶的笑容。

揭开盖头

   打开网址后, 透过我有点反光的手机屏幕看到的是一个贷款app的下载页面，几个大字把我震的一愣一愣的，蚂蚁借呗？

   这个APP不会是想盗取我的支付宝账号，然后继承我那500块限额的蚂蚁花呗？

烟抽完了，回去打开电脑，输入页面下面的那个链接。

打开后发现，这个CMS有那么一点点眼熟，于是乎做了个指纹验证，然后百度一圈搜搜CMS的漏洞，无果！

   遂到官网下载此套CMS进行审计，什么，下载要钱？？

 我看了看桌子上早上没吃完还剩下的半个馒头，不禁心里一酸。

   算了，算了，这年头干啥都要钱，看看网上有没有乞丐版本。

   在网上搜了一圈，老天还是挺好的，给了我一条明路，把这套CMS下载回来后，召集小伙伴并拿出我久经考验的审计专用IDE开始干活。

   先找找入口点，全局处理什么的。

   这里可以看到它定义了一个方法来处理get、post、cookie的相关请求

返回数据时经过了format_param函数,我们跟进format_param函数。

在format_param函数里面我们看见了一大堆过滤，仔细看看int类型直接返回,输入字符串转实体化然后加\，下面每一种类型都有对应的处理方法

那么这样的话，就有点难办了，虽然俗话说的好“世上无难事，只要肯放弃”，但是我们还是要试试，万一呢？先抽根烟稳定一下情绪。

在漫长的寻找过程中,我们发现了一处可疑的地方，这里可控的参数没单引号包裹,然后我们就可以闭合)去注入了

在这个文件里面，我们又发现了,这里完全没有走format_param函数方法，在跟进数据库操作find()方法函数里面也是一样，没有任何的处理，直接进行了相关参数的一个拼接，所以注入点理论上是成立的了。

那么，实践是检验真理的唯一标准，本地搭建此套CMS系统,构造POC，去吧，皮卡丘。可以看到没问题，成功利用。

这下拿着POC到那个钓鱼网站试试效果。

动作要快，姿势要帅。额........没反应？

经过和官网目录核对，嗯... 我可能下错CMS了，跑偏了。

所以啊，指纹识别有时候也是不靠谱的，正所谓“尽信书，不如无书”。

通过长时间的寻找，终于还是找到了。

这个CMS目录简单，直接看看吧，几分钟后，我们发现了一个后门文件，这cms里后门太明显了，果然干这行的，都喜欢黑吃黑。

那么，我们也就不费劲去找啥0day了，直接进吧。

进入大马后发现大马的权限很低,并且Linux localhost.localdomain 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64,并不好提权，因为我连执行权限都没有（命令函数都被禁了）。

拿了密码进入后台后看见安装量还有点多诶,并且这后台只是一个分发系统,不是真正的app数据管理系统,故放弃提这台服务器，提了也没啥用。

正当无计可施之时，我们想到了APT攻击。

既然服务器我们没办法，那我们就直接搞管理员？用之前看见比较火的Flash更新钓鱼(既然你钓鱼我，那么我也来钓鱼你，礼尚往来），对远控进行免杀捆绑。

免杀伪装步骤：

1） 免杀远控

2） 捆绑工具

3） 图标提取(从flash原版程序提取图标资源)

4） 制作捆绑伪装

直接提取图标版权内容，稍后用作捆绑，版权信息可以捆绑完以后在加到exe上这样捆绑完成后比较完美，还可以把原版flash程序数字签名一同复制到捆绑程序上就完成

在网上随便下的的一个捆绑工具用做木马捆绑

下一步就是让目标运行咱们这个独家定制的flash更新程序了。。。。。。。

钓鱼肯定需要伪装，于是我们克隆了一个Flash官网页面，并注册了一个和flash官网差不多的域名，漂漂亮亮的把咱的独家定制小玩意放上去。

接下来呢，我们在后台登录文件里写个跳转代码。

之前想过写在前台的，想了一下，这样不就暴露了么，还会钓到很多无用用户回来，于是乎，后台一般只有管理员会来看，所以这样就比较目标精确了。

插入了跳转代码后测试一下，OK，有那么一点小完美。

吃完午饭回来一看，嗯，运气不错鱼上钩了。

成功获取到目标的PC权限。

事情都走到这一步了，顺便翻了一下他的电脑，在翻看他电脑的时候我们发现了一个秘密。

那就是那个手机短信里的那个站根本不是钓鱼站，之前我们还以为这个站就是套取个人信息或者盗号的那一套玩意，没有想到，事情远远比我们想象中的还要复杂和严重的多，一切似乎变得有意思了起来，于是乎，我们打算长期潜伏并监视此团伙。

水落石出

我们翻看了此团伙的电脑后，发现了一些重要的东西。

在下面的文档中我们可以看到，他们是一个做假贷的网站，这个文档里面包含了他们的一些话术，也就是对每一种情况，他们都有相应的应对措施，

受害人在申请贷款后，骗子将会利用受害人的贷款心切心理，引导受害人交钱。

利用平台套取受害人的相关个人信息

找到了他们的其他站点

随便找一个看看,居然还有人满意...... 

我们在其他的站点翻到了这个团伙的邮箱地址、手机号码及QQ号码

利用配置找到邮箱密码，登录之

这个邮箱绑定了服务器的主机和域名，那么，我们有个大胆的想法

我们登录域名服务器查看到了骗子的真实信息（不一定真实，伪真实）

查看下联系地址是什么地方的

厉害，这个地址也敢乱写，还有什么不敢的

单看这些东西也不行啊，我们打算直接进内网看看，直接上隧道，加个代理直进内网。

进入内网发现，都是个人PC电脑，不好搞啊，那么还是先用ms17010扫一遍。扫完后发现，好多都打不了，即使成功了，也无法返回链接，额，不用说了肯定蓝屏了，所以算了，动静小点

那就抓个密码吧，发现密码为空，而且之前拿了几台都一样，所以可以肯定的是，内网中大部分或者全部都没有密码，而且都是用的WIN7，即使开了3389也不敢连，会被挤掉

所以还是先从已经拿下的这台电脑入手吧，先截一个图先，发现还在使用

这个时候我们查看进程，在进程中发现teamview的存在，那么就直接上teamview密码抓取工具，抓到密码后，等待一个夜深人静的时候，观察到没有动静了后开始干活。

连上后，发现QQ还是登上的，看一下聊了些啥

为了尽可能的在服务器上停留时间短，我们把几个人聊天记录导出到本地观看，以免被发觉

,从他们的聊天记录看，他们这个所谓的贷款平台就是赤裸裸的诈骗

从这个电脑上，我们登录上了阿里云服务器

查到了个人信息

**印河北省**县*******90号

这个信息也不一定就是真的

通过他们的聊天记录，我们掌握了他们所有平台的账号密码，下面来梳理一下这个团伙的分工及套路

团伙采取公司化运作，下设客户经理、话务组、业务组等。诈骗模式为，先由话务员电话,短信方式招揽需要贷款的受害人， 再由业务员与受害人联系，让受害人下载所谓的放贷APP，在这个虚假APP平台中，要求受害人按流程操作并先交纳10%的手续费才能贷款，受害人一旦 转账，便以各种理由推脱，不予放贷。

阅读原文

跳转微信打开

首先我们登陆抓个包,可以发现有一个sign签名认证,在app与服务端接口安全的问题上,sign是一个很好的办

首先我们登陆抓个包,可以发现有一个sign签名认证,在app与服务端接口安全的问题上,sign是一个很好的办法来保证安全性。

服务端会根据客户端的加密方式，得到一个sign(签名)，和客户端传过来的参数做对比一样就继续下面的数据调用，错误就直接结束程序,所以中间改了数据包的话,服务端是直接给你数据包结束掉的。

   Sign原理：用户登录后向服务器提供用户认证信息（如账户和密码），服务器认证完后给客户端返回一个Token令牌，用户再次获取信息时，带上此令牌，如果令牌正确，则返回数据。

0x1 Java层分析

那么我们反编译该APP，通过搜索字符串、查找相关函数，最终定位到sign数据包的相关代码段，分析它是如何处理传参并生成最终的sign值。

跟进第一个i0.a, 静态我们可以看出,它是将传进的参数进行了MD5的一次加密,

我们在它传参进来明文处下断点,再将加密返回后下个断

开始调试,获取明文

单步调试到返回密文

返回的密文确实是经过MD5加密一次,但是和篇头抓包的sign差了最后八位,

之前分析是进了两次方法,我们继续跟进

0x2  JNI层代码分析

跟进之前的sign可以看见，数据以参数形式传入了getEncryptDeviceId方法

跳转到该方法的定义处，可以发现getEncryptDeviceId方法是由native标识符修饰的JNI层函数

JNI函数具体定义在哪一个so文件中，可以通过查看相关的loadLibrary操作

打开libcryp.so文件，通过其导出表找到getEncryptDeviceId方法的实现。

(对于命名规范的android JNI层函数，都是以"Java_包名_类名_方法名"的格式来命名的，若要分析的目标方法没有按照命名规范，就要涉及到android中的JNI_OnLoad以及JNI函数的动态注册机制了，这里不过多解释。)

跟进到该方法,可以静态分析到它的算法,如下

这里我将该伪C代码翻译为JS代码后,成功得到后八位

至此我们的分析出来的sign就是 18c93acf307b0ba142df393b9722b0d112351f2d

与篇头抓包的sign相同,至此已经清楚的分析出了该sign加密的流程方式

阅读原文

跳转微信打开

好久没清理qq好友了,也不知道你过得好不好,反正你肯定是被盗了,我也不打王者荣耀干嘛发给我呢?打开这个网址扫

好久没清理qq好友了,也不知道你过得好不好,反正你肯定是被盗了,

我也不打王者荣耀干嘛发给我呢?

打开这个网址扫下目录就扫到了后台,本来盲打了一个xss可是半天没反应,看着是asp的这么简陋,试试万能密钥一下,还就进去了

进来了发现还有号码还躺在里面......

进是进来了,不能这么算了,扒下信息吧,登陆框都有万能密钥那后台里肯定到处都是注入,但是access数据库我这跑不出来,再扫扫目录吧,发现一个mdb目录

访问这个目录,还有目录遍历....还使用的简易服务器工具,心可真大,直接下数据库看看

打开数据库,发现mail字段还拿qq邮箱.....

搜索引擎了一通什么收录都没看见, 然后呢看了一下这个qq资料,原来还有旗下网站,业务有点广的嘛...

打开一个还卖吃鸡辅助的噢,真是业务广

随手一个robots,太不长心眼了,xiaocms和后台都出来了

根据后台实锤就是这套cms了

于是去官网下来了这一套cms,看看能不能拿吧,这套cms对get,post做了html实体化

并且有个安全函数

并且对这些个超全局变量做了过滤

然后使用了pdo预编译，只能看看被pdo照顾不到的地方,经多次观察...

终于我还是放弃了前台,还是看看后台吧,这有个注入,并且支持pdo,多语句的话,进去是可以拿shell的

还有任意文件上传,type和size都可控,这也可以拿shell的

还有任意目录删除

但是我进不了后台啊..... 咋办呢

挠挠头，点起一根香烟，想想这小子，从钓鱼站开始就是很不严谨，爱使用一键化，robots默认的都没有删除过， 那么这个站是Windows的，十有八九他用phpstduy搭建的，试试?

猜对了，还真有，dir找到网站目录了，

往里面echo一句话，菜刀连接，08的还没一个杀软，直接烂土豆上去提权

服务器逛了一圈，并没有发现有关于这人的资料信息啥的，白来一圈，

我还是得打到他PC才有办法搞点事情

于是就仿了个这页面

三个浏览器我都和我的免杀捆绑起来，随便挑一个你都得遭

专为目标制作的木马捆绑程序，三个只要任意执行一个就会上线，直接在浏览器图标上做了一个下载链接，在后台登录代码里插入跳转代码，跳转代码通过cookie来判断，如果TZ这个cookie值为空就跳转 ，如果跳转过就在浏览器里添加一个TZ cookie 避免每次都跳转。

当目标打开网站后台时候直接跳转升级浏览器页面，他会点击更新程序下载图标，下载了我加工的更新程序自然而然便会感染我的大MA，哈哈哈这样目标就打回来了，做好水坑攻击以后便是长时间的耐性等待。

经过漫长的等待目标终于上线了，虽然这次钓鱼等待时间过长不过好在还是拿到了目标，既然CS已经上线先简单看下目标就可以进一步对目标渗透了。

通过对数据的分析发现目标还有不少傻瓜中招，被钓鱼网站钓鱼。

不过，我还是逛了一圈没有发现这个人的啥信息，全是别人的，难道这台电脑只是他搞这些用的，平常不拿来打游戏，上网啥的？

看来还是得想点其他招了，我去下了他的和平精英除草，app需要卡密激活才能使用

将他的app里注入一个shell，安装后就弹回

加上他的qq，我购买了卡密，但是app安装上去卡密激活不了，诱使他安装一下

我当然知道要联网，不然你怎么能上线

翻一翻手机

看看他的手机信息，拿到手机号了，浙江人，魅族手机

看看短信,这里已经掌握了他家具体位置了

找这个勤奋小伙聊聊天~

他不知道我是什么人，直接问我是不是jc，我对他信息的掌握都是真实的，一步步逼问他，

当自己的生活和所做的不正当的事情曝光，内心承受的压力是很大的。

说完之后我发现我的好友列表已经没了他，再添加也不给任何回应

他到底怎么选择我也不得而知，即使关站那也可能不会结束

希望他的选择是正确的

好运和幸福只会降临在，当你开始为自己的未来一步一步脚踏实地的操作时。

阅读原文

跳转微信打开