"Maintenant", ce n'est pas qu'un adverbe à la con pour apprécier l'instant présent ou faire péter ses ordres comme votre Belle Mère ! C'est également un conteneur à lancer, qui se connecte en lecture seule à un socket Docker pour réaliser en un battement de cil, tout l'inventaire de votre home lab !

Il relève ainsi l'état de chaque conteneur, ses healthchecks, ses boucles de redémarrage, ses logs, et vos projets Compose regroupés comme vous les avez écrits.

Ensuite, tout ce qui vous alerte pour de bon se déclare à la main. Les checks HTTP et TCP se configurent sous la forme de labels sur les conteneurs à surveiller. Par exemple, un maintenant.endpoint.http avec son intervalle et son seuil d'échec, un maintenant.endpoint.tcp pour la base...etc. Pas besoin donc d'aller mettre votre gros nez dans un fichier de config spécifique.

Vos tâches planifiées reçoivent chacune une URL à appeler quand elles finissent comme ça si la sauvegarde de trois heures du matin ne se manifeste pas, vous êtes prévenu. Vos certificats HTTPS sont surveillés et signalés cinq fois avant leur expiration, un mois avant puis de plus en plus près. Il compare aussi l'empreinte de vos images à celle publiée sur le registre, ce qui vous permet ensuite de savoir lesquelles ont pris du retard sans lancer des docker pull à l'aveugle. Ah et il sert une page de statut publique pour vos utilisateurs.

Le tout tient dans un binaire Go qui occupe environ 17 Mo de RAM et qui se repose sur une simple base SQLite.

Par contre, l'édition gratuite (Community) gère une seule machine. Si vous voulez du multi-hôte, il faudra passer par la case payante. Toujours en gratuit, il y a aussi des plafonds... Vous avez le droit uniquement à 10 endpoints, 5 heartbeats, 5 certificats, 3 composants de page de statut et uniquement 7 jours d'historique.

Attention quand même, y'a 2 choses à savoir avant de vous enflammer et de poser ça sur une machine exposée sur le net. Il n'y a aucune authentification intégrée, et de ce que j'ai compris, c'est assumé ! A vous donc de mettre en place un reverse proxy et un Authelia ou un Authentik devant.

Pour situer "Maintenant" par rapport à d'autres solutions que je vous ai déjà présentées, Beszel fait les métriques par conteneur sans aucun plafond gratos, mais pas les checks HTTP. Uptime Kuma lui, fait les checks, mais ses monitors doivent être créés un par un dans l'interface, sauf à lui greffer AutoKuma pour lire les labels. Donc, il n'y a pas vraiment de solution tout-en-un gratuite...

A découvrir ici !

Zéro Logement Vacant, ce nom ne vous dit peut-être rien, mais c'est un service de l'État censé aider les collectivités à remettre sur le marché les logements vides. Il vient de se retrouver au cœur d'une fuite de données colossale.

Un pirate qui se fait appeler ZeroBytes affirme avoir aspiré près de 149 millions de lignes brutes depuis la plateforme. Après nettoyage des doublons, ça correspondrait à environ 48 millions de personnes différentes. En croisant les noms et les dates de naissance, on grimpe même à plus de 71 millions, mais les deux chiffres ne s'additionnent pas.

D'où vient une telle masse de données ? Essentiellement du foncier. La plateforme avait chargé d'énormes fichiers de propriétaires issus du cadastre et de la DGFiP, autrement dit le fisc. Deux tables contiennent presque tout, environ 82 millions de lignes de propriétaires d'un côté, et 66,9 millions provenant d'un fichier foncier national de 2024 de l'autre.

Le site Cyberattaque.org , qui a pu examiner des échantillons, confirme le pire. On y trouve des identités, des dates de naissance, des adresses postales et des informations liées aux droits de propriété. Un second extrait ajoute des adresses e-mail et des numéros de téléphone. Sur 500 lignes analysées, 453 contenaient un numéro, 274 un e-mail et 423 une date de naissance.

Et ça ne s'arrête pas aux propriétaires. Les comptes des utilisateurs de la plateforme sont aussi dans la nature, à savoir des agents de collectivités, des services de l'État et des prestataires. On parle de leurs e-mails professionnels, de leurs rôles, du SIREN de leur structure, mais aussi d'adresses IP, de sessions récentes et de mots de passe. Bonne nouvelle relative, ces mots de passe sont hachés, le plus souvent en bcrypt, donc pas lisibles directement, ou réutilisés ailleurs.

Le plus inquiétant, c'est la fraîcheur de certaines données, avec des sessions de connexion très récentes dans les échantillons. Ce n'est donc pas une vieille base oubliée dans un coin, mais bien un environnement encore actif.

Pour les propriétaires concernés, le risque immédiat, c'est l'hameçonnage sur mesure. Avec votre nom, votre adresse et votre bien, un faux courrier des impôts devient tout de suite bien plus crédible. Méfiance sur tout ce qui touchera au foncier dans les prochaines semaines.

Source : MacG

Toutes les fuites de données ne se valent pas, et celle-ci a de quoi faire transpirer pas mal de monde. Des pirates ont siphonné le registre des ayants droit économiques du Liechtenstein dans la nuit du 29 au 30 juillet, embarquant les informations de 31 000 sociétés, fondations et fiduciaires d'un coup.

Un ayant droit économique, pour faire simple, c'est la vraie personne en chair et en os qui possède ou contrôle une société, celle qui empoche l'argent tout au bout de la chaîne même quand une cascade de sociétés-écrans s'emploie à la rendre invisible.

