Hochfahren: Missbrauch von Power-Apps, um On-Prem-Server zu kompromittieren

Die Power Platform-Dienste von Microsoft bieten eine Low-Code/No-Code (LCNC)-Plattform, die Datenanalyse (Power BI), Website-Entwicklung (Power Pages), virtuelle Agenten (Power Virtual Agent) und eine Art „vollständige Anwendungsentwicklung“ (Power Apps) umfasst. Diese Plattformen geben weniger versierten Geschäftsanwendern die Möglichkeit, Lösungen zu entwickeln, für die traditionell ein eher technisch versierter Entwickler mit Programmiererfahrung erforderlich wäre.

Obwohl LCNC-Plattformen ein mächtiges Werkzeug für Geschäftsanwender sein können, müssen die Entwickler der Plattform darauf achten, dass die Sicherheit in jedem Schritt integriert ist. Geschäftsanwender ohne formale Programmiererfahrung verfügen möglicherweise nicht über das gleiche Sicherheitsbewusstsein wie ein moderner Softwareentwickler. Dies kann die Wahrscheinlichkeit erhöhen, dass Benutzer Fehlkonfigurationen in diese LCNC-Plattformen einführen.

In diesem Blogbeitrag werden wir uns ansehen, wie das Adversary Simulation Team von X-Force Red im Jahr 2022 eine damals häufige Fehlkonfiguration von Benutzern mit einem immer noch vorhandenen Sicherheitsproblem in der Power Apps-Plattform von Microsoft kombinierte. Auf diese Weise konnte X-Force Red einen gehärteten externen Schutzwall durchbrechen und Code auf einem lokalen SQL-Server ausführen, was schließlich zu einer vollständigen Kompromittierung von Active Directory führte.

Im Jahr 2022 bedeutete das Standardverhalten von Power Apps, dass beim Teilen einer Power Apps-Anwendung mit Benutzern auch alle zugehörigen Verbindungen geteilt wurden. Dadurch war es für Benutzer sehr einfach, Verbindungen versehentlich mit allen Benutzern in einem Unternehmen zu teilen, obwohl sie vielleicht nur die Anwendung teilen wollten. Dieses Verhalten wurde laut Microsoft im Januar 2024 geändert, sodass es deutlich weniger wahrscheinlich ist, dass Nutzer versehentlich Verbindungen teilen.

Im Jahr 2022 entdeckte X-Force Red jedoch eine SQL-Verbindung, die über ein „On-Premises Data Gateway“ eine Verbindung zu einem lokalen SQL-Server herstellte, der auf diese Weise weit verbreitet war. Obwohl native SQL-Abfragen für On-Prem SQL-Server in Power Apps-Flows nicht unterstützt werden, stellte X-Force Red fest, dass die Aktion „Daten mit Power Query transformieren“ verwendet werden kann, um native SQL-Abfragen auf On-Prem-Servern auszuführen. Dadurch konnte X-Force Red auf den On-Prem SQL-Server umsteigen und letztendlich alle Ziele des Projekts erreichen.

Dieser Fehler wurde kürzlich dem Microsoft Security Response Center (MSRC) gemeldet und als geringfügig eingestuft. Daher veröffentlichen wir nun die Details.

Power Apps ermöglicht es Benutzern, mithilfe einer für LCNC-Plattformen typischen Drag-and-Drop-Oberfläche „Apps“ und „Flows“ zu erstellen. Apps können zur Erstellung von Front-End-Anwendungen verwendet werden, die im Allgemeinen dazu dienen, Daten von irgendwoher zu beziehen und sie dem Benutzer anzuzeigen. Nachfolgend finden Sie eine Demo-Anwendung namens „Budget Tracker“ von Microsoft, die Daten aus einer Excel-Tabelle einliest und dem Benutzer anzeigt.

