Preventing Authentication Bypass: A Tale of Two Researchers

## Overview

The presentation "Preventing Authentication Bypass: A Tale of Two Researchers" was introduced by Dr. John Griffin and delivered by three speakers: **Terry Zhang** (co-founder of Defend and identity-breaking specialist), **Ron Chan** (security analyst at NTT and independent security researcher), and **Ravi Jaiswal** (engineering manager for Outlook Web App at Microsoft focusing on authentication and security).

The talk chronicles the independent and concurrent discovery by Zhang and Chan of a critical authentication bypass vulnerability affecting Microsoft Outlook Web App (OWA), followed by Microsoft's incident response and mitigation.

---

## Terry Zhang's Discovery and Escalation

Before March 24th, Terry Zhang investigated Outlook Enterprise Service after switching to the new UI and intercepting requests with Burp Suite. He observed an unfamiliar API action named `GetAccessTokenForResource`.

Key findings and escalation steps included: - **Unsigned JWT Generation**: The endpoint returned an unsigned JSON Web Token with the algorithm set to `none` (`"alg": "none"`). While originally intended for internal preview APIs (such as tips, status checks, and "what's new"), Zhang tested supplying this unsigned token in the `Authorization` header to official Outlook RESTful API endpoints—which typically require signed OIDC tokens—and found the server accepted it. - **Enterprise Exploitation within Tenant**: The token payload contained user identification fields (`oid` for user ID, `smtp` for email), full Exchange permission scopes (`full_access_as_user`), and an embedded, signed `actor_token` holding the tenant ID (`tid`). By replacing the `oid` with another user's `oid` within the same organization/tenant, Zhang could access their profile and fully control the account via the REST API. - **Consumer Service Escalation**: Moving to consumer Outlook (`outlook.live.com` / `mail.live.com`), Zhang discovered that all personal accounts share the same `tid`. - **Bypassing UUID Requirements**: Instead of finding or brute-forcing a target user's UUID `oid`, Zhang discovered that setting `oid` to `null` and setting `pid` and `cid` to empty strings forced the server to fall back solely on the `smtp` claim. This allowed full account takeover—including reading and sending emails on behalf of any consumer Outlook user—using only their email address, requiring zero user interaction.

---

## Ron Chan's Independent Discovery

In April, prompted by a tweet from the Microsoft Security Response Center (MSRC) announcing faster bounties via HackerOne, Ron Chan audited OWA using Burp Suite alongside the *JSON Web Token Attacker* extension, which flags JWTs in HTTP headers: - **Token Identification**: Chan noticed requests containing a JWT that had the `mail.readwrite` scope and lacked a cryptographic signature (algorithm `none`). - **Target `oid` Retrieval**: Identifying that the REST API relied on the `oid` parameter to authenticate identity, Chan needed the victim's UUID `oid`. By reviewing official Microsoft API documentation, he discovered an endpoint that returned any target's `oid` directly without user interaction. - **Enterprise Impersonation**: By querying the victim's `oid`, placing it into his unsigned JWT, and sending it to mail-reading endpoints, Chan successfully impersonated co-workers and read any user's email within the same tenant/organization.

---

## Microsoft Response and Remediation

Following the submissions to MSRC: - **Timeline and Escalation**: MSRC received Zhang's submission on March 24th. When Chan's report arrived shortly thereafter, the duplicate finding prompted MSRC to declare a **SEV-1 / SIRP** (Security Incident Response Process), Microsoft's escalated response process for high-severity customer risks. - **Architecture Context**: The browser client used cookie-based authentication with primary OWA service endpoints, but common Outlook REST endpoints (used for search and cross-service features) required header-based bearer tokens. The `GetAccessTokenForResource` API had been created to bridge this by minting partially signed/unsigned tokens for the client. - **Mitigation**: Within a couple of days of escalating the incident, Microsoft deployed a hotfix that completely disabled the `GetAccessTokenForResource` endpoint, accepting short-term functional trade-offs to immediately cut off the token minting and block all bypass attempts.