CSV-Injektion in Azure-Protokolle

Mit der weltweiten Umstellung auf cloud mussten die Unternehmen die Art und Weise, wie sie bösartige Aktivitäten in ihren Umgebungen verfolgen, neu überdenken. Einige der alten Überwachungsmechanismen (wie z. B. die Paketaufzeichnung) stehen nicht mehr zur Verfügung, und die Ereignisprotokolle haben neue Bedeutung erlangt. Oft sind sie das einzige Werkzeug, das Sie haben, um zu verfolgen, was in Ihrer Infrastruktur vor sich geht.

Cloud Anbieter hatten bei der Implementierung von Protokollierungsfunktionen mit Wachstumsschmerzen zu kämpfen. Insbesondere Azure hat mit zahlreichen Problemen bei der Protokollqualität zu kämpfen. Protokolle stellen auch ein interessantes Aufklärungsziel für Angreifer dar, die Ihre Umgebung abbilden wollen, unddort können sensible Informationendurchsickern.

So schwerwiegend diese Probleme auch sein können, sie sind "passiv" - die Offenlegung von Informationen ist das Schlimmste, was passieren kann. Allerdings können Protokolle gelegentlich zum Träger von Angriffen auf das Unternehmen werden. Wir werden in diesem Blog einen solchen Angriff beschreiben.

Protokollinjektion und CSV-Injektion

Bei einer Log-Injection handelt es sich um einen Angriff, bei dem ein Angreifer den Inhalt eines Protokolls beeinflussen kann, indem er ihm eine speziell gestaltete bösartige Nutzlast hinzufügt. Dies geschieht, weil Benutzeraktionen häufig dazu führen, dass neue Datensätze zu den Protokollen hinzugefügt werden, und diese Datensätze enthalten oft die Daten, über die der Benutzer Kontrolle hat: Benutzer-IDs, E-Mail-Adressen, Nachrichtenbetreffe usw. Wenn diese Daten böswillig manipuliert werden, kann die Anwendung, die die Protokolle verarbeitet, dazu verleitet werden, einen Angriff auszuführen. So könnte beispielsweise eine gefälschte E-Mail-Adresse mit einer XSS-Nutzlast (Cross-Site Scripting) in einem Kontoanmeldeformular übermittelt werden. Und der Anwendungsadministrator, der dieses Protokoll in einem Browser öffnet, kann Opfer eines XSS-Angriffs werden.

Protokolle in Azure können als CSV-Dateien (Comma-Separated Values) heruntergeladen werden, die für eine CSV-Injection-Technik anfällig sind. Wenn eine CSV-Datei eine Excel-Formel enthält (die in der Regel mit einem Gleichheitszeichen - "=" - beginnt), wird diese beim Öffnen der Datei von Excel ausgeführt. Einige Formeln können bösartig sein und die Ausführung von Betriebssystembefehlen oder andere Exploits verursachen. Dies kann nicht nur gefährlich sein, weil beliebige Befehle ausgeführt werden können, sondern auch, weil die Benutzer in der Regel nichts davon wissen, weil sie denken, dass CSV-Dateien nur einfache Textdateien sind, die keinen Schaden anrichten können. 

Wir haben einen neuen Fall von Log Injection in Kombination mit CSV Injection in Azure gefunden, der für Angriffe auf Azure-Administratoren genutzt werden kann. Solche Schwachstellen wurdenbereits in der Vergangenheit gemeldet, aber dieser Fall ist noch gefährlicher, da erunauthentifiziert ausgeführt werden kann, d. h. Sie müssen kein Konto in der cloud Umgebung haben.

Angriffsszenario

Der Angriff besteht aus zwei Phasen:

1. Azure-Protokolle verschmutzen

2. Social Engineering bei einem Opfer-Administrator, damit er die Protokolle als CSV-Datei öffnet

*Beachten Sie, dass der Angriff bei einer vollständig aktualisierten MS Excel-Instanz nicht funktioniert (mehr dazu später).

Verschmutzung von Azure-Protokollen mit bösartigen Benutzer-Agenten

