Re: [OAUTH-WG] Report an authentication issue

Phil Hunt <phil.hunt@oracle.com> Fri, 29 June 2012 20:16 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 3FC0521F88A0 for <oauth@ietfa.amsl.com>; Fri, 29 Jun 2012 13:16:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.124
X-Spam-Level:
X-Spam-Status: No, score=-10.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, 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 zbsafBNRyqDV for <oauth@ietfa.amsl.com>; Fri, 29 Jun 2012 13:16:11 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id CB33D21F8857 for <oauth@ietf.org>; Fri, 29 Jun 2012 13:16:10 -0700 (PDT)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5TKG7L3032358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jun 2012 20:16:08 GMT
Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q5TKG6UJ027238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 20:16:06 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q5TKG5WF021061; Fri, 29 Jun 2012 15:16:05 -0500
Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 29 Jun 2012 13:16:05 -0700
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <ABF83D8C-3C89-4616-9FA4-993592D6092B@ve7jtb.com>
Date: Fri, 29 Jun 2012 13:16:03 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <ED08EC40-0180-4071-9CA4-FED75A99D7CC@oracle.com>
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>
To: John Bradley <ve7jtb@ve7jtb.com>
X-Mailer: Apple Mail (2.1278)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
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: Fri, 29 Jun 2012 20:16:12 -0000

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
>>>>>> 
>>>>> 
>>> 
>