Der Bug Report vom Januar 2022

Von Kevin McGrath · 2. Februar 2022

Ein kleines Cyber-Sicherheits-Comic zu Ihrer Aufmunterung

Warum bin ich hier?

Omikron ist der 15. Buchstabe im griechischen Alphabet. Er wurde von Donald Knuth als Symbol für die O-Notation verwendet, stellte die Null im Almagest von Ptolemäus dar und hatte den Wert 70 in der Isopsephie. Doch für die meisten von uns symbolisiert er die Pandemie, die EINFACH. NICHT. ENDEN. WILL. Wie? Sie interessieren sich gar nicht für philosophische Abschweifungen zum meistgenutzten Wort im Januar 2022? Sie wollten hier eigentlich etwas über irgendwelche Schwachstellen erfahren? Aber, aber... na egal. Willkommen bei der Januar-Ausgabe des Bug-Reports!

• CVE-2022-0185: Denn nicht nur Java-Entwickler haben vergessen, Eingaben zu validieren!
• CVE-2021-42392: Was? Sie dachten, Log4Shell würde einfach so verschwinden?
• CVE-2022-21907: Ich habe dich nicht vergessen, kleiner Wurm.
• CVE-2021-4034: PwnKit – was passiert, wenn man meint, dass sudo nicht reicht.

CVE-2022-21907: Von Würmern ausnutzbarer Bug in HTTP.sys

Was ist das?

Zum Patch-Dienstag im Januar 2022 hat uns Microsoft mit einer für Würmer ausnutzbaren Schwachstelle im Kernel-Treiber HTTP.sys als Neujahrsgeschenk begrüßt. Innerhalb von sieben Monaten ist dies bereits die zweite in HTTP.sys gefundene für Würmer ausnutzbare Schwachstelle. Das ist ziemlich beeindruckend, wenn man bedenkt, wie ausgereift der Code dieses Treibers eigentlich ist. Aber CVE-2021-31166 hat nicht zum Zusammenbruch des Internets geführt und CVE-2022-21907 wird das hoffentlich auch nicht schaffen! CVE-2022-21907 nutzt den unvollständigen Patch von CVE-2021-31166 aus und profitiert von der HTTP-Trailer-Unterstützung (Metadaten am Ende einer segmentierten Nachricht). Unklar ist, ob dieser Exploit auf einen TRAILER-Header im letzten Segment angewiesen ist oder nicht – der RFC gibt ihn als OPTIONAL an. Dies stellt ein potenzielles Problem für Programmierer von Netzwerkproduktsignaturen dar, wenn sie sich nicht auf den TRAILER-Header verlassen können.

Interessante Info: PoCs dafür gibt es in GitHub!

Auch interessant: Wir beobachten die ersten Ausnutzungen da draußen! Wenn Sie die neuesten Informationen zu aktuellen Bedrohungen erhalten möchten, sollten Sie unbedingt einen Blick auf McAfee Insights werfen.

Es mag zwar vernünftig erscheinen, dass HTTP.sys nur von IIS verwendet wird, dies ist jedoch leider nicht der Fall. HTTP.sys ist der Kernel-Treiber, der wichtigen HTTP-Verarbeitungs-Code bereitstellt. Dieser Code wird von anderen Subsystemen genutzt:

• ADFS
• WinRM
• Intel Support-Assistent

Die vom Treiber genutzten Dienste können Sie mit der folgenden Anweisung anzeigen:

PS > netsh http show servicestate

Sie listet die im aktuellen System ausgeführten Anforderungswarteschlangen und die damit verknüpften URLs auf.

Wer sich nach Server 2019 oder Windows 10 1809 noch nicht wieder um die Updates gekümmert hat, ist trotzdem auf der sicheren Seite…es sei denn, in der Registrierung wurde die Trailer-Unterstützung aktiviert.

Wen interessiert's?

