Privater Schlüssel mit Microsoft Dynamics 365 verteilt

Microsoft hat ungewollt den Zugriff auf seine Kronjuwelen freigegeben, indem ein ein Wildcard-Zertifikat mit privatem Schlüssel für alle Dynamics 365-Instanzen verwendet wurde. Redmond brauchte dabei Monate, um auf das Thema zu reagieren und das Zertifikat zu widerrufen.

Es klingt wie Pleiten, Pech und Pannen, dürfte aber so manchem Blog-Leser irgendwie bekannt vorkommen. Du informierst Microsoft über irgend etwas ungereimtes und es passiert nix.

Worum geht es?

Microsoft Cloud ERP-Produkt Dynamics 365 verwendete verschlüsselte HTTPS-Verbindungen zu den Instanzen, die auf Azure-Servern laufen. Kunden bekommen also eine ERP-Instanz auf dem jeweiligen Azure-Server und können per RDP auf diese Instanz zugreifen. Ist ja alles in der Cloud. Das Problem: Das Unternehmen aus Redmond hat nun ein Wildcard-Zertifikat für alle Instanzen von Dynamics 365 verwendet und mit diesem Zertifikat den privaten TLS-Schlüssel gleich mitgeliefert.

Matthias Gliwka hat dies beim Arbeiten mit Dynamics 365 vor einiger Zeit entdeckt, wie er in diesem Medium-Beitrag schreibt. Die Verwaltung der Dynamics 365-Instanzen erfolgt per Remote Desktop Protocol-Verbindungen (RDP). Irgendwann wollte Gliwka sich ansehen, wie Microsoft seinen Server in einer solchen geschäftskritischen Anwendung aufsetzt. Also verband er sich per RDP mit der Sandbox-Umgebung und schaute sich das Zertifikat an.

(Quelle: Matthias Gliwka)

Das Wildcard-TLS-Zertifikat galt für alle Instanzen von *.sandbox.operations.dynamics.com und enthielt einen privaten Schlüssel. Wer diesen privaten Schlüssel besitzt, kann praktisch die Kommunikation über Man-in-the-middle-Angriffe aller anderen Dynamics 365-Instanzen per RDP mitlesen und notfalls auch verändern (z.B. Schadcode einschleusen).

Es braucht lediglich einen Kniff, um den privaten Schlüssel zu exportieren. Wie Gliwka schreibt, verweigert der Windows Certificate-Manager zwar diesen Export. Dazu gibt es eine API-Funktion zur Prüfung, ob ein Zertifikat exportiert werden darf. Aber mit einem kurzen C++-Programm, welches sich in die API-Funktion zur Prüfung einklinkt, war es ihm möglich, diesen privaten Schlüssel zu exportieren. Es gibt aber wohl auch Tools, die das erledigen können.

Microsoft Security Response Center (MSRC) schläft

Lange Geschichte kurzer Sinn: Gliwka informierte das Microsoft Security Response Center (MSRC) über seine Entdeckung und glaubte, dass das

Problem fix behoben werde. Nach mehreren Nachfragen kam eine Antwort des MSRC, dass man nicht glaube, dass das Problem in Produktivumgebungen relevant sei – die Kommunikation ist hier nachlesbar.

Dann kontaktierte er eine ihm bekannt Person aus der Produktgruppe, um das Thema nochmals einzuspeisen. Diese versuchte beim MSRC-Team den Fall aufzuwärmen, was sich aber zäh gestaltete. Es gab zwar eine Mail, dass man nun das Ganze aktiv untersuche – aber auch Wochen später tat sich nichts. Irgendwann versuchte er einen Chat mit dem Microsoft-Support, um auf diesem Weg einen neuen Kontakt mit dem MSRC zu erhalten. Er bekam auch eine Telefonnummer, die zur Marine Spill Response Corporation (MSRC) gehörte. Dazu muss man wissen, dass dies eine spezielle Organisation für Ölkatastrophen und Notfallmaßnahmen in den Vereinigten Staaten ist. Die kümmern sich zwar auch um Lecks, aber in Ölleitungen – weniger um Lecks in TLS-Zertifikaten. Aber wie heißt es so schön: 'Sie haben sich wenigstens bemüht'.

Ein Versuch, das Ganze nochmals per Twitter anzuschieben, ergab zwar eine Antwort, dass man das untersuche, aber kein Ergebnis.

@msftsecresponse Reported a leaked TLS private key for a cloud product >45 days ago – still no response. Can you take a look? Case #40397

— Matthias Gliwka (@cerebuild) 4. Oktober 2017

Auch 100 Tage nach der Entdeckung war das Zertifikat in Gebrauch. Gliwka dachte erst daran, das Ganze per Blog-Beitrag öffentlich zu machen. Dann entschloss er sich, Hanno Böck zu kontaktieren (der verdient sich seine Meriten mit Sicherheitsthemen und schreibt häufiger für Golem). Böck hat dann das Thema für Golem in diesem Artikel in deutsch aufbereitet – ich selbst bin über drei Ecken über diesen englischsprachigen Beitrag (via) aufmerksam geworden.

Hanno Böck schreibt, dass kompromittierte private Schlüssel binnen 24 Stunden zurückgezogen werden sollen. Also meldete er über den Bugtracker das Problem an Mozilla und informierte einen Chrome-Entwickler sowie einen Vertreter von Digicert. Damit kam Bewegung in die Geschichte, wohl auf Druck von Mozilla. Innerhalb weniger Tage wurden die Wildcard-Zertifikate zurückgezogen. Künftig will Microsoft die Instanzen von Dynamics 365 mit Zertifikaten ausstatten, die einen eigenen privaten Schlüssel enthalten. Schöne neue Welt – und wir wollen mit Industrie 4.0 alles vernetzen.