Neue Windows ALPC Zero-Day-Schwachstelle entdeckt

[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:

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.

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?


Anzeige

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.

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


Dieser Beitrag wurde unter Sicherheit, Windows abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

25 Antworten zu Neue Windows ALPC Zero-Day-Schwachstelle entdeckt


  1. Anzeige
  2. Swedish Chef sagt:

    Danke Günther… dein Artikel gefällt mir übrigens besser als der von Heise.

  3. Anon sagt:

    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

    • Günter Born sagt:

      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.

  4. Anzeige

  5. Al CiD sagt:

    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.

    • Andreas Schamanek sagt:

      Bug Bounties sind bei allen größeren Firmen inzwischen selbstverständlich.

      • Günter Born sagt:

        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.

  6. “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!

  7. “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!

    • Günter Born sagt:

      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!”

        • Bernhard Diener sagt:

          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!

          • riedenthied sagt:

            Wow, wie großzügig von dir. Ich finde, du benimmst dich schlicht und ergreifend daneben.

  8. “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!

  9. Anzeige

  10. Guido sagt:

    @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!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.