Vulnérabilité liée à l'usurpation d'identité dans EAA d'Akamai - Analyse approfondie

Dans cet article, nous couvrirons les détails techniques du CVE-2021-28091,la vulnérabilité affectant la plateforme Enterprise Application Access (EAA) d'Akamai. Nous couvrirons notre processus d'investigation, de correction et de divulgation de la vulnérabilité. Pour une présentation de la vulnérabilité, de son impact sur Akamai, de son impact sur les clients d'EAA et des actions requises, veuillez consulter notre rapport complémentaire.

Présentation

Dans cette section, nous examinerons l'histoire et la structure de cette vulnérabilité. Certains lecteurs souhaiteront peut-être ignorer cette section pour le moment et se rendre directement à la section Actions requises, en utilisant cette Présentation comme référence dans les évaluations qu'ils devraient effectuer ou pour de futures révisions.

Avant l'acquisition par Akamai de la technologie EAA via l'acquisition de Soha Systems en 2016, une fonctionnalité clé a été introduite dans la plateforme, permettant aux clients de prendre des décisions de contrôle d'accès et d'authentification sur la base des informations d'identité fournies par un fournisseur d'identité tiers. La plateforme EAA propose plusieurs méthodes d'intégration d'identités tierces. La méthode notable dans ce rapport est la prise en charge du protocole d'authentification SAML (langage de balisage d'assertion de sécurité) v2.0.

