Attaque matérielle : la part belle au réseau

Préambule

Nous avons écrit cet article avec Pierre en pensant à nos mères, en effet à l’approche des fêtes de Noël il nous faut préparer le fameux topo “alors qu’est-ce que tu fais à l’école en ce moment ?”. Cet article est donc à destination d’un public complètement néophyte, malgré la grande complexité du sujet.

Alors voilà maman : en ce moment je fais de la sécurité, c’est à dire on essaye de comprendre comment on peut pénétrer, comme un cambriolage, un ordinateur. En comprenant comment s’infiltrer on veut apprendre à protéger les gens.

Dans ce domaine il existe des multitudes d’attaques différentes, dans cet article je vais essayer de t’expliquer une d’entre elles, les attaques matérielles sur le réseau.

Qu’est ce que c’est une attaque matérielle ?

Comme l’ont expliqué nos chers aînés Gabriel Augendre et Emmanuel Gublin dans cet article, une attaque matérielle ou “hardware” est une attaque informatique exploitant les failles présentes au niveau matériel d’un ordinateur. Dans un ordinateur il existe beaucoup de composants très complexes qui gèrent beaucoup de choses par exemple il faut gérer dans quel ordre l’ordinateur fera les tâches qui lui sont demandés. Il doit aussi manipuler des valeurs (utiles pour ses calculs et ses différentes opérations) et doit donc gérer leur stockage pendant ces manipulations.

C’est le genre de tâches très délicates où se situe le danger : il faut empêcher qu’un programme malveillant puisse demander à l’ordinateur d’accèder aux données d’un autre programme, données qui sont potentiellement sensibles comme un mot de passe ou un message secret.

Les composants qui s’occupent de cette protection agissent très profondément dans l’ordinateur, nous, à titre personnel, nous n’avons jamais à nous en occuper par exemple ! C’est pour cela que l’on parle d’une attaque matérielle, c’est une attaque qui utilise des failles issues des composants de l’ordinateur. A contrario quelqu’un·e qui essaierait de s’attaquer à des logiciels comme ceux que nous créons en cours pratiquerait plutôt une attaque logicielle. C’est clair ?

L’avantage (ou défaut ?) traditionnel avec ces attaques c’est que justement elles demandent un accès important à l’ordinateur, ce qui n’est pas aisé à obtenir. Or il existe de nouvelles attaques qui permettent justement d’exploiter ces vulnérabilités à distance !

Les implications sur le réseau

ThrowHammer

ThrowHammer est un dérivé d’une attaque connue sous le nom de RowHammer qu’on traduit en français par attaque avec “Martèlement de mémoire”. La mémoire est gérée dans des cases et ces cases sont isolées les unes des autres, c’est ce dont on parlait au début : un programme ne doit pas pouvoir accéder aux cases d’un autre programme.

Tu sais que la mémoire d’un ordinateur est composée de 0 et de 1, physiquement cela correspond à des états électriques : bas et haut. Il faut imaginer que la mémoire rapide d’un ordinateur se sont des tas de composants minuscules qui conservent un état électrique dans le temps.

Normalement, comme on l’a dit, l’ordinateur ne donne qu’un nombre limité de ces emplacement à un programme. Et bien il se trouve que ces composants sont si serrés les uns des autres (pour miniaturiser les appareils) que les emplacements ne sont pas bien isolés électriquement ! Ainsi si l’on modifie très rapidement les états des emplacements qui encadre une donnée sensible on peut modifier la donnée sensible directement. Je peux alors modifier une valeur écrite stipulant que je n’avais pas le droit d’accéder aux autres programmes et ainsi outrepasser les règles de sécurité.

En modifiant rapidement les lignes bleue et verte on peut modifier les états de la ligne intermédiaire !

Jusque là cet effet n’était possible qu’avec un accès direct permettant une très grande vitesse de modification de ces cases. Or un nouvel article présenté en 2018 à une grande conférence à Boston montre qu’il est possible d’utiliser les accès rapides du réseau pour obtenir le même effet.

