EXO OWA Anmeldung analysiert

Wie funktioniert genau die Anmeldung per Browser an Outlook on the Web mit Exchange Online? Wie greifen EVOSTS, MFA per Smartphone und OpenID-Cookies zusammen und wer räumt beim Abmelden wieder weg? Eine Analyse der HTTPS-Request mit Fiddler und Co.

Übersicht

Ich habe Fiddler gestartet und mit in einem privaten Browser auf "outlook.office.com" verbunden. Der private Browser sorgte dafür, dass ein Seamless Single Sing On erfolgte und aus dem Homeoffice hat auch Conditional Access die Anmeldung per Kennwort und Authenticator App erzwungen. Hier ein Auszug der interessanten HTTP-Requests:

Sie sehen zuerst den Sprung zu "login.microsoftonline.com" und dann in Paket 125 (gelb) die formularbasierte Anmeldung im Browser, die dann mit der Anzeige der Prüfziffer und Statusabfrage (Paket 114-165 markiert) fortgesetzt wird. Nach der Bestätigung, die in Paket 165 kommt, wird die Anmeldung abgeschlossen und ein UserID-Token ausgestellt. Damit fordert OWA dann aber kein Bearer-Token an, sondern Exchange OpenID-Cookies zur Kontrolle der Anmeldung. Schauen wir diese Pakete im Detail weiter an.

Request 125: POST /common/login

Ich überspringe die vorherigen Request, welche meinen Client auf die Anmeldeserver verweisen und prüfen, ob z.B. Seamless Single Sign On o.a. Anmeldeverfahren möglich sind und starte direkt mit dem POST auf das ausgefüllte Anmeldeformular. Ich hoffe, sie sind nicht überrascht dass das Kennwort hier nur per HTTPS verschlüsselt aber ansonsten im Klartext als "Form POST" vom Client zu login.onmicrosoft.com übertragen wird.

Die Antwort enthält aber kein JSON-Token, sondern per gzip komprimiertes "text/html" aber setzt jede Menge Cookies. Diese enthalten quasi die Information über die erfolgreiche Anmeldung und werden in späteren Request immer wieder mitgesendet, so dass Microsoft den Anwender und seinen Anmeldestatus erkennen kann. Die Bedeutung der Cookies hat Microsoft öffentlich dokumentiert.

Request 133: BeginAuth

Das sehen wir dann im Request 133, bei dem die Authentifizierung fortgesetzt wird:

 

Der Client bekommt ein 200OK als Antwort und in der Payload steht die Zahl, die der Browser dem Anwender dann anzeigt:

 

Es ist also wichtig, dass die Übertragung dieser Informationen per TLS verschlüsselt ist und ein Angreifer diese Information nicht ausleiten kann.

Request 144-165

Nun wartet der Browser auf die Bestätigung des Clients. Dazu setzt Microsoft im November 2024 aber keine Websockets oder HTTP Streaming ein, sondern der Browser pollt clientseitig ca. alle 1,3 Sekunden den Status der "PhoneAuthentication" mit einem aufsteigenden "Count=".

 

Der Request enthält neben der URL wieder die Cookies und die Antwort ist ein 200 OK mit folgender JSON Payload:

 

Der letzte Request 165 wird mit einem "Success" in der Payload beantwortet:

 

Damit ist bestätigt, dass ich in der Authenticator App die Nummer korrekt eingegeben habe. 

Request 178 Post /kmsi

Mein Client greift dann auf "https://login.microsoftonline.com/kmsi" zu und postet wieder die ESTS-Cookies. Als Antwort bekommt er eine HTML-Seite mit JavaScript, in der ein verstecktes Formular und vorausgefüllten Feldern vorbereitet wird.

Das Token habe ich mir kopiert und über jwt.ms oder jwt.io decodiert (Siehe auch Bearer Decoding und ConvertFrom-Bearertoken). Es ist ein klassisches OAUTH-Token für den angemeldeten Benutzer, ausgestellt von sts.windows.net für die Application "00000002-0000-0ff1-ce00-000000000000" (Office 365 Exchange Online) und einer Gültigkeit von 90359 Sekunden = 25 Stunden.

