Der Bug-Report vom Dezember 2021

Von Philippe Laulheret · 19. Januar 2022

Ein kleines Cyber-Sicherheits-Comic zu Ihrer Aufmunterung

Warum bin ich hier?

Wenn Sie diese Zeilen lesen, HERZLICHEN GLÜCKWUNSCH! Sie haben 2021 überlebt und es sogar bis zum monatlichen ATR-Sicherheitsbericht geschafft, in dem wir unsere Lieblingsschwachstellen der letzten 30 Tage diskutieren. Klopfen Sie sich also auf die Schulter und holen Sie sich einen leckeren Kaffee, Tee oder Energy Drink – wonach auch immer Ihnen ist. Dann kann es jetzt losgehen!

Path Traversal bei Grafana: CVE-2021-43798

Was ist das?

Laut Wikipedia ist Grafana eine in der Branche weit verbreitete plattformübergreifende Open-Source-Webanwendung für Analyse und interaktive Visualisierung, zu deren zahlenden Kunden z. B. Bloomberg, eBay und PayPal gehören. Anfang Dezember wurde entdeckt, dass eine Path Traversal-Schwachstelle dazu führte, dass ein Angreifer auf lokale Dateien zugreifen konnte, weil "../../../" in ihrem Plugin-Pfad nicht ordnungsgemäß bereinigt wurde. Allerdings zog sie auch eine der kürzesten Aufdeckungszeitleisten der Geschichte nach sich:

Wen interessiert's?

Sie können kaum etwas dafür, dass in den letzten 30 Tagen fast nur über Log4Shell berichtet wurde. Wenn diese Software jedoch in Ihrem Unternehmen im Einsatz ist, hätten Sie diese Enthüllung letzten Monat wahrscheinlich doch besser verfolgen sollen. Sonst könnte es sein, dass inzwischen das ganze Internet Ihre "/etc/passwd"-Dateien“ kennt. Es gibt aber noch zwei weitere interessante Punkte, über die Sie nachdenken sollten. Wenn man sieht, wie einfach die Ausnutzung ist, hat scheinbar die Tatsache, dass der Hersteller den Bug über seinen öffentlichen GitHub patcht, ausgereicht, dass diese Schwachstelle in den Fokus gerückt ist und in weniger als 3 Tagen nach dem Patch funktionierende öffentliche PoCs verfügbar sind. Wenn Sie sich fragen, wie ausgereiftere Open-Source-Codebasen mit diesem Risiko umgehen, müssen Sie wissen, dass Projekte wie Chromium eine separate Infrastruktur für die Verfolgung von Bugs nutzen, die den Personenkreis mit Zugriff auf die Bug-Berichte (in denen die Sicherheitsrisiken und Testfälle aufgelistet werden) begrenzen kann. Diese wird mit einfach gehaltenen öffentlichen Commit-Messages kombiniert, die keine große Aufmerksamkeit auf die Sicherheits-Commits lenken sollen.

Sehr interessant ist auch, dass die Grundursache dieses Bugs in der falschen Verwendung einer Go-API liegt, um Pfade zu bereinigen, wie dieser Twitter-Thread zeigt. Es hat sich herausgestellt, dass die Funktion filepath.Clean, mit der die vom anfälligen Code verarbeitete Eingabe bereinigt wird, überzählige "../../" nur entfernt, wenn der Pfad absolut ist. Dies ist häufig der Fall bei APIs, die sich wie erwartet verhalten, aber gefährliche Konsequenzen haben. Wissen Sie genau, dass die Codebasis Ihres Unternehmens nicht von diesen Problemen betroffen ist? Ungepatchte Schwachstellen könnte hier zur Folge haben, dass Angreifer auf extrem sensible Daten zugreifen und sie weitergeben. *aus Zögern wird Hektik*

Was kann ich tun?

Natürlich die Software aktualisieren, wenn Sie sie nutzen. Darüber hinaus können Sie Angriffsversuche mithilfe von Sigma-Regeln erkennen. Idealerweise sollte Ihre Analyseplattform nicht für das ganze Internet zugänglich sein – nicht wie diese 87.000 Instanzen, von denen laut Shodan 16.000 immer noch anfällig sind. Stellen Sie zumindest sicher, dass sich Ihre Grafana-Instanz hinter einem .htaccess-Prompt oder ähnlichen Element befindet. Aus Entwicklersicht sollte mit Sicherheits- und Unit-Tests gewährleistet werden, dass die von Ihnen eingerichtete Filterung ordnungsgemäß funktioniert. Generell gilt: Wenn Sie nicht vertrauenswürdige Benutzereingaben verarbeiten, dürfen Sie bei der Filterung nicht improvisieren, sondern nur gründlich geprüfte Codemuster anwenden, statt die Warnungen Ihres Sicherheitstools zu deaktivieren.