En effet pour augmenter les performances des sytèmes informatiques les ordinateurs peuvent maintenant laisser un accès à des emplacements mémoires à des programmes exécutés sur d’autres ordinateurs. Cette technologie s’appelle RDMA pour Remote Direct Memory Access, et malgré tous les avantages qu’elle apporte elle permet par la même occasion de fournir une vitesse de modificatoin de la mémoire suffisament rapide pour utiliser l’attaque RowHammer à distance !

Netcat

Je te présente une faille majeure découverte tout récemment en juillet 2019 dans ce papier, NetCat. Il s’agit d’une attaque informatique qui veut dire “NETwork Cache ATtack” c’est-à-dire : “Attaque réseau par le cache”.

Avant de voir comment exploiter cette faille, il faut la comprendre. Elle intervient dans un contexte précis, celui de l’enjeu des infrastructures réseaux tels que les serveurs, qui est de délivrer du contenu (vidéos, articles de presse, dropbox…) de manière plus rapide à un nombre d’utilisateur·trice·s croissant. Il ne suffit plus de mettre des fibres ou des équipements hyper performants, il faut aussi des améliorations logicielles. C’est pour cela qu’Intel a développé le DDIO.

Cette fonctionnalité permet d’utiliser la mémoire qu’on atteint le plus rapidement, la mémoire cache du processeur, pour pouvoir gagner en débit. En effet, dans un équipement réseau, il y a plusieurs types de mémoires que l’on peut accéder à des vitesses plus ou moins rapides. Le problème, c’est que cette mémoire cache du processeur, elle est utilisée par tous les utilisateur·trice·s présent·e·s sur le serveur. Des chercheuses et chercheurs d’un groupe de sécurité à Amsterdam ont démontré que l’on pouvait utiliser cette fonctionnalité pour deviner lorsqu’un paquet est envoyé sur le réseau. Cela peut paraître dérisoire, mais il se trouve que ce sont des informations cruciales. En effet, si en plus du DDIO le RDMA est utilisé, on peut alors mesurer le temps entre tous les messages envoyés sur internet, paquets, et faire des statistiques. Comme tout le monde a un rythme de frappe unique, l’analyse statistique de ces paquets permettent de dévoiler ce qu’un utilisateur·trice a écrit.

Ce qui est fort, c’est que l’on a pas besoin d’infecter le serveur ni la machine du client·e. Qu’il s’agisse d’une attaque sur le réseau signifie qu’il suffit d’être dans le même réseau local pour pouvoir exploiter cette faille.

Il y a plusieurs types de réseaux dont deux principaux : le réseau étendu (internet) et le réseau local. Si l’ordinateur de la maison veut interagir avec l’imprimante, il va utiliser le réseau local de la maison, alors que s’il veut faire une recherche internet il va aller sur le réseau Internet.

Ici, cela veut dire concrètement qu’on peut infecter une machine peut-être moins protégée dans le même réseau local que le serveur cible pour réaliser l’attaque. C’est donc une faille assez importante, même si elle est difficile à mettre en place. Intel a reconnu l’existence de cette faille, mais l’a catégorisé comme de faible gravité avec un score de 2.6 sur 10 sur l’échelle CVSS.

Comment se protéger ?

Le patch

Pour se protéger de ces attaques, il n’existe pour l’instant aucune solutions magiques. Il faut tout simplement désactiver les mécanismes qui les ont rendu possible : le DDIO et le RDMA.

Pour NetCat par exemple, Intel va recommander d’utiliser DDIO et RDMA uniquement dans le cas où l’on est certain que le réseau local est sûr. Cependant, la vulnérabilité est toujours présente, et il est tout de même compliqué de savoir si le réseau local est dénué de tout défauts. Par exemple on peut mettre en place un logiciel qui va faire en sorte que tous les messages sont envoyé avec le même temps, rendant l’attaque statistique inutilisable. Cependant, on est pas sûr que ce soit la seule attaque possible avec cette vulnérabilité. C’est pourquoi les auteur·e·s de l’article ne sont pas d’accord et préconisent de ne pas utiliser DDIO, ou si c’est nécessaire de ne pas utiliser RDMA pour ne pas faciliter les attaques par timing.

