Haft

Backlinks

Basic SSRF against the local server

TL;DR

Use the vulnerable stockApi parameter in a POST request two times :

  1. Accessing unauthorized admin webpage
  2. Use the discovered data to trigger an admin action (user deletion) and solve the lab.

Learning material

In an SSRF attack against the server, the attacker causes the application to make an HTTP request back to the server that is hosting the application, via its loopback network interface. This typically involves supplying a URL with a hostname like 127.0.0.1 (a reserved IP address that points to the loopback adapter) or localhost (a commonly used name for the same adapter).

For example, imagine a shopping application that lets the user view whether an item is in stock in a particular store. To provide the stock information, the application must query various back-end REST APIs. It does this by passing the URL to the relevant back-end API endpoint via a front-end HTTP request. When a user views the stock status for an item, their browser makes the following request:

POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118 stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

This causes the server to make a request to the specified URL, retrieve the stock status, and return this to the user.

In this example, an attacker can modify the request to specify a URL local to the server:

POST /product/stock HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 118 stockApi=http://localhost/admin

The server fetches the contents of the /admin URL and returns it to the user.

An attacker can visit the /admin URL, but the administrative functionality is normally only accessible to authenticated users. This means an attacker won’t see anything of interest. However, if the request to the /admin URL comes from the local machine, the normal access controls are bypassed. The application grants full access to the administrative functionality, because the request appears to originate from a trusted location. Why do applications behave in this way, and implicitly trust requests that come from the local machine? This can arise for various reasons:

  • The access control check might be implemented in a different component that sits in front of the application server. When a connection is made back to the server, the check is bypassed.
  • For disaster recovery purposes, the application might allow administrative access without logging in, to any user coming from the local machine. This provides a way for an administrator to recover the system if they lose their credentials. This assumes that only a fully trusted user would come directly from the server.
  • The administrative interface might listen on a different port number to the main application, and might not be reachable directly by users.

These kind of trust relationships, where requests originating from the local machine are handled differently than ordinary requests, often make SSRF into a critical vulnerability.

Lab

This lab has a stock check feature which fetches data from an internal system.

To solve the lab, change the stock check URL to access the admin interface at http://localhost/admin and delete the user carlos.

Write-up

Upon landing on the lab, you’ll see a Home panel with no way to register, nor any credentials given in the challenge. Instead, you can visit articles and note a stock checking feature giving you the associated information depending on the defined location.

Intended use of stock checking : Since we are specifically looking for SSRF here, we might try to reach the admin interface given in context :

Altered Request to call for http://localhost/admin Trying to delete the user carlos will not work directly since we’re not allowed to access any admin action directly : Thus, we need to :

  1. Identify the HTTP deletion Request (shown above)
  2. Supply it in the stockApi parameter.

Doing so will solve the lab.

Multiple vulnerabilities here

The deletion request is not appropriate. We are able to trigger it because it is a GET request in this case, although it should be use the DELETE method. Here, we’re using both a SSRF and improper use of HTTP methods.

Note that the deletion action will appear in logs from the server itself. Identifying the original problem requires to trace back the flow of request.

Backlinks

Recent Notes