Victor De Schwanberg/Photothèque scientifique via Getty Images
Malgré plus d’une décennie de rappels, d’incitations et de véritables harcèlements, un nombre surprenant de développeurs ne peuvent toujours pas se résoudre à garder leur code exempt d’informations d’identification qui fournissent les clés de leur royaume à quiconque prend le temps de les rechercher.
Ce dysfonctionnement résulte de pratiques de codage immatures dans lesquelles les développeurs intègrent des clés cryptographiques, des jetons de sécurité, des mots de passe et d’autres formes d’informations d’identification directement dans le code source qu’ils écrivent. Les informations d’identification permettent au programme sous-jacent d’accéder facilement aux bases de données ou aux services cloud nécessaires à son fonctionnement comme prévu. J’ai publié un tel message d’intérêt public en 2013 après avoir découvert des recherches simples qui ont révélé des dizaines de comptes qui semblaient exposer les informations d’identification sécuriser les comptes SSH ordinateur-serveur. L’une des informations d’identification semblait donner accès à un compte sur Chromium.org, le référentiel qui stocke le code source du navigateur open source de Google.
En 2015, Uber a appris à ses dépens à quel point cette pratique pouvait être préjudiciable. Un ou plusieurs développeurs du service Ride avaient intégré une clé de sécurité unique dans le code, puis partagé ce code sur une page publique GitHub. Les pirates ont ensuite copié la clé et l’ont utilisée pour accéder à une base de données interne d’Uber et, à partir de là, voler des données sensibles appartenant à 50 000 chauffeurs Uber.
Les avocats d’Uber affirmaient à l’époque que « le contenu de ces fichiers de base de données internes est étroitement gardé par Uber », mais cette affirmation est minée par les moyens utilisés par l’entreprise pour protéger les données, qui ne valaient rien de mieux que de cacher une clé de maison sous un paillasson. .
Le nombre d’études publiées depuis les révélations a souligné à quel point cette pratique était courante et le restait dans les années qui ont immédiatement suivi la mise en garde d’Uber. Malheureusement, la négligence persiste encore aujourd’hui.
Des chercheurs de la société de sécurité GitGuardian cette semaine signalé découvrir près de 4 000 secrets uniques cachés dans un total de 450 000 projets soumis à PyPI, le référentiel de code officiel du langage de programmation Python. Près de 3 000 projets contenaient au moins un secret unique. De nombreux secrets ont été divulgués à plusieurs reprises, portant le nombre total de secrets dévoilés à près de 57 000.
« Exposer des secrets dans des packages open source comporte des risques importants pour les développeurs et les utilisateurs », ont écrit les chercheurs de GitGuardian. « Les attaquants peuvent exploiter ces informations pour obtenir un accès non autorisé, se faire passer pour les responsables du paquet ou manipuler les utilisateurs grâce à des tactiques d’ingénierie sociale. »
Les informations d’identification exposées donnaient accès à une gamme de ressources, notamment des serveurs Microsoft Active Directory qui provisionnent et gèrent les comptes dans les réseaux d’entreprise, des serveurs OAuth permettant l’authentification unique, des serveurs SSH et des services tiers pour les communications clients et les crypto-monnaies. Exemples inclus :
- Clés API Azure Active Directory
- Clés d’application GitHub OAuth
- Informations d’identification de base de données pour des fournisseurs tels que MongoDB, MySQL et PostgreSQL
- Clé de la boîte de dépôt
- Clés d’authentification0
- Informations d’identification SSH
- Informations d’identification Coinbase
- Informations d’identification principales Twilio.
Le transport comprenait également des clés API pour interagir avec divers services Google Cloud, des informations d’identification de base de données et des jetons contrôlant les robots Telegram, qui automatisent les processus sur le service de messagerie. Le rapport de cette semaine indique que les expositions dans les trois catégories ont augmenté régulièrement au cours des deux dernières années.
Les secrets ont été exposés dans différents types de fichiers publiés sur PyPI. Ils comprenaient des fichiers .py principaux, des fichiers README et des dossiers de test.
GitGuardien
GitGuardian a testé les informations d’identification exposées et a constaté que 768 restaient actives. Le risque peut toutefois s’étendre bien au-delà de ce chiffre plus restreint. GitGuardian a expliqué :
Il est important de noter que ce n’est pas parce qu’un titre ne peut pas être validé qu’il doit être considéré comme invalide. Ce n’est qu’une fois qu’un secret a été correctement alterné que vous pouvez savoir s’il est invalide. Certains types de secrets que GitGuardian s’efforce toujours de valider automatiquement incluent les jetons Hashicorp Vault, les jetons d’authentification Splunk, les informations d’identification du cluster Kubernetes et les jetons Okta.
Il n’y a aucune bonne raison d’exposer les informations d’identification dans le code. Le rapport indique que la cause la plus courante est accidentelle.
« Au cours de la sensibilisation à ce projet, nous avons découvert au moins 15 incidents au cours desquels l’éditeur ignorait qu’il avait rendu public son projet », ont écrit les auteurs. « Sans citer de noms, nous voulions mentionner que certains d’entre eux provenaient de très grandes entreprises dotées de solides équipes de sécurité. Les accidents peuvent arriver à n’importe qui. »
Au cours de la dernière décennie, divers mécanismes sont devenus disponibles pour permettre au code d’accéder en toute sécurité aux bases de données et aux ressources cloud. L’un d’eux concerne les fichiers .env qui sont stockés dans des environnements privés en dehors du référentiel de code accessible au public. D’autres sont des outils tels que AWS Secrets Manager, Secret Manager de Google Cloud ou Azure Key Vault. Les développeurs peuvent également utiliser des scanners qui vérifient le code pour détecter les informations d’identification incluses par inadvertance.
L’étude a examiné PyPI, qui n’est qu’un des nombreux référentiels open source. Au cours des années passées, le code hébergé dans d’autres référentiels tels que NPM et RubyGems a également été exposé à des informations d’identification, et il n’y a aucune raison de soupçonner que cette pratique ne se poursuit pas aujourd’hui.
