Konkrete Kritik an CVSS4
Marc Ruef
Das grundlegende Prinzip von Multiuser-Plattformen, wie sie im Windows-Umfeld beispielsweise mit Citrix eingeführt werden, liegt in der Einschränkung der jeweiligen Benutzer. Gerade bei Windows ist das besonders schwierig, weil die Multiser-Fähigkeit nicht Teil des grundlegenden Konzepts war.
So ist es mit gewissen Aufwänden oftmals möglich, dass neben den Published Applications ebenfalls weitere Prozesse gestartet und damit erweiterte Rechte erlangt werden können. Dies haben wir ausführlich im Fachartikel Citrix under Attack dokumentiert:
Administratoren entsprechender Systeme sind sich aber nur selten den Risiken bewusst, die eine derartig umfassende Multiuser-Umgebung mit sich bringt. Durch einfache Tricks können legitime Citrix-Nutzer ihre Rechte erweitern und im schlimmsten Fall mit wenigen Mausklicks die Kontrolle des Hosts erlangen.
Das gezielte Einschränken von jeglicher ausführbaren Dateien lässt sich mit Group Policies vornehmen. Mit secpol.msc
können entsprechende Einstellungen unter Software Restriction Policies vorgenommen werden. Der Benutzer erhält sodann eine Fehlermeldung, will er eine Datei ausführen, die für ihn als nicht ausführbar gekennzeichnet wurde:
Wie so oft bei solchen Whitelist/Blacklist-Ansätzen arbeitet die Komplexität gegen die Sicherheit. Dies bedeutet, dass eine Vielzahl an Fehlern passieren können. Standardmässig ist bei aktivierter Policy eine Blacklist realisiert. Ohne dedizierte Blacklist-Einträge werden also noch keine Applikationen gehindert.
Generell muss definiert werden, für welche Dateitypen die Analyse und Einschränkung stattzufinden hat. Standardmässig werden ausführbare Dateien berücksichtigt, Libraries (z.B. DLLs) hingegen nicht. In einer separaten Liste werden alle Extensions zu den vermeintlich ausführbaren Dateien festgehalten. Dabei fällt auf, dass zwar Access-Datenbanken berücksichtigt werden (wahrscheinlich wegen VBA-Code). Word und Excel-Dokumente, die jedoch weitestgehend die gleiche Funktionalität bezüglich eingebettetem Code bieten, hingegen nicht:
Das Umstellen auf einen Whitelist-Ansatz ist mit einem Klick in den Main Settings
möglich. Microsoft hat versucht ein Ausschliessen des Administrators zu verhindern, indem unter Additional Rules
die zentralen Verzeichnisse des Betriebssystems pauschal zugelassen werden:
Sollte ein Angreifer Schreibrechte für diese Verzeichnisse haben, kann er seinen korrupten Programmcode dahin kopieren und erneut ausführen. Zudem finden sich in den genannten Verzeichnissen viele Systemutilities, die das Auswerten und Angreifen des Systems ermöglichen können (z.B. ping.exe
, telnet.exe
, arp.exe
).
Typ | Identifikation | Sicherheit |
---|---|---|
Path Rule | Pfad-/Dateiangabe | Mittel |
Hash Rule | MD5-/SHA1-Hash, Dateigrösse | Hoch |
Certificate Rule | Code-Signing Zertifikat | Hoch |
Internet Zone Rule | Internet Explorer Zone | Mittel |
Administratoren pflegen vorwiegend derlei Path-Rules durchzusetzen. Durch Wildcards können sodann ganze Verzeichnisse, Verzeichnisstrukturen und Dateien freigegeben werden. Dort treten immerwieder typische Fehler auf, wie zum Beispiel die Freigabe von C:\*\SAP\*.exe
. Mit dieser Definition ist sowohl C:\SAP\sapgui\saplogon.exe
als auch C:\tmp\SAP\exploit.exe
ausführbar.
Um zu verhindern, dass sich Dateien in einen anderen Pfad kopieren und damit ausführen lassen, lohnt sich das Anwenden sogenannter Hash Rules. Dabei wird nicht nur der Pfad- und Dateiname in die Whitelist übertragen, sondern ebenfalls MD5- oder SHA1-Hash sowie Dateigrösse abgelegt. Ein Angreifer müsste nun schon eine Kollision im genutzten Hash-Algorithmus nutzen, um die Attacke erfolgreich durchzusetzen. Ein vergleichbarer und nicht minder interessanter Angriff mittels Binary-Patching auf eine gesperrte cmd.exe
kann in diesem Video angeschaut werden.
Unsere Spezialisten kontaktieren Sie gern!
Marc Ruef
Marc Ruef
Marc Ruef
Marc Ruef
Unsere Spezialisten kontaktieren Sie gern!