Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks

Hans Zandbelt <hans.zandbelt@zmartzone.eu> Fri, 17 December 2021 20:59 UTC

Return-Path: <hans.zandbelt@zmartzone.eu>
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 357F43A0781 for <oauth@ietfa.amsl.com>; Fri, 17 Dec 2021 12:59:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zmartzone.eu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPhYBsWBPrwF for <oauth@ietfa.amsl.com>; Fri, 17 Dec 2021 12:59:27 -0800 (PST)
Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EAF3A0780 for <oauth@ietf.org>; Fri, 17 Dec 2021 12:59:26 -0800 (PST)
Received: by mail-ua1-x92e.google.com with SMTP id y23so6653425uay.7 for <oauth@ietf.org>; Fri, 17 Dec 2021 12:59:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zmartzone.eu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=cRzEkwekRBR8qqHBcLSaABXIgCMn1w2XPpuV/1j2+l8=; b=FMU9czWYyQQMgjnbnfyWalNEystBT924Mv3jWDwStigJhlz3SFbuPfeYy7skxJr9Sp bA0euMMbRVN9kOHIBy9V1cKw91/USMSCUddfyqvM2ftMGwLFwIXxCyWezv3IGnSCa3K/ rP5HhNbzoxV1/o0STXsaL/HD1Dkar05nKhi6pujKUU8QDR1aeAtK6zb/u0wTntp6Mkkg 02V3mKzmvbB55+SUi+jfyIickUi0xoVO3DoZyxw5coujEKEYwY0biIwWM/EOWpWLcJE+ mYWDfKuqjgkIa9Ox4zRsDTgAZklhfYkINDNgA7leHJdSmrZDOiJfzT6tSTN7eHUGh83B Z5CQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=cRzEkwekRBR8qqHBcLSaABXIgCMn1w2XPpuV/1j2+l8=; b=yMcH0/u/e1HNG3/v6ox+Lt8RcTfYrYZG9y4dQ0rJl6eWyiwbxiNZfp7ruDFFtdRVBN g2kRW1ACoAGDtncnkAtG4sihPRXpnL8EmP7qYQ4MgEq/42JdjxW9DuGersRKXCGlPwUD /iqgOjGXRZmDte8+wAcyWRh6Z5S/NZ+kV13yxTuAXCz4wvO1FXZkkaltukw3Xhp+m3/L ueQpfvZePx5TbtrcT52oNM3S3/T86PIf6OU6NXbg/D9CusVMbue907QkHvHfdovsV2oN V9LfvwoOSu00QiZ07lcCz7trJvftMWadOyzgqf0oIU/Qzf80v/WTyRD8U4qqSOLeNSmL ZMSg==
X-Gm-Message-State: AOAM531g7WrWoYcaYlylz+yB+b2bi2MsyTHVW7i5Xd7ps/nvCM9v2k5E RXc7ZIWawJ6lQydbo7jgHZWYuYASw67u3qGtUZQMXshhTe+skw==
X-Google-Smtp-Source: ABdhPJz76dGZdazgIpLSEJ24kmQSoBX1HLmsW5rcyrl6+kQHsjZ2ebP3Yan5h3AA4qdLzz3q3fGs0oyI7Ph6qpkvbc8=
X-Received: by 2002:a67:fb42:: with SMTP id e2mr1977784vsr.56.1639774764538; Fri, 17 Dec 2021 12:59:24 -0800 (PST)
MIME-Version: 1.0
References: <CADNypP_AJFBc+HzKfFZ8d0hk7BZc=fYTDLNP6MroHUg-=r7FvQ@mail.gmail.com> <CAJot-L2X+Ma5BnXJ6Ys3UPJgHc_WnYtU33ast-myT2PN6rU5OQ@mail.gmail.com> <CAO_FVe5fUgS+=FoB9fJN7V0ujG+tDSb_20CgU2ffcPO3kENC=w@mail.gmail.com> <AM7PR83MB04521F9B225816B5D4D1A8F891789@AM7PR83MB0452.EURPRD83.prod.outlook.com> <CAJot-L2jB63K9RVK8F8PFEtOSXjJk+Eg4iJxs9qm7jt7zq1nMw@mail.gmail.com> <AM7PR83MB0452B729482E04F9B333D37791789@AM7PR83MB0452.EURPRD83.prod.outlook.com>
In-Reply-To: <AM7PR83MB0452B729482E04F9B333D37791789@AM7PR83MB0452.EURPRD83.prod.outlook.com>
From: Hans Zandbelt <hans.zandbelt@zmartzone.eu>
Date: Fri, 17 Dec 2021 21:59:13 +0100
Message-ID: <CA+iA6ujXrAqm5bY-akQyB3seD7zhZg1K26AnViOE2cHGEAvEoA@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/related; boundary="0000000000005a476805d35dd00e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/L1Lga8tahLfFhXMOQPfT4o1BhaU>
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: OAuth Redirection Attacks
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 17 Dec 2021 20:59:33 -0000

