Zufällig, wie sie selbst beschreiben, stießen Penetration Tester um Karl Fosaaen vom Unternehmen NetSPI auf eine verdächtige Zeichenkette in einem App-Registration-Manifest im Azure Active Directory, das man als AAD-Nutzer in der Azure-Oberfläche einsehen kann. Was dort unterhalb des Eintrags keyCredentials mit Base64 encodiert stand, entpuppte sich nach dem Dekodieren als privater Schlüssel im PFX-Format. Um herauszufinden, wie ein solcher so öffentlich einsehbar im Manifest landen konnte, legten sie einen neuen Automation-Account an und aktivierten den "Run-As"-Haken in der Oberfläche. Das Konzept kennen Windows-Server-Administratoren ohne Azure von geplanten Aufgaben, die im Namen eines Funktionsbenutzers eingerichtet und ausgeführt werden können.
Dass jeder AAD-Nutzer die Schlüsseldaten so einfach aus einem JSON-Objekt auslesen kann, macht eine Rechteausweitung möglich. Zum Test legten die Forscher einen Account ohne Rechte an und bauten ein PowerShell-Skript, das automatisch nach den Zertifikaten des Automations-Accounts suchte. So konnten sie beweisen, dass sich ein Nutzer ohne weitere Rechte automatisiert Zugriff auf Zugangsdaten mit der Contributor-Rolle beschaffen konnte. Mit diesen Ergebnissen informierten sie am 7. Oktober 2021 das Microsoft Security Response Center (MSRC) und die Redmonder reagierten. Am 29.10. konnte NetSPI feststellen, dass Abhilfe geschaffen wurde, nachdem man vorher im Kontakt mit Microsoft stand und Details zur Lücke ausgetauscht hatte.
Quelle: heise
Dass jeder AAD-Nutzer die Schlüsseldaten so einfach aus einem JSON-Objekt auslesen kann, macht eine Rechteausweitung möglich. Zum Test legten die Forscher einen Account ohne Rechte an und bauten ein PowerShell-Skript, das automatisch nach den Zertifikaten des Automations-Accounts suchte. So konnten sie beweisen, dass sich ein Nutzer ohne weitere Rechte automatisiert Zugriff auf Zugangsdaten mit der Contributor-Rolle beschaffen konnte. Mit diesen Ergebnissen informierten sie am 7. Oktober 2021 das Microsoft Security Response Center (MSRC) und die Redmonder reagierten. Am 29.10. konnte NetSPI feststellen, dass Abhilfe geschaffen wurde, nachdem man vorher im Kontakt mit Microsoft stand und Details zur Lücke ausgetauscht hatte.
Lücke geschlossen
Die Lücke hat die CVE-2021-42306 bekommen und wurde geschlossen. Microsoft konnte in seinen Logs keine Hinweise darauf finden, dass das Problem ausgenutzt wurde. Obwohl die privaten Schlüssel jetzt nicht mehr ausgelesen werden könnten, besteht das Risiko, dass sie schon vorher jemand unberechtigt abgerufen hat – daher sollten die Zertifikate ausgetauscht werden. Wer Run-As-Accounts mit automatisch generierten Zertifikaten in Azure Active Directory nutzt, die zwischen dem 15.10.2020 und dem 15.11.2021 ausgestellt wurden, sollte den Schritten in Microsofts GitHub-Repository mit Reparaturanweisungen folgen. Betroffen sein können auch Nutzer von Azure Migrate und Azure Site Recovery. Wann bei diesen Produkten Handlungsbedarf besteht, beschreibt Microsoft in einem Blogpost und stellt Anleitungen bereit.Quelle: heise
