Sécurité info - Page 69

SSH compromis, sérieux ?

Sérieux, oui. Même si c'est seulement sur les (certaines ?) distros rolling release dont les utilisateurs les ont mises à jour "récemment" (avec une version 5.6.0 ou 5.6.1 des sources xz, et donc des packages binaires qui en découlent, pour la plupart des distros), ça semble très grave: pre-auth RCE, d'après qui relaie le message d'un bon chercheur en sécurité, que je connaissais plutôt pour des aspects cryptographie, et aussi pour être une bonne plume, mais ses compétences peuvent évidemment être plus larges.

Tout ça à cause d'un import indirect de la lib XZ pour implémenter la notification systemd, d'après d'autres messages du même thread.

Zerosquare: c'est en effet possible qu'il y ait eu d'autres telles compromissions, mais il faut qu'elles soient encore mieux planquées que celle-là - or, la découverte de caca de ce calibre est rare, ce qui peut vouloir dire qu'on le détecte mal, mais probablement plutôt qu'il est rare
Et le fait que maintenant, les choses se déroulent en public, est un avantage par rapport aux logiciels closed-source, qui ne sont pas forcément exempts de vulnérabilités supply chain non plus.
Sur certaines bases de code, par exemple le kernel Linux, ça n'est même pas la peine de se faire chier à introduire délibérément une backdoor (et de risquer de se faire pincer a priori ou a posteriori), alors qu'il y a suffisamment de vulnérabilités par ailleurs, et que les défenses anti-exploitation du kernel mainline restent très limitées.

Lionel Debroux (./2042) :
Sur certaines bases de code, par exemple le kernel Linux, ça n'est même pas la peine de se faire chier à introduire délibérément une backdoor (et de risquer de se faire pincer a priori ou a posteriori), alors qu'il y a suffisamment de vulnérabilités par ailleurs, et que les défenses anti-exploitation du kernel mainline restent très limitées.

Tu veux dire que le kernel Linux est plus vulnérable qu'un kernel proprio ?

Historiquement, j'ai toujours lu que les fabricants d'analyseurs statiques indiquent, en moyenne, et de façon répétée, un nombre de vulnérabilités par ligne de code inférieur dans le logiciel ouvert par rapport au logiciel propriétaire. Et le Patch Tuesday de MS détaille chaque mois des corrections de jusqu'à des dizaines de vulnérabilités suffisamment graves dans Windows, alors que l'on n'entend pas parler de dizaines de vulnérabilités graves par mois dans le core du kernel Linux.
Mais dans Linux, les drivers font également partie du kernel, à une échelle beaucoup plus large que dans Windows, où nombre de drivers sont à la charge des fabricants (et pas forcément écrits selon les guidelines de sécurité...). Et j'avais lu que le nombre de vulnérabilités par ligne de code était beaucoup plus élevé dans les drivers que dans le core de Linux. Pour faire une comparaison à périmètre similaire (*) par rapport à Windows, il faut ne compter de Linux que le core et les drivers les plus centraux qui sont également présents dans Windows, ou bien - mais c'est probablement plus difficile - compter pour Windows également les vulnérabilités dans les drivers.

Depuis quelques semaines, le kernel Linux a sa propre CNA, et une ML pour annoncer les CVEs qui touchent le kernel Linux: https://lore.kernel.org/linux-cve-announce/ . On peut tous voir qu'il y en a beaucoup, mais que seule une minorité touche le core, et que parmi les vulnérabilités, les problèmes graves car facilement exploitables sont (très ?) minoritaires. Du DoS, en général partiel, par nullptr deref, il y en a pas mal. Des memory leaks aussi, mais si la proportion de memory leaks qui peuvent être utilisés pour déclencher des DoS complets de la machine (parce qu'ils sont répétables à volonté) était autre chose que négligeable, je pense que depuis le temps, ça se verrait plus souvent. Des choses vraiment plus graves (OOB writes sur des tailles significatives, en particulier; UAF et UMR ne sont pas toujours faciles à exploiter), qui peuvent facilement entraîner ACE, RCE ou privesc, il y en a nettement moins.

Là où Linux pèche, outre certaines technos qui sont des passoires connues et qui ne s'améliorent que très lentement (citons eBPF, io_uring, unprivileged userns, ksmbd), c'est dans les défenses anti-exploitation. Pour ça, il n'y a qu'une vraie solution, depuis une vingtaine d'années maintenant: PaX + grsecurity. Les approches de type LKRG, qui s'exécutent au même niveau de privilège, permettent de détecter un certain nombre de choses a posteriori, mais c'est par construction trop tard et donc bypassable. Mais depuis 7 ans, pour avoir accès à PaX + grsecurity, il faut être une entreprise et payer. Au moins, cela leur a permis de vivre de leur travail, plutôt que de passer un temps libre très important, sans rémunération en commune mesure - et même de recruter d'autres chercheurs en sécurité pour continuer à augmenter l'écart avec mainline, ou encore de sponsoriser des développements sur le front-end Rust de GCC.
Du côté de Windows, Virtualization-Based Security pour une partie de l'OS finira par faire une différence... et les Linux utilisés par tout le monde n'ont aucune techno comparable.