C'est tout le problème. Ce registre a été monté pour lutter contre le blanchiment, en forçant chaque structure à déclarer noir sur blanc qui profite réellement d'elle, si bien que les pirates viennent de mettre la main sur l'annuaire officiel des propriétaires cachés du pays.

Rappelons où l'on se trouve. Le Liechtenstein est ce mouchoir de poche coincé entre la Suisse et l'Autriche qui s'est taillé une réputation mondiale de terre d'accueil pour fondations et sociétés discrètes, l'endroit idéal pour ranger un patrimoine loin des regards.

Dans le butin, on retrouve le nom des entités et surtout le nom, la date de naissance, la nationalité et le pays de résidence des bénéficiaires planqués derrière chacune d'elles.

Une petite éclaircie pour ces gens quand même, puisque les adresses, les numéros de téléphone et les données financières comme le chiffre d'affaires, les actifs ou les dividendes sont restés hors de portée, ce qui atténue la casse sans rien retirer à la gêne provoquée par les noms exposés.

L'attaque aurait été menée avec un vrai savoir-faire technique d'après l'enquête, personne n'a encore été identifié, et le pays a réclamé un coup de main international pour espérer remonter la piste.

Une cellule de crise montée dès le samedi soir sous la houlette de la cheffe du gouvernement Brigitte Haas et du ministre de la Justice, pour prévenir les personnes concernées et éteindre l'incendie.

Franchement, pour un pays qui a fait de la discrétion de ses fondations un fonds de commerce, on imagine mal un fichier plus gênant à laisser filer dans la nature.

Source : Le Temps

Le constructeur Geekom a retiré de ses anciennes pages de support un installeur de pilote réseau que plusieurs moteurs d'analyse classent comme malveillant. Le fichier s'appelle Install_PCIE_Win11_11.10.0720.2022_11222022.exe et il dormait dans l'archive LAN partagée par six mini-PC de la marque : A7, A8, AE7, AE8, AX7 Pro et AX8 Pro.

Le signalement part d'un utilisateur de r/MiniPCs sur Reddit, et du site VideoCardz qui a vérifié lui-même en téléchargeant l'archive directement chez Geekom le 15 août dernier. VirusTotal, FileScan.IO, MetaDefender et YARAify réagissent tous les quatre, ce dernier en remontant même des signatures ClamAV qui nomment la famille Asruex.

Alors c'est déjà un peu chaud d'apprendre ça, surtout si vous avez un PC Geekom mais la problème c'est que ce n'est pas absolument pas une nouveauté !

En effet, le 29 décembre 2024, le propriétaire d'un AE8 explique sur le forum ComputerBase qu'il vient de réinstaller Windows, qu'il a pris ses pilotes sur le site du fabricant, et que Defender lui a sorti Trojan:Win32/Asruex.A au décompactage. Il dit ensuite avoir écrit à Geekom pour les prévenir.

20 mois plus tard, Tom's Hardware décrit sur les machines Geekom, des permissions administrateur, des frappes clavier interceptées et une connexion à un serveur de commande, et PCWorld raconte que des attaquants sont venus glisser une backdoor dans le paquet.

Ce fichier est donc bien un paquet Realtek générique, que DriversCloud héberge et redistribue depuis le 25 novembre 2022 et qui s'est fait vérolé ensuite en 2024. Sur l'origine de l'exemplaire qui traînait chez elle, Geekom dit dans son communiqué du 18 août qu'il s'agit d'une ressource obsolète oubliée sur de vieilles pages, mais jamais d'une intrusion.

Donc si vous avez téléchargé et lancé cet installeur LAN depuis une page support d'un de ces six modèles, vous êtes concerné !! Le Windows livré avec la machine n'est pas en cause, du moins d'après Geekom. Supprimez donc l'installeur, lancez un scan complet avec Windows Defender ou votre antivirus préféré, et récupèrez un pilote réseau faible chez Realtek ou directement via Windows Update.

De son côté, Geekom a invoqué la déesse de l'effet Streisand en demandant à VideoCardz de retirer son article mais VideoCardz a dit non évidemment...

Source : PCWorld

Trois chercheurs de l'université du Massachusetts à Amherst ont réussi à régler pour 3,19 dollars d'achats dans un supermarché avec une carte bancaire périmée !

Leur secret ?

Glisser une app maison entre la carte et le terminal qui trafique la date d'expiration de la carte.

En fait, leur montage relaie les échanges NFC et modifie au passage un champ que personne ne protège : la date d'expiration lue par le terminal. Leur papier s'appelle Zombie Cards Back Online , et a été présenté à USENIX Security 2026.

La mécanique tient en réalité à une bizarrerie du réseau Visa. Une carte annonce sa date d'expiration à deux endroits différents, et sur le kernel Visa, la date que le terminal consulte pour ses contrôles locaux n'est reliée à aucune signature. La banque, elle, regarde l'autre. Les deux devraient être liées cryptographiquement mais elles ne le sont pas.

Pire, ce kernel transmet à la banque un TVR entièrement à zéro. Le TVR, c'est le champ qui raconte ce que le terminal a vérifié et ce qui a coincé. Rempli de zéros, il ne raconte plus rien, du coup, la banque autorise une transaction sans savoir que les contrôles d'en face ont été contournés.

Reste que la portée est plus étroite que le tour de force le laisse croire. Sur cinq banques américaines testées, une seule a validé l'opération de bout en bout dans des conditions de laboratoire, permettant de payer jusqu'à 500 dollars. Une autre a laissé passer le terminal puis refusé côté banque. De leur côté, les kernels Mastercard, American Express et Discover, eux, ont rejeté les modifications.

