[原创] 看雪KCTF2022秋季赛 第七题 广厦万间
20小时前 318
从附件所给的Readme以及IDA分析可以看出所给attachment是个xrdp-sesman
,版本为0.9.18。
1 2 3 4 5 6 7 8 9 10 |
|
直接googl xrdp rce,很容搜到 CVE-2022-23613,并且受影响的版本为0.9.18及以前,找到相关的patch commit:
再结合IDA分析所给attachment中的sesman_data_in
函数,没有size <= 8
的判断,显然是未patch的状态:
可以确定这题考察的就是CVE-2022-23613
的利用了。
从github上直接下0.9.18的源码,然后降级openssl,在本地编译一个xrdp,解决lib的问题,即可正常跑起来。
简单来说,xrdp-sesman
会在本地监听3350端口(/etc/xrdp/sesman.ini):
每次有一个socket连接进来,就会分配一个trans
结构体:
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 |
|
然后进行相应的初始化:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
简单来说,就是设置sockfd
,type1
,status
等,并且为in_s
和out_s
分配空间,记录client的ip address和port,后面就进入到server和client的socket通信逻辑中了。
在通信过程中,server端接收的数据包格式为:
1 |
|
因此接收一个完整的数据包过程分为两步,第一步接收8 bytes,然后根据size字段计算出后续payload的长度为(size - 8)
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 |
|
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 |
|
问题在于如果header的字段size < 8
,那么to_read
就会整数溢出。
且由于这里涉及的size都是符号整数,因此如果设置header_size = 0x80000000
,那么to_read = 0x80000000 - 8 = 0x7ffffff8
,从而导致heap-based OOB write。
由于每次连接,server端都会创建一个trans
结构体,因此可以创建多个连接,使得在self->in_s->end
后面喷上一堆trans
的结构体,且该结构体中有很多可以利用的成员,包括函数指针。
第一想法就是是否能够通过劫持trans
结构体完成地址泄露.
通过分析trans_check_wait_objs()
发现,server除了每次读完数据之后,还有一个额外的动作,即如果trans->wait_s
如果不为NULL的话,会把缓冲区中的数据发送给client。
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 |
|
虽然正常情况下,trans->wait_s = NULL
,但是可以通过OOB write对其进行劫持,设置trans->wait_s->p
和trans->wait_s->end
,就能把两者之间的数据发送给client。
但是这里存在一个问题,trans->wait_s
是一个struct stream *
:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
需要在某个地址已知的地方布置一个stream
结构体,然后再将trans->wait_s
劫持到这个结构体上才能达到目的。
此时由于binary没有PIE,唯一知道的地址就是程序的地址,因此我只能先构造出一个任意地址写的原语,在bss上伪造一个stream
结构体。
因此把目标选为trans->in_s
,这个stream
结构体存放server接收缓冲区的地址信息,根据self->trans_recv(self, self->in_s->end, to_read);
,self->in_s
是在堆上动态分配出来的,因此有可能可以通过OOB write将其劫持,实现任意地址写。
然而调试过程中发现,in_s
chunk总是落在trans
chunk之后,意味着在写到in_s
结构体之前,必然会先破坏trans
结构体。
因此这里需要进行堆风水,让in_s->end
跳过trans
结构体,落在in_s
上。
很自然的想法就是首先通过OOB write,将in_s->end
挪到trans + 0x20
的位置上,因为前0x20 bytes的内容都是已知的。
然后通过断开连接,将这个trans
给释放掉,这样继续OOB的时候,由于in_s->end
此时落在chunk + 0x20的位置,不会破坏free chunk的metadata,因此可以继续OOB write,让其很安全地跨过trans
结构体,落在in_s
前。
最后再进行连接,将这个trans
重新分配出来,这样再OOB write,就能劫持到in_s
结构体了。
不过需要注意的是,内存的分配都是通过g_malloc
进行的:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
虽然源码里都是malloc
,但是实际上g_malloc(xx, 0)
最后都被优化为calloc
,因为calloc
不会从tcache中分配chunk,因此这里还需要通过7次连接加断开将相应的tcache填满,才能使得后来释放的trans
能够重新分配回来。
这个阶段结束,就完成对trans->in_s
的劫持了:
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 |
|
之后通过conns[11]
(对应被劫持的trans
)发送数据给server,就能在0x410c00开始的位置布置数据了,即可以伪造任意的stream
的结构体。
为了完成地址泄露,还是需要回到劫持trans->wait_s
的路上去。
但是此时buffer指针已经落在trans
后面了,如果想要继续OOB write劫持后面的trans
结构体的话,会破坏堆上的free chunk。
因此只能将当前OOB write的trans
释放再重新取回,从而重置in_s->end
指针位置,使得其能够在不破坏chunk结构的情况下,劫持到trans->wait_s
。
目前为止,通过在bss上构造一个wait_s
结构体用来泄露got表,以及一个合法的in_s
保证劫持wait_s
的过程中程序的正常执行,即可完成对got表内容的泄露,从而获取到libc的地址。
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 |
|
最后一步显然就是通过劫持trans
中的函数指针来getshell了。
最直接的目标就是trans->trans_recv
,因为在调用trans->trans_recv
时,第三个参数为to_read
(edi
寄存器),它是由header_size
间接控制的,因此只要结合mov rsp, rdx; ret
的gadget,将栈迁移到bss上进行rop就行了。
至于ropchain,前面已经可以在bss上写数据了,因此布置一条rop链也就轻而易举了。
只要执行`system("/bin/sh 1>&7 0>&7")就可以愉快地getshell了。
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 |
|
整体来说堆布局还是比较稳定的,不过显然是一次性exp,第二次再打堆布局就变了,得重启靶机环境。