Vous vous souvenez de BadUSB ? Mais siiii, c'est ce truc dévoilé en 2014 à la Black Hat qui avait foutu la trouille à tout le monde. Ça montrait qu'un simple périphérique USB pouvait se faire passer pour un clavier et balancer des commandes à votre place. Hé bien depuis, les attaques se sont bien raffinées et c'est pourquoi un dev vient de proposer un module kernel Linux capable de détecter ces saloperies.

Enfin !

Ce module s'appelle hid-omg-detect et c'est signé Zubeyr Almaho. Le patch (déjà en v2) a été soumis le 4 avril dernier sur la LKML. Alors je pense que vous allez vous dire que c'est encore un truc qui va bloquer par défaut vos périphériques USB sauf que non, ça ne bloque rien. En fait, il surveille passivement les périphériques HID (claviers, souris...) et leur attribue un score de suspicion basé sur trois critères.

D'abord, l'entropie des frappes clavier. Un humain tape de manière irrégulière, avec des pauses, des hésitations, des fautes (perso je fais au moins 3 fautes de frappe par phrase ^^). Un câble trafiqué, lui, balance ses commandes avec une régularité de métronome, genre 500 caractères en 2 secondes sans une seule erreur. Ensuite, y'a la latence entre le branchement et la première frappe. Si votre "clavier" commence à taper immédiatement après avoir été branché... y'a comme un souci. Et enfin, le fingerprinting des descripteurs USB pour repérer les vendor/product IDs suspects ou les anomalies dans les descripteurs HID.

Pas con hein ? Et si le score dépasse un certain seuil (configurable), hop, le module balance un warning dans dmesg et vous oriente vers USBGuard pour bloquer le périphérique. Parce que hid-omg-detect ne touche à rien lui-même. Il sonne juste l'alarme, et c'est à vous d'agir !

Mais alors pourquoi lancer ça maintenant ?

Hé bien parce que les outils d'attaque USB sont devenus légion ! Les câbles O.MG (créés par le chercheur MG et distribués via Hak5), par exemple, ça ressemble à un câble USB lambda que vous emprunteriez sans réfléchir pour charger votre téléphone. Sauf que dedans y'a un implant WiFi capable d'injecter des frappes, de les logger, de spoofer les identifiants USB, le tout contrôlable à distance. Quand je pense qu'il y a quelques mois, des chercheurs montraient qu'une simple webcam Lenovo pouvait être transformée en dispositif BadUSB ... Sa fé grav réchéflir 🤓 comme dirait les citoyens souverains ^^.

Maintenant, en attendant que le patch soit accepté, vous n'êtes pas totalement démunis non plus. Des outils comme USBRip (un script Python, pip3 install usbrip) permettent déjà de tracer les connexions et déconnexions USB en parsant /var/log/syslog. Y'a pas ce scoring d'anomalies, mais au moins vous avez un historique pour savoir qui a branché quoi et quand. Et si vous êtes vraiment parano (et franchement, vous avez raison de l'être), USBGuard peut carrément whitelister vos périphériques de confiance et bloquer tout le reste. Mais le problème d'une telle solution c'est que ça demande de maintenir une liste blanche à jour, ce qui n'est pas toujours pratique quand on branche 15 trucs par jour.

On verra si les mainteneurs du kernel l'accepte... Après ça ne protégera pas contre tous les scénarios non plus. Un périphérique qui attend 30 secondes avant de commencer son injection pourrait passer sous le radar. Et si un attaquant injecte du jitter aléatoire dans ses frappes pour simuler un humain, là ce sera plus compliqué. Mais combiné avec USBGuard, ça donnera enfin une vraie ligne de défense native contre les attaques par périphériques USB piégés . Et c'est quand même mieux que de boucher ses ports au plâtre et ciment (Mais pleure pas au dessus du mortier...) !

Bref, va falloir garder un œil là-dessus.

Source

Quand on gère un serveur, y'a un truc qui rend dingue, c'est le bruit de fond de ces dizaines de milliers d'IPs qui scannent vos ports, qui tentent du bruteforce sur le port 22, qui cherchent des failles WordPress ou des phpMyAdmin oubliés... et surtout qui font tourner Fail2ban à plein régime dans les logs pour stopper ce qui peut l'être.

