Github a du mal à suivre une campagne de malware qui constitue une nouvelle tournure du typosquatting. Le jeu est simple : clonez des référentiels populaires, ajoutez des logiciels malveillants et annoncez les forks comme l'original. Certains développeurs confondent les forks avec les vrais projets et exécutent involontairement le malware. Le choix de nom évident est forksquatting, mais les chercheurs d’apiiro ont opté pour le nom plus sûr de « Repo Confusion ».
La campagne est automatisée et GitHub en est conscient, la grande majorité de ces référentiels malveillants étant immédiatement supprimés. Pour une raison quelconque, l'algorithme GitHub ne détecte pas tous les nouveaux dépôts. La campagne actuelle semble publier des millions de forks, utilisant le code de plus de 100 000 projets légitimes. Il commence à sembler que la famille des attaques accroupies est là pour rester.
RustDesk et certificats Odd
Le logiciel d'accès à distance RustDesk est intéressant, car il est open source, permet l'auto-hébergement et est écrit en Rust. J'explore RustDesk comme élément de tâche depuis longtemps, mais un drame un peu inquiétant vient de finir de se dérouler. Un utilisateur a souligné en novembre qu'un certificat racine de test avait été installé dans le cadre de l'installation de RustDesk. Ce certificat racine est auto-signé avec SHA1. On craint également que les binaires RustDesk soient signés avec un certificat différent.
Depuis, de nouveaux événements se sont produits. Tout d’abord, il y a eu un fil de discussion Hacker News sur le problème plus tôt ce mois-ci. Le lendemain, CVE-2024-25140 a été enregistré auprès du NIST, classant un CVE 9.8 CVSS insensé. Parlons un peu de FUD et parlons de ce qui se passe réellement.
Premièrement, les certificats racine doivent être signés avec une fonction de hachage plus sécurisée que SHA1. Mais pas pour la raison que vous pensez, et dans ce cas, cela n'a pas d'importance. Les certificats racine sont auto-signés par définition, et la seule raison pour laquelle ils sont signés est que ces certificats doivent être signés pour être valides. Les certificats enfants ne sont pas protégés par la signature de la racine. La fonction importante qui dépend de cette signature racine est la possibilité d'émettre une demande de révocation. Ce serait vraiment mauvais pour l'un des certificats racine les plus fiables, et ce ne serait pas du tout un problème pour un certificat non fiable comme celui-ci.
Ensuite, RustDesk dispose d'un certificat valide et signé pour les exécutables. Le certificat racine auto-signé est strictement destiné à signer un pilote de noyau, qui nécessite un certificat Extended Validation (EV). Il est un peu déconcertant que cette exigence puisse être si facilement contournée en installant un certificat racine lors de l'installation de l'application, mais cela concerne Microsoft, pas RustDesk.
La dernière préoccupation ici est que ce certificat est installé en tant qu'autorité de certification (CA) à l'échelle du système. C’est l’élément le plus inquiétant de cette saga, mais les certificats disposent d’un champ précisant leur Key Usage (KU) et Extended Key Usage (EKU). L'autorité de certification RustDesk est strictement destinée à la signature de code. Cela ne permet pas à RustDesk ou à toute personne en possession de cette clé de pirater TLS ou d'usurper des sites Web. Il permet la signature de code, ce qui pourrait être une préoccupation valable, mais ce n'est pas la situation délicate qu'elle apparaît à première vue.
RustDesk a extrait cette clé de son installation, ce qui désactive le pilote d'affichage virtuel. C'était la fonctionnalité qui nécessitait un pilote de noyau signé. Les dernières nouvelles sont que les développeurs de RustDesk reçoivent de l'aide et recherchent un certificat de signature de code EV, et s'attendent à ce que ce processus soit terminé dans environ un mois. Et ce CVE, avec une gravité de 9,8 ? Cela semble complètement faux.
Injection SQL de membre ultime
Le plugin WordPress Ultimate Member a été mis à jour vers la version 2.8.3, corrigeant une faille d'injection SQL qui était accessible en tant qu'utilisateur non authentifié. D'après la différence de mise à jour, le problème clé est probablement un manquement prepare() sur la ligne 704. Oh, et il est apparemment en train d'être sondé et potentiellement exploité dans la nature, alors allez patcher.
C’est probablement le bon moment pour discuter des raisons pour lesquelles il y a tant d’attaques par injection SQL dans WordPress. Premièrement, l'injection SQL se produit lorsque les données fournies par l'utilisateur sont interprétées comme faisant partie de la commande SQL à exécuter. Cela se fait en incluant un personnage inattendu. Par exemple, un point-virgule indique la fin d’une instruction et peut être utilisé pour commencer la suivante. Ainsi, là où un programme naïf attend un nombre, une entrée de 15; DROP TABLE Students satisfera une instruction SQL et injectera une deuxième instruction à exécuter sur la base de données.
D'une manière générale, il existe deux approches pour empêcher l'injection SQL : la vérification des entrées et les instructions préparées. Et les deux sont bons aussi ! Tout d’abord, nettoyez les entrées des utilisateurs. Assurez-vous que l'entier est bien un entier et uniquement un entier. Supprimez les guillemets, les points-virgules et autres caractères potentiellement dangereux.
La deuxième approche consiste à utiliser des instructions préparées. Cela sépare la commande SQL des données de manière fondamentale. C'est quelque chose comme $database->prepare("INSERT INTO Students (name, age) VALUES (?, ?)"); pour envoyer les commandes SQL. Ensuite, c'est suivi de $database->bind_param("si", $name, $age); pour définir les valeurs à utiliser. Et enfin un $database->execute(); exécute réellement la requête. Aucune injection n’est possible du fait de la stricte séparation entre le code et les valeurs.
Venons-en maintenant à WordPress, qui a son propre wpdb classe pour les appels de base de données. Cela inclut une fonction utile, wpdb::prepare() cela ressemble presque à une déclaration préparée comme indiqué ci-dessus.
$wpdb->prepare( "u.user_registered BETWEEN %s AND %s", $from_date, $to_date );
Sauf que ce n'est pas du tout le cas. Le prepare() la fonction effectue strictement une passe de désinfection, et un sprintf() substitution de valeur. Le prepare() la fonction ne produit pas réellement une instruction de base de données préparée. WordPress ne permet pas d'utiliser réellement les instructions préparées. Il manque l’un des paradigmes de base permettant d’éviter aux développeurs des problèmes liés aux injections SQL.
Les M&M's regardent
J'ai une sorte de passe-temps. Je trouve amusant de repérer les machines qui se comportent mal et d'essayer de comprendre quel système d'exploitation fonctionne sous l'interface graphique brillante. Le périphérique intégré le plus étrange que j'ai trouvé est un scanner de pages qui exécutait une copie complète de Windows. Les scanners de prix de votre magasin à grande surface local peuvent simplement exécuter Windows CE. Les centres d'infodivertissement installés dans les dossiers des avions utilisent un très vieux Linux. Et apparemment, les distributeurs automatiques M&M de l'Université de Waterloo fonctionnent sous Windows avec l'application Invenda.Vending.FacialRecognition.App.exe.
Nous le savons parce que [SquidKid47] a détecté une exception logicielle inconnue sur l'écran d'affichage du distributeur automatique et l'a partagée sur Reddit. Un journal scolaire a repris l'histoire (pdf) et a déterminé que le distributeur automatique utilise une caméra et une détection faciale comme combinaison d'un capteur de mouvement intelligent et d'un détecteur démographique pour une publicité ciblée. Oui, ces distributeurs automatiques diffusent des publicités ciblées. Au moins, ils l'ont fait. Ces distributeurs automatiques ont rencontré leur Waterloo à l'Université de Waterloo, l'école demandant désormais officiellement leur retrait.
Bits et octets
Ring Doorbell to Pwn : Il s’avère que certaines sonnettes intelligentes ne sont pas si intelligentes que ça. Il n'est pas surprenant qu'il existe un processus pour réinitialiser une sonnette intelligente, pour l'associer à un autre compte. Il est plutôt surprenant que ce processus soit aussi simple que de maintenir enfoncé le gros bouton de la sonnette pendant 8 secondes. À tout le moins, le propriétaire légitime recevra un e-mail concernant le changement.
L’insécurité des imprimantes n’a rien de nouveau, mais la sécurité des imprimantes 3D reste encore une idée de niche. Cela est peut-être en train de changer, maintenant que l'équivalent d'un fichier « Greetings.txt » a été déposé sur un certain nombre d'imprimantes Anycubic. Apparemment, Anycubic utilise un serveur MQTT qui ne dispose pas vraiment de contrôles d'accès suffisants.
C'est à nouveau le moment où un correctif de vulnérabilité a été publié pour GitLab, et il est temps de procéder à la mise à jour. Cette fois, la particularité est une faille XSS (Cross Site Scripting) lors de la visite de la page de profil d'un utilisateur. Je laisse cela comme exercice au lecteur, pour produire un exemple de code qui copie « samy est mon héros » sur la page de profil de chaque visiteur.
Et enfin, ironie du sort, Avast a été condamné à une amende pour avoir utilisé un plugin de confidentialité du navigateur comme plate-forme pour collecter et vendre des données utilisateur. Cela s’est produit de 2014 à 2020, en utilisant la plateforme Jumpshot pour la vente proprement dite de données. Les données ont été théoriquement anonymisées, mais la quantité et le détail des informations disponibles sont un peu stupéfiants. Il convient de souligner que Jumpshot n’existe plus et qu’Avast appartient désormais à une autre société. Espérons sans récolter d’informations sur les utilisateurs.