2,4 Millionen Twitter-Anwender. Alle, in deren Umgebung IIS ausgeführt wird. Alle Nutzer von DocuSign (und das sind recht viele, wenn man die Anzahl rechtlich bindender Verträge sieht, die DocuSign durchlaufen, insbesondere während der Pandemie). Einem neuen Marktbericht zufolge wird IIS von ca. 7 % aller Internet-Websites genutzt. Dabei hat Microsoft gar nicht sehr viele Systeme mit Internet-Anbindung, d. h., es gibt noch viele andere Websites, die IIS nutzen. Oh und alle, die standardmäßig anfällige Versionen von Windows nutzen:

• Windows 10 2004 und höher (ARM und x64)
• Windows Server 20H2 und höher

Was kann ich tun?

Patchen Sie! Parallel zur Ankündigung hat Microsoft einen Patch für diese Schwachstelle veröffentlicht. Wenn Sie nicht patchen können, sollten Sie diese Systeme am besten nicht mehr mit einer Internet-Verbindung betreiben. Leider ist keine hostbasierte Behebung für aktuelle Versionen von Windows verfügbar.

Wenn Sie Windows Server 1909 oder Windows 10 1809 ausführen, sind Sie standardmäßig nicht anfällig. Ihren Anfälligkeitsstatus können Sie mit der folgenden Anweisung ermitteln:

PS > Get-ItemProperty "HKLM:\System\CurrentControlSet\Services\HTTP\Parameters" | Select-Object EnableTrailerSupport

Wenn ein Wert zurückgegeben wird und dieser Wert ungleich null ist, sind Sie gefährdet. Führen Sie zur Behebung des Problems folgende Anweisung aus:

PS > Set-ItemProperty "HKLM:\System\CurrentControlSet\Services\HTTP\Parameters" -name EnableTrailerSupport -Value 0

Oder löschen Sie diesen Registrierungsschlüssel einfach.

Der Gold-Standard

Die gute Nachricht ist, dass ein Patch verfügbar ist. Bitte wenden Sie ihn an! Wenn Sie den Patch wegen…irgendwas... nicht anwenden können… Keine Sorge. Trellix schützt Sie mit NSP-Signaturen (Network Security Platform) vor dieser Schwachstelle. Aktualisieren Sie also zumindest Ihre Signaturdatenbank!

CVE-2021-42392: H2 will auf diesen Log4Shell-Zug aufspringen!

Was ist das?

Eine Log4Shell-ähnliche Schwachstelle im Prozess für das Remote-Laden von Klassen mit JNDI. Sie nutzt zwar nicht den Bug in Log4j (Log4j wird noch nicht einmal benötigt), wohl aber dieselbe zugrunde liegende Technologie (JNDI). Eine vom Angreifer kontrollierte URL, die es bis zur Datenbank schafft (aber Sie haben ja Ihre Eingabe bereinigt…richtig?), kann die Remote-Code-Ausführung im Kontext des H2-RDBMS erreichen. Ihnen kann das natürlich nicht passieren, weil alle Abfragen an der Datenbank bereinigt, parametriert und gespeichert werden. Natürlich.

Wen interessiert's?

Einige Schätzungen beziffern die Nutzung von H2 mit fast 7.000 Projekten – einschließlich Log4j. Fragen Sie sich da, ob Log4j überhaupt jemals das wahre Problem war? Log4Shell müsste umbenannt werden und nicht nur von Log4j-Anwendern genutzt werden, wenn das der Fall ist. Aber wer weiß, was noch kommt?

Was kann ich tun?

H2-Datenbankversionen 1.1.100 bis 2.0.204 sind betroffen. Version 2.0.206, die am 5. Januar 2022 ausgeliefert wurde, behebt diese Schwachstelle. Eine Aktualisierung mindestens auf Version 2.0.206 wäre ideal.

Sie könnten die Datenbank-Module wechseln, doch das wäre wohl zu extrem. Eine Krankheit zu besiegen, indem der Patient getötet wird, ist in der IT – wie in der Medizin – keine empfehlenswerte Lösung.

