Dans le paradigme moderne de la sécurité de l'information pour les masses, la croyance selon laquelle la cybersécurité est coûteuse, difficile et pratiquement impossible pour l'utilisateur moyen est fermement établie. Donc, si vous souhaitez protéger pleinement vos données et informations personnelles, créez un compte avec Google ou Amazon, définissez-le en termes d'identification du propriétaire et vérifiez régulièrement les alertes d'alarme qu'une grande et solide entreprise a arrêté une autre tentative de connexion.
Mais les gens qui connaissent la sécurité de l'information l'ont toujours su: les services cloud sont beaucoup plus vulnérables qu'un poste de travail séparé. En effet, en cas de force majeure, le PC peut restreindre physiquement l'accès au réseau, et là la course commence déjà à changer les apparences et les mots de passe dans toutes les zones attaquées. L'infrastructure cloud est énorme, souvent décentralisée, et les données de plusieurs clients peuvent être stockées sur le même support physique, ou vice versa, les données d'un client sont réparties sur les cinq continents, et seul un compte les combine.
En bref, quand Internet était relativement frais et jeune (et c'était en 2003), les experts en sécurité de l'information ont soigneusement examiné
le système de protection contre le débordement de la mémoire tampon de 1997 et sont passés à la technologie, que nous appelons maintenant
Honeytoken ou Canarytoken. Et depuis quinze ans, ils fonctionnent correctement (et fonctionnent toujours), seules les dernières recherches indiquent qu'au lieu de la dernière ligne de défense dans un certain nombre de services AWS, Honeytoken s'est transformé en un trou béant dans la sécurité de l'information en raison des particularités de la mise en œuvre côté Amazon.
Qu'est-ce que Honeytoken
Honeytoken, comme son ancêtre idéologique dans le système de protection contre les débordements de pile, utilise l'approche «avertir, pas empêcher». En fait, Honeytoken est un appât pour les attaquants, qui est laissé sous le couvert d'informations précieuses et peut être présenté sous la forme, par exemple, d'un lien. Le Honeytoken le plus évident dans la pratique des utilisateurs ordinaires est une alarme de lien, cachée dans une lettre avec le titre "informations de compte bancaire" ou "mes comptes". Le principe est également simple: dès qu'un attaquant prend connaissance des informations que Honeytoken prétend être, ce dernier envoie une alerte au propriétaire / administrateur que le périmètre de sécurité a été violé.
Le Honeytoken lui-même n'est évidemment pas inclus dans le périmètre: dans sa forme classique, c'est un mannequin banal qui est déjà à l'intérieur du périmètre et joue le même rôle que les canaris mourant dans des cages jouées dans des faces minières - un avertissement de danger.
Et voici l'ancêtre de la technologieDe tels "systèmes de signalisation" sont maintenant assez courants et sont utilisés pour alerter les titulaires de compte personnel pour les alerter sur les violations de sécurité AWS. En même temps, il n'y a pas de norme Honeytoken unique - cela peut être n'importe quoi. Par exemple, plusieurs boîtes aux lettres mortes spéciales sont ajoutées aux listes de courrier électronique des clients, l'apparition d'une liste de diffusion sur laquelle indiquera le drain de la base de données entière.
Quelle est la vulnérabilité trouvée dans AWS?
Amazon Web Services utilise activement le système Honeytokens pour recevoir des alertes d'alerte de périmètre de service. Amazon Canaries sont de fausses clés d'accès au compte. Cet outil, avec toute sa simplicité, est extrêmement important: les services cloud sont soumis à des tentatives de piratage et autres attaques constantes. Le fait même d'avoir connaissance de la «percée» du périmètre de cybersécurité AWS dans l'une des directions est déjà la moitié de la victoire des ingénieurs d'Amazon.
Hier 2 octobre 2018, des spécialistes de Rhino Security Labs ont
publié une étude extrêmement désagréable, dont l'essence est exprimée par la déclaration suivante: Honeytokens Amazon Web Services peut être contourné sans perturber le système de signalisation cloud. Cela donne aux attaquants la possibilité d '«entrer», de «prendre» ce dont ils ont besoin et de «partir» tranquillement.
L'architecture entière de Honeytokes AWS est basée sur l'utilisation de fausses clés conjointement avec
CloudTrail , qui conserve également les journaux d'activité. Mais librement disponible dans le guide d'utilisation Amazon, il existe toute une liste d'adresses et de services qui ne prennent pas en charge CloudTrail. En fait, cela signifie que toute demande adressée à ces services, y compris via l'API, n'est enregistrée nulle part. Dans le même temps, Amazon renvoie les messages de retour avec une erreur d'accès avec
ARN .
Ensuite, les chercheurs de Rhino Security ont «frappé»
AWS AppStream via
l'API DescribeFleets et ont reçu les informations suivantes sur le compte de test:
Ensuite, avec son aide, un attaquant extrait des informations sur l'utilisateur / rôle
IAM du plan suivant:
IAM User:
arn:aws:iam::111111111111:user/the-path/TheUserName
IAM Role:
arn:aws:iam::111111111111:role/the-path/TheRoleName/TheSessionNameEn conséquence, grâce au retour ARN et aux données utilisateur / rôle IAM reçues, les spécialistes ont pu compromettre les clés d'appâts Honeytokes sur les services ci-dessus grâce à l'analyse.
Contre-mesures
Le chemin trouvé met
en danger non seulement AWS, mais également les développeurs de systèmes Honeytoken populaires pour les systèmes Amazon tels que
CanaryToken et
SpaceCrab . Les deux développeurs ont été informés et prennent toutes les mesures possibles pour résoudre le problème.
De plus, des spécialistes de Rhino Security ont
publié un script PoC
sur GitHub qui vérifiera si la clé AWS qui vous est fournie est un jeton, car toutes les configurations n'ont pas encore été mises à jour.
Réaction d'Amazon
Amazon a signalé à Rhino Security Labs que l'ARN n'est pas une information sensible, CloudTrain fonctionne (et ne fonctionne pas) si nécessaire, et il n'y a pas de problème en tant que tel.