[English]In faktisch allen Windows-Versionen steckt eine (interessante, aber wohl nicht so) gravierende Sicherheitslücke, die eine Rechteübertragungausweitung von Administrator-Privilegien an (Gast-)Konten ermöglicht. Das RID Hijacking genannte Verfahren ist seit mindestens 10 Monaten bekannt, ohne dass es groß bemerkt wurde.
Anzeige
Erste Informationen zur Schwachstelle
Ich bin bereits gestern bei Twitter auf das Thema gestoßen, Catalin Cimpanu (@campuscodi) hat es bei ZDNet.com aufbereitet und spricht von einer Hintertür.
Researcher finds simple way of backdooring Windows PCs and nobody notices for ten months.
"RID Hijacking" technique lets hackers assign admin rights to guest and other low-level accounts.https://t.co/UcteuyxKHc pic.twitter.com/b8bzWzlb2y
— Catalin Cimpanu (@campuscodi) 18. Oktober 2018
Blog-Leser Ralf hat mich per verstecktem Kommentar (danke dafür) hier im Blog noch auf den deutschsprachigen Artikel von Golem hingewiesen (Artikel wurde bei Golem gelöscht, siehe Kommentar). Ein weiterer Beitrag findet sich auf Fossbyte.
Die Entdeckung der RID Hijacking-Angriffsmethode
Die RID Hijacking-Angriffsmethode wurde von Sebastian Castro aus Kolumbien auf csl.com beschrieben. Es gibt von Castro aber einen älteren Blog-Beitrag vom 28. Dezember 2017, wo er bereits das Verfahren beschreibt. Der Angriffsweg ist also seit 10 Monaten bekannt. Der Hack von Castro wird in diesem Video (Aufzeichnung eines Vortrags von Castro) demonstriert.
Golem schreibt, dass sich der Sicherheitsforscher nach eigenen Angaben umgehend an Microsoft gewandt habe, als er die Lücke entdeckte. Auf seinen Hinweis habe er keinerlei Rückmeldung erhalten. Bisher ist aber kein Fall bekannt, wo diese Sicherheitslücke von Schadsoftware ausgenutzt wurde. Ergänzung: Der Grund ist auch klar, das Verfahren braucht Administratorrechte (siehe auch folgende Ausführungen).
Anzeige
Der RID Hijacking-Angriff im Detail
Mit den Windows-Ressourcen ist es möglich, die RID (relative identifier, siehe hier) eines bestehenden Kontos (sogar des 500 Administrator Built-in Accounts) zu übernehmen und einem anderen Benutzerkonto zuzuweisen. Dieser Angriff erlaubt:
- dem gekaperten (entführten) Benutzerkonto die Berechtigungen eines anderen Kontos zuzuweisen, auch wenn dieses Konto deaktiviert ist (damit kann man Admin-Rechte zuweisen).
- die Authentifizierung mit den Zugangsdaten des Hijacker-Kontos (auch Remote, abhängig von der Konfiguration des Computers), man erhält autorisierten Zugriff auf alles, was für das gekaperte Benutzerkonto zulässig ist.
- jede im Ereignisprotokoll eingetragene Aktion unter dem Namen des entführten Benutzerkontos protokollieren lassen, obwohl diese Aktion vom 'Entführer-Konto' erfolgt, unter dem der Ausführende angemeldet ist.
Sebastian Castro schrieb bereits im Dezember 2017, dass diese Technik trotz ihrer atemberaubenden Wirksamkeit seines Wissens nicht ausreichend dokumentiert sei. Also entschied er sich, ein Metasploit-Modul, rid_hijack, zu schreiben, das diesen Angriff mit einer beliebigen Kombination von bestehenden Konten auf dem Opferrechner automatisiert. Diese Software hat er in der neuesten Metasploit-Version hier (gebrochen) bereitgestellt.
Dieses Modul richtet eine 'Meterpreter-Sitzung' für ein Windows-Opfer ein. Dann versucht es, die Berechtigungen zu überprüfen (und diese bei Bedarf abzurufen). Dann versucht es, die Registrierungsschlüssel, die dem angegebenen Konto zugeordnet sind, zu ändern (klappt nur mit ausreichenden Berechtigungen). Hier eine kurze Beschreibung der einzelnen Parameter des Metasploit-Moduls.
- GETSYSTEM: Wenn wahr, wird versucht, die SYSTEM-Privilegien für das Opfer zu erwerben. Wenn falsch, geht nix.
- GUEST_ACCOUNT: Wenn wahr, wird das Gastkonto des Opfers als Hijacker-Konto (Entführungskonto) verwendet.
- RID: Die RID, die dem Entführungskonto zugewiesen wird. Dieser Wert sollte einem bestehenden Konto gehören, das zur Entführung bestimmt ist. Standardmäßig auf 500 gesetzt.
- USERNAME: Wenn diese Option eingestellt ist, wird nach dem definierten Benutzerkonto gesucht und dieses wie das Entführungskonto behandelt. Wenn der Name auf GUEST_ACCOUNT lautet, wird dieser Parameter ignoriert.
- PASSWORD: Wenn diese Option eingestellt ist, wird das Passwort für das Hijacker-Konto auf diesen Wert festgelegt.
Dass jemand mit physischem Zugriff auf einen Computer das standardmäßig deaktivierte Konto Administrator mittels Windows PE hacken und so Zugang zu Administratorenrechten bekommt, ist lange bekannt. Ich hatte es 2013 im Blog-Beitrag Vom Windows-Administratorkonto ausgesperrt – I beschrieben. Mit obiger Methode ist aber viel mehr möglich: Man kann sich quasi die Benutzerberechtigung des deaktivierten Windows-Kontos Administrator im laufenden Betrieb aneignen und einem anderen Konto, wenn man als Administrator angemeldet ist, zuweisen. Dazu wird die RID des entführten Kontos genutzt. Dieser Hack bleibt auch bei einem Neustart von Windows weiter wirksam.
Da ich keinen Zugriff auf das Metasploit-Tool habe, war mir unklar, ob dieses administrative Rechte für die Manipulation benötigt. In nachfolgendem Screenshot lässt sich aber ablesen, dass für GETSYSTEM administrative Rechte gefordert werden (wohl zur Manipulation der Schlüssel). Zudem ist keine Remote-Ausnutzung möglich. Der Pfiff des Angriffs besteht darin, dass man ein Gast-Konto aufnorden, und dann quasi unter falscher 'Flagge' operieren kann. In der Ereignisanzeige wird dann der Name des gekaperten Kontos auftauchen. Bei Facebook gab es noch den Hinweis: 'Die Anmeldung eines Nutzers am Gast-Konto lässt sich per Baseline GPO verhindern', so dass man das Ganze entschärfen kann.
Test des Moduls
Sebastian Castro schreibt, dass dieser Angriff unter Windows XP, Windows Server 2003, Windows 8.1 und Windows 10 getestet wurde. Auf seiner Webseite beschreibt er, wie er eine virtuelle Windows 8.1 Pro-Maschine als Angriffsziel (Opfer) verwendet. Es gibt gemäß nachfolgendem Screenshot nur ein Benutzerkonto namens Benutzer und zwei integrierte Konten, das Administratorkonto (Administrator, in spanisch Administrador) und das Gastkonto (in spanisch Invitado), auf der Testmaschine.
Bildquelle: http://csl.com.co/rid-hijacking/
Sobald eine Meterpreter-Sitzung eingerichtet wurde, lässt sich das Modul ausführen. Dabei soll das eingebaute Administrator-Konto mit der RID 500 entführt und dem integrierten Gastkonto gewiesen werden. Das Gastkonto hat standardmäßig kein Passwort, also wird eines eingerichtet. Das geht aus folgendem Screenhot hervor:
Bildquelle: http://csl.com.co/rid-hijacking/ (Zum Vergrößern klicken)
In obigem Screenshot ist zu sehen, dass der Exploit bereits mit Systemrechten ausgeführt wird (was die Ausnutzbarkeit 'in the wild' natürlich begrenzt, aber die Übertragung der Rechte zwischen den Konten ist ja das Ziel). Nach dem Ausführen des Metasploits ist es möglich, sich mit dem Gastkonto und dem angegebenen Passwort an der Maschine anzumelden.
Bildquelle: http://csl.com.co/rid-hijacking/
Nach einer erfolgreichen Anmeldung an der Maschine als Gast verfügt man über Administratorrechte. Das wird an diversen Befehlen demonstriert (siehe folgendes Bild).
- Öffnet man eine Eingabeaufforderung mit cmd.exe, erkennt man, dass diese unter dem Administrator-Konto ausgeführt wird.
- Um zu prüfen, ob man wirklich als Gastkonto angemeldet ist, kann man den Befehl whoami ausführen und den Standardpfad überprüfen.
- Das Gastkonto erscheint weiterhin als Mitglied der lokalen Gruppe der Gäste, der Angriff bleibt also in dieser Hinsicht geheim bzw. kann nicht erkannt werden.
Bildquelle: http://csl.com.co/rid-hijacking/
Mit diesen Berechtigungen kann man also alles machen, was ein Administrator tun darf – u.a. auch in die durch Windows eigentlich geschützten Ordner wie System32 schreiben.
Ergänzung: Alles in allem eine interessante Geschichte, die zeigt, wie sich Windows-Konten manipulieren lassen. Dass Microsoft da nicht sofort mit einem Patch reagiert, ist auch klar – die Schwachstelle ist nur mit Administratorberechtigungen ausnutzbar, wird also in diesem Kontext als weniger kritisch gesehen. Man sollte das Thema aber im Hinterkopf behalten.
Wie aus den folgenden Kommentaren hervorgeht, hat Golem ihren Beitrag gelöscht. Das ist deren Entscheidung. An den Diskussionen der Art 'wenn ich Admin-Rechte zur Ausnutzung brauche, ist eh alles zu spät', werde ich mich nicht weiter beteiligen – da möge jeder seine eigene Phantasie spielen lassen (oder auch nicht). Ich belasse den Artikel im Blog, da alleine die Technik des RID-Hijacking und die möglichen Implikationen schon spannend genug sind.
Anzeige
Das ist ja schön, nur benötigt man zum ändern der rid adminrechte / systemrechte auf dem zielsystem. Dann mag das zwar eine lustige Methode der verschleierung sein, aber wenn jemand fremdes Admin auf meinem System ist, ist das eher das kleinere Problem.
Schade das das wie bei Golem einfach ignoriert wird und so dem Artikel einen andren Sinn gibt.
Die Demos funktionieren ziemlich sicher nicht auf einem aktuell gepatchten System.
ja, ist wie der autor selbst schreibt zwar eine "post-exploitation technique" (denn das schreiben in den HKLM-zweig der registry erfordert selber schon hoehere systemrechte), aber sie sorgt im falle eines erfolgreichen angriffs dafuer, dass eigentlich eingeschraenkte benutzerkonten damit dauerhaft und auf verschleierte weise in den besitz von adminrechten gelangen koennen. eine auf diese weise geoeffnete sicherheitsluecke ist im nachhinein relativ unauffaellig, da sie keinerlei erkennbare software/malware auf dem rechner erfordert.
Die Argumentation, dass man ja 'Admin-Rechte' braucht – und dann eh verloren hat, ist mir schon so oft untergekommen, dass ich es nicht mehr hören mag. Die Argumentation ist zwar an sich nicht falsch.
Aber ich blogge nun schon eine Weile rund um Sicherheitsthemen. Immer wieder hörte ich 'das ist mit der oder jener Schwachstelle kein Problem, weil …'. Und irgendwann ist die Schwachstelle den Leuten auf die Füße gefallen, weil jemand eine neue Idee hatte, dies und jenes zu kombinieren. Von daher tute ich mich mit der Argumentation inzwischen schwer.
Und zum letzten Satz: Informiere dich mal über DLL-Hijacking oder die diversen VC++ Probleme. Ich würde da meine Hand für deine Aussage nicht ins Feuer legen ;-)
Ergänzung: Es gibt noch zwei Aspekte, die man im Hinterkopf haben sollte. Einmal ermöglicht die oben beschriebene Methode eine Verschleierung, wer auf bestimmte Sachen zugegriffen hat (die Logs zeigen ja das entführte Konto als Urheber). Zum Zweiten: verwende ich die Credentials des Kontos Administrator, dürfte auch die Benutzerkontensteuerung ausgehebelt sein. Etwas, was man mit Administratorkonten tunlichst vermeiden will. Würde mich nicht wundern, wenn sich da jemand in dieser Richtung die Geschichte zunutze macht.
Wie sieht das aus, wenn kein lokaler Admin existiert?
Ich hatte die Hoffnung, dass einer der Domänen-Admins da was zu schreibt. Wenn ich diesen Artikel richtig interpretiere, würde ich annehmen, dass man auf dem Client die RID eher nicht übertragen kann.
RID Hijack lässt sich frei herunterladen unter https://www.rapid7.com/db/modules/post/windows/manage/rid_hijack. Ich würde es selbst machen, aber mein System läuft viel zu gut, als dass ich es mir durch so fragwürdige Experimente zerschießen möchte :D
Danke für den Hinweis – hatte ich die Nacht gesehen. Aber die Seite bietet nur 14-Tage-Trials von MetaSploit Pro – und das nur nach Angabe von E-Mail & Co. ;-)
wer sich den quelltext des moduls anschauen will:
https://github.com/rapid7/metasploit-framework/blob/master/modules/post/windows/manage/rid_hijack.rb
Golem hat den Artikel inzwischen zurückgezogen. Dort steht jetzt:
"Nachtrag vom 19. Oktober 2018, 14:02 Uhr
Wir hatten an dieser Stelle ursprünglich irrtümlich berichtet, dass eine Sicherheitslücke in Windows das Erlangen von Administratorenrechten ermögliche. Das war so nicht korrekt. Vielmehr handelte es sich lediglich um eine Strategie, mit der Rechte auf einem System übertragen werden können, auf dem ein Angreifer bereits die Kontrolle hat. Wir bitten, diesen Fehler zu entschuldigen. Über diese als RID Hijacking bezeichnete Strategie hatte ZDnet berichtet. "
Danke für die Info. Ich belasse den Beitrag aber online – der Kontext (klappt nur mit Administratorberechtigungen) für den Exploit ist ja nun herausgearbeitet. Das Thema an sich bleibt imho aber spannend, da er zeigt, was man an den Windows-Konten manipulieren kann.
es gehört dann aber auch dazu, zu erwähnen, dass es bei Golem korrigiert und ein Irrtum eingestanden wurde. Es wurde eben nicht nur der Artikel gelöscht!
Das nicht zu erwähnen ist irreführend. Unnötig.
Hallo Herr Born,
zur Vermeidung jeglicher Irritationen, schlage ich vor, daß Sie Ihren Einschub '(Artikel wurde gelöscht)' entweder zu Golem oder auf meinen Kommentar oben (der ja den Link zu Golem enthält) verlinken.
greetz
Schönes Wochenende!
PM; – just delete. :)