Der Gold-Standard

In seinem Roman "Sabriel" sinnierte Garth Nix darüber, ob der Wanderer den Pfad wählt oder der Pfad den Wanderer. Sicher ist: Besagter Pfad wird von einem Angreifer weder "bewandert" noch überquert (traversiert), wenn er Kunden mit Network Security Platform-(NSP) gehört. Diese Glückspilze werden nämlich bereits durch eine generische Regel vor Path Traversal-Angriffen geschützt und können den Schutz sogar noch verstärken, wenn sie Regeln für "benutzerdefinierte Angriffe" erstellen.

CVE-2021-44228: Log4Shell

Was ist das?

Wer hätte geahnt, dass das Analysieren – und manchmal sogar das Ausführen – nicht vertrauenswürdiger Eingaben eine schlechte Idee sein könnte? Nun hat sich herausgestellt, dass der Log4j-Protokollierungscode von Apache aber genau das macht. Wenn die protokollierte Zeichenfolge die magischen Zeichen $(jdni:…) enthält, kann er sogar nicht vertrauenswürdigen Java-Code abrufen und ausführen. Zudem haben Iterationen dieses Angriffs gezeigt, dass lokale in Umgebungsvariablen gespeicherte Geheimnisse weitergegeben werden können, z. B. AWS-Schlüssel. Und wenn man die Umkehrbarkeit der Verarbeitung bedenkt, bietet er zudem viele Möglichkeiten, eine auf Musterabgleichen basierende Erkennung zu umgehen.

Wen interessiert's?

So ziemlich jeden. Sie sind Java-Programmierer und interessieren sich für Protokollierungsthemen? Dann sollten Sie hier auf dem Laufenden bleiben. Sie nutzen Java-basierte Anwendungen/Servlets? Auch dort werden wohl nicht vertrauenswürdige Benutzereingaben protokolliert. Ihr Arbeitgeber nutzt Java-basierte Appliances oder Dienste? Geben Sie Ihrem SOC und den IT-Leuten einen aus, denn sie werden wahrscheinlich viel Spaß über Weihnachten haben. Sie sehen schon, dieses Problem betrifft die gesamte Branche und aller Wahrscheinlichkeit nach werden die Auswirkungen auch in den nächsten Jahren noch zu spüren sein. Doch damit nicht genug. Der Bug kann wirklich einfach ausgenutzt werden. Von Penetrationstestern über SOC-Analysten und "Skript-Kiddies" bis hin zu staatlichen Akteuren, fast jeder befasst sich inzwischen mit diesem Angriffsvektor. Zudem haben wir massive laufende Angriffe mit einer breiten Palette von Schaddaten beobachtet, die von Krypto-Minern bis hin zu "rm -rf /*"-Schaddaten und sogar einem unterbrochenen Versuch reichen, den Mirai-Wurm zu verbreiten. Und das Schlimmste kommt wahrscheinlich erst noch.

Was kann ich tun?

In der TV-Serie "Stranger Things" heißt es, dass in "America" das Wort "Erica" steckt. Und genauso steckt "Patch" in "Apache". Irgendwie. Also: Upgraden Sie! Mikropatchen Sie. Überwachen Sie den Datenverkehr. Tipp: Wenn Ihre ausschließlich komplett interne Anwendung plötzlich LDAP-Anforderungen an einen Remote-Server in einem Land sendet, in dem Sie gar nicht vertreten sind, könnte etwas Verdächtiges vor sich gehen.

Wenn Sie Chaos lieben und/oder Ihre IT-Abteilung nur schwer von der Wichtigkeit dieses Bugs überzeugen können, holen Sie sich die Erlaubnis für eine Demonstration! Dann stellen Sie von Ihnen kontrollierte Zeichenfolgen (z. B. Benutzeragent, Twitter-Name, WLAN-SSID) auf den magischen $(jdni:ldap…)-Wert ein und lassen ihn auf einen von Ihnen kontrollierten IP:Port zeigen (oder einen Drittanbieter-Service wie Canarytoken, sofern Sie ihm vertrauen). Wenn Sie Treffer für diese Adresse erhalten, können Sie sich mit den Besitzern der eingehenden Adressen mal ganz nett über die Notwendigkeit eines Upgrades für den betreffenden Technologiestapel unterhalten. Deshalb ist es extrem wichtig, sich vorher eine Erlaubnis einzuholen. Denn wenn Sie die magische Zeichenfolge wahllos überall verteilen, um zu sehen, was geschieht (wie Sie es vielleicht auf verschiedenen Social Media-Plattformen gesehen haben), wird sich wahrscheinlich irgendwann jemand melden, um sich "nett" mit Ihnen zu unterhalten und nach Ihrem komischen Benutzeragent erkundigen. Bevor Sie also so ein Ding drehen, müssen Sie sich natürlich darüber klar werden, dass Sie kurz vor Weihnachten wohl kaum noch eine Anzeige wegen Computerbetrugs aus dem Briefkasten fischen wollen.

