Sécurité du processus de boot

Niveau :
Résumé :

Maintenant que nous connaissons le processus de boot, si on examinait ce processus d'un point de vue de la sécurité !

Lorsqu'on parle de sécurité, il faut d'abord savoir dans quel cas on se positionne et de quoi on cherche à se prémunir. Ici, je considère que le système lui-même est sécurisé. Je suppose que l'attaquant est devant la machine et cherche un accès root.

On considère que chaque élément est sécurisé pour ce qui est de ses propres fonctionnalités, ce qui veut dire que si le bootloader est protégé par mot de passe, il n'y a pas de faille dans le bootloader lui-même permettant d'outrepasser ce mot de passe. Nous nous attacherons donc à chercher ce qui peut être détourné dans le flux d'exécution en entrée et en sortie de chaque élément.

Je vais commencer par la fin, du plus facile au plus difficile.

rc

Rc est lancé par init et ne prend ses paramètres que de init. Ceux-ci sont fixés en dur dans /etc/inittab. Son démarrage ne peut donc être détourné que d'une façon : par modification du contenu du disque. GoTo partition /

Parmi ces paramètres il y a le paramètre 1 qui lance rc dans le runlevel 1, ce qui dans la plupart des cas se termine par un sulogin. Ouf on est protégé par le mot de passe root.

Mais vérifiez bien, dans certains cas il se termine par un simple shell et donc réussir à passer un tel paramètre permettrait à l'attaquant un accès root à votre machine.

Pour passer 1 en paramètre GoTo init

init

Init est lancé par le noyau après lecture de la racine. Il lit sa configuration dans /etc/inittab. Il peut donc être détourné par modification du disque : GoTo partition /

Parmi les paramètres qu'on peut lui passer il y a 1 et S, 1 renvoie au problème ci-dessus et S lance lui-même sulogin, donc même vérification. Ces paramètres viennent du noyau : GoTo noyau

Init est un binaire choisi par le noyau, or il est possible de dire au noyau de changer d'init à travers le bon paramètre. Par exemple, je peux ajouter init=/bin/sh aux paramètres du noyau pour qu'init ne soit jamais lancé qu'un shell apparaisse à sa place. Ça y est je suis root ! C'est d'ailleurs la technique pour changer de mot de passe root lorsque vous l'avez perdu.

Pour changer d'init GoTo noyau.

Init peut aussi être lancé par initrd, il souffre dans ce cas exactement des mêmes problèmes que lorsqu'il est lancé par le noyau : GoTo initrd.

Note upstart, initrdng... :
Il se peut (et ca va être de plus en plus courant) qu'init ou rc soit remplacé par autre chose, type upstart. Dans ce cas seul les noms des paramètres et le format des fichiers change. Mais les impacts sont exactement les mêmes.

Initrd