Die andere Seite von Power Apps, Flows, dürfte jedem bekannt sein, der schon einmal einen anderen LCNC-Dienst wie Azure Logic Apps verwendet hat. Flows ermöglichen es Benutzern, ein Programm zu erstellen, das einem Flussdiagramm ähnelt. Sie werden in der Regel verwendet, um Daten abzurufen, zu verarbeiten und dann irgendwohin zu senden. Nachfolgend ist ein sehr einfacher Ablauf dargestellt, der eine HTTP-Anfrage stellt und anschließend das resultierende JSON analysiert.

Power Apps verfügt über eine Suite von „Konnektoren“, mit denen Benutzer Aufgaben wie das Aufnehmen von Daten oder das Versenden von E-Mails durchführen können, ohne auf eine Vielzahl von HTTP-Anfrageaktionen zurückgreifen zu müssen. Viele dieser Konnektoren sind lediglich vorgefertigte Bibliotheken von HTTP-Anfragen, die jedoch alle technischen Details für den Benutzer abstrahieren. Anstatt eine HTTP-Anfrage an die Graph-API erstellen zu müssen, um Informationen über einen Entra-ID-Benutzer zu erhalten, können Sie einfach einen Entra-ID-Connector anschließen und die Aktion „Benutzer abrufen“ verwenden.

Power Apps bietet Anschlüsse für viele beliebte Dienste an, darunter sowohl Microsoft-Dienste als auch Drittanbieter-Angebote. Man kann Dateien von SharePoint herunterladen, ein Dokument mit Adobe PDF Services in PDF umwandeln oder virtuelle Maschinen in Azure neu starten, um nur einige zu nennen. Wenn Sie eine Verbindung erstellen, werden Sie zum Prompt aufgefordert, Authentifizierungsmaterial anzugeben, je nachdem, mit welchem Service Sie sich verbinden. Für so gut wie alles, was mit Microsoft zu tun hat, authentifizieren Sie sich einfach mit Ihrem O365-Konto.

Hinweis: Für den Rest dieses Beitrags werde ich "Connector" verwenden, um die Aktionsbibliothek in Power Apps zu beschreiben (z. B. der Entra-ID-Connector), und "Connection" für einen Connector, der von einem Benutzer erstellt und authentifiziert wurde (z. B. die Entra-ID-Verbindung authentifiziert als john.smith@contoso.com). und kann verwendet werden, um neue Aktionen zu erstellen.

Solange diese Verbindung besteht, ist Ihre Authentifizierung mit ihr verbunden. Jeder Benutzer mit Zugriff auf diese Verbindung kann neue Aktionen erstellen, die Ihre Authentifizierung verwenden. Wenn Sie zum Beispiel eine Entra-ID-Verbindung erstellen, könnte ein anderer Benutzer mit Zugriff auf diese Verbindung eine Aktion "Benutzer zur Gruppe hinzufügen" ausführen, die Ihre Authentifizierung nutzt, auch wenn dieser Benutzer nicht die nötigen Entra-ID-Berechtigungen hätte, um einen Benutzer einer Gruppe hinzuzufügen. Ich habe bereits über den Missbrauch dieser Funktion in Azure Logic Apps gebloggt und einen brauchbaren Ausnutzen zur Privilegienerweiterung in Azure Logic Apps gefunden, der diese Funktion missbraucht.

Bis 2024 war diese Art von Angriff in Power Apps deutlich wahrscheinlicher. Früher war es so, dass beim Teilen einer Anwendung, die eine Verbindung nutzte, auch die zugehörige Verbindung geteilt wurde. Sie können dies auf dieser Seite nachlesen. von Microsoft, das seit 2022 nicht mehr aktualisiert wurde. Laut dieser Seite von 2024 ist dies jedoch nicht mehr der Fall. Jetzt müssen Sie die Verbindung mit Ihrem Konto teilen, was eine weitaus seltenere Fehlkonfiguration darstellt. Dies könnte das Ergebnis des BlackHat 2023-Vortrags „All You Need Is Guest“ gewesen sein. von Michael Bargury, ein hervorragender Vortrag, der auch das Aufzählen und Ausgeben von Informationen aus Power Apps behandelte.

