Subject: [OAUTH-WG] Endpoint Misconfiguration / Social Engineering Attack

From: Guido Schmitz <[email-masked]>
Date: Thu, 8 Oct 2020 14:17:40 +0200

Hi,

We just had a discussion in Stuttgart on the possibility of
misconfigured endpoints, i.e., an honest client uses the wrong endpoints
for interacting with some honest AS. Such a setting might be the outcome
of a social engineering attack against the administrators of a client
(e.g., the attacker disguises as an AS support agent and convinces the
client admin that some endpoint needs to be changed). If some endpoint
is configured to a URL controlled by some adversary, critical data can
leak and the attacker can even tamper with the requests to this endpoint.

Is this a realistic attack scenario? Does anybody have more insight or
data on this problem? (I think that such a scenario had been mentioned
at some OSW discussion.)

A potential mitigation against this problem could be the usage of AS
metadata discovery (RFC8414). In this case, the client only needs to set
the "issuer" to configure the endpoint URLs. A social engineering attack
to change the issuer might be less likely as a social engineering attack
to change some endpoint URLs (which a client admin might have less
understanding of). Further, using AS metadata discovery also reduces the
risk of misconfiguration at the client in general. Maybe it is a good
idea to add a recommendation for the usage of RFC8414 in the security
BCP. What do you think?

Regards,

Guido

---

From: Dave Tonge <[email-masked]>
Date: Thu, 8 Oct 2020 14:30:55 +0200

Hi Guido

We've also discussed this issue in the FAPI Working Group at the OpenID
Foundation.
We came to the conclusion that we should require the use of either RFC8414
or OpenID Connect Discovery.

I'd be in favour of adding the recommendation to the BCP.

I'm not aware of an attack in the wild in this area, but I'm definitely
aware of quite a bit of misconfiguration of clients. We've had a problem in
the UK OpenBanking space where alternative authorization endpoints were
communicated via email or hosted PDFs. In my mind this opens up social
engineering attacks that are much less likely when RFC8414 is used.

Dave

On Thu, 8 Oct 2020 at 14:18, Guido Schmitz <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

--

-- 

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
Limited which is authorised and regulated by the Financial Conduct 
Authority ("FCA"). Moneyhub Financial Technology is entered on the 
Financial Services Register (FRN 809360) at https://register.fca.org.uk/ 
<https://register.fca.org.uk/>. Moneyhub Financial Technology is registered 
in England & Wales, company registration number 06909772. Moneyhub 
Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, 
Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email 
(including any attachments) is subject to copyright, and the information in 
it is confidential. Use of this email or of any information in it other 
than by the addressee is unauthorised and unlawful. Whilst reasonable 
efforts are made to ensure that any attachments are virus-free, it is the 
recipient's sole responsibility to scan all attachments for viruses. All 
calls and emails to and from this company may be monitored and recorded for 
legitimate purposes relating to this company's business. Any opinions 
expressed in this email (or in any attachments) are those of the author and 
do not necessarily represent the opinions of Moneyhub Financial Technology 
Limited or of any other group company.

---

From: Daniel Fett <[email-masked]>
Date: Thu, 8 Oct 2020 14:39:16 +0200

Hi Guido,

> data on this problem? (I think that such a scenario had been mentioned

This scenario is also explicitly mentioned in FAPI 1.0:
https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md#markdown-header-832-client-credential-and-authorization-code-phishing-at-token-endpoint

> understanding of). Further, using AS metadata discovery also reduces the

I find it plausible that having the issuer as the single entry point
makes misconfigurations less likely.

One disadvantage could be that an attacker might use a bening-looking
issuer URL to "hide" the fact that he uses an honest server's
authorization endpoint but an attacker-controlled token endpoint. Such
attacks, however, need to be caught by mix-up mitigations anyway (see
https://danielfett.de/2020/05/04/mix-up-revisited/).

A positive side-effect of a more widespread use of RFC8414 could be that
it becomes easier to configure OAuth and new(ish) features such as PKCE
and PAR could be enabled/relied-upon by clients more easily.

> idea to add a recommendation for the usage of RFC8414 in the security

Publishing RFC8414 metadata is (almost) mandatory already, since servers
MUST declare their support of PKCE (but they can also use
deployment-specific ways to accomplish this).

I would support adding

- that servers SHOULD publish RFC8414 metadata and
- that clients SHOULD make use RFC8414 discovery.

-Daniel

-- 
https://danielfett.de