Sie könnten auch Java einfach nicht mehr verwenden? Hört sich zwar ähnlich drastisch an, scheint aber in diesem Fall sinnvoll. Und tatsächlich: Es ist eindeutig die beste Lösung. Java mag ein hervorragender Anbauort für Kaffee sein, gehört aber sicher nicht auf Server.

Der Gold-Standard

Wenn Sie nicht patchen, den gesamten Java-Code entfernen und zu irgendeiner anderen Sprache wechseln oder die Datenbank-Module tauschen können, schützt Trellix Sie, weil die Exploits Log4Shell sehr ähnlich sind.

Trellix-Kunden sind in verschiedene Richtungen geschützt (Details finden Sie in diesem KnowledgeBase-Artikel):

• Expertenregeln in Endpoint Security (ENS) kann gefährliche Muster im Speicher erkennen, wie in diesem Blog-Artikel beschrieben.
• Endpoint Security (ENS), VirusScan Enterprise (VSE), McAfee Web Gateway (MWG) können eine generische Erkennung unter Exploit-CVE-2021-44228.C über die Erkennung einer potenziell unerwünschten Software bereitstellen. Diese Erkennung wird zudem durch eine Liste von Hash-Werten aus echten Kampagnen unterstützt, die diese Schwachstelle ausnutzen.
• Network Security Platform (NSP) kann den Angriff auch über eine benutzerdefinierte Signatur erkennen (die im oben verknüpften KB-Artikel bereitgestellt wird).
• Mit MVISION Endpoint Detection and Response (EDR) und McAfee Active Response (MAR) kann zudem mittels Real-Time Search-Abfragen (RTS) nach anfälligen Systemen gesucht werden.
• McAfee SIEM hat ein Update (Inhaltspaket zu Exploits Version 4.1.0), das einen Alarm bei potenziellen Exploit-Versuchen auslöst.

CVE-2022-0185: Linux-Kernel-Namespace-Unterlauf

Was ist das?

Äußerlich ist CVE-2022-0185 ein einfacher Ganzzahl-Unterlauf in einem veralteten Code-Pfad. Zum Glück aller Anwender, die Container nutzen, befindet sich dieser veraltete Code-Pfad im File System Context (FSC). An seine Stelle trat zwar die File Context API (FCAPI), allerdings wurden bestimmte Funktionen im Sinne der Rückwärtskompatibilität übernommen – darunter der anfällige Pfad. Dieser Ganzzahl-Unterlauf erzeugt einen unbegrenzten Schreibvorgang für einen Angreifer im Kontext des Container-Prozesses. Ein Angreifer mit Zugriff auf einen Container kann diese Schwachstelle nutzen, um den zugrunde liegenden Host anzugreifen, und sich Zugriff auf alle anderen Container verschaffen, die auf diesem Knoten ausgeführt werden. Wenn man sieht, wie beliebt Tools wie Kubernetes (k8s) geworden sind, haben alle Anlass zur Sorge, die Container für die Prozessisolation bei nicht vertrauenswürdigen Anwendern nutzen. Dieses Problem betrifft nur Container, die Namespaces ohne Berechtigungen verwenden, Container, die den Befehl unshare erlauben, oder Container mit der Berechtigung CAP_SYS_ADMIN (standardmäßig deaktiviert). Der Befehl unshare wird in Docker-Containern standardmäßig durch den Filter seccomp blockiert. Zum Pech der k8s-Anwender wird der Filter seccomp standardmäßig nicht aktiviert, d. h., alle Kubernetes-Cluster sind gefährdet.

Die Vergangenheit ist ein Würgegriff um den Hals des Fortschritts, das langsam das Leben aus allem Guten auf dieser Welt saugt. Mit anderen Worten: Rückwärtskompatibilität verhindert oft schöne Sachen.

