2 pièce(s) jointe(s)
Les erreurs de configurations sur des repos .git ont laissé près de 400k sites vulnérables à des vols de data
Les erreurs de configurations sur des repos .git ont laissé près de 400 000 sites vulnérables à des vols de données,
selon un chercheur
Vladimír Smitka, un chercheur tchèque en sécurité, a souligné que la configuration des sites Web, en particulier si les développeurs se servent d’un git pour le déployer et le gérer, peut représenter un problème important. Smitka a récemment analysé 230 millions de sites « intéressants » dans le monde entier sur un mois et a trouvé 390 000 pages Web avec un répertoire .git ouvert.
« Il s’agit là d’un problème vicieux car il est possible d’obtenir des fichiers actuels et passés contenant de nombreuses informations sur la structure du site Web. Parfois, vous pouvez obtenir des données très sensibles telles que mots de passe, clés API, paramètres IDE de développement, etc. Cependant, ces données ne doivent pas être stockées dans le référentiel, mais dans les analyses précédentes de divers problèmes de sécurité, j'ai trouvé de nombreux développeurs qui ne suivent pas ces meilleures pratiques », s’est indigné le chercheur.
Et de préciser que « Si vous utilisez git pour déployer votre site, vous ne devez pas laisser le dossier .git dans une partie du site accessible au public. Si vous l'avez déjà pour une raison quelconque, vous devez vous assurer que l'accès au dossier .git est bloqué du monde extérieur. Vous pouvez facilement vérifier ces règles en essayant d'ouvrir <site Web>/.Git/HEAD - si la configuration est correcte, cela ne devrait pas fonctionner. Cette vulnérabilité est très délicate et peut être facilement négligée. Si vous ne visitez que <site web>/.Git/ directement, vous obtiendrez une erreur HTTP 403 dans la plupart des cas.
« Il peut sembler que l'accès soit refusé, mais ce n'est qu'un faux sentiment de sécurité. En fait, l'erreur 403 est provoquée par la fonctionnalité manquante index.html ou index.php et autoindex désactivée. Cependant, l'accès aux fichiers est toujours possible. Si vous l'essayez et que la structure des répertoires apparaît, le problème est encore pire et le référentiel peut être téléchargé beaucoup plus facilement et peut être trouvé sur Google. Le référentiel git a une structure bien connue, vous pouvez donc simplement télécharger des fichiers individuels et analyser les références aux objets / packs individuels dans le référentiel. Ensuite, vous pouvez les télécharger via la demande directe. Cette méthode vous permet de reconstruire une grande partie du repo. Il y a même des outils qui vous permettent d'automatiser cela - GitTools ».
En clair, avec ces problèmes de configuration, un attaquant pourrait utiliser cet accès pour reconstruire lentement le référentiel git d'un site ou explorer quelles bibliothèques sont utilisées, et de là découvrir les vulnérabilités potentielles.
Il a lancé une analyse globale après avoir effectué une analyse plus fine des sites tchèques et slovaques, qui lui ont permis de trouver plus de 2 000 sites avec des dossiers .git exposés dans une partie du site accessible au public.
Sur certains des sites exposés, il a trouvé des mots de passe de base de données et des uploaders non authentifiés
Mais ce qui l’a poussé à lancer un scan au niveau mondial était le fait qu’il était relativement facile de trouver les coordonnées des propriétaires des sites tchèques et slovaques concernés pour résoudre le problème.
Normalement, <site Web>/.Git/HEAD ne doit pas être accessible au public, mais sur des sites vulnérables ce répertoire l’est. De plus, il contient une liste de commits et de détails sur les contributeurs, y compris leurs adresses électroniques.
Il faut noter que ses alertes ont été traitées assez rapidement. Un mois après avoir envoyé 2 000 alertes, il a à nouveau analysé les sites et a trouvé que les dossiers .git n'étaient accessibles que sur 874 sites, soit un taux de réussite de 55%.
Après avoir terminé l'analyse mondiale, il a envoyé un autre lot de 90 000 courriels aux administrateurs de sites concernés, dans lesquels il les a dirigé vers sa page où il a décrit le problème ainsi que les étapes à suivre pour les atténuer.
« Juste pour clarifier la situation, je n'ai pas piraté votre site », souligne Smitka dans son message. « Je suis un chercheur en sécurité / white hat / hacker éthique et j'ai seulement détecté un problème de sécurité sur votre site Web. Aucune donnée sensible n’a été téléchargée depuis votre site, à l’exception de votre adresse e-mail, qui sera oubliée après la recherche. Je ne la stockerai pas et je ne l’utiliserai à aucune autre fin ».
Dans la plupart des cas, ses alertes par e-mail ont été bien reçues, entraînant 300 messages supplémentaires provenant des parties concernées et 2 000 courriels de remerciement.
Cependant, l’un des bénéficiaires l’a menacé d’appeler la police canadienne, deux autres l’ont accusé d’être un spammeur.
Si le but principal était déjà accompli, par curiosité, il a cherché également les technologies utilisées sur les sites vulnérables. En voici les conclusions
Source : billet du développeur
Voir aussi :
:fleche: Une erreur de configuration sur un bucket Amazon S3 a exposé des infos de GoDaddy, le plus grand bureau d'enregistrement de noms de domaine du monde
:fleche: La Chine déploie des drones de surveillance ressemblant à des oiseaux, qui pourraient induire en erreur même les systèmes de radar les plus sensibles
:fleche: L'application de messages de Samsung enverrait des photos par erreur à des contacts, à cause d'un bogue dans sa dernière version
:fleche: Microsoft fait le point sur ses contributions dans les performances de Git en 2017, quelle est celle qui vous intéresse le plus ?
