La porte dérobée xz reste naturellement l’actualité la plus importante de la semaine. Si vous avez besoin d’un rappel, consultez notre couverture précédente. Comme prévu, des ingénieurs inverseurs très talentueux se sont mis au travail sur le code, et nous avons une bien meilleure idée de ce que fait la charge utile injectée.
L’une des premières constatations à noter est que la porte dérobée ne permet pas à un utilisateur de se connecter via SSH. Au lieu de cela, lorsqu'une requête SSH est signée avec la bonne clé d'authentification, l'un des champs du certificat est décodé et exécuté via un system() appel. Et cela est parfaitement logique. Une connexion SSH laisse une piste d’audit, alors que cette porte dérobée se veut évidemment silencieuse et secrète.
Il est intéressant de noter que ce code utilisait à la fois les macros autotools et le GNU ifunc, ou Indirect FUNCtions. C'est la fonctionnalité intéressante où un binaire peut inclure différentes versions d'une fonction, chacune optimisée pour un jeu d'instructions de processeur différent. La bonne version de la fonction est appelée au moment de l'exécution. Ou dans ce cas, la version malveillante de cette fonction est liée à l'exécution par une bibliothèque malveillante.
Qui est Jia Tan ?
L’un des mystères les plus intrigants est la véritable identité du ou des programmeurs derrière l’identité de Jia Tan. Je suis d'avis qu'il s'agit de plus d'un développeur, nous verrons pourquoi dans un instant. Le premier indice est le fuseau horaire des commits Jia, qui est UTC +8. Il s'agit du fuseau horaire de la Chine, de la Mongolie, d'une partie de la Russie, de l'Australie occidentale et des nations insulaires intermédiaires. Nom d'Asie de l'Est, fuseau horaire d'Asie de l'Est, il doit donc s'agir d'un pirate informatique d'Asie de l'Est, vraisemblablement chinois. Sauf que les délais de validation n'ont aucun sens.
J'ai vu certaines théories selon lesquelles Jia commettait dans un fuseau horaire +2 ou +3. Non. Vérifiez le journal git par vous-même et voyez le graphique. Il y a une tendance évidente ici, à partir de 12h00 UTC. Maintenant, à quel fuseau horaire cela correspondrait-il à un employé de bureau commençant à travailler à 8h00 ? UTC -4 correspond à l'est des États-Unis, mais seulement pendant la moitié de l'année. Ce qui manque notamment dans ce graphique, c'est le changement d'heure d'été deux fois par an que connaissent les États-Unis. Il convient également de noter que les temps de validation de git sont faciles à modifier avant de faire un push.
Et puis il y a la série de changements avec des temps bizarres vers la fin du graphique. Les changements de version vers 5.6.0 et 5.6.1, ainsi que le « correctif » Valgrind, sont intéressants. Ce qui pourrait éventuellement suggérer qu'un deuxième programmeur contrôle le compte fantoche de Jia Tan. Il existe également un écart notable dans les engagements chaque année autour des vacances de Noël et du Nouvel An. Mais tout bien considéré, il n’existe pas de preuve irréfutable pointant vers un pays spécifique. Juste quelques conseils. Mais l’absence totale d’informations sur Jia Tan dans d’autres lieux est un bon signe qu’il s’agit d’un personnage fabriqué, et qu’il utilise une assez bonne opsec pour cela.
Et maintenant ?
La question suivante est : que pouvons-nous faire pour empêcher que cela ne se reproduise ? Les développeurs et les responsables de la distribution réfléchissent définitivement à cette question en ce moment. Une conclusion est qu’on ne peut pas faire confiance aux archives tar sans réfléchir. Vérifier le contenu de l'archive tar par rapport aux balises git et régénérer le autotools les résultats sont également bons. Plusieurs développeurs cherchent sérieusement à s'éloigner des outils difficiles à comprendre comme gnulib et autotools tout à fait.
La politique de Debian consistant à exiger des réunions en personne avant l'attestation GPG semble soudainement être une bonne politique. Cela devrait peut-être devenir une pratique standard de l'industrie pour obtenir la maintenance de tout projet open source existant.
Un point intéressant a été soulevé environ 37 1/2 minutes après le début de l'interview FLOSS Weekly de cette semaine, où Joshua a expliqué que seules deux ou trois personnes ont un accès validé à la base de code Asterisk, et que seuls les employés de Sangoma sont autorisés à être les responsables du projet. Un plus grand parrainage d’entreprises de projets Open Source individuels fera-t-il partie de la solution ? Le temps nous le dira.
AT&T est enfin propriétaire
Nous savons maintenant qu'en 2019, les données des clients d'AT&T ont été saisies lors d'une violation. Ce qui est remarquable ici, c'est qu'il a fallu attendre le mois de mars pour qu'AT&T reconnaisse publiquement qu'il s'agissait bien de données divulguées à partir des dossiers de ses clients. La façon dont cela a été confirmé est particulièrement impressionnante.
Le crédit revient à [Sam Croley] pour avoir compris cela. Chaque enregistrement de compte comprenait l'adresse, le numéro de téléphone, les anniversaires et le numéro de sécurité sociale. Et puis pour chaque compte, un mot de passe numérique a été crypté et inclus. Ce cryptage est suffisamment fort pour empêcher de le pirater correctement. (Nous parierions qu'il s'agit en fait d'une fonction de hachage.) Mais [Sam] est particulièrement intelligent. Il a pris uniquement les valeurs chiffrées, les a triées et les a dédupliquées. Le résultat? environ 10 000 enregistrements uniques, ce à quoi on pourrait s'attendre si 70 millions d'utilisateurs choisissaient tous un code PIN à 4 chiffres. L'algorithme de hachage ou de chiffrement utilisé ici n'a pas été saisi ou salé par entrée.
Nous obtenons ainsi la deuxième partie du plus grand jeu de mots croisés au monde : l'édition numérique. Pour faire simple, chaque fois qu’un client choisissait 1337 comme code PIN, la valeur de la fuite était la même. Il suffit de quelques utilisateurs sur 70 millions avec un numéro de téléphone, un numéro de date de naissance ou un numéro de sécurité sociale se terminant par 1337 pour comprendre à quoi correspond une valeur de hachage donnée. Et même si vous avez choisi ce numéro de manière complètement aléatoire, il sera toujours compris avec tout le reste.
Lettres de marque des hackers
Parallèlement à la guerre terrestre en Ukraine, une saga fascinante se déroule : les pirates ont reçu une sorte de lettre de marque du gouvernement ukrainien, et maintenant des lettres physiques ont également été envoyées. M'appuyant sur mes connaissances historiques acquises grâce aux premiers jeux informatiques comme Sid Meier's Pirates !, je sais qu'une lettre de marque est une autorisation d'un gouvernement donnée à un citoyen privé d'attaquer et de revendiquer des navires et des biens étrangers. Nous avons donc ici une version moderne et numérique de l’idée. Il convient de noter que l’Ukraine n’est pas signataire du traité interdisant cette pratique.
Le typosquatting ajoute des hallucinations à l'IA
Il semble que nous devions ajouter une autre entrée à la liste standard des avertissements donnés aux utilisateurs de Linux. N'exécutez pas de code copié directement à partir d'un site Web, et maintenant, n'exécutez pas de code copié directement à partir de ChatGPT. Apparemment, il y a un paquet pip communément halluciné, huggingface-cli, faisant référence à une partie du projet huggingface. Ce package n'existe pas, mais la commande s'est quand même glissée dans quelques guides en ligne.
Et c’est là que le typosquatting entre en jeu. Heureusement, cette fois, il s’agit d’un chercheur en sécurité plutôt que d’un auteur de malware. [Bar Lanyado] a saisi ce nom de package à titre de test et a enregistré 15 000 tentatives de téléchargement en seulement trois mois. Jusqu’à présent, il n’y a pas eu de véritable attaque utilisant cette technique, mais ce n’est probablement qu’une question de temps.
Mais vous n'avez pas besoin d'IA pour le typosquatting traditionnel : PyPI se retrouve à nouveau dans la ligne de mire. Il s'agit d'une collection de 566 faux colis, dans une campagne automatisée. Les téléchargements se sont produits en deux rafales sur quelques jours et se sont terminés lorsque les responsables de PyPI ont suspendu à la fois le nouveau projet et la création de nouveaux utilisateurs.
Bits et octets
Le projet DOMPurify est destiné à prendre du HTML « sale » et à le transformer en une chaîne de HTML épuré et sans XSS. Il y avait un petit hic, dans la mesure où le code HTML est un peu différent du XML. XML est beaucoup plus strict dans ce qu'il considère comme des balises analysables, mais transmettra le contenu de ces balises, même s'il contient du HTML valide. Ce qu'il faut retenir, c'est que les chercheurs ont trouvé plusieurs contournements DOMPurify qui ont profité de cette lacune d'analyse. Des correctifs ont été appliqués, le package DOMPurify à jour devrait donc être prêt à fonctionner.
Classée dans la catégorie « maladroite », la fondation OWASP hébergeait accidentellement de très anciens CV de membres accessibles au public. C'est gênant car l'OWASP est la fondation dédiée à l'amélioration de la sécurité open source. L’avantage est que les informations divulguées sont tellement obsolètes que la plupart des personnes concernées ne peuvent même pas être contactées. Nous recevons donc une annonce publique.
Microsoft a reçu une évaluation du Cyber Safety Review Board concernant le piratage en 2023 des comptes Exchange hébergés. Il semble qu'il reste encore des questions sans réponse, comme celle de savoir exactement quel vidage sur incident contenait la clé utilisée lors de l'attaque finale. Pourtant, ce n’est pas un bon jour lorsque vos actions sont décrites comme une « cascade d’erreurs… évitables ».