*: historiquement, Windows avait une partie non négligeable de la stack graphique dans le kernel, donc les vulnérabilités de la stack graphique se comptaient également dans les vulnérabilités du kernel. Je ne sais pas si ça a changé dans les kernels Windows les plus récents.

Lionel Debroux (./2044) :
Historiquement, j'ai toujours lu que les fabricants d'analyseurs statiques indiquent, en moyenne, et de façon répétée, un nombre de vulnérabilités par ligne de code inférieur dans le logiciel ouvert par rapport au logiciel propriétaire.

Suffit de bien choisir son échantillon pour pouvoir montrer ce qu'on veut ^^

Brunni (./2043) :

Lionel Debroux (./2042) :
Sur certaines bases de code, par exemple le kernel Linux, ça n'est même pas la peine de se faire chier à introduire délibérément une backdoor (et de risquer de se faire pincer a priori ou a posteriori), alors qu'il y a suffisamment de vulnérabilités par ailleurs, et que les défenses anti-exploitation du kernel mainline restent très limitées.

Tu veux dire que le kernel Linux est plus vulnérable qu'un kernel proprio ?

C'est toujours compliqué de parler de manière aussi définitive, sachant que le kernel n'est jamais tout seul (et si tu trouves les failles qui te suffisent ailleurs, pas besoin de chercher dans le kernel) et que beaucoup de choses se jouent sur la configuration utilisée.

Lionel Debroux (./2034) :
Je n'ai pas encore vu passer d'analyse complète du code obfuscated qui est injecté.

On commence à en savoir un peu plus sur le sujet :

Ça ne fait que confirmer un peu plus qu'il y a vraisemblablement une grosse structure derrière (grande organisation criminelle, ou agence d'état).

(et personnellement, avant cette histoire, je ne savais pas que certaines distribs Linux étaient créées à partir de tarballs dont le contenu diffère du repo Git. Même en mettant de côté les cas comme celui-là, ça reste une mauvaise pratique à mes yeux.)

Je vois plus un service de renseignement qu'une organisation criminelle, NSA ou MSE.

Moi aussi (je trouve que ça colle parfaitement au mode opératoire de la NSA, même s'ils ne doivent pas être les seuls à procéder ainsi), mais ça pourrait être à la portée aussi d'une organisation criminelle avec de gros moyens.

./2046: voilà, c'est la source originale de ce que j'ai mentionné en ./2042

La pratique de nombreuses distros reste de packager des tarballs, par habitude historique des logiciels qui n'étaient packagés qu'ainsi. Quand les tarballs release sont différents de ce qu'il y a dans le SCM, évidemment, c'est un problème...

Et oui, ce type de mode opératoire correspond le mieux aux grades les plus élevés d'attaquants dans la classification ANSSI et certainement les autres classifications similaires - Nation State Adversaries (entre américains, autres occidentaux, russes, chinois, nord-coréens, iraniens, et d'autres, il y a l'embarras du choix !) ou mafia supérieure - la limite entre les deux pouvant ne pas être étanche.

Ah désolé, j'avais raté le lien

Zerosquare (./2048) :
mais ça pourrait être à la portée aussi d'une organisation criminelle avec de gros moyens.

J'y crois assez peu (ça demande beaucoup trop de moyens pour exploiter le résultat).

flanker (./2051) :
ça demande beaucoup trop de moyens pour exploiter le résultat

Pourquoi ?

Manifestement, ça ne fonctionne quand dans certaines conditions. Il faut donc savoir si ta cible réunit ces conditions, puis identifier à quoi correspond la machine qui t'envoie ses clefs (si la porte dérobée envoie bien les clefs), puis accéder à la machine… tout ça après un boulot pour identifier un code vulnérable, 2 ans d'infiltration pour avoir le droit de faire des commit, et cibler qu'une toute petite population de machines. Aucune chance d'être rentable pour un groupe cybercriminel.

Ca ressemble plus à un botnet que la collection de clef pour moi

Je ne vois pas trop l'intérêt de faire quelque chose d'aussi compliqué pour avoir un bête botnet à la fin.

C'est effectivement une RCE, certains ont créé des patchs pour remplacer la clef publique hardcodée avec la leur et envoie un payload qui est ensuite passé à system()



C'est quand même une approche assez alambiquée mais la quantité de travail qui a été fournie pour mettre tout ça en place est assez malaisante, sans parler de tout le social engineering pour pousser Lasse Collin (l'auteur originel de zx) à donner les accès au threat actor

Un billet de blog pas inintéressant sur le côté psychologique de l'affaire :
https://robmensching.com/blog/posts/2024/03/30/a-microcosm-of-the-interactions-in-open-source-projects/

blockchain contenant des dev ultra whitelistés pour démocratiser la validation des commits

bon ça induira d'autres vecteurs, mais plus d'attaques "chirurgicales" ^^

en tous cas ça n'a pas duré heureusement très longtemps, mais certainement suffisamment pour accéder à deux trois serveurs primordiaux

Je n'aimerais pas qu'on me mette dans une blockchain

Aucun risque : tu ne seras pas whitelisté, on sait tous que tu es un agent du FSB.