CVE-2018-5702: Mitigate dns rebinding attacks against daemon

[taviso]

This issue was originally reported to the private transmission security list on November 30th 2017

Transmission uses a client/server architecture, the user interface is the client and a daemon runs in the background managing the downloading, seeding, etc.

Clients interact with the daemon using JSON RPC requests to a web server listening on port 9091. The daemon will only accept requests from localhost by default, but it's common to configure NAS devices to accept remote clients.

Note: I regularly encounter users who don't accept that websites can access services on localhost or their intranet. These users understand that services bound to localhost are only accessible to software running on the local machine, and that their browser is running on the local machine - but somehow believe that accessing a website "transfers" execution somewhere else. It doesn't work like that, but this is a common source of confusion.

A sample RPC session looks like this:

$ curl -sI http://localhost:9091/transmission/rpc
HTTP/1.1 409 Conflict
Server: Transmission
X-Transmission-Session-Id: JL641xTn2h53UsN6bVa0kJjRBLA6oX1Ayl06AJwuhHvSgE6H
Date: Wed, 29 Nov 2017 21:37:41 GMT

$ curl -H 'X-Transmission-Session-Id: JL641xTn2h53UsN6bVa0kJjRBLA6oX1Ayl06AJwuhHvSgE6H'  -d '{"method":"session-set","arguments":{"download-dir":"/home/user"}}' -si http://localhost:9091/transmission/rpc
HTTP/1.1 200 OK
Server: Transmission
Content-Type: application/json; charset=UTF-8
Date: Wed, 29 Nov 2017 21:38:57 GMT
Content-Length: 36

{"arguments":{},"result":"success"}

As with all HTTP RPC schemes like this, any website can send requests to the daemon listening on localhost with XMLHttpRequest(), but the theory is they will be ignored because clients must prove they can read and set a specific header, X-Transmission-Session-Id.

Unfortunately, this design doesn't work because of an attack called "DNS rebinding". Any website can simply create a dns name that they are authorized to communicate with, and then make it resolve to localhost.

The attack works like this:

1. A user visits http://attacker.com, which has an <iframe> to a subdomain the attacker controls.
2. The attacker configures their DNS server to respond alternately with 127.0.0.1 and 123.123.123.123 (an address they control) with a very low TTL.
3. When the browser resolves to 123.123.123.123, they serve HTML that waits for the DNS entry to expire (or force it to expire by flooding the cache with lookups), then they have permission to read and set headers.

I have a domain I use for testing dns rebinding called rbndr.us, you can use this page to generate hostnames (source code is here):

https://lock.cmpxchg8b.com/rebinder.html

Here I want to alternate between 127.0.0.1 and 199.241.29.227, so I use 7f000001.c7f11de3.rbndr.us:

$ host 7f000001.c7f11de3.rbndr.us
7f000001.c7f11de3.rbndr.us has address 127.0.0.1
$ host 7f000001.c7f11de3.rbndr.us
7f000001.c7f11de3.rbndr.us has address 199.241.29.227
$ host 7f000001.c7f11de3.rbndr.us
7f000001.c7f11de3.rbndr.us has address 127.0.0.1

Here you can see the resolution alternates between the two addresses I want (note that depending on caching it might take a while to switch, the TTL is set to minimum but some servers round up).

I just wait for the cached response to expire, and then POST commands to the server.

Exploitation is simple, you could set script-torrent-done-enabled and run any command, or set download-dir to /home/user/ and then upload a torrent for .bashrc.

Here is my (simple) demo, it's slow, but could be made very fast:

http://lock.cmpxchg8b.com/Asoquu3e.html

I've verified it works on Chrome and Firefox on Windows and Linux (I tried Fedora and Ubuntu), I expect other platforms and browsers are affected. There are screenshots of how the attack is supposed to look below.

This Pull Request mitigates this attack by requiring a host whitelist for requests that cannot be proven to be secure, but it can be disabled if a user does not want security. I think users might not be find it intuitive that servers on localhost or their intranet are exposed to the web, but hopefully they will read the warning.

Here are some screenshots demonstrating the attack:

Before the attack begins, the Download directory is set correctly:

Here is how the exploit looks:

Here is the exploit running:

The attack succeeds:

And the result:

[lfam]

I naively adapted the patch so it applies to the 2.92 release (attached).
transmission-fix-dns-rebinding-vuln.patch.txt

As the CI server shows, with these changes the quark-test fails with exit status: 29.

[woodsb02]

Has a CVE been assigned for this?

[taviso]

I believe I've fixed the quark-test fail, the list wasn't ordered correctly.

(I broke the merge, but I think it's fixed now)

[taviso]

@woodsb02 No, but I've just requested one and will update when received.

[lfam]

I've updated the 2.92 patch with the latest changes from @taviso. The tests do pass now.
transmission-fix-dns-rebinding-vuln.patch.txt

[wknapik]

@taviso the demo works, unless you load it over https. Mixed content.
@EFForg HTTPS Everywhere ftw!;]

[jggimi]

@taviso and @lfam thank you. I've adapted lfam's second 2.92 patch set to the OpenBSD port of transmission, which I maintain. Testing underway.

[smithfred]

Just a naïve question for my own edification - this basically uses Host for header checking-based protection instead of relying on X-Transmission-Session-Id, because Host is a Fetch Standard forbidden header name, and so not vulnerable to the same exploit, is that correct?

[taviso]

@smithfred Yes, correct.

[wfiveash]

If transmission is configured such that the daemon/web server requires authorization (user ID, password) does this mitigate this attack?

[taviso]

@wfiveash Yes, but be aware that it's possible to guess the credentials, so make them strong.

[lfam]

@jggimi Okay, let us know if you notice any problems.

Remember I described my adaptation as "naive". I only made sure the patch applies and Transmission still works.

[woodsb02]

In my setup, the settings.json file is re-written each time transmission-daemon is started, based on the command line arguments passed to it.

Can we please add new command line arguments to transmission-daemon set the rpc-host-whitelist-enabled and rpc-host-whitelist parameters?

[msmeissn]

cve requested at Mitre.org

[msmeissn]

CVE-2018-5702

[lnicola]

Yes, but be aware that it's possible to guess the credentials, so make them strong.

@taviso Does [enabling rpc-password] mitigate this even if I previously connected to the Web UI? Transmission uses HTTP Basic Authentication and e.g. Firefox caches that until it's closed.

EDIT: Suppose so, since the credentials I logged in with are for a different origin.

[taviso]

@lnicola Yep, exactly, it will be a different hostname and so credentials won't be cached. Transmission already has a CSRF protection scheme, so you can't just POST commands to the real hostname.

[1265578519]

这需要更新html来修复还是核心？

[joq3]

I have used an NGinx Reverse Proxy on my server for a while now, and directly after I installed this update I could no longer visit Transmission via my domain.
I have made some changes and I have come as far as being able to reach it with https://bt.mydomain.com/web/, but if I try https://bt.mydomain.com it will only give me the "409: Conflict Your request had an invalid session-id header.".

This is the current Nginx setup: https://hastebin.com/oyicigowuz.nginx

I have tried changing proxy_pass to http://localhost:9091/transmission/web/; but that won't work at all.

Please help me solve this new problem. Thank you!

[1265578519]

@joq3 用nginx不麻烦么。。

[joq3]

@1265578519 sorry? I don't understand?

[1265578519]

@joq3 你根本不用通过nginx，直接通过DNS解析你的域名，通过域名:9091访问即可。

[mikedld]

@1265578519 When walking into a room with 17 people conversing in English, please speak English.