Initrd prend ses paramètres de la ligne de commande du noyau, mais généralement (il y a plein d'initrd différents) ils sont passés tels quels à init.

D'autre part initrd peut être chargé par 2 moyens, j'ai décrit le bootloader comme un moyen mais le noyau peut aussi charger lui-même l'initrd si on lui demande (avec le paramètre initrd=). On peut donc détourner son chargement par plusieurs moyens : GoTo noyau, GoTo bootloader.

Il est aussi possible de modifier directement l'initrd, par exemple lors d'une réinstallation distante. Celui-ci contenant tout ce qu'on veut, modifier son contenu permet de lancer n'importe que processus ... GoTo partition /boot

Noyau

Le noyau en lui-même ne vous rend pas root mais rien ne vous empêche d'y faire une modification pour qu'il vous fasse root une fois le système chargé.

Le noyau est chargé depuis la partition /boot donc une modification de cette partition et c'est gagné : GoTo partition /boot

Le noyau prend ses paramètres du bootloader, parmi ceux-ci de nombreux paramètres permettent de détourner le système : root= init= initrd= et surement bien d'autres. GoTo bootloader

Partition /

Jusque là, nous n'avons évoqué que les risques mais pas encore de faille. C'est parce qu'aucune interférence de l'utilisateur n'a été possible, tout est automatisé. Mais ça va changer.

Lors du montage de la racine, il y a une interférence possible : le disque contenant / peut avoir été modifié, voire remplacé, pour modifier /etc/inittab, /sbin/init, /etc/init.d/rc ou toute autre chose.

Pour éviter ce problème, il y a deux possibilités :

• mettre un cadenas sur la machine pour garantir l'intégrité physique du disque
• chiffrer le disque

Dans le premier cas, le problème est remonté aux autres couches pour garantir l'intégrité logique et éviter qu'on réussisse à booter sur un autre OS pour modifier le disque. GoTo bootloader.

Dans le deuxième cas, le chiffrement (par exemple avec luks ou truecrypt) doit être assuré par une clé.

• si cette clé est sur la machine et son mot de passe aussi : elle est dans un élément de boot (initrd, partition de boot ...) on reporte le problème GoTo partition /boot
• si cette clé ou son mot de passe n'est pas sur la machine (carte à puce, mot de passe, clé usb ...) alors il y a besoin d'un personne présente à chaque boot ...
• le chiffrement peut aussi être assuré par une puce (TPM) qui ne quitte pas la machine, auquel cas, on garanti que le disque ne quittera pas la machine pour être lu ou modifié (mais pas de garantie contre le formatage), par contre il peut être lu sur place par un autre OS.

Dans tous les cas, seul le démarrage post-noyau est préservé, pour le reste GoTo bootloader.

bootloader

Le bootloader est la source de tous les maux. C'est en effet par lui que l'utilisateur a tout loisir de modifier des paramètres de démarrage.

Le bootloader passe ses paramètres au noyau qui les passe à l'initrd qui les passe à init. Ces paramètres viennent de la configuration du bootloader mais pour un certain nombre de bootloader ils peuvent être directement demandés à l'utilisateur. Dans ce cas il y a moyen d'interdire cette modification à travers un mot de passe. Par exemple grub.

Le bootloader charge sa configuration puis choisit et charge le noyau et l'initrd, tout ceci depuis la partition de boot. Dans tous les cas il doit lire une version non chiffrée, ce qui interdit le chiffrement de cette partition.

Pire, le bootloader est incapable de savoir que le disque n'a pas changé. Donc un simple ajout de disque permet de le faire booter sur un noyau/initrd différent.

Vous ne pouvez presque rien y faire: GoTo partition /boot.

Bon en supposant qu'il n'y a pas de problème, le bootloader est chargé par le bios, il peut donc être détourné : GoTo Bios.

Partition /boot

J'inclue dans la définition de la partition de boot tout ce qui contient la configuration du bootloader, le bootloader lui-même, le noyau et l'initrd, même si ils peuvent être physiquement à des endroits différents. Protéger la partition de boot est très complexe, car tout doit être accessible en clair depuis des outils ayant des fonctionnalités très restreintes.

Les possibilités sont :

• sceau physique sur la machine
• TPM

Mettre un gros cadenas sur la machine permet d'éviter une lecture ou une modification de /boot. Mais il on ne se prémunit pas d'une personne un peu patiente avec un accès complet à la machine.

La dernière solution, complexe à mettre en place et sans garantie absolue est d'utiliser une puce TPM qui va vérifier (mesurer) le bootloader à chaque étape de son chargement, puis vérifier chaque élément que le bootloader charge avant de lancer le noyau.

Bios

Le bios s'exécute tout seul depuis lui-même, il se charge puis lis ses paramètres. Parmi ces paramètres il y a la séquence de boot, qui peut elle-même être modifiée par l'utilisateur.

Il est donc possible, voire facile de dire au bios de booter sur une clé USB et de prendre le contrôle du disque et donc de la machine. Pour éviter ce cas de figure il est possible de mettre un mot de passe au bios. Ainsi on est sûr de booter sur le bon disque, mais seulement s'il y a un cadenas sur la machine puisque le bios ne vérifie pas que le disque n'a pas été remplacé.

GoTo Matériel.

Matériel

Il est possible de changer le bios lui-même. Et ce de plusieurs façons. Si c'est un flash, il est possible de le remplacer logiciellement, si c'est une rom il est possible de la remplacer matériellement.

Et enfin le plus simple pour remplacer le bios est de remplacer la carte mère. Hop ni vu ni connu ...

Pour se protéger de cela ? Le cadenas ... ou la puce TPM, dont la mise en place est toujours très complexe et non garantie.

Conclusion

Résumons-nous car cet article commence à être un peu long. Différencions les cas dont on veut se protéger.

Accès réseau

Si l'attaquant n'a accès à la machine que par le réseau, on est tranquille pour ce qui est de la séquence de boot : No problemo.

Accès KVM

Si l'attaquant n'a accès à la machine que par KVM (pas de possibilité de toucher aux périphériques). Mettre un mot de passe sur le bootloader, le bios et vérifier que le mode rescue demande le mot de passe root devrait suffire. En effet les seul moyen d'attaque sont les paramètres de lancement du système.

N'oubliez pas que le simple accès KVM permet des choses comme le reboot via les magic keys

Accès cadenassé

Si on suppose que l'attaquant peut apporter un CD ou une clé usb sur le système, paramétrer le bios pour booter sur un disque et y mettre un mot de passe est un moyen simple à mettre en place pour éviter le boot sur un autre système.

Mais attention, il ne faut pas que l'utilisateur puisse ouvrir la machine, il pourrait réinitialiser le bios.

Accès au disque sans droit de boot

A partir du moment où l'attaquant a accès au disque c'est presque foutu. Si l'attaquant n'est pas une personne autorisée à booter la machine, il est possible de chiffrer le disque avec une clé qui ne se trouve pas sur le disque. Il faudra alors la rentrer à chaque démarrage. L'attaquant ne disposant pas de cette clé, il me pourra ni lire ni modifier les données où le système. Mais c'est déjà une solution assez contraignante.

D'autant plus que pour être complète cette solution doit garantir le noyau et l'éventuel initrd sur lequel on boote et donc vérifier soi même à chaque boot qu'on utilise une partition de boot non modifiée.

On en arrive au dernier cas ...

Accès complet

Lorsque l'attaquant a un accès complet à la machine, il n'existe qu'un moyen de se protéger (et encore) : la puce TPM.

Elle permet de :

• protéger le bios d'un changement
• protéger le bootloader d'un changement
• protéger le noyau d'un changement
• protéger le contenu du disque d'un changement

Mais tout cela est compliqué et nécessiterait un autre article que je ne suis pas encore prêt à faire, je n'ai même pas de puce TPM chez moi.

PS : Notez une dernière chose que je n'ai pas abordé, le chiffrement des données. Le chiffrement du disque contenant les données (/home et /srv selon vos besoins) devient obligatoire dès qu'on prévoit qu'il y aura un accès physique. Il doit de préférence se faire avec un moyen propre à l'utilisateur (mot de passe / clé / carte à puce ...) pour éviter les attaques à travers le boot de l'OS.

PPS : Considérez qu'a partir du moment où quelqu'un a un accès physique à votre machine c'est mort.

PPPS : Sauf si votre machine est une carte à puce.

PPPPS : Et encore ...

Bon courage !

Tags:Matériel, planet-libre, Savoir-faire, Sécurité, Théorie