Question

SSRFs can vary in impact, but they have a lot of potential if you know how to escalate them by chaining them with different bugs. Now that you have the basics of SSRFs down, let’s learn to exploit them most effectively.

如果你知道如何将它们与不同的漏洞链接起来，SSRF 可能会产生不同的影响，但它们有很大的潜力。现在你已经掌握了 SSRF 的基础知识，让我们学习如何最有效地利用它们。

What you can achieve with an SSRF usually depends on the internal services found on the network. Depending on the situation, you could use SSRF to scan the network for reachable hosts, port-scan internal machines to fingerprint internal services, collect instance metadata, bypass access controls, leak confidential data, and even execute code on reachable machines.

通过 SSRF ，您可以实现的通常取决于网络上发现的内部服务。根据情况，您可以使用 SSRF 扫描可访问主机的网络，对内部机器进行端口扫描以指纹内部服务，收集实例元数据，绕过访问控制，泄漏机密数据，甚至在可访问机器上执行代码。

Perform Network Scanning

You may sometimes want to scan the network for other reachable machines. Reachable machines are other network hosts that can be connected to via the current machine. These internal machines might host databases, internal websites, and otherwise sensitive functionalities that an attacker can exploit to their advantage. To perform the scan, feed the vulnerable endpoint a range of internal IP addresses and see if the server responds differently to each address. For example, when you request the address 10.0.0.1

有时候，你可能想要扫描网络中其他可达的机器。可达机器指的是可以通过当前机器连接到的其他网络主机。这些内部机器可能托管数据库、内部网站和其他敏感功能，黑客可以利用它们来攻击。为了进行扫描，需要将一个范围的内部 IP 地址输入到易受攻击的终端，看看服务器是否对每个地址有不同的响应。例如，当你请求地址 10.0.0.1 时。

POST /upload_profile_from_url
Host: public.example.com

(POST request body)
user_id=1234&url=https://10.0.0.1

the server may respond with this message:

服务器可能会响应此消息：

Error: cannot upload image: http-server-header: Apache/2.2.8 (Ubuntu) DAV/2

But when you request the address 10.0.0.2

当你请求地址 10.0.0.2 时。

POST /upload_profile_from_url
Host: public.example.com

(POST request body)
user_id=1234&url=https://10.0.0.2

the server may respond with this message:

服务器可能会响应此消息：

Error: cannot upload image: Connection Failed

You can deduce that 10.0.0.1 is the address of a valid host on the network, while 10.0.0.2 is not. Using the differences in server behavior, you can gather info about the network structure, like the number of reachable hosts and their IP addresses.

您可以推断出 10.0.0.1 是网络上有效主机的地址，而 10.0.0.2 不是。利用服务器行为的差异，您可以收集有关网络结构的信息，例如可达主机的数量和它们的 IP 地址。

You can also use SSRF to port-scan network machines and reveal services running on those machines. Open ports provide a good indicator of the services running on the machine, because services often run on certain ports by default. For example, by default, SSH runs on port 22, HTTP runs on port 80, and HTTPS runs on port 443. Port-scan results often point you to the ports that you should inspect manually, and they can help you plan further attacks tailored to the services found.

您也可以使用 SSRF 来扫描网络设备的端口，并揭示这些设备上运行的服务。开放的端口可以很好地指示设备上运行的服务，因为服务通常默认运行在某些端口上。例如，SSH 默认运行在 22 号端口上，HTTP 运行在 80 号端口上，而 HTTPS 运行在 443 号端口上。端口扫描结果通常指向您应该手动检查的端口，并且它们可以帮助您计划更多针对发现的服务的攻击。

Provide the vulnerable endpoint with different port numbers, and then determine if the server behavior differs between ports. It’s the same process as scanning for hosts, except this time, switch out port numbers rather than hosts. Port numbers range from 0 to 65,535.

提供不安全的终端点不同的端口号，然后确定服务器在端口之间的行为是否有所不同。这与扫描主机的过程相同，只不过这一次需要更改端口号而不是主机。端口号范围从 0 到 65,535。

Let’s say you want to find out which ports are open on an internal machine. When you send a request to port 80 on an internal machine, the server responds with this message:

假设您想找出内部计算机开放的端口。当您向内部计算机上的端口 80 发送请求时，服务器会以以下消息进行响应：

Error: cannot upload image: http-server-header: Apache/2.2.8 (Ubuntu) DAV/2

And when you send a request to port 11 on the same machine, the machine responds with this message:

当您向同一台机器的 11 号端口发送请求时，该机器将以此消息作出回应：

Error: cannot upload image: Connection Failed

We can deduce that port 80 is open on the machine, while port 11 is not. You can also figure out from the response that the machine is running an Apache web server and the Ubuntu Linux distribution. You can use the software information revealed here to construct further attacks against the system.

我们可以推断出在这台机器上，80 端口是开放的，而 11 端口则不是。从响应可以推断出，这台机器运行的是 Apache Web 服务器和 Ubuntu Linux 发行版。您可以使用在此处揭示的软件信息，构建进一步的攻击来攻击该系统。

Pull Instance Metadata

Cloud computing services allow businesses to run their applications on other people’s servers. One such service, Amazon Elastic Compute Cloud (EC2), offers an instance metadata tool that enables EC2 instances to access data about themselves by querying the API endpoint at 169.254.169.254. Instances are virtual servers used for running applications on a cloud provider’s infrastructure. Google Cloud offers a similar instance metadata API service.

云计算服务允许企业在其他人的服务器上运行其应用程序。 Amazon Elastic Compute Cloud（EC2）是这样一项服务，它提供了实例元数据工具，使 EC2 实例能够通过在 API 端点上查询 169.254.169.254 来访问有关自身的数据。实例是用于在云提供商基础架构上运行应用程序的虚拟服务器。谷歌云提供类似的实例元数据 API 服务。

These API endpoints are accessible by default unless network admins specifically block or disable them. The information these services reveal is often extremely sensitive and could allow attackers to escalate SSRFs to serious information leaks and even RCE.

这些 API 端点默认情况下是可访问的，除非网络管理员特别阻止或禁用它们。这些所提供的服务信息通常非常敏感，可能会让攻击者将 SSRF 升级成严重的信息泄漏、甚至 RCE。

Querying EC2 Metadata

If a company hosts its infrastructure on Amazon EC2, try querying various instance metadata about the host using this endpoint. For example, this API request fetches all instance metadata from the running instance:

如果公司将其基础设施托管在 Amazon EC2 上，请尝试使用此端点查询有关主机的各种实例元数据。例如，此 API 请求从正在运行的实例中提取所有实例元数据：

http://169.254.169.254/latest/meta-data/

Use this URL in an endpoint vulnerable to SSRF:

在易受 SSRF 攻击的终端点中使用该 URL：

https://public.example.com/proxy?url=http://169.254.169.254/latest/meta-data/

These endpoints reveal information such as API keys, Amazon S3 tokens (tokens used to access Amazon S3 buckets), and passwords. Try requesting these especially useful API endpoints:

这些终端节点揭示了诸如 API 密钥、Amazon S3 令牌（用于访问 Amazon S3 桶的令牌）和密码等信息。尝试请求这些特别有用的 API 终端节点：

• http://169.254.169.254/latest/meta-data/ returns the list of available metadata that you can query.
• http://169.254.169.254/latest/meta-data/local-hostname/ returns the internal hostname used by the host.
• http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME returns the security credentials of that role.
• http://169.254.169.254/latest/dynamic/instance-identity/document/ reveals the private IP address of the current instance.
• http://169.254.169.254/latest/user-data/ returns user data on the current instance.

You can find the complete documentation for the API endpoint at https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html .

你可以在 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html 找到完整的 API 端点文档。

Querying Google Cloud Metadata

If the company uses Google Cloud, query the Google Instance Metadata API instead. Google implements additional security measures for its API endpoints, so querying Google Cloud Metadata APIv1 requires one of these special headers:

如果公司使用 Google Cloud，请查询 Google Instance Metadata API。Google 为其 API 端点实施了额外的安全措施，因此查询 Google Cloud Metadata APIv1 需要其中的特殊标头之一：

Metadata-Flavor: Google
X-Google-Metadata-Request: True

These headers offer protection against SSRFs because most often during an SSRF, you cannot specify special headers for the forged request. But you can easily bypass this protection, because most endpoints accessible through APIv1 can be accessed via the API v1beta1 endpoints instead. API v1beta1 is an older version of the metadata API that doesn’t have the same header requirements. Begin by targeting these critical endpoints:

由于在 SSRF 期间，您通常无法为伪造的请求指定特殊标头，因此这些标头提供对抗 SSRF 的保护。但是，您可以轻松绕过此保护，因为大多数通过 APIv1 可访问的终端点可以通过 API v1beta1 终端点访问。 API v1beta1 是元数据 API 的较旧版本，不具有相同的标头要求。首先针对这些关键终端点开始： 由于 SSRF 的影响，这些标头提供保护。但可以轻松规避此保护，因为可以通过 API v1beta1 接口访问 API v1 的大多数端点。 API v1beta1 是元数据 API 的旧版，不具有相同的标头要求。从攻击这些关键端点开始：

