ZIKH26's Blog

前言

博客很久没有更新了，其实也写了很多 IOT 研究的文章，但因为保密不能公开。而本文写的是最近几天在搭建 QEMU 下 ARM Linux 运行环境的过程，这方面网上的文章比较多，没有什么保密性可言。

本文记录了交叉编译 Linux 内核、BusyBox 以及制作虚拟存储介质的过程。旨在根据不同设备的内核版本，搭建出一套匹配内核版本的 QEMU 仿真环境。之前研究几款路由器设备都是 2.6x 版本的 ARM 内核。使用 18.04 上安装的交叉编译工具链去编译的程序，在这种 2.6x 老内核中运行会报错 kernel too old。如果想编译一套相应的研究工具（如 gdbserver、ptrace、ltrace、小型反弹木马等等）会很麻烦，包括一些测试场景，可能会因为内核版本差异较大，产生一些异常。

因为网上有很多相关文章（大部分都是搞嵌入式的老哥写的），本文只是对自己学习这部分做一个记录和总结，帮助自己之后可以根据不同的研究需求去搭建特定环境。之前搞 IOT 仿真的时候，用的都是这个 编译好的配套环境，看完本文后，应该就能自己搞一套 QEMU 环境了😋。

本文记录了下面部分内容。

1. 配置交叉编译环境
2. 交叉编译 ARM Linux 4.1x 内核
3. 交叉编译 busybox
4. 构建磁盘文件镜像
5. 将 01-03 的产物成功用 QEMU 运行起虚拟机
6. 实现 QEMU 虚拟机的网络通信

前言

这是我收获的第一个 CVE 编号，在复现了 winmt 师傅的 CVE-2023-34644 后，他告诉我最新的固件虽然做了一些简单的处理，导致无法在未授权的情况下 RCE ，但因为没有从根源上对命令执行点做限制，所以在授权后，仍然可以进行 RCE 。我对最新的固件进行了分析，完整记录了授权后的 RCE 漏洞从分析到利用的过程。从提交漏洞到现在也有半年的时间了，并且锐捷官网也已经发布了最新的固件，现将该文章分享出来，供大家进行学习和研究。

已经配置好的环境：下载链接 (使用方法：先执行 net.sh 再运行 start.sh 即可)

参考文章：Building a Debian Bullseye QEMU image for AARCH64 | diozero

大概思路：先下载安装程序的基本文件，联网安装完之后从磁盘文件中提取出需要的 initrd.img 和 vmlinuz 文件。 QEMU 依赖提取的文件构建出 aarch64 环境。

前言

这是一道来自于 第六届强网拟态线下赛 有趣的 PWN 题，考察的是格式化字符串漏洞。我自认为格式化字符串的题目已经很熟练了，可在我的印象中格式化字符串漏洞无法一次向一个不存在的指针中写入数据，这道题颠覆了我的认知🥲。保护全开，只有一次 非栈上 格式化字符串漏洞利用的机会，之后触发 _exit 函数退出，唯一的信息是有栈地址末尾的两个字节。这可能是格式化字符串能利用的极限条件？！😶‍🌫️

前言

针对 TP-Link SR20 做漏洞复现的时候，学习到了 C 程序调用 lua 文件所造成的命令执行漏洞，同时该路由器还存在一个命令注入的点。TDDP 是 TP-LINK 在 UDP 通信基础上设计的一种调试协议，当 TP-Link SR20 运行了 V1 版本的 TDDP 协议，在无需认证的情况下，往 SR20 设备的 UDP 1040 端口发送特定数据就可以造成命令注入漏洞或利用 TFTP 服务下载指定 LUA 文件并以 root 权限将其执行。还好这个协议的逆向量挺小的 😶‍🌫️

前言

跟着 winmt 师傅的私房笔记做了一个 D-Link 的命令注入漏洞复现（ CNVD-2018-01084），由于前一段做了一个 CVE-2018-7034复现–TrendNet路由器登录信息泄露 ，那个固件当时进行了仔细分析，而这次的 DIR-815 和 TrendNet 里的 cgibin 几乎一致 ，因此只针对漏洞利用部分进行了详细分析。

前言

本文记录了一次失败的漏洞挖掘经历，但正是因为自己都在进行主观的思考，即使是失败了，这一次也学到了一些东西。我认为跟着别人文章照猫画虎成功做一遍，不如失败的独立思考探索有意义😎

前言

该漏洞的利用是通过发送 POST 报文在正常字段 SERVICES=DEVICE.ACCOUNT 后紧跟了一个 AUTHORIZED_GROUP=1 （二者用 %0a 连接），导致 cgibin 文件解析时先识别到了第一个 = ，认为 SERVICES 是键，DEVICE.ACCOUNT%0aAUTHORIZED_GROUP=1 是值。随后又对字符串进行解码，%0a 处理为 \n，此时内存中字符串为 _POST_SERVICES=DEVICE.ACCOUNT\nAUTHORIZED_GROUP=1 ，后续在 cgibin 中认证失败，在此基础上添加了 AUTHORIZED_GROUP=-1 。

之后把整个数据发送给 php 文件进行处理， getcfg.php 文件中if($AUTHORIZED_GROUP < 0) 获取字段值时，首先解析到的是 AUTHORIZED_GROUP=1 从而通过了验证。又因为可以加载 htdocs/webinc/getcfg 目录下的任意文件，最终造成敏感文件的信息泄露

前言

本文对 CVE-2017-17215 的复现过程进行了记录，该漏洞位于华为 HG532 路由器，在 UPnP 服务中存在 NewStatusURL 和 NewDownloadURL 标签中的命令注入。通过向端口 37215 ，地址为 /ctrlt/DeviceUpgrade_1 发送 POST 报文进行漏洞的触发。整体而言，这个漏洞确实是目前复现过最简单的了，但自己在做的时候依然踩了一些坑…😅

这道所谓的工控题目其实就是一道CTF的流量分析+逆向的迷宫题。鉴于是第一次认真复现和总结流量分析和逆向的题目，感觉学到了不少东西，写篇博客记录一下。