Fail2ban est d'ailleurs hyper réactif mais il attend qu'une IP fasse une connerie dans vos logs Apache ou SSH avant de la bloquer. Donc c'est quand même un peu tard.. Alors si on pouvait carrément virer le gros du trafic pourri avant même qu'il arrive à nos services ? Ce serait pas mieux ?

Hé bien c'est exactement ce que fait Data-Shield IPv4 Blocklist , un projet open source qui maintient une liste d'environ 100 000 adresses IP identifiées comme malveillantes. Le principe est simple... on colle l'URL RAW de la liste dans la config de son firewall (genre dans les alias d'OPNsense ou les External Block Lists de Fortinet) et hop, tout ce beau monde est filtré au niveau périmétrique. La liste (un simple fichier texte avec une IP par ligne) est rafraîchie toutes les 6 heures avec une fenêtre de rétention de 15 jours, du coup les IPs qui ne sont plus actives finissent par sortir automatiquement.

Côté compatibilité, c'est plutôt large : OPNsense, Fortinet, Palo Alto, F5 BIG-IP, Stormshield, Synology NAS, BunkerWeb... donc clairement, la plupart des pare-feu et WAF du marché peuvent ingérer la liste directement via une URL. Et pour les équipements un peu anciens qui ont des limites sur le nombre d'entrées, y'a même des listes splittées en paquets de 30 000 IPs.

Le projet est maintenu depuis 2023 par Duggy Tuxy, un CISO qui a visiblement décidé que ses week-ends aussi seraient consacrés à la threat intelligence. Presque déjà 4 000 commits sur le dépôt Git, soit des mises à jour quasiment tous les jours. Et c'est impressionnant car le taux de faux positifs affiché est de moins de 2 par mois, ce qui franchement, pour une liste de cette taille, est plutôt fou.

D'ailleurs, si vous utilisez déjà FireHOL pour vos listes de blocage, Data-Shield peut très bien venir en complément. L'idée c'est d'empiler les couches de défense... blocklist périmétrique au niveau iptables ou nftables en première ligne, puis CrowdSec ou Fail2ban pour le trafic qui passe quand même. Un défense en profondeur donc !

Attention par contre, la liste est pensée uniquement pour le trafic entrant (WAN vers LAN). L'appliquer en sortie bloquerait vos propres connexions légitimes. Et sauf si votre firewall gère le rechargement dynamique, pensez également à automatiser le refresh via un cron toutes les 6 heures.

Et pour assurer une haute disponibilité, le projet est distribué sur 5 miroirs : GitHub, GitLab, jsDelivr CDN, BitBucket et Codeberg. Du coup même si une source tombe, vos firewalls continuent à se mettre à jour.

Bref, si vous cherchez à réduire le bruit sur vos serveurs sans vous prendre la tête, allez, c'est gratuit, c'est sous licence GPLv3 et ça se configure en 2 minutes. Merci à Duggy Tuxy pour le tuyau !

Les boîtiers KVM IP, c'est le genre de matos qu'on branche dans un rack et qu'on oublie dans un coin pendant des années. Hé bien va falloir vous souvenir de où vous les avez mis les copains parce que des chercheurs d'Eclypsium viennent de retourner de fond en comble 4 modèles populaires... et c'est pas joli joli. A l'intérieur il y on trouvé pas moins de 9 failles, dont une qui score à 9.8 sur 10 en gravité CVSS. Autant dire qu'on n'est plus dans le "petit bug rigolo oh oh" qui fait marrer votre admin sys.

Pour ceux qui débarquent, ces petits appareils dont l'acronyme veut dire "Keyboard Video Mouse", permettent de contrôler un serveur à distance via le réseau, clavier, souris et écran compris, comme si vous étiez physiquement devant la machine. Hyper pratique donc pour gérer un homelab ou une salle serveur, et ça coûte entre 50 et 200 euros sur Amazon. Du coup, y'en a partout !!!

Les chercheurs Paul Asadoorian et Reynaldo Vasquez Garcia ont passé au crible le GL-iNet Comet RM-1, le JetKVM, le Sipeed NanoKVM et l'Angeet ES3 et ça fait mal : authentification manquante sur des fonctions critiques, injection de commandes OS, ports UART qui filent un accès root direct, et des firmwares qu'on peut remplacer sans aucune vérification de signature. En gros, c'est la fête du slip côté sécu !

