Fuite du code source du New York Times, des secrets exposés

Il y a quelques semaines, le New York Times a fait l’objet d’une attaque importante, tous ses dépôts git ayant été divulgués par le biais d’un torrent sur le forum 4chan.

Après des recherches, une grande quantité de secrets, tels que des clés d’API cachés dans le code ont été découverts. Ce sont plus de 4 000 secrets uniques et au moins 200 secrets critiques qui ont été découverts.

Qu’est-ce qui a fuité ?

Au total, plus de 5 600 dépôts de code ont été divulgués. Il serait légitime de se demander comment le New York Times a pu avoir autant de dépôts de code. En réalité, beaucoup d’entre eux sont des dépôts forkés utilisés comme dépendances. Ceci étant dit, il y avait encore un grand nombre de dépôts privés du New York Times, y compris celui du jeu viral Wordle.

Quel est donc le risque de fuite d’un tel code source ? Il y a de nombreuses raisons pour lesquelles il ne faut pas que le code source soit divulgué au grand jour : il peut permettre à des concurrents de créer des copies, et des acteurs malveillants peuvent l’utiliser pour essayer de trouver des vulnérabilités, mais le pire résultat d’une fuite comme celle-ci, ce sont tous les secrets qui peuvent être révélés.

Dans ce contexte, lorsque l’on parle de secrets, il s’agit d’identifiants d’authentification numérique tels que les clés API, les certificats de sécurité et d’autres identifiants.

Les précédentes fuites qui concernaient du code source ont souvent conduit à la divulgation d’un grand nombre de ces secrets. Lors d’une fuite similaire, l’ensemble du code source de Twitch a été divulgué et plus de 6 000 secrets ont été exposés. Il n’est donc pas si surprenant que cela de découvrir autant de secrets dans le code source du New York Times.

Il faut souligner que si aucun secret ne devrait être divulgué, le risque lié à chaque secret varie considérablement, de sorte que tous ces secrets n’entraîneraient pas un risque supplémentaire. En outre, le nombre de vrais secrets est probablement inférieur en raison des limites de la recherche, qui porte spécifiquement sur deux domaines : les « secrets génériques » et la « validation des secrets ».

Secrets génériques : 2 477 des secrets découverts ont été classés dans la catégorie « Autres ». Il s’agit de secrets pour des services difficilement identifiables. Cela signifie que le modèle de la chaîne et le code qui l’entoure correspondent aux exigences d’un secret, mais que la fonction du secret n’a pas pu être déterminée.

C’est dans cette catégorie que l’on trouve le plus grand nombre de faux positifs, mais il est impossible d’en déterminer le nombre sans mener une enquête approfondie sur chaque cas.

Validation des secrets : La meilleure façon d’éliminer les faux positifs lors de la découverte de secrets est de valider les secrets connus. Habituellement, cela se fait en effectuant un appel API non intrusif au service auquel les secrets sont connectés. Par exemple, si une clé AWS est trouvée, il faut faire un appel API à AWS pour la valider. Dans le cas présent, les secrets n’ont pas été validés.

En effet, cela peut être perçu comme une activité malveillante et il ne fallait pas perturber les opérations de cyberdéfense en cours du New York Times. On peut espérer qu’à ce stade, la plupart des secrets avaient été invalidés, ce qui fausserait les résultats.

Quelle a été l’ampleur de la brèche ?

Si le nombre de secrets divulgués est alarmant, il n’est pas anormal. C’est probablement mieux que ce que l’on verrait dans une organisation de taille similaire. Ceci étant dit, il y a certainement beaucoup d’opportunités pour les attaquants.

Au moins 228 des secrets découverts sont considérés comme des clés critiques. Il s’agit notamment de jetons HashiCorp Vault, de clés Auth0 et de clés AWS. Il y a aussi beaucoup de clés de services intéressants comme SendGrid et Mailchimp qui pourraient potentiellement être utilisées pour envoyer des courriels en masse aux abonnés du New York Times.

