Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
Hier — 23 juillet 2026Flux principal

Unitree - Le firmware que personne ne signe

Par : Korben ✨
23 juillet 2026 à 07:10

Le 26 février dernier, lors d'une réunion d'Austin Hackers Anonymous au Texas, le chercheur Andreas Makris a fait la démo d'un outil qui permet de générer de faux firmwares Unitree, que le robot avale sans broncher comme s'ils sortaient de l'usine de Hangzhou...

Car oui, Mesdames et Messieurs, les robots Unitree ne sont pas capables de déterminer si le firmware avec lequel ils se mettent à jour a été créé par Unitree ou par quelqu'un d'autre.

C'est ouf, non ? Le problème en fait, c'est que les paquets de mise à jour d'Unitree, c'est-à-dire les fichiers .upk qu'un Go2 ou un G1 télécharge tout seul, sont chiffrés avec TEA, un algo hyper minimaliste sorti de Cambridge en 1994.

La clé de chiffrement issue de cet algorithme se calcule ensuite à partir de trois constantes planquées dans le binaire du robot, + une graine aléatoire qui est stockée dans le paquet lui-même. Hop, comme ça vous avez la clé... Tout le monde a la clé, en fait !

Les trois constantes, en clair dans la doc de l'outil.

Et comme TEA est un algo symétrique, la clé qui déchiffre est aussi celle qui chiffre. Unitree s'en sert pour cacher le contenu de ses mises à jour, sauf que le robot, lui, comme il a été programmé avec les pieds, il en déduit que le paquet est légitime. C'est con, hein ? Une vraie signature, avec une clé privée gardée au chaud chez le fabricant, rendrait la contrefaçon impossible même en connaissant tout le reste.

Alors avant que vous ne débranchiez votre robot, je tiens à préciser un truc que Makris dit lui-même dans son dépôt : il n'existe pas de moyen public de livrer un firmware maison au robot. En effet, le canal de mise à jour passe par MQTT et n'accepte pas les paquets persos.

Cette faille a une belle note de 7,8 sur 10 mais exige un accès local et une action du propriétaire. Donc rassurez-vous, personne ne va reflasher votre chien robot qui fait des petits tours dans votre usine depuis un van garé sur le parking.

Le scénario réaliste, c'est plutôt le firmware véreux qu'on vous refile via un prestataire qui "met à jour" votre flotte, ou la clé USB d'un labo partenaire. Vous l'installez, votre robot le valide et vous n'avez aucun moyen de vérifier qu'il sort bien de chez Unitree. Bref, pour du matériel qu'on retrouve dans des labos de recherche et sur des sites industriels, c'est pas terrible !

Les firmwares décortiqués couvrent les gammes Go2 et G1, du Go2 Air au G1 Edu+, plus les modules moteur. Le NVD (National Vulnerability Database), lui, considère que toute l'offre actuelle du constructeur est concernée et surtout gag, y'a pas de correctif !!

On est quand même près de 5 mois après la publication, et y'a toujours rien. Je pense quand même qu'Unitree devrait revoir ses priorités et surtout revoir complètement la façon dont ils protègent leurs mises à jour.

De son côté, Makris n'a pas prévenu le fabricant. C'est pas un oubli, mais un choix car comme il l'explique dans son avis de publication , Unitree a montré une certaine hostilité face aux communications de divulgation. Donc, autant dire que le divorce est acté entre les chercheurs et l'entreprise chinoise.

Du coup ça nous fait quand même un quatrième épisode sur tout ce bordel. Le hack Bluetooth en 1 minute dont je vous parlais en décembre , les deux CVE sur le Go2 que je vous ai remis en mars , le backdoor vers un cloud chinois que Benn Jordan a popularisé en mai, et maintenant les mises à jour.

À l'époque, je me souviens que Benn Jordan conseillait carrément de ne plus jamais toucher au firmware pour garder l'accès root et surveiller ce que le robot envoie, sauf qu'on sait maintenant qu'une mise à jour officielle ne prouve rien, et que chacun peut forger la sienne. Breeeeef... pour du matos vendu à des labos et des industriels, je trouve ça vraiment pas sérieux.