Difficulté d’implémentation

Si on entend pas beaucoup parler de ces attaques, c’est qu’elles sont tout de même difficile à mettre en place. Si cela paraît déjà compliqué lorsqu’on l’explique, c’est encore plus difficile lorsqu’il faut l’implémenter.

Si on prend l’exemple de l’attaque réalisée par les chercheur·se·s, il y a eu plein de simplifications. Tout d’abord elle ne permet d’écouter les frappes de clavier uniquement si un·e utilisateur·trice est connecté·e sur le serveur avec un protocole qui s’appelle ssh. Si ce terme ne t’est pas familier, c’est normal, c’est une commande que l’on utilise principalement sur des machines Linux. Mais oui, tu sais, comme Windows ou Mac, le système d’exploitation. Cela est courant dans le milieu de l’informatique, beaucoup moins pour les utilisateur·trice·s lambdas.

Ensuite, il faut que ce serveur soit connecté en RDMA avec une machine. Et si RDMA est bien activé, il faut en plus que cette machine soit vulnérable et que l’attaquant·e réussisse à la compromettre. Il faut donc une attaque logicielle pour ensuite pouvoir effectuer l’attaque matérielle…

Questionnement : entre protection et performance

La balance éternelle entre protection et possibilités

Alors voilà, il y a des améliorations qui sont faites pour pouvoir répondre à un besoin. C’est d’autant plus vrai qu’avec l’explosion du trafic internet, les besoins d’optimisations pour avoir un débit plus grands sont importants. Le problème c’est que cela peut conduire à des failles.

Heureusement pour les failles matérielles sur le réseau, elles sont très difficiles à exploiter. Cela rend donc l’attaque peu dangereuse à grande échelle, à contrario d’un WannaCry qui va infecter le plus de machines possibles et chercher à s’étendre à tous les appareils d’Internet.

La décision incombe alors aux responsables sécurités de choisir quelles options ils souhaitent conserver dans leur système, et d’assumer ce choix et les risques associés. Nous ne sommes pas face à un cas classique “il faut corriger la vulnérabilité, dépêchez vous sinon vous allez être attaqué, et si vous ne le faites pas vous êtes fautif”. Ici chaque choix est argumentable et compréhensible, que l’on décide de conserver une fonctionnalité qui améliore grandement le rendement de notre système ou que l’on considère que le système doit être avant tout inattaquable plutôt que performant.

Diffuser la faille, tous au courant tous protégés ou empêcher d’armer les personnes malveillantes ?

On observe que les 2 papiers que nous avons étudiés ne donne pas forcément des cas pratiques et rapides à mettre en place. Notamment l’article sur ThrowHammer a même été retiré du site original (trouvable toujours sur Google Scholar) et que même si dans l’article il est dit que le code source de l’attaque et de la protection est trouvable sur VuSec il n’en est rien.

En effet maman, lorsqu’on découvre une faille, il y a deux manière de penser.

• La première consiste à prévenir le ou la constructeur·trice ou développeur·se de logiciels de la vulnérabilité en privé.
• La deuxième est de dévoiler la faille au monde entier. S’il y a un risque accru de se faire attaquer par tout le monde car la faille est publique, il y a aussi un gros effort pour corriger la vulnérabilité.

Aujourd’hui, on est un peu au milieu. On va prévenir qu’il y a une vulnérabilité de manière privée tout d’abord, en disant qu’ils ou elles ont 3 mois pour la corriger. Ensuite la faille est rendue publique. C’est ce qui s’est passé pour NetCat.

Concernant la diffusion du code, c’est un peu plus compliqué. Les deux écoles sont la même : propager la découverte à tous, sachant qu’il est facile de se défendre ou que la vulnérabilité va être corrigée. Ou bien justement ne pas divulguer le code, sachant que la défense est trop difficile à mettre en place ou que l’attaque peut être problématique.

Tu vois maman, ici aussi les spécialistes, les expert·es, ne sont pas forcément d’accord sur ce qu’il faudrait faire de cette information. Et nous non plus !