Bearer Decoding

Office 365 nutzt fast ausschließlich HTTPS und neben BASIC, Negotiate (Kerberos/NTLM) und TLS-PSK werden Anmeldedaten auch oft als "Bearer"-Token übermittelt. Auf dieser Seite beschreibe ich an einem konkreten Problem, wie Sie mit Fiddler das Token soweit auseinander nehmen können, dass Sie die Anmeldedaten untersuchen können.

Siehe dazu auch die Seiten Authentifizierung im Wandel der Zeit und HTTP Authentication

Auslöser

Angefangen hat es damit, dass mein eigenes Postfach sich nicht mehr replizieren konnte. Wie aus heiterem Himmel konnte mein Outlook nicht mehr mit meinem Office 365 Konto interagieren. In der Fußleiste stand natürlich drin, dass die Verbindung hergestellt war.

Und auch in der Verbindungsansicht war alles soweit in Ordnung

Ich habe mein eigenes Postfach in Office 365 geöffnet und ein zusätzliches Support-Postfach On-Premises und zwei weitere Postfächer in einem anderen Tenant eingebunden. Alle Verbindungen stehen und meine erste Verbindung nutzt "Bearer", was Microsoft als "Träger" bei der Authentifizierung anzeigt. Kleine Spitze: Auch bei Microsoft haben nicht alle Exchange Server die gleiche Version. Sie sind aber sehr viel weiter als mein aktuell gepatchter lokaler Server. Aber das hilft mir so nicht weiter denn Mails habe ich dennoch keine bekommen oder gesendet.

HTTPS-Trace mit Fiddler

Nun sehen Sie ja, dass die Verbindung per HTTP /SSL hergestellt ist. Also wird es Zeit für Fiddler und noch ehe ich was in Outlook antriggern konnte, hat Outlook mit in Fiddler schon die Meldungen geflutet. Es gibt einige "Autodiscover"-Anfragen und alle enden mit einem 401 und vielen 200 ohne zu einem Erfolg zu kommen.

Sie sehen hier auch, dass Outlook 2016 schon mit Autodiscover V2 arbeitet. Es ist eine Mischung von Anfragen auf die On-Premises Umgebung mit Umleitungen zu Office 365 und letztlich kommt es zu einer Autodiscover-Anfrage an die Cloud mit "Bearer" Authentifizierung:

POST https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Content-Type: text/xml
Authorization: Bearer eyJ0eX.....MqV3mA User-Agent: Microsoft Office/16.0 (Windows NT 10.0; Microsoft Outlook 16.0.9330; Pro)
X-MS-CookieUri-Requested: t
X-FeatureVersion: 1
Client-Request-Id: {8E60333C-5A11-4CB9-AB37-125C300A67CA}
X-User-Identity: User43@uclabor.net
X-MapiHttpCapability: 1
Depth: 0
X-AnchorMailbox: User43@uclabor.mail.onmicrosoft.com
Content-Length: 371
Host: autodiscover-s.outlook.com
Cookie: OutlookSession="{4C06E39E-F612-4078-A319-EAF73AFD63EB}";X-BackEndCookie=User43@uclabor.mail.onmicrosoft.com=xxxxxkJKBzw==

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
   <Request>
      <EMailAddress>User43@uclabor.mail.onmicrosoft.com</EMailAddress>
      <AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>
   </Request>
</Autodiscover>

Die Antwort darauf ist aber verblüffend:

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/10.0
request-id: c76caf73-67d0-44e1-9e10-d21b69dc3169
X-CalculatedBETarget: vi1pr0402mb3646.eurprd04.prod.outlook.com
X-RUM-Validated: 1
x-ms-appId: d3590ed6-52b3-4102-aeff-aad2292ab01c
X-DiagInfo: VI1PR0402MB3646
X-BEServer: VI1PR0402MB3646
X-AspNet-Version: 4.0.30319
Set-Cookie: X-BackEndCookie2=User43@uclabor.mail.onmicrosoft.com=xxx/xxx==&adminUser@carius.onmicrosoft.com=xxx/xxx==;
                   expires=Sun, 17-Jun-2018 17:15:45 GMT; path=/autodiscover; secure; HttpOnly
Set-Cookie: X-BackEndCookie=User43@uclabor.mail.onmicrosoft.com=xxx/xxx==&adminUser@carius.onmicrosoft.com=xxx/xxx==; 
                   expires=Sun, 17-Jun-2018 17:15:45 GMT; path=/autodiscover; secure; HttpOnly
X-Powered-By: ASP.NET
X-FEServer: AM5PR0701CA0050
Date: Fri, 18 May 2018 17:15:44 GMT
Content-Length: 361

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
  <Response>
    <Error Time="17:15:45.1029895" Id="2008461090">
      <ErrorCode>500</ErrorCode>
      <Message>The email address can't be found.</Message>
      <DebugData />
    </Error>
  </Response>
</Autodiscover>

Wer genau hinschaut findet hier schon den Fehler. Damit meine ich nun nicht den "The email address can't be found.". Die Mailadresse ist definitiv korrekt aber die Cookies, die gesetzt werden, enthalten nicht nur die Mailadresse des Users sondern auch die Anmeldedaten. Die sind hier aber falsch. Das ist ein AdminUser in einem ganz anderen Tenant. Der darf gar nicht prüfen, was hier passiert.

