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
For a full exploit let's just use OAuth app (created by Google) that imports some data from Microsoft:
And here's the full Proof of Concept:
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="" />
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 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 and are recognized as valid e-mail addresses, however is considered an invalid one. Here are some of the subdomains that auto-corrector recognizes as valid ones are:

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):
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 domain. So to leak the OAuth token to a malicious third-party an Open Redirect in 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:
So by chaining the two bugs we are able to acquire OAuth tokens from users. The complete example is here:
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 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. through Gmail.,,

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