VED (Vault Exploit Defense): Ein System zur Erkennung und Abwehr von Bedrohungen

Vault Labs, HardenedVault

Hintergrund

Zu Beginn der Ära des Hackers wurde ein langfristiger Kampf um die Kontrolle über den “CORE” im Gedächtnis geführt, seit Aleph One 1996 das Papier [Smashing The Stack For Fun And Profit] (http://phrack.org/archives/issues/49/14.txt) über Phrack Issue 49 veröffentlichte. Angreifer zielten in den nächsten zehn Jahren hauptsächlich auf den Benutzerraum ab, aber als die Popularität der Userland-Mitigation weiter verbreitet wurde, begannen mehr Angreifer, den “CORE” in den Kernel zu verschieben . Wir haben das dunkle Zeitalter der Linux-Kernel-Sicherheit durchgemacht, als “eine Nullzeiger-Dereferenzierung sie alle pwen kann”. Brad Spengler, einer der PaX/Grsecurity-Autoren offengelegt die Situation der Linux-Kernel-Sicherheit der Öffentlichkeit von Washington Post, was zu einigen Reaktionen des Megakoprs der Welt führte: Google, Red Hat, ARM und Intel haben ein Projekt namens KSPP (Kernel Self-protection project) gestartet, das das Problem tendenziell löst. Leider ist KSPP derzeit aus mehreren Gründen ziemlich zusammengebrochen, während Linux in kritischere Infrastrukturen wie Strom, Energie, Internet of Vehicle, ICS (Industrial Control System) usw. vorgedrungen ist. Aber die Probleme der Linux-Kernel-Sicherheit bleiben ungelöst.

Das Problem ist schwer zu lösen

• Die Kette der Korrekturen für eine Linux-Kernel-Schwachstelle vom Upstream- zum Linux-Distributionskernel (Produktionssystem) ist zu lang, da in Wirklichkeit niemand den “Upstream”-Kernel in dem Sinne wirklich verwendet.

• Stable Branch Mainters und Distribution Communities haben Schwierigkeiten, die Vulnerablity-Analyse, Regressionstests und die Ermittlung der Verteidigung für jede Vulnerablity zu verfolgen. Auf der anderen Seite können einige Sicherheits-Backports entweder von einem stabilen Zweig oder einem Distributionskernel übersehen werden.

• Die Linux-Kernel-Community vertritt die Philosophie “Sicherheit durch Verschleierung”, was bedeutet, dass sie niemals eine CVE einreichen. Trotzdem gibt es zwischen Januar und August 2021 mehr als 110 CVE-nummerierte Kernel-Schwachstellen.

• Das 0-Tage-Geschäft hat sein eigenes Ökosystem, und es ist ihnen egal, ob es ein CVE gibt

Unsere Lösung: VED (Vault Exploit Defense)

Um den Kunden bei der Lösung dieser Probleme zu helfen, entwickelte HardenedVault eine Linux-Kernel-0day-Schutzlösung namens VED. Das Bedrohungsmodell sieht im Wesentlichen wie folgt aus:

• Das grundlegende Implementierungsframework arbeitet als LKM (Linux Kernel Module) und ist Hook-basiert und kompatibel mit dem Hook-System der vorhandenen Sicherheitslösung, z. B. AKO oder LKRG.

• Versuchen Sie, den Exploit-Pfad in der früheren Phase zu blockieren. Andernfalls wird die Erkennung einige Quoten in der Post-Exploitation-Phase ausprobieren.

• “Watching the watcher” ist ein philosophisches Thema in der Cybersicherheit. VED ist ein wichtiges Sicherheitsprodukt, da es die letzte Verteidigungslinie ist, um das Produktionssystem des Kunden zu schützen (Virtualisierungs-, Firmware- und Hardwareschicht werden vor dem Angreifer vorhanden sein, wenn der Kernel kompromittiert wurde, so dass man sagen kann, dass VED die letzte sinnvolle Verteidigungslinie ist), so dass VED Selbstschutzeigenschaften haben muss.

Einige entscheidende Merkmale in VED:

• wCFI, sorgfältige Untersuchung wichtiger Funktionen zur Laufzeit durch Scannen der binären Aufrufseite im Textabschnitt für VED && syscalls Überprüfen Sie den Kernel-Stack (zwischen Call und ret) während schedule(). Es unterstützt zwei überlagerbare Verteidigungsmodi: ** Der Bereich wird nur dadurch bestimmt, ob eine Anweisung vor der Absenderadresse eine Anrufanweisung ist (unabhängig davon, ob es sich um eine Adresse oder ein Register oder einen Zeiger handelt). Diese Funktion kann die willkürliche Entlehnung von Codeblöcken zum Erstellen der ROP-Kette verhindern. Der einzige Block, der von ROP verwendet werden kann, ist der zwischen Call und Ret, der wahrscheinlich wCFI umgeht. ** Einige Funktionen werden durch VED markiert: 1) Kann vom Exploit-Writer favorisiert werden 2) Kann nur direkt aufgerufen werden (Anruf über eine Adresse, kein Register oder Zeiger). Wenn beispielsweise Funktion B() die wichtige Funktion ist, die markiert wird und nur von Funktion A() aufgerufen werden kann, dann berechnet VED die Adresse von B()‘’s, indem es eine Anweisung in A()‘’s Textabschnitt wie “call *” durchsucht und mit dem Offset berechnet. Wenn VED feststellt, dass der Textabschnitt von A()‘’s keine solche Anweisung enthält, wird die Ausführung blockiert.

