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

[Daniel Fett <[e-mail]>]

Hi Guido,

Am 08.10.20 um 14:17 schrieb Guido Schmitz:
> 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.)

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

> 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

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.

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

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