SSRF攻击实例解析

Posted 2021-09-06 Zeker62

普通版SSRF：

普通版版本的SSRF没有经过任何过滤
直接在请求的API中输入：

http://localhost/admin

比如：

stockApi=http://localhost/admin

Here, the server will fetch（获取） the contents（内容） of the /admin URL and return it to the user.

SSRF攻击后端系统：

SSRF攻击是操纵了服务器的权限，服务器存储于后端系统
我们可以用爆破的方法，爆破后端系统的IP地址，然后对其进行操作：
比如：

http://192.168.0.x/admin

是一个后端系统，但是x的值我们不知道，然后我们就可以进行爆破：
使用Python脚本先 生成一个0~255的字典：

def printnumber(path):
    with open(path,'a') as f:
        for i in range(0,256):
            f.write(str(i)+"\\n")
            
printnumber("a.txt")

然后将字典导入brupsuite，爆破即可。

规避常见的SSRF防御：

SSRF with blacklist-based（基于黑名单） input filters

Some applications block input containing hostnames（包含主机名） like 127.0.0.1 and localhost, or sensitive URLs like /admin. In this situation, you can often circumvent（绕过） the filter（过滤器） using various techniques:

• Using an alternative IP representation of 127.0.0.1, such as 2130706433, 017700000001（八进制）, or 127.1.
• Registering your own domain name that resolves to 127.0.0.1. You can use spoofed.burpcollaborator.net for this purpose（目的）.
• Obfuscating（混淆） blocked strings using URL encoding or case（大小写） variation（变化）.使用URL编码或大小写变化混淆被阻止的字符串

比如：当：

 http://127.0.0.1/

没有用的时候，可以变成

http://127.1/

当：

http://127.1/admin 

没有用的时候，可以尝试将a转码变成：%2561

http://127.1/%2561dmin 

即可

SSRF with whitelist-based（基于白名单） input filters

Some applications only allow input that matches, begins with, or contains, a whitelist of permitted values. In this situation, you can sometimes circumvent（绕过） the filter by exploiting inconsistencies（解析不一致性） in URL parsing（解析）。

The URL specification（规范） contains a number of features that are liable（可能） to be overlooked（忽略） when implementing（执行）parsing and validation of URLs:

• You can embed credentials（嵌入凭据） in a URL before the hostname, using the @ character. For example: https://expected-host@evil-host.
• You can use the # character to indicate（表示） a URL fragment（片段）. For example: https://evil-host#expected-host.
• You can leverage the DNS naming hierarchy（命名层次结构） to place required input into a fully-qualified DNS name that you control. For example: https://expected-host.evil-host.
• You can URL-encode characters to confuse the URL-parsing code. This is particularly useful if the code that implements the filter handles URL-encoded characters differently than the code that performs the back-end HTTP request.
  您可以使用URL编码字符来混淆URL解析代码。如果实现过滤器的代码处理URL编码字符的方式与执行后端HTTP请求的代码不同，则这一点特别有用
• You can use combinations of these techniques together.

例如
输入

 http://127.0.0.1/

看看是否能够通过回显白名单进行进一步攻击：

%2523是#

http://localhost:[e-mail]/admin/delete?username=carlos

Bypassing SSRF filters via open redirection（重定向）

It is sometimes possible to circumvent any kind of filter-based defenses by exploiting an open redirection vulnerability.

In the preceding SSRF example, suppose the user-submitted URL is strictly validated to prevent malicious exploitation of the SSRF behavior. However, the application whose URLs are allowed contains an open redirection vulnerability. Provided the API used to make the back-end HTTP request supports redirections, you can construct a URL that satisfies the filter and results in a redirected request to the desired back-end target.

有时可以利用开放重定向漏洞绕过任何类型的基于过滤器的防御。
在前面的SSRF示例中，假设用户提交的URL经过严格验证，以防止恶意利用SSRF行为。但是，允许URL的应用程序包含开放重定向漏洞。如果用于使后端HTTP请求支持重定向的API，则可以构造满足筛选器要求的URL，并将请求重定向到所需的后端目标。

For example, suppose the application contains an open redirection vulnerability（漏洞） in which the following URL:

/product/nextProduct?currentProductId=6&path=http://evil-user.net

returns a redirection to:

http://evil-user.net

You can leverage the open redirection vulnerability to bypass the URL filter, and exploit the SSRF vulnerability as follows:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

This SSRF exploit works because the application first validates that the supplied URL is on an allowed domain, which it is. The application then requests the supplied URL, which triggers the open redirection. It follows the redirection, and makes a request to the internal URL of the attacker’s choosing.
此SSRF攻击之所以有效，是因为应用程序首先验证提供的URL是否位于允许的域上，而该域是允许的。然后，应用程序请求提供的URL，从而触发打开重定向。它遵循重定向，并向攻击者选择的内部URL发出请求

如图，是一个明显的重定向漏洞：