Was, wenn Sie auf Daten zugreifen müssen, die im Internet nicht verfügbar sind? Was wäre, wenn Sie auf Daten eines lokalen SQL-Servers zugreifen müssten? Microsoft hat bereits daran gedacht und lokale Datengateways entwickelt. Gateways werden auf einem lokalen Host installiert und fungieren im Wesentlichen als Proxy, über den Power Apps-Konnektoren mit lokalen Ressourcen kommunizieren können. Um auf einen lokalen SQL-Server zuzugreifen, installieren Sie einfach ein Gateway auf dem SQL-Server (oder auf einem anderen Server oder vielleicht sogar auf Ihrer Workstation, wenn Sie Schatten-IT betreiben) und verwenden dann den SQL-Connector, um Abfragen auf dem Server durchzuführen.

Es gibt sechs unterstützte Authentifizierungstypen für die Verbindung zu einem SQL-Server, wobei nicht alle für lokale SQL-Server funktionieren. Bei einer lokalen Umgebung verwenden Sie wahrscheinlich entweder die SQL Server-Authentifizierung oder die Windows-Authentifizierung und geben dabei entweder Ihre AD-Anmeldedaten oder lokale SQL-Anmeldedaten an.

Sobald Sie Ihre Verbindung erstellt oder Zugriff auf eine gemeinsame Verbindung erhalten haben, können Sie eine Reihe von Aktionen gegen den SQL-Server durchführen. Die Meldung, die den meisten Lesern auffallen wird, ist „Execute a SQL Query (V2)“.

Wenn Sie mit den Auswirkungen der Ausführung nativer SQL-Abfragen nicht vertraut sind, empfehle ich Ihnen, diesen Blogbeitrag meines Kollegen Sanjiv Kawa über sein Tool SQLRecon zu lesen. Wenn man SQL-Abfragen auf einem Server ausführen kann, kann man natürlich alle Daten, zu denen man Zugriffsberechtigungen hat, dumpen. Dies könnte problematisch sein, wenn sensible Daten in der Datenbank gespeichert werden. Wenn Sie jedoch privilegierten Zugriff auf den SQL-Server haben, können Sie Code auf dem zugrunde liegenden Betriebssystem ausführen. Hier sind ein paar Möglichkeiten, wie Sie das tun könnten:

• Die gespeicherte Prozedur xp_cmdshell
• OLE-Automatisierungsverfahren
• Ausführung von .NET CLR-Assemblies
• SQL Agent-Jobs

Dies hängt letztlich von den Berechtigungen des Benutzers ab, der die Verbindung hergestellt hat. Wenn Sie jedoch schon einmal über einen SQL-Server gearbeitet haben, um ein bestimmtes Ziel zu erreichen, dann wissen Sie, wie häufig überprivilegierte Konten vorkommen. Selbst wenn der verbundene Benutzer nicht über die Berechtigung zum Ausführen von Code verfügt, können Sie auch auf Impersonation, Links zu anderen SQL Servern oder Zugangsdaten, die im Klartext in Datenbanken gespeichert werden, prüfen.

All dies ist jedoch letztlich bedeutungslos, da die Aktion „SQL-Query ausführen (V2)“ für Gateways nicht unterstützt wird.

Andere Aktionen, wie „Zeilen abrufen (V2)“, mit denen die Zeilen aus einer bestimmten Tabelle abgerufen werden, funktionieren einwandfrei. Wir können einfach keine beliebigen Abfragen auf dem Server ausführen. Ich nehme an, dies liegt daran, dass Microsoft die Möglichkeit des Missbrauchs in Betracht gezogen und entschieden hat, dass es schlecht ist, die Sicherheitslücken von lokalen SQL-Servern externen O365-Benutzern preiszugeben.

