Meta : des pirates ont volé du code et des données de 1 500 personnes dans ses dépôts GitHub

Meta informe environ 1 500 personnes, en majorité des salariés aux États-Unis, que leurs données personnelles ont été touchées par une intrusion dans certains de ses dépôts GitHub. L'entreprise l'a confirmé à SecurityWeek le 13 octobre, jour où les lettres de notification ont commencé à partir. Selon Meta, un « groupe extérieur », non identifié, a accédé aux dépôts avec les identifiants volés d'un employé. L'intrusion a été détectée quelques semaines plus tôt, sans date précise.

Surtout du code, mais aussi des données mal rangées

D'après Meta, 99 % des données dérobées sont des données d'entreprise, principalement du code source de ses produits. Le 1 % restant contient des informations personnelles, qui n'auraient jamais dû se trouver là : elles ont été déposées dans les dépôts par erreur, contrairement aux règles internes. Meta n'a pas précisé de quel type de données il s'agit. Une bonne partie des données d'apparence personnelle seraient des données de test, fictives ou anonymisées.

Meta affirme qu'il ne s'agit pas d'une faille dans l'un de ses produits et que ses systèmes internes n'ont pas été pénétrés. Selon son enquête, menée avec GitHub, les attaquants n'auraient pas visé spécifiquement ses données. Meta dit avoir notifié les autorités compétentes.

Les mesures prises par Meta

• coupure de l'accès des attaquants et alerte de GitHub et des forces de l'ordre ;
• remplacement des secrets (clés, jetons) trouvés dans les dépôts concernés ;
• nouveaux contrôles pour empêcher le stockage de données d'utilisateurs sur GitHub, et analyse automatique pour repérer celles déposées par erreur ;
• surveillance du crédit et du dark web proposée aux personnes concernées.

Les bons réflexes pour vos propres dépôts

Le scénario n'a rien d'exotique : un identifiant volé suffit pour ouvrir un dépôt de code, qui contient souvent bien plus que du code. Quelques mesures simples réduisent le risque :

• Activer l'analyse des secrets (« secret scanning ») sur vos dépôts et sur l'historique : une clé supprimée d'un fichier reste visible dans les anciennes versions.
• Interdire les vraies données personnelles dans les dépôts et les jeux de test. Si c'est inévitable, utiliser des données réellement anonymisées.
• Exiger une authentification forte (clé de sécurité matérielle de préférence) et des jetons d'accès à durée de vie courte et aux droits limités.
• Surveiller les clonages massifs et les accès inhabituels dans les journaux d'audit de votre plateforme de code.
• Remplacer immédiatement tous les secrets d'un dépôt dès qu'un accès illégitime est soupçonné.