Date de publication initiale : 25/04/2023 10H00 EST
Un chercheur en sécurité a récemment signalé un problème lié a la prise en charge récente par AWS (16 novembre 2022) de plusieurs dispositifs d'authentification multifactorielle (MFA) pour les principaux qui sont des utilisateurs IAM. Le problème signalé ne pouvait survenir que si les trois conditions suivantes étaient remplies : (1) un utilisateur IAM possédait des informations d'identification à long terme sous forme de clé d'accès (AK) / clé secrète (SK), (2) cet utilisateur IAM avait le privilège d'ajouter une MFA à sa propre identité sans utiliser de MFA, et (3) les privilèges d'accès globaux de l'utilisateur IAM au-delà de la connexion à la console avaient été configurés par un administrateur pour être améliorés après l'ajout de la MFA. Dans ces conditions strictes, la possession d'AK/SK seule équivalait à la possession d'AK/SK et d'une MFA préalablement configurée.
Bien que les utilisateurs IAM ayant la possibilité d'ajouter ou de supprimer un dispositif MFA associé à leur propre identité aient toujours pu le faire uniquement avec des informations d'identification AK/SK, un problème est survenu lorsque la nouvelle fonctionnalité a été combinée à l'autogestion par les utilisateurs IAM de leurs propres appareils MFA, avec un accès restreint avant l'ajout d'une MFA par l'utilisateur. Ce modèle d'autogestion a été documenté ici, et cette page comprend un exemple de politique IAM pour la mise en œuvre du modèle. La combinaison de la nouvelle fonctionnalité multi-MFA a créé une incohérence avec cette approche. Grâce à cette nouvelle fonctionnalité, un utilisateur ne disposant que d'informations d'identification AK/SK pouvait ajouter une MFA supplémentaire sans utiliser une MFA configurée au préalable, ce qui lui permettait de posséder uniquement une AK/SK sans une MFA préalablement configurée, obtenant ainsi un accès plus large que ce à quoi s'attendaient les clients utilisant l'exemple de politique.
Ce problème n'a pas affecté l'accès via la Console de gestion AWS, étant donné qu'une MFA existante est toujours requise lors de la connexion. Cela n'a pas non plus affecté les principaux fédérés, qui gèrent l'authentification multifactorielle par le biais de leur fournisseur d'identité.
Le 21 avril 2023, le problème identifié a été résolu en demandant aux utilisateurs IAM qui possèdent déjà une ou plusieurs MFA et qui utilisent des informations d'identification AK/SK pour gérer leurs propres appareils MFA d'utiliser d'abord sts:GetSessionToken et une MFA existante pour obtenir des informations d'identification temporaires compatibles MFA afin de signer leurs commandes CLI ou leurs demandes d'API avant d'activer ou de désactiver les appareils MFA pour eux-mêmes. Nous avons directement informé un très petit nombre de clients via leur tableau de bord Personal Health Dashboard qui avaient précédemment associé un appareil MFA supplémentaire à l'aide d'un mécanisme autre que la Console de gestion AWS. Nous avons recommandé aux clients avertis de confirmer l'exactitude de leurs configurations MFA. Aucune autre action n'est nécessaire de la part du client.
Nous tenons à remercier les chercheurs de MWR Cybersec d'avoir identifié ce problème et de l'avoir signalé de manière responsable à AWS. Vous pouvez nous envoyer vos questions ou préoccupations liées à la sécurité à l'adresse aws-security@amazon.com.