Connexion Premium

GitHub s’est fait dérober des données de plusieurs milliers de ses dépôts privés

Alerte de sécurité : les dépôts publics sont toujours accessibles… publiquement !

GitHub s’est fait dérober des données de plusieurs milliers de ses dépôts privés

Illustration : Flock

GitHub reconnait s’être fait dérober des données de 3 800 dépôts privés, mais uniquement ses propres dépôts, pas ceux de ses clients. TeamPCP a revendiqué l’attaque et propose les données à la vente.

Dans un message publié sur X, GitHub reconnait avoir été piraté. Plus exactement, la plateforme explique « enquêter sur un accès non autorisé aux dépôts internes de GitHub ». Les dépôts privés de ses clients ne semblent pas concernés : « Nous n’avons actuellement aucune preuve d’impact sur les informations client stockées en dehors des dépôts internes de GitHub », explique la plateforme.

GitHub se fait pirater à cause d’une extension VS Code

Dans un second temps, elle a précisé que la compromission venait « de l’appareil d’un employé avec une extension Visual Studio Code empoisonnée ». Les extensions peuvent être installées depuis le VS Code Marketplace, mais aussi via des boutiques tierces ou manuellement.

GitHub ne précise pas comment l’extension compromise avait été installée. La plateforme ne donne pas son nom et n’entre pas davantage dans les détails. L’extension a évidemment été supprimée et des mesures ont été prises pour limiter les dégâts.

La société affirme de nouveau que l’exfiltration des données ne concernait que des dépôts internes à l’entreprise. De plus, « les affirmations actuelles de l’attaquant concernant environ 3 800 dépôts sont globalement cohérentes avec les résultats de notre enquête jusqu’à présent », ajoute l’entreprise. Un rapport complet sera publié une fois l’enquête terminée.

TeamPCP revendique le piratage et demande 50 000 dollars

Quelques heures avant la publication du message de GitHub sur X, le groupe de pirates TeamPCP affirmait sur un forum spécialisé avoir accédé aux « codes source et organisations internes de GitHub ». Il était question d’environ 4 000 dépôts privés. TeamPCP demandait une rançon de 50 000 dollars, comme le rapporte Bleeping Computer.

Enfin, selon les pirates, ce n’est pas de l’extorsion : « Comme toujours, il ne s’agit pas d’une rançon. Nous ne cherchons pas à extorquer GitHub. Un seul acheteur et nous détruisons les données de notre côté. Notre retraite approche, donc si aucun acheteur n’est trouvé, nous les diffuserons gratuitement ».

Comme le rappellent nos confrères, TeamPCP est très actif ces derniers temps avec quelques prises importantes (revendiquées et/ou attribuées). C’est notamment le cas de Trivy/LiteLLM et de Xinference sur PyPI, avec des répercussions en cascade.

Dans le premier cas, la compromission de Trivy avait conduit au piratage de la Commission européenne fin mars : « Nous estimons avec un degré de confiance élevé que l’accès initial a été obtenu grâce à la compromission de la chaîne d’approvisionnement de Trivy, qui a été publiquement attribuée à un acteur malveillant connu sous le nom de TeamPCP », expliquait le CERT-EU.

Commentaires (11)

votre avatar
"Comme toujours, il ne s’agit pas d’une rançon." 😅

LOL

C'est la mode, les criminels qui essaient de se faire passer pour des gentils et se donner bonne conscience ? Parce que vous comprenez, les temps sont durs ? 🤔

Autant je peux comprendre le SDF qui a faim et ne bénéficie d'aucune aide alimentaire, qui va piquer de la bouffe en magasin pour survivre, autant, les mecs en col blanc ou non, qui nous sortent des excuses... 😭
votre avatar
Donc encore une sorte d’attaque par chaîne d'approvisionnement (indirecte ?)

Ça devient anxiogène.
J'ai désinstallé nodeJS de mon poste y a quelques semaines.
Depuis quelque temps des mises à jour de sécu très régulière sur les serveurs avec des reboot en urgence pour mettre en place les nouveaux kernel.

Moi perso je fatigue, personne n'est à l'abri. Ok on le savait déjà mais disons que les preuves s’accumule ces derniers temps.
votre avatar
Au final, on va tous bosser hors ligne sur nos postes de travail, avec un p'tit serveur local qui rappatrie et distribue les MAJS. 😁
Machine de boulot ? Rien d'autre ne sort ni ne rentre. 😅
Une VM par outil pour tout cloisonner, une usine à gaz ingérable. 😂
votre avatar
J'ai fait une petite mission chez Orange y-a un peu plus de 20 ans et on avait pas accès à internet sur le plateau.
Normal, mais j'avoue ne jamais m'être posé la question depuis que j'ai ma boite :D ...
Ho merde ce serait vraiment la loose :ooo:
votre avatar
x2Go pour l'accès à un browser depuis un conteneur dédié ? 😁
votre avatar
utiliser des devcontainer devrais suffire
votre avatar
utiliser des devcontainer devrais suffire
Pour autant que j'ai bien lu, les exploits récents d'élévation de privilège arrivent potentiellement à sortir des conteneurs Docker... Et rien ne prouve que le prochain exploit ne sera pas d'attaquer les namespaces...
votre avatar
Une VM par outil pour tout cloisonner
j'ai lu "on va utiliser NixOS" :D
votre avatar
Donc encore une sorte d’attaque par chaîne d'approvisionnement (indirecte ?)
C'est cocasse de subir ça côté GitHub alors qu'ils vendent une suite sécurité sur le code...

Cela dit, ça rappelle l'importance de l'approche shift left et qu'il faut aussi sécuriser le poste du développeur. Et avec tous ces éditeurs bardés d'extensions qui viennent d'on ne sait où, c'est une véritable cata tellement l'écosystème est devenu le bordel.
votre avatar
@gg40

L'accélération des mises à jour de sécurité vient deux choses complémentaires selon moi:

  1. La préparation des éditeurs de logiciels tournant en local et des appareils reliés à Internet à la réglementation Européenne CRA.

  2. L'arrivée des nouvelles IA capable de trouver des failles complexes et qui en ont révélé pas mal sur des éléments très utilisés. Après la vague, ces découvertes vont se faire plus rares.



Concernant le CRA, la phase actuelle de préparation se base sur la création systématique et automatisée des nomenclatures logicielles et cryptographique puis leur analyse à minima quotidienne selon les bases de données CVE : ces éditeurs sont désormais rapidement au courant d'une faille dans leurs bibliothèques externes. Ajouté à la création d'un point de contact pour les avertir d'une faille sur leurs propres produits, cela va leur permettre d'être prêt pour l'échéance de septembre: l'obligation de signaler la présence d'une faille exploitée sur leurs produits en 24h maximum dès le 11 septembre prochain.

Les méthodes de travail qui seront obligatoire pour respecter le CRA vont rendre les failles moins probables sauf chez ceux qui continueront de voir la cybersécurité comme un truc non nécessaire. Mais les amandes prévues devraient les faire réfléchir dès maintenant. Je pense que certaines boîtes vont tenter de dépasser l'échéance en douce et diront que c'était trop compliqué mais je ne pense pas que cela se passera aussi bien que pour le RGPD car ils auront alors leurs clients sur le dos en plus des autorités.
votre avatar
Les m-à-j de kernel c'est dingue depuis la 7.x, on est en 7.0.9-r5 (r5 !) tous les 2j y'a une nouvelle version invalidant la précédente qui est masquée !

Edit : et non la 7.0.9-r5 compilée ce matin même a déjà un remplaçant : 7.0.10 :mdr2: