GitHACK ! Nous sommes la vulnérabilité

Github piraté ? Pour la plupart, cela ne semble pas trop déraisonnable, car les grandes entreprises technologiques et les petites ont déjà été piratées. Cependant, cela ne signifie pas que le capot probable du piratage de Github est élevé. Pourquoi donc? Github est le principal référentiel de code ouvert pour tous dans l'industrie informatique.

Quel que soit le sous-secteur. Même si quelqu'un fait des systèmes embarqués, du développement Web3, du développement Web2, de la science des données, etc., la plupart utiliseraient Github pour stocker leur code. C'est pour cette raison que la sécurité de Github a toujours été extrêmement élevée. Non seulement parce qu'ils voulaient que leurs utilisateurs leur fassent confiance, mais aussi parce que le code sur les référentiels Github de leurs utilisateurs est rempli de clés privées crypto, de clés privées API, d'informations d'identification financières et même de logiciels propriétaires de plusieurs entreprises de l'industrie informatique à l'échelle mondiale. C'est pour cette raison que Github a toujours été dur avec sa sécurité et l'accessibilité des utilisateurs, c'est pourquoi leur piratage, bien que pas complètement surprenant, est très surprenant et inquiétant.

Contexte du Githack :

De quel type d'attaque de piratage s'agissait-il ? Il s'agit d'une attaque de malware. Il ne s'agit donc pas d'une attaque DDoS traditionnelle ou d'une attaque par pénétration forcée à laquelle on aurait pu s'attendre, mais potentiellement plus mortelle. Le pirate / les pirates ont téléchargé un logiciel malveillant répandu sur différents référentiels de la plate-forme.

Que fait le Malware ? il copie toutes les informations financières, les informations d'authentification et les clés cryptographiques privées, essentiellement l'ENV du script. Ensuite, une fois accepté dans le référentiel et exécuté localement sur les ordinateurs alors affectés, il copiera et enverra les informations à l'attaquant. Il ne s'agit donc pas d'un piratage au sens traditionnel, mais bien d'un piratage, car les informations étaient toujours extraites par des moyens de violation de données non consensuels.

Quelle est l'ampleur de l'attaque de piratage ? cette tentative de piratage particulière a atteint pas plus et pas moins de 35 000 dépôts Github. Il a infiltré des référentiels tels que le repo python, le repo golang, le repo docker et le repo bash. Certains des référentiels concernés étaient même archivés et inutilisés. Certains ont même été vus avec le logiciel malveillant à l'intérieur dès 2015. Cela indique que le piratage était bien documenté et planifié.

Comment s'infiltre-t-il dans les dépôts Github ? Il est ajouté aux référentiels Github via un commit et dans le commit via des scripts npm ou différentes classifications d'images docker. Ainsi, vous ne seriez principalement vulnérable que si votre projet utilisait javascript d'une manière ou d'une autre. Ensuite, si le commit est accepté et est cloné et utilisé dans le référentiel principal, les utilisateurs qui l'ont cloné seront affectés.

Comment empêcher cela ?

Au moment où je tape sur cet incident, toutes les parties impliquées dans le nettoyage, les propriétaires du référentiel et Github, sont déjà en train de contrôler les dégâts et de s'assurer que cela ne se reproduise plus. Nous ne pouvons que spéculer et nous demander quelles seront les différentes techniques de sécurité et défenses que Github utilisera pour se protéger des futures attaques. En tant que tel, nous devons nous concentrer sur nous en tant qu'individus ou groupes. Que pouvons-nous faire en notre propre capacité pour arrêter de futurs vols de données comme celui-ci ?

• N'acceptez pas les demandes push de personnes aléatoires vers votre référentiel. Je sais que cela pourrait être plus difficile pour la plupart des grands projets open source. Cependant, soyez prudent lorsque vous acceptez des requêtes push, surtout si les requêtes push modifient les variables d'environnement de votre application.

• Vérifiez toujours exactement ce que vous clonez à partir d'un référentiel git. Je sais que la plupart d'entre nous ne le font pas activement. Tout simplement parce que les référentiels contiennent tellement de fichiers et de dossiers qu'il sera fatigant d'en garder une trace et de les analyser un par un. Il serait donc judicieux de vérifier les fichiers les plus importants tels que les fichiers readme et .env.

• Utilisez les tests de sécurité dans les demandes push. Github dispose en fait d'un cadre de sécurité, piloté par Githook, qui vous permet d'envoyer des requêtes de publication HTTP lorsque certains événements sont rencontrés lors de la requête push. Il existe différentes technologies qui peuvent analyser votre demande push ou pull pour détecter les vulnérabilités de sécurité, les virus courants et d'autres types de failles de sécurité dans votre code.

Dans l'ensemble, que ce soit une leçon pour nous tous. Les attaques que les organisations/personnes néfastes peuvent commettre ne sont pas seulement rudimentaires mais aussi avancées et très inconditionnelles ainsi que planifiées à long terme. En tant que développeurs, nous devons être plus conscients des vulnérabilités de notre code, de nos référentiels, de nos ordinateurs et même de nous-mêmes et du fait que si quelqu'un veut des informations, il peut trouver des moyens très différents de les obtenir. Même si Internet doit être sûr, cela ne veut pas dire qu'il l'est. Il appartient à chacun de faire sa part pour sécuriser vos propres données et, si vous le pouvez, de trouver des moyens d'aider les autres à protéger leurs données.

Pour en savoir plus sur la situation, rendez-vous ici : https://www.bleepingcomputer.com/news/security/35-000-code-repos-not-hacked-but-clones-flood-github-to-serve-malware/