Des chercheurs de la société ARMO ont démontré la possibilité de créer des rootkits n'utilisant pas d'appels système spécifiques pour effectuer des opérations typiques, telles que la lecture/écriture de fichiers et la réception de commandes d'un serveur externe. Au lieu des appels système pour réaliser des opérations réseau et fichiers, il est proposé d'utiliser l'interface d'entrée/sortie asynchrone io_uring, prise en charge depuis le noyau Linux 5.1.
Le principe de la méthode est que, plutôt que d'effectuer des appels système distincts pour accéder aux fichiers et effectuer des opérations réseau (read/write, recv/send/connect/bind/listen), on peut utiliser les appels système généraux io_uring (io_uring_enter, io_uring_setup, io_uring_register, etc.) qui ne sont pas analysés par les outils standards pour détecter les activités malveillantes. L'interface io_uring prend en charge environ 60 opérations différentes. Une fonctionnalité permettant de lancer de nouveaux processus via io_uring est en cours de développement.
Pour démontrer le fonctionnement de la méthode, un prototype de rootkit nommé Curing a été préparé, exécutant des actions telles que la réception de commandes d'un hôte externe de serveurs et la transmission/modification de fichiers. La démonstration a impliqué l'envoi d'une requête au port TCP 8888 d'un hôte externe et l'envoi du contenu du fichier «/etc/shadow». Il est supposé qu'après une compromission réussie du système et l'acquisition des droits root, l'attaquant installe le rootkit pour consolider sa présence dans le système piraté.
Dans l'expérience réalisée, l'activité du rootkit Curing n'a pas été détectée par les outils de surveillance Falco et Tetragon, utilisés pour identifier les anomalies liées à la sécurité sur les hôtes et dans les conteneurs (une intégration avec une infrastructure basée sur Kubernetes est prise en charge). Ces outils utilisent l'interception des appels système pour analyser des événements tels que le lancement de processus, l'activité réseau et la manipulation de fichiers, mais ne tiennent pas compte de la possibilité d'utiliser la sous-système io_uring pour de telles opérations. La plupart des systèmes commerciaux de détection et de réponse aux incidents de sécurité disponibles pour Linux s'appuient également sur l'interception des appels système.
Pour éviter de contourner les outils de suivi de l'activité réseau et des fichiers, il est recommandé d'utiliser le mécanisme KRSI (Kernel Runtime Security Instrumentation), introduit dans le noyau Linux 5.7, qui permet de lier des programmes BPF à n'importe quel hook LSM. Par exemple, KRSI au niveau des hooks LSM permet de suivre les opérations sur les fichiers, l'accès réseau et le lancement de processus, peu importe si ces opérations ont été initiées par des appels systèmes spécifiques ou via io_uring.
Auparavant, la sous-système io_uring avait été critiqué en raison de vulnérabilités sérieuses régulièrement découvertes. En réponse aux demandes des utilisateurs souhaitant un outil simple pour désactiver io_uring sans reconstruire le noyau, la version 6.6 du noyau Linux a introduit le sysctl io_uring_disabled. Google a par défaut désactivé io_uring dans ChromeOS, Android et sur ses serveurs, expliquant que la situation désastreuse de la sécurité dans io_uring l'emporte sur les avantages d'utilisation d'io_uring pour améliorer les performances.
Source : opennet.ru
