Friday, September 18, 2015

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:

Wednesday, April 15, 2015

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:

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

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

A lot has been written about dangers of mistakes in OAuth implementations. Here’s another story.
Microsoft uses a specialized OAuth scope wli.contacts_emailswhich 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 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:

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 disclosureUpdate [2014/09/17]: Microsoft has fixed the OAuth vulnerability

Friday, January 3, 2014

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

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.