Software Restriction: How to Make and how to Break

Software Restriction

How to Make and how to Break

Marc Ruef
by Marc Ruef
time to read: 7 minutes

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.

About the Author

Marc Ruef

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

Are you interested in a Penetration Test?

Our experts will get in contact with you!

×
Specific Criticism of CVSS4

Specific Criticism of CVSS4

Marc Ruef

scip Cybersecurity Forecast

scip Cybersecurity Forecast

Marc Ruef

Voice Authentication

Voice Authentication

Marc Ruef

Bug Bounty

Bug Bounty

Marc Ruef

You want more?

Further articles available here

You need support in such a project?

Our experts will get in contact with you!

You want more?

Further articles available here