• http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token returns the access token of the default account on the instance.
• http://metadata.google.internal/computeMetadata/v1beta1/project/attributes/ssh-keys returns SSH keys that can connect to other instances in this project.

Read the full API documentation at https://cloud.google.com/compute/docs/storing-retrieving-metadata/ . Note that the API v1beta1 was deprecated in 2020 and is in the process of being shut down. In the future, you might be required to query metadata with APIv1 and will need to find a way to forge the required headers to request instance metadata for targets that use Google Cloud.

请访问 https://cloud.google.com/compute/docs/storing-retrieving-metadata/ 阅读完整的 API 文档。请注意，API v1beta1 在 2020 年已经被弃用并正在逐步关闭。未来，您可能需要使用 APIv1 查询元数据，并需要找到一种方式来伪造所需的标头以请求使用 Google Cloud 的目标实例元数据。

Amazon and Google aren’t the only web services that provide metadata APIs. However, these two companies control a large share of the market, so the company you’re testing is likely on one of these platforms. If not, DigitalOcean and Kubernetes clusters are also vulnerable to the same issue. For DigitalOcean, for example, you can retrieve a list of metadata endpoints by visiting the http://169.254.169.254/metadata/v1/ endpoint. You can then retrieve key pieces of information such as the instance’s hostname and user data. For Kubernetes, try accessing https://kubernetes.default and https://kubernetes.default.svc/metrics for information about the system.

亚马逊和谷歌并非唯一提供元数据 API 的网络服务。然而，这两家公司控制着较大的市场份额，因此您测试的公司可能在其中一个平台上。如果不是，DigitalOcean 和 Kubernetes 集群也容易受到同样的问题影响。例如，对于 DigitalOcean，您可以通过访问 http://169.254.169.254/metadata/v1/端点来检索元数据端点的列表。然后，您可以检索关键的信息，例如实例的主机名和用户数据。对于 Kubernetes，尝试访问 https://kubernetes.default 和 https://kubernetes.default.svc/metrics 以获取有关系统的信息。

Exploit Blind SSRFs

Because blind SSRFs don’t return a response or error message, their exploitation is often limited to network mapping, port scanning, and service discovery. Also, since you can’t extract information directly from the target server, this exploitation relies heavily on inference. Yet by analyzing HTTP status codes and server response times, we can often achieve results similar to regular SSRF.

由于盲目的 SSRF 不会返回响应或错误信息，他们的利用通常局限于网络映射、端口扫描和服务发现。此外，由于无法直接从目标服务器提取信息，因此这种利用非常依赖推理。然而，通过分析 HTTP 状态代码和服务器响应时间，我们通常可以达到类似常规 SSRF 的结果。

Network and Port Scanning Using HTTP Status Codes

Remember from Chapter 5 that HTTP status codes provide information about whether the request succeeded. By comparing the response codes returned for requests to different endpoints, we can infer which of them are valid. For example, if a request for https://public.example.com/webhook?url=10.0.0.1 results in an HTTP status code of 200, while a request for https://public.example.com/webhook?url=10.0.0.2 results in an HTTP status code of 500, we can deduce that 10.0.0.1 is the address of a valid host on the network while 10.0.0.2 is not.

记住第 5 章提到的 HTTP 状态码提供关于请求是否成功的信息。通过比较不同端点请求返回的响应码，我们可以推断哪些是有效的。例如，如果对 https：//public.example.com/webhook？url = 10.0.0.1 的请求返回 HTTP 状态码 200，而对 http：//public.example.com/webhook？url = 10.0.0.2 的请求返回 HTTP 状态码 500，则我们可以推断 10.0.0.1 是网络上一个有效的主机地址，而 10 .0.0.2 不是。

Port scanning with blind SSRF works the same way. If the server returns a 200 status code for some ports, and 500 for others, the 200 status code might indicate open ports on the machine. On the other hand, if all requests return the same status code, the site might have implemented protection against SSRF port scanning.

使用盲目 SSRF 进行端口扫描的方式是相同的。如果服务器针对某些端口返回 200 状态码，而针对其他端口返回 500 状态码，则 200 状态码可能表示计算机上的开放端口。另一方面，如果所有请求返回相同的状态码，则该站点可能已经实施了对 SSRF 端口扫描的保护。

Network and Port Scanning Using Server Response Times

If the server isn’t returning any useful information in the form of status codes, you might still be able to figure out the network structure by examining how long the server is taking to respond to your request. If it takes much longer to respond for some addresses, those network addresses might be unrouted or hidden behind a firewall. Unrouted addresses cannot be reached from the current machine. On the other hand, unusually short response times may also indicate an unrouted address, because the router might have dropped the request immediately.

