Anatomy of an Attack: How I Hacked StackOverflow (2012) | Hacker News Reader

Anatomy of an Attack: How I Hacked StackOverflow (2012)

blog.ircmaxell.com

83 pointschdir20 comments

Inband signalling is such a terrible idea and is so hard to get right. Here's the next step: try screwing up how you write headers. Use line wrapping and comments[1], or mix up crlf with just cr or lf. Very possible you'll make one proxy ignore your malicious header, but have the next HTTP software take it. This type of attack can be called "confused deputy".

This same issue exists on many VoIP networks as they share the same broken parsing ideas (in SIP).

1: HTTP allows you to line wrap headers and add comments. It's stupidly bizarre. It comes from the 70s or 60s where you wouldn't have a client program, so human-formatted headers weren't just a debug benefit, but a necessary requirement. The IETF can be rather clueless, so they blindly copy these terrible ideas into new protocols, like HTTP and SIP.

like having your web services stop if the end of your url is some magic string. Inband signalling is impossible to get right in my opinion.

Actually, most header fields don't allow comments. The most common one that does (User-Agent) isn't exactly necessary for processing, and is its own little world of bizarre pain.

There's a lot of historical header abuse caused by the fact that HTTP sort of shared a syntax with email MIME headers, but HTTP implementations have generally started treating such abuses as malformed. (MIME on the other hand still hasn't. It's actually quite gory.)

IP white-listing can be great until you one day add a load balancer and all requests now come from a trusted IP :P

Lesson learned: Add more "layers" of security.

What was the advantage of directing your requests through ssh and Squid, as opposed to just ssh? Squid page talks about reducing bandwidth, was that it?

By using Squid you can easily proxy requests using (for example) HTTP_PROXY environment variable, Squid can then be exposed over ssh. Proxying over socks (-D) or every individual website (-L) becomes rather tiresome. Not all programs will be able to do socks proxies but most can do http proxies - http/1.1 over nc can use a http proxy!

I'd say the point is valid though if the only function the tunnel is supposed to fulfil is channelling traffic from and to a web browser.

As far as browsers go, only Internet Explorer lacks SOCKS5 support. And I doubt an office which such stringent header filtering has an IT department that doesn't provide people with proper browsers...

I'd actually argue that an office with stringent and archaic filtering of internet use is precisely the type of office to provide only IE, laden with corporate spyware.

I think this is the perfect example of why you shouldn't trust values that can be sent or modified from the client.

It sounds like this was the root of the problem:

> But IIS was misconfigured to rewrite Remote_Addr from X-Forwarded-For if it existed.

Does anyone know why that might've happened? Is this something IIS does by default, something it inadvertently encourages, etc.? And is there another example of a web server doing something like this?

I think if its running infront of a proxy this is the default behavior. I think this is configured in other web servers like nginx, etc.

> Not only was I not denied access, but I was granted full access to everything. I had the developer console to see what people were doing.

Now THAT would be an awesome screenshot.

With lots of censor bars.

I wouldn't mind that; I just like peeking at internal admin panels and observing how much design effort a company or individual decides to put into an "industrial" software system that's only meant for internal and/or limited use.

Considering it'd be looking at live data, I would be somewhat freaked out if censor bars weren't present.

Interesting.

As an aside, I find this phrase strange, given the context:

"The SO team was absolutely incredible to deal with during this. They were fast, responsive and reasonable."

What is strange about it? Fast should be clear. Responsive I'm guessing indicates they talked it over (related to fast probably). And reasonable I'm guessing means didn't threaten to sue him for hacking SO and accepted their mistake and wanted to fix it.

Too bad that StackOverflow doesn't have an official bug bounty or even a wall of fame.

They actually have a wall of fame: http://stackexchange.com/about/security

It's not accurate though. I found a vulnerability on StackExchange too and am not listed although it was fixed.

Also I'm pretty sure that I've read much more StackExchange vulnerabilities as there are listed here.

Its the expectation / perspective he had. He is talking like someone who had to report the problem, who had to have his issue resolved and was really pleased with the service.

Its not like he just bought an iPhone which had a flaw and he was happy with the customer service that resolved the issue, but it reads like that.

To be more blunt, he is using rhetoric in his article, probably acquired through osmosis from reading other articles, without actually realizing that the rhetoric doesn't apply to his situation.

Reply on news.ycombinator.com