TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)

关于错误

CVE-2022-24355 允许网络相邻攻击者在受影响的 TP-Link TL-WR940N 路由器装置上执行恣意代码。应用此破绽不需求身份考证。该特定缺陷存在于文件扩展名的解析中。该问题是由于在将用户提供的数据复制到固定长度的基于堆栈的缓冲区之前缺乏对长度的正确考证。攻击者能够应用此破绽在 root 上下文中执行代码。( www.zerodayinitiative.com )

图片[1]-TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)-孤勇者社区

阅读描绘后,我以为该错误相似于常见的缓冲区溢出,它是经过发送对具有很长文件扩展名的文件的恳求(例如,index.aaaa ……….aaaa)触发的。但是,这种状况是不同的。
 


 

重新创立错误

从名为httpd()的 init 函数中,要使程序调用httpRpmFs()函数,恳求 url 必需包含“/fs/”或“/loginFs/”。

图片[2]-TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)-孤勇者社区

此外,恳求中的referer ip 必需等于host ip 才干经过httpDispatcher()函数中的平安检查。

图片[3]-TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)-孤勇者社区

如今,关于易受攻击的函数,httpRpmFs()用于读取和响应恳求文件的内容,假如它存在于 /tmp/ 或 /web/ 文件夹中。

图片[4]-TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)-孤勇者社区

起初,我以为缺陷是strcat(v2, v3)但是,v2和v3都是分配的并且仅在堆上运用。因而,我尝试将此httpRpmFs()与固定的停止比拟。它们根本相同,只是假如您想读取 /tmp/ 文件夹中的文件,则需求停止新的平安检查。

图片[5]-TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)-孤勇者社区

依据该线索,我提出了几个读取 /tmp/ 中每个文件的恳求,最后,当我尝试读取名为passwd的文件时,它解体了。查看调试器,恳求的一局部被写入堆栈并招致溢出。

图片[6]-TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)-孤勇者社区

让我们回到代码,看看这是怎样发作的。在htttpRpmFs()函数中,胜利读取文件后,程序将做出包含该文件内容的响应。

调用函数sub_5299E0()以检测与文件扩展名匹配的响应的 Content-Type。这是溢出开端的中央

图片[7]-TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)-孤勇者社区

函数sub_5299E0()经过创立指向文件途径末尾的指针来查找文件扩展名。之后,该点将向后挪动,直到与“。”相遇。特性。最后,sub_5299E0()将复制 '.' 之后的一切字符。字符一个接一个,直到它遇到空字节。复制的字符将更改为上键并保管到堆栈中。在我们的例子中,passwd 没有文件扩展名,指针向后挪动,传送文件途径,抵达保管的恳求头区域,只要在遇到最后一个'.'时才中止。在Referer局部的IP地址中。结果,将其复制到堆栈并掩盖保管的存放器值之后的一切内容。在sub_5299E0()之后完成后,这些值被弹出回存放器并招致程序解体。

图片[8]-TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)-孤勇者社区

 


 

编写破绽

我没有实践的路由器,所以我运用固件剖析工具包来模仿固件。经过一番研讨,我发现路由器的 ASLR 默许是禁用的,所以我也在我的模仿器上禁用了 ASLR。由于程序没有维护,我将运用溢出错误将shellcode存储到堆栈中并运转它。

图片[9]-TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)-孤勇者社区

从上面的调试中,我创立了一个存储在恳求的 cookie 局部中的有效负载。有效载荷包含 16 字节缓冲区、指向 shellcode 的堆栈指针和 shellcode。

图片[10]-TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)-孤勇者社区

一切看起来都很圆满,我以为这很容易,但是该恳求只会使程序在没有任何外壳或衔接的状况下解体。我回去调试,发现问题出在toupper()函数上。shellcode 包含 0x61 到 0x7a 范围内的一些字节(ascii 中的“a”到“z”)。当经过toupper()函数(减去 0x20)时,这些字节将被更改,这会招致 shellcode 无法工作。

图片[11]-TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)-孤勇者社区

所以,我找到了一个绕过toupper()的处理计划,它在发送到路由器之前对 shellcode 停止编码。侥幸的是,pwntool 库针对这种状况有一个 XORencode 函数。但是,经过编码后,shellcode 依然有一个字节 0x70。

图片[12]-TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)-孤勇者社区

我试图反汇编 0x01c07027 并收到一条指令“ nor $t6, $t6, $zero ”。为了终止坏字节,我略微更改了编码的 shellcode。由于 $t1 存放器与 $t6 具有相同的用处,并且它没有在 shellcode 和编码中运用,因而我将 $t6 存放器交换为 $t1 并且坏字节消逝了。

图片[13]-TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)-孤勇者社区

此外,我理解到 MIPS 路由用具有缓存分歧性,可经过异步读取和写入主内存来进步内存访问速度。在堆栈缓冲区溢出用 shellcode 地址掩盖存储的返回地址后,处置器将执行定向到正确的位置,由于返回地址是数据。但是,它执行的是依然占用指令缓存的旧指令,而不是最近写入数据缓存的指令。为了使 shellcode 工作,我必需经过调用sleep()函数来刷新数据和指令缓存。我从旧的破绽应用代码 ( www.exploit-db.com/exploits/46678 )中借用了一个 ROPchain,并对其停止了一些修正以顺应我的状况。

图片[14]-TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)-孤勇者社区

该恳求还需求编辑以匹配新的有效负载。

图片[15]-TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)-孤勇者社区

最后,破绽应用完成并准备好运转。

图片[16]-TP-Link TL-WR940N:1day缓冲区溢出RCE漏洞分析(CVE-2022-24355)-孤勇者社区

------本页内容已结束,喜欢请分享------

感谢您的来访,获取更多精彩文章请收藏本站。

© 版权声明
THE END
喜欢就支持一下吧
点赞6赞赏 分享
评论 共2条
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片
    • 头像及三0
    • 头像卡卡0