Bit of a Close Talker: A Practical Guide to Serverless Cloud Co-Location Attacks
Cet article présente une méthodologie complète pour exploiter les vulnérabilités des ordonnanceurs de nuages sans serveur afin de parvenir à la colocalisation physique pour des attaques par canaux auxiliaires micro-architecturaux, démontre des attaques réussies sur des plateformes majeures telles que Microsoft Azure Functions, et propose un ordonnanceur « Double-Dip » comme stratégie d'atténuation.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
La vue d'ensemble : L'hôtel « Serverless »
Imaginez le monde du cloud computing comme un immense hôtel.
- Cloud Traditionnel (Serverful) : Vous louez une chambre entière pour vous seul. Vous payez pour la chambre même si vous n'y dormez que 5 minutes ou 24 heures.
- Cloud Serverless : Vous ne payez que pour le temps exact passé dans la chambre. Si vous avez besoin d'une chambre pendant 10 secondes pour déposer un colis, vous payez pour 10 secondes. Le personnel de l'hôtel (le fournisseur de cloud) s'occupe de tout le nettoyage, des clés et de la maintenance. Vous n'avez qu'à arriver, faire ce que vous avez à faire et partir.
C'est excellent pour économiser de l'argent et être flexible. Mais, parce que l'hôtel est très efficace, il essaie de faire tenir autant de clients que possible dans les mêmes chambres pour gagner de l'espace. Cela crée un risque de sécurité : Des inconnus pourraient se retrouver dans la même chambre que vous.
Le Problème : L'attaque du « Close Talker » (celui qui parle trop près)
Dans le monde de l'informatique, il existe des astuces sournoises appelées attaques par canal auxiliaire (side-channel attacks). Imaginez un voleur essayant de voler votre numéro de carte de crédit. Il ne peut pas forcer votre coffre-fort, mais s'il se tient juste à côté de vous dans la même pièce, il peut entendre votre rythme cardiaque ou ressentir la chaleur de votre ordinateur pour deviner votre mot de passe.
Pour ce faire, le voleur doit être co-localisé avec vous — ce qui signifie que son instance informatique et votre instance informatique doivent fonctionner sur le même serveur physique (la même « chambre »).
Le Défi : Les fournisseurs de cloud sont intelligents. Ils essaient de mélanger les clients pour que des inconnés ne se retrouvent pas dans la même pièce. L'article pose la question suivante : Un voleur peut-il tromper le gestionnaire de l'hôtel (l'ordonnanceur/scheduler) pour qu'il le place dans la même chambre qu'une victime spécifique ?
La Solution : Comment les voleurs ont procédé
Les auteurs de cet article ont créé un « guide pratique » pour expliquer comment tromper le cloud. Ils ont décomposé le processus en trois étapes, comme un détective résolvant une énigme :
Étape 1 : L'empreinte digitale (L'essai de routine)
Avant d'attaquer, le voleur doit savoir comment pense le gestionnaire de l'hôtel.
- L'analogie : Imaginez que le voleur envoie un message de test à l'hôtel. Il observe où l'hôtel le place. Ensuite, il envoie un autre message et observe à nouveau.
- La découverte : En envoyant de nombreuses requêtes de test, le voleur apprend les habitudes du gestionnaire.
- Le gestionnaire met-il toujours le même client dans la même chambre pour gagner du temps ? (Oui, c'est ce qu'on appelle la « Localité d'invocation » ou Invocation Locality).
- Le gestionnaire ajoute-t-il plus de chambres quand il y a beaucoup de monde ? (Oui, c'est l'« Auto-scaling »).
- Le gestionnaire regroupe-t-il les gens qui ont des bagages similaires ? (Oui, c'est la « Localité de package » — si vous avez tous les deux besoin des mêmes outils logiciels, on vous met ensemble).
Étape 2 : L'attaque (Le piège)
Une fois que le voleur connaît les habitudes du gestionnaire, il tend un piège.
- Si le gestionnaire regroupe par bagages (Package Locality) : Le voleur crée une fonction factice qui utilise exactement les mêmes « bagages » (packages logiciels) que la victime. Le gestionnaire voit les bagages correspondants et les place automatiquement dans la même chambre.
- Si le gestionnaire est débordé et ajoute des chambres (Auto-Scaling) : Le voleur crée une vague massive de fausses requêtes. Cela force le gestionnaire à ouvrir de nombreuses nouvelles chambres rapidement. Le voleur inonde le système avec ses propres « clients » pour augmenter les chances que l'un d'eux atterrisse accidentellement dans la chambre de la victime.
- Le Résultat : Dans leurs tests, ils ont réussi à tromper des systèmes comme Microsoft Azure et des plateformes open-source pour placer leur code « attaquant » juste à côté du code « victime ».
Étape 3 : La preuve
Ils n'ont pas seulement deviné ; ils ont prouvé que cela fonctionnait.
- Ils ont testé cela sur un hôtel simulé (un programme informatique).
- Ils ont testé cela sur un véritable cluster de 50 ordinateurs.
- Ils ont testé cela sur Microsoft Azure Functions (un véritable service de cloud public).
- Le Résultat : Ils ont réussi à se co-localiser avec des victimes dans Azure, en dépensant moins de 25 $ pour y parvenir.
La Correction : L'ordonnanceur « Double-Dip »
L'article ne se contente pas de montrer comment entrer ; il propose aussi un verrou. Ils proposent une nouvelle règle pour le gestionnaire de l'hôtel appelée Double-Dip.
- Comment ça marche :
- Premier passage (First Dip) : Si un client (fonction) arrive, le gestionnaire vérifie d'abord : « Est-ce que ce client est déjà dans une chambre ? Pouvons-nous le remettre là-bas ? » (Cela permet de rester rapide et efficace).
- Second passage (Second Dip) : S'il n'y a pas de place pour lui, le gestionnaire cherche une chambre qui possède le moins de types de clients différents déjà présents.
- Le But : Cela garantit que si un nouveau client entre, il est moins susceptible d'être mélangé à un étranger. Cela crée une « isolation douce ». Ce n'est pas un mur parfait (comme une maison privée dédiée), mais cela rend beaucoup plus difficile pour un voleur de deviner où la victime se cache.
L'essentiel à retenir
- La Menace : Les clouds serverless sont efficaces, mais leur efficacité (regrouper des choses similaires) crée une porte dérobée permettant aux attaquants de s'approcher de leurs victimes.
- La Réalité : Les attaquants n'ont pas besoin de super-pouvoirs ; ils ont juste besoin de comprendre les règles d'ordonnancement du cloud et d'envoyer les bons « messages de test » pour les exploiter.
- La Défense : Les fournisseurs de cloud doivent changer leurs algorithmes d'ordonnancement pour les rendre un peu plus aléatoires et moins prévisibles, afin de garantir que des inconnus ne se retrouvent pas accidentellement à partager une chambre.
Note importante : L'article souligne que cette recherche porte sur l' ordonnancement (l'attribution des chambres). Elle ne vole pas réellement de données ; elle prouve simplement que l'« attribution de chambre » peut être manipulée pour préparer le terrain à un futur vol de données. Les auteurs ont prévenu Microsoft de cela, et Microsoft a noté qu'elle dispose d'autres défenses en place, mais la vulnérabilité de l'ordonnancement reste un problème réel.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.