Subject: [OAUTH-WG] Device Authorization Grant and Illicit Consent Exploits

From: Pieter Kasselman <[email-masked]>
Date: Thu, 17 Mar 2022 21:09:27 +0000

Hi All

One of the agenda items for IETF 113 is the device authorization grant flow (aka device code flow), scheduled for Thursday 24 March 2022.  Before the meeting, I wanted to share a bit more information for those interested in the topic and also give those who are unable to attend in person an opportunity to participate in the conversation.

The Device Authorization Grant Flow (RFC 8682)<https://datatracker.ietf.org/doc/html/rfc8628> solves an important problem by enabling authorization flows on devices that are unable to support a browsers or have limited input capabilities. However, looking back over the past 18-24 months, there have been a number of practical exploits published that use social engineering techniques applied to the device authorization grant flow.

The goal of the session at IETF 113 is to discuss the patterns of the exploits that are known and start a conversation on what (if anything) we should do, based on what we are learning.

These exploits follow a general man-in-the-middle (MITM) pattern, where the attacker:

  1.  Initiates the Device Authorization Grant flow on a device under their control,
  2.  Presents the user code in a context that the end-user is likely to act on (using social engineering techniques), and
  3.  Once the user grants access, retrieves the access and refresh tokens and uses them to access the user’s resources.

Some of the exploits are described here for those interested in more detail:

  1.  The Art of the Device Code Phish - Boku (0xboku.com)<https://0xboku.com/2021/07/12/ArtOfDeviceCodePhish.html>
  2.  Microsoft 365 OAuth Device Code Flow and Phishing | Optiv<https://www.optiv.com/insights/source-zero/blog/microsoft-365-oauth-device-code-flow-and-phishing>
     *   optiv/Microsoft365_devicePhish: A proof-of-concept script to conduct a phishing attack abusing Microsoft 365 OAuth Authorization Flow (github.com)<https://github.com/optiv/Microsoft365_devicePhish>
  3.  Introducing a new phishing technique for compromising Office 365 accounts (o365blog.com)<https://o365blog.com/post/phishing/#new-phishing-technique-device-code-authentication>
  4.  DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth Authentication Flows - YouTube<https://www.youtube.com/watch?v=9slRYvpKHp4>

In terms of a response, there are a few options that come to mind (these are not exhaustive, I would love to see what others have in mind as well):

  1.  Do nothing: We can choose to leave everything as is. The downside of this is that the lessons we are learning are not getting disseminated or resulting in reduced risks.
  2.  Update the recommendations: We can document the social engineering exploits and recommend some additional mitigations as well as recommendations in terms of use cases. Although these types of "phishing"/social engineering attacks are called out in the security considerations in RFC 8628 - OAuth 2.0 Device Authorization Grant<https://datatracker.ietf.org/doc/html/rfc8628>, we can add further mitigations to create greater defence in depth. This will help future implementers and may even be useful for future protocols that rely on a similar cross-device authentication and authorization flows.
  3.  Explore alternatives: Develop, adopt, or evolve new protocols that address the scenario while mitigating or avoiding the risks.

Option A does not do much to improve the state of the art. Option B feels like something we can do now, and we may learn something along the way that can help inform Option C, which may be much further down the road and require more research. What other options come to mind?

I’m looking forward to the conversation and hearing what others are thinking about this topic.

Cheers,

Pieter

---

From: Shane B Weeden <[email-masked]>
Date: Thu, 17 Mar 2022 21:20:59 +0000

Isn’t this essentially what is mitigated in the FAPI-compliant OIDC CIBA by:
1. Requiring the client to initiate the flow with signed request parameters which include, via some hint, the resource owner for whom authentication is being requested
2. Requiring that the OP check that the resource owner approving the grant is the same as that the client associated with the request in step 1

I realise this requires that the client obtains an indication of the username of the resource owner up front to kick things off, but short of this I cannot think of any practical mitigation.

On 18 Mar 2022, at 7:09 am, Pieter Kasselman <pieter.kasselman=[email-masked]<mailto:pieter.kasselman=[email-masked]>> wrote:

ant problem by enabling authorization flows on devices that are unable to support a browsers or have limited input capabilities. However, looking back over the past 18-24 months, there have been a number of practical exploits published that use social en

---

From: "Brock Allen" <[email-masked]>
Date: Thu, 17 Mar 2022 17:24:32 -0400

I watched one of those videos and it seems to be that a proper consent screen would have been the best and easiest line of defense. Is there something more to the attacks where a better consent page (or any consent page for that matter) would not have been sufficient?

-Brock
On 3/17/2022 5:10:35 PM, Pieter Kasselman <pieter.kasselman=[email-masked]> wrote:
Hi All 

The Device Authorization Grant Flow (RFC 8682) [https://datatracker.ietf.org/doc/html/rfc8628] solves an important problem by enabling authorization flows on devices that are unable to support a browsers or have limited input capabilities. However, looking back over the past 18-24 months, there have been a number of practical exploits published that use social engineering techniques applied to the device authorization grant flow. 

 
* Initiates the Device Authorization Grant flow on a device under their control, 
* Presents the user code in a context that the end-user is likely to act on (using social engineering techniques), and 
* Once the user grants access, retrieves the access and refresh tokens and uses them to access the user’s resources. 

* The Art of the Device Code Phish - Boku (0xboku.com) [https://0xboku.com/2021/07/12/ArtOfDeviceCodePhish.html] 
* Microsoft 365 OAuth Device Code Flow and Phishing | Optiv [https://www.optiv.com/insights/source-zero/blog/microsoft-365-oauth-device-code-flow-and-phishing] 
* optiv/Microsoft365_devicePhish: A proof-of-concept script to conduct a phishing attack abusing Microsoft 365 OAuth Authorization Flow (github.com) [https://github.com/optiv/Microsoft365_devicePhish] 
* Introducing a new phishing technique for compromising Office 365 accounts (o365blog.com) [https://o365blog.com/post/phishing/#new-phishing-technique-device-code-authentication] 
* DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth Authentication Flows - YouTube [https://www.youtube.com/watch?v=9slRYvpKHp4] 

* Do nothing: We can choose to leave everything as is. The downside of this is that the lessons we are learning are not getting disseminated or resulting in reduced risks. 
* Update the recommendations: We can document the social engineering exploits and recommend some additional mitigations as well as recommendations in terms of use cases. Although these types of "phishing"/social engineering attacks are called out in the security considerations in RFC 8628 - OAuth 2.0 Device Authorization Grant [https://datatracker.ietf.org/doc/html/rfc8628], we can add further mitigations to create greater defence in depth. This will help future implementers and may even be useful for future protocols that rely on a similar cross-device authentication and authorization flows. 
* Explore alternatives: Develop, adopt, or evolve new protocols that address the scenario while mitigating or avoiding the risks. 

 
Cheers, 
Pieter

---

From: Pieter Kasselman <[email-masked]>
Date: Fri, 18 Mar 2022 12:21:53 +0000

Hi Brock

Great point, and I would agree that better consent screens could help, but I don’t think it is sufficient.

One of the challenges with consent screens is that it makes assumptions about the users abilities when they are being asked to make decisions about things they do not fully appreciate or understand. In addition, they are in a rush, are often trying to be helpful and prone to grant consent (the framing in these social engineering attacks can be very persuasive). Even users who are aware of these exploits and understand the systems they interact with are prone to be misled. Better guidance on the consent screen is definitely something we should provide.

I do think there is a defence in depth strategy that can reduce risk by (1) avoiding asking the user for a decision by making back-end risk decisions (2) augmenting the information presented to the user when making the decisions and (3) mitigating against a decision made in error.

Proximity and location information can for instance be used to bind user codes to specific locations or inform the user on where the user code was first presented, device status and/or location may be used to make decisions on whether to allow device code flows to be used in the first place and use of token binding (e.g. DPoP) may help defend against attackers who are able to exfiltrate tokens from a device and make lateral attacks.

Anything we can do to encourage implementor to ask users to make fewer decision, help them make better decisions and then protecting them in case of a bad decision will help drive down risk.

Cheers

Pieter

From: Brock Allen <[email-masked]>
Sent: Thursday 17 March 2022 21:25
To: Pieter Kasselman <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Re: [OAUTH-WG] Device Authorization Grant and Illicit Consent Exploits

-Brock

On 3/17/2022 5:10:35 PM, Pieter Kasselman <pieter.kasselman=[email-masked]<mailto:pieter.kasselman=[email-masked]>> wrote:

Hi All

The Device Authorization Grant Flow (RFC 8682)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8628&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884440262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=EswcNYKNZWEAWLBuOvQytd8TMlgpgUxIk0E%2FlfKkRIk%3D&reserved=0> solves an important problem by enabling authorization flows on devices that are unable to support a browsers or have limited input capabilities. However, looking back over the past 18-24 months, there have been a number of practical exploits published that use social engineering techniques applied to the device authorization grant flow.

  1.  The Art of the Device Code Phish - Boku (0xboku.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F0xboku.com%2F2021%2F07%2F12%2FArtOfDeviceCodePhish.html&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884440262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2B71AMxS1m4aBTrX8e76UiXs%2Fa%2F22dfxen1pI9Ln17Ig%3D&reserved=0>
  2.  Microsoft 365 OAuth Device Code Flow and Phishing | Optiv<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.optiv.com%2Finsights%2Fsource-zero%2Fblog%2Fmicrosoft-365-oauth-device-code-flow-and-phishing&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884440262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=I6tnZsOgj6fl9aYbfXe98wKf%2B5M7X%2FHEu8Umn3cui7Q%3D&reserved=0>

     *   optiv/Microsoft365_devicePhish: A proof-of-concept script to conduct a phishing attack abusing Microsoft 365 OAuth Authorization Flow (github.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foptiv%2FMicrosoft365_devicePhish&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884440262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=hVXdTbLAkdBXAepI26qG5J3poSzquok1sgUwdLGPNTg%3D&reserved=0>

  1.  Introducing a new phishing technique for compromising Office 365 accounts (o365blog.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fo365blog.com%2Fpost%2Fphishing%2F%23new-phishing-technique-device-code-authentication&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884490234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=KXDXJ8dDBdKxT72jIl8pa2BksAXiKc8N0%2F0NThYiN5Q%3D&reserved=0>
  2.  DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth Authentication Flows - YouTube<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D9slRYvpKHp4&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884490234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=KWmBAf3pYGdVzT6LeNhgT7t%2BybfnFdGMVJxLbDrD5vo%3D&reserved=0>

  1.  Do nothing: We can choose to leave everything as is. The downside of this is that the lessons we are learning are not getting disseminated or resulting in reduced risks.
  2.  Update the recommendations: We can document the social engineering exploits and recommend some additional mitigations as well as recommendations in terms of use cases. Although these types of "phishing"/social engineering attacks are called out in the security considerations in RFC 8628 - OAuth 2.0 Device Authorization Grant<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8628&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884490234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=6YYkNcG2GC32KSDdWU792bkXnr6GQaRen%2F02560aSRA%3D&reserved=0>, we can add further mitigations to create greater defence in depth. This will help future implementers and may even be useful for future protocols that rely on a similar cross-device authentication and authorization flows.
  3.  Explore alternatives: Develop, adopt, or evolve new protocols that address the scenario while mitigating or avoiding the risks.

Cheers,

Pieter

---

From: Pieter Kasselman <[email-masked]>
Date: Fri, 18 Mar 2022 12:42:38 +0000

Hi Shane,

Agreed that CIBA is interesting in this context as an alternative to Device Authorization Grant.

Having the user initiate the request makes it harder for an adversary to manipulate the context, but I think it also shifts the point of attack. Now instead of getting the user to enter a user code, you have to get the user to enter their “user_hint”. This does put it on par with any regular phishing attack (at least the attack did not become easier). I do think mitigations on the back-end can help to further reduce the risks for both Device Authorization Grant and CIBA.

Something else we may want to provide is some clear recommendations on when to use CIBA vs Device Authorization Grant etc (e.g. use CIBA if the user can provide input, use Device Authorization Grant if there is no input device). All of this may seem obvious for experts familiar with this space, but being explicit will help implementors who has expertise elsewhere.

From looking at various protocols, whenever we attempt to use the user as a secure transport between their authentication device and the device on which the service will be delivered, we open an opportunity for social engineering attacks. Keeping that opening as small and constrained as possible and then mitigating against errors in judgement will help the overall security posture.

Cheers

Pieter

From: Shane B Weeden <[email-masked]>
Sent: Thursday 17 March 2022 21:21
To: Pieter Kasselman <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [OAUTH-WG] Device Authorization Grant and Illicit Consent Exploits

---

From: Dave Tonge <[email-masked]>
Date: Tue, 22 Mar 2022 16:07:06 +0100

> Something else we may want to provide is some clear recommendations on
when to use CIBA vs Device Authorization Grant etc

I think this would be really helpful. Both specs support "decoupled" flows,
but they were designed for different use cases and have different
trade-offs.

CIBA provides a few more options when it comes to securing decoupled flows
that could make the attacks in the original email harder to implement, e.g.
 - user code (mainly an "anti-spam" parameter)
 - binding_message
 - login_hint_token / id_token_hint to bootstrap the flow

I'm looking forward to the discussion around this on Thursday

Dave

On Fri, 18 Mar 2022 at 13:43, Pieter Kasselman <pieter.kasselman=
[email-masked]> wrote:

> Having the user initiate the request makes it harder for an adversary to
> manipulate the context, but I think it also shifts the point of attack. Now
> instead of getting the user to enter a user code, you have to get the user
> to enter their “user_hint”. This does put it on par with any regular
> phishing attack (at least the attack did not become easier). I do think
> mitigations on the back-end can help to further reduce the risks for both
> Device Authorization Grant and CIBA.
>
>
>
> Something else we may want to provide is some clear recommendations on
> when to use CIBA vs Device Authorization Grant etc (e.g. use CIBA if the
> user can provide input, use Device Authorization Grant if there is no input
> device). All of this may seem obvious for experts familiar with this space,
> but being explicit will help implementors who has expertise elsewhere.
>
>
>
> From looking at various protocols, whenever we attempt to use the user as
> a secure transport between their authentication device and the device on
> which the service will be delivered, we open an opportunity for social
> engineering attacks. Keeping that opening as small and constrained as
> possible and then mitigating against errors in judgement will help the
> overall security posture.
>
>
>
> Cheers
>
>
>
> Pieter
>
>
>
> *From:* Shane B Weeden <[email-masked]>
> *Sent:* Thursday 17 March 2022 21:21
> *To:* Pieter Kasselman <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* [EXTERNAL] Re: [OAUTH-WG] Device Authorization Grant and
> Illicit Consent Exploits
>
>
>
> 1. Requiring the client to initiate the flow with signed request
> parameters which include, via some hint, the resource owner for whom
> authentication is being requested
>
> 2. Requiring that the OP check that the resource owner approving the grant
> is the same as that the client associated with the request in step 1
>
>
>
> I realise this requires that the client obtains an indication of the
> username of the resource owner up front to kick things off, but short of
> this I cannot think of any practical mitigation.
>
>
>
>
>
>
>
> On 18 Mar 2022, at 7:09 am, Pieter Kasselman <
> pieter.kasselman=[email-masked]> wrote:
>
>
>
> ant problem by enabling authorization flows on devices that are unable to
> support a browsers or have limited input capabilities. However, looking
> back over the past 18-24 months, there have been a number of practical
> exploits published that use social en
>
>
> _______________________________________________
> 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 2022 © 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: George Fletcher <[email-masked]>
Date: Wed, 23 Mar 2022 21:09:51 -0400

I just want to make a quick comment on the use of "proximity and 
location information". I used the device flow to authorize my son's 
device by having him text me the code so I could login on my device (in 
a different state) and provide his device access. If we close the door 
too much we will potentially impact good users :)

I agree that consent can be socially engineered... but think that it 
would be useful to improve that information so that the user 
authenticating to provide authorization could know where the device 
their authorizing is located. That could help users detecting that they 
are authorizing a device in a location that doesn't make sense to them.

Thanks,
George

On 3/18/22 8:21 AM, Pieter Kasselman wrote:
> One of the challenges with consent screens is that it makes 
> assumptions about the users abilities when they are being asked to 
> make decisions about things they do not fully appreciate or 
> understand. In addition, they are in a rush, are often trying to be 
> helpful and prone to grant consent (the framing in these social 
> engineering attacks can be very persuasive). Even users who are aware 
> of these exploits and understand the systems they interact with are 
> prone to be misled. Better guidance on the consent screen is 
> definitely something we should provide.
>
> I do think there is a defence in depth strategy that can reduce risk 
> by (1) avoiding asking the user for a decision by making back-end risk 
> decisions (2) augmenting the information presented to the user when 
> making the decisions and (3) mitigating against a decision made in error.
>
> Proximity and location information can for instance be used to bind 
> user codes to specific locations or inform the user on where the user 
> code was first presented, device status and/or location may be used to 
> make decisions on whether to allow device code flows to be used in the 
> first place and use of token binding (e.g. DPoP) may help defend 
> against attackers who are able to exfiltrate tokens from a device and 
> make lateral attacks.
>
> Anything we can do to encourage implementor to ask users to make fewer 
> decision, help them make better decisions and then protecting them in 
> case of a bad decision will help drive down risk.
>
> Cheers
>
> Pieter
>
> *From:*Brock Allen <[email-masked]>
> *Sent:* Thursday 17 March 2022 21:25
> *To:* Pieter Kasselman <[email-masked]>; [email-masked]
> I watched one of those videos and it seems to be that a proper consent 
> screen would have been the best and easiest line of defense. Is there 
> something more to the attacks where a better consent page (or any 
> consent page for that matter) would not have been sufficient?
>
> -Brock
>
>     On 3/17/2022 5:10:35 PM, Pieter Kasselman
>     <pieter.kasselman=[email-masked]> wrote:
>
>     Hi All
>
>     One of the agenda items for IETF 113 is the device authorization
>     grant flow (aka device code flow), scheduled for Thursday 24 March
>     2022.  Before the meeting, I wanted to share a bit more
>     information for those interested in the topic and also give those
>     who are unable to attend in person an opportunity to participate
>     in the conversation.
>
>     The Device Authorization Grant Flow (RFC 8682)
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8628&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884440262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=EswcNYKNZWEAWLBuOvQytd8TMlgpgUxIk0E%2FlfKkRIk%3D&reserved=0>solves
>     an important problem by enabling authorization flows on devices
>     that are unable to support a browsers or have limited input
>     capabilities. However, looking back over the past 18-24 months,
>     there have been a number of practical exploits published that use
>     social engineering techniques applied to the device authorization
>     grant flow.
>
>     The goal of the session at IETF 113 is to discuss the patterns of
>     the exploits that are known and start a conversation on what (if
>     anything) we should do, based on what we are learning.
>
>      2. Presents the user code in a context that the end-user is
>         likely to act on (using social engineering techniques), and
>      3. Once the user grants access, retrieves the access and refresh
>         tokens and uses them to access the user’s resources.
>
>      1. The Art of the Device Code Phish - Boku (0xboku.com)
>         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F0xboku.com%2F2021%2F07%2F12%2FArtOfDeviceCodePhish.html&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884440262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2B71AMxS1m4aBTrX8e76UiXs%2Fa%2F22dfxen1pI9Ln17Ig%3D&reserved=0>
>      2. Microsoft 365 OAuth Device Code Flow and Phishing | Optiv
>         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.optiv.com%2Finsights%2Fsource-zero%2Fblog%2Fmicrosoft-365-oauth-device-code-flow-and-phishing&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884440262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=I6tnZsOgj6fl9aYbfXe98wKf%2B5M7X%2FHEu8Umn3cui7Q%3D&reserved=0>
>
>          1. optiv/Microsoft365_devicePhish: A proof-of-concept script
>             to conduct a phishing attack abusing Microsoft 365 OAuth
>             Authorization Flow (github.com)
>             <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foptiv%2FMicrosoft365_devicePhish&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884440262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=hVXdTbLAkdBXAepI26qG5J3poSzquok1sgUwdLGPNTg%3D&reserved=0>
>
>      3. Introducing a new phishing technique for compromising Office
>         365 accounts (o365blog.com)
>         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fo365blog.com%2Fpost%2Fphishing%2F%23new-phishing-technique-device-code-authentication&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884490234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=KXDXJ8dDBdKxT72jIl8pa2BksAXiKc8N0%2F0NThYiN5Q%3D&reserved=0>
>      4. DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting
>         OAuth Authentication Flows - YouTube
>         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D9slRYvpKHp4&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884490234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=KWmBAf3pYGdVzT6LeNhgT7t%2BybfnFdGMVJxLbDrD5vo%3D&reserved=0>
>
>     In terms of a response, there are a few options that come to mind
>     (these are not exhaustive, I would love to see what others have in
>     mind as well):
>
>      1. Do nothing: We can choose to leave everything as is. The
>         downside of this is that the lessons we are learning are not
>         getting disseminated or resulting in reduced risks.
>      2. Update the recommendations: We can document the social
>         engineering exploits and recommend some additional mitigations
>         as well as recommendations in terms of use cases. Although
>         these types of "phishing"/social engineering attacks are
>         called out in the security considerations in RFC 8628 - OAuth
>         2.0 Device Authorization Grant
>         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8628&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884490234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=6YYkNcG2GC32KSDdWU792bkXnr6GQaRen%2F02560aSRA%3D&reserved=0>,
>         we can add further mitigations to create greater defence in
>         depth. This will help future implementers and may even be
>         useful for future protocols that rely on a similar
>         cross-device authentication and authorization flows.
>      3. Explore alternatives: Develop, adopt, or evolve new protocols
>         that address the scenario while mitigating or avoiding the risks.
>
>     Option A does not do much to improve the state of the art. Option
>     B feels like something we can do now, and we may learn something
>     along the way that can help inform Option C, which may be much
>     further down the road and require more research. What other
>     options come to mind?
>

---

From: "Brock Allen" <[email-masked]>
Date: Wed, 23 Mar 2022 21:24:51 -0400

In the case of DEF CON video showing the Microsoft exploit, it worked liked this (if I recall correctly):

The attacker started the device flow from their system, sent the user a link to login with an "promo code" (the user code) to get a discount on their Microsoft bill, and when the user logged in they were prompted for the code (which they thought it was a promo code), and thus they granted access to the attacker waiting for the flow to be complete.

The problem was that:

1) The vendor's first party administrative CLI app was designed to use device flow.
2) The consent screen just said "Do you want to login to your Microsoft account".

So the issues were that for (1) device flow was just the wrong one (the native apps BCP w/ system browser should have been used), especially for an app with such high/privileged access, and for (2) the consent did not let the end-user know they were granting the client full administrative access.

So several missteps here that the protocol by itself can't completely protect against.

-Brock
On 3/23/2022 9:10:01 PM, George Fletcher <[email-masked]> wrote:
I just want to make a quick comment on the use of "proximity and location information". I used the device flow to authorize my son's device by having him text me the code so I could login on my device (in a different state) and provide his device access. If we close the door too much we will potentially impact good users :)

I agree that consent can be socially engineered... but think that it would be useful to improve that information so that the user authenticating to provide authorization could know where the device their authorizing is located. That could help users detecting that they are authorizing a device in a location that doesn't make sense to them.

Thanks,
George

Hi Brock

 

 
Cheers
 
Pieter

From: Brock Allen <[email-masked]> [mailto:[email-masked]]
Sent: Thursday 17 March 2022 21:25
To: Pieter Kasselman <[email-masked]> [mailto:[email-masked]]; [email-masked] [mailto:[email-masked]]
Subject: [EXTERNAL] Re: [OAUTH-WG] Device Authorization Grant and Illicit Consent Exploits

-Brock
On 3/17/2022 5:10:35 PM, Pieter Kasselman <pieter.kasselman=[email-masked] [mailto:pieter.kasselman=[email-masked]]> wrote:
Hi All 

The Device Authorization Grant Flow (RFC 8682) [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8628&amp;data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884440262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=EswcNYKNZWEAWLBuOvQytd8TMlgpgUxIk0E%2FlfKkRIk%3D&amp;reserved=0] solves an important problem by enabling authorization flows on devices that are unable to support a browsers or have limited input capabilities. However, looking back over the past 18-24 months, there have been a number of practical exploits published that use social engineering techniques applied to the device authorization grant flow. 

 

* The Art of the Device Code Phish - Boku (0xboku.com) [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F0xboku.com%2F2021%2F07%2F12%2FArtOfDeviceCodePhish.html&amp;data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884440262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=%2B71AMxS1m4aBTrX8e76UiXs%2Fa%2F22dfxen1pI9Ln17Ig%3D&amp;reserved=0] 
* Microsoft 365 OAuth Device Code Flow and Phishing | Optiv [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.optiv.com%2Finsights%2Fsource-zero%2Fblog%2Fmicrosoft-365-oauth-device-code-flow-and-phishing&amp;data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884440262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=I6tnZsOgj6fl9aYbfXe98wKf%2B5M7X%2FHEu8Umn3cui7Q%3D&amp;reserved=0] 
* optiv/Microsoft365_devicePhish: A proof-of-concept script to conduct a phishing attack abusing Microsoft 365 OAuth Authorization Flow (github.com) [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foptiv%2FMicrosoft365_devicePhish&amp;data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884440262%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=hVXdTbLAkdBXAepI26qG5J3poSzquok1sgUwdLGPNTg%3D&amp;reserved=0] 
* Introducing a new phishing technique for compromising Office 365 accounts (o365blog.com) [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fo365blog.com%2Fpost%2Fphishing%2F%23new-phishing-technique-device-code-authentication&amp;data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884490234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=KXDXJ8dDBdKxT72jIl8pa2BksAXiKc8N0%2F0NThYiN5Q%3D&amp;reserved=0] 
* DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth Authentication Flows - YouTube [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D9slRYvpKHp4&amp;data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884490234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=KWmBAf3pYGdVzT6LeNhgT7t%2BybfnFdGMVJxLbDrD5vo%3D&amp;reserved=0] 

* Do nothing: We can choose to leave everything as is. The downside of this is that the lessons we are learning are not getting disseminated or resulting in reduced risks. 
* Update the recommendations: We can document the social engineering exploits and recommend some additional mitigations as well as recommendations in terms of use cases. Although these types of "phishing"/social engineering attacks are called out in the security considerations in RFC 8628 - OAuth 2.0 Device Authorization Grant [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8628&amp;data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cdab129df96fb4fe03c7908da085c8dae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637831490884490234%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=6YYkNcG2GC32KSDdWU792bkXnr6GQaRen%2F02560aSRA%3D&amp;reserved=0], we can add further mitigations to create greater defence in depth. This will help future implementers and may even be useful for future protocols that rely on a similar cross-device authentication and authorization flows. 
* Explore alternatives: Develop, adopt, or evolve new protocols that address the scenario while mitigating or avoiding the risks. 

 
Cheers, 
Pieter 

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

---

From: Pieter Kasselman <[email-masked]>
Date: Thu, 24 Mar 2022 12:34:40 +0000

Thanks George, I agree that there are “on behalf-off” authorization use cases where strict proximity enforcement could be problematic.

I think of proximity as one of the controls that can be applied and influence the risk assessment. For example, the authorization server may still issue authorization tokens, but may choose to reduce the validity period or require re-authentication in the future if proximity cannot be established (i.e. you can get a temporary pass, until you can satisfy the proximity requirements).

Another way to think about it is correlating proximity at different levels (same room, same building, same city, same country, same continent).

A third variation of this may be related to the vce being protected (e.g. above a certain monetary value proximity is enforced, below another value, it is not).

I don’t think of it as a binary decision, but rather one of a number of signals that can help to reduce risk, based on the deployment scenario.

Cheers

Pieter

From: George Fletcher <gffletch=[email-masked]>
Sent: Thursday 24 March 2022 02:10
To: Pieter Kasselman <[email-masked]>; Brock Allen <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Device Authorization Grant and Illicit Consent Exploits

Thanks,
George

Cheers

Pieter

From: Brock Allen <[email-masked]><mailto:[email-masked]>
Sent: Thursday 17 March 2022 21:25
To: Pieter Kasselman <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [OAUTH-WG] Device Authorization Grant and Illicit Consent Exploits

-Brock

Hi All

The Device Authorization Grant Flow (RFC 8682)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8628&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Ce03b324211d34dcd6fb108da0d330b6b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836810161626048%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yP%2FRmr7v916T8z1uA8KpTysavkcXZzBxj1KKB%2FoWANk%3D&reserved=0> solves an important problem by enabling authorization flows on devices that are unable to support a browsers or have limited input capabilities. However, looking back over the past 18-24 months, there have been a number of practical exploits published that use social engineering techniques applied to the device authorization grant flow.

  1.  The Art of the Device Code Phish - Boku (0xboku.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F0xboku.com%2F2021%2F07%2F12%2FArtOfDeviceCodePhish.html&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Ce03b324211d34dcd6fb108da0d330b6b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836810161626048%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JMOmPUuYP6XqADHP5CbDIUpfplGRx0tbKU%2FJ4pTk4EQ%3D&reserved=0>
  2.  Microsoft 365 OAuth Device Code Flow and Phishing | Optiv<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.optiv.com%2Finsights%2Fsource-zero%2Fblog%2Fmicrosoft-365-oauth-device-code-flow-and-phishing&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Ce03b324211d34dcd6fb108da0d330b6b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836810161626048%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hWkc6%2FO2DsAFoQLeo0JA7QB4KdM3dCoyY8Nm4Jeuytc%3D&reserved=0>

     *   optiv/Microsoft365_devicePhish: A proof-of-concept script to conduct a phishing attack abusing Microsoft 365 OAuth Authorization Flow (github.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foptiv%2FMicrosoft365_devicePhish&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Ce03b324211d34dcd6fb108da0d330b6b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836810161626048%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Kpihi7dmzGyh%2Bt6%2BALWD5EqdSlgFjcz3c5HWkNuV4Og%3D&reserved=0>

  1.  Introducing a new phishing technique for compromising Office 365 accounts (o365blog.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fo365blog.com%2Fpost%2Fphishing%2F%23new-phishing-technique-device-code-authentication&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Ce03b324211d34dcd6fb108da0d330b6b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836810161626048%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vypXoL3og9n9r38SRxHjmXFsy%2FgVODVHG454OeEKN3s%3D&reserved=0>
  2.  DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth Authentication Flows - YouTube<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D9slRYvpKHp4&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Ce03b324211d34dcd6fb108da0d330b6b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836810161626048%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JGMzt%2FCSAbKOB9GvryBqEirFKHZpG6JHUAp1JPUuIvU%3D&reserved=0>

  1.  Do nothing: We can choose to leave everything as is. The downside of this is that the lessons we are learning are not getting disseminated or resulting in reduced risks.
  2.  Update the recommendations: We can document the social engineering exploits and recommend some additional mitigations as well as recommendations in terms of use cases. Although these types of "phishing"/social engineering attacks are called out in the security considerations in RFC 8628 - OAuth 2.0 Device Authorization Grant<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8628&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7Ce03b324211d34dcd6fb108da0d330b6b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836810161626048%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yP%2FRmr7v916T8z1uA8KpTysavkcXZzBxj1KKB%2FoWANk%3D&reserved=0>, we can add further mitigations to create greater defence in depth. This will help future implementers and may even be useful for future protocols that rely on a similar cross-device authentication and authorization flows.
  3.  Explore alternatives: Develop, adopt, or evolve new protocols that address the scenario while mitigating or avoiding the risks.

Cheers,

Pieter

OAuth mailing list

[email-masked]<mailto:[email-masked]>

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%7Ce03b324211d34dcd6fb108da0d330b6b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836810161626048%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3xVlAPrntOa6N1mY6Xo%2BUFbeIsqveGK%2FstitgJePzvs%3D&reserved=0>

---

From: Pieter Kasselman <[email-masked]>
Date: Thu, 24 Mar 2022 12:41:10 +0000

Hi Brock, one of the options to consider here is just better guidance in terms of implementation, including guidance on selecting protocols. From looking at numerous exploits (not just the authroization grant flow and the social engineering exploits), implementation issues is by far the most prevalent cause of issues, much more so than protocol issues themselves.

I would add that keeping protocols and the primitives they are built on simple is important in reducing implementation errors as well.

To put it another way, giving implementors more context about the consequences of using a protocol in a certain way is really important if we want to minimise security issues that arise from implementation issues and protocol selection.

Cheers

Pieter

From: Brock Allen <[email-masked]>
Sent: Thursday 24 March 2022 02:25
To: George Fletcher <[email-masked]>; Pieter Kasselman <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] [EXTERNAL] Re: Device Authorization Grant and Illicit Consent Exploits

The problem was that:

-Brock

On 3/23/2022 9:10:01 PM, George Fletcher <[email-masked]<mailto:[email-masked]>> wrote:
I just want to make a quick comment on the use of "proximity and location information". I used the device flow to authorize my son's device by having him text me the code so I could login on my device (in a different state) and provide his device access. If we close the door too much we will potentially impact good users :)

Thanks,
George

Cheers

Pieter

-Brock

Hi All

The Device Authorization Grant Flow (RFC 8682)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8628&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C6a66422ca9354a8c5d8708da0d351f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836819085440431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=BuCofd8KVdLqaU3XcTuNURAq9GXfMn3192mH2psAtVc%3D&reserved=0> solves an important problem by enabling authorization flows on devices that are unable to support a browsers or have limited input capabilities. However, looking back over the past 18-24 months, there have been a number of practical exploits published that use social engineering techniques applied to the device authorization grant flow.

  1.  The Art of the Device Code Phish - Boku (0xboku.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F0xboku.com%2F2021%2F07%2F12%2FArtOfDeviceCodePhish.html&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C6a66422ca9354a8c5d8708da0d351f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836819085440431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dSerVO2tbsAoR0daHAJrgIjO7twSK09LJPjfFLcTWIk%3D&reserved=0>
  2.  Microsoft 365 OAuth Device Code Flow and Phishing | Optiv<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.optiv.com%2Finsights%2Fsource-zero%2Fblog%2Fmicrosoft-365-oauth-device-code-flow-and-phishing&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C6a66422ca9354a8c5d8708da0d351f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836819085440431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=l9GU8kRjvThOBVb64wLCkAH9DRudmC2u2pwDMWM3pWU%3D&reserved=0>

     *   optiv/Microsoft365_devicePhish: A proof-of-concept script to conduct a phishing attack abusing Microsoft 365 OAuth Authorization Flow (github.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foptiv%2FMicrosoft365_devicePhish&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C6a66422ca9354a8c5d8708da0d351f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836819085440431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bvNblUsF8pfDcqP28Dk5FawgIPaA7%2BTIicGoETMtjxk%3D&reserved=0>

  1.  Introducing a new phishing technique for compromising Office 365 accounts (o365blog.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fo365blog.com%2Fpost%2Fphishing%2F%23new-phishing-technique-device-code-authentication&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C6a66422ca9354a8c5d8708da0d351f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836819085440431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eyJKm0cTCHZVeyngiBEt9CbyJ%2Fd16q%2B8SGitHwUW9M0%3D&reserved=0>
  2.  DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth Authentication Flows - YouTube<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D9slRYvpKHp4&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C6a66422ca9354a8c5d8708da0d351f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836819085440431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sY%2BPsBP%2Bdy4F2L7bOValEbadgXmeG4D4DaKFiZeE6S4%3D&reserved=0>

  1.  Do nothing: We can choose to leave everything as is. The downside of this is that the lessons we are learning are not getting disseminated or resulting in reduced risks.
  2.  Update the recommendations: We can document the social engineering exploits and recommend some additional mitigations as well as recommendations in terms of use cases. Although these types of "phishing"/social engineering attacks are called out in the security considerations in RFC 8628 - OAuth 2.0 Device Authorization Grant<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8628&data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C6a66422ca9354a8c5d8708da0d351f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836819085440431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=BuCofd8KVdLqaU3XcTuNURAq9GXfMn3192mH2psAtVc%3D&reserved=0>, we can add further mitigations to create greater defence in depth. This will help future implementers and may even be useful for future protocols that rely on a similar cross-device authentication and authorization flows.
  3.  Explore alternatives: Develop, adopt, or evolve new protocols that address the scenario while mitigating or avoiding the risks.

Cheers,

Pieter

OAuth mailing list

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%7C6a66422ca9354a8c5d8708da0d351f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836819085440431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tyZIO8wpz6XTc1Jf8xKd5LK0xMFHaIeQ24Zih5Uys9U%3D&reserved=0>

---

From: "Brock Allen" <[email-masked]>
Date: Thu, 24 Mar 2022 09:27:15 -0400

Yep +1

But also... in my experience, FWIW, the dev generally wants to do the right thing and follow the guidance, but then you get the product owner/marketing/sales/UX/designer people who then want to make things as friction-less for the end user/customer (which often translates into revenue). And that's often why we end up with so much guidance ignored. Resource owner password grant type vs. AppAuth is a great example of this -- about one a month I have to get on a call to have this battle again and again.

It's a tough line to walk.

-Brock
On 3/24/2022 8:41:13 AM, Pieter Kasselman <[email-masked]> wrote:
Hi Brock, one of the options to consider here is just better guidance in terms of implementation, including guidance on selecting protocols. From looking at numerous exploits (not just the authroization grant flow and the social engineering exploits), implementation issues is by far the most prevalent cause of issues, much more so than protocol issues themselves.

 
Cheers
 
Pieter

 
 
The problem was that:

 
 
-Brock
On 3/23/2022 9:10:01 PM, George Fletcher <[email-masked] [mailto:[email-masked]]> wrote:
I just want to make a quick comment on the use of "proximity and location information". I used the device flow to authorize my son's device by having him text me the code so I could login on my device (in a different state) and provide his device access. If we close the door too much we will potentially impact good users :)

Thanks,
George

 

 
Cheers
 
Pieter

 
-Brock

The Device Authorization Grant Flow (RFC 8682) [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8628&amp;data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C6a66422ca9354a8c5d8708da0d351f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836819085440431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=BuCofd8KVdLqaU3XcTuNURAq9GXfMn3192mH2psAtVc%3D&amp;reserved=0] solves an important problem by enabling authorization flows on devices that are unable to support a browsers or have limited input capabilities. However, looking back over the past 18-24 months, there have been a number of practical exploits published that use social engineering techniques applied to the device authorization grant flow. 

 

* The Art of the Device Code Phish - Boku (0xboku.com) [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F0xboku.com%2F2021%2F07%2F12%2FArtOfDeviceCodePhish.html&amp;data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C6a66422ca9354a8c5d8708da0d351f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836819085440431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=dSerVO2tbsAoR0daHAJrgIjO7twSK09LJPjfFLcTWIk%3D&amp;reserved=0] 
* Microsoft 365 OAuth Device Code Flow and Phishing | Optiv [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.optiv.com%2Finsights%2Fsource-zero%2Fblog%2Fmicrosoft-365-oauth-device-code-flow-and-phishing&amp;data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C6a66422ca9354a8c5d8708da0d351f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836819085440431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=l9GU8kRjvThOBVb64wLCkAH9DRudmC2u2pwDMWM3pWU%3D&amp;reserved=0] 
* optiv/Microsoft365_devicePhish: A proof-of-concept script to conduct a phishing attack abusing Microsoft 365 OAuth Authorization Flow (github.com) [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foptiv%2FMicrosoft365_devicePhish&amp;data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C6a66422ca9354a8c5d8708da0d351f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836819085440431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=bvNblUsF8pfDcqP28Dk5FawgIPaA7%2BTIicGoETMtjxk%3D&amp;reserved=0] 
* Introducing a new phishing technique for compromising Office 365 accounts (o365blog.com) [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fo365blog.com%2Fpost%2Fphishing%2F%23new-phishing-technique-device-code-authentication&amp;data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C6a66422ca9354a8c5d8708da0d351f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836819085440431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=eyJKm0cTCHZVeyngiBEt9CbyJ%2Fd16q%2B8SGitHwUW9M0%3D&amp;reserved=0] 
* DEF CON 29 - Jenko Hwong - New Phishing Attacks Exploiting OAuth Authentication Flows - YouTube [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D9slRYvpKHp4&amp;data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C6a66422ca9354a8c5d8708da0d351f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836819085440431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=sY%2BPsBP%2Bdy4F2L7bOValEbadgXmeG4D4DaKFiZeE6S4%3D&amp;reserved=0] 

* Do nothing: We can choose to leave everything as is. The downside of this is that the lessons we are learning are not getting disseminated or resulting in reduced risks. 
* Update the recommendations: We can document the social engineering exploits and recommend some additional mitigations as well as recommendations in terms of use cases. Although these types of "phishing"/social engineering attacks are called out in the security considerations in RFC 8628 - OAuth 2.0 Device Authorization Grant [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8628&amp;data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C6a66422ca9354a8c5d8708da0d351f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836819085440431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=BuCofd8KVdLqaU3XcTuNURAq9GXfMn3192mH2psAtVc%3D&amp;reserved=0], we can add further mitigations to create greater defence in depth. This will help future implementers and may even be useful for future protocols that rely on a similar cross-device authentication and authorization flows. 
* Explore alternatives: Develop, adopt, or evolve new protocols that address the scenario while mitigating or avoiding the risks. 

 
Cheers, 
Pieter 

_______________________________________________
OAuth mailing list
[email-masked] [mailto:[email-masked]]
https://www.ietf.org/mailman/listinfo/oauth [https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&amp;data=04%7C01%7Cpieter.kasselman%40microsoft.com%7C6a66422ca9354a8c5d8708da0d351f77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637836819085440431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=tyZIO8wpz6XTc1Jf8xKd5LK0xMFHaIeQ24Zih5Uys9U%3D&amp;reserved=0]