auditing-uefi-firmware-with-chipsec

Auditer le firmware UEFI avec CHIPSEC

Utilisation autorisée uniquement : CHIPSEC charge un pilote noyau et lit/écrit des registres matériels de bas niveau, la mémoire flash SPI et le SMM. Exécutez-le uniquement sur des systèmes dont vous êtes propriétaire ou que vous êtes explicitement autorisé à évaluer, idéalement sur du matériel de test dédié. Une mauvaise utilisation (en particulier les modules d'écriture/modification) peut détruire une machine. N'exécutez jamais de modules capables d'écrire sur des systèmes de production.

Présentation

CHIPSEC est le framework d'évaluation de la sécurité de la plateforme open source créé par l'équipe de recherche sur les menaces avancées d'Intel. Il inspecte la configuration de sécurité de bas niveau du firmware et du matériel des plateformes x86 — la couche située sous le système d'exploitation où résident les bootkits et les implants de firmware. CHIPSEC charge un pilote noyau signé (Linux, Windows, ou peut fonctionner depuis l'environnement UEFI shell) pour lire et écrire les registres matériels, les registres spécifiques au modèle (MSR), l'espace de configuration PCI, la mémoire flash SPI et les variables UEFI, puis exécute une suite de tests automatisés qui vérifie si les verrous défensifs de la plateforme sont effectivement activés.

La menace à laquelle CHIPSEC répond est la technique MITRE ATT&CK T1542.001 — Pre-OS Boot: System Firmware : des adversaires qui modifient le firmware système (l'image BIOS/UEFI sur la mémoire flash SPI) pour obtenir un contrôle furtif, persistant et survivant au système d'exploitation. Les implants de firmware persistent après la réinstallation du système d'exploitation et le remplacement du disque et sont invisibles pour la plupart des EDR. La valeur de CHIPSEC réside dans la vérification des conditions préalables qui empêchent de tels implants : que la zone BIOS de la mémoire flash SPI est protégée en écriture (BIOS_CNTL BLE/SMM_BWP, plages protégées SPI), que le descripteur flash verrouille l'accès aux régions, que la SMRAM/SMRR est configurée et que les variables Secure Boot sont protégées. Il permet également de dumper la mémoire flash SPI pour une comparaison forensique hors ligne.

Sources : Projet Intel/CHIPSEC (https://github.com/chipsec/chipsec), documentation CHIPSEC (https://chipsec.github.io/).

Quand l'utiliser

• Évaluation de base de la sécurité du firmware d'une nouvelle plateforme ordinateur portable/serveur ou d'une image de flotte
• Vérification que la protection en écriture du BIOS et les verrous de la mémoire flash SPI sont correctement activés par le fabricant
• Forensique du firmware : dumper la mémoire flash SPI pour la comparer à une image de référence connue
• Validation de la protection des variables Secure Boot et de la protection du script de démarrage S3
• Recherche de preuves d'un implant de firmware ou d'une mauvaise configuration qui en permettrait un

Prérequis

• Accès physique ou administrateur/root à la plateforme x86 cible (Intel ou AMD)
• Linux (root) ou Windows (Administrateur), ou un environnement UEFI shell
• Capacité à charger un pilote noyau (Secure Boot peut nécessiter d'autoriser le pilote CHIPSEC, ou utiliser --no_driver pour des vérifications limitées)
• Python 3.8+ et un compilateur C/outils de construction pour le module noyau sur Linux
• Matériel de test dédié fortement recommandé

Installer CHIPSEC :

# Depuis PyPI
pip install chipsec

# Ou depuis les sources (construit le pilote d'aide noyau)
git clone https://github.com/chipsec/chipsec
cd chipsec
python setup.py install        # construit et installe, y compris le pilote Linux

# Vérifier
sudo chipsec_main --help
sudo chipsec_util --help

Objectifs

• Exécuter la suite complète de tests automatisés de sécurité de la plateforme et interpréter les résultats PASS/FAIL/WARNING
• Vérifier la protection en écriture du BIOS (BIOS_CNTL) et les plages protégées SPI
• Vérifier que le descripteur flash SPI verrouille l'accès en lecture/écriture des régions
• Vérifier les protections SMRAM/SMRR et des gestionnaires SMI
• Vérifier la protection des variables Secure Boot et la protection du script de démarrage S3
• Dumper la mémoire flash SPI et la décoder pour une analyse hors ligne
• Énumérer les variables UEFI et détecter les entrées anormales/inattendues

Cartographie MITRE ATT&CK

ID de technique	Nom	Tactique
T1542.001	Pre-OS Boot: System Firmware	Persistance / Défense Évasive

CHIPSEC défend contre T1542.001 en vérifiant que les contrôles empêchant la modification non autorisée du firmware sont activés. Un FAIL sur common.bios_wp (BIOS non protégé en écriture) ou chipsec.modules.common.spi_lock (descripteur flash déverrouillé) signifie qu'un attaquant disposant de privilèges OS pourrait réécrire la mémoire flash SPI et implanter un firmware persistant — exactement la condition préalable pour cette technique.

Flux de travail

Étape 1 : Exécuter la suite de tests automatisés complète

chipsec_main sans argument de module exécute toutes les vérifications de sécurité applicables pour la plateforme détectée et affiche un résumé des résultats PASS/FAIL/WARNING/INFORMATION.

sudo chipsec_main

# Sauvegarder la sortie lisible par machine pour le rapport/la comparaison
sudo chipsec_main -j results.json -x results.xml -l chipsec.log

Étape 2 : Exécuter les modules de protection du firmware de base individuellement

Le groupe de modules common contient les vérifications de sécurité indépendantes du fabricant. Exécutez le groupe ou des modules spécifiques :

# Exécuter tout le groupe common
sudo chipsec_main -m common

# Protection en écriture du BIOS : vérifie BIOS_CNTL BLE/SMM_BWP et les plages protégées SPI
sudo chipsec_main -m common.bios_wp

# Verrou du descripteur flash SPI (FLOCKDN) — les accès aux régions flash sont-ils verrouillés ?
sudo chipsec_main -m common.spi_lock

# Programmation SMRR — protège la SMRAM des attaques basées sur le cache
sudo chipsec_main -m common.smrr

# Protection en écriture du BIOS SMM
sudo chipsec_main -m common.smm

# Protection du script de démarrage S3 (contre les attaques de table de script de démarrage)
sudo chipsec_main -m common.uefi.s3bootscript

Étape 3 : Vérifier la protection des variables Secure Boot

# Vérifie que les variables UEFI Secure Boot sont correctement protégées
sudo chipsec_main -m common.secureboot.variables

# Pour tester activement la protection en écriture des variables (matériel de test UNIQUEMENT) :
sudo chipsec_main -m common.secureboot.variables -a modify

Étape 4 : Inspecter les permissions d'accès aux régions de la mémoire flash SPI

# Rapporter les régions de la mémoire flash SPI, le descripteur et les permissions d'accès
sudo chipsec_util spi info

# Vérifier le module de contrôle d'accès SPI
sudo chipsec_main -m common.spi_access

Étape 5 : Dumper la mémoire flash SPI pour une forensique hors ligne

Dumper la flash vous permet de décoder les volumes de firmware et de les comparer à une image OEM de référence.

# Dumper toute la mémoire flash SPI dans un fichier
sudo chipsec_util spi dump rom.bin

# Décoder l'image dumpée : extrait les volumes de firmware, fichiers, variables NVRAM, etc.
sudo chipsec_util decode rom.bin

Étape 6 : Énumérer et trier les variables UEFI

# Lister toutes les variables UEFI de l'interface runtime
sudo chipsec_util uefi var-list

# Lister les variables directement depuis l'image SPI (hors ligne)
sudo chipsec_util uefi var-find PK
sudo chipsec_util uefi var-read db <GUID> db.bin

# Décoder la structure du firmware UEFI
sudo chipsec_util uefi decode rom.bin

Étape 7 : Évaluation limitée sans pilote noyau

Lorsque le chargement du pilote est impossible (Secure Boot verrouillé), certaines vérifications peuvent encore être exécutées en lecture seule.

sudo chipsec_main -n            # --no_driver : ignorer les vérifications nécessitant le pilote
sudo chipsec_main -p <PLATEFORME> # forcer le code de plateforme si la détection automatique échoue

Étape 8 : Trier les résultats et rapporter

• FAIL sur bios_wp / spi_lock → le firmware est réinscriptible depuis l'OS : risque élevé pour T1542.001.
• FAIL sur secureboot.variables → la politique Secure Boot peut être falsifiée.
• Comparez le spi dump avec l'image de référence du fabricant (hacher les volumes de firmware) pour détecter des modifications non autorisées.
• Enregistrez la plateforme, la version du BIOS et chaque FAIL/WARNING avec les valeurs de registre pertinentes pour le rapport.

Outils et ressources

Outil	Objectif	Source
chipsec_main	Suite de tests automatisés de sécurité de la plateforme	https://github.com/chipsec/chipsec
chipsec_util	Accès manuel au matériel/firmware (spi, uefi, decode)	https://chipsec.github.io/
UEFITool	Analyse GUI/CLI des images UEFI dumpées	https://github.com/LongSoft/UEFITool
Binarly fwhunt	Règles de chasse aux vulnérabilités/implants de firmware	https://github.com/binarly-io/fwhunt-scan
Guide Secure Boot UEFI de la NSA	Référence de durcissement	https://media.defense.gov/

Référence des modules principaux

Module	Vérifications
common.bios_wp	BIOS_CNTL BLE / SMM_BWP et plages protégées SPI
common.spi_lock	Verrou FLOCKDN du descripteur flash SPI
common.spi_access	Permissions de lecture/écriture des régions de la mémoire flash SPI
common.smrr	Programmation des registres de plage de gestion système
common.smm	Protection en écriture du BIOS SMM
common.secureboot.variables	Protection des variables Secure Boot
common.uefi.s3bootscript	Protection du script de démarrage S3

Critères de validation

• CHIPSEC installé et le pilote se charge (ou -n documenté si ce n'est pas le cas)
• Suite complète chipsec_main exécutée avec sortie JSON/XML/log sauvegardée
• Résultat de common.bios_wp interprété (état de la protection en écriture)
• Résultat de common.spi_lock / spi_access interprété (verrou du descripteur)
• Résultats des modules SMRR/SMM enregistrés
• Protection des variables Secure Boot vérifiée
• Mémoire flash SPI dumpée et décodée pour analyse hors ligne
• Variables UEFI énumérées et triées
• Tous les résultats FAIL/WARNING documentés avec la plateforme/version du BIOS
• Modules d'écriture/modification NON exécutés sur du matériel de production