Rootkit eBPF sous Linux : fuite DB via sous-traitant

Rootkit eBPF via un prestataire : Détection de fuites de données cachées dans Linux

Un serveur de base de données sous Ubuntu générait 5 à 10 % de trafic sortant supplémentaire par rapport au trafic entrant depuis un mois. Les journaux et les processus semblaient propres, et le fournisseur confirmait un fonctionnement réseau normal. Un audit a révélé un rootkit eBPF déployé via un ordinateur portable compromis appartenant à un prestataire DBA. Les attaquants ont utilisé la chaîne d'approvisionnement pour installer un programme qui masquait les processus et exfiltré des données personnelles vers un serveur de commande et contrôle.

Premier indice : Règle iptables suspecte

Dans /etc/iptables/rules.v4, une règle autorisant les connexions TCP sortantes vers une IP du pool VPN du prestataire est apparue :

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

Cette règle ne faisait pas partie de la configuration de base. Elle permettait la transmission furtive de dumps compressés de tables de base de données. L'analyse de /var/log/auth.log a montré une connexion SSH par clé du prestataire avec une IP du même pool. L'accès au serveur avait été révoqué après le travail, mais le VPN était resté actif.

Incohérence dans /proc pointant vers un rootkit

La commande ps auxf affichait des processus standards, mais le nombre de répertoires dans /proc dépassait le nombre de PID de un. Cela indiquait une interception des appels système getdents et getdents64. La vérification de /proc/modules et l'analyse de la mémoire du noyau avec un LiveCD n'ont révélé aucun module LKM—la liste correspondait à la base de référence.

eBPF comme fondation du rootkit : Détails d'implémentation

L'utilitaire bpftool a révélé des programmes eBPF attachés aux points kprobe __x64_sys_getdents et __x64_sys_kill. Un programme socket supplémentaire redirigeait le trafic. Dans /usr/share/man/man3/, un binaire nommé systemd-snoop a été trouvé, chargeant eBPF via libbpf.

Le malware vidait les tables de données personnelles la nuit, les compressait et les envoyait au serveur de commande et contrôle. eBPF n'est pas visible dans la liste des modules car il se charge via l'appel système bpf(). La détection nécessite des privilèges root pour bpftool ou une analyse de la mémoire du noyau. Dans ce cas, les objets n'étaient pas masqués.

Scénario d'attaque

• Ordinateur portable du prestataire compromis.
• Pendant le travail planifié via clé SSH—connexion au serveur.
• Ajout de la règle iptables et installation de systemd-snoop.
• Exfiltration nocturne des données via proxy eBPF.

Méthodes pour détecter les rootkits eBPF

L'AIDE standard est inefficace—eBPF ne modifie pas les fichiers dans /lib/modules. Approches recommandées :

• Collecte périodique de bpftool prog list et bpftool map list avec envoi vers un SIEM.
• Audit de l'appel système bpf() via auditd ou ebpf_exporter.
• Surveillance avec Falco, Tracee ou Osquery pour une activité eBPF anormale.
• Analyse du NetFlow pour les écarts de trafic et corrélation avec GeoIP.

Protéger la chaîne d'approvisionnement des prestataires

Authentification et accès

• 2FA obligatoire pour SSH même avec des clés.
• Privilèges minimaux : pas d'accès root, uniquement via un hôte bastion avec journalisation des sessions.
• Rotation des clés tous les 6 mois, révocation dans les 24 heures après résiliation.
• Sessions VPN temporaires avec déconnexion automatique.

Infrastructure

• GitOps pour le pare-feu : modifications iptables uniquement via Ansible avec contrôle Git.
• ELK/Graylog centralisé + SIEM pour corréler les journaux, NetFlow et GeoIP.

Points clés à retenir

• Les rootkits eBPF masquent les processus, ne sont pas visibles dans /proc/modules, et sont détectés via bpftool.
• Attaque via prestataire : compromission de l'ordinateur portable + accès VPN persistant.
• Symptômes : asymétrie du trafic, incohérence des PID dans /proc.
• Protection : 2FA, hôte bastion, audit de bpf(), surveillance NetFlow.
• Outils : Falco, Tracee, ebpf_exporter pour la détection en temps réel.

Ce cas démontre comment une anomalie mineure de trafic a révélé une exfiltration de données d'un an. La mise en œuvre d'une surveillance proactive eBPF et d'un contrôle d'accès strict minimise les risques liés aux équipes externes.

— Editorial Team