Vous avez un Mac et un PC Windows sur le même bureau, et à chaque fois qu'il faut faire passer une commande de l'un à l'autre, vous vous envoyez un message Slack à vous-même, ou vous ouvrez un fichier texte dans un dossier partagé. Hé oui, avouez, c'est le lose un peu quand même. Heureusement, UniClipboard règle exactement ce problème ! Vous copiez ici, vous collez là-bas, et basta !

La première fois que vous utilisez UniClipboard, vous choisissez une phrase de passe, vos machines rejoignent le même espace avec un code d'invitation, et le presse-papiers circule entre elles. Pas de compte à vous créer et surtout, texte, images et fichiers passent d'une machine à l'autre sans souci.

L'outil vous permet même de conserver un historique local dans lequel vous pouvez faire des recherches hyper rapidement, à l'aide d'un raccourci clavier.

Entre 2 ordinateurs sur le même réseau ça fonctionne super bien mais quand deux machines ne se voient pas directement, elles passent par un relais, et ce relais n'a aucune clé : il ne transporte que du chiffré. Maintenant, si l'idée même de passer par un intermédiaire vous hérisse le poil, y'a un mode LAN-only qui coupe tout chemin sortant de votre réseau. Comme ça vous êtes pépouze.

Le 30 juillet, un attaquant a vidé 1 196 adresses Bitcoin en 41 minutes. Un peu plus de 1 082 bitcoins, environ 70 millions de dollars. Aucune des victimes n'avait cliqué sur quoi que ce soit.

Elles avaient acheté un Coldcard, le portefeuille matériel de la société canadienne Coinkite, l'appareil que les puristes du bitcoin recommandent depuis des années précisément parce qu'il ne se connecte jamais à Internet.

Un portefeuille matériel fabrique une seed, la suite de mots dont dérivent toutes vos clés. Toute la sécurité repose sur un seul point : que cette suite soit réellement imprévisible. La puce embarque pour ça un générateur d'aléatoire physique.

En mars 2021, le firmware 4.0.0 a introduit une erreur d'intégration. Coldcard voulait désactiver le générateur intégré de MicroPython pour utiliser le sien, et a donc défini le paramètre MICROPY_HW_ENABLE_RNG à zéro. Sauf que la bibliothèque libngu vérifiait seulement si ce paramètre existait, pas la valeur qu'il portait. Il existait. Le test passait.

Pendant cinq ans, chaque tirage est donc passé par Yasmarang, un générateur pseudo-aléatoire non cryptographique dont l'état de départ venait de trois choses : l'identifiant 32 bits de la puce, un registre de minuterie et l'horloge interne. Rien de secret là-dedans, et plus la moindre entropie fraîche ensuite.

Les Mk3 se retrouvaient avec une quarantaine de bits d'imprévisibilité au lieu des 128 promis, les Mk4, Mk5 et Q avec 72. Pour ces derniers, l'ensemble des clés que l'appareil pouvait produire tombait à quelques milliards de combinaisons.

À ce niveau, il n'y a plus rien à pirater. L'attaquant génère les seeds candidates sur sa propre machine, calcule les adresses que chacune produirait, et les compare à la blockchain, publique par construction. Quand une adresse contient des fonds, il tient la clé. Aucun appareil n'a jamais été touché.

Coinkite a publié un firmware d'urgence le 31 juillet pour tous les modèles concernés. Attention au contresens qui coûte cher : la mise à jour ne répare pas une seed déjà créée. Il faut en générer une nouvelle et y déplacer les fonds. Les configurations multisignature, où le Coldcard n'est qu'une clé parmi plusieurs, sont largement épargnées.

Rodolfo Novak, le patron de Coinkite, a écrit qu'il était désolé et dévasté, et assume. Il avance aussi que l'attaquant a peut-être déniché la faille avec une IA, sans en apporter la preuve, tout en reconnaissant que sa propre revue de code assistée par IA était passée à côté.

Cinq ans qu'un zéro traînait dans un fichier de configuration, sur l'appareil vendu comme le plus sûr du marché. Le pire endroit possible pour ce genre d'oubli.

Source : The Hacker News

Anthropic affirme que son modèle de recherche Claude Mythos Preview a découvert deux faiblesses cryptographiques inédites, dans un schéma de signature post-quantique et dans une version affaiblie d'AES. Deux résultats théoriques, sans impact sur les systèmes en production.

Si vous avez déjà envoyé un lien à usage unique qui est arrivé mort chez votre collègue, c'est probablement la prévisualisation de la messagerie qui a ouvert le lien en premier et qui a cramé le secret accompagnant le lien.

La bonne nouvelle c'est que Oğuzhan Karacabay vient de publier une grosse mise à jour d' OTI , son service open source auto-hébergeable qui génère des liens de partage consultables une seule fois, avec chiffrement dans le navigateur.

Vous collez un mot de passe, une clé d'API ou un bout de config dans OTI, le navigateur chiffre, le serveur lui ne stocke que du charabia, et le destinataire reçoit une jolie URL qui ne fonctionnera bien qu'une fois.

Ce qui change, c'est que le lien ne meurt plus tout seul. En chargeant la page, votre destinataire voit un compte à rebours et un bouton "Decrypt Message", rien d'autre. Du coup, tant que personne ne clique, le message continue son roupillon.

Comme ça, un bot qui déroule les URLs pour fabriquer une jolie vignette repart bredouille. Après si c'est un vrai scanner de sécurité qui charge vraiment la page dans un navigateur automatisé, vous ne pourrez pas éviter le problème.

