Fix DNS-rebinding attack (low severity)

[bartekn]

Issue type

Future proof security fix

Issue description

Tavis Ormandy described a dns rebinding issue with Blizzard clients here: https://bugs.chromium.org/p/project-zero/issues/detail?id=1471&desc=3

stellar-core runs a simple admin http server on localhost. Currently it doesn't look like any of the commands than can be run using this interface can cause any harm (correct me if I'm wrong) but it's possible that new commands will be added in a future.

Attacker can register a new domain and point one of the subdomains to 127.0.0.1 with a short TTL. Then there are two ways to exploit this:

• If attacker wants to call the admin endpoint but doesn't care about the response he/she can add an <img> tag that points at a subdomain. This will request the core admin server. This attack requires a person who runs stellar-core locally to open a exploit website with image included (one of the Stellar forums?).
• If attacker wants to read a response he can configure CORS headers to allow connection from a root domain and send request to stellar-core admin server. This attack requires a person who runs stellar-core locally to open a exploit website.

Given the number of core nodes (and the fact that most of them are not run on local machines but in a cloud) I'd say this is low severity but worth fixing. The fix is very simple and requires checking the Host header of the incoming HTTP request.

[MonsieurNicolas]

Can you expand on the scenario?

I am not sure I understand the attack: for this to work it seems the attacker would be leveraging some other service running on localhost (like in another container?), and that other service would be connecting to arbitrary host names/ports over http?

In particular, I do not understand the attack with a browser: this would only be exploitable on a dev box, right?

[bartekn]

In particular, I do not understand the attack with a browser: this would only be exploitable on a dev box, right?

Yes, that's why I think it's a low severity.

When it comes to the explanation of the attack, there's a actually a good TL;DR in wikipedia:

The attacker registers a domain (such as attacker.com) and delegates it to a DNS server under the attacker's control. The server is configured to respond with a very short time to live (TTL) record, preventing the response from being cached. When the victim browses to the malicious domain, the attacker's DNS server first responds with the IP address of a server hosting the malicious client-side code. For instance, they could point the victim's browser to a website that contains malicious JavaScript or Flash scripts that are intended to execute on the victim's computer.

The malicious client-side code makes additional accesses to the original domain name (such as attacker.com). These are permitted by the same-origin policy. However, when the victim's browser runs the script it makes a new DNS request for the domain, and the attacker replies with a new IP address. For instance, they could reply with an internal IP address or the IP address of a target somewhere else on the Internet.

[MonsieurNicolas]

I am not sure I understand why you need the DNS exploit for this though... if I am browsing to a malicious site, the js code can just make calls to localhost directly or is that blocked by browsers? If they block localhost but are vulnerable to this, it seems like a bug browser side.

If we want to mitigate for this, I think the only good mitigation is to add some auth to the endpoint - as browsers are just one attack vector

[bartekn]

OK, I read again the original report and it looks like I completely missed authorization part that's required there (attacker needs to read an authorization code to send requests to other endpoints).

In stellar-core this is not the case. So:

• If attacker is not interested in the response body he/she doesn't need a DNS rebinding. The way CORS works is it will send the request but won't allow a response to be read (lack of Access-Control-Allow-Origin header). To fix this we need auth/CSRF tokens.
• If attacker needs a response body then DNS rebinding will allow this. To fix this we need Host header checking.

[MonsieurNicolas]

cool, ok. we'll start with the Host filtering (we'll have to double check if it includes the port number as well). We'll probably have to do localhost but also the "resolved" versions : 127.0.0.1 (ipv4) and ::/128 (ipv6)

[marta-lokhova]

It looks like HTTP headers are not easily accessible for us to add a check. The actual request handling happens inside the asio module. Some ways around it would be moving request handling out of lib/ or using a different http library, but it might be an overkill.

[MonsieurNicolas]

yeah that doesn't seem to be worth it at this time