Un Rootkit BIOS qui persiste au redémarrage, au formatage, à la réinstallation, au changement de disque et au flashage

Par Xavier Poli, secuobs.com
Le 24/03/2009

---

Résumé : Une technique a été présentée à CanSecWest pour permettre à un Rootkit BIOS de persister au redémarrage, au formatage, à la réinstallation, au changement de disque et au flashage. Les impacts démontrés sont l'injection de code sous Microsoft Windows et l'accès à /etc/shadow sous OpenBSD. - Lire l'article



Face à des protections plus performantes pour les modes utilisateur ( Ring 0 - lien ) et noyau (Ring 3), les chercheurs ont tendance à se reporter vers des portes d'entrée plus exotiques, les avancées sur SMM ( lien & lien ) en attestent. Même en appliquant tous les correctifs du monde aux systèmes et aux applications, les plateformes resteront faillibles tant que les niveaux les plus bas de gestion matérielle se feront involontairement les complices d'exploitations silencieuses.

C'est en résumé le message délivré par deux chercheurs argentins de Core Security ( lien ) lors de leur présentation ( lien ) à CanSecWest ( lien ). Une méthode d'infection des micro-logiciels ( Firmware - lien ) BIOS ( lien ) y a été démontrée. Elle permet un contrôle total via des injections récurrentes de micro-codes pouvant survivre aux redémarrages, aux formatages, à la réinstallation et même aux flashages ( lien ) ou aux changements de disque dur.

Ces recherches sont dans la continuité de celles de John Heasman ( NGSS - lien ) sur les Rootkits BIOS ( lien ) utilisant les fonctions ACPI ( Advanced Configuration and Power Interface - lien ) et sur les Rootkits placés ( lien ) dans l'espace flashable d'adressage mémoire EEPROM ( Electrically-erasable programmable read-only memory - lien ) des cartes graphiques utilisant le bus PCI ( Peripheral Component Interconnect - lien ).

Nécessitant l'utilisation d'une machine déjà compromise et des droits de super-utilisateur, ou un accès physique, le champ d'application de cette nouvelle attaque reste plus ou moins limité. Sa réussite confère néanmoins aux codes malicieux injectés une furtivité accrue et une forte capacité de résilience ( lien ) vis-à-vis des solutions défensives pour les espaces utilisateur et noyau. Elle revêt de plus un contexte d'exploitation totalement indépendant du système de la cible, Alfredo Ortega et Anibal Sacco affirmant en ce sens qu'il a été facile de placer ensuite leur code là où il le voulait sans pour autant utiliser une quelconque vulnérabilité additionnelle de ces systèmes.

De nombreuses méthodes existent pour modifier un BIOS, des programmes de mises à jour sous Microsoft Windows et MS-DOS en passant par des ActiveX ( lien ) et l'utilitaire FlashROM du projet GPL CoreBoot ( lien ). Le fait que le BIOS puisse être réinfecté de façon semi-persistante motive les deux chercheurs à travailler encore plus activement à l'élaboration d'un Rootkits BIOS ultime et de Rootkits virtualisés implémentant l'attaque démontrée. Un code permettant de désinstaller/désactiver les solutions antivirales en présence sur le système ciblé aurait déjà été développé, des évolutions ne devraient pas tarder à voir le jour.

Différents mécanismes de vérification d'intégrité sont offerts pour le BIOS, toutes modifications entrainant alors une incapacité à démarrer. Cela peut être contourné en extrayant le BIOS via FlashROM pour modifier le code et compenser la différence des sommes de contrôle ( Checksum - lien ) avant de flasher l'original avec la version modifiée et conforme à ces vérifications. Les modifications peuvent être opérées à différents endroits, l'adresse mémoire de la première instruction exécutée, celle de la dernière utilisée avant le chargement et l'exécution du système d'exploitation, ou bien encore en insérant un module ROM malicieux exécuté lors du POST ( Power On Self Test - lien ).

Pour l'injection de code réalisée depuis le système via un script Python ( lien ), les chercheurs se sont ici concentrés sur la routine du BIOS, facilement identifiable par recherche de motifs, qui permet de décompresser les modules LZH ( Pinczakko's Guide to Award BIOS Reverse Engineering - lien ). C'est un choix judicieux puisque cette fonction n'est pas nativement compressée et qu'elle n'est pas amenée à être modifiée selon le type et la marque du BIOS, tout en étant appelée à de nombreuses reprises lors de l'amorçage préliminaire.

Cette technique a permis de démontrer l'injection de code arbitraire dans un système d'exploitation de type Microsoft Windows, mais également la modification du fichier de mots de passe « /etc/shadow » ( lien ) sous les systèmes OpenBSD ( lien ). A noter que lors des démonstrations, ces systèmes étaient virtualisés via une solution VMware ( lien ) proposant son propre BIOS de type Phoenix-Award ( lien ) et dont la compromission peut permettre dans ce contexte d'exploiter de multiples machines virtuelles.

Source : Zero Day ( lien ) & Governmentsecurity.org/Threatpost ( lien )