AFAIK this topic has been discussed before, e.g.:
https://mailarchive.ietf.org/arch/msg/oauth/gIuIrxeXudRBg8L6RYGDElxrc4s/

Hans.

On Fri, Dec 17, 2021 at 9:44 PM Pieter Kasselman <pieter.kasselman=
40microsoft.com@dmarc.ietf.org> wrote:

> The problem isn’t invalid URLs but malicious ones. Given a choice between
> a sub-optimal user experience and a phished end-user, perhaps an option
> that allows the authorization server to handle the error, rather than
> redirecting can serve end-users better. But as Vittorio points, out, there
> are probably other options as well to consider. URL reputation services is
> another option, but problematic since they are imperfect and I expect hard
> to standardise to a point that creates a common minimum level of assurance
> (similar to any fraud calculation or risk score).
>
>
>
> *From:* Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org>
> *Sent:* Friday 17 December 2021 20:27
> *To:* Pieter Kasselman <pieter.kasselman@microsoft.com>
> *Cc:* Vittorio Bertocci <Vittorio@auth0.com>om>; oauth <oauth@ietf.org>
> *Subject:* Re: [EXTERNAL] Re: [OAUTH-WG] OAuth Redirection Attacks
>
>
>
> You want to redirect on some errors because the last thing an AS wants is
> to leave the user in the AS because the user can't do anything there and
> the AS can't do anything either. It's just bad UX. But if the redirect url
> isn't valid, this is absolutely the time that the AS should keep the user
> there for user's protection.  Any AS redirecting the user to an invalid
> redirect url, isn't doing the right thing.
>
>
>
> But that only solves the illegitimate phishing urls, it doesn't solve the
> class of problem where a phishing application is legitimately registered.
>
>
> [image: Image removed by sender.]
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data with IAM authorization as a service. Implement
> Authress
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bD0m3JF8HeDpcw65ZHO4H29FaU2Lc6rvGwxr%2FzF52w0%3D&reserved=0>
> .
>
>
>
>
>
> On Fri, Dec 17, 2021 at 9:23 PM Pieter Kasselman <pieter.kasselman=
> 40microsoft.com@dmarc.ietf.org> wrote:
>
> Agreed that the attackers goal is to bypass phishing filters and they
> found a way to achieve this by using an IdP that adheres to the standards.
> I don’t have the context for the design choice to redirect on an error
> condition, but am curious why the IdP should not be allowed to handle the
> error condition, rather than redirect (or at least have the option to do
> so)?
>
>
>
> *From:* OAuth <oauth-bounces@ietf.org> *On Behalf Of *Vittorio Bertocci
> *Sent:* Friday 17 December 2021 19:55
> *To:* Warren Parad <wparad=40rhosys.ch@dmarc.ietf.org>
> *Cc:* oauth <oauth@ietf.org>
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] OAuth Redirection Attacks
>
>
>
> The attack doesn't rely on redirecting to unregistered URLs, that's the
> problem.
>
> The goal of the attack is to circumvent phishing filters, by presenting a
> URL from a legitimate domain (the AS) that eventually redirects to the
> actual phishing URL. The actual phishing page doesn't need to target the
> same authorization server, or an authorization server at all for that
> matter.
>
> An attacker can register a legitimate app on any authorization server as a
> service, on their own tenant. The goal is just to have a starting URL that
> phishing filters won't block, and the attacker is in full control of the
> redirect URIs they register in their own tenant.
>
>
>
> My take: it might be tricky to change the redirect on error behavior at
> this point, but we should at least note the issue in the security
> considerations/BCPs and possibly give some advice. For example, on top of
> my head: AS should expose their endpoints on a domain dedicated to
> OAuth/OIDC operations, and avoid using its top level domains (different
> area/service, but think herokuapp.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fherokuapp.com%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6oiRh6TMVJnXYUGdDJt%2BLQQI0gCtOs7au%2BU7ctOd%2Bjo%3D&reserved=0>
> vs heroku.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fheroku.com%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=egS2AEI1FmpbL09upMutgGCUtpgyEn2l1FtdDb7WCdI%3D&reserved=0>)
> so that if a phishing filter decides to block direct links to the issuing
> endpoints will only impact things like IdP initiated flows (solvable by
> adding jumpstart endpoints on the RP anyway, just like IdP initiated sign
> in works in OIDC). I am sure there are lots of other things we can come up
> with that can make the problem better.
>
>
>
> On Fri, Dec 17, 2021 at 5:00 AM Warren Parad <wparad=
> 40rhosys.ch@dmarc.ietf.org> wrote:
>
> I think this just falls into the category of never redirect the user to a
> url that doesn't match one of the preregistered redirect urls (or logout
> urls for that matter). Any application that has redirects anywhere provides
> an opportunity for this attack vector, OAuth isn't unique in that way, it
> just is consistent and documented. And the 2.1 draft is pretty clear on
> this front:
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-04#section-4.1.2.1
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-oauth-v2-1-04%23section-4.1.2.1&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=M7ZtR%2BTYVIVzXZmHaeJS6rGVLC84RUisnfl5KCF0rHg%3D&reserved=0>
>
>    If the request fails due to a missing, invalid, or mismatching
>    redirect 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    redirect
> URI*.
>
>
>
> I want to call this attack vector "*illegitimate* phishing applications"
> which is easily blocked by preregistration and/or PARs. And is only a very
> small subset of phishing attacks with OAuth, of which the larger group is "
> *legitimate* phishing applications". An app can be registered correctly,
> and still issue a phishing attack as phishing attacks through OAuth are
> actually indistinguishable from standard user delegation. There is no way
> to prevent these without an application review before registration is
> completed, here's an example that cloned Google apps y creating a fake app
> called *google defender*:
> https://www.trendmicro.com/en_us/research/17/d/pawn-storm-abuses-open-authentication-advanced-social-engineering-attacks.html
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.trendmicro.com%2Fen_us%2Fresearch%2F17%2Fd%2Fpawn-storm-abuses-open-authentication-advanced-social-engineering-attacks.html&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9kKah9zgc66ew2AD5iGhgX2Qnzbnq3UJ%2FHoHsuzUU5w%3D&reserved=0>
>
>
>
> If we can't protect against these latter ones, I hardly think protecting
> against the former is useful/interesting/valuable.
>
>
> [image: Image removed by sender.]
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data with IAM authorization as a service. Implement
> Authress
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthress.io%2F&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bD0m3JF8HeDpcw65ZHO4H29FaU2Lc6rvGwxr%2FzF52w0%3D&reserved=0>
> .
>
>
>
>
>
> On Thu, Dec 16, 2021 at 9:05 PM Rifaat Shekh-Yusef <
> rifaat.s.ietf@gmail.com> wrote:
>
> All,
>
>
>
> An article was recently published discussing some *OAuth Redirection
> Attacks* to try to bypass *phishing* detection solutions. See the details
> of these attacks in the following link:
>
>
>
>
> https://www.proofpoint.com/us/blog/cloud-security/microsoft-and-github-oauth-implementation-vulnerabilities-lead-redirection
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.proofpoint.com%2Fus%2Fblog%2Fcloud-security%2Fmicrosoft-and-github-oauth-implementation-vulnerabilities-lead-redirection&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696441984307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=itNmcvlkuKrPzG6%2F23Iod8zyH%2FqSjhcNuxJMw3dZslU%3D&reserved=0>
>
>
>
>
>
> The article discusses attacks on Microsoft and GitHub, but these attacks
> are not unique to these companies.
>
> The attacks take advantage of how OAuth handles error responses, which
> sends responses to the application’s redirect URL.
>
>
>
> I would like to get the thoughts of the working group on these types of
> attacks.
>
> What is the best way to mitigate these attacks?
>
> Do we need a new approach for handling errors with OAuth?
>
>
>
> Regards,
>
>  Rifaat
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696442034307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9S1YCx61RDItp9TtylYb4bgxMTABCZJ9MbjwUHV%2FStM%3D&reserved=0>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C10cc087500b9437ac09408d9c19b9d90%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637753696442034307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9S1YCx61RDItp9TtylYb4bgxMTABCZJ9MbjwUHV%2FStM%3D&reserved=0>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
hans.zandbelt@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu