On peut être compromis sans vulnérabilité — la réalité des attaques « fondées sur la confiance » visant les développeurs open source
(cybersecuritynews.com)Les développeurs open source font face à un nouveau type de menace. Il ne s’agit ni d’exploits complexes ni de vulnérabilités zero-day, mais d’attaques d’ingénierie sociale qui prennent pour arme la « confiance » même au sein des communautés de développeurs.
Les attaquants mènent actuellement sur Slack une campagne dans laquelle ils se font passer pour une personne bien réelle de la Linux Foundation afin d’inciter à installer un fichier malveillant.
Déroulement des faits
Cette attaque a été révélée pour la première fois le 7 avril 2026, lorsque Christopher « CRob » Robinson, CTO et architecte sécurité en chef de l’OpenSSF (Open Source Security Foundation), a publié un avis à haut risque sur la mailing list OpenSSF Siren.
L’attaque visait l’espace de travail Slack du TODO Group, un groupe de travail rattaché à la Linux Foundation, ainsi que des communautés open source associées. Le TODO Group rassemble des praticiens des Open Source Program Offices (OSPO).
Les attaquants ont soigneusement construit une fausse identité imitant un dirigeant connu de la Linux Foundation, puis ont envoyé aux victimes des DM Slack contenant des liens de phishing hébergés sur Google Sites, une plateforme à laquelle de nombreux développeurs accordent leur confiance.
L’équipe d’analyse de Socket.dev a été la première à enquêter sur cette attaque et à en documenter le fonctionnement technique. L’enquête a confirmé qu’il ne s’agissait pas d’une simple tentative de phishing, mais d’une opération en plusieurs étapes conçue pour exploiter la confiance profonde qui se forme naturellement dans la communauté open source.
L’appât : « Vous pouvez savoir à l’avance si votre PR sera mergée »
Le message des attaquants était conçu avec beaucoup de soin. En usurpant l’identité d’un dirigeant de la Linux Foundation, ils présentaient un outil d’IA exclusif capable d’analyser la dynamique des projets open source et de prédire quelles contributions de code (PR) seront mergées avant même qu’un reviewer ne les examine.
Le message insistait sur la rareté en expliquant que l’outil n’était « partagé qu’avec un petit nombre de personnes pour l’instant », et fournissait avec le lien de phishing une fausse adresse e-mail ainsi qu’une clé d’accès pour donner l’apparence d’un véritable workspace.
Analyse étape par étape de l’attaque
L’attaque se déroule en quatre phases :
Étape 1 — Usurpation d’identité (Impersonation)
Copie du profil Slack d’une personne réelle de la Linux Foundation afin d’établir une relation de confiance.
Étape 2 — Phishing
Incitation à cliquer sur un lien de phishing hébergé sur Google Sites. Une fausse page, qui imite un flux d’authentification légitime, vole l’adresse e-mail et le code d’authentification.
Étape 3 — Collecte d’identifiants (Credential Harvesting)
Une fois les identifiants volés, le site de phishing pousse la victime à installer un certificat racine malveillant déguisé en « certificat Google ».
Étape 4 — Déploiement du malware (Malware Delivery)
Une fois le certificat racine installé, les attaquants peuvent intercepter discrètement le trafic chiffré entre l’appareil de la victime et l’ensemble des sites web.
Mécanisme d’infection selon les plateformes
macOS
Après l’installation du certificat racine malveillant, un script télécharge automatiquement depuis l’IP distante (2.26.97.61) un binaire nommé gapi, puis l’exécute. Ce binaire donne aux attaquants le contrôle total de l’appareil, y compris l’accès aux fichiers, le vol d’identifiants supplémentaires et l’exécution de commandes à distance.
Windows
L’installation du certificat malveillant est encouragée via une boîte de dialogue de confiance du navigateur et, une fois celle-ci effectuée, l’interception du trafic chiffré devient de la même manière possible.
Recommandations de l’OpenSSF
L’OpenSSF a recommandé aux développeurs actifs dans les communautés Slack open source de :
- Vérifier l’identité hors bande (out-of-band) : ne pas se fier uniquement au nom affiché ou à la photo de profil sur Slack, et confirmer l’identité via un canal distinct déjà connu
- Refuser toute demande d’installation de certificat racine : ne jamais installer de certificat racine à partir d’un lien reçu par chat ou par e-mail. Un service légitime ne le demandera pas
- Activer la MFA : cela permet de limiter l’impact même si des identifiants sont compromis
À retenir
Cette attaque mérite l’attention parce qu’elle ne vise pas une vulnérabilité technique, mais la structure de confiance même de la communauté comme vecteur d’attaque. Dans des écosystèmes étroits comme l’open source, il est facile de baisser la garde face à un nom familier et à une proposition crédible.
L’appât consistant à « prédire par IA si une PR sera mergée » montre aussi le degré de sophistication de cette attaque, tant il peut être séduisant pour les développeurs. Face à un lien inconnu ou à une demande d’installation de certificat racine, il faut garder le réflexe de douter une fois de plus, même si la source semble digne de confiance.
Cet article est une traduction et adaptation de l’original de Cyber Security News.
Aucun commentaire pour le moment.