Um die Protokolle mit einem bösartigen Befehl zu verunreinigen, benötigen Sie keine besonderen Berechtigungen oder gar ein Konto auf dem Opfersystem. Sie brauchen nur den Benutzernamen eines bestehenden Benutzers.

Wir beginnen mit der Übermittlung der Injektionsnutzlast als User-Agent-String:

1. Starten Sie Microsoft Edge (jeder Browser funktioniert, solange Sie den User Agent wie unten beschrieben manipulieren können, ebenso wie jeder Angriffsproxy wie Burp oder ZAP)

2. Öffnen Sie dieEntwicklertools (Strg+Umschalt+I), klicken Sie auf das Menü oben rechts und wählen Sie Befehl ausführen(Strg+Umschalt+P):

3. Geben Sie"Netzwerkbedingungen" ein und drücken Sie die Eingabetaste:

4. Deaktivieren Sie in der sich öffnenden Schublade die Option"Browser-Standard verwenden" und fügen Sie die folgende Zeichenfolge in das untere Feld ein:

=msexcel|'\..\..\..\Windows\System32\cmd.exe /c calc.exe'!'A1'

Diese Excel-Beispielformel verwendet das Dynamic Data Exchange (DDE)-Protokoll zum Starten des Rechners. Eine echte Nutzlast wird etwas destruktiver sein (z. B. ein PowerShell-Befehl, der die nächste Stufe der Infektion herunterlädt).

5. Gehen Sie, ohne die Schublade zu schließen, aufhttps://portal.azure.comund geben Sie die E-Mail eines beliebigen bestehenden Kontos in Ihrem Zielsystem ein.

6. Wenn Sie nach einem Passwort gefragt werden, geben Sie eine beliebige Zeichenfolge ein(es ist nicht unser Ziel, uns erfolgreich anzumelden!):
   
    

Das Opfer dazu bringen, die Protokolle zu öffnen

Die Anmeldeprotokolle im Ziel-Azure-Tenant enthalten nun den vergifteten Protokolleintrag (es kann einige Minuten dauern, bis er tatsächlich geliefert wird).

Nun können Sie den Zieladministrator durch Social Engineering dazu bringen, die Protokolle zu öffnen. Im Portal gibt es zwei Dienste, bei denen dies möglich ist: Log Analytics und Microsoft Entra ID. Wir werden den ersteren beschreiben.

Jeder Benutzer mit Lesezugriff auf Azure Log Analytics ist ausreichend, es muss sich also nicht um einen Administrator mit Top-Level-Rechten handeln. 

Es gibt eine Vielzahl von möglichen Vorwänden. So kann sich beispielsweise ein"Azure-Techniker für den technischen Support" an den Administrator wenden und um Unterstützung bei der Untersuchung"verdächtiger Anmeldeversuche" bitten.

Die Schritte sind wie folgt:  

1. Weisen Sie das Ziel an,Azure Log Analyticszu öffnen und die TabelleSigninLogsin das Abfragefenster zu laden (doppelklicken Sie darauf). Klicken Sie auf die SchaltflächeAusführen, um die Standardabfrage auszuführen:
   
   

2. Das Protokoll wird geladen, und einer der Einträge enthält unsere Nutzlast:

3. Weisen Sie die Zielperson an, das Protokoll als CSV-Datei in Excel zu laden, umdie Analyse zu erleichtern:
   
   

4. Die Protokolle werden in Excel geladen. Es erscheint eine Warnmeldung, die die Zielperson ignorieren sollte:
   
   

5. Es wird eine weitere Warnmeldung angezeigt, die das Ziel ebenfalls ignorieren sollte. Beachten Sie, dass die Anwendung, über die sie sich beschwert, "MSEXCEL.EXE" heißt, was weniger verdächtig ist als etwas wie "CMD.EXE":  
   

6. Die Calculator-Instanz wird erscheinen (genau wie von uns beabsichtigt):
   
   

In diesem Video können Sie den Angriff in Aktion sehen:

Umgang mit dem Excel-DDE-Schutz

