Début novembre, Sumo Logic signalait une faille de sécurité suite à la compromission d’un compte AWS. L’entreprise a rapidement sécurisé son infrastructure et conseillé à ses clients d’effectuer une rotation de leurs clés d’accès à l’API à titre de précaution, laissant entrevoir des risques potentiels. Mackenzie Jackson, developer advocate GitGuardian, nous explique ce que met en évidence cet incident et les leçons qu’il faut en tirer.
Comment un des comptes AWS de Sumo Logic a–t-il été compromis ?
Sumo Logic a signalé une faille de sécurité, détectée le 3 novembre, impliquant un identifiant compromis qui a permis un accès non autorisé à l’un de leurs comptes AWS. Malgré cela, l’entreprise affirme n’avoir constaté aucun impact sur ses réseaux ou systèmes, et les données de ses clients continuent d’être cryptées. En réponse à l’incident, Sumo Logic a déclaré qu’elle avait « immédiatement sécurisé l’infrastructure exposée et remplacé toutes les informations d’identification potentiellement compromises ». Malgré cela, Sumo Logic conseille à tous ses clients de changer immédiatement toutes les clés d’accès à l’API de Sumo Logic, ce qui indique qu’il existe un potentiel certain pour les attaquants de passer de l’infrastructure de Sumo Logic pour accéder aux tableaux de bord et à la supply chain logicielle de leurs clients, afin d’obtenir potentiellement plus d’informations et d’identifiants. Le 7 novembre, Sumo Logic a également proposé des mesures de précaution supplémentaires, qui ont ensuite été revues à la baisse le 8 novembre. « Les informations d’identification de tiers qui ont été stockées dans Sumo dans le cadre de la configuration de la connexion au webhook ». Encore une fois, cela indique qu’un attaquant aurait pu s’introduire dans le tableau de bord de ses clients.
Comment les attaquants trouvent-ils les secrets divulgués ?
Dans le cas de Sumo Logic, aucune information n’a été fournie sur la manière dont la fuite s’est produite. Après quelques recherches, des exemples de fuites d’identifiants AWS dans des dépôts publics GitHub appartenant à Sumo Logic ont été trouvés. Cependant, ces clés ne sont plus valides, et nous ne pouvons pas être sûrs qu’elles l’étaient au moment où elles ont été divulguées. Bien que rien n’indique que GitHub soit à l’origine de la fuite, cela indique que les clés étaient peut-être mal gérées par les développeurs de Sumo Logic. D’une manière plus générale, les attaquants deviennent de plus en plus sophistiqués dans leur manière de trouver des informations d’identification en ciblant spécifiquement les développeurs qui ont souvent accès au code source, qui contient des secrets. Une augmentation des attaques contre la chaîne d’approvisionnement a été constatée, comme ce qu’il a été vu cette année avec Circle CI ou il y a plusieurs années avec CodeCov.
Comment savoir si les secrets ont été divulgués ?
C’est un des aspects les plus difficiles des fuites de secrets, c’est qu’elles se produisent souvent en dehors de la visibilité des organisations. L’exemple le plus courant est le compte GitHub personnel d’un développeur travaillant pour l’organisation. Désormais, il est possible de savoir si un identifiant a fait l’objet d’une fuite sur GitHub au cours des dernières années. Le service Has My Secret Leaked de GitGuardian utilise un hachage sécurisé des secrets et le compare à une base de données de plus de 20 millions de secrets ayant fait l’objet d’une fuite pour découvrir si ceux-ci ont été publiés sur GitHub au cours des six dernières années.
Pourquoi les fuites de secrets constituent-elles un problème aussi persistant ?
Cette fuite, bien qu’elle ne soit pas très conséquente, montre une tendance à savoir que les secrets (les informations d’identification comme les clés en question ici) sont ciblés par les attaquants. Dans le domaine interconnecté du développement logiciel, les secrets tels que les mots de passe, les clés API et les tokens sont les piliers de la sécurité. Leur fuite présente de graves risques, souvent lourds de conséquences. Non seulement ces secrets permettent à un attaquant de pénétrer dans un système, mais ils fournissent également une méthode de communication valide qui contourne souvent les outils de renseignement sur les menaces, car ils fonctionnent dans les conditions prévues En outre, les secrets donnent souvent accès à d’autres secrets. L’exemple de Sumo Logic est parfait : selon les recommandations de l’entreprise, vous devriez renouveler vos clés d’accès API et toutes les clés tierces stockées chez Sumo Logic, car un attaquant pourrait être en mesure de se déplacer latéralement à travers différents systèmes.
Quelles leçons tirer de cette mésaventure ?
Plusieurs choses :
- L’erreur humaine est le talon d’Achille : Les développeurs peuvent, par inadvertance, inclure des clés dans des référentiels de code ou les partager dans des communications internes qui deviennent ainsi exposées.
- Les systèmes modernes sont complexes: À mesure que les systèmes deviennent plus complexes, le nombre de clés et de secrets se multiplie. Chaque service intégré dans une application exige sa propre clé, ce qui rend encore plus difficile la gestion sécurisée d’un inventaire croissant d’informations sensibles.
- La formation en matière de sécurité est insuffisante : Les développeurs et les professionnels de l’informatique sont soumis à une pression constante pour livrer rapidement. Dans cette course contre la montre, les meilleures pratiques en matière de sécurité peuvent être reléguées au second plan. En l’absence d’une formation régulière et rigoureuse en matière de sécurité, la manipulation correcte des clés API peut être négligée.
- On manque d’outils robustes : Parfois, les organisations ne fournissent pas d’outils robustes pour la gestion des secrets. Les développeurs ont recours à des méthodes de fortune, comme le stockage des clés dans des fichiers de configuration ou des variables d’environnement, qui ne sont pas sûres et peuvent facilement être divulguées par le biais des systèmes de contrôle de version. Cette situation, associée à un manque d’outils de détection de qualité, peut conduire à des fuites non détectées.
- La vue sur la rotation des clés n’est pas optimale : La rotation régulière des clés d’API est une mesure de sécurité essentielle. Cependant, elle est souvent négligée en raison de la surcharge opérationnelle qu’elle engendre. Les clés statiques qui restent inchangées présentent un risque plus élevé de fuite et d’exploitation.
- Le suivi des clés n’est toujours pas une évidence : Dans les opérations à grande échelle, il est difficile de savoir quelles clés sont actives et qui y a accès. Lorsque des développeurs quittent une équipe ou que des comptes de service sont mis hors service, des clés qui devraient être invalidées continuent de passer inaperçues jusqu’à ce qu’elles fassent l’objet d’une fuite éventuelle.
