[{"uuid":"4cf880e6-e4e0-42dd-aae2-675837850b83","slug":"compromission-de-jdownloader-6-7-mai-2026-analyse-indicateurs-et-procedure-de-detection","title":"JDownloader : quand le CMS devient la faille","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.webp","published":true,"published_at":"2026-05-12 17:09","created_at":"2026-05-12 17:10:36","updated_at":"2026-05-12 17:21:01","tags":[],"plain":"À propos de l'incident de sécurité affectant le site officiel jdownloader.org les 6 et 7 mai 2026.\r\n\r\nJDownloader expliqué simplement\r\n\r\nJDownloader est un gestionnaire de téléchargements écrit en Java, distribué gratuitement par l'éditeur allemand AppWork GmbH depuis plus de quinze ans. Il sert essentiellement à automatiser la récupération de fichiers depuis des hébergeurs (Mega, Uptobox, Rapidgator…), des plateformes vidéo et des services de liens premium. Côté utilisateur, c'est l'outil qu'on lance pour récupérer une série de fichiers en une opération, plutôt que cliquer sur cent liens un par un. L'application est multiplateforme — Windows, Linux, macOS — et tourne sur quelques millions de postes dans le monde.\r\n\r\nLe projet est distribué de plusieurs façons : un JAR principal (le binaire Java pur), des installateurs natifs par OS depuis le site officiel, et des paquets passant par des canaux distribués comme Flatpak, Snap ou Winget. C'est cette diversité de canaux qui va jouer un rôle central dans ce qui suit.\r\n\r\nL'incident : ce qui s'est passé\r\n\r\nEntre le 6 mai 2026 à 00 h 01 UTC et le 7 mai 2026 à 17 h 06 UTC, le site officiel  a distribué des installateurs piégés à la place des binaires légitimes. La fenêtre n'a duré qu'environ 48 heures, et seuls deux liens ont été affectés. Mais pendant cette fenêtre, tout utilisateur qui passait par le bon parcours téléchargeait un cheval de Troie au lieu d'un gestionnaire de téléchargements.\r\n\r\nLe scénario reconstitué par l'équipe d'AppWork et les chercheurs en sécurité (BleepingComputer, Thomas Klemenc, équipe Rescana) se déroule en quatre temps.\r\n\r\n1. Compromission du CMS du site. Les attaquants ont exploité une vulnérabilité non corrigée dans le système de gestion de contenu de , qui permettait de modifier les listes de contrôle d'accès et le contenu publié sans authentification. Point crucial : ils n'ont pas eu accès au serveur sous-jacent, ni au système de fichiers, ni à l'infrastructure de build. Juste au contenu web — et ça a suffi.\r\n\r\n2. Réécriture de deux liens. Plutôt que de tenter de modifier les binaires originaux (qui étaient hors de leur portée), les attaquants ont fait beaucoup plus simple : ils ont changé l'URL cible de deux liens publics sur la page de téléchargement. Le lien « Download Alternative Installer » pour Windows et le script shell pour Linux pointaient désormais vers des fichiers malveillants hébergés sur une infrastructure tierce. Le HTML autour, lui, restait identique. Visuellement, rien ne distinguait la page propre de la page piégée.\r\n\r\n3. Charges utiles différenciées par plateforme. Sur Windows, l'installateur piégé agit comme un loader qui déploie un RAT (Remote Access Trojan) écrit en Python, fortement obfusqué, communiquant avec deux serveurs de commande et contrôle ( et ). Le RAT est modulaire : il reçoit du code Python depuis le C2 et l'exécute, ce qui donne aux attaquants une porte ouverte indéfiniment extensible. Sur Linux, le script shell modifié télécharge une archive depuis , déguisée en fichier SVG, dont il extrait deux binaires ELF —  et . Le second est installé en SUID-root dans , le premier est copié dans , et la persistance est assurée par un script déposé dans . Le malware se lance ensuite déguisé en , un nom de processus qui existe légitimement sur la plupart des distributions.\r\n\r\n4. Détection par la communauté. L'alerte n'est pas venue d'un système de surveillance, mais d'un utilisateur Reddit (PrinceOfNightSky) qui a remarqué que Microsoft Defender bloquait son installateur fraîchement téléchargé. La signature numérique indiquait « Zipline LLC » au lieu de « AppWork GmbH ». L'équipe AppWork a confirmé, mis le site hors ligne pour investigation dans les heures qui ont suivi, puis publié un rapport d'incident détaillé. Le site est revenu en ligne dans la nuit du 8 au 9 mai avec des liens vérifiés.\r\n\r\nPourquoi c'est systémique\r\n\r\nÀ première vue, c'est un incident isolé : une faille CMS, une équipe qui patche, le service revient. Vu de loin, ça ressemble à un mauvais quart d'heure. Mais en prenant un peu de recul, le schéma est troublant.\r\n\r\nCPUID, début avril 2026. Le site officiel de l'éditeur de CPU-Z est compromis, des installateurs piégés sont distribués pendant plusieurs jours.\r\n\r\nDAEMON Tools, début mai 2026. Même schéma : compromission du site officiel, substitution d'installateurs, plusieurs versions infectées (12.5.0.2421 à 12.5.0.2434) distribuées avant détection.\r\n\r\nJDownloader, 6–7 mai 2026. Toujours le même schéma.\r\n\r\nTrois compromissions d'éditeurs logiciels en cinq semaines, exactement sur le même schéma : pas d'intrusion dans l'infrastructure de build, pas de modification du code source, pas de vol de certificat de signature de l'éditeur. À chaque fois, le maillon faible est le CMS qui sert la page de téléchargement. Ce qu'on attaque, ce n'est pas le logiciel ; c'est le panneau publicitaire qui pointe vers le logiciel.\r\n\r\nCette mécanique est intéressante parce qu'elle déjoue à peu près toutes les défenses « modernes » de la chaîne d'approvisionnement.\r\n\r\nLa signature de code ne protège pas. Le binaire légitime de JDownloader est toujours signé proprement par AppWork GmbH. Mais le binaire malveillant servi à sa place est signé, lui aussi — par un autre éditeur (Zipline LLC, The Water Team), avec des certificats vraisemblablement volés ou achetés au marché noir. La signature certifie que le fichier vient bien de celui qui l'a signé ; elle ne certifie pas que c'est le bon fichier.\r\n\r\nLe HTTPS ne protège pas. La page de téléchargement est servie en HTTPS valide, depuis le bon domaine, avec le bon certificat. Le navigateur n'a aucune raison de tiquer.\r\n\r\nLes mises à jour in-app sont, elles, protégées. AppWork le souligne : chaque mise à jour livrée par le mécanisme intégré de JDownloader est signée RSA et vérifiée cryptographiquement, indépendamment du site web. Ce canal n'a pas été touché. C'est tout le paradoxe : les utilisateurs qui mettaient à jour JDownloader depuis l'application elle-même n'ont rien risqué ; ceux qui sont allés sur le site officiel pour le télécharger « proprement » sont les seuls exposés.\r\n\r\nLes paquets distribués sont protégés. Flatpak, Snap, Winget, le JAR principal — tout ce qui passe par une chaîne d'approvisionnement où l'intégrité est vérifiée par checksum hors site est resté propre. AppWork le résume sans détour : « Winget/Flatpak/Snap infra is outside of our reach — files downloaded by those are hosted on other infra and secured by sha256 checksums that are unchanged. »\r\n\r\nAutrement dit, plus le canal est court et naïf, plus il est vulnérable. Le téléchargement direct depuis un site web est le canal le plus naïf qui soit : on fait confiance au CMS, point. Tout l'effort de sécurisation de l'écosystème logiciel — signatures, builds reproductibles, SBOMs, attestations de provenance — porte sur la chaîne de production et la chaîne de distribution centralisée. Le maillon « page HTML qui dit clique ici », lui, est resté tel qu'il était en 2005.\r\n\r\nComment vérifier si on est touché\r\n\r\nLa fenêtre est étroite, donc le filtrage est simple. Trois questions, dans l'ordre :\r\n\r\n1. L'installateur a-t-il été récupéré entre le 6 mai 2026 (00 h 01 UTC) et le 7 mai 2026 (17 h 06 UTC) ?\r\n2. S'agit-il du lien « Download Alternative Installer » Windows ou du script shell Linux depuis  ?\r\n3. Le fichier a-t-il été exécuté ?\r\n\r\nTrois oui → traiter la machine comme compromise. N'importe quel non dans la liste → aucun risque lié à cet incident. Une installation pré-existante mise à jour automatiquement, un paquet Flatpak/Snap/Winget, le JAR, la version macOS : rien à craindre.\r\n\r\nSous Windows\r\n\r\nLe contrôle de référence, c'est la signature numérique. Clic droit sur l'installateur → Propriétés → onglet Signatures numériques. La valeur attendue est . Toute autre signature (notamment Zipline LLC ou The Water Team), ou l'absence de signature, désigne un fichier malveillant.\r\n\r\nEn PowerShell :\r\n\r\n\r\n\r\nSi  n'est pas  ou si le certificat ne contient pas , ne pas exécuter.\r\n\r\nSous Linux\r\n\r\nTrois artefacts sont à chercher en post-exécution :\r\n\r\n\r\n\r\nL'apparition de l'un de ces trois éléments suffit à confirmer l'infection. Pour aller plus loin, un coup d'œil au trafic sortant vers les trois domaines C2 (, , ) dans les logs DNS ou via  permet de confirmer l'activité du malware.\r\n\r\nSi le script installateur traîne encore quelque part, sa signature est sans ambiguïté : taille de 7 934 496 octets, SHA-256 commençant par .\r\n\r\nEn cas de compromission confirmée\r\n\r\nLa position officielle d'AppWork est sans nuance : réinstallation complète du système. Un RAT modulaire avec persistance SUID-root et exécution arbitraire de code Python depuis un C2 n'est pas quelque chose qu'on retire avec un antivirus. Il faut considérer que tout secret qui a transité sur la machine est compromis — mots de passe saisis au clavier, clés SSH, jetons API, cookies de session, configurations cloud — et les faire tous tourner après réinstallation, depuis une autre machine saine.\r\n\r\nCe que ça change pour qui s'auto-héberge\r\n\r\nL'incident JDownloader est un exemple éclairant pour qui exploite ses propres services exposés sur Internet — un Forgejo, un reverse proxy, un site personnel. La leçon n'est pas vraiment côté utilisateur (la procédure de détection plus haut suffit), elle est côté opérateur.\r\n\r\nLe CMS de JDownloader n'a probablement pas été ciblé pour ses qualités intrinsèques. C'est un dommage collatéral d'un schéma plus large : tout site qui distribue un binaire avec un nombre significatif d'utilisateurs devient une cible rentable, et le CMS public est souvent la pièce la moins surveillée du dispositif. On sécurise le serveur Git, le pipeline de build, la signature des paquets — et on laisse tourner un CMS qui n'a pas été patché depuis huit mois parce qu'il « ne sert qu'à afficher la page d'accueil ».\r\n\r\nQuelques principes opérationnels qui en découlent.\r\n\r\nSéparer le canal de publication du canal de vérification. AppWork a eu raison sur un point essentiel : leurs mises à jour in-app passent par une infrastructure indépendante du site web, avec signature RSA vérifiée côté client. Quand on auto-héberge, ça se traduit par : ne jamais utiliser le même serveur pour distribuer un binaire et publier son empreinte. Le checksum doit vivre ailleurs — dans un dépôt Git séparé, sur un domaine différent, idéalement sur une infrastructure qu'on n'administre pas soi-même.\r\n\r\nSurveiller la dérive du contenu publié. Une simple vérification quotidienne du hash des pages publiques (un cron qui calcule le SHA-256 des URL critiques et alerte en cas de changement non planifié) aurait détecté la compromission de JDownloader en moins d'une heure. C'est le genre de surveillance qu'aucune solution commerciale ne propose nativement, et qui s'écrit en quinze lignes de bash.\r\n\r\nPatcher le CMS avec la même rigueur que l'OS. L'automatisation des mises à jour applicatives reste sous-investie, surtout pour les outils « périphériques » (CMS, wiki, formulaire de contact). Une mise à jour automatique de niveau correctif n'est pas plus risquée qu'une mise à jour du noyau, et elle évite ce type de scénario.\r\n\r\nAuditer les ACL régulièrement. La faille exploitée ici permettait de modifier les ACL sans authentification. C'est l'équivalent CMS d'un répertoire  dans un coin du système. Un audit périodique des permissions sur les pages publiques fait partie du minimum syndical pour un service exposé.\r\n\r\nEn résumé\r\n\r\nJDownloader n'a pas été cassé. Son code source est intact, son infrastructure de build est intacte, ses paquets officiels distribués via Flatpak ou Snap sont intacts, ses mises à jour internes sont intactes. Ce qui a été cassé, c'est le panneau qui dit où aller chercher le binaire.\r\n\r\nC'est une mécanique élégante du point de vue de l'attaquant, et inquiétante du point de vue de l'opérateur. Elle illustre quelque chose que l'incident NPM avait déjà mis en lumière dans un autre registre : la chaîne d'approvisionnement logicielle n'est pas une chaîne, c'est un réseau, et les points faibles ne sont jamais là où on les attend. On peut investir massivement dans la sécurité du code, du build et de la signature ; si la page web qui sert le lien reste un Wordpress non patché derrière un nom de domaine prestigieux, tout cet investissement passe à côté.\r\n\r\nLe rôle de l'opérateur en 2026, ce n'est plus de protéger le code. C'est de protéger chaque maillon qui sert à dire au monde où trouver le code — et de partir du principe que ce maillon-là sera le prochain à céder.\r\n\r\nLiens & sources\r\n\r\nJDownloader site hacked to replace installers with Python RAT malware | BleepingComputer\r\n\r\nRapport d'incident officiel | jdownloader.org\r\n\r\nJDownloader Website Supply Chain Attack | Rescana\r\n\r\nLe site officiel de JDownloader compromis | IT-Connect"},{"uuid":"6f2639a5-58ed-4102-a6a2-0acbecf01de5","slug":"esp8266-commandes-at","title":"ESP8266 : prise en main des commandes AT","category":"Électronique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-12-13 08:51","created_at":"2020-12-13 08:51:55","updated_at":"2026-05-13 18:23:54","tags":[],"plain":"Présentation\r\n\r\nL'ESP8266 est un microcontrôleur Wi-Fi développé par Espressif. Lorsqu'il sort d'usine, ou lorsqu'il est flashé avec le firmware AT officiel d'Espressif, il accepte un jeu d'instructions textuelles appelées commandes AT (ou commandes Hayes, du nom du fabricant de modems qui les a popularisées dans les années 1980).\r\n\r\nLe module ESP-01, le plus répandu pour découvrir l'ESP8266, est généralement livré avec ce firmware AT préchargé. Il est donc utilisable immédiatement, sans programmation, simplement en lui envoyant des commandes texte sur sa liaison série.\r\nPrérequis matériel : un ESP-01 connecté à un PC via un adaptateur USB-série, et un terminal série (moniteur série de l'IDE Arduino, , , PuTTY…) configuré à 115200 bauds avec fin de ligne CR+LF.\r\nNote sur les versions : la syntaxe et les codes retour des commandes AT varient selon la version du firmware. Les exemples ci-dessous correspondent à un firmware AT v1.x typique sur ESP-01. Pour les firmwares plus récents (AT v2.x sur ESP32), certaines commandes prennent des paramètres supplémentaires.\r\n\r\nTravaux pratiques\r\n\r\nL'enchaînement ci-dessous permet de mettre l'ESP-01 sur un réseau Wi-Fi, puis de le transformer en serveur HTTP minimaliste. Chaque commande est envoyée depuis le terminal série ; les lignes préfixées par  représentent la réponse du module.\r\n\r\n1. Vérifier le mode Wi-Fi courant\r\n\r\n\r\n\r\nLe module répond avec un chiffre indiquant son mode courant (voir glossaire plus bas).\r\n\r\n2. Passer en mode dual (client + point d'accès)\r\n\r\n\r\n\r\nLe mode 3 active simultanément le mode station (le module se connecte à un Wi-Fi existant) et le mode AP (le module expose son propre point d'accès). C'est le mode le plus polyvalent pour expérimenter.\r\n\r\n3. Se connecter à un réseau Wi-Fi\r\n\r\n\r\n\r\nTrois événements sont remontés successivement :\r\nWIFI CONNECTED : association réussie au point d'accès ;\r\nWIFI GOT IP : adresse IP obtenue via DHCP ;\r\nOK : la commande est terminée avec succès.\r\n\r\n4. Lister les adresses IP et MAC du module\r\n\r\n\r\n\r\nEn mode dual, le module possède deux interfaces réseau :\r\nAP (point d'accès) : adresse fixe  par défaut, sur laquelle se connectent les clients du Wi-Fi exposé par l'ESP ;\r\nSTA (station/client) : adresse attribuée par le routeur du réseau auquel l'ESP s'est connecté.\r\n\r\n5. Activer les connexions multiples\r\n\r\n\r\n\r\nPar défaut, l'ESP n'accepte qu'une seule connexion TCP simultanée. Le mode multi-connexion est obligatoire pour faire fonctionner le module en serveur (étape suivante).\r\n\r\n6. Démarrer un serveur TCP sur le port 80\r\n\r\n\r\n\r\nLe module écoute désormais sur le port 80 de son adresse STA. Un simple navigateur pointé sur  (l'adresse retournée par ) déclenche une connexion HTTP.\r\n\r\n7. Observer une requête entrante\r\n\r\nLorsqu'un client se connecte, l'ESP recopie sur la liaison série l'événement de connexion, puis la requête HTTP brute, et enfin la fermeture de la connexion :\r\n\r\n\r\n\r\nLecture :\r\n: un client vient de s'associer ;  est l'identifiant de connexion (link ID), utile en mode multi-connexion ;\r\n: l'ESP a reçu 341 octets sur la connexion  ; ces octets suivent immédiatement (ici, l'en-tête HTTP envoyé par Firefox) ;\r\n: le client a fermé la connexion (ou un timeout est intervenu).\r\n\r\nÀ ce stade, l'ESP ne répond rien au client : il faut explicitement envoyer une réponse avec  (voir glossaire). Le navigateur affichera donc une page vide ou un message d'erreur.\r\n\r\nPour aller plus loin : répondre au client\r\n\r\nPour renvoyer une page HTML minimale au client  :\r\n\r\n\r\n\r\nLe module affiche  et attend exactement le nombre d'octets annoncé, puis envoie le tout sur la connexion . Il faut ensuite fermer la connexion avec :\r\n--\r\n\r\nGlossaire des commandes AT\r\n\r\nConventions\r\n\r\nTrois formes coexistent pour la plupart des commandes :\r\nForme | Syntaxe | Rôle |\r\n---|---|---|\r\nInterrogation |  | Lire la valeur courante |\r\nTest |  | Lister les valeurs autorisées |\r\nAffectation |  | Modifier la valeur |\r\n\r\nLes chaînes de caractères (SSID, mot de passe…) sont toujours encadrées par des guillemets droits.\r\n\r\nCommandes Wi-Fi\r\n\r\n— Mode de fonctionnement Wi-Fi\r\n\r\n\r\n\r\nValeurs de  :\r\nValeur | Mode | Description |\r\n---|---|---|\r\n1 | STA | Station/client : le module se connecte à un Wi-Fi existant |\r\n2 | AP | Point d'accès : le module expose son propre Wi-Fi |\r\n3 | STA+AP | Mode dual : les deux à la fois |\r\n\r\nExemple :\r\n\r\n\r\n\r\n— Lister les points d'accès visibles\r\n\r\n\r\n\r\nRetourne une ligne par réseau détecté, sous la forme :\r\nChamp | Signification |\r\n---|---|\r\n| Chiffrement :  ouvert,  WEP,  WPA-PSK,  WPA2-PSK,  WPA/WPA2-PSK |\r\n| Nom du réseau |\r\n| Puissance du signal en dBm (plus la valeur est proche de 0, plus le signal est fort) |\r\n| Adresse MAC du point d'accès (BSSID) |\r\n| Canal Wi-Fi (1 à 13 en Europe sur 2,4 GHz) |\r\n\r\nExemple :\r\n\r\n\r\n\r\nPrérequis :  doit inclure le mode station (1 ou 3).\r\n\r\n— Se connecter à un point d'accès\r\n\r\n\r\n\r\nCodes d'erreur retournés en cas d'échec via  :\r\nCode | Signification |\r\n---|---|\r\n1 | Délai de connexion dépassé |\r\n2 | Mot de passe incorrect |\r\n3 | SSID introuvable |\r\n4 | Échec de connexion (autre) |\r\n\r\nExemple d'échec :\r\n\r\n\r\n\r\nExemple de réussite :\r\n\r\n\r\n\r\n— Se déconnecter du point d'accès\r\n\r\n\r\n\r\nÀ ne pas confondre avec une commande de sauvegarde :  signifie Quit AP, c'est-à-dire déconnexion. Les paramètres de connexion (SSID, mot de passe) sont en revanche automatiquement mémorisés en flash par les commandes  et  dans les versions classiques du firmware AT — le module se reconnectera donc au démarrage suivant.\r\n\r\n— Adresses IP et MAC locales\r\n\r\n\r\n\r\nRenvoie les adresses IP et MAC du module pour chaque interface active :\r\n/  : interface point d'accès (toujours  par défaut) ;\r\n/  : interface station (attribuée par le DHCP du réseau rejoint).\r\n\r\nEn mode , seule la partie STA est retournée ; en mode 2, seule la partie AP.\r\n\r\nCommandes TCP/IP\r\n\r\n— Activer les connexions multiples\r\n: connexion unique (mode par défaut) ;\r\n: jusqu'à 5 connexions simultanées, chacune identifiée par un link ID de 0 à 4.\r\n\r\nPrérequis pour passer en mode 1 : aucune connexion ne doit être active, et le module ne doit pas déjà être en mode serveur.\r\n\r\n— Démarrer un serveur TCP\r\n:  pour démarrer,  pour arrêter ;\r\n: port d'écoute, optionnel (par défaut 333).\r\n\r\nPrérequis :  doit avoir été exécuté au préalable.\r\n\r\nAprès un arrêt (), un redémarrage du module est nécessaire () pour libérer complètement le port.\r\n\r\n— Envoyer des données sur une connexion\r\n\r\n\r\n\r\nLe module affiche un prompt  et attend exactement  octets, puis transmet le bloc au client. Indispensable pour répondre à une requête HTTP entrante.\r\n\r\n— Fermer une connexion\r\n\r\n\r\n\r\nCommandes générales utiles\r\nCommande | Rôle |\r\n---|---|\r\n| Test de présence du module (doit répondre ) |\r\n| Redémarrer le module |\r\n| Afficher la version du firmware AT |\r\n| Changer le débit série (non persistant) |\r\n/  | Désactiver / activer l'écho des commandes |\r\n--\r\n\r\nRécapitulatif : déclarer un serveur HTTP minimal\r\n\r\nSéquence complète depuis un ESP-01 vierge :\r\n\r\n\r\n\r\nÀ partir de cet instant, toute connexion entrante sur  est remontée sur le port série sous forme d'événements , à charge pour le programme côté PC (ou pour un firmware personnalisé) de les analyser et de répondre via .\r\n\r\nLimites du firmware AT\r\n\r\nLe firmware AT est pratique pour découvrir et tester l'ESP8266, mais il montre vite ses limites :\r\nlatence importante (chaque commande passe par le port série) ;\r\npas de TLS correct dans les anciennes versions ;\r\ncomplexité pour gérer plusieurs clients simultanés ;\r\ndépendance à un hôte qui pilote l'ESP en permanence.\r\n\r\nPour des projets plus aboutis, il est préférable de flasher l'ESP avec un firmware personnalisé (Arduino, ESP-IDF, MicroPython, Tasmota, ESPHome…) qui exécute directement la logique applicative sur le microcontrôleur, sans intermédiaire série.\r\n```"},{"uuid":"f8184dc2-72f0-408d-ac3c-47d117e0d04c","slug":"actualite-burger-tech-sinformer-sur-le-high-tech","title":"S'informer sur la technologie","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2020-04-17 18:06:16","created_at":"2020-04-17 18:06:16","updated_at":"2020-04-17 18:06:16","tags":[],"plain":"14 avril 2019\nLe Wi-Fi 6 met le cap sur la bande des 6 GHz\nTechnologie : La Wi-Fi Alliance a annoncé l'adoption d'une nouvelle terminologie, Wi-Fi 6E, pour les appareils pouvant fonctionner sur la bande des 6 GHz. Une bande qui promet un débit encore supérieur à ceux promis par le Wi-Fi 6.\nPierre Benhamou Par Pierre Benhamou | Lundi 06 Janvier 2020 Le Wi-Fi 6 met le cap sur la bande des 6 GHz Alors que le Wi-Fi 6 montre petit à petit le bout de son nez, la Wi-Fi Alliance, le consortium en charge de cette technologie, a annoncé en fin de semaine dernière avoir adopté une nouvelle terminologie pour les les appareils Wi-Fi 6 capables de fonctionner sur la bande des 6 GHz. Ces derniers porteront désormais le nom de Wi-Fi 6E, alors que les appareils compatibles avec la nouvelle norme Wi-Fi 6 mais fonctionnant uniquement sur les bandes des 2,4 GHz et 5 GHz continueront à se voir classifiés comme Wi-Fi 6. « La Wi-Fi 6E apporte un nom commun dans l'industrie pour les utilisateurs de Wi-Fi, afin d'identifier les appareils qui offriront les caractéristiques et les capacités de la Wi-Fi 6 - y compris une performance plus élevée, une latence plus faible et des débits de données plus rapides - étendues à la bande des 6 GHz », a fait savoir le consortium avant de vanter les multiples mérites de ces nouveaux appareils capables d'avoir recours à cette bande des 6 GHz, « une partie importante du spectre sans licence qui pourrait bientôt être mise à disposition par les régulateurs du monde entier ». Selon la Wi-Fi Alliance, la bande des 6 GHz a de multiples mérites. Elle dispose en effet d'assez de spectre contigu pour fournir 7 canaux de 160 MHz et 14 canaux de 80 MHz, a fait savoir l'organisation, qui relève qu'un tel spectre supplémentaire est nécessaire pour gérer les applications à large bande passante telles que la diffusion vidéo haute définition et la réalité virtuelle. En outre, cette bande « est bien adaptée pour faciliter la croissance continue du Wi-Fi dans les zones mal desservies en raison de sa proximité avec la fréquence de 5 GHz où le Wi-Fi fonctionne déjà, de la plus grande disponibilité de canaux de plus grande taille et de l'accessibilité à un spectre clair avec moins d'interférence des appareils Wi-Fi 4 ou Wi-Fi 5 existants », précise-t-elle. publicité\nDe quoi renforcer l'implantation du Wi-Fi 6 ? Les appareils avec la marque Wi-Fi 6E devraient apparaître une fois que les approbations réglementaires dans le monde entier commenceront à se produire. « Alors que l'application et la demande globale de Wi-Fi continuent à augmenter, l'accès au spectre sans licence du 6 GHz permettra au Wi-Fi de continuer à apporter les vastes innovations et les avantages socio-économiques qu'elle apporte aujourd'hui au marché, tout en contribuant à garantir que le Wi-Fi puisse répondre aux nouvelles promesses de l'ère de la 5G et au-delà », a indiqué Chuck Lukaszewski, le vice-président des normes et de la stratégie sans fil. « La bande des 6 GHz aidera à répondre au besoin croissant de capacité du spectre Wi-Fi pour que les utilisateurs de Wi-Fi continuent à bénéficier de la même excellente expérience d'utilisation avec leurs appareils », a de son côté appuyé le président de la Wi-Fi Alliance, Edgar Figueroa. Le Wi-Fi 6E devrait encore renforcer l'essor du Wi-Fi 6 qui fait, depuis septembre dernier, l'objet d'un programme de certification permettant à des entreprises comme Apple et Samsung de labelliser officiellement leurs appareils comme étant capables de prendre en charge le protocole IEEE 802.11ax, de plus grande capacité. Pour rappel, ce protocole, qui fonctionne dans les bandes 2,4 GHz et 5 GHz - à l'instar des générations précédentes de la technologie sans fil IEEE 802.11 - promet plus de capacité et de performances lorsque de nombreux périphériques se connectent au même routeur. S'il reprend les fréquences déjà adoptées par ses aînés, le Wi-Fi 6 - ou 802.11ax - promet en effet des débits entre 20 et 40 % supérieurs à la version précédente, le Wi-Fi 5, aussi connu sous l'appellation technique de 802.11ac. Comment ? Grâce à un meilleur encodage des données qui permet de faire transiter plus de datas sur une même fréquence et à des processus d'encodage et de décodage améliorés du côté des processeurs compatibles, à l'image du mode de modulation d'amplitude en quadrature 1024 (1024-QAM). Mais si l'utilisation de la bande des 6 GHz devrait encore amplifier la puissance du Wi-Fi 6, son effet sur la généralisation de cette nouvelle technologie reste encore à prouver dans les faits. Source : https:www.zdnet.fr/actualites/le-wi-fi-6-met-le-cap-sur-la-bande-des-6-ghz-39896751.htm\nLe Wifi de Google aux abonnés absents\nSi votre travail consiste à protéger l'infrastructure informatique, il pourrait bien valoir la peine de lire le nouveau livre gratuit de 500 pages de Google qui détaille les nombreuses défaillances affectant les systèmes internes de Google et des produits comme YouTube. Il est important de noter que ce nouveau livre révèle également comment ses équipes d'ingénierie et de sécurité des sites coopèrent pour protéger les systèmes clés de Google, d'Android à Chrome, en passant par Gmail, Search et Google Cloud. Une vue maison sur le SRE (Site Reliability Engineering) Peu d'entreprises dans le monde opèrent à l'échelle de Google, mais il y a néanmoins des leçons à tirer de ce document, qui est publié alors que la pandémie de Coronavirus COVID-19 rend plus important que jamais la fiabilité des systèmes en ligne. Le livre présente les points de vue d'équipes qui pratiquent ce qu'on appelle l'ingénierie de la fiabilité des sites (SRE - Site Reliability Engineering), l'approche de Google pour coordonner les ingénieurs en logiciels qui développent ses produits et ses systèmes, et les équipes opérationnelles qui assurent le fonctionnement du produit. Google, qui utilise les principes de l'ESR depuis près de deux décennies, le définit comme \"ce que vous obtenez lorsque vous traitez les opérations comme s'il s'agissait d'un problème de logiciel\". Le lien sécurité entre les développeurs et les équipes opérationnelles Le texte, intitulé 'Building Secure and Reliable Systems', se concentre sur la façon dont Google apporte une approche SRE à la sécurité, et le rôle de la sécurité dans le développement et les opérations de produits logiciels. Les précédents ouvrages de Google sur le SRE couvraient les meilleures pratiques en la matière, mais ne traitaient pas des liens entre fiabilité et sécurité. \"Pour de bonnes raisons, les équipes de sécurité des entreprises ont largement mis l'accent sur la confidentialité. Cependant, les entreprises reconnaissent souvent que l'intégrité et la disponibilité des données sont tout aussi importantes, et abordent ces domaines avec des équipes différentes\", explique Royal Hansen, l'un des premiers responsables SRE pour Gmail et l'actuel vice-président de l'ingénierie de la sécurité de Google. \"La fonction SRE est une approche de la fiabilité qui est la meilleure de sa catégorie. Toutefois, elle joue également un rôle dans la détection en temps réel des problèmes techniques et la réponse à ceux-ci - y compris les attaques liées à la sécurité sur les accès ou les données sensibles. En fin de compte, si les équipes d'ingénieurs sont souvent séparées sur le plan organisationnel en fonction de compétences spécialisées, elles ont un objectif commun : assurer la qualité et la sécurité du système ou de l'application\". Un système peut-il être fiable s'il n'est pas fondamentalement sûr ? Ou peut-il être sûr s'il n'est pas fiable ? Le livre s'ouvre sur les questions suivantes : un système peut-il être considéré comme vraiment fiable s'il n'est pas fondamentalement sûr ? Ou peut-il être considéré comme sûr s'il n'est pas fiable ? La première histoire mentionnée par Google est celle d'un échec en cascade en 2012, après que son service de transport ait annoncé que le mot de passe Wi-Fi de ses bus reliant ses campus de la baie de San Francisco avait changé. Le flot d'employés essayant de changer leur mot de passe a surchargé son gestionnaire de mots de passe et l'a mis hors ligne, ainsi que ses trois services de secours. Google avait besoin d'une carte à puce pour redémarrer le système et en disposait dans plusieurs bureaux à travers le monde, mais ne pouvait pas y accéder aux États-Unis. L'entreprise a donc fait appel à des ingénieurs en Australie pour en trouver une là-bas. Il s'est avéré qu'elle était enfermée dans un coffre-fort avec un code que l'ingénieur avait oublié. Google et le mystère de la carte à puce Et où le code avait-il été sauvegardé ? Bien sûr, dans le gestionnaire de mots de passe qui était désormais inaccessible. Mais il y a eu encore plus de problèmes lorsque les ingénieurs ont tenté de redémarrer le gestionnaire de mots de passe. \"Ce jour-là, en septembre, l'équipe des transports de l'entreprise a envoyé un courriel à des milliers d'employés pour leur annoncer que le mot de passe du WiFi avait changé. Le pic de trafic qui en a résulté était bien plus important que ce que le système de gestion des mots de passe - qui avait été développé des années auparavant pour un petit groupe d'administrateurs système - pouvait gérer\". \"La charge a fait que la réplique primaire du gestionnaire de mots de passe ne répondait plus, de sorte que l'équilibreur de charge a détourné le trafic vers la réplique secondaire, qui a rapidement échoué de la même manière. À ce stade, le système a bipé l'ingénieur de garde. L'ingénieur n'avait aucune expérience en matière de réponse aux pannes du service : le gestionnaire de mots de passe était supporté au mieux de ses capacités et n'avait jamais subi de panne au cours de ses cinq années d'existence. L'ingénieur a tenté de redémarrer le service, mais ne savait pas qu'un redémarrage nécessitait une carte à puce\". De l'avantage d'insérer correctement une carte dans un lecteur \"Ces cartes à puce étaient stockées dans plusieurs coffres-forts dans différents bureaux de Google à travers le monde, mais pas à New York, où se trouvait l'ingénieur de garde. Lorsque le service n'a pas pu redémarrer, l'ingénieur a contacté un collègue en Australie pour récupérer une carte à puce. À son grand désarroi, l'ingénieur australien n'a pas pu ouvrir le coffre-fort car la combinaison était stockée dans le gestionnaire de mots de passe désormais hors ligne. Heureusement, un autre collègue en Californie avait mémorisé la combinaison dans le coffre-fort sur place et a pu récupérer une carte à puce\". \"Cependant, même après que l'ingénieur californien ait inséré la carte dans un lecteur, le service n'a pas redémarré et affichait l'erreur incompréhensible suivante : \"Le mot de passe ne peut charger aucune des cartes protégeant cette clé\". Les ingénieurs australiens ont alors décidé qu'une approche de force brute était justifiée pour résoudre leur problème de sécurité et ont utilisé une perceuse électrique pour cela. Une heure plus tard, le coffre-fort était ouvert - mais les cartes récupérées dedans ont déclenché le même message d'erreur. \"Il a fallu une heure supplémentaire pour que l'équipe se rende compte que la carte n'avait pas été insérée correctement. Lorsque les ingénieurs ont retourné la carte, le service a redémarré et la panne a pris fin\". Source : \"ZDNet.com\" Source : https:www.zdnet.fr/actualites/google-comment-la-reinitialisation-de-mot-de-passe-wi-fi-a-paralyse-l-un-de-nos-systemes-39902079.htm\n06 avril 2019\nAttestation de déplacement sur mobile\nLe générateur de QR code est disponible depuis le 06 avril 2020. Il permet de générer un QR code qui devra être présenté en cas de contrôle. L’impression ou la version manuscrite de l’attestation dérogatoire est encore possible. Une seule adresse : https:media.interieur.gouv.fr/deplacement-covid-19/ Une fois sur la page, la personne remplit son formulaire de la même façon que la version papier (nom, prénom, adresse, date de naissance, lieu de naissance, date et heure de sortie, raison). Toutes les informations doivent être renseignées. Une fois cette démarche réalisée, un PDF sera généré. Il inclus un QR code qui devra être présenté aux policiers ou aux gendarmes en cas de contrôle. Les gendarmes et la police seront équipés de l’application Android sur des terminaux sécurisés. L'application nommée CovidReader, a été développée par le STI2S (service des technologies et des SI de la sécurité intérieure). A voir si celle-ci pourra être utilisée pour enregistrer les sorties et réaliser des statistiques. Exemple de sortie du QR code :\n<pre>\nCree le: 06/04/2020 a 20h38; Nom: Dupont; Prenom: Jean; Naissance: 01/01/1970 a Lyon; Adresse: 999 avenue de france 75001 Paris; Sortie: 06/04/2020 a 20h38; Motifs: \n</pre> Source : https:www.lemondeinformatique.fr/actualites/lire-attestation-de-deplacement-sur-mobile-le-generateur-de-qr-code-disponible-78675.html\nCovid-19 : Google libère les données de géolocalisation dans 131 pays\nQuelques jours après Orange, c'est au tour de Google de lâcher dans la nature les données de géolocalisation - anonymisées - des centaines de millions d'utilisateurs de son service Maps. « À partir d'aujourd'hui, nous publions une version anticipée de nos rapports sur la mobilité communautaire COVID-19 pour donner un aperçu de ce qui a changé en réponse au travail à domicile, au logement sur place et à d'autres politiques visant à aplanir la courbe de cette pandémie, a expliqué la société dans un billet de blog. Au total, une analyse de l'évolution des déplacements a été effectuée pour 131 pays dont la France, accessible depuis ce site. Les données pour la France sont assez représentatives des conséquences des mesures de confinement prises par le gouvernement pour faire face à la pandémie Covid-19 qui affecté 59 105 personnes et provoqué le décès de 4 503 d'entre elles d'après les données de Santé Publique France au 2 avril 2020. Parmi les principaux enseignements du rapport concernant l'Hexagone, Google fait état d'une chute de 88% des déplacements pour se rendre dans des magasins, restaurants, cafés ou encore des parcs de loisirs, musés, bibliothèques ou encore cinémas.  Covid-19 Evolution des déplacements en France selon les données de géolocalisation anonymisées émanant de Google Maps. (crédit : Google) Concernant les commerces alimentaires et les pharmacies, la baisse est moindre (-72%) qui s'explique par la mise en place de dérogations pour permettre aux Français de se rendre dans des commerces pour répondre à des besoins de première nécessité. Les trajets vers les parcs et places publiques sont aussi en chute libre (-82%), tout comme les grands lieux de transits et de transports (stations, gares...) affichant un recul abyssal de 87%. En revanche, les déplacements vers les lieux de travail sont, certes, également touchés (-56%) preuve que le télétravail - ou la contrainte liée au chômage partiel et donc le fait de rester confiné à la maison - fonctionnent à plein mais aussi qu'une bonne partie de la population poursuit ses déplacements à titre professionnel vers leurs lieux de travail, bénéficiant également d'une possible dérogation. A noter que l'étude de Google s'intéresse aux évolutions des déplacements par régions. L'occasion de remarquer par exemple que l'Ile-de-France tient la palme en matière de recul des déplacements vers les lieux de travail (-63%), pouvant s'expliquer pour une prédisposition « naturelle » des salariés pour le télétravail. Source : https:www.lemondeinformatique.fr/actualites/lire-covid-19-google-libere-les-donnees-de-geolocalisation-dans-131-pays-78674.html\n3 000 machines avec SQL Server infectées par jour depuis 2018\nChaque jour depuis deux ans entre 2 à 3 000 serveurs dédiés à Microsoft SQL Server sont contaminés dans le monde. D'après une dernière étude de Guardicore, les principaux pays concernés sont la Chine, l'Inde, les Etats-Unis, la Corée du Sud et la Turquie. Les entreprises ayant des activités à l'international dans ces pays ont donc intérêt à redoubler de vigilance, leurs systèmes étant susceptibles d'être victimes d'attaques aussi variées que redoutables : DDoS, backdoors, exécution de logiciels malveillants de contrôle d'accès à distant, cryptomineurs en font parti. « Les victimes appartiennent à divers secteurs industriels, notamment les soins de santé, l'aviation, l'informatique et les télécommunications et l'enseignement supérieur », indique Guardicore Labs. Le premier incident de ce type a avoir été identifé par Guardicore Labs remonte à mai 2018 via son réseau de capteurs mondial (Global Sensors Network) servant d'honeypot. Depuis, un pic d'attaques ciblant les serveurs MS SQL Server a été enregistré en décembre dernier. En analysant de près les fichiers de logs, les chercheurs en sécurité du fournisseur ont été en mesure de déterminer que 60% des machines touchées restent infectées pour une période courte de temps, mais que près de 20% restent vulnérables pendant une semaine voire plus laissant le temps aux cyberattaquants d'agir. « Nous avons remarqué que 10% des victimes ont été re-infectés par un malware », indique Guardicore Labs. « Ce modèle de réinfection a déjà été observé dans l'analyse de la campagne Smominru, et suggère que la suppression des logiciels malveillants se fait souvent de manière partielle, sans enquête approfondie sur la cause profonde de l'infection ».\nEliminer la concurrence pour régner en maitre sur les systèmes infectés Au global, ces attaques baptisées « Vollgar » par Guardicore Labs émanent de plus de 120 adresses IP. La brèche initiale exploitée commence avec des attaques par force brute pouvant aboutir à des changements de configuration dans les bases de données permettant de préparer le terrain à de futures exécutions de commandes malveillantes. Par la suite, les pirates effectuent plusieurs étapes pour rendre le système le plus ouvert possible, en commençant par la validation de certaines classes COM (WbemScripting.SWbemLocator, Microsoft.Jet.OLEDB.4.0 et Windows Script Host Object Model. « Ces classes prennent en charge à la fois les scripts WMI et l'exécution de commandes via MS-SQL, qui seront ensuite utilisées pour télécharger le binaire malveillant initial », indique le fournisseur. « L'attaquant Vollgar s'assure également que les fichiers stratégiques tels que cmd.exe et ftp.exe disposent des autorisations d'exécution ». De quoi permettre l'installation de backdoors et des attaques par escalade de privilèges utilisateurs. Bien souvent les pirates essaient par tous les moyens d'éliminer la concurrence. Sans surprise, c'est également le cas ici encore avec des efforts réalisés en semant leur trace. Cela passe par l'effacement de la clé HKLM\\SOFTWARE\\Microsoft\\Command Processor\\Autorun utilisée pour des attaques persistantes ou encore de valeurs depuis Image File Execution Options. « En supprimant ces  valeurs, Vollgar garantit qu'aucun autre malware n'est attaché aux processus légitimes, tels que cmd.exe, ftp.exe, net.exe et les hôtes de script Windows tels que wscript.exe et cscript.exe ». Des charges malveillantes peuvent ensuite être activées. « La charge utile initiale, nommée SQLAGENTIDC.exe ou SQLAGENTVDC.exe, commence par exécuter taskkill sur une longue liste de processus, dans le but d'éliminer les concurrents et de gagner plus de ressources informatiques. Ces processus incluent Rnaphin.exe, xmr.exe et winxmr.exe, pour n'en nommer que quelques-uns. Ensuite, la charge utile se copie dans le dossier AppData de l'utilisateur et exécute la copie. Le nouveau processus vérifie la connectivité Internet, puis interroge Baidu Maps pour obtenir l'IP et la géolocalisation de la victime qu'il envoie ensuite au C&C. Ensuite, quelques charges utiles supplémentaires sont téléchargées sur la machine infectée - plusieurs modules RAT et un cryptominer basé sur XMRig ».\nDeux serveurs C&C opérés depuis la Chine Deux serveurs de commande et de contrôle (C&C) ont été identifiés par Guardicore Labs en lien avec les attaques Vollgar, dotés de capacités en téléchargement de fichiers, installation de services Windows, enregistreurs de frappes, captures d'écran, exécution d'un terminal shell dynamique, activation des caméras et microphones, initialisation d'attaques DDoS... Pour se prémunir de ce type d'attaques, le fournisseur propose un script Powershell permettant de détecter ce vecteur d'attaque. Contrôler les communications réseau avec des serveurs distants et activer des blocages en conséquence est bien évidemment recommandé, en se basant par exemple sur un service de réputation adossé à son firewall. Source : https:www.lemondeinformatique.fr/actualites/lire-3-000-machines-avec-sql-server-infectees-par-jour-depuis-2018-78660.html\nLe ransomware visant Marseille perturbe le décompte des décès Covid-19\nLes dommages des ransomwares ont parfois des conséquences inattendues et celui qui a touché la ville de Marseille il y a quelques semaines refait ainsi parler de lui. Alors que la ville se remet petit à petit des impacts sur son système d'information de cette cyberattaque - à l'image d'Antibes et également de la Métropole Provence Alpes Côte d'Azur - l'INSEE a publié vendredi dernier les données de mortalité liées au coronavirus. Quel rapport ? En raison du ransomware, les services administratifs de la ville de Marseille n'ont pas pu faire remonter les informations requises à des fins de traitement statistiques demandées par l'institut. « La rapidité de remontée de ces informations varie également selon les départements et pourrait être perturbée par les mesures de confinement, de même que le choix des modalités de transmission (dématérialisé ou courrier postal). Les dernières données quotidiennes sont donc à prendre avec précaution ; elles seront révisées »,  a précisé l'INSEE dans une note méthodologique. « Depuis le 13 mars, la mairie de Marseille n’a pu transmettre aucun nouveau décès du fait d’un problème technique. C’est pourquoi les données des Bouches-du-Rhône sont pour le moment arrêtées au 11 mars ».\nUn retour temporaire au registre papier Contactée par notre confrère LCI, l'INSEE a apporté la précision suivante : « La comptabilisation des décès est, en effet, suspendue en raison d’un problème informatique à la mairie de Marseille [...] La seule commune de Marseille enregistrant la moitié des décès pour toutes les Bouches-du-Rhône, publier des résultats de ce département sans ses chiffres serait peu représentatif ». Et la mairie de Marseille d'indiquer de son côté : « L'attaque a mis à mal nos capacités et nous n'avons pas pu envoyer nos informations à l'Insee dans les délais requis. » En attendant la mise à jour du logiciel habituellement utilisé pour saisir et transmettre ses données à l'Insee et à la Préfecture, la ville de Marseille se résout en attendant à tenir à jour un registre papier. Ce problème intervient dans un contexte de tensions autour du protocole à base de chloroquine promue par la professeur Raoult de l'IHU Méditerranée. Source : https:www.lemondeinformatique.fr/actualites/lire-le-ransomware-visant-marseille-perturbe-le-decompte-des-deces-covid-19-78684.html\nles dépenses en infrastructure cloud ont dépassé les dépenses en infrastructure informatique traditionnelle\nSelon le cabinet de recherche IDC, le total des dépenses des utilisateurs finaux en produits d'infrastructure informatique (serveur, stockage d'entreprise et commutateur réseau) pour les environnements cloud, y compris le cloud public et privé, a renoué avec la croissance au quatrième trimestre 2019 après deux trimestres consécutifs de baisse. La croissance de 12,4 % d'une année sur l'autre au 4T19 a généré 19,4 milliards de dollars de dépenses. Les résultats du quatrième trimestre ont également permis de faire passer l’année au vert avec une croissance annuelle de 2,1 % et des dépenses totales de 66,8 milliards de dollars pour 2019. Parallèlement, le marché global des infrastructures informatiques a éprouvé de la difficulté après sa solide performance en 2018, en hausse de 3,3 % à 38,1 milliards de dollars au 4T19 mais en baisse de 1,1 % à 134,4 milliards de dollars pour l'ensemble de l'année. L'infrastructure informatique non cloud a baissé de 4,6 % à 18,7 milliards de dollars pour le trimestre et a baissé de 4,1 % à 67,7 milliards de dollars pour l'année. Au 4T19, la croissance des dépenses en infrastructure informatique cloud a été tirée par le segment du cloud public, qui a augmenté de 14,5 % d'une année sur l'autre pour atteindre 13,3 milliards de dollars; le cloud privé a augmenté de 8,2 % pour atteindre 6,1 milliards de dollars. Comme le segment global est généralement à la hausse, il a tendance à être plus volatil au niveau trimestriel, car une partie importante du segment informatique du cloud public est représentée par quelques fournisseurs de services à grande échelle. Après un milieu d'année plus faible, le cloud public a terminé 2019 à peine en hausse de 0,1 % à 45,2 milliards de dollars. Le cloud privé a augmenté de 6,6 % en 2019 pour atteindre 21,6 milliards de dollars. Alors que les investissements dans l'infrastructure informatique cloud continuent d'augmenter, avec des fluctuations durant les trimestres intermédiaires, IDC note que ce secteur approche le point où les dépenses en infrastructure informatique cloud dépassent systématiquement les dépenses en infrastructure informatique non cloud. Le quatrième trimestre 2019 a marqué le troisième trimestre consécutif de leadership informatique cloud avec une part annuelle légèrement inférieure au point médian (49,7 %). Désormais, IDC s'attend à ce que l'infrastructure informatique cloud reste au-dessus de 50 % du marché de l'infrastructure informatique aux niveaux trimestriel et annuel, atteignant 60,5 % par an en 2024. Dans les trois domaines technologiques de l'infrastructure informatique, les plateformes de stockage ont connu la croissance la plus rapide d'une année sur l'autre au 4T19 à 15,1 %, les dépenses atteignant 6,6 milliards de dollars. Les plateformes de calcul ont augmenté de 14,5 % d'une année sur l'autre avec 10,8 milliards de dollars de dépenses, tandis que les commutateurs réseau ont diminué de 3,9 % pour s'établir à 2,0 milliards de dollars. Pour l'ensemble de l'année 2019, les commutateurs réseau ont dominé avec une croissance d'une année sur l'autre de 5,0 % et 8,2 milliards de dollars de dépenses, suivis des plateformes de stockage avec une croissance de 1,9 % et des dépenses de 23,1 milliards de dollars, et des plateformes de calcul avec une croissance de 1,5 % et des dépenses de 35,5 milliards de dollars. Prévisions du marché de l'infrastructure informatique cloud Après avoir pris en comptes les répercussions de la pandémie COVID-19 et de la crise économique qui s’en est suivi, IDC estime qu’en 2020 les dépenses en infrastructure informatique cloud vont s’élever à 69,2 milliards de dollars, soit une augmentation annuelle prévue de 3,6 % par rapport à 2019. Les dépenses d'infrastructure informatique non cloud sont devrait reculer de 9,2 % pour atteindre 61,4 milliards de dollars en 2020. Ensemble, les dépenses globales en infrastructure informatique devraient reculer de 2,9 % pour s'établir à 130,6 milliards. La pandémie de COVID-19 représente une grave menace pour la croissance mondiale. Avant l'épidémie, la croissance mondiale prévue était de 2,3 % (aux taux de change du marché) en 2020. L'émergence de l'épidémie en Chine change la donne et la croissance attendue pour 2020 est désormais de -0,2 %, la plus lente depuis la crise financière mondiale. L'effet négatif sur la croissance proviendra à la fois des canaux de demande et d'approvisionnement. D'une part, les mesures de quarantaine, la maladie et le sentiment négatif des consommateurs et des entreprises vont supprimer la demande dans des domaines spécifiques, tandis que certaines poches de demande feront surface, telles que les plateformes cloud pour les charges de travail de communication et de collaboration. Dans le même temps, la fermeture de certaines usines et la perturbation des chaînes d'approvisionnement créeront des goulots d'étranglement. IDC s'attend à ce que ces effets soient répartis de manière inégale dans le paysage du marché. « Alors que le début de 2020 a été marqué par des problèmes de chaîne d'approvisionnement qui devraient être résolus avant la fin du deuxième trimestre, l'impact économique négatif affectera les dépenses en CAPEX des entreprises », a déclaré Kuba Stolarski, directeur de la recherche, Infrastructure Systems, Platforms and Technologies. chez IDC. « Alors que les budgets informatiques des entreprises se resserrent tout au long de l'année, le cloud public verra une augmentation de la demande de services. Cette augmentation proviendra en partie de la montée en puissance des employés travaillant à domicile utilisant des outils de collaboration en ligne, mais aussi de la migration de la charge de travail vers le cloud public tandis que les entreprises cherchent des moyens d'économiser de l'argent pour l'année en cours. Une fois la pandémie passée, IDC s'attend à ce qu'une partie de cette nouvelle demande de services cloud reste constante à l'avenir ». Les nouvelles prévisions quinquennales d'IDC prévoient que les dépenses d'infrastructure informatique cloud atteindront 100,1 milliards de dollars en 2024 avec un taux de croissance annuel composé (TCAC) de 8,4 %. Les dépenses d'infrastructure informatique hors cloud diminueront légèrement à 65,3 milliards de dollars avec un TCAC de -0,7 %. L'infrastructure informatique totale devrait croître à un TCAC de 4,2 % et produire des dépenses de 165,4 milliards de dollars en 2024. Source : IDC Source : https:cloud-computing.developpez.com/actu/299145/IDC-les-depenses-en-infrastructure-cloud-ont-depasse-les-depenses-en-infrastructure-informatique-traditionnelle-pour-le-troisieme-trimestre-consecutif/\nZoom a routé des appels vers la Chine\nZoom a routé des appels vers la Chine. Le 3 avril, Eric Yuan, CEO de Zoom, a admis que des appels dans son application avaient été routés par erreur vers la Chine. Cela s’est déroulé au démarrage de la pandémie, quand l’entreprise a augmenté sa capacité à gérer la demande, en commençant par Wuhan. Dans la précipitation, l’Américain avoue ne pas avoir appliqué ses habituelles bonnes pratiques de géo-fencing. Les chercheurs canadiens qui ont identifié le problème ont également découvert que le contenu de conversations Zoom entre deux utilisateurs nord-américains pouvait être chiffré avec des clés venant de serveurs situés en Chine. De nouveaux problèmes pour l’Américain déjà fortement critiqué pour ses failles de sécurité. Source : https:www.lemondeinformatique.fr/actualites/lire-telex-ap-hp-imprime-des-equipements-en-3d-zoom-a-route-des-appels-vers-la-chine-edge-detrone-firefox-78687.html\nChrome : face au coronavirus, Google fait marche arrière vis-à-vis des cookies\nAfin d’assurer la stabilité des sites web en ces temps de crise, Google a décidé de suspendre une importante mesure de sécurité introduite en février dernier. Face à la crise du Covid-19, Google rétropédale sur une nouvelle mesure de sécurité introduite en février dernier avec l’arrivée de Chrome 80. A savoir le blocage par défaut des cookies de tiers. Ces derniers, en effet, peuvent représenter un risque de vol de données personnelles ou de piratage (attaques de type Cross-Site Request Forgery). Pour éviter le blocage de cookies tiers, les éditeurs de site sont désormais contraints de les identifier explicitement, et donc de donner d’une certaine manière leur approbation. Concrètement, cela revient à rajouter un tag baptisé « SameSite » dans le code du site web pour l’ensemble des cookies utilisés.\nA découvrir aussi en vidéo Mais avec la crise du coronavirus, beaucoup d’organisations n’ont pas eu le temps d’appliquer ces changements. Et dans certains cas, cela risque de casser le fonctionnement de leur site. C’est le cas, par exemple, si elles utilisent des services d’identification tiers tels que Facebook Login. Afin de préserver la stabilité des sites, Google a donc décidé de suspendre cette mesure de sécurité. Source : Google Source : https:www.01net.com/actualites/chrome-face-au-coronavirus-google-fait-marche-arriere-vis-a-vis-des-cookies-1889721.html\nAu Royaume-Uni, des antennes 5G incendiées à cause d’une théorie du complot\nBirmingham, Liverpool, Melling (Meyerside)… au cours de la semaine écoulée, trois antennes téléphoniques ont été incendiées au Royaume-Uni, rapporte la presse britannique. Au moins quatre antennes ont été visées par des tentatives de dégradations durant le week-end du 4 et 5 avril, rapporte l’opérateur Vodafone — un départ d’incendie a également été signalé à Belfast, en Irlande du Nord. Ces trois incendies, dont l’origine criminelle ne fait guère de doute, se sont produits alors qu’une théorie du complot très populaire outre-Manche fait le lien entre l’apparition du coronavirus et le déploiement des antennes 5G dans le pays. Particulièrement fantasque, cette hypothèse, dont il existe plusieurs variantes, prétend soit que l’épidémie a été « inventée » pour « couvrir » les conséquences sur la santé de la 5G, soit que les ondes 5G « chassent » l’air des poumons et ont facilité ou provoqué les contaminations de Covid-19. Ces théories ont également été propagées par certaines célébrités britanniques, dont Amanda Holden, la juge de l’émission de télé-réalité « Britain’s got talent », qui a diffusé, à ses presque deux millions d’abonnés Twitter, une pétition liant la 5G à l’épidémie. Dans un communiqué, le régulateur des télécommunications britannique précise : « Nous avons reçu plusieurs rapports de vandalisme visant des antennes téléphoniques, mais aussi d’agressions d’employés des télécommunications, inspirées par des théories cinglées du complot qui circulent sur Internet. Les responsables de ces actes seront poursuivis avec la plus grande sévérité. » Des salariés d’une filiale de British Telecom (BT) chargés d’installer les raccordements à Internet dans les foyers britanniques ont également publié plusieurs appels au calme sur les réseaux sociaux, après plusieurs incidents au cours desquels des employés ont été menacés dans la rue. Le maire de Liverpool, Joe Anderson, a dit avoir reçu des menaces après avoir dénoncé ces théories.\nDes limitations sur les réseaux sociaux Certains réseaux sociaux, dont YouTube, ont annoncé qu’ils mettraient en place de nouvelles mesures pour limiter la diffusion des vidéos complotistes liant la technologie 5G à l’épidémie de Covid-19 : « Nous avons commencé à diminuer la place des vidéos qui promeuvent les théories du complot sur la 5G et l’épidémie, qui désinforment nos utilisateurs de manière dangereuse. » Les vidéos devraient désormais apparaître moins fréquemment dans les suggestions de vidéos à regarder, qui sont une gigantesque source de trafic sur la plate-forme. Sur Facebook, une recherche « 5G coronavirus » affiche, dans ses premiers résultats, plusieurs messages défendant cette théorie du complot, avant ceux des autorités sanitaires, a pu constater Le Monde, lundi matin. Mais le problème ne touche pas que les réseaux sociaux : le régulateur des médias britannique a également sanctionné une radio locale qui avait donné une large place sur son antenne à une personne propageant cette théorie.\nLire aussi Facebook, YouTube… les grandes plates-formes d’Internet face au défi du coronavirus Ces attaques contre le réseau téléphonique inquiètent également les responsables du réseau de santé britannique. Stephen Powis, le directeur médical du National Health Service, le service de santé britannique, a vivement dénoncé ces actes de vandalisme : « La réalité est que les réseaux mobiles sont absolument critiques pour nous tous, alors que nous demandons à tous les citoyens de rester chez eux et de ne pas voir leurs parents et amis. Mais plus particulièrement, ces réseaux sont utilisés par nos services de secours et les travailleurs du système de santé, et je suis totalement furieux, totalement dégoûté de voir qu’il y a des attaques contre les infrastructures mêmes qui nous permettent de répondre à cette urgence sanitaire. » Les antennes incendiées ces derniers jours n’étaient pas toutes des antennes 5G. Selon la BBC, au moins l’une des tours incendiées semblait ne pas contenir d’antenne 5G. Source : https://www.lemonde.fr/pixels/article/2020/04/06/au-royaume-uni-des-antennes-5g-incendiees-a-cause-d-une-theorie-du-complot-sur-le-coronavirus60357184408996.html"},{"uuid":"3e7ef528-6bd0-4fd1-83cb-a0d03ba35949","slug":"npm-le-ver-dans-le-fruit-comprendre-la-faille-systemique-et-repenser-les-pratiques-devops","title":"NPM, le ver dans le fruit : comprendre la faille systémique et repenser les pratiques DevOps","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2026-05-12 13:08","created_at":"2026-05-12 13:08:44","updated_at":"2026-05-12 13:12:42","tags":[],"plain":"À propos de l'article du MagIT « NPM : une nouvelle campagne malveillante souligne une vulnérabilité systémique ».\r\n\r\nNPM expliqué simplement\r\n\r\nQuand on développe une application web moderne en JavaScript ou TypeScript, on ne réécrit jamais tout depuis zéro. On assemble des briques logicielles déjà écrites par d'autres : un module pour parser des dates, un autre pour valider des emails, un troisième pour discuter avec une base de données. Ces briques s'appellent des paquets, et la place de marché centrale qui les distribue s'appelle npm (Node Package Manager).\r\n\r\nConcrètement, dans un projet, on déclare la liste des paquets nécessaires dans un fichier . On lance la commande , et l'outil télécharge automatiquement les paquets demandés… ainsi que tous les paquets dont ces paquets ont eux-mêmes besoin. Un projet « simple » se retrouve souvent à dépendre de plusieurs centaines, voire plusieurs milliers, de paquets en cascade. C'est ce qu'on appelle l'arbre des dépendances.\r\n\r\nLe registre npm héberge aujourd'hui plus de 2,5 millions de paquets. C'est à la fois sa force — un écosystème colossal, une productivité décuplée — et sa faiblesse : la confiance accordée à chaque maillon de la chaîne est implicite, et chaque maillon devient une porte d'entrée potentielle.\r\n\r\nLa faille : ce qui s'est passé\r\n\r\nL'épisode décrit par LeMagIT n'est pas un bug logiciel classique. C'est ce qu'on appelle une attaque sur la chaîne d'approvisionnement logicielle (supply chain attack) : au lieu d'attaquer directement la cible finale, l'attaquant compromet un fournisseur en amont, et laisse la mise à jour légitime faire son travail de propagation.\r\n\r\nLe scénario reconstitué se déroule en plusieurs temps.\r\n\r\n1. Compromission d'un paquet de confiance. Les attaquants sont parvenus à pousser du code malveillant dans des paquets npm largement utilisés, notamment via le détournement du pipeline d'intégration continue de projets connus comme  et l'écosystème Checkmarx. L'astuce n'est pas de publier un faux paquet : c'est de modifier un vrai paquet en exploitant les GitHub Actions — les robots qui construisent et publient automatiquement les nouvelles versions.\r\n\r\n2. Vol de secrets à l'installation. Une fois installé sur la machine d'un développeur ou dans un environnement de build, le code malveillant scanne l'environnement à la recherche de variables sensibles : , , , . Tout ce qui traîne dans les variables d'environnement, les fichiers , les configurations cloud.\r\n\r\n3. Auto-propagation. C'est là que l'attaque devient virale. Avec les jetons npm volés, le maliciel se reconnecte au registre npm, récupère la liste des paquets publiés par la victime, et publie automatiquement des versions piégées de ces paquets. Chaque développeur compromis devient un super-propagateur. Socket a identifié une quarantaine de paquets infectés en cascade lors d'une seule vague.\r\n\r\n4. Persistance. Sur les postes touchés, le malware installe un script  pour survivre aux redémarrages, et, si nécessaire, exfiltre les données volées dans un dépôt GitHub public créé pour l'occasion.\r\n\r\nLe résultat : un binaire signé, publié sous un nom officiel, à jour, qui passe tous les contrôles de surface — et qui contamine simultanément le poste du développeur et les serveurs de production.\r\n\r\nPourquoi c'est « systémique »\r\n\r\nLe terme employé par LeMagIT est juste. Ce n'est pas un bug isolé, c'est une propriété structurelle de l'écosystème.\r\n\r\nLa confiance est transitive. On fait confiance à , qui fait confiance à , qui fait confiance à , etc. Compromettre un nœud profond et populaire suffit à toucher des millions de projets.\r\n\r\nLa publication est ouverte. N'importe qui peut publier un paquet. Les contrôles existent (provenance, 2FA pour les mainteneurs populaires) mais restent surtout a posteriori.\r\n\r\nLes scripts d'installation s'exécutent automatiquement. Un paquet npm peut déclarer un  qui lance du code arbitraire au moment de . C'est pratique, mais c'est aussi un cheval de Troie idéal.\r\n\r\nLes jetons d'API sont partout. Le poste du développeur, les runners CI/CD, les serveurs : tous manipulent des secrets en clair dans des variables d'environnement. Un malware qui s'exécute dans le build n'a même pas besoin d'escalader ses privilèges.\r\n\r\nLes versions sont mutables sur fenêtre courte. Un paquet peut être republié dans les 72 heures suivant sa publication, et un  peut retirer une version d'un jour à l'autre.\r\n\r\nAucun de ces points n'est un défaut technique réparable par un patch. Ce sont des choix d'architecture, vieux de plus de dix ans, qui ont accompagné l'explosion de l'écosystème.\r\n\r\nY a-t-il des alternatives ?\r\n\r\nLa question est légitime, mais la réponse honnête est : pas vraiment, et pour de bonnes raisons.\r\n\r\nLes gestionnaires de paquets alternatifs\r\n\r\n,  et  sont des gestionnaires différents, mais ils tirent leurs paquets du même registre npm. Migrer de  à  ne change rien à la surface d'attaque : ce sont les mêmes paquets, le même registre, les mêmes mainteneurs.\r\n\r\nCela dit, certains apportent des garde-fous utiles :\r\na introduit l'option , qui refuse d'installer un paquet publié il y a moins de N jours. Une vague d'attaque dure typiquement quelques heures avant détection : attendre 72 heures avant d'installer une nouvelle version élimine la fenêtre dangereuse.\r\nimpose un consentement explicite pour les scripts , là où npm les exécute par défaut.\r\net  proposent des lockfiles stricts () qui garantissent que ce qui est installé en CI correspond exactement à ce qui a été testé.\r\n\r\nLes registres alternatifs\r\n\r\nJSR (JavaScript Registry), lancé par les créateurs de Deno, est le seul vrai nouveau registre crédible. Il a été conçu en tirant les leçons des problèmes de npm : TypeScript natif, modules ECMAScript par défaut, pas de scripts d'install, scoring qualité automatique, compatible avec tous les runtimes (Node, Deno, Bun). Mais JSR est complémentaire, pas un remplaçant : il héberge des milliers de paquets, pas des millions. Pour la majorité des dépendances, on continuera de passer par npm.\r\n\r\nLes registres privés — Verdaccio, GitHub Packages, JFrog Artifactory, Sonatype Nexus — ne remplacent pas npm non plus. Ils servent de proxy filtrant : on continue de récupérer les paquets publics, mais à travers un cache d'entreprise où l'on peut bloquer une version, exiger une signature, refuser un mainteneur, ou interdire les paquets publiés depuis moins de X jours. C'est probablement le meilleur compromis disponible aujourd'hui pour une organisation.\r\n\r\nLe verdict\r\n\r\nAbandonner npm en 2026 reviendrait à abandonner JavaScript. La valeur de l'écosystème (2,5 millions de paquets) est trop importante pour qu'on en sorte. Le problème ne se résoudra pas par un changement d'outil ; il se résoudra par un changement de pratiques.\r\n\r\nChanger les pratiques : ce qui doit devenir réflexe\r\n\r\nL'enseignement de cette campagne, et des précédentes (Shai-Hulud, TeamPCP, l'attaque Trivy/KICS), tient en une phrase : la confiance par défaut est morte. Il faut traiter chaque dépendance comme du code hostile par défaut, et le pipeline CI/CD comme une zone de production.\r\n\r\nAu niveau du poste de développement\r\nActiver l'option  (ou équivalent) pour différer l'installation des paquets fraîchement publiés.\r\nDésactiver les scripts  par défaut, et n'autoriser que ceux explicitement validés.\r\nNe jamais stocker de jetons en clair dans  ou les variables d'environnement persistantes. Préférer un gestionnaire de secrets (1Password CLI, , ).\r\nUtiliser des comptes npm séparés pour la publication, avec 2FA matérielle obligatoire.\r\n\r\nAu niveau du dépôt\r\nVerrouiller systématiquement les dépendances (, , ) et installer en mode strict (, ).\r\nMettre en place un audit automatique des dépendances à chaque PR (Socket, Snyk, GitHub Dependabot, ).\r\nPublier ses propres paquets avec provenance npm (signature liée au pipeline GitHub Actions), pour que les consommateurs puissent vérifier l'origine.\r\nTenir à jour un SBOM (Software Bill of Materials) pour savoir exactement ce qui tourne en production.\r\n\r\nAu niveau du CI/CD\r\n\r\nC'est probablement le chantier le plus important.\r\nCloisonner les jetons. Un jeton de publication npm ne doit jamais coexister avec un jeton AWS dans la même étape de pipeline. Un secret par étape, durée de vie minimale, scope minimal.\r\nPréférer les jetons à courte durée de vie (OIDC entre GitHub Actions et le cloud) plutôt que des clés statiques.\r\nAuditer les GitHub Actions tierces. Une action  est l'équivalent d'un . Épingler par hash SHA (), pas par tag mutable.\r\nRestreindre les permissions du  au strict minimum ( par défaut,  ponctuel et justifié).\r\nSurveiller le comportement réseau des runners : un build qui contacte un domaine inconnu doit lever une alerte.\r\n\r\nAu niveau de l'organisation\r\nMettre en place un registre proxy (Verdaccio, Nexus, Artifactory) avec liste blanche/noire de paquets, et l'imposer comme unique source pour tous les projets.\r\nDéfinir une politique de dependency governance : qui peut introduire une nouvelle dépendance, sous quelles conditions, avec quel niveau d'audit.\r\nPrévoir un playbook de révocation : que faire dans l'heure qui suit la détection d'un paquet compromis (rotation de tous les jetons npm/GitHub/cloud, audit des artefacts publiés, communication).\r\n\r\nEn résumé\r\n\r\nNPM n'est pas cassé, il est tel qu'il a été conçu : ouvert, automatique, transitif. Ce qui a changé, c'est la valeur que les attaquants peuvent en extraire — secrets cloud, jetons CI/CD, accès aux pipelines — et la sophistication des campagnes, qui exploitent désormais l'auto-propagation pour atteindre une échelle virale.\r\n\r\nAucune alternative ne supprime le problème, parce que le problème n'est pas npm : c'est l'idée qu'on puisse exécuter en production du code écrit par des inconnus sans jamais le regarder. Le rôle du DevOps en 2026, c'est de bâtir l'infrastructure qui rend cette inspection systématique, économique et inévitable — registres proxy, lockfiles stricts, jetons éphémères, audits continus, isolation des étapes de build.\r\n\r\nOn ne fera pas confiance à moins de gens. On exigera juste que chaque maillon prouve, à chaque exécution, qu'il est bien celui qu'il prétend être."},{"uuid":"17f293bd-c65b-494a-bfeb-8ab37fef8dd8","slug":"consulter-la-liste-des-programmes-installes","title":"Consulter la liste des programmes installés","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-09 14:53:39","created_at":"2023-02-09 14:53:39","updated_at":"2023-02-09 14:53:39","tags":[],"plain":"Sous Fedora, je vous propose une liste de commandes pour avoir la liste des programmes déployés sur votre machine. Lister les snaps installés\nVous pouvez utiliser la commande  pour afficher la liste des snaps déployés sur votre système :   snap list\n   Quelques snaps, comme core sont affichés et sont installés automatiquement par snapd. Il s'agit d'un prérequis pour les autres snaps. Lister les paquets DNF\nEn utilisant la commande , la liste des programmes déployés par le gestionnaire DNF"}]