Re: [OAUTH-WG] Phishing with Client Application Name Spoofing

Mark Mcgloin <mark.mcgloin@ie.ibm.com> Fri, 16 December 2011 12:09 UTC

Return-Path: <mark.mcgloin@ie.ibm.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 CD13C21F8B4F for <oauth@ietfa.amsl.com>; Fri, 16 Dec 2011 04:09:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.291
X-Spam-Level:
X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, J_CHICKENPOX_75=0.6]
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 3Q9mAd4zAN65 for <oauth@ietfa.amsl.com>; Fri, 16 Dec 2011 04:08:59 -0800 (PST)
Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBE021F8B2F for <oauth@ietf.org>; Fri, 16 Dec 2011 04:08:59 -0800 (PST)
Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <oauth@ietf.org> from <mark.mcgloin@ie.ibm.com>; Fri, 16 Dec 2011 12:08:52 -0000
Received: from d06nrmr1707.portsmouth.uk.ibm.com ([9.149.39.225]) by e06smtp13.uk.ibm.com ([192.168.101.143]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 16 Dec 2011 12:08:49 -0000
Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pBGC8mR92686990 for <oauth@ietf.org>; Fri, 16 Dec 2011 12:08:49 GMT
Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pBGC8mTX021702 for <oauth@ietf.org>; Fri, 16 Dec 2011 05:08:48 -0700
Received: from d06ml091.portsmouth.uk.ibm.com (d06ml091.portsmouth.uk.ibm.com [9.149.104.170]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pBGC8mkD021697 for <oauth@ietf.org>; Fri, 16 Dec 2011 05:08:48 -0700
X-KeepSent: 89CAB6D0:846918A4-80257968:003F9F0B; type=4; name=$KeepSent
To: OAuth WG <oauth@ietf.org>
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: <OF89CAB6D0.846918A4-ON80257968.003F9F0B-80257968.0042BA35@ie.ibm.com>
From: Mark Mcgloin <mark.mcgloin@ie.ibm.com>
Date: Fri, 16 Dec 2011 12:08:44 +0000
X-MIMETrack: Serialize by Router on D06ML091/06/M/IBM(Release 8.5.2FP1 ZX852FP1HF12|September 28, 2011) at 16/12/2011 12:08:43
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
x-cbid: 11121612-2966-0000-0000-000002A56721
Subject: Re: [OAUTH-WG] Phishing with Client Application Name Spoofing
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, 16 Dec 2011 12:09:00 -0000

Andre

You are right that the threat model does not cover this kind of issue
related to client registration. Client registration is considered to be out
of scope in the oauth spec but it is worth drawing developers attention to
this.  I can add a threat entitled something like "Client Registration of
phishing clients". It kind of reminds me of the issues android market place
has seen recently with malware apps due to no vetting of those apps.

It is touched upon in the oauth 2 rfc:
http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-2

Regards
Mark


On 3 Nov 2011 17:09:39, "Andre DeMarre" wrote:


You are right that they are similar, but there is a difference, and
only one of the six countermeasures is relevant to the threat I
described.

http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-4.4.1.4

seems to be about an attack where the malicious client impersonates a
different (valid) client that is registered with the authorization
server. In other words, the valid client is registered as client_id
123, and the malicious client does not have its own client_id but
tries to pose as client 123. This corresponds to
http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-10.2.

In the threat I described, there is no valid client. The malicious
client is properly registered with the authorization server and has
its own client_id and client credentials. It can authenticate with the
authorization server without trying to pose as a different client.

As an attacker you might reason, "Why would I try to impersonate a
valid client for which I don't know the client credentials and can't
pass the redirect URI test, when I can just register my own client
with my own redirect URI and be given my own credentials?"

Imagine the attacker wants to impersonate Google with a popular web
service called Foobar. The attacker registers his application with
Foobar's auth server. It does not matter if the real Google has
registered an authentic app with Foobar. The attacker has no reason to
be interested in stealing or guessing client credentials when he can
simply register his own app and call it "Google".

The information the auth server shows to end users when asking them to
grant authorization becomes very important.
Regards,Andre DeMarre
On Wed, Nov 2, 2011 at 2:27 PM, Torsten Lodderstedt
<torsten at lodderstedt.net> wrote:
> Hi Andre,
>
> how do you think differs the threat you descibed from
>
http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-01#section-4.4.1.4
?
>
> regards,
> Torsten.