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:
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 <brockal...@gmail.com>
*Sent:* Thursday 17 March 2022 21:25
*To:* Pieter Kasselman <pieter.kassel...@microsoft.com>; oauth@ietf.org
*Subject:* [EXTERNAL] Re: [OAUTH-WG] Device Authorization Grant and
Illicit Consent Exploits
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=40microsoft....@dmarc.ietf.org> 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.
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://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?
I’m looking forward to the conversation and hearing what others
are thinking about this topic.
Cheers,
Pieter
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