Cependant, comme ce code source a été partagé publiquement, il est très probable que ces clés aient été depuis révoquées (du moins nous l’espérons), ce qui réduit le risque.

Méthodologie

Analyse de l’ensemble du code 
La première étape a consisté à analyser chaque dépôt git inclus dans la base de code. Après une première analyse, plus de 100 000 candidats secrets et 131 types de secrets différents ont été découverts.

Suppression des données non pertinentes 
La plupart des dépôts étant des forks d’outils open-source, uniquement les secrets commis par une personne utilisant une adresse électronique *@nytimes.com ont été inclus, afin de s’assurer de ne pas inclure des résultats non pertinents. Cela a permis de réduire le nombre de secrets à un total de plus de 48 000 secrets répartis dans 113 catégories différentes. Mais il est possible que certains secrets pertinents aient été oubliés au cours de ce processus.

Suppression des doublons 
Une fois la liste initiale de 48 000 secrets obtenue, tous les secrets en double ont été supprimés pour obtenir un total de 4 875 secrets uniques commis par des développeurs ayant une adresse électronique @nytimes.com. (Il est assez courant que les secrets soient dupliqués plusieurs fois lorsqu’ils se retrouvent dans un VCS comme git, ce qui explique les doublons).

Comment la fuite s’est-elle produite ?

Le New York Times a déclaré que « l’événement sous-jacent lié à la publication de la semaine dernière s’est produit en janvier 2024, lorsqu’un identifiant pour une plateforme de code tierce dans le cloud a été rendue disponible par inadvertance ».

Le New York Times a ensuite confirmé qu’un token GitHub ayant fait l’objet d’une fuite publique était à l’origine de la fuite du code source. Il a également confirmé avoir été alerté de ce problème dès le mois de janvier.

Y a-t-il d’autres fuites ?

En effectuant un audit de sécurité sur le domaine du New York Times, 634 secrets (268 confirmés valides) qui ont été divulgués dans des dépôts GitHub publics par des développeurs du New York Times, principalement sur des comptes personnels ont été trouvés.

Quels sont les risques ?

La fuite de code source privé présente de nombreux risques potentiels. La menace la plus immédiate concerne les secrets codés en dur : s’ils tombent entre de mauvaises mains, un pirate peut se faire passer pour un utilisateur ou un système légitime, compromettre des données et des services, voire lancer des attaques latérales plus sophistiquées.

Mais les risques ne s’arrêtent pas là. Un examen plus approfondi du code divulgué peut révéler des failles logiques ou l’utilisation de dépendances non sécurisées. L’architecture même de l’application exposée peut être précieuse pour les attaquants, en les guidant potentiellement vers des actifs cachés.

Dans ce cas particulier, le New York Times semble avoir agi rapidement pour atténuer ces risques. Il a déclaré : « Il n’y a aucune indication d’un accès non autorisé aux systèmes appartenant au Times ni d’impact sur nos opérations lié à cet événement. Nos mesures de sécurité comprennent une surveillance continue des activités anormales. »

Le New York Times a également confirmé utiliser divers outils de surveillance, permettant à ses équipes de sécurité de prendre des mesures défensives et de révoquer tout identifiant valide ayant fait l’objet d’une fuite.

Un scénario plus grave aurait pu se dérouler si un acteur malveillant avait discrètement découvert les clés d’accès aux dépôts privés sans les rendre publiques. Il aurait alors pu disposer de suffisamment de temps pour découvrir les fuites d’informations d’identification et orchestrer des attaques plus préjudiciables.

Il est très facile de faire fuir du code source. De nombreux développeurs y ont accès et il est stocké à de multiples endroits (VCS, sauvegardes, machines des développeurs, etc.), ce qui lui confère un large rayon d’action. L’enseignement le plus important n’est pas que le code source a été exposé, mais que les entreprises doivent s’assurer qu’elles n’ont pas de secrets exposés dans leur code source.