Mackenzie Jackson et Dwayne McDaniel, deux chercheurs en cybersécurité de la société spécialisée GitGuardian, estiment que les commits publics de GitHub recèlent « au moins 10 millions de secrets », soit 67 % de plus que l'an passé, relève SC Magazine.
Par « secrets », ils entendent « tout ce qui permet d'accéder à un autre système ou de déchiffrer des données », qu'il s'agisse de paires nom d'utilisateur/mot de passe, de jetons d'API, d'URL de connexion à une base de données ou de cookies de session de navigateur.
Intervenant à la conférence BSides de Las Vegas, ils ont expliqué que « un utilisateur de GitHub sur 10 a partagé un secret en 2022 », mais également que « 5,5 commits sur 1 000 contenaient un secret », soit 50 % de plus que l'an passé. Les clés d'API de Google, représentant 9,7 % du total, auraient été le secret le plus souvent divulgué en 2022.
Les chercheurs de GitGuardian, qui ont décompilé 50 000 applications Android du Google Play Store, ont également découvert que près de la moitié d'entre elles exposaient des informations d'identification en clair.
Jackson a expliqué qu'il était très simple de vérifier si les applications mobiles contenaient des secrets codés en dur. Il faut d'abord télécharger une application mobile sur un ordinateur, à l'aide d'un logiciel comme GPlayDL (pour Android) ou ipatool (pour iOS).
L'application Android peut être décompilée à l'aide d'un outil appelé JADX ; pour les applications iOS, il suffit de changer le type de fichier .ipa en .zip et de décompresser les fichiers, puis d'utiliser l'application de GitGuardian, GGShield, pour rechercher des informations d'identification.
Commentaires (30)
#1
Oui mais vous comprenez, c’est la faute aux chefs de projets qui n’y comprennent rien, aux spécifications mal branlées, aux prestas, aux timings serrés, au chat de la voisine, au climat…
Ah bah non, en fait : 1 dev sur 10 au moins est inconsistant, et plus encore pour les devs android…
#2
Un grand classique, hélas.
Je dis probablement une bêtise : il n’y a pas moyen d’utiliser ggshield « à l’envers » pour détecter si ce qui va être pushé pour détecter automatiquement si un mot de passe/une clé en clair s’y trouve ?
De la même façon que sur les courriels on me suggère d’ajouter la pièce jointe au cas où je l’aurais oubliée.
#2.1
Il existe des outils pour contrôler le code, qui peuvent être soit appelés avant les push, soit intégrés dans le pipeline de build, voir ajoutés comme plugin dans le repo Git (ça doit exister sur GitHub, mais il faut peut-être la version licenciée…?).
De la même manière, basé sur le ReadMe de GGShield, il peut être intégré dans les pipelines CI/CD.
Évidemment, tout ça suppose d’avoir une chaîne CI/CD, au minimum… pour le type qui a son repo public et qui package avec click droit > package depuis son IDE, on ne peut pas faire grand chose…
#3
Les IPA d’iOS sont en effet des fichiers ZIP.
Les APK d’Android sont aussi des fichiers ZIP. Le renommage enn .zip permet de les décompresser.
#3.1
C’est marrant, moi, je n’ai pas besoin de les renommer pour les décompresser.
#3.2
Tu as peut-être une association de fichiers en place avec ton logiciel d’archivage/désarchivage ?
#3.3
oui, ou clic droit, 7zip –> extraire, ça marche sur n’importe quel type d’extension de fichier compressé :)
#3.4
Peut-être que je n’ai pas un système d’exploitation qui s’appuie sur une règle ridicule de nommage des noms de fichiers pour savoir avec quoi ouvrir un fichier.
#3.6
Même sous Windows, il n’est pas forcément nécessaire de le renommer pour l’ouvrir comme un ZIP. On peut très bien ouvrir directement un DOCX ou un APK dans 7-Zip, par exemple.
#3.7
Oui, je sais.
Mais ce qui m’énerve sur ce sujet, c’est que NXI n’est même plus capable d’avoir un esprit critique sur une manip inutile même sur Windows (le renommage de fichier) avant de le décompresser. Maintenant, on recopie simplement les manips données par d’autre. Heureusement que la manip décrite ne détruit pas le contenu d’un disque !
On peut en déduire cependant que ce n’est pas Vincent qui a écrit la brève.
#3.5
Fred42 veux juste affirmer la «supériorité» de Linux sur Windows (ou la sienne ou les deux :-)
#4
il y a donc eu au moins 10 millions de piratage de systèmes sensibles.
Ou pas.
Si ca se trouve c’est encore une étude publiée par des chercheurs/sociétés de cybersécurité en mal de visibilité. Bref, de la pub.
ah, tiens donc…
#5
Personne n’a dit cela. C’est un risque supplemo. Et Heureusement que dans la plupart des cas ce n’est pas suffisant d’avoir le loggin/mot de pass d’une bdd par exemple pour y avoir accès…
#6
C’est pas strictement en clair s’il a fallu décompiler pour voir l’info :“)
#7
Puis il découvrit horrifié que sur son OS fétiche le mime-type d’un package se basait en fait sur l’extension du fichier.
#7.1
Sauf que ce n’est pas si simple que cela :
renomme un toto. apk en toto et tu l’ouvriras sans souci en double cliquant dessus. La recherche de “magic” est passée par là.
#8
Oui, les commits contiennent des secrets, c’est malheureusement la réalité. Des clés privées, des tokens, des passwords dans du code terraform, j’en passe et des meilleurs, tout ça peut finir malencontreusement dans le commit quand le dev ne fait pas attention.
Et oui, je parle de toi, l’adepte du
git add -Aqui vérifie pas avant ce qu’il ajoute à l’historique. 🫵(presque) Blague à part (ça c’est quand même une réalité observée), c’est aussi pour ça que les solutions techniques sont de plus en plus développées et déployées.. Avec les outils comme GitLeaks, les solutions des hébergeurs comme GitHub et GitLab (qui sont même capables de révoquer automatiquement ou notifier le partenaire de la fuite - ex un clé AWS, une notif est envoyée pour signaler la fuite à Amazon) qui bloquent le push, etc.
Et les tokens dans les artifacts, c’est malheureusement une mauvaise pratique assez répandue aussi…
N’étant pas dev de formation, je ne sais pas si dans les cursus de développement on apprend les rudiments de la sécurité informatique. Mais en tous cas, mon constat est que ça ne doit pas être le cas quand j’observe toutes les mauvaises pratiques que je peux voir au quotidien.
#9
Ca dépend des DE sous Linux, mais généralement ils regardent d’abord leur association extension=logiciel pour ouvrir un fichier avant de recourir au magic byte.
Si tu veux faire l’essai : dans le DE associe un éditeur texte A pour .txt et un éditeur de texte B pour markdown (.md). Techniquement ce sont tout deux des fichiers texte ASCII mais l’association du DE aura la priorité sur le choix du logiciel.
ex : chez moi .txt sera ouvert par VSCodium, .md par Ghostwriter.
#9.1
Ça dépend peu des DE, les principaux appliquent les spécifications de freedesktop.org
Par contre, ça dépend des logiciels installés.
#10
J’ai des secrets (fake) dans mes tests unitaires, est-ce que je fais partie de ces “1 développeur sur 10” mauvais élève selon eux?
#10.1
J’imagine que c’est pour tester des valeurs passées ?
Dans tous les cas il y en a où cela est “justifié” par la finalité du projet. Typiquement, on ne va pas considérer OWASP comme mauvais élève pour avoir créé des projets volontairement vulnérables à des fins de démonstration de pratiques à risques.
Genre Terragoat où les fichiers variables contiennent des credentials AWS ou Azure valides sur le papier (mais révoqués) et autres applications extrêmement vulnérables.
Evidemment, la personne qui souhaite déployer ces applis … Bah have fun. Mais dans ce cas là autant publier ses credentials Cloud sur son profil facebook ou linkedin si le but est de gagner plein de copains Eurasiatiques qui viennent squatter la sub et faire péter les scores du billing
#11
C’est quoi l’interet ? Vraie question ?
#11.1
Il peut y avoir plein de raisons… Par exemple, pour tester une communication en mtls, il va falloir fournir des fakes certifs/clés
#11.2
Oui, mais c’est quoi l’intérêt de les mettre sur un GitHub public ?
#11.3
Je saisis peut-être pas bien la question : pour du code open-source sur github, le repo va contenir les tests unitaires (ou autres), et doit pouvoir fonctionner en autonomie.
Pour répondre à @SebGF: si comme tu proposes les tests dépendent d’un gestionnaire de secrets ça complexifie la mise en place de l’environnement (y compris sur chaque machine de dev qui voudrait lancer localement les tests) et je ne suis pas sûr de voir le bénéfice au final
Précision : je ne parle pas d’un environnement de test persistant, mais bien d’un environnement qu’on setup et shutdown à la volée pour le test
#11.4
OK je vois c’est juste un jeu de test exécuté sur une instance éphémère. Après comme tu l’as dit, les données sont fausses et inexploitables.
Cela dit, les infos de type credential (même fausses) peuvent dans ce cas être passées par injection au moment de l’exec (passées au container via environment par exemple) sur le poste de dev et ainsi éviter de commit ces valeurs aussi inutiles soient-elles. Et ce même sans passer par un gestionnaire de secrets.
#12
eh ben, tu as des vrais problèmes dans la vie !
Je trouve l’explication très utile pour les débutants sur un site qui s’adresse à tout le monde :)
#13
Il ne serait pas possible de les injecter lors du pipeline de test depuis un gestionnaire de secrets ?
#14
Ok je comprends bien l’interet de tests unitaires.
Mais quel intérêt de les laisser ? Dans ma branche on appelle ca du code mort, et c’est interdit. J’imaginais que c’etait une bonne pratique partout.
#14.1
C’est du code de test, donc pas du code mort (?)