- Les malwares vérifient la présence de certains composants matériels, comme un ventilateur CPU, afin d’éviter de s’exécuter dans un environnement virtuel
- Les informations sur le ventilateur CPU peuvent être consultées via la classe Win32_Fan de WMI, et ces données sont stockées dans le SMBIOS
- Sous Xen, l’injection de données SMBIOS personnalisées nécessite un patch et une configuration spécifique, et il faut configurer à la fois les tables Cooling Device (Type 27) et Temperature Probe (Type 28)
- Avec QEMU/KVM, il est possible d’appliquer simplement un SMBIOS personnalisé via l’option -smbios, sans patch supplémentaire
- Cela permet de faire croire à la machine virtuelle qu’un ventilateur CPU est présent, afin de tenter de contourner la détection par le malware
Pourquoi faire cela ?
- Certains malwares vérifient la présence ou l’absence de matériel spécifique (par exemple un ventilateur CPU) pour déterminer s’ils s’exécutent dans un environnement virtuel
- Ils inspectent le matériel via des classes WMI comme
Win32_Fan, et si ces informations sont absentes, ils concluent qu’il s’agit d’une machine virtuelle et évitent de s’exécuter
- L’objectif est d’empêcher les analystes d’analyser le malware
- Il existe diverses classes WMI comme
Win32_CacheMemory ou Win32_VoltageProbe, mais cet article se concentre sur le ventilateur CPU
Comment un ordinateur sait-il qu’il a un ventilateur CPU ?
- L’ordinateur lit les informations SMBIOS pour détecter la présence d’un dispositif de refroidissement (ventilateur CPU)
- Les instances
Win32_Fan sont fournies par cimwin32.dll, et cette DLL lit les informations sur le ventilateur à partir des entrées SMBIOS de type 27
- Il serait aussi possible de faire du hooking de DLL, mais modifier directement le SMBIOS est une meilleure approche
SMBIOS Type 27
- Le SMBIOS type 27 correspond à "Cooling Device"
- L’utilitaire
dmidecode permet d’inspecter directement les données Cooling Device du SMBIOS
- Exemple :
- Type : Chip Fan
- Statut : OK
- Description : CPU Fan
- Vitesse nominale : 5600 rpm, etc.
Comment configurer des données SMBIOS personnalisées sous Xen
- Sous Xen, on peut utiliser l’option smbios_firmware du fichier de configuration du domaine pour fournir directement des données SMBIOS binaires
- Il faut créer un fichier
smbios.bin et y insérer les données Cooling Device (type 27)
- La taille de la structure SMBIOS (par exemple 24 octets) doit être préfixée sous forme d’entier 32 bits little-endian
Problème : limitation de remplacement des structures
- Xen limite le remplacement aux seules structures 0, 1, 2, 3, 11, 22, 39
- Le type 27 n’est pas autorisé par défaut, ce qui impose un patch du code source
- Un patch connexe a bien été proposé sur le forum des développeurs Xen, mais n’a pas été officiellement accepté (il faut donc appliquer le patch et recompiler)
Le Type 28 est également nécessaire
- Le Cooling Device (type 27) est lié au Temperature Probe (type 28)
- S’il n’existe pas d’entrée type 28 dans le SMBIOS, la classe
Win32_Fan ne s’affiche pas correctement
- Il faut récupérer les données type 28 du système hôte et les ajouter à
smbios.bin pour obtenir une détection correcte
Structure finale de smbios.bin
- Elle inclut à la fois les données de type 27 et de type 28
- Les informations de taille (little-endian) sont insérées avant chaque structure
- Exemple :
18 00 00 00 ... (type 27) ... 29 00 00 00 ... (type 28) ...
Application et vérification sous Xen
- Après avoir démarré la machine virtuelle Windows avec la commande de création du domaine, on vérifie via WMI que la classe
Win32_Fan est correctement reconnue
- L’affichage de
Description: Cooling Device et Status: OK confirme que le ventilateur CPU est détecté avec succès
Configuration des données SMBIOS sous QEMU/KVM
- Sous QEMU/KVM, l’option -smbios file=chemin permet de définir facilement un SMBIOS personnalisé
- Les données brutes sont utilisées telles quelles, sans information de taille de structure
- Il est également possible de réutiliser directement les données SMBIOS de l’hôte
Références
- Documentation du fichier de configuration de domaine Xen, notes de configuration de mcnewton, archive du patch Xen rejeté, System Management BIOS Reference, patch QEMU Anti Detection, etc.
1 commentaires
Commentaires sur Hacker News
Parmi les nouvelles méthodes anti-malware, on peut aussi acheter un PC à refroidissement passif, et il est également mentionné qu’utiliser un clavier russe est une astuce pour bloquer certains malwares frauduleux ; voir le lien associé
J’utilise effectivement un PC Linux Streacom FC8 Evo à refroidissement passif ainsi qu’un clavier russe, mais d’après la commande
dmidecode, les informations sur les dispositifs de refroidissement sont toujours présentes et le matériel de refroidissement est bien détecté ; on peut aussi vérifier les températures via les données des capteursMême avec un PC à refroidissement passif, la carte mère conserve en général des connecteurs pour ventilateurs, donc cela ne changerait probablement pas grand-chose même si rien n’y est réellement branché
Remarque disant qu’il vaudrait mieux éviter des expressions comme « smol pp », en soulignant que ce type de langage intègre une moquerie sur le corps
Dans ma ville, quelqu’un a une plaque personnalisée « SML PP », sans que je sache vraiment pourquoi
Avis selon lequel parler de « notre langue » reste vague quand cela vient simplement de quelqu’un dans les commentaires d’un blog qui dit « nous »
Avis selon lequel faire apparaître le système d’exploitation comme une machine virtuelle pourrait améliorer la sécurité et aider les chercheurs ; si l’on veut une approche non virtualisée, il faudrait obligatoirement obtenir une autorisation, et de cette façon les malwares pourraient aussi éviter de cibler les utilisateurs ordinaires afin d’échapper à l’analyse par les chercheurs ; au final, tout le monde y gagnerait sauf les auteurs de malware
Plutôt que de faire ressembler un système d’exploitation normal à une VM, l’idée serait au contraire de faire en sorte qu’une machine virtuelle ne se rende pas du tout compte qu’elle est virtualisée ; selon un avis, les systèmes lpars d’IBM fonctionnent de cette manière
Il est aussi mentionné que les entreprises d’anti-cheat y perdraient ; personnellement, je veux savoir clairement où tourne mon logiciel, mais comme beaucoup de joueurs multijoueur détestent encore plus les tricheurs que la triche elle-même, un changement semble peu réaliste
Dans le monde du développement mobile, ce cadre serait déjà une réalité
Je n’ai encore jamais vu, sur des cartes mères grand public, une description SMBIOS correspondant vraiment au matériel réel ; un malware qui vérifie cela pourrait échouer sur 50 % du matériel réel, mais si cela suffit à bloquer avec certitude 100 % des VM ou des débogueurs, cela reste intéressant du point de vue du malware, même en cas d’échec ; cependant, cette approche semblerait moins fiable qu’une vérification par mesure du temps
Ce décalage entre la description SMBIOS et le matériel réel est particulièrement fréquent sur les boîtiers chinois bas de gamme ; des valeurs non renseignées comme « to be filled in by OEM » apparaissent souvent lors du codage à partir d’images BIOS réelles, ce qui rend déjà la situation assez absurde à lui seul
Les malwares ont aussi beaucoup de bugs ; comme dans le passé, quand des erreurs dans le code réseau faisaient qu’un virus se propageait deux fois moins vite que prévu, un malware peut causer d’énormes dégâts sans pour autant infecter tous les appareils
Je me demande comment Linux détecte aujourd’hui les ventilateurs, si cela passe par ACPI ou EFI ; sur la plupart de mes machines, ventilateurs et capteurs sont reconnus correctement
Je me demande aussi si cette vérification SMBIOS est vraiment utilisée par des malwares réels, ou seulement dans des exemples créés par des chercheurs
Les astuces où un malware utilise des API pour compliquer l’analyse peuvent sembler amusantes, mais dans la plupart des cas ces appels API sont faciles à repérer en analyse statique et, si le binaire n’est pas obfusqué, cela peut même se retourner contre lui ; expérience partagée selon laquelle les programmes réellement motivés sont généralement distribués avec une signature d’une CA de confiance, donc leur comportement est assez facilement signalé comme suspect dans une analyse de sécurité ; à mes débuts, j’ai même travaillé à détecter ce type d’usage d’API avec des motifs regex, et c’était plutôt efficace pour repérer des malwares basiques diffusés à grande échelle
Ces derniers temps, les malwares signent aussi assez souvent leurs fichiers ; il ne faut plus s’attendre à ce que les acteurs du malware ne signent pas leurs binaires, d’autant que les certificats de signature de code volés sont courants et que Microsoft hésite à révoquer des certificats par crainte de casser les logiciels de clients existants ; les malwares exploitent aussi souvent des pilotes vulnérables pour s’infiltrer dans le kernel ; ainsi, un petit binaire suspect qui fait des appels WMI attire plus l’attention qu’un utilitaire d’overclocking très vulnérable qui effectue exactement les mêmes requêtes ; en pratique, l’objectif de cette méthode n’est pas tant d’éviter la détection que d’empêcher l’activation de la charge utile du malware sur le PC de l’analyste ; si le malware est détecté, la charge utile de second niveau n’est pas téléchargée et les actions de C&C susceptibles de lancer la véritable attaque restent suspendues
Du point de vue de la sécurité, suggestion selon laquelle il vaudrait peut-être mieux exécuter tous les logiciels dans des VM
Il est aussi ambigu pour un antivirus de déterminer qu’un logiciel est malveillant uniquement par analyse statique ; dans ce cas, on obtiendrait presque le même résultat en adoptant directement une approche par liste blanche où seuls les logiciels de confiance sont autorisés et tout le reste est considéré comme du malware
Réalité dénoncée dans laquelle des entreprises comme CrowdStrike font tourner officiellement des logiciels médiocres au niveau kernel, signés, capables d’effectuer tous les appels système sans que cela n’émeuve grand monde ; indépendamment de la présence d’une VM, on déploie simplement en production du code et des releases non testés, puis quand cela provoque des perturbations mondiales, des retards aériens ou des incidents sur des infrastructures critiques, la responsabilité reste limitée ; critique selon laquelle les entreprises légitimes peuvent causer plus de dégâts encore que des hackers ou des acteurs étatiques ; l’affaire de l’utilitaire xz est aussi décrite comme un incident de sécurité majeur comparable à SolarWinds ou ClownStrike
J’ai vu un ami du secteur infosec passer l’essentiel de son temps à rendre un honeypot de malware totalement semblable à du vrai matériel ; c’était impressionnant de le voir configurer avec un niveau de détail énorme toutes sortes d’appareils, depuis un thermostat sous Windows XP jusqu’à des contrôleurs PLC Siemens ou des postes bancaires
Cela me rappelle qu’au moment de configurer un Hackintosh, il fallait absolument choisir le bon SMBIOS ; beaucoup d’API PC relativement obscures ont été introduites au cours des dernières décennies, et elles servent souvent à tester dans quelle mesure les logiciels de virtualisation ou les malwares reflètent bien ces détails ; pour aller encore plus loin, il faudrait aussi une simulation de capteur de température variant dynamiquement en fonction de la charge CPU réelle
Selon Mitre ATT&CK T1497.001 (VM Detection), la vérification SMBIOS est un vecteur connu ; j’ai aussi fait l’essai et j’ai pu configurer l’alimentation comme
HotReplaceable=Yes,Status=OKafin qu’elle apparaisse comme celle d’un serveur bare metal à 5 000 $, avec la commande suivante :pip install dmigenpuisdmigen -o smbios.bin --type0 vendor="American Megatrends",version="F.1" --type1 manufacturer="Dell Inc.",product="PowerEdge T630" --type39 name="PSU1",location="Bay 1",status=3,hotreplaceable=1