# JWT Token ist gekürzt
{
  "typ": "JWT",
}.{
  "aud": "00000002-0000-0ff1-ce00-000000000000",
  "iss": "https://sts.windows.net/eef62a09-7718-4063-82db-d7582dc8916f/",
  "nbf": 1732004306,
  "exp": 1732094665,
  "acct": 0,
  "amr": [
    "pwd",
    "mfa"
  ],
  "auth_time": 1732004600,
  "idtyp": "user",
  "nonce": "638676013547680051.<guid>",
  "sid": "<guid>",
  "upn": "Frank.test@carius.de",
  "wids": [
    "62e90394-69f5-4237-9190-012177145e10",
    "b79fbf4d-3ef9-4689-8143-76b194e85509"
  ],
  "xms_cc": [
    "CP1"
  ],
}.[Signature]

Request 179 POST /owa

Den "Absenden"-Button drückt im Browser das JavaScript für den Anwender und sendet damit an Exchange Online einen Request, in dem das Token als Payload übertragen wird.

 

Exchange Online dieses prüft und wenn alles ok ist, dann kommt ein "200 OK" zurück, in dem Exchange den Client anweist, viele Cookies zu setzen.

 

Bitte fragt mich nicht, warum hier jeder "Set-Cookie" doppelt erscheint.

Interessant ist hier z.B. das "OpenIDConnect.id_token.v1", welches in der Folge noch interessant wird.

ebp/6kD6zfgl..............1pz5k6 ; path=/;SameSite=None; secure; HttpOnly 

Das Cookie selbst hat nämlich keine Verfallszeit. Der Inhalt ist BASE64-codiert aber kein klassisches JSON-Token sondern eine Binär-Information, aus der zumindest ich nichts weiter erkennen konnte. Mich hätte schon die Gültigkeitsdauer interessiert. Ich gehe aber davon aus, dass Exchange Online das Token dann auch wieder verlängert.

Folgekommunikation

Bei allen weiteren Zugriffen meines Clients zu Exchange wird nur der Cookie zur Authentifizierung mitgesendet

 

Es ist über mehrere Request hinweg unverändert.

Logoff

Zum Ende habe mich mich natürlich auch wieder abgemeldet. Dazu habe ich ganz klassisch den "Abmelde"-Button in OWA geklickt, was zu einem Aufruf von "/owa/logoff" geführt hat.

Schon diese Seite hat als Payload alle Cookies gelöscht:

Zudem wurde ich natürlich am Ende  auf die Anmeldeseite von Microsoft gelenkt, damit auch diese noch ihre ESTS-Cookies löschen konnte:

Erst dann ist die Anmeldung an dem Browser wirklich erfolgt und ein Anwender kann auch nicht mehr über einen "Zurück"-Button eine Sitzung wieder aufnehmen. Das bedeutet natürlich nicht, dass nicht ein anderer Service sich in einem anderen Tab des gleichen Browser an einem anderen Service (Teams, SharePoint, OneDrive, Planner etc.) über die bestehenden ESTS-Cookies angemeldet hat. Die ist damit nicht abgemeldet, aber Verbindungen zu neuen Diensten sind nicht mehr ohne weitere vorherige Anmeldung möglich.

Insofern sollten Sie als Anwender ein "Abmelden in OWA" mit implizierter Abmeldung an EVOSTS nicht so deuten, dass Sie überall abgemeldet sind. Der Ratschlag, den Browser nach der Abmeldung zu schließen, ist immer noch gültig. Zumal auch die Cookies selbst keine sichtbare Verfallszeit haben und ich nicht ermitteln konnte, wie lange das OpenIDConnect.id_token.v1 letztlich gültig ist.

Einschätzung

Exchange Online bzw. insbesondere OWA nutze für die Anmeldung den klassischen Anmeldeprozess von EVOSTS mit Formular, Form-POST, MFA mit Phone und bekommt am Ende ein ID_Token als Feld in einem Formular, welches der Browser dann im nächsten Schritt direkt wieder an Exchange Online sendet um ein OpenIDConnect.Token zu bekommen. Exchange hat mit diesem ID_Token aber kein Access_Token angefordert und auch später habe ich keine HTTP-Anmeldung gefunden, die ein "Authorization:Bearer" nutzt.

Weitere Links