如果服务器没有以状态码的形式返回任何有用的信息，您仍然可以通过检查服务器响应您的请求所需的时间来确定网络结构。如果对某些地址响应时间超长，这些网络地址可能没有路由，或被隐藏在防火墙后面。从当前机器无法访问未路由的地址。另一方面，异常短的响应时间也可能表明存在未路由的地址，因为路由器可能立即丢弃了该请求。

When performing any kind of network or port scanning, it is important to remember that machines behave differently. The key is to look for differences in behavior from the machines on the same network, instead of the specific signatures like response times or response codes described previously.

执行任何类型的网络或端口扫描时，重要的是要记住不同的机器表现不同。关键是要查找在同一网络上的机器的行为差异，而不是先前描述的特定签名，比如响应时间或响应代码。

The target machine might also leak sensitive information in outbound requests, such as internal IPs, headers, and version numbers of the software used. If you can’t access an internal address, you can always try to provide the vulnerable endpoint with the address of a server you own and see what you can extract from the incoming request.

目标机器在出站请求中可能会泄露敏感信息，例如内部 IP、标头和所使用软件的版本号。如果您无法访问内部地址，可以尝试向易受攻击的端点提供您拥有的服务器地址，并查看您可以从传入请求中提取什么。

Attack the Network

Use what you’ve found by scanning the network, identifying services, and pulling instance metadata to execute attacks that have impact. Notably, you may be able to bypass access controls, leak confidential information, and execute code.

使用通过扫描网络、识别服务和提取实例元数据所获得的信息执行具有影响的攻击。值得注意的是，您可能能够绕过访问控制、泄露机密信息并执行代码。

First, try to bypass access control. Some internal services might control access based on IP addresses or internal headers only, so it might be possible to bypass controls to sensitive functionalities by simply sending the request from a trusted machine. For example, you might be able to access internal websites by proxying through a web server:

首先，请尝试绕过访问控制。一些内部服务可能仅基于 IP 地址或内部头来控制访问，因此通过从受信任的机器发送请求，可能可以绕过对敏感功能的控制。例如，您可能可以通过代理服务器访问内部网站：

https://public.example.com/proxy?url=https://admin.example.com

You can also try to execute internal API calls through the SSRF endpoint. This type of attack requires knowledge about the internal system and API syntax, which you can obtain by conducting recon and via other information leaks from the system. For example, let’s say the API endpoint admin.example.com/delete_user deletes a user and can only be requested by an internal address. You could trigger the request if you find an SSRF that lets you send a request from a machine in the trusted network:

您还可以尝试通过 SSRF 端点执行内部 API 调用。这种类型的攻击需要对内部系统和 API 语法有所了解，您可以通过查阅信息并通过系统中的其他信息泄漏来获得这些知识。例如，假设 API 端点 admin.example.com/delete_user 删除用户，并且只能由内部地址请求。如果您找到了一个允许您从可信网络中的计算机发送请求的 SSRF，您就可以触发该请求。

https://public.example.com/send_request?url=https://admin.example.com/delete_user?user=1

Second, if you were able to find credentials using the SSRF by leaking info via headers or by querying instance metadata, use those credentials to access confidential information stored on the network. For example, if you were able to find Amazon S3 keys, enumerate the company’s private S3 buckets and see if you can access them with the credentials you found.

其次，如果你能够通过 SSRF 泄露标头或查询实例元数据找到凭据，请使用这些凭据访问存储在网络上的机密信息。例如，如果你能够找到 Amazon S3 密钥，请列举公司的私有 S3 存储桶，看看是否可以使用你找到的凭据访问它们。

Third, use the info you gathered to turn SSRF into remote code execution (which you’ll learn more about in Chapter 18 ). For example, if you found admin credentials that give you write privileges, try uploading a shell to the web server. Or, if you found an unsecured admin panel, see if any features allow the execution of scripts. You can also use either classic or blind SSRF to test for other vulnerabilities on the target’s network by sending payloads designed to detect well-known vulnerabilities to reachable machines.

第三步，利用收集到的信息将 SSRF 转换为远程代码执行（这将在第 18 章中详细介绍）。例如，如果您找到了可以让您拥有写权限的管理员凭据，请尝试将 shell 上传到 Web 服务器。或者，如果您发现了一个不安全的管理员面板，请查看是否有任何功能允许执行脚本。您还可以使用经典或盲目的 SSRF 来测试目标网络上的其他漏洞，通过向可到达的机器发送旨在检测众所周知的漏洞的有效载荷来测试。