Blizzard games were vulnerable to DNS rebinding attack • Hacker News Board

Re: Blizzard games were vulnerable to DNS rebinding attack

#81

Post by geofft » Tue, Jan 23, 2018, 1:17 AM UTC

dooglius wrote: post #58

geofft wrote: post #29

Earlier quoted context omitted.

Yes. They can't send arbitrary traffic, though; they can only send valid HTTP requests, and they don't get access to your cookies (because the hostname doesn't match), so the "only" thing they can do is get access to things that an unauthenticated HTTP client running as you could get access to. This has been true since almost the first web browsers - XHR wasn't a thing, but you could send GET requests with " rel="nof…

This makes sense, thanks for the explanation. The unfortunate thing is that setting up a local HTTP server is easy, while proper authentication takes more work. Based on the nature of their fix, it seems Blizzard doesn't really want to expend effort on proper authentication. I wonder if browsers could send a special HTTP header indicating the host that initiated the request?

Browsers (and most other HTTP clients) already send the Host: header, and that appears to be a pretty good way to mitigate DNS rebinidng attacks. It does not save you from things like attacks.

One common use of local HTTP servers is with the express intent of hosting web pages (not just an API endpoint) that's rendered in an embedded web browser widget, or perhaps even in a real web browser, because the web is a pretty good way of showing UIs. A common example is CUPS - if you're on macOS or most desktop Linuxes, http://localhost:631 is likely to bring up the CUPS admin interface. So browsers saying "I'm a browser" is not really the (un)authorization you want - many times you want browsers, or embedded widgets made from browser code, to access them. So if the Host header isn't enough, there isn't really a better answer than proper authentication. (CUPS is pretty hardened now, but one good solution for CUPS would be a command-line utility that generated a session key and printed out a URL like http://localhost:631/?auth=a1b2c3d4.)

Re: Blizzard games were vulnerable to DNS rebinding attack

#82

Post by skela224 » Tue, Jan 23, 2018, 1:38 AM UTC

Would having TLS on the localhost endpoint (without client certificates) make the attack more difficult? the browser would have to validate the localhost-returned cert against the attacker.com hostname.

Re: Blizzard games were vulnerable to DNS rebinding attack

#83

Post by emmelaich » Tue, Jan 23, 2018, 2:08 AM UTC

aplorbust wrote: post #70

A mischievous person renting a domainname can list any public or private IP addresses in her A records; and she can list any nameservers, including ones with which she has no relationship. She can list an IP address that the user may be utilising or renting. I use a fast DNS resolution solution that only queries authoritative servers and stores IPs in constant, perfect hash databases, then in kdb+. No caches. I see t…

Yep, I saw 127.0.0.1 for an A record about 20 years ago.

It was discovered when going to that name outside revealed what seemed to be a copy of our own internal webserver!

What had happened is that our webserver was on the same host as our squid proxy. So we were in fact seeing our own site under the external name.

Protection for this sort of thing is in the default squid conf these days (from memory)

Re: Blizzard games were vulnerable to DNS rebinding attack

#84

Post by cryptonector » Tue, Jan 23, 2018, 2:47 AM UTC

DrJokepu wrote: post #62

catfood wrote: post #44

Earlier quoted context omitted.

That's how it should be done yeah. Developers on Windows seem to be really loose in their use of TCP or UDP for IPC. Even my mouse driver opens up a port on 0.0.0.0.

UDP for IPC seems to be especially crazy to me. I mean sending data over TCP to localhost is basically a memcpy(), what advantages could UDP possibly have in that context?

AF_LOCAL (Unix domain) sockets suck for datagram messaging because both end-points need a filesystem name -- you can't have the client end-point be anonymous! The simplest way to have an anonymous client is to send a datagram socketpair to the server in a datagram, this way the server can respond over the socketpair -- but this is complex and significantly slower than if Unix domain datagram sockets just supported anonymous clients.

Meanwhile, if you want to write an IPC library that's portable to WIN32 and POSIX, and just about any OS that supports TCP/IP, then TCP or UDP works very well. In fact, nothing else does. But of course, you have to publish the server port number (and at least a cookie for authentication) for this somewhere (e.g., in /tmp).

Re: Blizzard games were vulnerable to DNS rebinding attack

#85

Post by eli » Tue, Jan 23, 2018, 3:00 AM UTC

gsnedders wrote: post #37

geofft wrote: post #10

Earlier quoted context omitted.

Can you explain why this is a Chrome-specific issue? I believe that it applies to all web browsers, including Internet Explorer for UNIX (which I do have access to and I can test if you would like me to confirm). I remember this being a vulnerability class with CUPS, which listens on http://localhost:631/ , about 10 years ago. In particular, note that the request is not made to localhost, it's made to a DNS name that…

> I believe that it applies to all web browsers It does not apply to late versions of Presto, where there was similar treatment of requests to various special-use addresses (after hostname resolution, if applicable) as to requests that result in TLS failures. I believe, though it's been years since I dealt with this, that this caused various enterprise sites to stop working, many of which assumed they could access in…

In any event lacking this feature is not evidence of a "leaky sandbox" in Chrome.

Re: Blizzard games were vulnerable to DNS rebinding attack

#86

Post by kibibu » Tue, Jan 23, 2018, 3:24 AM UTC

DrJokepu wrote: post #5

So basically this is a local web server that is used for IPC? Is there a reason to do local IPC over TCP/IP, rather than over named pipes / unix pipes, other than not knowing about the existence of named pipes / unix pipes?

Spotify does pretty much the same thing

Re: Blizzard games were vulnerable to DNS rebinding attack

#87

Post by kentonv » Tue, Jan 23, 2018, 3:26 AM UTC

michaelermer wrote: post #77

kentonv wrote: post #60

Earlier quoted context omitted.

Answer: The service should check that the `Host` header on every request specifies `localhost`, `127.0.0.1`, or whatever other name is normally used to access it. If the `Host` header specifies a possibly-attacker-controlled name, the service should reject the request. Explanation: The problem is that the service is relying on same-origin policy to prevent a web site running in a local browser from making requests to…

And/or simply implement CORS headers.

No, CORS doesn't apply here. CORS regulates cross-origin requests, but the attack here makes the browser think the requests are same-origin.

(Also, CORS can only be used to permit access that would normally be denied. CORS does not offer any way to deny access that is normally permitted.)

Re: Blizzard games were vulnerable to DNS rebinding attack

#88

Post by fulafel » Tue, Jan 23, 2018, 3:51 AM UTC

emmelaich wrote: post #83

aplorbust wrote: post #70

A mischievous person renting a domainname can list any public or private IP addresses in her A records; and she can list any nameservers, including ones with which she has no relationship. She can list an IP address that the user may be utilising or renting. I use a fast DNS resolution solution that only queries authoritative servers and stores IPs in constant, perfect hash databases, then in kdb+. No caches. I see t…

Yep, I saw 127.0.0.1 for an A record about 20 years ago. It was discovered when going to that name outside revealed what seemed to be a copy of our own internal webserver! What had happened is that our webserver was on the same host as our squid proxy. So we were in fact seeing our own site under the external name. Protection for this sort of thing is in the default squid conf these days (from memory)

It was a standard joke to point warez.yourdomain.country to 127.0.0.1 - I wouldn't be surprised if there were still some left and could be used for rebinding attacks!

Re: Blizzard games were vulnerable to DNS rebinding attack

#89

Post by ClassyJacket » Tue, Jan 23, 2018, 3:52 AM UTC

squiguy7 wrote: post #27

Jyaif wrote: post #11

Developer 101: if you want to do a blacklist, do a whitelist instead.

I think it depends mostly on the context. If you only want to allow a known subset of items, prefer a whitelist. If you want to avoid a subset of items, prefer a blacklist.

That's literally just the definition of a whitelist and a blacklist. I think the comment you were replying to was making the point that blacklists generally work poorly in practice and should be reconsidered where at all possible.

Re: Blizzard games were vulnerable to DNS rebinding attack

#90

Post by Tobba_ » Tue, Jan 23, 2018, 4:20 AM UTC

DrJokepu wrote: post #5

So basically this is a local web server that is used for IPC? Is there a reason to do local IPC over TCP/IP, rather than over named pipes / unix pipes, other than not knowing about the existence of named pipes / unix pipes?

While they're certainly the correct way of doing this, named pipes don't provide too many benefits under Win32; other than this little problem and having to assign a port number, of course. They're harder to debug, require a whole new slew of I/O boilerplate ontop of your existing files/TCP/UDP sockets, suffer from a bunch of weirdness when connecting, etc.

They're also pretty slow, but that isn't much of a concern here - browsers do suffer from it though (except for Edge, which uses an undocumented IPC API).