Merci à Sammy pour le tuyau !

Source

À partir d’avant-hierFlux principal

Bornes de recharge - Un SSH root au bout du câble CCS2

Par : Korben ✨
21 juillet 2026 à 13:47

Le gros câble que vous branchez sur votre voiture électrique, celui qu'il faut soulever à deux mains et qui pèse le poids d'un âne mort, dispose de 2 choses : Du courant, et un réseau. Lionel Richard Saposnik, chercheur chez SaiFlow, a eu la curiosité d'aller voir ce qui traîne sur ce réseau-là et vous allez voir, c'est pas triste...

Quand vous clipsez le pistolet dans la trappe, votre bagnole et la borne montent une liaison IPv6 entre elles, par courant porteur, sur deux broches du connecteur CCS2. Elles se causent en respectant la norme ISO 15118 pour négocier vos ampères, votre tension, le prix de votre kWh.

Le simulateur de véhicule se branche sur la prise et atteint la carte de la borne. Schéma SaiFlow.

Lors de ses tests, sur une borne rapide XCharge C6, il a trouvé un service SSH (Dropbear) qui écoute sur le port 22 et un Telnet (BusyBox) sur le port 23. Et sans surprise, le login c'est root et le mot de passe... bah c'est "root" aussi !! Mdrrrr ! Donc vous branchez votre voiture, vous vous connectez en SSH et vous êtes root !!

La raison c'est que les services d'administration de la borne écoutent sur 0.0.0.0, autrement dit sur toutes les interfaces réseau de la machine. Sauf que parmi ces interfaces, y'a can0 pour le bus CAN interne, eth0 pour le réseau de management... et surtout qca0 et qca1, les deux modems courant porteur des deux pistolets de charge. Écouter partout, ça veut donc dire aussi écouter du côté de votre voiture.

SSH et Telnet à l'écoute sur toutes les interfaces, celles du câble comprises. Capture SaiFlow.

Pour aller taper dessus, il lui a donc fallu seulement 130 $ de matos. De quoi tirer le Control Pilot à 9 V (5 à 10 $) pour faire croire à la borne qu'une voiture est connectée, un modem HomePlug Green PHY genre QCA7000 ou QCA7005 à 70 $, un Raspberry Pi à 50 $, et deux fils à mettre en contact avec le connecteur.

Et hop, avec tout ça, n'importe qui peut se retrouver sur le réseau interne de la borne. Et là, avec l'accès root, un attaquant peut faire tout un tas de choses comme voler le certificat SECC pour se faire passer pour la borne au moment où votre voiture s'authentifie en Plug & Charge, trafiquer le comptage de l'énergie, poser une backdoor dans un cron, rebondir vers le réseau de l'opérateur par le VPN de la borne, ou couper le refroidissement et la protection contre les surintensités.

Ça craint hein ?

Je vous avais raconté comment Charlie Miller a pris le contrôle d'une Jeep sur l'autoroute , ou encore comment une faille d'API permettait d'en déverrouiller à distance mais l'idée que la prise cause du réseau n'est pas neuve puisqu'en 2022 déjà, des chercheurs d'Oxford et d'Armasuisse avaient monté Brokenwire, une attaque qui coupait les charges à distance en brouillant ce même canal courant porteur, avec une radio logicielle LimeSDR et un ampli de 1 W. Ils ont tué des sessions jusqu'à 47 mètres, sur 8 voitures et 20 bornes rapides.

Ce qui change ici, c'est pas le canal, c'est ce qu'on trouve à écouter dessus car personne n'avait pensé à scanner la prise comme vous scanneriez un réseau d'entreprise.

L'avis publié par la CISA à ce sujet liste bien 3 failles sur la borne C6, mais une seule est notée 9,8 sur 10, et c'est celle du firmware qui s'installe sans vérification de signature. Les deux autres qui concernent la prise sont à 7,6, avec accès physique obligatoire. Je tiens à le préciser parce que j'ai vu passer des actus qui annoncent 3 failles à 9,8 partout et je n'y comprenais plus rien.

