Discussion :

[Stéphane le calme]

Des chercheurs ont découvert un levier permettant une injection de code sur toutes les versions de Windows
et soutiennent qu'il n'est pas possible de parler de correctif

Des chercheurs d’Ensilo ont découvert un levier qui permet de contourner les mécanismes de sécurité installés sur Windows et d’injecter du code malicieux. Ils l'ont baptisé AtomBombing, nom qui fait référence au mécanisme sous-jacent de Windows qui est exploité. Les chercheurs préviennent que toutes les versions de Windows sont affectées, y compris Windows 10. « Malheureusement, ce problème ne peut pas être résolu étant donné qu’elle ne repose pas sur un code défectueux, mais plutôt sur la façon dont ces mécanismes du système d'exploitation sont conçus ».

Pour rappel, Microsoft avait déjà présenté ledit mécanisme exploité en avançant « qu’une table d'atome est une table définie par le système qui stocke des chaînes et des identifiants correspondants. Une application place une chaîne dans une table d'atome et reçoit un entier de 16 bits, appelé un atome, qui peut être utilisé pour accéder à la chaîne. Une chaîne qui a été placé dans une table d'atome est appelé un nom d'atome ».

Selon les chercheurs, il est possible que des attaquants s’en servent pour injecter du code malveillant dans des processus légitimes, ce qui facilite le contournement des solutions anti-infiltration, l’extraction d’informations sensibles ou même l’accès à des mots de passe chiffrés, bien entendu à l’insu de l’utilisateur. Pour mettre en lumière ce dernier cas de figure, nous pouvons parler de Google Chrome qui chiffre les mots de passe stockés en utilisant l'API Protection des données Windows (DPAPI) ; si un logiciel malveillant est injecté dans un processus qui se déroule dans le contexte de l'utilisateur actuel, ces mots de passe peuvent être révélés en texte brut puisque l'API se sert des données actuelles de l'utilisateur pour chiffrer et déchiffrer des informations, ainsi que l'accès à ces mots de passe.

Dans l’optique de mieux illustrer leur propos, ils rappellent le contexte de l’injection de code : « par exemple, supposons qu’un pirate a été en mesure de convaincre un utilisateur d’exécuter le fichier evil.exe. Tout type de pare-feu décent installé sur l'ordinateur pourrait bloquer cet exécutable. Pour surmonter ce problème, evil.exe va devoir trouver un moyen de manipuler un programme légitime, comme un navigateur Web, de sorte que le programme légitime lance la communication au nom de evil.exe ». . .

Mais que se passe-t-il concrètement ? Après avoir rappelé que les tables d’atome peuvent également servir à partager des données entre les applications, ils affirment que « nous avons découvert qu’un pirate peut écrire du code malveillant sur dans une table d’atome et forcer un logiciel légitime à récupérer ledit code de la table. Nous avons également découvert que le logiciel légitime, qui contient désormais ce code malveillant, peut être contraint à l’exécuter ».

Les chercheurs précisent qu’AtomBombing est une technique qui se sert d’un mécanisme sous-jacent de Windows, il n’est donc pas question ici d’exploiter une quelconque faille ou un bogue. « Étant donné que le problème ne peut pas être résolu, il n’y a pas de notion de correctif pour un cas comme celui-ci. Aussi, la réponse d'atténuation directe réside dans les appels d'API et la surveillance d’activités malveillantes ».

Ils rappellent qu’il est important de ne pas oublier qu’AtomBombing n’est qu’une technique parmi d’autres qui peuvent être utilisées par des pirates : « les pirates vont continuer de se servir d’outils, nouveaux ou déjà éprouvés, pour s’assurer de contourner les technologies anti-infiltration (tels que AV, JAV, HIPS, etc.). ».

Tal Liberman, chercheur en sécurité en chef d'Ensilo, a déclaré « AtomBombing utilise des mécanismes et des fonctionnalités légitimes du système d'exploitation pour effectuer et cacher des activités malveillantes. La plus grande préoccupation est que, lorsque les attaquants sont motivés, ils vont toujours trouver des techniques créatives comme cellle-ci. Comme elle est nouvelle et n'a pas encore été marqué comme malveillante, cette méthode permettra de contourner facilement tout produit de sécurité qui tente de bloquer de façon heuristique les activités malveillantes. Reconnaissant que le compromis est inévitable, les organisations devraient envisager une stratégie de sécurité qui suppose que les attaquants sont déjà à l'intérieur ».