Il faut aussi avoir la carte expirée à portée de NFC, et que la banque ait réémis la nouvelle avec le même numéro de compte, ce que les auteurs décrivent comme une pratique d'émetteurs américains.

Bref, c'est pas si simple et tous les essais ont eu lieu aux États-Unis donc rien ne dit non plus ce que ça donnerait sur un terminal français, où le sans contact plafonne de toute façon à 50 euros par paiement, 150 euros cumulés et 5 opérations avant que ça ne réclame le code. Puis de toute façon, le numéro de CB change intégralement à chaque renouvellement de carte, donc bon...

Six ans plus tôt, l'équipe de David Basin publiait The EMV Standard: Break, Fix, Verify , une application Android en relais sur du Visa sans contact, ce qui permettait de payer sans saisir de code. C'est vrai que les failles du paiement sans contact ne datent pas d'hier mais ce qui est neuf ici, c'est cette histoire de faiblesse au niveau de la date d'expiration.

Voilà, comme d'hab, Visa a été prévenu en mai 2025, relancé en décembre mais ni Visa ni les banques n'ont annoncé le moindre correctif pour le moment...

Source

Je viens d'apprendre qu'une carte Nvidia normalement dédiée au minage de cryptomonnaies, vendue avec 8 Go de mémoire en expose aujourd'hui 64 Go, sans que rien n'ait été remplacé ou soudé dessus... C'est ça la magie de Nvidia, la mémoire était bien là depuis le début, mais était juste maintenue en sommeil par le firmware.

Cette carte, la CMP 170HX est sortie il y a 5 ans pour miner de l'Ethereum. Elle est bâtie sur le GA100, le même silicium 7 nm que l'accélérateur A100 que Nvidia vend aujourd'hui autour de 3 500 dollars en version 40 Go. Et la mémoire HBM2e qu'on y trouve est physiquement présente sur la carte, quoi qu'affiche la fiche technique. Alors certes, débrider une carte Nvidia par logiciel n'a rien de neuf puisqu'on transformait déjà des GeForce en Quadro en 2013.

Mais cette fois, le déverrouillage exploite un bug de chargement de signature dans le BootROM du Falcon, le microcontrôleur de sécurité qui garde le démarrage de la puce. Et ce dernier se fait grâce à un outil nommé cmpunlocker , publié sous licence GPL.

Si vous voulez vous lancer, il vous faudra du Linux x86-64, un accès root et le pilote libre nvidia-open en version 610.43.0x. Votre carte 8 Go passera ainsi à 64 Go, une carte 10 Go à 40 Go, et les unités de calcul bridées reviendront naturellement avec. Et surtout, ce patch survit au redémarrage !

Le PCIe, lui, ne se déverrouille qu'à moitié. Passer de Gen1 à Gen2 est logiciel, mais la largeur reste coincée à quatre lignes parce que Nvidia a laissé 24 condensateurs de couplage vides sur le circuit imprimé. Aller au-delà du x4 veut donc dire les souder à la main et ça c'est pas donné à tout le monde.

Reste que ça donne environ 1 Go/s vers la carte. À titre d'exemple, un utilisateur du forum développeurs de Nvidia a réussi à charger un modèle 70B quantifié en une quarantaine de secondes, contre une dizaine avec la modification matérielle et le Gen2 x16. Pour de l'inférence sur une seule carte, ce goulot ne se paie donc qu'au chargement.

Le même utilisateur mesure un taux de 27,3 tokens par seconde en décodage sur un modèle Qwen2.5-72B, pour 150 à 180 watts, et explique que lors de ses tests, le GPU a réclamé un reset autour de 95% d'occupation mémoire, sur de très grandes fenêtres de contexte. Rien de gênant donc. Deux réserves par contre, et elles ne sont pas décoratives.... La première c'est que l' ECC figure toujours dans la liste des problèmes non résolus du projet, avec le NVLink et le PCIe Gen4, alors que c'est précisément le mécanisme qui pourrait nous dire si la mémoire déverrouillée tient dans la durée. Et la seconde, c'est que le palier des 80 Go a été testé, mais rejeté car instable.

Sur la question qui fâche maintenant, à savoir celle du silicium mis au rebut qui serait bridé car défectueux, ValdikSS, dans un fil sur Hacker News , écrit n'avoir trouvé jusqu'ici aucune carte dont la RAM soit réellement défectueuse. Le bridage ressemble donc à de la segmentation commerciale plus qu'à du recyclage de puces ratées, mais pour le moment, personne n'a fait tourner ces 64 Go assez longtemps pour le prouver.

Reste le prix... La 170HX se trouvait peu de temps avant ça, autour de 250 dollars sur eBay mais depuis que l'exploit circule, elle dépasse les 1 000 $... Bref, le verrou a sauté, et le prix est en train d'exploser !

Source : Tom's Hardware

Au début du mois d'août, une Toyota Yaris de 2009 est passée devant une caméra Flock à Las Vegas sans être "vue". Car même si la caméra l'a filmée correctement, le logiciel de détection, lui, n'a rien inscrit dans ses logs, comme si la rue était restée vide...

J'ai trouvé ça intéressant parce que ça ne nécessite pas de grande technologie... Non, il faut juste que la voiture soit recouverte d'un certain motif généré à l'aide d'un ordinateur. C'est un motif qui ne cache rien puisque la plaque d'immatriculation reste à sa place réglementaire et est parfaitement visible.

Mais ce qu'il faut savoir avant pour bien comprendre comment ça fonctionne, c'est qu'une caméra de lecture de plaques ne lit pas une plaque en permanence. Elle repère d'abord un véhicule dans l'image, puis va chercher la plaque dessus. Du coup, en cassant la première étape, la seconde n'a jamais lieu. La plaque reste donc visible mais le système n'a pas l'idée d'aller la lire...

