Server-Side Request Forgery - or 'SSRF' for short - is a category of vulnerability that allows a malicious actor to send network requests on behalf of a server operated by the victim. The main use of this type of attack is typically to send requests to internal hosts (such as an AWS credentials endpoint) that only the exploited server would be able to access.
Most of the time, this type of issue arises from a server being allowed to make external requests (i.e, downloading an image from a URL to then store it as a profile picture) but a lack of input validation causes the server to be allowed to make internal requests. For this reason and similarly to 'open redirect' issues, SSRF isn't usually classed as a vulnerability unless there is demonstrable impact facing the company hosting such a server.
In addition to the main form of this vulnerability, 'blind' SSRF can also be used to imply that the person exploiting the vulnerability can make requests on behalf of a server but is unable to retrieve the responses (though some information might be leaked via side channels such as timing discrepancies).
Network analysis takes place via a huge range of techniques, ranging from heuristic monitoring of metadata to static blacklisting/allowlisting of endpoints, protocols, incoming/outgoing ports, and patterns in raw data. A common utility for implementing network protection is Snort, an open-source intrusion prevention system. Snort supports a set of rules such as the following:
preprocessor reputation:
memcap 500,
priority whitelist,
nested_ip inner,
whitelist $WHITE_LIST_PATH/white_list.rules,
blacklist $BLACK_LIST_PATH/black_list.rules
Other systems have different rule syntaxes but allow for similar functionality; flagging, blocking, or ignoring traffic based on volume, destination, or signature scanning packet contents.
For an attacker, bypassing an IP blacklist can be as trivial as renting a new set of proxies/servers, meaning that unless the malicious actor has hardcoded the IP of their command-and-control (C2) server, they will likely have little issue getting around an IP blacklist. Heuristic network analysis is more difficult to get around as it involves the developer tweaking the way that their malware communicates; this typically takes more time to work around but if an adversary can reverse engineer the model used to detect network traffic (or they have access to the public ruleset responsible for it) a workaround wouldn't take too long. If a network exclusively allows traffic based on a whitelist, malware authors have to find a way to route their communications through a set of trusted domains or IP ranges. This might lead to the use of a social media-based C2 structure or the (more accessible for attackers) compromise of a DNS (i.e, exploiting the firewall's DNS cache in a rebinding attack or modifying the DNS server relied upon by the firewall).
So, as you've probably guessed where this post is heading, the idea is to use SSRF to bypass blacklists and possibly to even lend credibility to communications by routing all traffic destined for the C2 server through a reputable service's servers. This is particularly advantageous over other methods of using reputable networks as endpoints that relay requests are likely to be less actively monitored (or logged) than, say, Twitter's post feed.
A case study for such an issue can be observed in Gravatar's avatar retrieval endpoint, where it was noted that https://secure.gravatar.com/avatar/nonexistent_identifier? default=http://images.google.com/default_avatar.png redirects to https://i1.wp.com/images.google.com/default_avatar.png, with 'images.google.com' subsequently receiving a DNS and then HTTP(S) GET request from the backend of 'i1.wp.com' (requesting 'default_avatar.png'):
;; opcode: QUERY, status: NOERROR, id: 50054
;; flags:; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version 0; flags: do; udp: 1680
;; QUESTION SECTION:
;images.google.com. IN A
;; opcode: QUERY, status: NOERROR, id: 50054
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;images.google.com. IN A
;; ANSWER SECTION:
images.google.com. 3600 IN A 8.8.8.8
;; AUTHORITY SECTION:
images.google.com. 3600 IN NS ns1.abc.def.
images.google.com. 3600 IN NS ns2.abc.def.
;; ADDITIONAL SECTION:
ns1.abc.def. 3600 IN A 8.8.8.8
ns2.abc.def. 3600 IN A 8.8.8.8
GET /default_avatar.png HTTP/1.1
Host: images.google.com
Accept: image/webp,*/*
User-Agent: Photon/1.0
This opens an opportunity for data to be embedded within the DNS request (the subdomain parameter being the most obvious choice) or the HTTP request/response, and bidirectional signalling would be possible with either - however, setting up a system to insert data into DNS requests/responses would be tedious and there is a limit to how much data can be held in a subdomain whereas there are a range of HTTP parsing libraries available for most langages and it could even be possible for an attacker to stream malicious binaries from their backend serer to a victim by embedding it inside an image that the i1.wp.com endpoint returns.
In this real-world example, we see that intentional server-side request forgery implemented by reputable companies can be leveraged by attackers to evade detection and make blocking their traffic slightly harder (Gravatar from the above example is embedded in every Wordpress site and is used by GitHub, Trello, Slack, Shopify, and Atlassian BitBucket) given how disallowing traffic to such an endpoint could cause collateral damage to legitimate users.
In addition to having traffic apparently flowing to a legitimate server, there is typically less moderation on the backend requests being made by endpoints such as i2.wp.com than there would be on obfuscated social media posts and by default, such endpoints don't collect the scores of data that seem to be assimilated by other platforms. These factors present the use of SSRF as a far more viable long-term communication method, a factor that is seemingly reinforced by how likely it is that the maintainers of such platforms tend to be unwilling to patch issues that do not directly impact themselves or their customers.
The example used in the case study above was reported to Automattic - the owners of Gravatar and Wordpress - in March of 2021 and was decided to be an 'intended feature' of the platform, which makes sense as the feature doesn't negatively impact internal assets or Gravatar users.