pixel_dreams - Fotolia

AtomBombing : un vecteur d’attaque qui paraît bien difficile à corriger

Ce nouveau vecteur s’appuie sur les briques fondamentales de Windows. Toutes les versions du système d’exploitation sont donc affectées par une vulnérabilité en l’état impossible à corriger.

Un vecteur d’attaque par injection de code, baptisé AtomBombing, vient d’être découvert, affectant toutes les versions du système d’exploitation de Microsoft depuis Windows 2000. Et l’éditeur pourrait ne pas être en mesure de créer une rustine.

AtomBombing doit sa découverte à Tal Liberman, directeur d’équipe de recherche chez EnSilo, jeune acteur de la détection et remédiation sur le point de terminaison (EDR). La technique consiste à détourner les Atom Tables, l’un des mécanismes fondamentaux de Windows.

Dans un billet de blog, Liberman explique que « ces tables sont fournies par le système d’exploitation pour permettre aux applications de stocker et accéder à des données. Ces tables peuvent également être utilisées pour partager des données entre application ». Et de résumer la découverte de ses équipes : « nous avons trouvé qu’un acteur malveillant peut écrire du code malicieux dans une atom table et forcer un programme légitime à récupérer ce code. Le programme légitime, contenant alors le code malicieux, peut être manipulé pour l’exécuter ».

Ce type d’injection de code pourrait être utilisé pour contourner les logiciels de sécurité, mener des attaques de type man-in-the-browser, accéder à des données chiffrées, ou encore réaliser des captures d’écran du système d’un utilisateur. Mais il y a des limites : « il n’y a pas là d’élévation de privilèges » et donc pas d’accès à des droits administrateur à partir d’un compte utilisateur simple. Pour autant, précise Liberman : « nous devons nous souvenir que cette méthode n’est uniquement utile lors de l’infection initiale. L’attaquant va obtenir une forme de persistance et rester bloqué dans un processus unique ».

J.P. Taggart, chercheur en sécurité chez Malwarebytes, estime qu’AtomBombing est très comparable aux opérations d’injection de code « réalisées la majorité des logiciels malveillants modernes ». Celle-ci est juste inédite. Mais il rappelle que « le but final est l’exécution de code avec des privilèges élevés. AtomBombing utilise des composants légitimes de Windows, comme un agent pathogène tentant de piéger le système immunitaire. Une fois que cela s’est produit, la partie est quasiment finie ».

Pour Bobby Kuzma, ingénieur systèmes chez Core Security, le plus inquiétant est la facilité avec laquelle les atom tables peuvent être détournées : « c’est assez simple à implémenter. A partir du démonstrateur, j’ai pu reproduire l’attaque en environ une demi-heure. Et je ne me considère pas comme un expert dans ce genre de technique. Les appels aux API qui rendent cette attaque possible n’exigent pas de privilèges élevés. Donc si un attaquant est capable de forcer l’exécution de code, il pourra profiter de ça pour injecter du code malicieux dans un processus de confiance ».

Pour Liberman, il est possible de se protéger de ce vecteur d’attaque en surveillant les appels aux API à la recherche d’éventuelles activités malicieuses, en s’appuyant par exemple sur un système de prévention d’intrusion sur l’hôte (HIPS) : « puisque la situation ne peut pas être corrigée, il n’y a pas de notion de patch pour cela. La réponse directe serait donc de surveiller les appels aux API ».

Pour Taggart, les produits de sécurité moderne devraient être capables de détecter et d’arrêter les processus détournés par surveillance applicative en temps réel : l’exploitation du vecteur AtomBombing ne correspondant pas à une activité courant, « ce serait identifié comme malicieux ».

Mais pour Kuzma, Microsoft pourrait bien ne pas être en mesurer de proposer de rustine, ou alors au prix d’effets collatéraux désastreux : « le mécanisme sous-jacent est fondamental pour l’architecture du noyau de Windows. Le supprimer ou modifier son comportement affecterait de nombreux logiciels de manières » difficiles à prédire. Alors selon lui, plutôt qu’un correctif, Microsoft pourrait « introduire une couche d’abstraction qui permettrait d’isoler les threads les uns des autres, ce qui est sage en général ».     

Adapté de l’anglais.

Pour approfondir sur Windows

Close