Derrière l'expérience, on retrouve Bill Swearingen, un vieux de la vieille de la sécu qui a cofondé SecKC, le meetup sécurité de Kansas City. Son projet s'appelle noRecognition et fonctionne comme un fuzzer. Il génère un motif, le passe devant des modèles de détection, note ce qui échoue, et recommence et ainsi de suite... 31,7 millions de tests plus tard, il produit alors des motifs à la demande pour déjouer ce genre de caméra.

Alors pourquoi quelqu'un irait dépenser un an de calcul machine là-dessus ? Hé bien parce que Flock revendique 93 plaques correctement lues sur 100, pour plus de 20 milliards de lectures par mois et que l'Institute for Justice a recensé au moins 27 automobilistes innocents arrêtés, détenus ou emprisonnés depuis 2018 à cause d'une de ces erreurs de lecture...

Et dans près des deux tiers des cas, les policiers s'en sont rendu compte après avoir sorti leur arme. Bref, la polémique enfle aux États-Unis, encore plus depuis février dernier, dans l'Arkansas, quand un couple s'est retrouvé injustement menotté au bord de la route à cause d'une de ces caméras, pendant que leur bébé de six semaines attendait dans le siège auto.

Swearingen a même mis à dispo publiquement un tableau de bord public qui affiche en toutes lettres les résultats chiffrés qui sortent de ses modèles réels avec l'impression et la caméra simulées. Son tableau de bord indique également que pour le moment, aucun motif unique ne bat encore les onze modèles de caméra de son banc d'essai, en même temps, et surtout, il a mesuré jusqu'à 64 % d'écart entre les chiffres de son labo et les vrais tests réalisés dans le monde extérieur. J'ai rarement vu une page de vente aussi peu vendeuse ^^ mais au moins c'est honnête.

Et ça n'a pas empêché sa campagne Kickstarter de dépasser de 20 fois son objectif. Ses motifs générés se vendent en t-shirts et en hoodies, mais ce qui vaut pour une carrosserie ne vaut pas forcément pour un vêtement. En effet, une portière est plate, rigide et ce qui y est imprimé est fixe. Alors qu'un tissu se plie et se déforme, et Swearingen prévient qu'un motif imprimé trop grand ou trop petit cessera de fonctionner sans que ça ne se remarque.

Et chez nous en France ?

Hé bien les lecteurs de plaques tournent aussi donc possiblement, ça pourrait aussi fonctionner ici. Mais tout ceci reste géré au niveau de l'État et des communes, et c'est contrôlé par la CNIL. Même si on n'en est pas loin, ce n'est donc pas encore dans ce cauchemar très américain où ce sont des dizaines de réseaux privés comme Flock, revendus clé en main aux villes, qui font la loi, peu importe le taux d'erreur du logiciel.

Source : Bitdefender

Six chercheurs d'UC San Diego et d'Oberlin College ont présenté le 13 août dernier à l'USENIX Security Symposium de Baltimore un implant assez petit qui se branche sur un port de maintenance de la baie électronique d'un Boeing 737 et s'intercale ainsi entre le calculateur de vol et l'écran par lequel les pilotes le programment.

La trappe présente sur l'avion, qui y mène n'a ni serrure ni contrôle d'accès et est accessible depuis le sol, sans échelle. Les chercheurs estiment que ça peut se mettre en place en moins de 60 secondes, ouverture et refermeture comprises. Le boîtier, lui, disparaît sous le capuchon anti-poussière du connecteur.

Hé oui c'est un simple capuchon en plastique qui "protège" l'accès aux commandes de navigation d'un avion de ligne. C'est beau non ?

Ce connecteur donne un accès aux bus ARINC 429 qui transmette les échanges entre le calculateur, le FMC, et le clavier-écran du cockpit, le MCDU. La norme date de 1977 et ne prévoit aucune authentification et comme vous vous en doutez, c'est connu depuis longtemps, même si le plus souvent, les attaques envisagées sur les systèmes d'un avion visaient plutôt ses liaisons radio.

Toutefois, se brancher sur le bus ne suffit pourtant pas à le contrôler, puisque les autres équipements continuent d'émettre par-dessus. Sauf que les émetteurs légitimes passent par des résistances de 37,5 ohms qui brident leur courant, alors que le connecteur de maintenance, lui, attaque le bus en direct.

L'implant en profite alors pour pousser plus de courant que l'émetteur d'origine et écraser physiquement son signal. Les chercheurs appellent ça une attaque Bus Driver, et elle donne une interception complète du dialogue sans couper ni épisser le moindre fil.

Une fois ce dialogue sous contrôle, le boîtier ajoute un point de passage à la route programmée. Normalement, sur un 737, cette modification doit être confirmée par le pilote, qui appuie sur le bouton EXEC. Mais l'implant, lui, appuie tout seul, l'autopilote change de cap, et comme le voyant du bouton passe par le même bus, il reste éteint. Et comme les pages affichées sont réécrites en live pour montrer encore l'ancienne route, rien à l'écran ne trahit le changement.

Le même mécanisme peut servir aussi à fausser la masse de l'appareil saisie avant le départ, ou la température retenue pour calculer la poussée. Une masse sous-évaluée ou une température trop basse, et le calculateur commande alors une poussée insuffisante au décollage.

Bref, c'est la cata assurée... Et cela vaut pour tous les 737 NG et MAX.

