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

Re: Blizzard games were vulnerable to DNS rebinding attack

#91

Post by benchaney » Tue, Jan 23, 2018, 5:59 AM UTC

geofft wrote: post #80

benchaney wrote: post #75

Earlier quoted context omitted.

There are a few options. IMO the best is saving ip address that each DNS name is resolved to for every connection for the duration of a windows existence.

That doesn't save you from this attack - you can send the index page and some JS over with a long Cache-Control header, and then trigger the site to get loaded some days later when DNS has been changed to point to localhost. The JS will trigger the same XHR and it will succeed this time. (.. and now that I think about caching, the various "within the same tab" solutions elsewhere in the comments don't work, because t…

Can you really reload a website just even if it is rejecting connections just using a long Cache-Control header? I find that hard to believe.

> because they'd force Gmail / OWA / Slack / etc. to get reloaded with a full cache flush when they change IP addresses

I think security issues should be fixed even if the fix imposes an inconvenience. Especially since the inconvenience is basically just a performance issue.

Side note: I don't find the idea that this attack is hard to fix a particularly strong justification for not fixing it. Not being able to connect to arbitrary hosts is deliberately not part of the API exposed to javascript so I think it would be hard to argue that DNS rebinding isn't a bug.

Side note 2: The workaround of "don't trust" localhost doesn't prevent all DNS rebinding based attacks. For instance, if you took out an ad, you could then have a botnet to bypass any ratelimiter.

Re: Blizzard games were vulnerable to DNS rebinding attack

#92

Post by Matheus28 » Tue, Jan 23, 2018, 10:37 AM UTC

geofft wrote: post #30

Matheus28 wrote: post #26

Earlier quoted context omitted.

Maybe if the address in the URL bar doesn't resolve to a local address, block access to local addresses. Might break some enterprise stuff, but better safe than sorry, put an opt out of this behind a flag.

But it does resolve to a local address. The point of rbndr is that it switches between resolving to a remote address and to a local address, which is an entirely legitimate thing - https://owa.example.com for most companies will do exactly this when you move between the corporate network and the public internet.

>But it does resolve to a local address.

Huh? The exploit allows remote website you visit ends up having access to stuff bound to localhost. If a localhost website has access to other localhost stuff, it isn't as much of a big deal.

>The point of rbndr is that it switches between resolving to a remote address and to a local address, which is an entirely legitimate thing - https://owa.example.com for most companies will do exactly this when you move between the corporate network and the public internet.

IMO it's worth blocking it, and only allowing that behind a flag or a custom whitelist that the user maintains. Enterprises can easily do that.

Re: Blizzard games were vulnerable to DNS rebinding attack

#93

Post by dooglius » Tue, Jan 23, 2018, 4:30 PM UTC

geofft wrote: post #81

dooglius wrote: post #58

Earlier quoted context omitted.

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 pret…

I know about the Host header, my thought was more about something like a Redirected-From header which would be set based on things like the host the or XHR came from. A simple sanity check on that (anything other than localhost is blocked) should suffice.

Re: Blizzard games were vulnerable to DNS rebinding attack

#94

Post by atesti » Tue, Jan 23, 2018, 10:14 PM UTC

Tobba_ wrote: post #90

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 h…

>(except for Edge, which uses an undocumented IPC API).

Do you have any links or things to google for?