Source : blog Ensilo, blog Microsoft (table d'atomes)

[Aurelien.Regat-Barrel]

Les tables d'ATOM sont en fait des hash-table qui associent une clé (entier 16 bits) à une chaîne de caractère. Ce mécanisme existe depuis le tout début de Windows du temps de DOS (d'où les 16 bits). Mais j'ai du mal à voir comment une appli tierce exploite ce mécanisme assez basique pour forcer un logiciel à aller consulter cette table.

Il est facile de créer des tables d'atom globales à tous les process via GlobalAddAtom. Mais comment font-ils pour forcer n'importe quelle appli à consulter cette table? Ils doivent se reposer sur un autre mécanisme qui peut utiliser cette table à l'insu de l'appli car de nos jours les applis n'utilisent plus directement ce reliquat de Win16.

Je connaissais CreateWindow qui peut aller interroger cette table, mais en cherchant un peu il doit plutôt s'agir de DDE (Dynamic Data Exchange), l'ancêtre des technos d'IPC entre composant genre OLE/COM:

Certain arguments of DDE messages are global atoms or shared memory objects. Applications using these arguments must follow explicit rules about when to allocate and delete them. In all cases, the message sender must delete any atom or shared memory object that the intended receiver will not receive because of an error condition, such as failure of the PostMessage function.

DDE uses shared memory objects for three purposes:
To carry a data-item value to be exchanged. This is an item referenced by the hData parameter in the WM_DDE_DATA and WM_DDE_POKE messages.
To carry options in a message. This is an item referenced by the hOptions parameter in a WM_DDE_ADVISE message.
To carry a command execution string. This is an item referenced by the hCommands parameter in the WM_DDE_EXECUTE message and its corresponding WM_DDE_ACK message.

Si c'est le cas, alors c'est une faille / un abus de DDE, pas des tables d'atom.

C'est loin d'être la première fois que l'échange de messages Win32 trahi son âge et ses limites en terme de sécurité. On se souvient sous NT4 de comment n'importe quelle appli pouvait injecter un timer dans une autre pour lui faire appeler une callback de son choix... A partir de XP Microsoft est arrivé à sécuriser les choses dans une certaine mesure (et c'était pas gagné).

Mais là c'est effectivement délicat car tout se passe en user mode : on ne cherche plus à escalader les privilèges (en attaquant un service par exemple), mais à détourner une application basique considérée comme légitime (navigateur) pour lui faire exécuter un autre code. Cela étant dit DDE est un dinosaure, peut-être qu'on peut envisager de le rendre désactivable... si c'est bien chez lui que se trouve la faille

En tous cas cette faille concerne plus les navigateurs web que la plupart des autres applis.

[transgohan]

Je reste tout autant dubitatif... Aucune information utile pour comprendre cela sur leur blog.
Faut les croire sur parole à priori.

Mais je ne vois pas comment une application irait lire le contenu d'un atome sans en avoir l'identifiant...
A ma connaissance aucune application ne fait un random pour s'amuser à aller lire n'importe quoi.

[Dromar34]

Hello,
En fait il y a a priori des informations utiles ici:
https://breakingmalware.com/injectio...n-for-windows/

En tout cas la news est interessante

[Médinoc]

L'article suggère QueueUserAPC/NtQueueApcThread, mais ça nécessite d'avoir des droits suffisants sur le thread ciblé (et donc, son processus). Ce qui signifie que ça ne passerait pas à travers l'UAC si elle est réglée à fond (qui est le seul réglage efficace).

De plus évidemment, ça nécessite d'avoir déjà compromis le processus de départ.

Edit: De plus, le correctif Microsoft, je le vois venir d'ici: Vu qu'il est expressément déconseillé de faire des QueueUserAPC en inter-processus de toute façon, supprimer cette fonctionnalité. Ou si les seuls programmes "importants" qui l'utilisent tournent en admin, rendre cette fonctionnalité dépendante d'un tel privilège. Le coup du Atom-bombing, lui, n'est qu'un leurre, car il y a d'autres méthodes pour qu'un thread injecté récupère une payload (comme le dit le premier commentaire sur l'article, injecter un thread vers LoadLibrary() fait ça très bien).