Wenn Sie alle verfügbaren Aktionen für den SQL-Connector durchsehen, werden Sie die Aktion „Daten mit Power Query transformieren“ entdecken. Trotz des Namens ist Power Query kein Mitglied der Power Platform-Dienstfamilie. Es handelt sich vielmehr um eine Datentransformations-Engine, die auch in anderen Diensten/Anwendungen wie Excel zu finden ist. Als Datenkonvertierungs-Engine ist Power Query darauf ausgelegt, Daten zu übernehmen und umzuwandeln, ohne die Quelldaten zu verändern.

Nach dem Erstellen einer „Daten mit Power Query transformieren“-Aktion mit einer gültigen Verbindung wird ein Menü angezeigt, in dem alle Tabellen der jeweiligen Datenbank aufgeführt sind, mit der die Verbindung hergestellt wurde. In meinem Test-SQL-Server gibt es nur eine leere Tabelle namens „Persons“.

Wenn Sie „Daten transformieren“ auswählen, gelangen wir zum nächsten Bildschirm, einem Power Query-Editor. Power Query verwendet die M-Formelsprache, eine von Microsoft entwickelte Datenkonvertierungssprache. Die Referenzdokumentation für die Programmiersprache M beschreibt die „Zugriffsfunktionen für Daten“, eine Liste von Funktionen, die zum Importieren von Daten in Power Query verwendet werden können. Wenn wir unseren Power Query-Editor für die Standardabfrage öffnen, sehen wir, dass die Funktion „Sql.Databases“ verwendet wird, um Informationen aus der verbundenen Datenbank abzurufen.

Beim Durchblättern der 1394-seitigen PDF-Version der M-Sprache fiel mir auf, dass die Funktion „Sql.Database“ (beachten Sie das fehlende „S“) einen optionalen Parameter namens „Query“ besitzt. Dieser Parameter wird als „Eine native SQL-Query zum Abrufen von Daten“ beschrieben.

Wenn Sie den folgenden Power Query-Code in den Editor einfügen, wird eine Warnung angezeigt, die besagt, dass „native Abfragen möglicherweise unsicher sind und die Datenbank verändern“.

Nun ja, „Datenbanken verändern“ ist quasi mein zweiter Vorname, also werden wir nach dem Klicken auf „fortfahren“ mit der Ausgabe einer nativen SQL query belohnt.

Um es noch einmal zusammenzufassen: Hier erfahren Sie, wie Sie dies missbrauchen können, um einen lokalen SQL-Server zu kompromittieren, der nur Zugriff auf eine Power Apps-Lizenz hat:

1. Ein Nutzer erstellt eine Anwendung, die eine lokale SQL-Verbindung nutzt und diese mit allen teilt, entweder absichtlich oder unbeabsichtigt.
2. Ein Angreifer erstellt einen neuen Datenfluss und fügt eine Aktion „Daten mit Power Query transformieren“ unter Verwendung der bestehenden SQL-Verbindung hinzu.
3. Wenn der verbundene Benutzer ein SQL-Administrator ist oder über Identitätswechselrechte verfügt, oder wenn privilegierte SQL-Links oder Klartext-Anmeldeinformationen in Datenbanken vorhanden sind, oder wenn Sie andere privilegierte Klartext-Anmeldeinformationen erhalten haben, können Sie jetzt zu einem lokalen SQL-Server wechseln.

Laut diesen Microsoft-Dokumenten , die zuletzt 2022 aktualisiert wurden, wird das Gateway ebenfalls geteilt, wenn man eine App teilt, die Daten von einem Gateway verwendet. Nach Tests in meinem Mieter scheint dies nicht mehr der Fall zu sein. Wenn Sie jedoch Zugang zu einem Gateway haben, können Sie über dieses Gateway neue Verbindungen herstellen, so dass Sie nicht mehr durch die bestehenden Verbindungen eingeschränkt sind. Dies bedeutet, dass Sie kompromittierte Klartext-Anmeldeinformationen für AD- oder SQL-Konten benötigen und die Hostnamen der SQL-Server kennen müssen, obwohl es nicht ungewöhnlich ist, diese Informationen in SharePoint/Confluence zu finden.

Sie können auch andere Connectoren profitieren, die Gateways verwenden, wie zum Beispiel die Aktion „Dateisystem“. Auch hierfür benötigen Sie gültige Zugangsdaten und Hostnamen, aber Sie können Dateien auf internen Hosts lesen und schreiben.

Wenn Sie Zugang zu einem Konto mit Zugriff auf Power Apps erhalten, sollten Sie alle Umgebungen überprüfen, auf die Sie Zugriff haben. Dies können Sie überprüfen, indem Sie in der oberen rechten Ecke das Dropdown-Menü „Umgebung“ auswählen. In jeder Umgebung sollten Sie „… Mehr“ und dann „Alle entdecken“ auswählen. Dadurch gelangen Sie zu einer Seite, auf der Sie zu allem in Power Apps navigieren können.

Dort können Sie „Verbindungen“ auswählen, um alle Verbindungen anzuzeigen, auf die Sie Zugriff haben, und „Gateways“, um alle Gateways anzuzeigen, auf die Sie Zugriff haben. Sie können auch sehen, wem die Verbindungen gehören, sodass Sie überprüfen können, ob der Benutzer privilegiert ist oder nicht.

Zusätzlich befinden sich auf der linken Seite des Bildschirms die Schaltflächen „Flows“ und „Apps“. Sie sollten auf „Mit mir geteilt“ klicken, damit Sie alles sehen und nach Zugangsdaten oder vertraulichen Informationen suchen können. HTTP-Flow-Aktionen eignen sich besonders gut zum Aufspüren von Passwörtern und API-Schlüsseln.

Administratoren sollten in Erwägung ziehen, die Anzahl der Benutzer, die Gateways installieren können, einzuschränken oder sie ganz zu deaktivieren, wenn es keinen Anwendungsfall für sie gibt. Sie können dies tun, indem Sie in die Power Apps-Administrationsplattform gehen, „Daten“ auswählen, das Kontrollkästchen „Mandantenverwaltung“ aktivieren und dann „Gateway-Installer verwalten“ auswählen. Dort können Sie die Einstellung „Benutzer in Ihrem Unternehmen daran hindern, Gateways zu installieren“ aktivieren und Benutzer hinzufügen, die Gateways installieren müssen. Weitere Informationen finden Sie in der Microsoft-Dokumentation .

Überprüfen Sie regelmäßig die Verbindungen in Ihrer Umgebung und stellen Sie sicher, dass sensible Verbindungen nicht unkontrolliert weitergegeben werden.

In diesem Blog haben wir untersucht, wie ein Nutzer mit Zugang zu einem SQL-Server-Connector über ein lokales Datengateway native Abfragen auf dem Server ausführen und möglicherweise von O365 auf lokale Ressourcen umsteigen kann. Das Verhalten, das zuvor zu einer häufigen Fehlkonfiguration führte, wurde 2024 geändert, aber mit dem richtigen Zugriff kann ein Angreifer immer noch in der Lage sein, diese Funktion zu missbrauchen. Mit der Veröffentlichung dieses Blogbeitrags hoffen wir, dass die Sicherheitsverantwortlichen ihre Umgebung überprüfen, um Gateways und übermäßig genutzte Konnektoren zu identifizieren und so zukünftige Angriffe auf Power Apps zu verhindern.

10.02.2025: Ursprünglicher MSRC-Fall abgesendet

2/11/2025: MSRC stellt fest, dass es sich um ein Problem der Sozialtechnik handelt und schließt den Fall ab

02.12.2025: Zweiter MSRC-Fall abgesendet

24.02.2025: MSRC bewertet Sicherheitslücke mit niedrigem Schweregrad