Le truc vraiment relou avec ce type d'appareils, c'est qu'en fait ils opèrent en dessous de votre OS. Pas d'antivirus, pas d'EDR, rien ne les voit. Un attaquant qui compromet votre switch de contrôle distant peut alors injecter des frappes clavier, booter depuis une clé USB (bye bye le chiffrement de disque et le Secure Boot), contourner l'écran de verrouillage, et planquer une backdoor directement dans le firmware du boîtier. Tout ça sans que votre machine ne bronche car un KVM compromis, c'est pas un stupide gadget IoT de plus sur votre réseau... Là je vous parle vraiment d'un accès direct et silencieux à toutes les machines qu'il contrôle.

Et c'est pas juste théorique puisqu'en 2025, des travailleurs nord-coréens infiltrés dans des boîtes américaines utilisaient des PiKVM et TinyPilot pour contrôler à distance les laptops d'entreprise depuis des "laptop farms". Voilà le genre de scénario qu'on rend possible quand le firmware n'a même pas de signature. C'est un peu comme ces caméras IoT bourrées de failles sur lesquelles un chercheur faisait tourner DOOM... sauf qu'ici, l'attaquant prend le contrôle de vos serveurs, pas d'un flux vidéo.

Et histoire de parfaire le tableau, côté correctifs c'est la jungle intégral !! JetKVM a patché en v0.5.4, Sipeed en v2.3.1, GL-iNet promet un fix en v1.8.1 beta et pour l'Angeet ES3, qui cumule les 2 failles les plus sévères (scores 9.8 et 8.8), y'a aucun correctif prévu. Oupsy oups...

Donc si vous avez un de ces boîtiers qui traîne, voilà ce qu'il faut faire. D'abord isolez-le sur un VLAN de management dédié (jamais sur le réseau principal), coupez-lui l'accès Internet, activez le MFA si c'est supporté, et vérifiez que votre appareil n'est pas exposé publiquement via un scan de votre IP. Mettez également le firmware à jour, sauf si c'est un Angeet... là, franchement, faut débrancher.

Bref, si vous avez un de ces machins dans votre rack, traitez-le comme un point d'accès critique... parce que c'en est un !

Source

Telnet en big 2026... bah oui ça existe encore les amis ! Et surtout c’est toujours aussi troué ! J'en veux pour preuve le daemon telnetd de GNU InetUtils qui vient de se prendre une 2ème faille critique en l’espace de deux mois, et celle-là, elle pique de fou !

Il s'agit de la CVE-2026-32746 , elle permet d’obtenir un shell root sur n’importe quel serveur Linux ou BSD exposant le port 23, et l’attaque se fait avant même que le prompt de login n’apparaisse. Pas besoin de mot de passe, pas besoin de compte. Juste une bonne vieille connexion TCP et un paquet SLC malformé et c'est parti mon kiki !

En fait, le bug se planque dans le handler SLC (Set Local Characters) du code source C de telnetd. Ainsi, quand un client ouvre une socket TCP sur le port 23, y’a une phase de négociation d’options avant l’authentification. L’attaquant envoie alors un paquet SLC contenant un nombre anormal d'octets, et ça déclenche un buffer overflow de type out-of-bounds write dans la mémoire du processus. Et boom, exécution de code arbitraire avec les privilèges root ! Et ça, ça donne un score CVSS de 9.8 sur 10 soit quasi la note maximale !

Toutes les versions de GNU InetUtils telnetd jusqu’à la 2.7 sont touchées. Toutes vulnérables, et pour le moment, aucun patch n’est disponible à ce jour. C’est la boîte de cybersécurité israélienne Dream, via son chercheur Adiel Sol, qui a découvert le pot aux roses et publié l’advisory le 11 mars dernier. Le patch officiel du mainteneur GNU est attendu pour le 1er avril (et non, c’est pas un poisson).