Wen interessiert's?

Alle, die einen Container ausführen. Auch Administratoren, die das selbst nicht tun, aber es Anwendern erlauben. Oder wenn in Containern Reste aufgehoben werden sollen, obwohl das vielleicht etwas zu weit geht. Jeder, der einen Container auf einem freigegebenen Server ausführt, sollte sich zumindest Sorgen machen und potenziell alle missionskritischen Elemente von diesem Server entfernen, bis sicher ist, dass der zugrunde liegende Kernel aktualisiert wurde.

Die Autoren haben einen detaillierten Blog-Artikel geschrieben und PoC-Code für diese Schwachstelle veröffentlicht. Also, momentan sollten wir alle besorgt sein, denn es ist nur eine Frage der Zeit, bis böswillige Akteure die Schwachstelle ausnutzen.

Was kann ich tun?

Wenn Sie den Host kontrollieren, müssen Sie den Kernel aktualisieren. Wenn das keine Option ist (oder der Eigentümer es ablehnt), begrenzt die Ausführung von

# sysctl -w kernel.unprivileged_userns_clone = 0

diese Schwachstelle auf Container mit der Berechtigung CAP_SYS_ADMIN. Wenn Sie diese Berechtigung aus Ihren Containern entfernen, wird auch diese Schwachstelle behoben (standardmäßig deaktiviert).

Red Hat empfiehlt für Systeme, die keine Container ausführen, Namespaces einfach komplett zu deaktivieren:

# echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.conf # sysctl -p /etc/sysctl.d/userns.conf

Das hat gleichzeitig zur Folge, dass dieser Host keine Container mehr ausführen kann. Vermutlich ohnehin eine gute Idee, wenn Sie sie überhaupt nicht verwenden.

Der Gold-Standard

Momentan sind das Patchen oder Anwenden von Behebungen Ihre besten Optionen. Da Container als Isolationsmechanismus genutzt werden, ist es unwahrscheinlich, dass ein externer Prozess Einblicke in einen ausgeführten Container hat. Stellen Sie sicher, dass die Ausführung auf einem gepatchten Host stattfindet oder aktivieren Sie den Filter seccomp für k8s.

CVE-2021-4034: PwnKit

Was ist das?

CVE-2021-4034, auch liebevoll PwnKit genannt, nutzt einen Logik-Bug in PolKit (früher bekannt als PolicyKit). PolKit ist ein systemweiter Richtlinienverwaltungsdienst, der Prozessen ohne Berechtigungen sicheren Zugriff (so wurde zumindest angenommen) auf Prozesse mit Berechtigungen ermöglicht. Der Bug findet sich insbesondere im Tool pkexec (weil sudo irgendwie nicht genug war und unbedingt ein weiteres setuid-Programm gebraucht wurde, das… genau dasselbe wie sudo macht). Dabei wird angenommen, dass die Variable argc mindestens den Wert 1 besitzt. Für einen typischen Programmaufruf trifft das natürlich zu. Es gibt aber auch Methoden…die alle auf Kompromittierungen hindeuten und zur Laufzeit abgewehrt werden sollten. Aber, hey, es ist, wie es ist!

Bei der Verwendung von pkexec wird in der Regel ein Popup-Fenster angezeigt, das nach Anmeldedaten fragt. Diese Schwachstelle umgeht die Prüfung der Anmeldedaten und wird einfach als Root ausgeführt. Denn natürlich, nach einem Fehler händigt man einfach den Schlüsselbund aus und klopft sich selbst auf die Schulter!

Dies ist die zweite polkit-Schwachstelle in 6 Monaten. Auch CVE-2021-3560 umging die Anmeldedatenprüfung mit dem dbus-Mechanismus, um polkit aufzurufen. Beide haben scheinbar dieselbe Root-Schwachstelle ausgenutzt. Wenn wir schon beim Thema sind, die Grundursache wurde zuerst 2013 gemeldet, ohne dass der Autor einen direkten Weg zur Ausnutzung sah. Und so rottete der Patch einsam vor sich hin, in der Hoffnung, eines Tages doch noch in voller Pracht erstrahlen zu können. Neun Jahre zogen ins Land... nun strahle, schöner Patch! Nutze deine Zeit im Sonnenlicht!

