Linux a un problème de cale. Ce qui conduit naturellement à une question raisonnable : qu’est-ce qu’une cale et pourquoi en avons-nous besoin ? La réponse : faire fonctionner Linux avec Secure Boot et une bizarrerie involontaire de la GPLv3.
Secure Boot est le système de vérification des machines modernes qui garantit que seul un système d’exploitation fiable peut démarrer. Lorsque Secure Boot a été introduit pour la première fois, de nombreux fans de Linux ont suggéré qu’il ne s’agissait que d’une tentative de maintenir les distributions Linux hors des machines des consommateurs. Cette crainte semble avoir été injustifiée, car Microsoft a consciencieusement gardé la signature Linux Shim, afin que nous puissions tous exécuter des distributions Linux sur nos machines à démarrage sécurisé.
Donc la cale. Il s’agit essentiellement d’un chargeur de démarrage de premier étage, qui peut démarrer un GRUB2 signé ou une autre cible. Vous vous demandez peut-être pourquoi ne pouvons-nous pas simplement demander à Microsoft de signer GRUB2 directement ? Et c’est là que la GPLv3 entre en jeu. Cette licence comporte une section « anti-tivoisation », qui spécifie les « informations d’installation » dans le cadre de ce qui doit être fourni dans le cadre de la conformité GPLv3. Et l’équipe juridique de Microsoft comprend que cette exigence s’applique même à ce processus de signature. Et cela irait totalement à l’encontre de l’intérêt du démarrage sécurisé de libérer les clés, donc aucun code GPLv3 n’est signé. Au lieu de cela, nous récupérons la cale.
Maintenant que nous comprenons la cale, voyons comment elle est cassée. La vulnérabilité la plus grave est un débordement de tampon dans le code de transfert de fichiers HTTP. Le tampon est alloué en fonction de la taille de l’en-tête HTTP, mais un serveur HTTP malveillant peut définir cette valeur de manière incorrecte, et le code shim écrirait volontiers le contenu HTTP réel après la fin de ce tampon, conduisant à l’exécution de code arbitraire. Vous vous demandez peut-être pourquoi la cale contient-elle du code HTTP ? La réponse simple est de prendre en charge le démarrage HTTP UEFI, un remplacement du démarrage PXE.
La bonne nouvelle est que cette vulnérabilité ne peut être déclenchée que lors de l’utilisation d’un démarrage HTTP, et uniquement en se connectant à un serveur malveillant ou via une attaque de l’homme du milieu. Dans cette optique, il est étrange que cette vulnérabilité soit notée 9,8. Plus précisément, il semble incorrect de considérer ce bug comme étant de faible complexité ou comme vecteur d’attaque réseau général. Dans son propre article sur la vulnérabilité, Red Hat affirme que l’exploitation est d’une grande complexité et n’est possible qu’à partir d’un réseau adjacent. Une poignée de vulnérabilités mineures ont été trouvées, et celles-ci ont toutes été corrigées avec shim 15.8.
LassPass banni de l’App Store
Tout ce qui nous manque ici, c’est un autre nom d’application LastPast, et nous aurions l’équivalent sur l’App Store de trois Spidermen différents debout en cercle se pointant l’un vers l’autre. Les développeurs derrière l’application LastPass ont trouvé une application LassPass étrangement similaire sur l’App Store d’Apple. Nous avons constaté du typosquatting sur de nombreux référentiels de logiciels Open Source, mais c’est également un problème sur les magasins d’applications.
Trois millions de brosses à dents
Une histoire a pris d’assaut le monde de la sécurité cette semaine : trois millions de brosses à dents intelligentes ont été compromises et ont été utilisées pour lancer une attaque par déni de service distribué (DDoS) sur un site Web suisse. L’histoire provenait d’un site d’information suisse et faisait référence à une interview de Stefan Züger de Fortinet.
Avant de raconter la suite de l’histoire, réfléchissons à ceci. L’histoire serait très importante, mais celle-ci semble être la seule source originale sur Internet. La marque de la brosse à dents n’est pas nommée, pas plus que l’entreprise victime du DDoS. Un botnet ou une famille de logiciels malveillants spécifique n’a pas non plus été répertorié. Les brosses à dents intelligentes existent, mais elles ne seront pas exposées en masse à Internet. En fait, il serait inhabituel que l’un d’entre eux dispose d’une connectivité au-delà du simple Bluetooth. Comment un logiciel malveillant parviendrait-il à atteindre l’un de ces appareils pour le compromettre ?
Nous pourrions construire un scénario dans lequel cela pourrait se produire. Une brosse à dents intelligente devrait disposer d’une connexion Wifi dans le cadre de son processus de configuration. Cela semble bizarre, mais j’ai vu un comportement IoT plus stupide. Ensuite, la seule façon d’expliquer qu’un si grand nombre d’appareils soient compromis d’un seul coup est une mise à jour malveillante du micrologiciel. Soit par le biais d’une attaque de la chaîne d’approvisionnement, soit par quelque chose de stupide comme un nom de domaine qui expire et qui est revendiqué par un acteur menaçant. Ce scénario plutôt alambiqué pourrait en fait expliquer un botnet de trois millions de brosses à dents.
Mais si vous ne l’avez pas encore compris, cela ne s’est pas produit. Il s’agit d’un scénario hypothétique basé à peu près sur des recherches antérieures de Fortinet sur ce qui pourrait être fait avec les logiciels malveillants liés aux brosses à dents (PDF). Bleeping Computer a reçu une réponse officielle de Fortinet :
Pour clarifier, le sujet des brosses à dents utilisées pour les attaques DDoS a été présenté lors d’un entretien comme une illustration d’un type d’attaque donné, et il ne s’appuie pas sur des recherches de Fortinet ou de FortiGuard Labs. Il semble qu’en raison des traductions, le récit sur ce sujet a été étiré au point que les scénarios hypothétiques et réels sont flous.
Ce n’est pas tout à fait la fin de l’histoire. Le site Aargauer Zeitung a été assez explicite sur le fait que Stefan de Fortinet a déclaré que cette attaque était réelle dans l’article original. En réponse à l’annonce de Fortinet, ils ont modifié cet article, mais ont également publié une réponse affirmant qu’il n’y avait aucun problème de traduction – ils parlent tous allemand après tout. Ils rapportent que Fortinet a considéré l’attaque à la brosse à dents comme réelle, a donné des détails sur sa durée et sur le coût qu’elle a coûté à la victime. Le détail le plus surprenant ici est que Fortinet a effectué une révision préalable à la publication de l’article et l’a signé.
Alors, quel est le point à retenir ici ? D’une part, les sites d’information se trompent parfois. Si une histoire vous semble bizarre, recherchez les sources primaires. S’il n’y a pas de sources primaires, c’est peut-être que quelque chose n’est pas tout à fait comme indiqué. On ne sait pas exactement où la rupture de communication s’est produite dans ce cas, mais ce qui semble le plus probable est qu’un employé de Fortinet a lu une étude de cas interne sur une attaque hypothétique et a pensé qu’il s’agissait d’un événement réel. De toute la couverture médiatique de ce sujet, je pense que c’est celle du blog Malwarebytes qui me plaît le plus.
Bits et octets
Il existe un tour intéressant que les chercheurs en sécurité se sont joués. Il y a trop de pots de miel. Ou peut-être que le problème est que les pots de miel sont trop doués pour agir comme du vrai matériel. Quoi qu’il en soit, le processus de suivi du nombre d’appareils accessibles et vulnérables sur Internet devient un véritable défi. L’exemple donné est la présence de plus de 200 000 résultats Confluence sur Shodan, mais seulement 5 000 résultats réels de favicon. Cela suggère qu’il y a 40 pots de miel Confluence pour chaque serveur réel. L’esprit est ahurissant.
Apparemment, certaines pompes à chaleur d’Alpha Innotec et Novelan ont une fonctionnalité non documentée : un accès SSH avec un mot de passe root connu. C’est une façon d’empêcher les utilisateurs de Home Assistant de spammer vos serveurs API. Mais ce n’était probablement pas intentionnel. Il se trouve qu’un simple mot de passe haché avec 3DES peut être déchiffré en quelques secondes sur une machine moderne. C’est eschi si vous vous le demandiez.
Et enfin, une vulnérabilité dans Mastodon a été publiée la semaine dernière. Il s’agit d’un bug dans la gestion des comptes fédérés, de sorte qu’un attaquant peut usurper l’identité d’un compte depuis un autre serveur. La mise à jour est disponible maintenant, mais tous les détails ne seront pas publics avant le 15 pour donner aux opérateurs de serveurs le temps de mettre à jour. Hackaday.social est déjà mis à jour, si vous vous le demandez.