Dieser Artikel zeigt auf wie eine von Oneconsult entdeckte Design-Schwachstelle im Microsoft UAC-Mechanismus missbraucht werden kann, damit beliebige Skripte und Programme eine vermeintlich echte Microsoft Signatur vorgaukeln.
Einleitung
Wenn unter Windows eine Software ausgeführt wird, welche höhere Rechte benötigt als der ausführende Benutzer hat, so kommt die User Account Control (UAC) zum Einsatz.
Bei der Anfrage nach höheren Rechten wird die Signatur des Portable Executable (PE) File geprüft, welches die höheren Rechte anfordert. Falls die Software zertifiziert wurde und die Signatur korrekt ist, wird als «Verified publisher» der Name des Herstellers angezeigt, um hierdurch dem Benutzer mitzuteilen, dass es sich um vertrauenswürdigen Code handelt.
Wird hier ein bekannter Name angezeigt, so führt dies dazu, dass der Benutzer vermutlich dem Programm vertraut und daher die Ausführung mit Administrator-Rechten gestattet. Das höchste Level an Vertrauen geniesst hier wohl Microsoft selbst. In diesem Artikel wird gezeigt, wie eigene (Schad-)Software mit administrativen Rechten ausgeführt werden kann, ohne dass dabei die «Verified publisher»-Anzeige geändert wird um damit den Benutzer dazu zu bringen, die administrativen Rechte zu erteilen.
Ausgangslage
Im Grunde ist das Problem simpel. Ein PE-File für eine Installation ist in vielen Fällen ein sogenannter Unpacker, der die eigentlichen Installationsdateien in einen temporären Ordner entpackt. Im hier betrachteten Beispiel werden vier Dateien entpackt:
Nach dem Entpacken wird durch den Unpacker automatisch «Setup.exe» aufgerufen. Der Entpacker benötigt keine administrativen Rechte, die «Setup.exe»-Datei jedoch schon. Daher wird bei «Setup.exe» über die UAC nach erhöhten Rechten gefragt. Aufgrund der korrekten Signatur ist davon auszugehen, dass der Benutzer diese dem Programm auch erteilen wird. Bei «Setup.exe» handelt es sich jedoch um einen generischen Installer, der seine Tasks, bzw. was zu installieren ist, aus der Datei «setup.xml» liest. Aufgrund des «setup.xml» werden gewisse Checks durchgeführt und danach der MSP Patch Installer dem Microsoft Installer Framework übergeben.
Da die UAC die Signatur der «Setup.exe»-Datei überprüft, kann dieses nicht erfolgreich durch einen Angreifer manipuliert werden. Und auch der MSP Patch Installer enthält weitere Signaturen.
Analysiert man «Setup.exe», so stellt man fest, dass die «setup.xml»-Datei ohne Prüfung einer Signatur eingelesen wird. Dies bedeutet, dass ein Angreifer «setup.xml» beliebig manipulieren kann. Das durch Microsoft signierte «Setup.exe» vertraut demnach einem nicht signierten File, nimmt Befehle von diesem entgegen und führt sie aus.
Anatomie des Angriffs
«setup.xml» muss so angepasst werden, dass es die Befehle des Angreifers ausführt. Der naheliegende Ansatz, «Setup.exe» eine andere Datei installieren zu lassen, ist aufgrund der Signaturprüfung komplizierter als der hier vorgestellte Angriff, sollte jedoch nicht ausgeschlossen werden. Der hier beschriebene Ansatz wurde bei der Analyse der Optionen der XML-Datei gefunden.
Geht man die relevanten Strings von «Setup.exe» durch, fällt der Unicode-String „CustomAction“ auf. Der Debugger zeigt den relevanten Teil des XPaths (eindeutiger Pfad zu einem Knoten). Das heisst in der XML-Datei gibt es die Möglichkeit unter „PatchBefore“ sogenannte „CustomActions“ zu definieren. Allenfalls gibt es hierfür eine Dokumentation online (diese wurde von den Autoren jedoch nicht gefunden). Die weitere statische Analyse zeigt, dass die Funktion „Installer::ExecuteCustomActions“ die Typen „Exe“, „Dll“, „Regedit“, „Script“ und „Regentry“ als Typ erlaubt.
Da diese Typen alle zur Code-Ausführung benutzt werden können, sind sie für diesen Angriff geeignet. Für die weiteren Schritte wurde „Script“ als Beispiel gewählt. Die Analyse zeigt, dass allfällige Skripte mittels „CScript.exe“ aufgerufen werden. Das Ausführen im „PatchBefore“ hat aus Angreifersicht den Vorteil, dass der eigentliche Patch nicht funktionieren muss und der Schadcode trotzdem ausgeführt wird. Der Angreifer fügt daher der «setup.xml» folgenden Node unter PatchBefore hinzu:
<CustomAction Type="Script" IgnoreError="yes" File="C:\Users\Public\Roaming\run.vbs" Arguments="">Weiter sollte der Product-Code, der eindeutige Code für jede Software, welche mittels dem MSI installiert wird, in der XML-Datei noch auf einen möglichst allgemein bekannten gesetzt werden. Beispielsweise kann der eines Microsoft-Produkts oder des Lenovo Solution Centers verwendet werden. Hierdurch gelangt das Update auf möglichst vielen Systemen zur Installation. Eine so erstellte Datei fragt korrekt signiert nach administrativen Rechten und führt das mit eingepackte Skript mit diesen Rechten aus. Dieses Skript kann dann z.B. als Teil einer APT-Attacke Malware herunterladen und sich im System einnisten.
Konsequenzen
Grundsätzlich ist dies vermutlich mit diversen anderen signierten Installationsdateien oder auch anderen Arten von PEs möglich. Hier wurde ein Installer von Microsoft verwendet um ein möglichst hohes Vertrauen beim Opfer zu erlangen und den generellen Ansatz zu erläutern. Dieser Trick erlaubt das Erstellen eines Installers, welcher eine beliebige Software installiert, dabei dem Anwender jedoch eine vermeintlich korrekte Microsoft-Signatur anzeigt. Hierdurch wird das Vertrauen des Benutzers in die Windows-Signatur missbraucht, um administrative Rechte zu erschleichen.
Eine andere Methode um administrative Rechte zu erhalten ist das Ausnutzen von oft noch unbekannten Schwachstellen (sogenannnte «Privilege Escalation Exploits»). Diese hat jedoch den Nachteil, dass solche Exploits einerseits aufwändig bzw. teuer sind und andererseits einfach durch ein Update neutralisiert werden können. Die hier vorgestellte Technik benötigt zwar eine Interaktion mit dem Benutzer, aber der Missbrauch der UAC kann nicht ohne grosse Umstellung bei der Signierung von ausführbaren Dateien behoben werden. Denn um dieses Problem zu lösen, müssten alle signierten Executables insofern geändert werden, dass diese keine unsignierten Skripte oder Programme mehr ausführen und nur korrekt signierte Konfigurationsdateien lesen. Wenn jedoch selbst Microsoft dies nicht tut, ist kaum zu erwarten, dass die signierten Programme anderer Hersteller diesbezüglich sicherer sind.
Microsoft wurde selbstverständlich frühzeitig von Oneconsult über diese Schwachstelle informiert. Gemäss Aussage von Microsoft vertraue der Benutzer durch das Ausführen des Programmes jedoch diesem und daher sehe Microsoft keinen unmittelbaren Handlungsbedarf und ziehe einen Vergleich zu DLL Hijacking, das ähnlich eingesetzt werden könne. Auch habe Microsoft in der Vergangenheit bereits festgehalten, dass UAC keine Sicherheitsgrenze darstelle.
Konkret bedeutet dies, dass ein Benutzer keine Möglichkeit hat, zu erkennen, welche Programme tatsächlich durch eine signierte Software ausgeführt werden. Da stellt sich unweigerlich die Frage, wozu die Signatur im UAC-Fall überhaupt dient – ausser (unbegründete) Vertrauenswürdigkeit zu suggerieren?
Jan Alsenz ist Chief Research Officer und Rafael Scheel ist Senior Penetration Tester, IT-Forensiker & Security Researcher bei der Oneconsult AG.
Über Oneconsult
Die Oneconsult AG ist ein Schweizer Cybersecurity Consulting Unternehmen mit rund 25 Mitarbeitern, Büros in der Schweiz und Deutschland und einem Kundenstamm von 300+ Organisationen und 1200+ weltweit durchgeführten Projekten. Wir sind Ihr vertrauenswürdiger Partner für einen umfassenden Cybersecurity Ansatz gegen externe und interne Cyber-Bedrohungen wie APT, Hacker-Angriffe, Malware-Befall, digitalen Betrug und Datenverlust. Die Kerndienstleistungen von Oneconsult sind Penetration Tests, ISO 27001 Security Audits und IT-Forensik / Incident Response. Zum Schutz Ihrer Organisation und um spezifische Informationssicherheitsrisiken anzugehen, sind auch praxisorientiertes Security Consulting, Security Training und Virtual Security Officer Services Teil des Portfolios. Eigene IT Security Researcher, IT-Forensik-Experten (GCFE, GREM), ISO Security Auditoren (ISO 27001 Lead Auditor) und ein grosses Team an zertifizierten Penetration Testern (OPST, OSCP etc.) stehen Ihnen kompetent zur Verfügung.
