Written by Matt Kiely, Principal Security Researcher at Huntress
Come along with me on a journey as we delve into the swirling, echoing madness of identity attacks. Today, I present a case study on how different implementations of OAuth 2.0, the core authentication schema used in most identity providers, can have radically different attack surfaces.
The subjects for today’s case study are two scrappy up-and-coming tech shops straight outta Silicon Valley: Microsoft and Google. Perhaps you’ve heard of them?
Let’s look at how one of my favorite identity attacks, Device Code Phishing, stacks up between these two identity providers. By the end of this blog, you, dear reader, will appreciate how the OAuth 2.0 implementation compares between these two identity providers and how that directly facilitates or negates the blast radius of this extremely over-powered attack.
Ready to get nerdy with it? Let’s get nerdy with it.
Meet the Device Code Flow
Before we understand Device Code Phishing, we need to understand the feature that allows this attack to exist in the first place. Let’s begin with an implementation independent breakdown of the feature in question and how it is exploited. Time to meet the device code flow, aka the device authorization grant!
Figure 1: Abstract of the OAuth 2.0 device authorization grant
I read the RFC so you don’t have to. Though I’d recommend it if you’re looking for a sleep aid.
The device authorization grant is used in scenarios where one wishes to authenticate an internet connected device that lacks a traditional input mechanism like a keyboard, web browser, or the like. The RFC calls these input constrained devices. Let’s imagine your average IoT printer, smart TV, wifi enabled toaster with a touch screen, or any other kind of device that is internet connected but lacks a full featured user interface.
... continue reading