Die Kontrolle und Einschränkung von Anwendungen ist eine wichtige Schutzmaßnahme in der IT-Sicherheitsarchitektur eines Unternehmens. Doch schon kleine Konfigurationsfehler können schwerwiegende Folgen haben. Wir zeigen in diesem Artikel auf, was Sie bei der Konfiguration der Application Controls unbedingt beachten müssen und weshalb die Durchführung eines Penetrationstests in einer solchen Umgebung zu empfehlen ist.
Welche Rolle spielt Application Control in der IT-Sicherheitsarchitektur?
Es ist keine neue Erkenntnis, dass Anwendungen durch Angreifer gekapert oder missbräuchlich eingesetzt werden können. Application-Control-Mechanismen können im Gegenzug dazu verwendet werden, um die Möglichkeiten des potentiellen Angreifers von vornherein maßgeblich einzuschränken.
Microsoft fasst den Zweck von Application Control (zu deutsch: Anwendungssteuerung) wie folgt zusammen:
“Die Anwendungssteuerung kann dazu beitragen, Sicherheitsbedrohungen zu mindern, indem die Anwendungen, die Benutzer ausführen dürfen, und der Code, der im Systemkern (Kernel) ausgeführt wird, eingeschränkt wird. Anwendungssteuerungsrichtlinien können auch nicht signierte Skripts und MSIs blockieren und Windows PowerShell auf die Ausführung im eingeschränkten Sprachmodus beschränken.”
Sprich: Application Control ist wie Schwachstellenmanagement oder Systemhärtung eine Maßnahme, um die Angriffsfläche der IT-Infrastruktur zu verkleinern. Damit gehört Application Control im Rahmen des Dreiklangs “Prävention – Detektion – Reaktion” in den Bereich der präventiven IT-Sicherheitsmaßnahmen.
Lässt sich ein System trotz Einsatz von Application Control kompromittieren?
Die kurze Antwort auf diese Frage lautet: Ja. Im Falle einer ungünstigen oder unvollständigen Konfiguration hat ein Angreifer die Möglichkeit, die Application-Control-Mechanismen zu umgehen. Um aufzuzeigen wie das geht, haben wir unsere erfahrenen Pentesting-Kollegen/-innen gebeten, sich ans Werk zu machen und mögliche Angriffsszenarien zu entwickeln.
Beispiele, wie sich Anwendungskontrolle aushebeln lässt
Im Folgenden skizzieren wir zwei Szenarien, in denen unser Pentesting-Team erfolgreich die Application-Control-Mechanismen eines vielfältig eingesetzten Produktes umgeht: Carbon Black App Control von VMWare.
Wie? Eine Umgehung der Kontrollmechanismen ist möglich, wenn beispielsweise der Windows Script Host nicht Teil der sogenannten “ban rules” ist. Oder wenn die Ausführung von Binärdateien aus nicht vertrauenswürdigen Verzeichnissen wie c:\users\public erlaubt wird. Beide Szenarien erklären wir in den folgenden Absätzen.
Szenario 1: Ausführung von geblockten, nicht-signierten Binärdateien
Anwendungen wie wscript und cscript, die Jscript.dll als Engine-Bibliothek verwenden, können Skripte mit eingebetteten, Base64-serialisierten Binärdateien ausführen. Und sie können daher von einem Angreifer verwendet werden, um die Detektionsmechanismen von Carbon Black App Control zu umgehen.
Hier zeigen wir, wie unser Pentesting-Team das in der Praxis umgesetzt hat und erfolgreich geblockte, nicht-signierte Binärdateien ausgeführt hat.
Im ersten Schritt haben wir das reguläre AccessChk-Programm ausgeführt. Dieses wurde wie erwartet von Carbon Black App Control blockiert, da dieses Executable nicht explizit von Carbon Black freigegeben war. Das ist in folgendem Screenshot zu sehen:
Im zweiten Schritt haben unsere Pentester eine C#-Anwendung mit einer mit AccessChk vergleichbaren Funktion entwickelt, um eine Umgehung der Blocking-Konfiguration in die Praxis umzusetzen. Diese C#-Anwendung wurde anschließend mittels tyranid/DotNetToJScript mit einem JScript-Wrapper versehen.
Und siehe da: Die JScript-Datei konnte, wie in der Abbildung unten zu sehen ist, erfolgreich ausgeführt werden – und das, obwohl unsere C#-Anwendung nicht in der Konfiguration von Carbon Black App Control freigegeben war!
Szenario 2: Umgehung der DLL-Blocking-Regeln
Im zweiten Szenario versuchten unsere Pentesting-Experten die DLL-Blocking-Regeln von Carbon Black App Control zu umgehen. Das Ziel hierbei: PowerShell.exe trotz vorhandener DLL-Blocking-Regeln erfolgreich starten und vollumfänglich nutzen.
Wie in folgendem Screenshot zu sehen ist, verhindern die konfigurierten Regeln von Carbon Black App Control erfolgreich den Zugriff von PowerShell.exe auf die Bibliothek clr.dll. Demzufolge wird die Ausführung von PowerShell.exe blockiert.
Bei der Bewertung dieses Ergebnisses sollte man Folgendes berücksichtigen: Die Regeln (“ban rules”) prüfen in diesem Fall ausschließlich, ob die Binärdatei signiert ist oder nicht. Es wird aber nicht der Pfad überprüft, von dem aus die Anwendung ausgeführt wurde. Das ist gleichbedeutend mit einer wesentlichen Einschränkung des Sicherheitsgewinns, der aus der DLL-Blockierung resultieren sollte.
Warum? Es ist möglich, das Laden bestimmter Bibliotheken zu verhindern, indem man die Zielanwendung einfach umbenennt. Die Win32-Funktion LoadLibraryExW merkt sich den Namen clr.dll bereits im Prozessspeicher und wird daher nicht versuchen, die DLL erneut zu laden.
Im ersten Schritt haben wir eine Kopie von PowerShell_ise.exe erstellt:
Im zweiten Schritt haben wir die Binärdatei entsprechend von PowerShell_ise.exe in clr.dll umbenannt:
Im dritten Schritt nutzten wir die von WScript.Shell.Exec implementierte CreateProcessA-Funktion, um die umbenannte Binärdatei mittels JScript erfolgreich zu starten. Das Ergebnis: Das Trovent Pentest-Team war in der Lage, die PowerShell-Konsole aufzurufen. Ziel erreicht!
Da die fehlende clr.dll Bibliothek einige Funktionen von PowerShell_ise.exe einschränkt und die Carbon Black Group Policy den Sprachmodus einschränken kann, ist die Nutzung von PowerShell insgesamt eingeschränkt.
Daher haben unsere Pentester im vierten Schritt einen individuell konfigurierten Runspace erstellt, um diese Einschränkungen zu umgehen. Dazu wurde folgende selbst entwickelte Anwendung verwendet: CustomRunspace.
Custom C# PowerShell Runspace ermöglicht auf dem gehärteten System das Umgehen des Constrained Language Modes (CLM) in PowerShell.
In diesem Szenario wurde, ähnlich wie im ersten Szenario, mit Hilfe des in C# geschriebenen Custom Runspaces eine JS-Datei generiert und ausgeführt. Diese prüft unter anderem, dass CLM außer Kraft gesetzt wurde und der Full Language Mode zur Verfügung steht.
Fazit
Lösungen, welche die Ausführung von potentiell gefährlichen Programmen verhindern sollen, sind eine sinnvolle Schutzmaßnahme. Doch Application-Control-Tools stellen kein Allheilmittel dar! Sie sind wie jede Security-Komponente anfällig für potentielle Konfigurationsfehler.
Wir empfehlen deshalb die Umsetzung von Blocking-Regeln, die aus einer Kombination von zugelassenen, signierten Binärdateien und Dateipfaden bestehen. So lassen sich effektiv die Risiken aus möglichen Umgehungsmethoden von Angreifern minimieren.
Nun steht die große Frage im Raum: Wie können Konfigurationsfehler bzw. Konfigurationsschwächen in der Application-Control-Umgebung frühzeitig gefunden werden? Die Antwort ist einfach: Mit einem Penetration Test!
Ein Pentest deckt Schwachstellen in der Konfiguration auf, um diese proaktiv und zeitnah beheben zu können. Unser Team steht Ihnen hierbei natürlich gerne zur Seite.
Oder nutzen Sie unseren Pentest-Konfigurator, um sich umgehend ein Angebot erstellen zu lassen.
Was ist zu tun, wenn Application-Control-Mechanismen trotzdem umgangen werden?
Trotz aller Vorsicht bei der Konfiguration effektiver Application-Control-Regeln kann die Kompromittierung eines Systems nicht gänzlich ausgeschlossen werden. Daher ist eine effektive und zeitnahe Detektion eines Angriffs bzw. der Versuch eines Angriffs von entscheidender Bedeutung, um das Schadenspotential möglichst gering zu halten.
Angriffe und Angriffsversuche lassen sich mit einem System wie Trovent MDR (Managed Detection & Response) erkennen. Unser System zur Angriffserkennung können Sie gerne unter realen Bedingungen testen.
Bilder: Pixabay / Screenshots