Éclipse de citrouille

 (blog.lumen.com)
1 points par GN⁺ 2024-06-01 | 1 commentaires | Partager sur WhatsApp
  • L’URL est the-pumpkin-eclipse, mais le texte fourni est non pas l’article sur l’éclipse de citrouille, mais la page de blog et de hub d’actualités de Lumen Technologies
  • Les articles mis en avant en haut de page s’articulent autour de l’idée qu’avec l’IA qui transforme le fonctionnement des entreprises, il faut un réseau programmable, évolutif et sécurisé
  • Le projet d’acquisition d’Alkira par Lumen est présenté comme un exemple de mise en place du plan de contrôle nécessaire à la connectivité cloud de nouvelle génération
  • Les autres contenus recommandés enchaînent sur le réseau programmable, le cas d’usage de Lumen et Zoom AI chez Bank of Tennessee, ainsi que le support de connectivité pour les événements mondiaux d’AWS
  • Les dernières actualités et la zone d’exploration proposent à la fois des nouvelles d’entreprise comme des offres d’échange, des promotions de dirigeants et des résultats d’offre publique d’achat, ainsi que des filtres par sujet, secteur et service

Nature réelle de la page fournie

  • Le contenu est une page de blog et de hub d’actualités de Lumen Technologies, qui rassemble innovations technologiques, stratégies et expertise liées à la transformation numérique et à la préparation à l’IA
  • La page est structurée en contenus recommandés, dernières actualités et zone d’exploration du contenu
  • Le chemin d’URL d’origine est the-pumpkin-eclipse, mais le contenu fourni ne contient aucun véritable article sur l’éclipse de citrouille

Fil des contenus recommandés

Dernières actualités

Filtres d’exploration du contenu

  • Les filtres par sujet incluent notamment Application Protection, Customer Success, Data Center, DIA, Ransomware, SD WAN, API, Artificial Intelligence, Cloud Computing, DDoS Protection, SASE et ZTNA
  • Les filtres par secteur proposent Manufacturing, State and Local Government, Technology, Defense Intelligence, Federal Government, Education, Gaming, Healthcare, Retail, Financial Services et Public Safety
  • Les filtres par service se composent de Infrastructure services, Connectivity services, Security services, Communication services et Media Entertainment

À lire aussi

