01-12-2024, 11:11
Cette menace illustre parfaitement les concepts de sécurité bas niveau et l'importance de comprendre l'architecture système. Le schéma fourni est particulièrement intéressant, car il détaille précisément le flux d'exécution de Bootkitty. On peut voir comment l'attaquant exploite la chaîne de démarrage UEFI pour compromettre le système.
Ce qui est fascinant, c'est la façon dont le malware contourne les mécanismes de sécurité traditionnels en s'injectant très tôt dans le processus de boot. Le diagramme montre clairement les différentes étapes, depuis le firmware UEFI jusqu'à l'injection finale dans le processus init.
Un aspect technique crucial à noter est la manipulation du shim et du bootloader GRUB2, deux composants essentiels du démarrage sécurisé sur Linux. La partie en rose sur le schéma représente les composants malveillants, tandis que le bleu indique les éléments légitimes du système : une distinction visuelle qui aide à comprendre la portée de l'infection.
Pour les futurs administrateurs systèmes que vous êtes, c'est un excellent exemple de l'importance de sécuriser la chaîne de démarrage complète. D'ailleurs, le fait que ce malware ne fonctionne pas avec Secure Boot activé souligne l'importance des bonnes pratiques de sécurité.
On pourrait penser que Linux est immunisé contre ce type d'attaques, mais Bootkitty prouve le contraire. C'est un rappel que la sécurité doit être considérée à tous les niveaux, même les plus bas de l'architecture système.
Si on reprend un peu le schéma de Juanito, voici les étapes du processus d'infection :
Phase initiale
L'attaquant commence par déployer le bootkit et redémarre la machine. Le firmware UEFI exécute alors la partition système EFI, où commence réellement l'infection.
Chaîne de confiance compromise
Le schéma montre comment le malware s'insère dans la chaîne de validation du bootloader :
La partie la plus intéressante est la séquence de patches en bas du schéma :
Pour vous, étudiants en BTS SIO, ce schéma est une excellente ressource pédagogique pour comprendre concrètement comment un malware peut compromettre un système au niveau le plus bas.
Merci pour cet article Juanito
Ce qui est fascinant, c'est la façon dont le malware contourne les mécanismes de sécurité traditionnels en s'injectant très tôt dans le processus de boot. Le diagramme montre clairement les différentes étapes, depuis le firmware UEFI jusqu'à l'injection finale dans le processus init.
Un aspect technique crucial à noter est la manipulation du shim et du bootloader GRUB2, deux composants essentiels du démarrage sécurisé sur Linux. La partie en rose sur le schéma représente les composants malveillants, tandis que le bleu indique les éléments légitimes du système : une distinction visuelle qui aide à comprendre la portée de l'infection.
Pour les futurs administrateurs systèmes que vous êtes, c'est un excellent exemple de l'importance de sécuriser la chaîne de démarrage complète. D'ailleurs, le fait que ce malware ne fonctionne pas avec Secure Boot activé souligne l'importance des bonnes pratiques de sécurité.
On pourrait penser que Linux est immunisé contre ce type d'attaques, mais Bootkitty prouve le contraire. C'est un rappel que la sécurité doit être considérée à tous les niveaux, même les plus bas de l'architecture système.
Si on reprend un peu le schéma de Juanito, voici les étapes du processus d'infection :
Phase initiale
L'attaquant commence par déployer le bootkit et redémarre la machine. Le firmware UEFI exécute alors la partition système EFI, où commence réellement l'infection.
Chaîne de confiance compromise
Le schéma montre comment le malware s'insère dans la chaîne de validation du bootloader :
- Il intercepte d'abord le shim64.efi (composant Microsoft-signed, oui oui, sur Linux...)
- Il contourne la vérification de confiance via MokManager
- Il injecte un grub64.efi malveillant auto-signé
La partie la plus intéressante est la séquence de patches en bas du schéma :
- Le hook zstd_decompress_dctx pour la décompression du noyau
- La modification de mod_sig_check pour contourner les vérifications
- L'injection finale via /opt/injector.so dans le processus init
Pour vous, étudiants en BTS SIO, ce schéma est une excellente ressource pédagogique pour comprendre concrètement comment un malware peut compromettre un système au niveau le plus bas.
Merci pour cet article Juanito
[Système d'exploitation : Linux Mint 21.3] - [RAM : 15.34 GB]
[Processeur : 11th Gen Intel® Core i5-1135G7 @ 2.40GHz - 4 cœurs physiques]
[Disque dur : SSD 980 PRO 2TB(1,8T)]
[Carte graphique : Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01)]
[Processeur : 11th Gen Intel® Core i5-1135G7 @ 2.40GHz - 4 cœurs physiques]
[Disque dur : SSD 980 PRO 2TB(1,8T)]
[Carte graphique : Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01)]


![[-]](https://www.tisi-fr.com/board/images/collapse.png)