Ça craint surtout qu'il y a à peine 2 mois, une autre faille critique dans le même daemon, la CVE-2026-24061 (aussi scorée 9.8), avait déjà été divulguée. Et celle-là, la CISA l’a depuis ajoutée à son catalogue de vulnérabilités activement exploitées dans la nature. Ça me rappelle carrément la faille RCE dans cups-browsed l’an dernier... Ces vieux services réseau, c’est dingue comme ça revient régulièrement.

systemctl stop telnet.socket && systemctl disable telnet.socket

iptables -A INPUT -p tcp --dport 23 -j DROP

Faut le reconnaître, la doc et qui plus est, la doc réseau, c'est un peu le parent pauvre du homelab. Tout le monde sait qu'il faudrait la tenir à jour sur un petit wiki tout mignon mais personne le fait parce qu'on n'est pas cinglé et qu'on aime trop la vie pour ça. Heureusement, pour nous aider, y'a maintenant Scanopy qui est un outil open source qui scanne automatiquement votre réseau pour générer une topologie interactive incroyable qui se met à jour toute seule !

Pour l'installer, deux lignes suffisent :

curl -O https://raw.githubusercontent.com/scanopy/scanopy/refs/heads/main/docker-compose.yml
docker compose up -d

Un vieux smartphone Android, c'est quoi en fait ? Un bon petit quad-core, 1 ou 2 Go de RAM, et du WiFi. Soit de quoi largement servir des pages web finalement... Hé bien CompHost vous montre comment en faire un serveur en quelques commandes, sans rooter quoi que ce soi. Vous faut juste Termux et basta !

En gros, vous installez Termux depuis F-Droid sur n'importe quel Android 7+ (pour Android 5-6, y'a également une version spéciale dispo sur GitHub), vous tapez pkg update && pkg upgrade -y puis termux-setup-storage -y, et hop, vous avez un environnement Linux sur votre téléphone.

Un vieux téléphone qui sert des pages web, la classe quand même

De là, un pkg install python suivi d'un python -m http.server 8080 et votre serveur web tourne ! Pensez surtout à lancer termux-wake-lock pour éviter qu'Android tue le processus en arrière-plan, sinon votre super site web ne sera pas accessible longtemps.

Le wiki fournit aussi des fiches PDF, une cheatsheet Termux et des présentations annotées pour ceux qui voudraient par exemple animer un atelier. Bref, j'ai trouvé ça plutôt bien ficelé !

D'ailleurs, j'sais pas si vous vous souvenais, mais je vous avais déjà parlé de Far Computer qui héberge un site sur un Fairphone 2 avec PostmarketOS, sauf que CompHost a une approche un peu différente. En fait y'a pas besoin de flasher l'OS ni besoin d'avoir un PC Linux sous la main et encore moins un bootloader à déverrouiller. Vous installez une app, vous ouvrez un terminal, c'est parti. Du coup c'est bien plus accessible, même si faut quand même être prêt à taper quelques commandes.

Le truc sympa avec Termux, c'est que ça tourne dans une sandbox Android classique, donc sans root et le gestionnaire de paquets pkg donne accès à tout ce qu'il faut pour héberger ce que vous voulez comme Python, Node.js, nginx...

Et aussi bizarre que ça puisse paraitre, votre vieux Samsung de 2018 a largement les specs pour servir un site statique, une petite API ou même un wiki perso. Et vu que ces machins consomment que dalle en électricité (2-3 watts à otut casser), c'est carrément viable comme micro-serveur permanent branché dans un coin (surveillez quand même l'état de la batterie, les vieilles cellules Li-ion n'aiment pas forcement rester en charge 24/7).

Après côté limites, attention, c'est pas pour iPhone et pour les Android vraiment antiques (genre Android 4 et moins), le wiki renvoie vers PostmarketOS qui flashe une vraie distrib Linux sur le mobile... là c'est plus technique, par contre.

Ce projet CompHost est dispo sur GitLab et comme ça, au moins, plutôt que de jeter vos appareils, vous leur filez une utilité concrète. Puis ça permet de piger ce qu'est vraiment un serveur web... Et quand je vois que certains montent même des clusters Kubernetes avec des vieux smartphones , je me dit que y'a vraiment un filon à creuser côté recyclage / compostage de vieux matos.

Et qui sait, peut-être qu'un jour, Korben.info tournera sur l'un de ces trucs ?