Some thoughts on SSRF detection

The DNS platform did not receive the request immediately, but received different request information at a later time, which at least indicates that there is SSRF with or without echo. Although it is difficult to prove greater harm, it at least indicates that there is a risk of SSRF, so I will explore its principle next.

Cracking the lens

There is also an introduction on the home page of the project, which was written according to Cracking the Lens’s Research. With the author less than four level of English, can barely understand the author is through the construction of malformed HTTP request, accompanied by a special request header, so that the server processing problems, so that the request to the customized server. As simple as it sounds, and in practice it is the Collaborator-everywhere tool, the code is easier to understand than it is in English. It defines the injection point and the form of payload

It processes the request, adding the payload in each request

Note that no matter what the injection point is, a request header cache-control: no-transform is added. The main function of this field is to Control the Cache, and the no-transform means that the request response is not processed in any case. This field is added to prevent the request from being processed in transit and thus not being properly detected. The processed request header looks like this

1, Network security learning route 2, electronic books (white hat) 3, security factory internal video 4, 100 SRC documents 5, common security comprehensive questions 6, CTF contest classic topic analysis 7, full kit 8, emergency response notes

So far you can actually find the SSRF, but it’s not enough to just have the access record. You also need to associate the trigger request-access record with the result of the author’s detection

It loops through to check whether Collaborator has received a request, and then presents the request and why

At this point, the implementation of the tool is clear, but it is clear that its injection point only covers header fields, and that blind-SSRF can be seen as a complement to it

Blind-SSRF

Templates can be divided into three types:

  1. Add a specific request header
  2. Modify theHostfield
  3. rightURLFor processing

Adding headers is not much to say, except that it adds a field to a request, and a request packet looks something like this

Wl-proxy-client-ip is similar to x-Forwarded-For. It usually obtains the IP address of the Client.

For the latter two kinds of processing is much more complicated, which are generally caused by logical processing errors, such as the example mentioned in the original text

Url backendURL = "http://public-backend/";
String uri = ctx.getRequest().getRawUri();

URI proxyUri;
try {
proxyUri = new URIBuilder(uri)
        .setHost(backendURL.getHost())
        .setPort(backendURL.getPort())
        .setScheme(backendURL.getScheme())
        .build();
} catch (URISyntaxException e) {
    Util.sendError(ctx, 400, INVALID_REQUEST_URL);
    return;
}
Copy the code

As of Apache HttpComponents 4.5.1 it does not detect urIs that start with /, which means that we can construct deformed HTTP requests to access addresses other than the specified backendURL, for example:

After concatenation, the obtained proxyUri is in the form of http://public-backend@host. Public-backend before @ is used as the user name, but the requested address is the host specified in the URI.

Burp4SSRF

The two tools in the previous section can already detect SSRF, but there are some drawbacks:

  • The Collaborator-Everywhere situation is not comprehensive, and its direct modification of requests such as referer can sometimes lead to errors in the request

  • Blind – SSRF cannot visually display the vulnerability situation

In response to these issues, the authors decided to make a simple change to Collaborator-Everywhere to give it more coverage, while adopting a passive scanning approach to prevent interference with normal requests.

The first is the request method modification, this is very simple, just need to change the original inheritance of IProxyListener to IScannerCheck, the former indicates that the request is processed while the request is being processed, and the latter is handed to the active or passive scanner for processing. The resulting scan logic is now available in the Injector’s doPassiveScan function

After injectPayloads header and param into the request, the request is sent using the makeHttpRequest function.

In addition to handling hosts and URIs as injection points, an injectAnyWhere function has been added

After processing the regular injection point, the remaining raw and host are processed separately. The raw is replaced from the first line of the request packet. Both types of raw can cause irreversible effects on the body of the request packet, so we send a request for each payload. All payloads are sent at once. So far, the first few problems have been solved. The actual results are as follows:

conclusion

This is not a new technology, but in the actual penetration, there are often unexpected gains. At present, it is just a simple improvement of the original tool. There are many things to do in the next step, for example, the DNSLog of Burp is sometimes broken, and some malformed requests can not be viewed when viewing requests through the Burp log. But there are more ways than difficulties.