- Le Threat Analysis Group (TAG) de Google a récemment confirmé des attaques visant des chercheurs en sécurité, ainsi que l’existence d’une vulnérabilité zero-day exploitée à cette fin.
- La vulnérabilité zero-day a été signalée à l’éditeur concerné, et un correctif est en cours de déploiement.
- Les attaquants nord-coréens ont activement échangé avec leurs cibles via les réseaux sociaux comme Twitter afin d’établir une relation de confiance.
- Dans un cas réel, ils ont discuté pendant plusieurs mois avec un chercheur en sécurité au sujet de centres d’intérêt communs, gagnant progressivement sa confiance.
- Ils sont ensuite passés à une application de messagerie chiffrée, où ils ont envoyé un fichier malveillant contenant au moins une vulnérabilité zero-day dans un package logiciel populaire.
- Une fois l’exploitation réussie, le shellcode effectuait des vérifications de machine virtuelle et envoyait diverses informations vers les serveurs des attaquants, selon une méthode similaire à celles observées dans de précédentes attaques nord-coréennes exploitant des vulnérabilités.
- En plus des attaques ciblées via des vulnérabilités zero-day, ils ont également développé un outil open source de rétro-ingénierie et l’ont publié sur Github.
- Ce programme a été publié pour la première fois le 30 septembre 2022, puis a fait l’objet d’un développement actif avec plusieurs mises à jour.
- Cependant, cet outil contenait une porte dérobée permettant de télécharger et d’exécuter du code arbitraire depuis les serveurs des attaquants.
- TAG recommande à toute personne ayant utilisé cet outil d’inspecter son système et, si nécessaire, de réinstaller l’OS.
- Tous les sites web et domaines malveillants identifiés ont été ajoutés à Google Safe Browsing, et une alerte d’attaque soutenue par un gouvernement a été envoyée aux comptes Google susceptibles d’avoir été affectés.
- Tous les domaines, fichiers et comptes malveillants, notamment dbgsymbol, blgbeach et @Paul091_, ont également été divulgués.
5 commentaires
Les attaques ciblées sont effrayantes, mais il faut sans doute être encore plus vigilant face à l’injection de code malveillant dans des projets open source.
Le code source de l’outil en question était normal, mais les fichiers inclus dans la GitHub Release contenaient, eux, du code malveillant.
Il y aurait même eu plus de 200 étoiles sur GitHub...
On dirait que les actualités liées à la sécurité s’enchaînent soudainement. Vous devriez tous faire attention à la sécurité.
Le code source semble malgré tout pouvoir être vérifié, mais je n’avais pas imaginé que cela puisse être différent de la release. La sécurité n’a vraiment pas de fin...
Je suppose que cela ressemble aussi à une forme d’attaque de la chaîne d’approvisionnement.
Justement, dans le cas de Go 1.21.0, publié il y a un mois, ils avaient mis en ligne sur leur blog un billet expliquant que, pour la première fois, le résultat de compilation de leur toolchain était entièrement reproductible. Les deux premiers paragraphes de cet article sont les suivants.
Perfectly Reproducible, Verified Go Toolchains
> L’un des principaux avantages des logiciels open source est que n’importe qui peut lire le code source et en examiner le fonctionnement. Mais comme la plupart des logiciels, y compris les logiciels open source, sont téléchargés sous forme de binaires compilés, ils sont beaucoup plus difficiles à inspecter. Pour un attaquant qui veut mener une attaque de la chaîne d’approvisionnement contre un projet open source, la méthode la moins visible consiste à remplacer les binaires distribués sans modifier le code source.
>
> La meilleure façon de se défendre contre ce type d’attaque est de rendre les builds des logiciels open source reproductibles, c’est-à-dire de faire en sorte qu’un build lancé à partir de la même source produise toujours exactement le même résultat. Ainsi, n’importe qui peut compiler à partir de la source réelle et vérifier que le binaire reconstruit est bit à bit identique au binaire publié, afin de s’assurer qu’aucune modification cachée n’a été introduite dans le binaire diffusé. Cette approche permet de prouver qu’un binaire ne contient ni porte dérobée ni autre modification absente du code source, sans avoir à le désassembler ni à en inspecter l’intérieur. Comme tout le monde peut vérifier le binaire, des groupes indépendants peuvent détecter et signaler facilement les attaques de la chaîne d’approvisionnement. (Traduction DeepL)
Je me demandais bien pourquoi ils se préoccupaient de ce genre de choses, et il semble qu’en réalité ce type d’attaque se produisait déjà discrètement depuis environ un an. Quel monde inquiétant…
Moi aussi, j’ai tendance à faire un peu plus confiance à ce qui est publié sur GitHub avec le code... Il va falloir faire attention.
Il n’y a peut-être pas d’autre solution que de toujours relire le code et de le compiler soi-même...
Résumé IA du fil HN