Diese Sicherheitsanfälligkeit wird in der neuesten aktualisierten Version von MS Excel nicht standardmäßig ausgelöst. Microsoft hat Abhilfemaßnahmen implementiert, um zu verhindern, dass der DDE-Server standardmäßig über Excel-Formeln gestartet wird. Damit die Nutzlast korrekt funktioniert, muss das Ziel eine ältere Version von Excel verwenden oder derDDE-Server-Startin der neuesten Version von Excel aktiviert sein (z. B. durch Anweisung des Angreifers als Teil der Social-Engineering-Phase).

Um diesen Schutz in Excel zu deaktivieren, gehen Sie zuDatei > Optionen > Trust Center > Trust Center-Einstellungen... > Externer Inhaltund aktivieren SieDynamischen Datenaustauschserverstart aktivieren (nicht empfohlen):

Jenseits von DDE

Die Beschränkung der DDE-Aufrufe mag den Anschein erwecken, dass die Benutzer sicher sind, aber diese Sicherheit ist trügerisch. Verschiedene andere gefährliche Formeln, die kein DDE erfordern, können eingeschleust werden. Hier sind einige Beispiele (bei den meisten wird beim Öffnen der Datei eine Warnmeldung angezeigt):

Offenlegung

Wir haben diese Schwachstelle verantwortungsbewusst gegenüber Microsoft offengelegt:

2022-09-13 - Gemeldet an MSRC
2022-09-21 - MSRC antwortete: "...Die Schwachstelle besteht tatsächlich darin, wie Microsoft Excel Dateien öffnet. Sie erfordert auch das Durchklicken einer Warnung in Microsoft Excel. Wir könnten das Blockieren von CSV-Injektions-Payloads als DND-Vorsichtsmaßnahme als Fix in den nächsten Versionen in Betracht ziehen."

Microsoft schien sich nicht zu verpflichten, Änderungen vorzunehmen, um CSV-Injection-Payloads zu verhindern, und die Sicherheitslücke besteht bis heute. 

Milderung

Microsoft hat zwar richtig festgestellt, dass Sicherheitsupdates in Excel das Auslösen von DDE-Nutzdaten verhindern, aber es gibt noch weitere Faktoren zu berücksichtigen:

• Das Opfer hat möglicherweise eine alte, nicht gepatchte Version von Excel installiert oder wurde durch Social Engineering dazu gebracht, die Schutzmaßnahmen zu vernachlässigen. Ein entsprechendes Szenario haben wir oben beschrieben.

• Es gibt in Excel Formeln, die nicht DDE sind und die gefährlich sein können. Wir haben mehrere Beispiele dafür beschrieben. Außerdem fügt Microsoft neuePython-Funktionen zu Excel-Formeln hinzu, und der Aufruf von Python-Code durch Injektion kann neue, unerwartete Folgen haben.  

• Andere Anwendungen können CSV-Dateien öffnen, was zu neuen Exploits führen kann. Unter Linux ist zum Beispiel LibreOffice ein beliebtes Office-Paket, das zum Öffnen von CSV-Dateien verwendet werden kann. Es führt Excel-Formeln aus und unterstützt auch DDE.

• Und schließlich ist es wichtig, "Verteidigung in der Tiefe" zu praktizieren. Es wäre konsequent, sich nicht nur auf eine Excel-Korrektur zu verlassen, sondern auch die Möglichkeit der Einspeisung von Formeln in CSV-Dateien, die von Azure generiert werden, an der Quelle zu eliminieren.

We believe that the right course of action is for Microsoft to sanitize values in CSV file cells that begin with "=" (and some others cells that start with "+", "-", "@", and some other characters can also be interpreted as formulas). The original values do not have to be removed (after all, they may be important to the defender). Prefixing them with some string that clarifies the intent (e.g. "<INSERTED TO MITIGATE POSSIBLE CSV INJECTION>") will be sufficient.

Bis dahin sollten Azure-Benutzer alle Tools, die sie zum Öffnen von CSV-Dateien verwenden, vollständig aktualisieren und ihre IT-Mitarbeiter über die Gefahren bösartiger Nutzdaten in Azure-Protokollen und Social-Engineering-Angriffe, die diese auszunutzen versuchen, aufklären.

Diskutieren Sie mit uns direkt über diesen Blogbeitrag und andere Themen in der Vectra AI Reddit-Gemeinschaft.