SAML est une norme ouverte largement utilisée. SAML permet à un fournisseur d'identité (IdP) de faire une assertion, par signature et retour cryptographiques à un fournisseur de services (SP), par l'intermédiaire du client présentant un objet d'assertion de l'IdP au fournisseur de services dans un délai défini. (Voir la section contexte ci-dessous pour plus d'informations.)

Lorsque la prise en charge des IdP tiers a été ajoutée à EAA, les développeurs ont sélectionné la bibliothèque open source Lasso pour implémenter la prise en charge de SAML au sein de la plateforme. Sur la base de l'évaluation par Akamai du code au cours duquel Lasso vérifie les réponses SAML qui lui ont été fournies en tant que fournisseur de services, nous estimons qu'au moment de l'intégration initiale, les développeurs implémentant la fonctionnalité IdP tierce l'ont fait de manière raisonnable en fonction des cas d'essai fournis avec la bibliothèque. Une enquête plus approfondie a révélé que la suite de tests utilisée pour mettre en œuvre Akamai n'était pas suffisamment rigoureuse pour identifier cette vulnérabilité d'usurpation d'identité ou des faiblesses similaires dans le processus d'authentification. Cette lacune a été comblée dans le cadre de notre réponse en élargissant la suite de tests appliquée aux nouvelles versions du produit pour inclure toutes les combinaisons de réponses et/ou assertions valides et non valides, ainsi que les assertions et réponses non signées. Ces nouveaux tests font partie du processus d'assurance qualité standard à venir.

Dans les sections suivantes du rapport, nous détaillerons les diverses faiblesses et facteurs contributifs ayant constitué la vulnérabilité globale. Notre objectif, en fournissant ce niveau de transparence, est d'aider d'autres personnes à comprendre les mesures prises par Akamai et de leur permettre d'éviter des situations similaires dans leur propre environnement.

Test et évaluation du système

Les tests unitaires, les tests d'intégration et les tests de régression sont un aspect critique de tout cycle de développement logiciel. Bien que la sous-composante mise en œuvre comportait toutes ces méthodes de test associées, nous avons clairement découvert que les tests n'étaient pas assez rigoureux. En outre, cet incident a mis en lumière une omission où certaines bibliothèques tierces étaient incorporées dans des projets sous la fausse hypothèse que le cycle de développement des logiciels de la dépendance était lui-même rigoureux et serait informé par des découvertes spécifiques au domaine, telles que des vulnérabilités dans des bibliothèques similaires.

Bien qu'un cycle de développement des logiciels rigoureux pour chaque composant et chacune de ses dépendances soit nécessaire, les tests intégrés dans le plan de développement des composants et d'assurance qualité ne sont souvent pas suffisants. Pour compléter ces tests, des évaluations contradictoires, telles que des tests de pénétration ou des révisions du code par des tiers, peuvent être utilisées. Dans le cas d'EAA, de multiples évaluations externes de la sécurité et de la vulnérabilité de la plateforme EAA ont été menées au cours de la durée de vie du produit, souvent par les clients. Malgré cela, le rapport à l'origine de cette réponse correspondait à la première fois que cette vulnérabilité était signalée à Akamai. Akamai a mené des évaluations ciblées par rapport à d'autres parties de la plateforme EAA et de son application cliente, mais ce composant spécifique n'a pas été soumis à ce niveau d'examen.

Éviter la divulgation prématurée

Dès le début de ce processus de réponse aux incidents, Akamai a commencé à rédiger une notification client générale pour guider les clients dans le lancement des enquêtes suggérées dans la section Actions requises de l'article complémentaire. Lors d'un examen préalable de ce document, les collaborateurs d'Akamai qui n'avaient pas été informés de la vulnérabilité ont reçu une copie du message adressé aux clients. Dans l'heure qui a suivi la transmission du message, nos réviseurs ont pu identifier le protocole affecté (SAML), le package affecté (Lasso), et, avec une activité récente du responsable du projet Lasso, estimer la vulnérabilité. Cette révélation a immédiatement interrompu nos plans de notification partielle visant à respecter les principes de divulgation responsable. 

Après d'autres conversations avec nos réviseurs, l'équipe de l'incident a pu apprendre le processus par lequel elle a fait ces découvertes. Un résultat clé signalé par les réviseurs était le message d'erreur renvoyé par l'IdP lorsqu'une condition d'erreur se produisait. Jusqu'à ce que le correctif de la vulnérabilité soit publié, les échecs SAML renvoyaient une page d'erreur qui exposait l'erreur de Lasso à l'utilisateur final, comme le montre l'image ci-dessous. Le transfert d'une erreur, en particulier pour les processus de sécurité critiques comme l'authentification, est contraire aux meilleures pratiques. C'est pourquoi l'erreur ne sera pas visible pour les utilisateurs finaux à partir de cette version. 

Le document XML ci-dessus a été simplifié pour les besoins du présent rapport, mais la structure est la même. Le document externe « parent » correspond à la réponse SAML, y compris les métadonnées sur la requête et un document d'assertion. L'assertion, également appelée assertion SAML, correspond aux données fournies par l'IdP au fournisseur de services pour utilisation dans le processus d'authentification. Plusieurs assertions peuvent être présentes dans une seule réponse SAML. Dans l'exemple ci-dessus, le contenu des crochets ds:Signature est une signature cryptographique sur le contenu de l'objet parent, qui est l'assertion dans le cas présent. Le même objet signature peut également être appliqué à l'objet réponse complet. Le but de la signature est de permettre au fournisseur de services de vérifier que les données contenues dans l'affirmation ou la réponse sont légitimes et fournies par l'IdP. Dans le cas de l'assertion, la signature ne s'applique qu'à toutes les données contenues dans l'assertion, comme un nom d'utilisateur, une adresse e-mail ou des indications d'appartenance à un groupe. Les signatures appliquées au niveau de la réponse s'appliquent au contenu complet de la réponse et à toutes les assertions qu'elle contient.

La vérification des différentes signatures dans la réponse SAML est confiée au fournisseur de services et est souvent configurée au moment où l'IdP est configuré pour communiquer avec l'application. Dans notre réponse à cette question, nous estimons que les conditions de vérification par défaut pour les réponses SAML devraient être les suivantes :

• Lorsque la totalité de la réponse SAML est validement signée, toutes les assertions de la réponse doivent être correctement signées ou ne pas avoir de signature. Si des signatures non valides sont trouvées, la vérification doit échouer. Cette méthode repose sur le fait que l'IdP fait autorité pour l'ensemble du corps du message, qui est signé.
• Lorsque la réponse SAML n'est pas signée, toutes les assertions de la réponse doivent être signées correctement, sinon la vérification doit échouer.
• Lorsque la réponse SAML a une signature non valide, la vérification doit échouer.

Les conditions de traitement ci-dessus correspondent au correctif proposé par Akamai à Lasso.

Le rapport fourni à Akamai au début de ce problème montrait que le chercheur soumettait deux assertions SAML dans une seule réponse SAML ; la première était validement signée, mais la seconde n'était pas signée. La configuration par défaut de Lasso présentait les conditions de vérification par défaut suivantes.

• Si la première assertion SAML dans la réponse était validement signée, la vérification réussissait, sans tenir compte de la validité ou non de la signature complète de la réponse SAML.
• Si la première assertion SAML était signée de manière invalide, la vérification échouait.
• Si la réponse SAML était validement signée et qu'aucune des affirmations n'avait été signée, la vérification réussissait.
• Sinon, la vérification échouait.

 Pour compliquer les choses, lorsque la réponse était jugée valide par la bibliothèque, la fonction pour récupérer l'assertion de la réponse SAML renvoyait la dernière assertion dans l'objet réponse, indépendamment du fait qu'elle ait une signature valide. À titre d'exemple, supposons qu'un pirate obtienne une réponse SAML valide avec une seule assertion d'un IdP, comme celle ci-dessus, et ajoute ce qui suit comme seconde assertion :

Dans le cas où l'utilisateur fourni est valide pour l'organisation mais dispose de privilèges supplémentaires, il aura alors la réponse SAML combinée à soumettre au fournisseur de services :

Lorsque Lasso tentait de valider cette réponse SAML, le résultat était que la réponse était valide. Lorsque l'application appelante récupérait l'assertion de la réponse ci-dessus, l'assertion avec l'ID utilisateur de superutilisateur était retournée et probablement considérée comme une assertion valide. En plus de l'exemple ci-dessus, si la réponse SAML elle-même avait une signature valide, cette même méthode d'usurpation d'identité était possible. C'était le cas du traitement des réponses SAML par EAA. 

Conditions d'exploitation

Pour que la réponse SAML soit modifiée avant d'être soumise au fournisseur de services, l'une des conditions suivantes doit être remplie :

• Le client légitime, contrôlé par un utilisateur autorisé valide et par lequel une réponse SAML est redirigée, doit modifier la réponse SAML en injectant le document d'assertion supplémentaire dans le cadre de la réponse SAML. Par exemple, cela peut se produire via une extension de navigateur malveillante ou un autre logiciel malveillant sur le système client, parfois appelé "attaque man-in-the-browser".
• Un pirate doit obtenir une copie valide d'une réponse SAML qui soit toujours valide, soit en ayant encore du temps avant l'expiration de l'assertion, soit, dans certaines applications, lorsque l'assertion n'a pas encore été présentée au fournisseur de services. Par exemple, une partie intermédiaire peut intercepter et modifier une réponse SAML via un proxy, ce qui est souvent appelé "attaque de type man-in-the-middle".
• Un client non autorisé connaît les informations de connexion d'un utilisateur autorisé ou est capable de les deviner. Les informations de connexion peuvent être collectées par le biais de nombreux processus, y compris le phishing, les violations de mot de passe, les suppositions ou les attaques par force brute.

Chacune des conditions ci-dessus peut compromettre la session d'un utilisateur, et si l'implémentation SAML est défectueuse comme indiqué ci-dessus, le fournisseur de services sera vulnérable à une attaque par usurpation d'identité.

Historique de la vulnérabilité

Cette même vulnérabilité, connue sous le nom de XML Signature Wrapping, a été signalée encore et encore et encore. 

L'examen des référentiels Lasso indique que la faiblesse de la bibliothèque a été incorporée dans la base de code dès novembre 2005, bien avant notre incorporation de la bibliothèque mais également avant la publication des vulnérabilités précédentes annoncées à d'autres plateformes.

Nous avons également remarqué au cours de l'enquête que les responsables de la bibliothèque de Lasso s'étaient engagés dans le projet peu de temps après l'envoi de l'avis du problème à Akamai. Lors des discussions avec le lanceur d'alerte, il a été établi que cet engagement n'était pas du tout lié à son rapport, mais était simplement une coïncidence.

Le correctif qui a été proposé le 24 février 2021 a partiellement résolu l'impact de la faille d'exploitation, mais après un examen plus approfondi, nous avons déterminé que ce n'était pas un correctif complet, ce qui explique pourquoi notre correctif a finalement été proposé aux responsables.

Aperçu de la réponse aux incidents d'Akamai

Akamai suit un processus formel de réponse aux incidents. Les incidents font habituellement l'objet d'un traitement conjoint qui implique à la fois les équipes chargées de l'ingénierie, du développement système, des opérations réseau et du service clientèle. En général, plus l'incident est grave, plus il y a de personnes impliquées pour y travailler, et plus il est prioritaire par rapport aux opérations et au travail planifiés. Dans tous les incidents, l'objectif d'Akamai est de : 

• limiter l'impact du problème, 
• assurer un fonctionnement continu et sûr de nos systèmes,
• assurer la continuité, la sécurité et la prise en charge de nos intervenants en cas d'incident,
• assurer la satisfaction des clients et la sécurité de leurs données,
• respecter diverses lois et réglementations,
• s'assurer que nous sommes en mesure d'apprendre et de nous améliorer à partir de tous les dangers qui ont permis à l'incident de se produire.

Comme nous l'avons décrit ci-dessus, nous avons engagé notre processus de réponse aux incidents après notification de cette vulnérabilité. Ce processus a permis à Akamai d'aligner les ressources techniques, de communiquer avec les parties prenantes internes et la direction, de communiquer avec les parties prenantes externes et de coordonner toutes les activités liées à l'incident rapidement et efficacement.

Processus de déploiement et correctifs

Le processus de développement d'un correctif pour cette vulnérabilité et de déploiement du correctif sur le réseau d'EAA était très similaire au processus normal suivi pour les mises à niveau planifiées, mais avec un changement beaucoup plus modeste et un calendrier beaucoup plus court.

Dans les premières heures suivant la réponse à l'incident, nous avons préparé une ébauche de calendrier pour la correction en tenant compte de quelques décisions clés. Selon ce calendrier, une fois le correctif prêt, le processus d'assurance qualité devait prendre 3 jours après le processus d'assurance qualité standard, et la phase de déploiement durerait 48 heures. Suite à la phase de déploiement, nous avons planifié la communication du problème sous la forme d'un article de blog et de notifications aux clients. Ces délais auraient pu être accélérés, mais comme il n'y avait aucune preuve d'exploitation active, nous avons accordé la priorité à la stabilité de notre réseau et veillé à ce que nos clients restent stables tout au long du processus.

Après le triage initial du problème, l'équipe d'ingénierie a abordé le correctif via deux voies, utilisant toutes deux des ressources d'ingénierie et d'assurance qualité différentes. 

Une équipe a étudié et développé un correctif partiel pour le problème, clôturant le problème signalé et limitant les exigences sur le traitement des réponses SAML à ce que nous croyons être la présentation normale d'une réponse SAML avec une assertion. Cette méthode a peut-être entraîné le refus de certaines réponses de certains IdP, même si elles étaient valides et sûres. Cette approche offrait également la possibilité de désactiver la vérification plus stricte par client pour permettre au reste de la clientèle d'être protégée en cas d'interaction inattendue avec un petit nombre d'IdP.

L'autre équipe a adopté une approche similaire à celle de la première équipe, mais plutôt qu'une solution configurable et partielle, elle a travaillé sur ce que nous estimons être une solution complète. Son approche a été examinée de près pour s'assurer que toutes les réponses SAML bien formées et correctement signées seraient acceptées, réduisant ainsi la complexité requise pour permettre aux clients d'être déclassés.

Nous avons adopté cette approche simultanée, car elle permettait de bloquer un chemin ou de lancer des défis d'assurance qualité tout en permettant le déploiement d'un correctif. Tard dans la journée du 24 février, heure de l'est des États-Unis, nous nous attendions à ce que le correctif partiel soit prêt pour l'assurance qualité trois jours après le début de l'incident, tandis que le correctif complet avait besoin d'une semaine de plus pour être développé. Les travaux se sont poursuivis pendant la nuit jusqu'au 25 février. Le rapport d'avancement de l'équipe d'ingénierie a alors montré que l'option de réparation complète progressait bien et qu'elle devrait finalement être plus rapide à développer et moins complexe à tester.

En fin de compte, l'option de réparation complète a été transmise à l'équipe d'assurance qualité environ un jour avant la réparation partielle. Une fois que la première option a été remise à l'équipe d'assurance qualité, une notification de correctif a été envoyée à tous les clients d'EAA afin d'indiquer le délai de déploiement prévu.

Ce statut est resté le même tout au long du processus d'assurance qualité. Avec une légère avance sur la fenêtre de maintenance, le correctif complet a été approuvé par l'équipe d'assurance qualité, ouvrant la voie à son déploiement.

Le processus de déploiement a commencé avec un point de présence très légèrement chargé sur lequel  nous avons exécuté une suite de régression étendue en surveillant attentivement le trafic afin de détecter les perturbations potentielles pour les clients. Un autre point de présence légèrement chargé a été amélioré, avec un processus de test réduit et une période de surveillance. Aux premières heures de la journée du 2 mars, les points de présence servant au déploiement interne d'EAA d'Akamai ont été mis à niveau pour permettre d'effectuer davantage de tests de charge auprès de nos quelque 8 000 utilisateurs finaux. Lorsque nous avons constaté qu'aucun problème de déploiement ne s'était présenté jusqu'à ce stade, les autres points de présence ont été mis à niveau au cours des 36 heures restantes de la fenêtre de maintenance, achevant le processus de déploiement avant la clôture de la fenêtre de maintenance. 

Au cours du processus de mise à niveau, la plupart des utilisateurs qui interagissaient avec leurs applications d'EAA ont probablement vu une ou plusieurs interactions de ré-authentification.  Il s'agissait généralement d'une interruption temporaire de session et d'une redirection vers leur IdP afin de saisir leurs informations d'identification avant d'être renvoyé à leur travail normal. Les utilisateurs d'EAA Client ont également pu rencontrer ce comportement. Les tentatives de ré-authentification ont été mises en cluster par les clients d'EAA pendant le déploiement. Suite à la mise à niveau du code sur chaque point de présence, le cache de session géré par EAA a été effacé, ce qui a déclenché, sur une fenêtre de 5 minutes, une ré-authentification pour toutes les requêtes. Après la ré-authentification, nous n'avons observé aucun impact supplémentaire sur les utilisateurs finaux.

Gérer l'équipe chargée des incidents

Un aspect clé du développement, de la vérification et du déploiement sécurisé de correctifs sur notre réseau pour des problèmes importants comme celui-ci est l'attention particulière portée à la prise en charge de l'équipe travaillant sur un problème. Le processus de gestion des incidents d'Akamai et la formation qui l'accompagne comprennent des conseils sur la façon de limiter l'épuisement professionnel des équipes techniques et de gestion qui interviennent en cas d'incident. Ces directives comprennent la vérification que l'équipe chargée de l'incident :

• mange (régulièrement),
• dort (idéalement une « nuit » complète de sommeil),
• tend à ses obligations personnelles,
• reste en bonne santé (vaccins de COVID-19, exercices).

Bien que la résolution de l'incident en cours soit essentielle, nous constatons que le suivi des soins de l'équipe pendant l'ensemble du processus aide à atteindre un destin plus sûr pour le produit et/ou le système concerné, tout en réduisant le nombre d'erreurs évitables et d'événements pouvant affecter les clients, souvent associés à une réponse à un incident impliquant un niveau de stress élevé.

Un autre aspect clé du processus de gestion des incidents d'Akamai est le principe selon lequel nous sommes tous impliqués et ne blâmerons personne, aujourd'hui ou à l'avenir. L'équipe chargée de l'incident travaille conjointement pour résoudre le problème, quel qu'il soit, de la meilleure façon possible, en se concentrant d'abord sur la réduction de son impact, puis en trouvant comment l'empêcher de se reproduire. Akamai se concentre sur la recherche des hypothèses ayant mené à un incident, sur les leçons tirées de ces hypothèses incomplètes et sur les modifications appropriées pour réduire les risques que cet événement ou des événements similaires se reproduisent.

Actions requises

Les propriétaires de systèmes qui dépendent de Lasso pour leur authentification SAML devraient appliquer un correctif dès que possible. Des actions supplémentaires peuvent être nécessaires pour étudier l'impact sur les systèmes authentifiés. Vous trouverez de plus amples informations sur les actions requises dans la section Actions requises de l'article complémentaire à cet argumentaire.

Chronologie