En tout cas, c'est corrigé. XCharge a poussé la mise à jour sur toutes les bornes concernées, et la CISA n'a constaté aucune exploitation dans la nature. Rassurez-vous donc, votre prochaine charge sur l'autoroute ne va pas transformer votre voiture en bagnole zombie explosive !

La France compte près de 200 000 points de recharge ouverts au public, et XCharge revendique une équipe sur place et plus de 2500 bornes rapides posées en Europe. C'est donc un modèle qui est touché mondialement et surtout, SaiFlow pense que le motif de cette faille se retrouve probablement chez d'autres fabricants, toutefois sans l'avoir démontré.

Bref, la prochaine fois qu'on vous dit qu'une borne c'est "juste" de la grosse électricité, vous saurez maintenant que c'est surtout un ordinateur avec une prise réseau dehors.

Merci à DjeDje pour l'info !

Source

WP2Shell - La faille qui permet de pirater WordPress sans aucun plugin

Par : Korben ✨
19 juillet 2026 à 08:38

Vous avez un site sous WordPress ? Alors lâchez tout ce que vous faites deux minutes, parce que là c'est du sérieux !!

Cette nouvelle attaque baptisée WP2Shell permet de compromettre une installation Wordpress sans passer par le moindre plugin. Heureusement, un patch est sorti en urgence le 17 juillet !

En temps normal, quand une alerte sécu tombe sur WordPress, le fautif c'est un plugin tiers vérolé , un truc installé un soir de flemme et oublié depuis des lustres. Mais cette fois, rien de tout ça puisque le trou de sécu se trouve dans le cœur de WordPress lui-même.

Dans le détail, WP2Shell enchaîne deux failles. La première, CVE-2026-63030 , est une confusion de route dans l'API REST batch, sur l'endpoint /wp-json/batch/v1. La seconde, CVE-2026-60137 , est une injection SQL bien planquée dans le paramètre author__not_in de WP_Query. Chacune dans son coin, c'est déjà vilain, mais mises bout à bout, elles offrent une exécution de code à distance.

Pas de compte, pas de mot de passe, et encore moins de plugin exotique mais simplement quelques requêtes HTTP et hop, c'est plié !

Côté versions, la chaîne complète touche WordPress 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1. Si votre site est dans cette fourchette, vous êtes donc exposé. Les correctifs sont arrivés avec les versions 6.9.5 et 7.0.2. Et si vous vous traînez encore une vieille 6.8.x, sachez que seule l'injection SQL vous concerne potentiellement mais qu'elle a été patchée depuis la version 6.8.6.

Derrière cette trouvaille, on trouve Adam Kues, chercheur chez Assetnote (une branche de Searchlight Cyber), qui a assemblé et documenté toute la chaîne avant de la remonter proprement via le programme HackerOne de WordPress. Les détails techniques les plus croustillants restent sous le coude le temps que la planète patche mais l'équipe a mis en ligne un outil, wp2shell.com , pour vérifier si votre site est vulnérable. Allez-y, ça coûte rien !

Autre signal qui ne trompe pas, WordPress.org a déclenché les mises à jour automatiques forcées sur les sites concernés. Une mesure réservée aux failles vraiment graves, comme à l'époque où la faille critique de Really Simple Security avait exposé des millions de sites. Il y a donc de bonnes chances que votre installation toute pourrie dont vous ne vous occupez pas parce que vous êtes un mauvais webmaster ^^ ait déjà été rustinée toute seule. Vraiment, vous ne méritez pas les équipes sécu de Wordpress ^^