• Schutz kritischer Datenstrukturen

• VSPP (VED-Selbstschutzprojekt), ist dies vor allem dann notwendig, wenn Multi-Threat-Akteure unter Ihrem Bedrohungsmodell:

• Post-Exploitation-Prüfungen auf KERNEXEC (SMEP/PXN), UDEREF (SMAP/PAN), creds, MODHELPER, etc

Situative Härtung: Automobilindustrie

Laut UPSTREAM SECURITY’S GLOBAL AUTOMOTIVE CYBERSECURITY REPORT 2020 betragen die Angriffe aus der Cloud, Infotainment und ECU/TCU/GW 27,22%, 7,69% und 5,03%:

Der Anteil der Linux-Systeme, die in diesen Systemen laufen, ist sehr hoch. Es gibt zwar bestimmte Anforderungen an den Linux-Sicherheitsschutz in Requirements on Security Management for Adaptive Platform (AUTOSAR AP R20-11), aber es handelt sich eher um minimale Anforderungen für den Anbieter. Auf der anderen Seite steht das Fahrzeug in freier Wildbahn vor einer ernsteren Situation:

Die technischen Details haben nicht mit der Zeit Schritt gehalten, und einige Änderungen / Vorschläge wurden kürzlich von HardenedVault vorgeschlagen.

Cloud-native Sicherheitsarchitektur

Die Kubernetes-Architektur reduziert die Schwierigkeit der Standardisierung von Entwicklung und Betrieb für das Unternehmen im Vergleich zu lokalen und virtuellen Maschinen als primäre Business-Support-Infrastruktur erheblich, was einen Sicherheitsvorteil darstellt und auf drei Komponenten reduziert werden kann, die weitgehend auf einer Cloud-nativen Sicherheitsarchitektur basieren:

• Falco-basiertes Container-Sicherheitserkennungssystem für Überwachung und Audit. Es gibt zwei Hauptmodi der Datenerfassung über den Falco-Treiber (benutzerraumbasierte Instrumentierung wird hier nicht diskutiert): 1) Standardmäßig kann ein Tracepoint-basiertes LKM (Linux-Kernelmodul) zur Überwachung von ca. 88 Syscalls verwendet werden. 2) Eine eBPF-basierte Implementierung kann über 81 Syscalls überwacht werden, aber bitte beachten Sie, dass diese Implementierung auch auf Tracepoints basiert. Unternehmensbenutzer können Code und Regeln basierend auf dem Falco-Framework schreiben und anpassen, um ihre Anforderungen zu erfüllen.

• Um Kernel-Komponenten zu schützen, da die neuen Falcon-Bereitstellungen zunehmend eBPF verwenden, ist es daher notwendig, auch eBPF zu schützen. Der Hauptzweck des Kernel-Schutzes besteht darin, die EoP (Esclation of priviledges) und die Container-Flucht zu verhindern. In einer solchen Architektur kann eine erfolgreiche Container-Flucht zur Kompromittierung anderer Pods / Container führen, was für die Datensicherheit von Bedeutung ist.

• Gehärteter ELK- oder SIEM-Protokollserver.

In einer Cloud-nativen Sicherheitsarchitektur können VEDs entweder gut mit Falco zusammenarbeiten oder Protokolle von blockierenden Angriffen zur Analyse an die SIEM/ELK-Plattform senden.

Demo aus der Praxis

Nun, da wir in letzter Zeit viele Anfragen zu ein paar öffentlichen Schwachstellen erhalten haben. Wir haben gezeigt, wie VED eine [populäre] (https://google.github.io/security-research/pocs/linux/cve-2021-22555/writeup.html) besiegen kann, die in kCTF (einer Kubernetes-basierten Infrastruktur für CTF-Wettbewerbe) gefunden wurde.