Many people are aware of how Cross Site Request Forgery can be used to turn a victim’s browser against a vulnerable application, however vulnerabilities also exist that can turn an application server itself against the infrastructure that it is connected to.
The confused deputy
Like Cross Site Request Forgery (CSRF), Server Side Request Forgery is an example of the “Confused Deputy” problem. By using intended functionality of a system it is sometimes possible to exploit the fact that the system an attacker is connected to has greater privileges than the attacker themselves.
In CSRF, the “Confused Deputy” that attackers exploit is the web browser of a user who has elevated privileges within an application. The attacker can trick a logged-in web browser into carrying out actions on another site by originating the request within their own, malicious site.
Under the thumb
In Server Side Request Forgery (SSRF), the “Confused Deputy” is the business logic of the web application itself. A common example of this is for sites which provide automatic “thumbnailing” of images or web pages from arbitrary locations on the Internet. These are often provided as part of user-editable content. As a user edits a piece of content, they may insert links to images or web pages.
Figure 1 - Automatic thumbnail creation in action
In the background, the web application sends off a request to a feature of the application which grabs the page and produces a thumbnail image.
Figure 2 - A request to Facebook's URL "scraper" feature
The thumbnail can then be inserted into content and the copy of the image that the server grabbed is served to any visitors to that page instead of the larger copy on the web site that is being linked to.
This seems harmless enough however, we have now established that the application will request any URL that we specify for us. If the hosting server that the application is running on has different privileges to the attacker, this can be exploited.
Death by a thousand thumbnails
In the example above, the image thumbnail is produce by Facebook – one of the largest and most resilient sites on the Internet. What would happen if, instead of the address of a web page or an image, we linked directly to a large file such as a software download, and instead of linking to it just once, we linked to it 100 times by varying the URL slightly? Independent researcher Chaman Thapa recently demonstrated that by using this feature and the incredible resilience of Facebook’s hosting platform it is possible to direct a Denial of Service (DoS) attack using a sustained 900 Mbps of traffic at a host of his choosing.
A spy within your own network
Web applications often have one other major privilege over external attackers: They are hosted within a company’s network infrastructure. If a web application is available to not only the Internet but the internal company infrastructure then not only can users connect to them, but they can connect to hosts within the network as well. Knowing this, an attacker can direct the application to a series of local IP addresses in order to determine what IP address range the server exist on internally (e.g. 192.168.1.0/24) and then start pulling content from sites that would not otherwise have been available to the Internet. This enumeration of services doesn’t stop with just web sites. By specifying which TCP port the thumbnail feature should connect to in the URL (e.g. http://192.168.1.200:21) the web service will attempt to make a TCP connection to that host on the specified port as if it was hosting a web site.
Figure 3 - Scanning for open ports behind the firewall
At this point, one of two things will happen:
- The port will not be open and, after a period of several seconds, an error is produced.
- The port is open and a connection is made instantly, however the connection closes with an error when the client or server realises they are not talking the same protocol.
By using this disparity in the response times generated or any error messages produced, a list of open TCP ports can be established for each host, allowing an attacker to gain valuable information about the technology used on the internal infrastructure of the target network.
Figure 4 - Error messages may also hold additional information about hosts
Figure 5 - Results of a port scan attack showing newly discovered open ports behind the firewall
Picking on the little guy
The attacker now has a list of services available inside the target network. What next? Often, companies consider security in applications behind a firewall to be less critical as they are only available to “trusted” users. By using known image locations, such as the application logo within web applications, the attacker can attempt to enumerate which applications are installed on hosts inside the network and target the weakest.
Figure 6 – Enumerating known image locations within discovered web services
The attacker is limited to simple “GET” requests and can only receive image content, error messages and timing information, but this can still be enough to extract data or interact with an internal network. Once the technology in use has been established, known vulnerabilities such as Cross Site Request Forgery can then be exploited on vulnerable services in place.
Figure 7 - How an attacker interacts with hosts inside a network
For example, the database engine MongoDB implements a web admin interface on port 28017. Older or poorly configured versions of MongoDB provide unauthenticated functionality to execute powerful server side JavaScript or maintenance commands via simple “GET” requests.
Figure 8 - Server side JavaScript run on a MongoDB instance
If the image thumbnail script successfully connects to this service, it would effectively provide an attacker with full administrative rights to the database.
Closing the hole
How do you protect against this type of attack? I recommend two precautions when implementing an application which requests a URL on behalf of a user:
- Rate Limit requests through the feature. Legitimate users do not need hundreds of requests per minute as an attacker carrying out a port scanning or Denial of Service attack would.
- Prevent internal network requests. This is most simply achieved by rear-facing firewall rules, however strong blacklisting of internal address ranges would also help to mitigate this vulnerability.