Re: [OAUTH-WG] Report an authentication issue

Phil Hunt <phil.hunt@oracle.com> Sat, 30 June 2012 08:11 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B786221F87A9 for <oauth@ietfa.amsl.com>; Sat, 30 Jun 2012 01:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.412
X-Spam-Level:
X-Spam-Status: No, score=-9.412 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2YQ7gw4NE82 for <oauth@ietfa.amsl.com>; Sat, 30 Jun 2012 01:11:20 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id A39CE21F87AF for <oauth@ietf.org>; Sat, 30 Jun 2012 01:11:18 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5U8BFdL026993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Jun 2012 08:11:16 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5U8BEvW003289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jun 2012 08:11:15 GMT
Received: from abhmt112.oracle.com (abhmt112.oracle.com [141.146.116.64]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5U8BETv003000; Sat, 30 Jun 2012 03:11:14 -0500
Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 30 Jun 2012 01:11:14 -0700
References: <CAEEmcpEcNqNHwfVozD-NtfkruiB-v0MTszwNL4cob2rL=QQTSA@mail.gmail.com> <4FE223E4.6060307@mitre.org> <4FE226BC.6010403@alcatel-lucent.com> <59E470B10C4630419ED717AC79FCF9A910889AB5@BL2PRD0410MB363.namprd04.prod.outlook.com> <CABzCy2CLe_DVcxiD1EasuhtG1_6+6tCtV5TckZ80fvqyjan_bA@mail.gmail.com> <59E470B10C4630419ED717AC79FCF9A917052BC8@SN2PRD0410MB370.namprd04.prod.outlook.com> <4FE37D38.1030407@gmail.com> <CABzCy2A_zJ3vaauoo6VwsmLWsTesdTujuQ4dHdVpc5Nh==iEFg@mail.gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2C8949@CH1PRD0410MB369.namprd04.prod.outlook.com> <CABzCy2DzmNgmMALNfc1qp95fwD2WULb-49Dk yLiZnjXngAmaPg@mail.gmail.com> <59E470B10C4630419ED717AC79FCF9A91A2D1309@CH1PRD0410MB369.namprd04.prod.outlook.com> <496AFB1D-A609-4188-B92D-2185E8880388@ve7jtb.com> <59E470B10C4630419ED717AC79FCF9A91A2D13C9@CH1PRD0410MB369.namprd04.prod.outlook.com> <67F8B633-E4C8-42F6-B84C-FDBC337B7EEA@ve7jtb.com> <04C05FAA-63BC-4441-8540-36280E40DB98@adobe.com> <4FEDE4AF.9030107@mitre.org> <! ! ! ! ! ! ! ! ! ! ! 4 DD23AA1-C319-477A-B0CB-34E558EB7FCC@ve7jtb.com> <8C18C43D-AC63-465A-ADC2-966CE7F38685@gmail.com> <71899C6B-40A6-46E8-BCF8-BF9C43B83C64@oracle.com> <83124DF5-8D21-4D63-9D37-BBFBA0932065@ve7jtb.com> <353091D2-F63F-4D48-A49B-99E53FE31954@oracle.com> <7ED8AA4B-85D0-4D60-AFB6-C50503042A52@ve7jtb.com> <9DFCB89E-39E2-4F70-A9F8-4D245800D798@oracle.com> <ABF83D8C-3C89-4616-9FA4-993592D6092B@ve7jtb.com> <ED08EC40-0180-4071-9CA4-FED75A99D7CC@oracle.com> <CB16A60B-7BD2-4AA7-B316-7EB1635CAFDE@ve7jtb.com> <7A8FC3E0-79E4-403D-8A4E-16CBCD55C565@oracle.com> <904BFB7C-0A84-427F-BA06-CBEE90FCCF53@ve7jtb.com>
In-Reply-To: <904BFB7C-0A84-427F-BA06-CBEE90FCCF53@ve7jtb.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"
Message-Id: <D3C4BF60-204C-4976-8C39-43076CB2460B@oracle.com>
X-Mailer: iPhone Mail (9B206)
From: Phil Hunt <phil.hunt@oracle.com>
Date: Sat, 30 Jun 2012 01:11:12 -0700
To: John Bradley <ve7jtb@ve7jtb.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Report an authentication issue
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jun 2012 08:11:26 -0000

John,

Thanks. I am not understanding yet. But if you believe there is a problem that is enough for me. I do not mean in any way dismiss it.

Do you think the issue you described is different from the original message that started this thread? It seems so to me.  

Phil

On 2012-06-29, at 20:34, John Bradley <ve7jtb@ve7jtb.com> wrote:

> Phil,  
> 
> You know not everyone gets a personalized example:)
> 
> In the below examples there is no proxy or other compromise of the client required only the ability to do what appears to be a SSO login using OAuth.
> The attacker needs only a web browser.
> 
> When they tales about compromised clients,  they are not talking about needing to compromise the app on the users phone.
> 
> They can compromise a client on there platform e.g. load it into a iPhone emulator, or just create a new client that emulates the backend API.
> 
> There are already script kits to exploit this.   The vulnerability was distributed in API kits from Faceboo, Apple and others.
> 
> If it was just one developer getting it wrong that would be one thing,  hundreds getting it wrong by using the API in trusted development kits is a much worse problem in my opinion.
> 
> My hope is to at least make it clear to the library authors and tool venders, what are unsafe patterns.
> 
> This exploit is unfortunately not hypothetical.
> 
> John B.
> 
> 
> On 2012-06-29, at 7:31 PM, Phil Hunt wrote:
> 
>> See below...
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>> 
>> 
>> 
>> 
>> 
>> On 2012-06-29, at 1:54 PM, John Bradley wrote:
>> 
>>> No,
>>> 
>>> Trying to explain this over email is a challenge:)
>>> 
>>> This apples to both native apps and Web Servers who are OAuth Clients.
>>> 
>>> Imagine there are two web servers that authenticate people with Facebook Connect (just an example).
>>> 
>>> Site A is I love Puppies   (An evil site)
>>> Site B is I Hate Larry Ellison  (A good site)
>>> 
>>> You as a chocolate lover go to Site A and login to get some cool free screensaver of Puppies.
>>> Site A gets a token for your social graph no big deal mostly public stuff.  However they discovery you work for Mr Evil who they think is purchasing paradise to put up a parking lot.
>> 
>> Ummm....ok. I didn't want to go political on this. ;-)
>>> 
>>> They then go to site B who is using the implicit flow for Facebook authentication.  They login using a web browser but using any one of a number of browser plugins modify the response to have the access_token that they got from you when you logged into their site.   They now post as you telling everyone that Larry can't sail and has bad fashion sense. (Perhaps true)  You might now have some explaining to do!
>> 
>> Soooo...according to the specs, there are now TWO mistakes:
>> 
>> 1. Implicit is intended ONLY for java script clients in the browser. Implicit clients shouldn't have any data of value (at least retained data). 
>> 
>> 2. The MS example states that they have control of the client application and its communications.
>> 
>> Do we need to make #1 even more clearer -- an entire paragraph in all caps maybe? ;-)
>> 
>> Since the researchers put a proxy server in between the app and Facebook. Therefore ANY OAUTH flow would be compromised since they are able to insert tokens into the flow.  Adding client id isn't going to help (so I agree with you there).
>> 
>> But I point out this hack only works if you can intercept the communications path.
>> 
>> If we were talking about some sports network on a public internet site, this problem wouldn't come up unless that hackers have access to the web sites physical network and can reconfigure the clients proxy server settings.
>> 
>> In the end, I don't think this is a valid *oauth* security issue since the assumption is a compromised client and/or communications path. This is a network security issue.
>> 
>> 
>>> It would be worse if Site B had some PII about you or could transfer the money from your bank based on that authentication.
>> 
>>> 
>>> The same thing could happen with the code flow if the client is public and doesn't have a secret.   Site A doesn't use the code themselves when you login,  they just let you through to get the puppy photos.
>> Agreed.
>>> They immediately take the token to site B and paste it into a legitimate response (note the client_id is not in the response or code ) the public client then presents that to the token endpoint with it's client_id to get the access_token.   The token endpoint just hands it over because without a client_secret it is not required to authenticate the client.
>>> 
>>> What Dick and I are saying is that we don't see the need not to verify the client_id in the request to the token endpoint.  If it were required clients would not be able to mistakenly accept codes issued to diffrent clients.
>> 
>>> 
>>> I strongly suspect most implementations do that already, so why not clarify the spec on that point.   
>> 
>>> 
>>> That won't stop the attack on implicit clients.
>>> 
>>> This is why openID 2.0, openID Connect, SAML and every other identity protocol I can think of audience restrict the assertion to the intended recipient and sign or integrity protect the response.
>>> 
>>> That is not needed for the typical authorization use case of OAuth, but is a really good idea if you are asserting Authentication information to the client.
>>> 
>>> No puppies were hurt in the creation of this message.
>>> John B.
>>> 
>>> On 2012-06-29, at 4:16 PM, Phil Hunt wrote:
>>> 
>>>> John,
>>>> 
>>>> I think that helps to clarify the authorize issue.
>>>> 
>>>> But they were talking about a phishing site obtaining a legit access token from Facebook.
>>>>> Let's take Soluto's metro app as an example to describe the problem. The app supports Facebook Login. As an attacker, we can write a regular Facebook app. Once the victim user allows our app to access her Facebook data, we receive an access_token from the traffic. Then, on our own machine (i.e., the "attacker" machine), we run the metro app of Soluto, and use a HTTP proxy to insert the victim's access_token into the traffic of Facebook login. Through this way, we are able to log into the victim's Soluto account from our machine. Other than Soluto, we also have confirmed the same issue on another Windows 8 metro-app Givit.
>>>> 
>>>> 
>>>> Important: the attack works because the researchers had control of the client application.  And thus they were able to insert the token between the metro client app and the server because they are able to get in the communications path. All bets are off. If the attacker can insert a token then can insert appropriate client_id's and responses in the stream as well.
>>>> 
>>>> Phil
>>>> 
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 2012-06-29, at 1:00 PM, John Bradley wrote:
>>>> 
>>>>> The attack requires a web browser that allows modifying the value of the of the redirect URI.   It is dead simple cut token or code from the string and paste in the token or code that was granted by the user you want to impersonate.
>>>>> 
>>>>> OAuth responses are not signed or audience restricted to the client(except confidential clients using the code flow).  
>>>>> 
>>>>> In cases where the code or token is passed over a back channel to a server, faking the entire client is the easiest thing for the attacker.
>>>>> 
>>>>> I don't consider these to be authorization attacks,  rather attacks on a client that is inappropariatly making unwarranted assumptions about the presenter of the token.
>>>>> 
>>>>> John B.
>>>>> On 2012-06-29, at 3:29 PM, Phil Hunt wrote:
>>>>> 
>>>>>> We need more info on the inject method the researchers used before we can account for it. 
>>>>>> 
>>>>>> Phil
>>>>>> 
>>>>>> On 2012-06-29, at 12:16, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>>>>> 
>>>>>>> The same thing can be done with code.
>>>>>>> 
>>>>>>> If the token endpoint checks the client_id before giving out the access token then the attack on code can be prevented, as the token endpoint won't return the access token.
>>>>>>> 
>>>>>>> The spec dosen't require authenticating public clients currently so it is a slightly more difficult attack but possible.
>>>>>>> 
>>>>>>> Dick and I are suggesting closing the hole at the token endpoint so that nether confidential nor public clients using the code flow are susceptible to this substitution attack.
>>>>>>> 
>>>>>>> John B.
>>>>>>> 
>>>>>>> On 2012-06-29, at 2:53 PM, PhiIt helps with the code flow when l Hunt wrote:
>>>>>>> 
>>>>>>>> I'm not seeing how client id helps if a proxy server is somehow involved with inserting the bearer token as the researchers suggested. 
>>>>>>>> 
>>>>>>>> Phil
>>>>>>>> 
>>>>>>>> On 2012-06-29, at 11:30, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>>>>>>> 
>>>>>>>>> I think they only exploited the implicit flow.   
>>>>>>>>> 
>>>>>>>>> My point was that there is a way you could do the same thing with code if it is a public client that is not authenticating to the token endpoint.
>>>>>>>>> 
>>>>>>>>> In general making identity assumptions in the client based on a code or access_token has risks that are out of scope for OAuth.
>>>>>>>>> 
>>>>>>>>> We do however want to provide good advice about specific things that can leave systems insecure when using OAuth.
>>>>>>>>> 
>>>>>>>>> John B.
>>>>>>>>> 
>>>>>>>>> On 2012-06-29, at 2:22 PM, Phil Hunt wrote:
>>>>>>>>> 
>>>>>>>>>> I'm not clear whether the MS Security Researcher hack was with the authorization code or the access token. If the latter, the client_id is out of the picture isn't it?
>>>>>>>>>> 
>>>>>>>>>> Phil
>>>>>>>>>> 
>>>>>>>>>> @independentid
>>>>>>>>>> www.independentid.com
>>>>>>>>>> phil.hunt@oracle.com
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On 2012-06-29, at 11:14 AM, Dick Hardt wrote:
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Jun 29, 2012, at 11:06 AM, John Bradley wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> It is nice to know that I may occasionally be correct:)
>>>>>>>>>>> 
>>>>>>>>>>> You must be delighted when it happens! ;)
>>>>>>>>>>> 
>>>>>>>>>>>> While you may assume that it is reasonable for a client with a code to make a request to the token endpoint including it's client_id and the server to only give out the access token if the client_id in the token request matches the one in the original authorization request.   However the spec specifically doesn't require that.
>>>>>>>>>>> 
>>>>>>>>>>> I think that is an error in the spec and should be changed, or text adding saying that the client_id SHOULD be checked.
>>>>>>>>>>> 
>>>>>>>>>>> -- Dick
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>