I Learned

Vérifier l’intégrité d'un système d'exploitation grâce à Secure Boot.

· · ·

La sécurité d’un système dépends de beaucoup de facteur, un des facteurs important est de pouvoir vérifier l’intégrité du système démarré, en effet sans cette vérification un attaquant pourrait sans trop de difficultés modifier les fichiers de démarrage pour ajouter un malware. Cet article se concentrera sur les machines de bureaux.

Pour bien comprendre comment peuvent être effectuées des attaques pendant le boot il est important de comprendre le fonctionnement du démarrage en mode BIOS, et son remplaçant l’UEFI.

BIOS

Le démarrage en BIOS s’appuie sur une table des partitions en MBR (master boot record), pour démarrer le bios va exécuter du code contenu dans la table des partitions, ce code s’occupe de passer la main au bootloader qui va s’occuper de lancer le système. Un problème assez flagrant apparait déjà, du code peut être directement inséré dans cette partie, aucune vérification n’est effectuée par le BIOS. Un attaquant pourrait aussi attaquer le bootloader qui ne peut pas être chiffré.

Sous Linux (nous verrons le fonctionnement de Windows un peu plus loin) le bootloader le plus courant est grub, il insère dans le MBR de quoi charger son code complet qui est contenu dans /boot , la plupart des bootloader sous linux fonctionnent sur le même principe.

Un système non chiffré

Pour éviter une modification du système on pourrait chiffrer le partition root (aussi appelé Userland) et faire un /boot à part (le bootloader ne peut pas être chiffré), un problème se pose alors, l’initramfs et le kernel sont toujours en clair.

Un système chiffré avec seulement le userland de chiffré

Grub (et c’est à ma connaissance le seul) permet de déchiffrer le partition boot, pour garder l’initramfs et le kernel chiffré. Mais grub en lui même est toujours modifiable, même chose pour le code exécuté directement dans le MBR.

Un système chiffré avec le userland et le kernel de chiffré

En plus de ne pas être totalement sécurisé, avec cette méthodes la phrase de passe doit être tapée deux fois, une fois pour lire l’initramfs et une autre fois pour déchiffrer la partition root. (grub ne la retient pas).

Une solution possible serait de signer les différents élément du boot, le problème est qu’en BIOS aucun mécanisme pour la vérification de signature existe.

Avec un BIOS nous n’avons pas de possibilité de sécuriser entièrement un système Linux.

Pour Windows, le concept est très proche, le BIOS va exécuter le code dans le MBR, ce code va enclencher le bootloader de Windows qui, depuis Windows Vista, est bootmgr, chiffrer son disque pose le même soucis que sous Linux, le bootloader restera en clair.

UEFI

Avec UEFI on se passe de MBR au profit de GPT qui apporte un certain nombre d’avantages. Le processus de boot ne se passe plus par un code exécutable dans la partie MBR, ce code est contenu dans une partition en FAT32 (ou FAT16), ce qui permet de ne plus être aussi limité en taille, la partie dédié au code de démarrage dans MBR n’est que de 446 bytes. UEFI apporte aussi une évolution majeure pour la sécurité : Secure Boot, c’est un moyen de vérifier l’intégrité via une signature du fichier EFI. Un fichier EFI est un exécutable lancé par l’UEFI, on pourrait le comparer aux ELF de Linux, ou aux exe de Windows.

Lorsque qu’un pc avec Secure Boot démarre, il vérifie le binaire EFI, pour voir si la signature corresponds à une clé de “confiance” et si la signature n’est pas dans dans la liste des clés à refuser.

L’UEFI se base sur des variables pour les clés, vous pouvez les voir depuis Linux via l’utilitaire “efi-readvars”, ce qui sur ma machine donne :

Variable PK, length 823
PK: List 0, type X509
    Signature 0, size 795, owner 5b2a4205-8ee1-404d-a357-45629f968019
        Subject:
            CN=Ramle PK
        Issuer:
            CN=Ramle PK
Variable KEK, length 825
KEK: List 0, type X509
    Signature 0, size 797, owner 5b2a4205-8ee1-404d-a357-45629f968019
        Subject:
            CN=Ramle KEK
        Issuer:
            CN=Ramle KEK
Variable db, length 823
db: List 0, type X509
    Signature 0, size 795, owner 5b2a4205-8ee1-404d-a357-45629f968019
        Subject:
            CN=Ramle DB
        Issuer:
            CN=Ramle DB
Variable dbx has no entries
Variable MokList has no entries

Regardons de plus près chaque variable :

La chaine de confiance de Secure Boot

Ces variables sont bien sur modifiable sur la plupart des pc, ce qui permet de gérer sa propre PKI (public key infrastructure).

Si on veut un réel contrôle il faut gérer soit même ses clés, sous Linux c’est possible sans trop de difficultés, FreeBSD et OpenBSD semblent supporter aussi (je n’ai pas eu l’occasion de tester) et sous Windows on peut soit utiliser les clés de Microsoft ou utiliser ses propres clés ce qui semble en théorie possible.

J’espère que cette article vous aura plus, je pense prochainement faire un petit guide pour la gestion de Secure Boot sous Linux, je vous laisse donc surveiller les sorties 👀. On se retrouve après demain pour un article sur MQTT

Articles Recommandés :

RSS · Twitter · Mastodon