Wen interessiert's?

Es lässt sich schwer bestreiten, dass dies der größte lokale Berechtigungseskalations-Bug des letzten Jahres ist. Diese Schwachstelle funktioniert unter den meisten Linux-Hauptdistributionen, die veraltete polkit-Binärdateien ausführen. Damit ist jeder anfällig, der Linux ausführt und seit dem 25. Januar nicht mehr gepatcht hat. Die Versionsnummern von polkit sind etwas unsicher, weil Debian seine eigene Struktur hat. Wenn Sie jedoch eine Version

• kleiner als 0.105-26ubuntu1.2 unter Ubuntu 20.04 (LTS),
• kleiner als 0.105-31ubuntu0.1 unter Ubuntu 21.10,
• kleiner als 0.105-31+deb11u1 unter Debian Bullseye oder
• kleiner als polkit-0.115-11.el8_4.2 unter RedHat Enterprise Linux (RHEL) 8.4 EUS

ausführen, sind Sie gefährdet. Noch einmal: Sie sind gefährdet, wenn Sie seit dem 25. Januar keinen Patch mehr installiert haben. Es gibt auch PoC-Code da draußen, sodass es nicht lange dauern wird, bis die Schwachstelle aktiv ausgenutzt wird.

Oh, Sie vertrauen allen Ihren Anwendern? In that case, you have nothing to worry about. Compromised accounts are readily available. Ob es durch Phishing, Cracking, andere kompromittierte Konten, die dieselben Anmeldedaten teilen, oder irgendeine andere Methode der Kontenkompromittierung geschah, Vertrauen in Anwender ist kein Grund für Vertrauen in Anwenderkonten.

Dieser Bug wurde zwar unter Linux gefunden, aber auch andere UNIX-Distributionen verwenden polkit, auch die BSDs. Zumindest OpenBSD hält aber schon immer Abwehrmechanismen parat – es verweigert die Ausführung eines Programms mit einem argc von 0. Solaris nutzt ebenfalls polkit, aber Oracle macht so ein Geheimnis um Solaris, dass sie sogar eine Bezahlschranke für Sicherheitsbulletins eingerichtet haben. Eine super Methode, um Kunden zu halten!

Was kann ich tun?

Updaten Sie! Die Patches sind bei allen großen Linux-Anbietern erhältlich und sollten angewendet werden. Es sind keine Neustarts erforderlich. Sollten Sie sich dennoch gegen das Patchen entscheiden, können Sie das setuid-Element in pkexec entfernen:

# chmod 0755 /usr/bin/pkexec

Leider hindert dieser Schritt pkexec auch an seiner eigentlichen Arbeit. Aber besser so, als eine Kompromittierung zu riskieren, richtig?

Red Hat hält eine RHEL-spezifische Behebungsanleitung in seinem Sicherheitsbulletin bereit.

Der Gold-Standard

Da dies eine koordinierte Veröffentlichung für alle Linux-Distributionen war, sollte das Update tatsächlich einfach angewendet werden. Es lohnt sich, darauf hinzuweisen, dass anormale Ursprungspunkte von Anmeldungen ohne irgendeine andere Form der Authentifizierung aufgezeichnet, markiert und möglichst blockiert werden sollten. Sie verwenden die Mehrfaktor-Authentifizierung, richtig? Mehrfaktor-Authentifizierung würde die Ausnutzung dieser Schwachstelle durch Nicht-Insider-Bedrohungen stoppen, weil sie nicht auf das System zugreifen könnten. Und Insider-Bedrohungen? Das ist unsere Hausaufgabe für den Leser.