Les attaques de firmware représentent un risque substantiel pour la chaîne logistique logicielle, comme l’a souligné la célèbre porte dérobée dans le firmware UEFI de Gigabyte. Les vulnérabilités du firmware sont souvent plus difficiles à détecter, se situent sous le radar de la plupart des solutions de sécurité des terminaux, et peuvent persister même après une réinstallation du système d'exploitation. Dans cet article de blog technique, vous apprendrez comment fonctionnent les portes dérobées du firmware, pourquoi le cas de Gigabyte a choqué l'industrie, comment les outils de pointe dévoilent ces menaces, et ce que les praticiens de la sécurité peuvent faire pour se défendre contre ces attaques avancées. Nous couvrirons des concepts allant de débutant à avancé, disséquerons des cas concrets et montrerons des techniques d'analyse médicolégale — avec des exemples pratiques de code Bash et Python pour le balayage et l'automatisation.
Le firmware est la couche la plus basse de logiciels qui interagit directement avec le matériel — typiquement stockée sur des puces mémoire flash réinscriptibles situées sur des cartes mères, des disques durs, des cartes réseau et plus encore. En raison de leur base privilégiée et de leur persistance, les portes dérobées du firmware présentent un risque immense. Une seule mise à jour de firmware compromise peut créer un canal secret, contourner les défenses au niveau du système d'exploitation, et maintenir une persistance furtive même après le nettoyage de tous les disques.
Des cas récents très médiatisés — en particulier la porte dérobée dans le firmware UEFI des cartes mères Gigabyte — ont démontré que des fournisseurs de confiance peuvent involontairement expédier un firmware vulnérable ou malveillant, mettant des millions de systèmes en danger. Cette menace souligne à la fois les défis auxquels est confrontée la sécurité moderne de la chaîne logistique et le besoin d'une analyse forensique robuste du firmware.
Le firmware est essentiel pour l'initialisation des plateformes informatiques modernes. Non seulement il initialise le matériel au démarrage, mais il peut aussi se mettre à jour de manière sécurisée via des paquets signés par le fournisseur. Pourtant, l'omniprésence et la complexité du firmware présentent d'importants risques :
La chaîne logistique est le réseau de fournisseurs, développeurs, et intégrateurs qui ensemble livrent le dispositif fini. Si un maillon introduit une vulnérabilité — que ce soit par accident, par malware, ou par acteur étatique — chaque appareil en aval peut être compromis.
En mai 2023, des chercheurs chez Eclypsium et ReversingLabs ont publié des découvertes choquantes : plus de 270 modèles de cartes mères Gigabyte ont été livrés avec une porte dérobée cachée pouvant être exploitée à distance.
La porte dérobée de Gigabyte provient d'un binaire de firmware UEFI — généralement situé dans une puce SPI sur la carte mère — qui contenait la logique suivante :
GigabyteUpdateService.exe ou similaire, récupérait le code depuis les serveurs cloud de Gigabyte via HTTP (non chiffré !) et l'exécutait sur l'hôte, avec les privilèges SYSTEM.Principalement, tout cela se produisait sans le consentement explicite de l'utilisateur ou du système d'exploitation, et le point de terminaison de mise à jour utilisait un canal HTTP en clair, violant les hypothèses de sécurité modernes.
+-----------------------+
| Firmware UEFI |----> Installe
+-----------------------+ (au démarrage de l'OS)
|
v
+--------------------------+
| GigabyteUpdateService.exe|
+--------------------------+
|
v
Récupère des Mises à Jour via HTTP ---> Exécute en tant que SYSTEM
La porte dérobée de Gigabyte montre la fragilité de nos chaînes logistiques logicielles :
La détection et la dissection des implants de firmware exigent une analyse forensique spécialisée, différente de l'analyse typique des logiciels malveillants basés sur les systèmes d'exploitation. Explorons une analyse pratique, des différences via l'ingénierie inverse d'ELF.
En fonction de l'appareil, extrayez le firmware à l'aide d'outils fournisseurs ou d'utilitaires bas-niveau comme flashrom :
# Sur Linux, avec autorisation root et matériel compatible
sudo flashrom -p internal -r gigabyte_spi_dump.bin
Pour trouver des modifications malveillantes, comparez les images de firmware extraites :
# Différence au niveau binaire
cmp -l firmware_v1.bin firmware_v2.bin
# À l'aide de hd, xxd, ou radare2 pour les différences visuelles
xxd firmware_v1.bin > f1.hex
xxd firmware_v2.bin > f2.hex
diff f1.hex f2.hex
Utilisez binwalk pour extraire les sections de firmware :
# Extraire les modules UEFI et les entités compressées
binwalk -e gigabyte_spi_dump.bin
# Lister les fichiers extraits et analyser les sections PE/ELF :
ls _gigabyte_spi_dump.bin.extracted/
file _gigabyte_spi_dump.bin.extracted/*
Les attaquants ajoutent souvent ou modifient des modules. Ainsi, en extrayant les horodatages de construction et en alignant les événements de la chaîne logistique, les équipes d'IR peuvent placer les changements suspects dans le contexte organisationnel.
import pefile
pe = pefile.PE("GigabyteUpdateService.exe")
print("Compile time:", pe.FILE_HEADER.TimeDateStamp)
Comparez les fichiers manifestes ou les métadonnées des capsules UEFI :
strings firmware_old.bin | grep -i "Build" > old_buildinfo.txt
strings firmware_new.bin | grep -i "Build" > new_buildinfo.txt
diff old_buildinfo.txt new_buildinfo.txt
De nombreux composants de firmware UEFI sont des binaires PE32 standard (Windows) ou ELF (Linux).
find _extracted_firmware/ -type f | xargs file | grep -E "ELF|PE32"
Par exemple, inspecter un binaire suspect :
radare2 -A suspicious_module.efi
# ou
ghidraRun
# Puis charger et décompiler suspicious_module.efi
strings suspicious_module.efi | grep -i -E "http|socket|connect"
Une logique de réseau suspecte dans un contexte de firmware est un signal d'alarme.
Écrivez une règle YARA pour détecter les IP durcies des C2 ou les points de terminaison HTTP :
rule GigabyteUEFI_HTTP {
strings:
$http = "http://mb.download.gigabyte.com"
condition:
$http
}
Balayer pour déceler des résultats :
yara GigabyteUEFI_HTTP.yara _extracted_firmware/
L'incident BombShell, découvert sur les appareils Framework, montre une autre porte dérobée de la chaîne logistique — cette fois sur un pilote UEFI signé. Le pilote a été envoyé directement aux clients finaux, ses signatures donnant un faux sentiment de légitimité.
Les équipes de sécurité s'appuient de plus en plus sur des scanners spécialisés pour l'UEFI/BIOS, tels que :
Exemple : Balayage avec CHIPSEC
# Installer les dépendances
sudo apt install python3-pip build-essential
pip3 install chipsec
# Exécuter les vérifications de base
sudo chipsec_util uefi decode
sudo chipsec_main -m tools.uefi.find_guids
Si les journaux Eclypsium ou EDR révèlent une persistance suspecte, interprétez les résultats de manière programmatique :
# Exemple de résultats
cat eclypsium_scan.log | grep -i suspicious
import re
with open("chipsec_results.txt") as f:
for line in f:
if "suspicious" in line.lower() or re.search(r"http://", line):
print("ALERT:", line.strip())
ls -l /Windows/System32/drivers/ | grep -v "Microsoft"
title: Detect Unauthorized Firmware Updaters
logsource:
product: windows
service: system
detection:
selection:
Image|contains: 'GigabyteUpdateService.exe'
ParentImage|contains: 'wininit.exe'
condition: selection
level: high
Formuler une stratégie robuste contre les menaces de la chaîne logistique au niveau du firmware nécessite une approche à plusieurs volets.
Les portes dérobées du firmware — comme celles vues dans les incidents Gigabyte et BombShell — représentent une nouvelle frontière pour les attaquants autant que pour les défenseurs. Étant donné que le firmware comble invisiblement le fossé entre le matériel et le logiciel, même les organisations les plus soucieuses de la sécurité sont vulnérables si la chaîne logistique est compromise.
Les leçons clés apprises :
En maîtrisant à la fois les techniques d'analyse du firmware et en adoptant une culture de gestion de la chaîne logistique axée sur la sécurité, les organisations peuvent contrer ces menaces émergentes et réduire l'impact potentiel des futures portes dérobées.
Vous souhaitez voir plus de démonstrations pratiques sur l'analyse médicolégale du firmware ou la sécurité de la chaîne logistique ? Laissez un commentaire ou connectez-vous sur Twitter !
Si vous avez trouvé ce contenu utile, imaginez ce que vous pourriez accomplir avec notre programme de formation élite complet de 47 semaines. Rejoignez plus de 1 200 étudiants qui ont transformé leur carrière grâce aux techniques de l'Unité 8200.