1 commentaires

 
GN⁺ 2024-06-01
Avis de Hacker News

  • Ce serait bien de pouvoir intercepter la ligne d’activation d’écriture de la puce flash qui contient le firmware pour empêcher les mises à jour, et de virer avec un redémarrage quotidien toutes les saletés qui ne résident qu’en mémoire.
    C’est une méthode qu’on utilisait sur les récepteurs satellite il y a 20 ans, mais désormais il faudra peut-être considérer que tous les équipements connectés à Internet sont vulnérables à des contre-mesures électroniques similaires.
    Au moins, sur mon propre matériel, j’aimerais surveiller si une mise à jour a lieu et allumer un voyant quand c’est le cas, afin de savoir si c’est normal ou non.

    • C’est une situation perdante quoi qu’il arrive. Si on bloque les mises à jour de firmware, on aurait empêché cette attaque, mais on bloquerait aussi les correctifs de sécurité qui évitent que le routeur devienne un botnet.
      Cela dit, ce que je ne comprends pas dans ce cas, c’est pourquoi il n’était pas possible de remettre l’appareil dans son état d’origine. Si l’intégralité du firmware, sauvegardes comprises, peut être détruite, ça ressemble à un défaut de conception.
    • Il existait un projet open hardware d’émulation de carte SD capable de refuser les écritures : https://github.com/racklet/meeting-notes/blob/main/community...
      Il existe aussi une émulation open source pour la flash SPI : https://trmm.net/Spispy/
      Certains lecteurs USB (Kanguru) et boîtiers SSD (ElecGear M.2 2230 NVME) permettent de bloquer l’écriture via le firmware et un interrupteur physique, ce qui est utile pour démarrer des live ISO personnalisées exécutées en RAM.
    • Du point de vue de quelqu’un qui utilisait des cartes HU du marché noir, DirecTV était en fait un exemple de menace persistante avancée. Je ne l’avais jamais vu comme ça auparavant.
    • Je ne connais pas bien les solutions DSL grand public, mais pour les modems câble, le firmware et la configuration sont gérés par le CMTS. En effet, lorsque la technologie et la configuration côté tête de réseau changent, des modifications côté client peuvent être nécessaires pour continuer à fonctionner.
      À mesure que l’infrastructure câble et les équipements de tête de réseau sont mis à niveau et maintenus, le plan de fréquences, les débits de signal, etc. changent, donc la configuration évolue assez dynamiquement.
      Si l’on essaie de verrouiller l’activation d’écriture de l’EEPROM, le provisionnement du modem finira très probablement par échouer.
    • On pourrait appeler ça un « malware first-party ».

  • L’article manque de détails intéressants. Je me demande comment ils sont entrés, et si ces routeurs ont par défaut des ports et services ouverts et répondent de manière significative sur Internet.
    Ne pourrait-on pas récupérer différentes versions de firmware et les comparer ?
    Ça ressemble à l’approche courante consistant à poser un SDK fournisseur par-dessus OpenWrt : https://forum.openwrt.org/t/openwrt-support-for-actiontec-t3...
    Ce qui est intéressant, c’est qu’on soupçonne que le fournisseur a pu envoyer une mise à jour malveillante ou cassée : https://www.reddit.com/r/Windstream/comments/17g9qdu/solid_r...
    Si c’est le cas, pourquoi n’y a-t-il pas eu de communiqué officiel de l’ISP ? S’il s’agissait d’une attaque, ne devrait-il pas y avoir une enquête ? Je ne sais pas comment ce genre de choses est traité aux États-Unis, mais ça paraît vraiment étrange.
    Peut-être que ces équipements étaient infectés par des bots et que le fournisseur a poussé une mise à jour qui les a tous cassés.
    Ou alors c’était, comme dans l’article, une attaque coordonnée impliquant aussi du rançonnage, et on a simplement dit à tout le monde : « c’est une mise à jour de firmware défectueuse, restez calmes ».
    Du point de vue des clients, c’est aussi assez grave, car ils voudraient savoir s’il y a eu un incident de sécurité.
    Je me demande s’il existe des images de firmware de ces appareils, ou des liens vers des informations plus détaillées.

    • Il est possible que la décision de l’ISP de ne pas faire de communiqué officiel soit fondée sur les résultats de l’enquête.
      Je me demande aussi quelle part du coût de remplacement sera couverte par l’assurance. Probablement aucune, ce qui ferait peser sur l’ISP un risque sérieux pour la continuité de son activité. Une raison de plus de ne pas communiquer.

  • « Lumen a identifié plus de 330 000 adresses IP uniques ayant communiqué avec l’un des 75 nœuds C2 observés » : comment la télémétrie mondiale de Black Lotus Labs sait-elle quelles IP ont communiqué avec quelles IP sans contrôler aucune des deux extrémités ? Qui conserve les journaux de trafic, et lesquels ?
    S’ils peuvent faire ça, j’aimerais qu’on m’explique à nouveau pourquoi Tor est sûr : l’explication selon laquelle il est impossible de suivre un paquet depuis mon équipement, à travers les sauts de routage en oignon, jusqu’au nœud de sortie, où ce même paquet apparaît en clair.

    • J’ai un ami qui travaille chez Black Lotus, et il a peut-être écrit cet article. Black Lotus fait partie de Lumen, et Lumen est l’un des plus grands opérateurs de trafic backbone au monde, incluant Level3 et CenturyLink.
      Une énorme proportion du trafic mondial passe par leur réseau, donc ils peuvent probablement observer directement le trafic, y compris les indicateurs.
    • C’est assez désillusionnant. Est-ce que cela veut dire qu’il est pratiquement impossible d’éviter une empreinte IP, d’une manière ou d’une autre ? Même avec Tor ou une VM ? À moins de posséder soi-même le serveur physique, finit-on toujours par devoir faire confiance à l’opérateur ?
    • C’est une fonctionnalité assez standard sur les routeurs backbone. De toute façon, il faut analyser les en-têtes TCP en matériel, et les points de terminaison fréquents peuvent être suivis avec un état O(1).
      Bien sûr, à l’autre extrême, il y a aussi la situation où la NSA place des taps sur les liaisons Internet clés, enregistre tout ce qu’elle peut et le conserve pour toujours.
    • Windstream journalise probablement le trafic de ses clients de manière routinière. Ce peut être des métadonnées (NetFlow/sFlow/IPFIX, etc.), mais quoi qu’il en soit, pour disposer de ces informations, il faut les enregistrer et les conserver.
      J’espère que les conditions contractuelles de Windstream le précisent clairement.
    • Tor repose sur l’hypothèse qu’il protège parce que le trafic passe par plusieurs nœuds avant de sortir et se mélange avec d’autres flux. Si l’on possède la plupart, voire tous les nœuds du réseau et qu’on peut analyser le trafic, il est peut-être possible d’identifier certains flux.
      Cela dit, plus un nœud traite de trafic, plus c’est difficile.
      La méthode la plus simple est tout simplement d’exploiter un nœud de sortie.[1]
      1 : https://en.wikipedia.org/wiki/Tor_(network)#Exit_node_eavesd...

  • Depuis quelques années, j’utilise une petite machine x86 avec deux NIC sur laquelle je fais tourner OpenWRT. C’est open source, bien pris en charge, la communauté est bonne, et WireGuard est aussi supporté
    La dernière version peut même exécuter des conteneurs Docker

    • Mais ici, il s’agit d’un modem DSL. À un moment donné, il faut bien une interface qui relie le réseau côté WAN, que ce soit en DSL, en coaxial ou en fibre
      Même un adaptateur DSL pour slot PCIe est en fait un système au format carte, donc il n’a simplement pas de boîtier, mais possède toutes les fonctions et tous les bugs d’un « routeur »
    • Ce qui a été touché, c’était le modem, donc OpenWRT n’aurait pas protégé contre ça
    • J’utilise OpenBSD sur une vieille carte PC Engines, et elle fonctionne de façon étonnamment fiable depuis environ 8 ans
    • « La dernière version peut même exécuter des conteneurs Docker » : qu’est-ce qui pourrait bien mal tourner…

  • Quand on implante une backdoor dans 600 000 routeurs et qu’on met un bug de firmware dans l’un des correctifs, voilà ce qui arrive
    Ils ne pouvaient pas déployer la mise à jour progressivement ? Les auteurs et utilisateurs du malware sont apparemment trop cool pour adopter les pratiques opérationnelles standard

    • Leurs contraintes économiques sont simplement différentes. Ce n’est pas leur matériel qui se fait briquer, et il y a peu de chances qu’ils aient à en répondre

  • Je ne comprends pas ce que signifie le titre de l’article

    • Cette attaque s’est produite quelques jours avant Halloween 2023, donc « citrouille » ; et la forte baisse du nombre d’appareils connectés à Internet est peut-être comparée à une éclipse qui plonge soudainement tout dans l’obscurité
      Ce n’est que mon interprétation, et je trouve moi aussi le titre obscur
    • Il n’y avait pas un titre plus compréhensible il y a quelques heures ?

  • Pour ceux que le titre a embrouillés : il ne s’agit pas d’un routeur à 600 000 dollars, mais de 600 000 petits routeurs individuels qui ont été détruits

  • Si HN avait des points de karma, on pourrait en donner davantage à l’auteur de la soumission qui a amélioré le mauvais titre clickbait d’origine
    Ici, on emploie le présent pour parler d’un incident d’octobre dernier

    • On pourrait aussi retirer des points aux soumissions dont le titre semble encourager à causer des dégâts

  • Article connexe d’Ars Technica : https://arstechnica.com/security/2024/05/mystery-malware-des...

    • Ce n’est pas tant un article connexe qu’une réécriture de l’article original. Il n’ajoute aucun détail propre

  • Pour mon réseau domestique, j’ai acheté un ordinateur sous forme d’appliance réseau. En gros, c’est une machine avec un i3 ordinaire prenant en charge VT-x, un boîtier fanless et quatre NIC 2,5 GiB
    J’ai installé une distribution Linux stable, avec mises à jour de sécurité automatiques régulières, à la fois sur l’hôte et sur la VM, et j’ai mappé trois NIC vers cette VM en tant que périphériques. Le NIC restant n’est connecté à rien, sauf quand je veux accéder à l’hôte en SSH
    Dans la VM, UFW et Shorewall gèrent le pare-feu et le routage. Si je veux ajuster quelque chose, je me connecte à cette VM en SSH. J’ai aussi des snapshots du disque de la VM, pour pouvoir revenir facilement à un état sain connu si je fais une erreur
    J’ai aussi acheté quelques points d’accès WiFi commerciaux moins chers et les ai répartis dans la maison, avec des canaux configurés pour minimiser les interférences
    Avant ça, j’avais essayé plusieurs produits réseau d’Apple, Google, ASUS, etc., mais tous avaient des problèmes de performances et de fiabilité. Par exemple, des pertes de paquets aléatoires de 3 à 5 secondes pendant des réunions Zoom, ce qui était extrêmement agaçant
    Depuis que je l’ai configuré moi-même, je n’ai plus aucun problème, et je suis aussi plus sûr que l’ensemble est configuré de façon sécurisée et reçoit les mises à jour de sécurité pertinentes. En résumé, tant qu’une grande partie du monde utilisant la même distribution Linux réputée stable ne rencontre pas un problème en même temps, mon réseau domestique n’en aura pas non plus

    • Cette attaque touchait le modem, donc même avec un matériel aussi chouette, vous auriez quand même perdu Internet
    • Par curiosité, j’aimerais savoir quel ordinateur de type appliance réseau vous avez acheté