Maintenant, reste à savoir dans quelles conditions cette attaque peut être réalisée. Car jusqu'à présent, tout a été validé mais uniquement sur un banc de vraies pièces de 737 câblées selon les schémas Boeing, et jamais sur un avion en service. Le Wi-Fi est bien intégré au boîtier, mais le papier précise que les auteurs n'ont pas pu tester si le signal de la cabine traverse le plancher de la baie.

Boeing a bien sûr été prévenu en avril 2020, et les chercheurs ont rejoué l'attaque avec succès sur le banc d'essai du constructeur en décembre 2023. Ils proposent de boucher ce type de connecteur, ou d'y déplacer les résistances de limitation. Boeing, lui, estime que "les couches de protection en place sur l'avion" limitent déjà "significativement la faisabilité et le risque d'attaques en conditions réelles".

Ouais les gars ont la flemme de sécuriser leur truc on dirait...

Source

Hé oui, ENCORE LUI !!

Jonathan Blow, le développeur de Braid et de The Witness, a annoncé hier (le 12 août) sur X qu'il laissait tomber VLC... La raison c'est 33 putain de secondes d'attente entre un clic sur un fichier MP3 et le début de la lecture, sous Windows (évidement). C'est vrai qu'une demi-minute pour lancer un son sur une machine récente, c'est abusé ! Du coup, il est repassé au bon vieux lecteur multimédia de Microsoft.

Son point de vue c'est que "tout un secteur du logiciel open source est dans un état franchement embarrassant" dès qu'il s'agit de tourner Windows. Je peux pas lui donner tord, c'est vrai que le ralentissement est réel sous Windows 11, sans qu'on sache vraiment pourquoi...

Mais heureusement, la réponse de VideoLAN ne s'est pas faite attendre et a replacer correctement le débat. Pour l'équipe de VLC, la lenteur vient d'un bug de Microsoft Defender arrivé avec une mise à jour de Windows 11, qui a mis le cache de plugins de VLC en quarantaine. L'antivirus maison de Windows a donc classé comme suspect, puis mis de côté, un fichier que VLC génère lui-même. VideoLAN écrit qu'il s'est retrouvé là "comme par magie".

Pour remettre VLC d'aplomb, VideoLAN propose donc de réinstaller le logiciel ou de régénérer ce cache. Mais pas besoin d'aller jusqu'à la réinstallation, puisque l'installeur Windows officiel dispose déjà d'un raccourci qu'il faut dans le dossier VideoLAN du menu Démarrer, "VLC media player - reset preferences and cache files".

Ce raccourci lance vlc.exe avec les deux options de remise à zéro, la configuration et le cache de plugins, puis referme aussitôt le lecteur. Ça devrait faire le taf même si attention, vos préférences partent aux chiottes avec le reste, donc si vous avez bricolé vos réglages de sortie audio, vos raccourcis clavier ou vos sous-titres, vous les perdrez. Mais ensuite, le cache, lui, se reconstruira au lancement suivant.

Après régénérer le cache n'empêche pas Defender de le rechoper par la suite. L'autre option, c'est donc d'exclure une bonne fois pour toutes vlc.exe de la liste d'analyse de l'antivirus.

Bref, ce genre de faux positif n'est pas nouveau chez Windows Defender, qui y'a pas longtemps a même pris des certificats DigiCert pour un cheval de Troie, sans parler des ISO Linux qui se font flagger régulièrement .

Voilà, hormis la comm de VLC pour le moment, personne n'a encore publié de détails techniques, et Microsoft n'a rien dit.

Source

ShieldBreak est un nouvel exploit qui vise l'antivirus livré avec Windows. Cela permet à un compte utilisateur limité de passer SYSTEM sur un Windows entièrement à jour, grâce notamment à Windows Defender qui lui sert de marchepied.

Le chercheur Nightmare Eclipse a sorti le code de son exploit en public y'a 2 jours, quelques heures après un Patch Tuesday qui corrigeait plus de 400 failles. Mais pas celle-ci évidemment... Une machine parfaitement à jour reste donc exposée.

Kevin Beaumont, ancien de chez Microsoft, a testé l'exploit et confirme qu'il fonctionne sur un Windows 11 à jour. Sa lecture technique, en revanche, diffère de celle du chercheur. Nightmare Eclipse présente ShieldBreak comme un contournement complet du correctif de RoguePlanet, sa faille précédente, alors que Beaumont souligne que les deux reposent sur des mécanismes très différents.

L'attaque réclame un accès local et l'exécution du programme, elle ne s'attrape pas en visitant une page web. Elle a été testée sur Windows 11 25H2 et Windows Server 2025, Windows 10 étant déclaré vulnérable sans être pris en charge par le code publié. Et il faut que Defender soit activé pour que ça marche.

Cette publication sans préavis n'arrive pas de nulle part. En mai, Microsoft a publié un billet qualifiant d'injustifiables les divulgations non coordonnées qui mettent du code d'exploitation entre les mains d'acteurs malveillants, en rappelant que sa Digital Crimes Unit continuerait à poursuivre ces acteurs. Le texte ne visait pas nommément les chercheurs. Le milieu de la sécurité l'a quand même reçu comme une menace.

Microsoft a fait ensuite machine arrière sur les réseaux sociaux, en assurant ne pas vouloir s'en prendre à ceux qui publient de la recherche. Le billet d'origine, lui, est toujours en ligne et les publications n'ont pas ralenti pour autant : une dizaine de zero-days Windows depuis avril, dont BlueHammer et GreatXML dont je vous ai déjà parlé.