Mais ne pariez pas votre site là-dessus non plus... Car si vous avez désactivé les mises à jour auto (et beaucoup d'hébergeurs et d'admins le font), personne n'aura rien poussé chez vous. Sans oublier qu'un bout de PoC circule déjà sur GitHub (les chercheurs gardent pour eux le dernier maillon vers la RCE, mais ça n'arrêtera pas longtemps les motivés), et les scans automatisés ont commencé.

En attendant de patcher, bloquez surtout donc l'accès anonyme à l'endpoint batch de l'API REST via votre WAF ou votre plugin de sécu. Attention, pas seulement la forme /wp-json/batch/v1 : sa variante ?rest_route=/batch/v1 doit sauter aussi, sinon autant laisser la clé sur la porte. Cloudflare propose d'ailleurs des règles toutes prêtes. Et pour durcir le reste de votre config, ma vieille série sur le sujet reste d'actualité.

En tout cas, quand on sait qu'il y a +500 millions de sites actuellement propulsés par Wordpress, même s'ils ne sont pas tous concernés par cette faille, ça reste une surface d'attaque gigantesque !!

Bref, filez vérifier votre version. Sous 6.9.5 ou 7.0.2, vous mettez à jour et vous bloquez le batch en attendant. Deux minutes chrono, et votre site dort tranquille !

Source : Security Affairs

Januscape - La faille KVM qui dormait depuis 16 ans dans le cloud

Par : Korben ✨
7 juillet 2026 à 11:55

Depuis 16 ans, il y a une énorme faille qui fait dodo dans le coeur de tout ce qui gère la virtualisation sous Linux et personne ne l'avait remarqué, jusqu'à ce que Hyunwoo Kim, un chercheur en sécurité connu sous le pseudo @v4bel débarque. Ce dernier vient de dénicher un use-after-free dans le shadow MMU de KVM, ce bout de code que KVM partage entre les processeurs Intel et AMD. Il a baptisé sa trouvaille Januscape (CVE-2026-53359), et croyez-moi, le scénario a de quoi filer des sueurs froides à n'importe quel hébergeur...

En pratique, quand vous louez une VM dans le cloud, vous y êtes root (normal, c'est votre instance). Mais si l'hôte autorise la virtualisation imbriquée, hé bien la faille vous ouvre en grand la porte vers la machine physique. Le code de démonstration que Kim a publié se contente de faire planter l'hôte, et il garde sous le coude un second exploit, non divulgué publiquement celui-là, qui transforme le même bug en exécution de code root sur l'hôte. Et il n'a pas trouvé tout ça par hasard, puisqu'il participait au kvmCTF de Google, un programme qui paie jusqu'à 250 000 dollars pour une évasion complète d'une VM vers son hôte...

À ce stade, l'isolation censée séparer les locataires d'un même serveur vole en éclats, les VM de vos voisins de palier comprises.

Le code fautif traîne depuis août 2010, du temps du noyau 2.6.36 et Kim présente d'ailleurs Januscape comme la première évasion d'une VM vers son hôte qui fonctionne aussi bien sur Intel que sur AMD, à sa connaissance en tout cas.

Maintenant, avant de couper le wifi et de partir élever des chèvres dans le Larzac, deux petites nuances quand même car l'attaque réclame deux conditions réunies : être root dans la VM invitée, et que l'hôte expose la virtualisation imbriquée. Pas mal d'hébergeurs ne l'activent pas, donc c'est pas non plus une apocalypse universelle. Par contre, pour ceux qui l'activent, c'est game over.

Mais bonne nouvelle, le correctif est déjà là donc si vous administrez des serveurs KVM, mettez à jour maintenant. Et si vous ne pouvez pas patcher tout de suite, la parade consiste à désactiver la virtualisation imbriquée en attendant, avec kvm_intel.nested=0 sur de l'Intel ou kvm_amd.nested=0 sur de l'AMD.

VENOM s'échappait déjà d'une VM en 2015 via un vieux driver de disquette, et plus récemment une faille kernel planquée neuf ans offrait un accès root sur une machine Linux. Ces "fantômes" dorment longtemps dans le noyau, et ils choisissent toujours le pire moment pour se réveiller. Voilà, comme d'autres failles Linux à patcher d'urgence , celle-ci mérite tout de suite votre attention.

Source

❌
❌