L'autre nouveauté dans OTI c'est à la création d'un nouveau lien. Le service vous génère en fait 2 liens. Il y a celui que vous envoyez et un second que vous gardez pour vous. Ce dernier vous permettra de consulter l'état du message sans jamais afficher son contenu.

Côté crypto, le contenu est chiffré en AES-256-GCM via WebCrypto, et cette clé AES est elle-même emballée dans une paire RSA-2048 générée dans votre navigateur. La clé privée voyage dans le fragment de l'URL, la partie après le #, que les navigateurs n'envoient jamais au serveur.

Le principe zero-knowledge utilisé par OTI est quasi le même que celui de PrivateBin ou d' Enclosed où la clé ne quitte jamais le navigateur.

Par contre, ça donne des liens obèses puisque le mien faisait 1825 caractères, dont 1728 rien que pour le fragment, et c'est déjà compressé en zlib. Bon courage donc pour le dicter au téléphone ^^ (il y a un QR code, heureusement !)

Le reste, c'est du confort... Fichiers .txt jusqu'à 100 Ko validés dans le navigateur avant chiffrement, mot de passe optionnel par-dessus, expiration au choix entre 5 minutes et 7 jours, limitation de débit via Redis et une tâche planifiée qui balaie les secrets périmés toutes les 30 minutes.

Pour l'héberger, c'est de l'AdonisJS 6 en TypeScript avec Dockerfile, docker-compose et migrations fournis, en licence MIT. Redis peut céder sa place au limiteur en mémoire si vous montez juste un petit truc perso.

Notez quand même que pour le moment, le projet n'a pas été audité et est maintenu par un gars tout seul, donc évitez de l'utiliser pour des secrets d'État.

La démo est en ligne si vous voulez essayer avant d'installer.

Ryan Walker, le gars derrière Rootkit Labs, vient de sortir un truc que je trouve super malin. C'est une clé USB, baptisée Phantomdrive, qui se déverrouille en écrivant dans un simple fichier texte stocké dessus. Vous la branchez, vous ouvrez un bloc-notes, vous tapez password:votremotdepasse dans un fichier que vous enregistrez à la racine, et hop, une partition cachée apparaît.

Et y'a pas de logiciel pour faire tourner ça ! Au branchement, votre système voit une clé de 8 Go tout ce qu'il y a de plus banale, et il est incapable de deviner qu'il existe le moindre octet au-delà. Le firmware, lui, n'a aucune notion de système de fichiers, et se contente d'intercepter les commandes USB brutes (les WRITE10 et READ10 que votre ordi envoie pour lire et écrire des blocs) et de les traduire pour la carte SD planquée à l'intérieur.

Et quand il repère le motif password: qui passe, il dérive alors une clé, démonte la partition visible et remonte la seconde, chiffrée en AES-256, le tout en trois secondes chrono.

L'idée derrière ce bricolage, c'est le modèle de menace que ça vient contrer. Par exemple, un volume caché VeraCrypt vous sauve si on vous force à donner votre mot de passe, car vous pouvez mettre en place 2 niveaux de mot de passe. Le premier est un leurre qui ne révèle pas grand-chose et le second ouvre la vraie partition avec tous vos secrets. Mais bon, tout le monde connaît le truc et le simple fait d'avoir un conteneur chiffré sur vous suffit à vous faire passer pour un suspect. Phantomdrive répond donc à ça, puisque rien n'est détectable donc il n'y a rien à vous reprocher... Exactement ce qui se joue aux frontières, où les appareils se font fouiller sans se gêner .

Évidemment, cette invisibilité tient uniquement face à une inspection logicielle, et pas face à un labo qui démonterait la clé. Ryan le reconnaît lui-même, on peut retrouver la carte SD en cassant le boîtier, même s'il l'a noyée dans l'époxy et que la partition cachée, elle, restera chiffrée quoiqu'il arrive.

Sauf que si on dessoude la puce et qu'on lit la mémoire brute, on tombera forcément sur bien plus que les 8 Go annoncés, à cause de ce gros bloc de données illisibles qui trahit l'existence de la partition cachée. La déniabilité joue donc contre un contrôle "pressé" mais pas contre un forensique très motivé. Autre limite rigolote, si vos vraies données contiennent par hasard la chaîne password:, la clé peut alors se déverrouiller toute seule au mauvais moment.

Et surtout, le projet n'a pas été audité. C'est du hardware expérimental fait par une seule personne, sous licence MIT certes, mais pas un coffre-fort certifié. C'est rigolo pour bidouiller, mais pas encore pour lui confier de vrais secrets.

Côté matos, Ryan a utilisé une puce que je ne connaissais pas, la CH569, qui embarque de l'USB3 et un bloc de chiffrement AES matériel. Les débits restent modestes mais suffisants pour de l'usage courant, autour de 9 Mo/s en écriture et 20 Mo/s en lecture. Sachez aussi que s'il est parti sur une carte SD plutôt que de l'eMMC, c'est parce que cette dernière est devenue hors de prix à cause de la flambée des mémoires dopées par l'IA.

Hé oui, même les bidouilleurs hardware se prennent la bulle de l'IA dans les pattes. Voilà, tout est sur GitHub , électronique, mécanique et firmware compris, avec une page de précommande si vous préférez ne pas sortir le fer à souder.

Source : Rootkit Labs

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