Software Restriction: How to Make and how to Break

Software Restriction

How to Make and how to Break

Marc Ruef
von Marc Ruef
Lesezeit: 7 Minuten

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:

Software Restriction Warnmeldung

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:

Software Restriction Default File Types

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:

Software Restriction Default Rules

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.

Software Restriction Hash Rule Beispiel

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.

Über den Autor

Marc Ruef

Marc Ruef ist seit Ende der 1990er Jahre im Cybersecurity-Bereich aktiv. Er hat vor allem im deutschsprachigen Raum aufgrund der Vielzahl durch ihn veröffentlichten Fachpublikationen und Bücher – dazu gehört besonders Die Kunst des Penetration Testing – Bekanntheit erlangt. Er ist Dozent an verschiedenen Fakultäten, darunter ETH, HWZ, HSLU und IKF. (ORCID 0000-0002-1328-6357)

Links

Haben Sie Interesse an einem Penetration Test?

Unsere Spezialisten kontaktieren Sie gern!

×
Konkrete Kritik an CVSS4

Konkrete Kritik an CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentisierung

Voice Authentisierung

Marc Ruef

Bug-Bounty

Bug-Bounty

Marc Ruef

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv