Il semble que j’ai laissé ma petite marque indélébile dans l’histoire de la sécurité Internet, avec le terme « protestware ». Pour autant que je sache, j’ai d’abord inventé cette saveur particulière de malware en couvrant le vandalisme Faker.js/Colors.js en janvier.
Encore un autre développeur, [RIAEvangelist] a inséré un code malveillant (Mirror, puisque la plainte a été supprimée) dans un projet existant, pour protester contre quelque chose, dans ce cas la guerre en Ukraine. Le comportement ici est d’écrire une belle note sur le bureau, prêchant « la paix, pas la guerre ». Cependant, quelques versions de cet exemple ont une mauvaise surprise – il effectue une recherche GeoIP et tente d’effacer l’intégralité du lecteur s’il détecte un emplacement russe. Oui, node-ipc les versions 10.1.1 et 10.1.2 contiennent des logiciels malveillants purs et simples. On ne sait pas combien d’utilisateurs ont exécuté le code potentiellement malveillant, car il a été rapidement annulé et publié 10.1.3. Les versions à jour de node-ipc créez toujours le fichier de bureau et Unity Hub a déjà confirmé qu’il a livré la bibliothèque dans cet état et a depuis publié un correctif.
Cette histoire continue de se développer, mais il y avait aussi un problème soulevé par un node-ipc utilisateur qui prétendait être associé à une organisation de défense des droits de l’homme qui travaillait avec des observateurs en Europe de l’Est. L’affirmation non fondée est que node-ipc exécuté sur leur infrastructure de dénonciation, et le code malveillant de la version 10.1.1 ou 10.1.2 a effacé une énorme collection de preuves. Bien que cela puisse être un canular – n’importe qui peut réclamer n’importe quoi sur Internet – il existe une menace de poursuites judiciaires, ce qui donnerait de la substance à la réclamation. Si nous avons vent de quelque chose de plus en développement, nous vous tiendrons au courant.
Cette récurrence du protestware va forcer le monde Open Source à tirer des conclusions sur le type de commentaire social et politique approprié dans les projets largement utilisés. Essuyer les disques durs est évidemment bien au-delà de la pâleur. Il n’est pas tout à fait clair que le code était destiné à être déployé au public, car il a été récupéré dans un ensemble de modifications sans rapport, suggérant soit une inclusion accidentelle, soit une tentative de l’introduire clandestinement. Mais qu’en est-il de la création d’une brochure virtuelle sur le bureau de l’utilisateur ? Je suggère que cela aussi est inacceptable pour un projet sérieux. Qu’en est-il de la rhétorique dans la sortie du journal ? L’impulsion derrière le protestware semble être immuable, nous devrons donc trouver les réponses à ces questions.
Netfilter RCE
Vient ensuite l’annonce d’une autre vulnérabilité du noyau Linux, CVE-2022-25636, celle-ci étant une écriture hors limites dans le code du pare-feu Linux. Si vous avez soudainement des palpitations cardiaques à l’idée de l’exécution de code à distance, essayez de vous détendre. Cette faille est grave, mais tout comme DirtyPipe dont nous avons parlé la semaine dernière, elle est entièrement limitée à un compte d’utilisateur local pouvant exécuter des commandes shell. Une paire d’astuces permet à tout utilisateur de déclencher la faille avec n’importe quel matériel, ce qui signifie qu’il s’agit d’une simple élévation de privilèges.
Ce qui rend ce problème plus sérieux, il y a au moins deux preuves de concepts disponibles : une dans la divulgation liée ci-dessus, et la seconde sur Github de [Bonfee]. Le problème a été introduit dans le noyau 5.4 et corrigé dans les versions 5.16.12, 5.15.26, 5.10.103, 5.4.182, et a atterri dans la version 5.17 qui devrait être publiée très prochainement. Malheureusement, il existe des rapports incorrects indiquant que ce CVE a été corrigé dans la version 5.6.10, y compris la page NIST sur le bogue. Le problème est que la version 5.6.10 a été publiée plus d’un an avant que le problème ne soit détecté. Ajustez votre réponse en conséquence.
Comment briquer des milliers de terminaux satellites
Vous avez peut-être vu l’histoire de plusieurs milliers d’éoliennes en Europe qui ont soudainement perdu leur liaison satellite avec leurs contrôleurs. Il y a finalement eu suffisamment d’informations publiées pour reconstituer une supposition éclairée sur ce qui n’a pas fonctionné. [Ruben Santamarta] combine son expérience de la rupture des systèmes satellites avec les indices donnés dans les déclarations officielles, et présente une explication probable. Premièrement, la panne correspondait à la guerre en Ukraine et faisait l’objet d’une enquête en tant que cyberattaque. Cela aurait pu être un simple DDoS, mais un responsable militaire a déclaré que « les terminaux ont été endommagés, rendus inutilisables et ne peuvent probablement pas être réparés ». Les attaques DDoS ne briquent généralement pas les appareils.
Qu’est-ce que les appareils en brique leur envoient un mauvais firmware. Le scénario le plus probable est que les attaquants russes ont compromis une station au sol ou l’ont usurpée. Ils ont utilisé cette connexion et le protocole TR-069 pour envoyer une mise à jour malveillante du firmware. Cette attaque a détruit des terminaux en Ukraine, en République tchèque, en Slovaquie et en Allemagne.
TLStorm
C’est un nom accrocheur, un logo et même une vidéo d’information astucieuse. TLStorm est-il plus qu’un flash-in-the-WAN ? Peut-être – il y a un trio de vulnérabilités sérieuses en jeu. Les chercheurs d’Armis les ont trouvés dans le micrologiciel APC Smart-UPS.
Commençons par le problème d’authentification du firmware. Pour vraiment s’assurer que les micrologiciels malveillants ne peuvent pas être installés, les appareils utilisent une approche signée et cryptée, où la clé de signature est détenue de manière très sécurisée par le fabricant. Le micrologiciel Smart-UPS était simplement chiffré avec une clé symétrique, ce qui signifie que la même clé est utilisée pour chiffrer et déchiffrer le micrologiciel. La vérification effectuée dans l’appareil cible consistait à déchiffrer le nouveau micrologiciel et à le vérifier, généralement en recherchant une valeur magique dans l’en-tête. Le problème est que chaque appareil partageant la compatibilité du micrologiciel partage également la même clé de cryptage. L’extraction de la clé d’une unité permet à un attaquant de produire un micrologiciel valide mais malveillant pour toutes.
Le deuxième problème est une attaque Man in the Middle TLS. Celui-ci tire parti de la confusion des états dans la bibliothèque nanoSSL livrée avec les appareils APC. Le client tente de communiquer avec le cloud APC et l’attaquant interrompt la poignée de main initiale. Maintenant que la connexion est dans cet état, l’attaquant peut envoyer un message de reprise TLS, et le client l’accepte, en sautant la vérification très importante du certificat HTTPS.
L’exploit final est un RCE, tirant parti de la fragmentation TLS. L’attaquant envoie un message fragmenté, puis continue d’envoyer des fragments au-delà du nombre d’octets attendu, dépassant le tampon alloué. Celui-ci permet un contrôle total et s’enchaîne au problème du micrologiciel malveillant. Ensemble, ceux-ci offrent à un attaquant un très large éventail d’options, allant de la mise hors tension des périphériques en aval à la modification du micrologiciel pour induire des opérations dangereuses. Le trope hollywoodien devient enfin réalité, où le pirate informatique peut faire exploser des appareils à distance.
Bits et octets
Cet appareil astucieux que vous emportez partout est doté d’un processeur de bande de base et d’un micrologiciel, et cela a toujours été un composant très opaque. Il existe un nouvel outil pour avoir un aperçu de ce que fait ce micrologiciel, FirmWire. Il s’agit d’un émulateur de bande de base, destiné à vous permettre de fuzzer, de déboguer et de découvrir les secrets de votre micrologiciel de bande de base.
Est-ce juste moi, ou Google Chrome a-t-il eu une recrudescence d’exploits dans la nature récemment ? Apparemment, la tendance est réelle et les chercheurs de Google l’ont remarqué. Ils soulignent quelques raisons de la tendance. Chromium est le plus grand jeu par navigateur de la ville, c’est donc naturellement celui qui est attaqué. Un point contre-intuitif est qu’une meilleure sécurité gonfle artificiellement le nombre de vulnérabilités, car le sandboxing nécessite une véritable attaque pour enchaîner au moins deux bogues ensemble pour accomplir quelque chose de valable. Le message se termine par une discussion sur les plans de Google pour continuer à ajuster le code dans Chrome/Chromium à une norme plus sécurisée.
Vous vous souvenez de l’impressionnant outil de fuzzing WordPress dont nous avons parlé il y a quelques semaines ? Quelques commentateurs ont voulu savoir où trouver la source du nouvel outil. Wpgarlic est maintenant sorti et est prêt à être utilisé, amélioré et libéré de votre créativité en matière de piratage. Si vous y trouvez quelque chose de particulièrement intéressant, n’hésitez pas à nous le faire savoir !