Bearer decodieren

Das wollte ich nun genauer verstehen und habe mir den String, der im Request steht, genauer angeschaut:

Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbG......er_4g3v7MqV3mA  (gekürzt)

Das ist eine Base64-codierte Information, sie die mit jedem Decoder wieder zurück verwandeln können. Das geht sogar direkt in Fiddler. Sie markieren den Text im Request und senden ihn zum Textwizard

Im Textwizard gilt es dann den String zu decodieren.

Die nun sichtbare Struktur ist wieder ein JSON-Objekt und es sollte gut ersichtlich sein, welcher UPN im den Bearer-Token enthalten ist. Wer noch mehr Strings anschaut, findet auch die URL, für welche das Token ausgestellt ist, welche Rechte damit verbunden sind aber auch den Ausstelle (https://sts.windows.net) und weiter Daten des Bearer Tokens. Hier eine gekürzte Text-Version, damit Google und Co auch was zu finden haben.

{
  "typ":"JWT",
  "alg":"RS256",
  "x5t":"xxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "kid":"xxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
{
  "aud":"https://autodiscover-s.outlook.com/",
  "iss":"https://sts.windows.net/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx/",
  "iat":xxxxxxxxxx,
  "nbf":xxxxxxxxxx,
  "exp":xxxxxxxx
  "acct":0
  "acr":"1"
  "aio":"xxxx/xxxxxxxxxxxxxxxxxxxxxxxxxx/xxx/xxxxxxx="
  "amr":["pwd"
  "rsa"]
  "app_displayname":"Microsoft Office"
  "appid":"xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  "appidacr":"0"
  "deviceid":"xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
  "e_exp":262800
  "enfpolids":[]
  "family_name":"Carius"
  "given_name":"Frank"
  "ipaddr":"80.66.10.222"
  "name":"Frank Carius (farius ADM)"
  "oid":"xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx"
  "puid":"xxxxxxxxx"
  "pwd_exp":"7669693"
  "pwd_url":"https://portal.microsoftonline.com/ChangePassword.aspx"
  "scp":"Calendars.ReadWrite Calendars.ReadWrite.Shared Contacts.ReadWrite Contacts.ReadWrite.Shared 
         Files.ReadWrite.All Group.ReadWrite.All Mail.ReadWrite Mail.ReadWrite.Shared Mail.Send 
         Mail.Send.Shared MailboxSettings.ReadWrite Notes.Read Notes.ReadWrite Privilege.ELT 
         Signals.Read Signals.ReadWrite SubstrateSearch-Internal.ReadWrite Tags.ReadWrite 
         Tasks.ReadWrite.Shared User_impersonation User-Internal.ReadWrite"
  "sub":"xxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx"
  "tid":"3xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx"
  "unique_name":"fc.admin@fc.onmicrosoft.com"
  "upn":"fc.admin@fc.onmicrosoft.com"
  "uti":"xxxxxxxxxxxxx"
  "ver":"1.0"
}

Es ist also gar nicht so einfach ein Bearer-Token zu decodieren und die darin enthaltenen Informationen zu interpretieren. Natürlich gibt es dazu auch jede Menge Skripte, die im Browser ein Token für Sie decodieren.

Windows Credential Speicher

Damit wusste ich nun, warum mein Outlook nicht mehr synchronisieren konnte aber nicht, woher die Daten kommen. Es gibt ja mehrere Speicher unter Windows. Mein erster Anlaufpunkt ist der Windows Tresor unter "Systemsteuerung\Alle Systemsteuerungselemente\Anmeldeinformationsverwaltung". Leider war da nichts zu finden. Dennoch ist es wohl das einfachste hier erst mal zu putzen. Da steht ja in der Regel nichts, was man nicht wieder eingeben könnte. Mit CMDKEY geht das recht schnell, wenn Sie nicht über die GUI Eintrag für Eintrag anklicken wollen.

REM Anzeige der gespeicherten Credentials
cmdkey /list

Interessant sind alle Einträge die dem Namensschema "MicrosoftOfficeXXData:XXXXXXXXX" folgen.

Alternativ können die Daten auch per PowerShell verändert werden. Dazu muss aber ein Modul installiert werden

Install-Module -Name PSCredentialManager

Office Identity Speicher

Aber irgendwie merken sich auch die Office Applikationen den angemeldeten Benutzer. Dies gilt nicht nur für OneDrive, sondern auch für Word, Excel PowerPoint als auch Office. In Word habe ich dann gesehen, dass irgendwo etwas durcheinander sein musste. Hier tauchen gleich drei Einträge von unterschiedlichen Objekten auf

Den "Frank Carius (fcarius ADM) habe ich nicht direkt in der Registrierung gefunden aber verweist auf den falschen Benutzer. Auch unten bei den verbundenen Diensten ist ein fremdes Konto. Die Lizenz dieser Office-Instanz ist aber richtig. Ich habe mich dann einfach mal "abgemeldet" und Outlook neu gestartet. Klar musste ich nun wieder Anmeldeinformationen eingeben aber danach hat der Ordner sich wieder synchronisiert. In Word stand dann wieder

Vielleicht ist das aber auch mal ein Zeichen, die Windows 10 App-Konten etwas aufzuräumen.

Hier haben sich schon einige Konten gesammelt.

Weitere Links