eBPF-rootkit w Linux: wyciek bazy danych przez podwykonawcę

eBPF-rootkit poprzez podwykonawcę: wykrycie ukrytego wycieku bazy danych w Linux

Serwer bazy danych na Ubuntu generował o 5–10% więcej ruchu wychodzącego niż przychodzącego przez miesiąc. Logi i procesy wyglądały czysto, dostawca potwierdził normalną pracę sieci. Audyt wykazał eBPF-rootkit, wdrożony poprzez skompromitowany laptop podwykonawcy DBA. Osoby atakujące wykorzystały łańcuch dostaw do zainstalowania programu ukrywającego procesy i eksfiltrującego dane PII na serwer C2.

Pierwszy trop: podejrzana reguła iptables

W /etc/iptables/rules.v4 pojawiła się reguła zezwalająca na wychodzące połączenia TCP na IP z puli VPN podwykonawcy:

-A OUTPUT -d xxx.xxx.xxx.xxx -p tcp --dport YYYY -j ACCEPT

Ta reguła nie występowała w konfiguracji bazowej. Pozwalała ona na dyskretne wysyłanie skompresowanych zrzutów tabel bazy danych. Analiza /var/log/auth.log wykazała logowanie przez klucz SSH podwykonawcy z IP z tej samej puli. Dostęp do serwera został odwołany po pracach, ale VPN pozostał aktywny.

Niespójność w /proc wskazała na rootkit

Polecenie ps auxf wyświetlało standardowe procesy, ale liczba katalogów w /proc przekraczała liczbę PID o jeden. Wskazywało to na przechwycenie wywołań systemowych getdents i getdents64. Sprawdzenie /proc/modules i analiza pamięci jądra z LiveCD nie wykazały modułów LKM — lista zgadzała się z referencyjną.

eBPF jako podstawa rootkita: szczegóły implementacji

Narzędzie bpftool wykryło programy eBPF dołączone do punktów kprobe __x64_sys_getdents i __x64_sys_kill. Dodatkowy program na gnieździe przekierowywał ruch. W /usr/share/man/man3/ znaleziono plik binarny systemd-snoop, ładujący eBPF przez libbpf.

Złośliwe oprogramowanie nocą zrzucało tabele z PII, kompresowało i wysyłało na C2. eBPF nie jest widoczny w liście modułów, ponieważ jest ładowany przez syscall bpf(). Wykrycie wymaga uprawnień root dla bpftool lub analizy pamięci jądra. W tym przypadku obiekty nie były ukryte.

Scenariusz ataku

• Skompromitowany laptop podwykonawcy.
• Podczas planowanych prac przez klucz SSH — logowanie na serwer.
• Dodanie reguły iptables i instalacja systemd-snoop.
• Nocna eksfiltracja danych przez proxy eBPF.

Środki wykrywania rootkitów eBPF

Standardowy AIDE jest bezużyteczny — eBPF nie modyfikuje plików w /lib/modules. Zalecane podejścia:

• Okresowe zbieranie bpftool prog list i bpftool map list z wysyłką do SIEM.
• Audyt syscall bpf() przez auditd lub ebpf_exporter.
• Monitorowanie z Falco, Tracee lub Osquery pod kątem anomalnej aktywności eBPF.
• Analiza NetFlow pod kątem rozbieżności ruchu i korelacji z GeoIP.

Ochrona łańcucha dostaw przed podwykonawcami

Uwierzytelnianie i dostęp

• Obowiązkowe 2FA dla SSH nawet z kluczami.
• Minimalne uprawnienia: bez root, tylko przez bastion host z logowaniem sesji.
• Rotacja kluczy co 6 miesięcy, odwołanie w 24 godziny po zwolnieniu.
• Tymczasowe sesje VPN z automatycznym wyłączeniem.

Infrastruktura

• GitOps dla firewalla: zmiany iptables tylko przez Ansible z kontrolą Git.
• Scentralizowany ELK/ Graylog + SIEM do korelacji logów, NetFlow i GeoIP.

Co jest ważne

• Rootkity eBPF ukrywają procesy, nie są widoczne w /proc/modules, wykrywane przez bpftool.
• Atak przez podwykonawcę: kompromitacja laptopa + pozostawiony dostęp VPN.
• Objawy: asymetria ruchu, niespójność PID w /proc.
• Ochrona: 2FA, bastion, audyt bpf(), monitorowanie NetFlow.
• Narzędzia: Falco, Tracee, ebpf_exporter do wykrywania runtime.

Ten przypadek pokazuje, jak drobna anomalia ruchu ujawniła roczną eksfiltrację. Wdrożenie proaktywnego monitorowania eBPF i ścisłej kontroli dostępu minimalizuje ryzyka ze strony zewnętrznych zespołów.

— Editorial Team