Microsoft dit avoir connaissance de la vulnérabilité signalée et enquêter sur la validité des affirmations mais pour le moment, la faille n'a même pas d'identifiant CVE à elle, et reste rattachée au correctif qu'elle est censée contourner. Bref, si ça vous fait flipper comme faille, désolé, il n'y a rien à installer pour l'instant pour fixer le problème.

En attendant, Beaumont a mis en ligne des requêtes de "chasse" pour Defender for Endpoint qui repèrent quand un processus étranger à Defender charge ses bibliothèques, ou qu'un processus non validé charge celles de l'API Cloud Filter. Tout ça via le même processus.

Mais c'est de la détection, et pas un correctif...

Source

Je m'intéresse à la sécurité mobile depuis un paquet d'années, et cette attaque-là, je ne l'avais jamais vue. Le point de départ n'est ni le réseau, ni un SMS piégé, ni une appli vérolée. C'est la carte SIM elle-même ! En effet, des chercheurs de l'université de Birmingham et de Fuzzware lui ont fait donner des ordres au modem qui l'héberge.

Le mécanisme s'appelle RUN AT et c'est une commande proactive puisque la carte ne se contente pas de répondre à l'appareil, mais elle lui demande aussi d'exécuter une commande AT. C'est ce même langage qui pilote les modems depuis le Hayes Smartmodem de 1981 donc autant dire qu'on a là, une vraie console générique dispo sur un bout de plastique.

Et sur une borne de recharge Autel, ça donne tout simplement une exécution de code. Le module Quectel qui l'équipe, fait passer le texte reçu dans un appel shell, avec une liste noire de caractères censée bloquer les échappements. Mais un simple retour à la ligne passe au travers... Et voilà comment 2 étapes plus loin, les chercheurs sont parvenus à faire tourner leur propre code, piloté depuis la SIM. Décidément, les bornes de recharge collectionnent les mauvaises surprises .

Autre exemple sur un smartphone OPPO Reno 14 F 5G, où une seule commande coince le téléphone en 2G... Son propriétaire ne peut alors plus revenir en arrière : ni le mode avion, ni la sélection manuelle du réseau, ni la désactivation de la SIM dans les réglages ne permet de restaurer de la 5G ou de la 4G. Or la 2G n'a pas d'authentification mutuelle, donc une fausse antenne redevient un facteur de risque sur ce genre de matos récent. Deux autres commandes éteignent même le téléphone ou tuent son modem.

Reste la condition d'entrée, et elle est lourde : la carte doit déjà être hostile. Cela passe au choix par un échange physique, un interposeur glissé sous la puce, un opérateur compromis, ou du sabotage en usine... Mais surtout, rien là-dedans n'exploite de bug exotique. En fait, cette capacité est écrite dans les spécifications cellulaires, ce qui fait dire au chercheur Marius Muench que ces attaques sont conformes au standard.

Maintenant sur votre téléphone perso, le scénario d'une telle attaque reste assez serré. Mais sur un boîtier 4G oublié dans un local technique, beaucoup moins. Sur 26 appareils testés, 9 exposent l'interface, dont 6 modems IoT sur 8, contre 3 téléphones sur 18. Par contre, ni iPhone ni Pixel ne sont faillibles et Qualcomm a préparé une configuration durcie qui la coupe par défaut. De son côté, Quectel travaille encore dessus...

Bref, si vous exploitez des équipements cellulaires sur le terrain, une seule question au fournisseur du module suffit : RUN AT est-il activé, et peut-on le couper ? Notez qu'aucune attaque de ce type n'a été signalée pour le moment.

Source

Dans la série "les gens qui assurent notre sécurité n'ont pas fait leur job jusqu'au bout", voici une chouette histoire de caméras montées sur les drones navals de la Royal Navy qui, ÉVIDEMMENT, envoyaient des signaux vers une adresse IP située en Chine. Et cette découverte ne vient pas d'une opération de contre-espionnage mais d'une simple évaluation de vulnérabilité de routine, menée par le ministère de la Défense britannique sur son propre matériel.

Ces caméras sont celles qui équipent les K3 Scout, des bateaux sans équipage que la Royal Navy et les Royal Marines utilisent pour la surveillance et la protection de force.

Charger la vidéo depuis YouTube Ce clic autorise une connexion à Google : adresse IP transmise et traceurs possibles. En savoir plus Voir cette vidéo sur YouTube

Et le signal en question porte un nom que tout le monde connaît en domotique : un heartbeat. C'est le ping le plus banal qui existe, celui qui dit "je suis en ligne, je fonctionne" et rien d'autre. C'est le même que crache votre caméra IP du salon, dont je vous parlais déjà avec OpenIPC .

Le ministère britannique affirme qu'aucune donnée sensible, aucun système militaire et aucune donnée gouvernementale n'ont été consultés, compromis ou transmis hors des canaux autorisés et ajoute que ses procédures de test ont repéré le problème "tôt".

La connectivité internet des caméras a quand même été coupée puisque même si ça n'a l'air de rien, un mouchard qui se contente de dire bonjour reste un mouchard qui connaît le chemin.

Reste maintenant la question de comment ce composant est arrivé sur un engin de reconnaissance militaire. En fait, les caméras ne viennent pas de Kraken Technology Group, le constructeur britannique du K3 Scout, mais d'un sous-traitant tiers qui pourtant avait fourni des assurances sur le fait que ses caméras répondaient aux exigences de sécurité, y compris celles rattachées au National Defense Authorization Act américain.

Bref, de la paperasse, des assurances, mais pas un démontage ni une capture de trafic... Kraken dit avoir mené un audit complet avec la Royal Navy une fois les communications découvertes. J'espère bien ^^ !

