[Openid-specs-fapi] Bristol man loses £8,000 in banking app scam

Mon Feb 13 18:07:17 UTC 2023

Hi Kosuke, Joseph

Although the goal of the attack in the article is not token theft, some of the ideas on defending against attacks cross-device flows might be helpful here (draft-ietf-oauth-cross-device-security-00 - Cross-Device Flows: Security Best Current Practice<https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/00/>).

The attack shares some properties with the "illicit consent grant" attacks in draft-ietf-oauth-cross-device-security-00 - Cross-Device Flows: Security Best Current Practice<https://datatracker.ietf.org/doc/draft-ietf-oauth-cross-device-security/00/>, most notably the lack of an authenticated channel between the initiating service and the authenticating device. From reading the article, this unauthenticated channel is exploited by the attacker, who changes the context of the authorization request. In this case, the change in context is achieved by calling the user and convincing them to trust the caller. The attack goes something like this.

  1.  Call the user from a number similar to the fraud line number (one-digit difference)
  2.  Initiate fraudulent transactions
  3.  Asking the user to decline the fraudulent transaction (imagine someone telling the user to "review the transaction your about to receive and decline it if you did not perform this transaction"), thereby earning the users trust.
     *   The user now considers the channel "authenticated" and will disclose sensitive information to the person who called them.
  4.  Initiating a fund transfer/request from the users account (details are sketchy - presumably there is some business process that allows this)
  5.  User receives authorization code in the app
  6.  User gives code to the attacker (who earned the users trust)
  7.  Attacker completes fund transfer.

In terms of mitigations, I would consider:

  1.  Proximity: If the OTP is being delivered to an app that is running in a different location from the one where the transaction is being initiated, this may be an indicator of risk. There are several ways to do this and requires that the system issuing the OTP compares location information with the system where the transaction is initiated. Attackers may still be able to work their way around this, but does raise the bar for a successful attack (see Cross-Device Flows: Security Best Current Practice (ietf.org)<https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-00.html#name-establish-proximity>).
  2.  Authenticated flow: Require that the user authenticates on the initiating device before initiating the flow. This prevents attackers from initiating the flow unless they can authenticate first. Not sure it would have helped in this case, but worth considering (see Cross-Device Flows: Security Best Current Practice (ietf.org)<https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-00.html#name-authenticated-flow>)
  3.  Protocol selection: Choose cross-device protocols that are more resilient against exploits aimed at the unauthenticated channel (e.g. WebAuth/FIDO passkeys Cross-Device Flows: Security Best Current Practice (ietf.org)<https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-00.html#name-fido2-webauthn>)

Defending against social engineering attacks is very hard, and at some point, technology cannot prevent a user who is convinced/intent on authorizing a transaction. At this point it is important to help the customer recover if they were tricked.

Cheers

Pieter

From: Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> On Behalf Of Joseph Heenan via Openid-specs-fapi
Sent: Thursday, February 9, 2023 5:29 PM
To: Openid-specs-fapi <openid-specs-fapi at lists.openid.net>
Cc: Joseph Heenan <joseph at authlete.com>
Subject: Re: [Openid-specs-fapi] Bristol man loses £8,000 in banking app scam

You don't often get email from openid-specs-fapi at lists.openid.net<mailto:openid-specs-fapi at lists.openid.net>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hi Kosuke

On 9 Feb 2023, at 14:51, Kosuke Koiwai via Openid-specs-fapi <openid-specs-fapi at lists.openid.net<mailto:openid-specs-fapi at lists.openid.net>> wrote:

FYI

Is there anything we can do?

https://www.bbc.com/news/uk-england-bristol-64559260<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bbc.com%2Fnews%2Fuk-england-bristol-64559260&data=05%7C01%7Cpieter.kasselman%40microsoft.com%7C67bacbbb04fc4732f28f08db0ac33155%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638115605911173526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=JyUloKeOql3qYuT%2FTVj%2BvbjNcXLEpv%2B6PBhy%2Fc2qrjs%3D&reserved=0>

As I understand it, the scam works something like this:

The user's debit card details have been obtained by the scammer.

The scammers try to make payments online using these details, which triggers Mastercard secure3d ( https://www.starlingbank.com/blog/introducing-3D-secure/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.starlingbank.com%2Fblog%2Fintroducing-3D-secure%2F&data=05%7C01%7Cpieter.kasselman%40microsoft.com%7C67bacbbb04fc4732f28f08db0ac33155%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638115605911173526%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=OkvQfLKyyNFtO%2B3kCgsiypPub6s0Eeq9a7v8MrbGXUI%3D&reserved=0> ).

The user generates a code in their app, which has copious warnings not to share it (screenshots attached).

I don't understand the details/limitations of 3d secure, but this feels like the classic problem of OTPs not being context specific - i.e. it's generally better to have a prompt like "Do you want to approve a transaction of £1523.43 to Amazon Gift Cards?", although for some reason many of the 3d secure prompts I've seen do have a fallback to an sms issued OTP (but again, at least they can include the context in the SMS).

Thanks

Joseph

[cid:image001.jpg at 01D93FC1.5D3B36A0][cid:image002.jpg at 01D93FC1.5D3B36A0]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20230213/5aadd26f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 67278 bytes
Desc: image001.jpg
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20230213/5aadd26f/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 56994 bytes
Desc: image002.jpg
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20230213/5aadd26f/attachment-0003.jpg>