Der Gold-Standard

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

• Expertenregeln in Endpoint Security (ENS) können gefährliche Muster im Speicher erkennen, wie in diesem Blog-Artikel beschrieben.
• Endpoint Security (ENS), VirusScan Enterprise (VSE), Web Gateway (WG) 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 Endpoint Detection and Response (EDR) und Active Response (AR) kann zudem mittels Real-Time Search-Abfragen (RTS) nach anfälligen Systemen gesucht werden.
• SIEM hat ein Update (Inhaltspaket zu Exploits Version 4.1.0), das einen Alarm bei potenziellen Exploit-Versuchen auslöst. Insights stellt ebenfalls wertvolle Informationen unter der Bedrohungskampagne "Log4Shell – Eine Log4j-Schwachstelle – CVE-2021-44228" bereit. Siehe MVISION Insights-Vorschau.

CVE-2021-43527 – Big Sig

Was ist das?

Big Sig hätte die Mutter ihren Sigmund (Freud) rufen können. Dieser Bug ist mindestens genauso "treffend". Anfang Dezember berichtete Google Project Zero in seinem Blog über eine Schwachstelle in den Network Security Services (NSS) von Mozilla, die auf der NIST-Seite der nationalen Schwachstellendatenbank mit einem CVSS-Score von 9,8 angegeben wird. In der Verarbeitung bestimmter Signaturen (DER-codierte DSA- und RSA-PSS-Signaturen) gibt es einen Heap-Overflow. Einfach ausgedrückt ist das NSS eine Sammlung kryptografischer Bibliotheken, mit denen Entwickler sicherere/intensiv getestete Implementierungen kryptografischer Primitive und Standards (für die Verschlüsselung von Kommunikation, Prüfung der Authentizität von Daten usw.) nutzen können. Die Funktion, in der der Bug gefunden wurde, ist verantwortlich für die Prüfung von Signaturen, die die Authentizität von Daten mithilfe öffentlicher Kryptografieschemen beweisen. Diese Art von Funktion wird in der Regel verwendet, um E-Mails oder Dokumente zu signieren und ihre tatsächlichen Autoren zu bestätigen. Wirklich interessant ist die relative Einfachheit dieses Bugs, aber auch sein langes Leben. Laut dem Blog von Project Zero kann er bereits seit 2012 ausgenutzt werden. Der schwache Codepfad fiel genau durch das Raster, an dem sich verschiedene von Mozilla verwendete Fuzzing-Tools überschneiden.

Wen interessiert's?

Wenn Sie möchten, dass Ihre Signaturen verifiziert werden, und sich dafür auf die NSS-Bibliothek verlassen, sollten Sie definitiv einen Blick auf die Empfehlung werfen und die neueste Version der Software verwenden (NSS-Version 3.73/3.681 ESR oder höher). Firefox ist scheinbar nicht betroffen, aber andere Software, die Signaturen analysiert, könnte gefährdet sein (Thunderbird, LibreOffice, Evolution, Evince und mehr).

Was kann ich tun?

Wie gewohnt müssen Sie sicherstellen, dass jede Software, die Sie nutzen und anfällig sein könnte, auf die neueste Version aktualisiert wird. Der Patch wurde am 1. Dezember veröffentlicht. Als ersten Schritt sollten Sie also sicherstellen, dass potenziell anfällige Software nach diesem Datum ein Update erhält. Darüber hinaus wäre es gut, zu wissen, welche Software diese Bibliothek nutzt. Es gibt zwar keinen Königsweg, aber Verweise auf Dateien wie nss3.dll unter Windows oder libnss3.so unter Linux sind ein guter Ausgangspunkt. Darüber hinaus achten Sie am besten auf Versionsinformationen und potenzielle Listen von Drittanbieter-Bibliotheken, die in Ihren Anwendungen verwendet werden. Wenn Sie eine anfällige Bibliothek in Ihrem eigenen Produkt verwenden, aktualisieren Sie den Code oder portieren den Patch zurück.

Der Gold-Standard

Haben Sie unsere Bulletins gelesen? Sie liefern hervorragende Informationen zu kritischen Schwachstellen, die Ihnen vielleicht bisher entgangen sind! Dazu können auch Anwendungen zählen, die Patches für CVE-2021-43527 bereitstellen.