Côté portée, ça concerne les 20 K3 Scout achetés dans le cadre du Project Beehive, un programme de 12,3 millions de livres, en service chez les Royal Marines depuis mars. Le Telegraph , qui a sorti l'affaire, écrit que du matériel lié à la préparation d'une éventuelle mission britannique dans le détroit d'Ormuz avait été enregistré sur ces appareils.

Par contre, ce qu'on ne sait toujours pas, c'est la marque de la caméra et la nature exacte du composant chinois car aucun rapport ne les nomme pour le moment... Mais j'espère que ça n'a pas été aussi intégré sur du matos français...

Source

Voici une bonne nouvelle du côté de Chrome puisque ce dernier a commencé à enfermer la clé qui signe votre session dans la puce de sécurité de votre machine, c'est-à-dire le TPM sous Windows, ou la Secure Enclave sous macOS. Le serveur envoie un défi, le navigateur le signe, et la clé privée ne sort jamais du silicium. Ainsi, un cookie de session recopié ailleurs ne suffit donc plus à entrer dans votre compte.

Ça s'appelle DBSC, pour device-bound session credentials et comme le résume Scott Helme, qui vient de déployer le protocole chez Report URI : "*L'attaquant peut voler le cookie, mais il ne peut pas répondre à un défi DBSC en le signant avec la clé privée, qui reste en sécurité sur votre appareil *".

Depuis que la double authentification et les passkeys se généralisent, voler un mot de passe ne rapporte plus grand-chose et c'est pour cela que les attaquants sont passés au cookie de session, un bout de texte qui prouve au site que vous êtes déjà bien connecté.

Ils le récupèrent avec un infostealer, ou avec une page de phishing qui relaie votre vraie connexion, comme le faisait la plateforme Tycoon 2FA démantelée par Europol . Ensuite ils collent le cookie dans leur navigateur et héritent de votre session. Et votre bonne vieille 2FA n'y change rien, puisqu'elle est déjà passée.

Donc ce DBSC c'est une bénédiction, surtout que côté utilisateur, il n'y a rien à activer.

Google a basculé ses propres comptes dessus fin mai, sur Chrome pour Windows, et il n'existe ni réglage administrateur ni réglage utilisateur pour le couper. Pour le reste du web, il faut évidemment que le site ait implémenté le protocole de son côté, et Chrome ne l'ouvre encore qu'à une partie des utilisateurs (dispo à partir de la version 147 sous Windows et 150 sous macOS).

Pour vérifier si c'est en place chez vous, ouvrez les outils de développement (F12) sur un site où vous êtes connecté, votre compte Google par exemple, onglet Application, et cherchez "device bound sessions". Si la ligne apparaît, c'est que c'est actif. Sinon, c'est que le site, votre version de Chrome ou votre machine ne suivent pas encore, et Chrome retombe alors sur la session classique sans rien casser.

Sur Firefox, en revanche, il ne faudra pas l'attendre car Mozilla a acté début août une position officielle négative sur le sujet. Les deux reproches que fait Mozilla c'est que DBSC laisse une fenêtre ouverte pendant laquelle un cookie volé reste utilisable, et que son flux de réauthentification est un protocole ad hoc qui ne colle pas à la gestion normale des cookies.

Mozilla craint aussi qu'on finisse par exiger des sites une attestation matérielle, ce qui limiterait le choix du matos... Google répond que rien de tel n'est prévu, et que faire signer chaque requête s'est révélé infaisable à grande échelle. Mais bon, cette position négative n'interdit pas une implémentation future... On verra bien. Apple, elle, n'a jamais tranché, mais a prévenu que DBSC risquait de compliquer la restauration d'un appareil depuis une sauvegarde.

Bref, aujourd'hui, ça se joue donc sur Chrome, et seulement là où le site a implémenté DBSC, mais je pense que ça s'étendra de plus en plus à l'avenir.

Source

CHERRY a annoncé deux appareils à carte à puce, un clavier complet avec lecteur intégré baptisé Smart Board 1150, et un terminal séparé, le Smart Terminal ST-1150. Ils remplacent le KC 1000 SC et le ST-1144.

Une carte à puce sert ici à prouver qui vous êtes. Vous l'insérez, elle signe électroniquement un document, elle ouvre une session sur un réseau ou elle déchiffre un fichier, sans que la clé privée qu'elle contient ne sorte jamais de la puce.

Les deux appareils s'appuient sur le pilote CCID que Microsoft livre déjà dans Windows, et sur pcsc-lite sous Linux et macOS. La norme CCID permet à un lecteur de dialoguer avec le système d'exploitation sans code maison, et pcsc-lite en est l'implémentation libre côté Unix.

Aucun pilote propriétaire à installer, donc. Vous branchez et ça fonctionne, y compris sur une machine Linux, ce qui est encore assez rare pour ce type de matériel.

Screenshot

Les deux modèles embarquent aussi un contrôleur à mémoire flash, et le firmware peut être mis à jour après le déploiement. Ce genre de lecteur était jusqu'à présent figé pour toute sa durée de vie, avec les failles qu'il avait le jour de sa fabrication.

Le communiqué ne dit hélas rien sur la signature de ces mises à jour. Sur un périphérique de sécurité, la question n'a rien de cosmétique, parce qu'un firmware modifiable est aussi un firmware attaquable si personne ne vérifie d'où vient l'image installée.

Le terminal lit et écrit les cartes, pour ouvrir une porte, se connecter au réseau de l'entreprise ou valider une transaction en ligne. Il est fabriqué entièrement en Europe. CHERRY veut clairement faire les yeux doux aux administrations et aux organismes de défense, avec les certifications américaines TAA et FIPS-201 au passage, et une base lestée en métal qui permet d'y glisser la carte d'une seule main.

