[English]In Windows existiert eine ungepatchte Zero-Day-Schwachstelle (zero-day local privilege escalation vulnerability), über die unprivilegierte Benutzer Rechte bis auf SYSTEM-Ebene ausweiten können. Hier einige Informationen zum Sachverhalt. Ergänzung: Die Schwachstelle kann per Workaround entschärft werden. Zudem gibt es einen ersten 0patch-Testkandidaten für die Geschichte.
Anzeige
Erste Infos per Twitter
Die ersten Meldungen erreichten mich die Nacht über Twitter (siehe hier), wobei der Twitter-Kanal der Person @sandboxescapter, die das ursprünglich gepostet hat, inzwischen gelöscht wurde. Der usprüngliche Tweet lautete folgendermaßen:
Here is the alpc bug as 0day: https://t.co/m1T3wDSvPX I don't fucking care about life anymore. Neither do I ever again want to submit to MSFT anyway. Fuck all of this shit.
— SandboxEscaper (@SandboxEscaper) August 27, 2018
Kevin Beaumont (@GossiTheDog) hat aber die Information in diesem Tweet zusammen gefasst:
The account got pulled, but the PoC is at https://t.co/JqX4ueHorZ
— Kevin Beaumont (@GossiTheDog) 28. August 2018
und auf die GitHub-Quelle verlinkt, wo das Proof of Concept (PoC) zu finden ist. CERT/CC-Schwachstellenanalytiker Will Dormann verifizierte den Fehler. In einem Tweet bestätigte er die Schwachstelle.
Anzeige
I've confirmed that this works well in a fully-patched 64-bit Windows 10 system.
LPE right to SYSTEM! https://t.co/My1IevbWbz— Will Dormann (@wdormann) 27. August 2018
Will Dormann bestätigt, dass der Exploit auf einem vollständig gepatchten 64-Bit-Windows 10-System gut funktioniert. Es ist eine Local Privilege Escalation-Schwachstelle, die Rechteausweitung bis zu SYSTEM ermöglicht. Dormann hat dann eine CERT-Warnung (VU#906424 Microsoft Windows task scheduler contains a local privilege escalation vulnerability in the ALPC interface) veröffentlicht.
Schwachstelle im Task-Scheduler
Die Zero-Day-Schwachstelle steckt im Task-Scheduler von Windows im ALPC-Interface. Das Kürzel ALPC steht für Advanced Local Procedure Call. Der Windows Task-Scheduler (Aufgabenplanung) enthält eine Schwachstelle in der Handhabung von ALPC-Aufrufen, die es einem lokalen Benutzer ermöglicht, SYSTEM-Privilegien zu erlangen.
Begrenzte Ausnutzbarkeit?
Ergänzung: Die Schwachstelle erfordert jedoch, dass das Konto die Berechtigungen besitzt, einen Hardlink zu erstellen (was m. M. nur mit Administratorkonten geht). Zitat aus der Beschreibung des PoC.
Tasks created by the task scheduler will create a corresponding folder/file in c:\windows\system32\tasks. This function seems to be designed to write the DACL of tasks located there, and will do so while impersonating. However, for some reason it will also check if a .job file exists under c:\windows\tasks and try to set the DACL while not impersonating. Since a user, and even a user belonging to the guests group can create files in this folder, we can simply create a hardlink to another file (all we need is read access). Because of the hardlink, we can let the task scheduler write an arbitrary DACL (see second parameter of SchRpcSetSecurity) to a file of our choosing.
So any file that we have read access over as a user and that system has the write DACL permission for, we can pivot into full control and overwrite it.
Selbst der lesende Zugriff auf den Ordner c:\windows\system32\tasks ist für Standardnutzer nicht möglich (gerade nochmals explizit getestet). Da aber manche Nutzer unter Administratorkonten arbeiten, sollten sich die Hardlinks anlegen lassen. Ergänzung: Auch unter Standard-Benutzerkonten lassen sich Hardlinks anlegen. Dann ließen sich SYSTEM-Rechte erlangen. Bei einem Standardkonto mit begrenzten Rechten klappt das (wegen der fehlenden Rechte zum Erstellen von Hardlinks oder zum Zugriff auf den tasks-Ordner, zumindest bei meinen Versuchen per Eingabeaufforderung) nicht.
Der Autor des PoC schreibt denn auch, dass der Charme des Exploits darin liege, dass man nun eine Menge Dateien manipulieren könne, auf die normalerweise nur der Trusted Installer Zugriff hat. Das ist bei solchen Daten unter Administratorkonten möglich, indem man die Dateien als Besitzer übernimmt.
Ergänzung: Es scheint einen Workaround zu geben
Auf administrator.de gibt es eine Diskussion zum Thema, nachdem ich dort den Hinweis eingestellt habe. Dort hat jemand das, woran ich gescheitert bin, auf einem System (auf dem zweiten nicht) hin bekommen, er konnte auf einem System unter einem Standardkonto Notepad Systemrechte zuweisen. Irgend etwas habe ich übersehen. Interessant finde ich den dort beschriebenen Workaround:
c:\windows\system32\tasks
die Schreibrechte zu entziehen. Damit kann man wohl erreichen, dass der PoC-Exploit nicht mehr funktioniert. Ist für Administratoren in Unternehmensumgebungen ggf. von Interesse. Sofern ihr dort aktiv werdet, behaltet diesen Thread bei administrator.de im Auge. Dort hat der betreffende Administrator seinen Workaround zur Diskussion gestellt.
Ergänzung 1: 0patch wohl im Anflug
Über die Leute von 0patch hatte ich ja schon mehrere Blog-Beiträge (hier, hier, hier). Die Leute entwickeln Mikropatches, die Schwachstellen schließen, die von den Softwareanbietern (noch) nicht geschlossen worden sind. Dazu muss ein spezieller Patch-Agent installiert werden, der dann die Mikropatches beim Start der Anwendung lädt.
Okay people, 24 hours after the 0day was published we have a micropatch candidate for @SandboxEscaper's LPE in Task Scheduler. As you can see, scheduler's access to user-controlled hardlink is impersonating the user and gets ACCESS DENIED. pic.twitter.com/3kHcXdY42H
— 0patch (@0patch) 28. August 2018
Team von 0patch hat in obigem Tweet bekannt gegeben, dass man bereits mit einem Mikropatch-Kandidaten operiert. Falls es also besonders brennt, könnte man bei denen anfragen (ich selbst habe aber bisher nicht mit deren Mikropatches und dem Agenten gearbeitet).
Schwachstelle sowieso nur lokal ausnutzbar
Glück im Unglück: Dadurch lässt sich die bisher ungepatchte Schwachstelle nur lokal, nicht aber Remote per Internet, ausnutzen. Und Standardnutzer (z.B. in Unternehmensumgebungen) sind nach meinem bisherigen Kenntnisstand eher nicht gefährdet. Allerdings öffnet dies einen vertrauten Angriffsvektor: Wenn ein Angreifer einen Benutzer (mit entsprechenden Rechten) dazu verleiten kann, ein Schadprogramm aus dem Internet herunterzuladen und auszuführen, kann dieses die Lücke zur Ausweitung der Rechte (aus dem lokalen Benutzerkontext eines Admin-Kontos) auf Systemprivilegien verwenden.
The Register hat bei Microsoft angefragt. Ein Microsoft-Sprecher antwortete, "dass man so schnell als möglich reagieren wolle", und verwies auf den Zeitplan für das Update am Dienstag. Mal schauen, ob heute – bzw. am 11. September 2018 – ein Patch kommt. Ergänzung: Inzwischen sind mehrere Artikel hier, hier und hier erschienen. Auch heise.de hat inzwischen diese Meldung gebracht.
Hier geht es weiter: Neues zur Windows ALPC Zero-Day-Schwachstelle
Anzeige
Danke Günther… dein Artikel gefällt mir übrigens besser als der von Heise.
Wenn man sich ein wenig nach dem Autor umschaut findet man auf Reddit gelöschte Beiträge von vor einem Monat, wo er/sie versucht hat vermutlich diesen 0-Day zu verkaufen: https://www.reddit.com/user/SandboxEscaper
Danke für den Link – mir fehlt z.Z. schlicht die Zeit 'mich ein bisschen im Internet umzuschauen' – erst den Morgen mit Ergänzungen des Microcode-Update-Fehlers sowie Physiotherapie verbracht – dann das obige Thema halbwegs verständlich mit den Infos, die ich (vor allem über meine Twitter Kanäle) hatte, zusammen gekramt. Und nun muss ich mich des Themas Chaos bei den MS Microcode-Updates widmen – ist mir heute Vormittag von zwei Blog-Lesern zugetragen worden.
Nicht die feine Art, aber bei den ganzen Anhäufungen von Sicherheitslücken, teilweise wieder uralte Lücken wieder auftauchen, und die teilweise sehr ignorante Reaktion Microsofts auch ein wenig verständlich, dass einem mal richtig der Kragen platzt.
Gut, daraus hinten rum ein Geschäft machen zu wollen ist natürlich zu verurteilen.
Bug Bounties sind bei allen größeren Firmen inzwischen selbstverständlich.
Ist schon korrekt. Man kann nur spekulieren – möglicherweise ist der Gute nicht ganz sauber und kann da nicht punkten.
Zudem bekomme ich am Rande mit, dass die Firmen da Leute mit den Prämien auch schon mal 'hängen lassen' und das Zahlen vergessen. Leider – die Welt ist schlecht.
"Chinese whisper" funktioniert ganz offensichtlich: nachdem "The Register" den guten Will Dormann (den sie schon 'mal als "CERT furniture" bezeichnet haben) "Phil Dormann" genannt haben sind alle Abschreiber schnell zu identifizieren!
"Ergänzung: Die Schwachstelle erfordert jedoch, dass das Konto die Berechtigungen besitzt, einen Hardlink zu erstellen (was m. M. nur mit Administratorkonten geht)"
AUTSCH!
Hardlinks kann (seit NT4) JEDER (unprivilegierte) Benutzer erstellen!
"Selbst der lesende Zugriff auf den Ordner c:\windows\system32\tasks ist für Standardnutzer nicht möglich (gerade nochmals explizit getestet)."
AUTSCH!
Wie getestet, womit getestet?
"Auflisten" eines Ordners/Verzeichnisses und "Lesen" von Dateien innerhalb dieses Ordners sind ZWEI PAAR Schuhe.
Demonstration: starte in einer (frischen) Standard-Installation die Eingabeaufforderung und führe folgende Kommandos aus
DIR "%SystemRoot%\Temp"
COPY "%COMSPEC%" "%SystemRoot%\Temp"
DIR "%SystemRoot%\Temp\cmd.exe"
"%SystemRoot%\Temp\cmd.exe"
ERASE "%SystemRoot%\Temp\cmd.exe"
Wehret den Anfängern!
Ich schrieb 'Selbst der lesende Zugriff auf den Ordner c:\windows\system32\tasks ist für Standardnutzer nicht möglich'. Ich hatte es im Explorer getestet, aber auch die Eingabeaufforderung liefert mir das. Probiere es aus – cmd als Standardnutzer öffnen und:
cd c:\windows\system32\tasks
dir c:\windows\system32\tasks
versuchen. Beides wird hier (wie erwartet) abgewiesen.
Und zum Hardlink – in der Eingabeaufforderung eines Standardkontos mit mklink /H getestet – ich erhalte 'Zugriff verweigert' – auch das hatte ich erwartet.
Ich habe auch die Schritte, die der PoC-Author im Video demonstriert, ausprobiert. Möglicherweise ist mir ein Fehler unterlaufen – aber hier bekommt der angegebene Prozess keinen Integrity-Level SYSTEm.
ARRRRGGGHH!
1. es geht NICHT um den Zugriff auf das Verzeichnis, sondern um den Zugriff auf darin liegende Dateien!
Sobald Du meine %TEMP% verwendende Demonstration verstanden hast geht's weiter.
2. Du verwendest [CMD.exe /K] mklink /H falsch UND misinterpretierst dann dessen Fehlermeldung!
Erstelle eine neue Datei auf Deinem Desktop und von dieser einen Hardlink.
"Wer misst misst Mist!"
Stefan, beruhige Dich. Man könnte meinen, du littest unter Tourette.
Was Günter festgestellt hat, ist doch bloß, dass kein Lesezugriff auf c:\windows\system32\tasks besteht, und das stimmt. Nutzer haben dort jedoch Schreibzugriff und das wird hier ausgenutzt.
mklink geht auch, jedoch nicht auf beliebige Dateien – aber was soll's, das Injecting funktioniert vermutlich gar nicht unter Verwendung des Selbigen. Es funktioniert jedenfalls als normaler Nutzer.
Kein Grund zur Aufregung (auch wenn ich durchaus "wehret den Anfängen" ebenso manchmal vor mich hindenke).
"Was Günter festgestellt hat, ist doch bloß, dass kein Lesezugriff auf c:\windows\system32\tasks besteht, und das stimmt."
1. Dummerweise ist das VÖLLIG unerheblich für die Funktion des Angriffs.
2. Zeigt er damit, dass er die Demonstration aus dem vorherigen Kommentar noch immer nicht nachvollzogen hat.
Ich gebe jedem die einmalige Chance, seine eigenen Fehler zu erkennen!
Wow, wie großzügig von dir. Ich finde, du benimmst dich schlicht und ergreifend daneben.
"Der Autor des PoC schreibt denn auch, dass der Charme des Exploits darin liege, dass man nun eine Menge Dateien manipulieren könne, auf die normalerweise nur der Trusted Installer Zugriff hat. Das ist in der Tat auch unter Administratorkonten nur möglich, wenn man die Dateien als Besitzer übernimmt."
AUTSCH!
Jeder Administrator (oder "Backup Operator") kann die Privilegien "Backup" und "Restore" aktivieren und dann ALLE Dateien lesen und (über)schreiben!
Jeder Administrator kann das aber auch an das SetupAPI delegieren.
WEHRET DEN ANFÄNGERN!
@Stefan Kanthak: Habe mir gerade erlaubt auf deinen Namen hier zu klicken und musste dann sofort feststellen, dass mein AV-Programm anschlug. Virus:DOS/EICAR_Test_File
https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?name=Virus%3aDOS%2fEICAR_Test_File&threatid=2147519003
Wirklich eine ganz lustige Nummer von dir.
Achtung, hier spricht Captain Niveau, wir sinken!
@Guido: Nur zur Information: Die Hintergründe für dieses Verhalten hatte ich im Kommentar hier skizziert.
Unter Dein Niveau kann niemand sinken.
Wehret den Merkbefreiten!
"Wehret den Merkbefreiten!"
Scheint ja dein Lieblingszitat zu sein …
Mein Niveau ist nicht messbar auch nicht mit einem deinen unfreiwilligen Penetrationstests!
@Stefan Kanthak: Du magst gerne über mich ranten – als Blogger muss ich das abkönnen. Man kann Fehler auch sachlich benennen, ohne die Blog-Leser herabzusetzen.
Aber das geht langsam zu weit – bitte mäßig dich mit den Attributen, die Du gerne vergibst.
Andernfalls müsste und werde ich einen Spamfilter aufsetzen, der deine Kommentare künftig blockt. Sorry, da muss ich jetzt einen Pflock einschlagen.
+1
Hallo Günter
Ich begrüße diese deine Reaktion, sie war leider nötig. Habe mich schon gewundert, dass dieser Mensch mit seinem unrühmlichen Verhalten auf deinem Blog durchkommt.
Der Ton macht die Musik :-)
Vielen Dank Herr Born. Ich schätze Ihren Blog sehr und schaue täglich gerne mit deaktiviertem Adblocker vorbei. Die Grenze die Sie S.K. aufzeigen halte ich für notwendig, sinnvoll und sie ist auch in meinem Sinne. Dankeschön!
Tätowier dir den letzten Satz ganz groß auf die Stirn – und schau halbstündlich im Spiegel nach.
vlt hilfts, wenigstens etwas…
ps:
tausche den gegen dem,
det janze in Spiegelschrift.
;-)
Das Thema ist durch – auch hier 'kein nachtreten' – danke!