Le clavier ajoute pour sa part une touche Copilot, ce qui sur un poste à données sensibles est quand même quelque peu audacieux. Il existe aussi en version conforme au Trade Agreements Act américain, pour les agences fédérales et les installations militaires soumises à des règles d'approvisionnement particulières, mais bon a priori ça ne devrait pas trop vous concerner (même si on a de plus en plus de lecteurs américains depuis que le site est traduit !).

Le Smart Board 1150 est vendu 49,99 euros. Le Smart Terminal ST-1150 descend à 34,99 euros, et les deux sont disponibles dès maintenant.

J'avoue que je ne pensais plus voir sortir de nouveaux lecteurs de carte à puce en 2026.

Source : Cherry

JFrog, une société spécialisée dans la sécurité de la chaîne logicielle, a passé au crible les 55 vulnérabilités déposées par un seul compte GitHub. Cinquante-quatre étaient entièrement fabriquées, une seule décrivait un vrai bug.

Six d'entre elles visaient SQLite, la petite base de données embarquée qu'on retrouve dans à peu près tous les téléphones et navigateurs de la planète, avec des scores de gravité affichés jusqu'à 9,8 sur 10. Les quarante-neuf autres s'en prenaient à libraw, une bibliothèque de traitement d'images, et à un module audio pour cartes ESP32.

Les rapports ne résistent pas à une vérification. L'un s'appuie sur une fonction qui n'existe pas dans la version de SQLite qu'il prétend attaquer. Un autre cite les lignes 3555 et 3575 d'un fichier qui n'en compte que 2706.

Ces failles n'ont été bloquées à aucune étape. Elles ont atterri dans le NVD, la base de référence américaine des vulnérabilités, avec un enrichissement fourni par la CISA, l'agence fédérale de cybersécurité, qui a validé les scores critiques au passage. Red Hat a dû redescendre l'une d'elles de 10 sur 10 à 7,6.

Le formulaire public par lequel on déclare une faille ne vérifie pas sérieusement l'identité du déclarant. Aucune étape du processus n'exige de preuve de concept ni la moindre reproduction du bug. Un texte plausible suffit.

Le reste est automatique. La fiche descend dans les bases dérivées, puis dans les scanners que les entreprises font tourner sur leur propre code, et une équipe finit par chercher un correctif à un problème qui n'a jamais existé. MITRE, l'organisme qui attribue ces identifiants, a rejeté le lot le 1er août.

Le NIST, chargé d'analyser ces fiches, avait déjà plus de 27 000 vulnérabilités en attente fin 2025, et un rapport officiel de mai dernier lui reprochait un manque de planification et de décision.

Les mainteneurs de logiciels libres décrochent. Le projet curl a fermé son programme de primes début 2026, après sept ans, son taux de rapports confirmés étant passé de 15 % à moins de 5 % sous le déluge de textes générés par IA.

Daniel Stenberg, qui le maintient, a ensuite fermé le guichet aux signalements du 1er juillet au 3 août. Bref, ce qui faisait tenir le système, c'est que fabriquer un faux rapport crédible demandait du temps à quelqu'un.

Source et visuel : The Register et JFROG

727 mots de passe testés par seconde, c'est le score incroyable d'une Game Boy Advance reprogrammée en casseur de mots de passe par solst-ice, un développeur qui avait visiblement une console de 2001 qui traînait et pas mal de temps à tuer ^^. Son projet s'appelle GBA-Hashcat, et c'est un "port" de hashcat (le célèbre outil de crackage) sur le petit hardware portable de Nintendo.

Enfin, un port entre grosses guillemets, parce que le vrai hashcat gère plus de 300 algorithmes de hash optimisés et une palanquée de méthodes d'attaque alors que là, vous avez le droit à un seul truc, du SHA-256, et rien d'autre.

Le programme embarque la wordlist ignis-1M, une liste de 8 Mo qui contient environ 1 million de mots de passe parmi les plus courants. Pour chaque ligne, la GBA calcule le hash SHA-256, le compare à un hash cible codé en dur dans le programme, et regarde si ça correspond.

C'est une attaque par dictionnaire, quoi, sauf que, je vous rappelle, ça tourne sur une puce ARM7TDMI cadencée à 16,78 MHz avec 288 Ko de RAM.

Du coup, forcément, ça rame de fou... au rythme de 727 hachages par seconde mais c'est normal car cette console n'a jamais été pensée pour ce genre de calcul. Pour vous donner une idée, un PC moderne avec un GPU décent va environ 30 millions de fois plus vite, soit des milliards de tentatives par seconde.

Alors que la GBA, elle, met une bonne vingtaine de minutes à avaler toute sa liste de 1 million de mots.

Après côté bidouille c'est assez fort car, certes, la wordlist de 8 Mo tient dans la cartouche, mais faire tourner une routine SHA-256 propre sur une puce aussi poussive, avec ses malheureux 288 Ko de RAM pour bosser, il faut le vouloir ! Solst-ice s'est donc appuyé sur le moteur Butano, un framework C++ open source taillé pour développer des jeux GBA, qu'il a détourné pour faire mouliner des hashs à la place de sprites.

Et voilà, ce projet loufoque rejoint la longue tradition des gens qui font faire n'importe quoi à leur Game Boy Advance, comme ce clavier GBA à monter soi-même que je vous montrais récemment.

Bref, comme un ministre ou un notaire, ça ne sert strictement à rien, et c'est pour ça qu'on kiffe ! Le code est sur le GitHub de solst-ice si vous voulez jouer.

Source

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