Sélection de l’actualité de la semaine

 

Des numéros de téléphone des utilisateurs WhatsApp indexés sur Google

La fonctionnalité « Cliquer pour discuter » de WhatsApp conduit à l’indexation des numéros de téléphone des utilisateurs par Google. La fonction s’appuie sur le domaine https://wa.me, propriété de WhatsApp, pour générer des liens d’invitation à démarrer une nouvelle conversation avec quelqu’un sans avoir son numéro de téléphone enregistré dans le carnet d’adresses de son téléphone. Problème, les numéros de téléphone utilisés pour générer des liens de conversation sont indexés par Google ; un chercheur a ainsi montré que les numéros pouvaient être très facilement retrouvés par une simple recherche avancée. WhatsApp et Facebook, propriétaire de l’application, ne considèrent pas cette indexation comme un bug ou comme un problème. En effet, en réponse à l’alerte lancée par le chercheur qui a découvert le problème, Facebook a répondu que la découverte « contenait simplement un index de moteur de recherche d’URL que les utilisateurs de WhatsApp ont choisi de rendre public. Tous les utilisateurs de WhatsApp, y compris les entreprises, peuvent bloquer les messages indésirables en appuyant sur un bouton ». Toutefois, les numéros de téléphone sont aujourd’hui massivement utilisés comme authentifiants – pour la double authentification –  et permettent de réaliser de nombreuses attaques, la plus connue étant le SIM swaping. Dans ce contexte, l’exposition de ces numéros de téléphone pose un risque de sécurité non-négligeable que Facebook et WhatsApp ne semblent pas vouloir prendre en compte. De son côté, Google a rappelé que l’indexation de sites était le cœur d’activité de l’entreprise mais que celle-ci proposait des outils permettant de bloquer l’indexation si besoin.

[EDIT] Suite à la révélation de cette problématique, WhatsApp a finalement apporté les changements informant les web crawlers de ne pas indexer les liens contenant les numéros de téléphone générés par la fonction « Cliquer pour discuter ».

 

Une faille de sécurité aurait pu permettre de prendre le contrôle des feux de circulation SWARCO

SWARCO est le plus grand fabricant mondial dans la signalisation lumineuse et le numéro deux à l’échelle internationale pour les billes de verre réfléchissantes. Des chercheurs de ProtectEM ont découvert que les contrôleurs de feux de circulation CPU LS4000 de SWARCO disposent d’un port ouvert conçu pour le débogage qui aurait pu être exploité par des attaquants. La faille (CVE-2020-12493, CVSS score : 10.0) qui demandait toutefois un accès physique aux feux de circulation pour être exploitée, a été signalée en juillet 2019 avant d’être corrigée en avril 2020. Un attaquant ayant pu obtenir un accès physique aux contrôleurs vulnérables aurait ainsi pu désactiver simultanément tous les feux de circulation à l’échelle d’une ville.

 

Une vulnérabilité dans le protocole UPnP affecte potentiellement des millions d’appareils

Des chercheurs ont identifié une vulnérabilité, baptisée CallStranger (CVE-2020-12695), qui affecte le protocole Universal Plug-n-Play (UPnP). La vulnérabilité est due à la valeur Callback dans le header de la fonction UPnP SUBSCRIBE, qu’un attaquant peut contrôler pour ensuite déclencher des attaques de type Server-Side Request Forgery (SSRF). La vulnérabilité permet ainsi de contourner les dispositifs de sécurité des réseaux et les DLP, exploiter tous les objets connectés intégrant le protocole UPnP et exposés sur Internet pour générer des attaques DDoS TCP réfléchies et amplifiées, ou encore de scanner les ports internes depuis les appareils intégrant UPnP et exposés sur Internet. Un attaquant peut dès lors affecter les appareils et objets connectés à Internet mais également les LAN auxquels ils sont rattachés. La vulnérabilité n’est pas sans rappeler l’attaque DDoS SSDP, mais diffère de celle-ci dans la mesure où elle scanne l’ensemble des ports ouverts et peut donc potentiellement les exploiter.

 

Une faille de sécurité dans la politique des Groupes Windows permet une élévation de privilèges

Les chercheurs de CyberArk ont découvert une vulnérabilité (CVE-2020-1317) permettant une élévation de privilèges sur un domaine Windows. Un domaine Windows permet de définir des politiques de sécurité depuis un contrôleur de domaine et de les mettre en application sur tous les postes (pc/serveurs) du domaine. En l’occurrence, sur chaque machine du domaine, le service Group Policy Client (gpsvc) va régulièrement se connecter à un contrôleur de domaine pour mettre à jour localement les politiques de sécurité. Il s’avère que ce service tourne avec les privilèges « SYSTEM », c’est-à-dire ceux équivalents à un administrateur local. Ce service écrit les politiques de sécurité dans un sous-dossier dans lequel n’importe quel utilisateur standard a des droits d’écriture. De ce fait, un utilisateur pourrait créer un lien symbolique sur un fichier utilisé par le service gpvsc vers une commande RPC qui exécute une Dynamic Link Library (DLL). Cette DLL serait donc exécutée avec les privilèges de « SYSTEM » et pourrait permettre une élévation de privilèges qui peut conduire un attaquant à compromettre un système d’information.

 

Piratage de Nintendo : plus de 300 000 comptes NNID finalement concernés

Nintendo avait annoncé en avril dernier que quelque 160 000 comptes Nintendo Network ID avaient été piratés, sans plus de précision. Deux mois plus tard, la maison mère du plombier moustachu le plus célèbre indique que ce sont finalement plus de 300 000 comptes NNID qui ont été touchés par l’attaque. Les comptes NNID étaient utilisés pour les consoles 3DS et Wii U et permettaient aux utilisateurs de l’un ou l’autre système de télécharger du contenu et de lier leurs systèmes à un portefeuille partagé. Un nouveau système de comptes utilisateurs a été déployé pour la Nintendo Switch, mais les propriétaires de 3DS et Wii U pouvaient lier leurs comptes NNID. Ainsi, les attaquants ont eu accès aux informations personnelles des utilisateurs comme à leurs portefeuilles virtuels ; Nintendo a toutefois précisé que les informations bancaires des utilisateurs concernés n’ont pas été piratées.

 

Honda frappé par le ransomware Snake/Ekans

Honda a annoncé lundi que entreprise était victime d’une cyberattaque paralysant des lignes de production dans certaines usines américaines ainsi que les services financiers et de support clients. Les serveurs internes, la messagerie et une partie du système d’information du fabricant automobile semblaient touchés par l’attaque. Les équipes de MalwareBytes ont analysé les échantillons mis à disposition et ont identifié un ransomware sensiblement similaire à SNAKE/EKANS, ransonware identifié en janvier 2020 et ciblant spécifiquement les systèmes industriels ICS/SCADA. D’autres chercheurs qui se sont penchés sur les échantillons confirment les conclusions des équipes de MalwareBytes et craignent ainsi que l’ampleur de la cyberattaque à laquelle Honda doit faire face soit bien plus importante que ce que la communication de Honda suggère.

 

L’expiration prochaine des certificats racines va rendre inopérant un grand nombre d’appareils intelligents

Afin qu’un navigateur puisse authentifier un site Web, il doit être présenté avec une chaîne de certificats valides par le serveur auquel il se connecte. Le nombre minimum de certificats dans une chaîne valide est de 3 : un certificat racine (Root Certificate), intégré dans l’OS ou le navigateur, un Certificat CA intermédiaire, et un certificat destiné aux utilisateurs finaux, présentés par les serveurs.
Le certificat d’autorité de certification racine est le cœur d’un CA et est intégré dans l’OS ou le navigateur Internet, il est physiquement présent sur votre appareil. L’autorité de certification racine émet l’autorité de certification intermédiaire, qui émet à son tour le certificat d’entité finale (également connu sous le nom de Leaf Certificate de certificat de serveur) sur votre site Web. Les certificats Leaf et Intermediate sont livrés au client à partir du serveur, et le client possède déjà le certificat Racine, de sorte qu’avec cette collection de certificats, la chaîne peut être construite et l’identité du site Web authentifiée.
Le problème est que les certificats ont une date d’expiration et doivent être remplacés. La majorité des Certificats intermédiaires ont une durée de vie de 5 ans et les certificats racines une durée de vie de 20-25 ans ; changer le certificat intermédiaire n’est pas un problème, il peut être modifié assez facilement à côté du certificat de serveur, contrairement au certificat d’autorité de certification racine. Changer l’autorité de certification racine n’est pas quelque chose que le site Web peut contrôler, c’est quelque chose qui nécessite soit une mise à jour installée sur le client, soit une mise à jour du système d’exploitation, ou une mise à jour logicielle. Or, les objets connectés, tels que les Smart TV, Smart Fridge, et tous les objets connectés intégrant un certificat racine non mis à jour régulièrement se retrouveront inopérants à l’expiration du certificat. Pourquoi s’en inquiéter maintenant ? Et bien parce que les premiers certificats racines intégrés à des objets connectés arrivent à expiration, et qu’une grande partie des OS ou logiciels déployés sur ces objets ne bénéficient plus aujourd’hui de mises à jour. Dans ces conditions, les utilisateurs risquent de se retrouver avec des objets intelligents inutilisables, non pas en raison d’une obsolescence programmée, mais bien pour des raisons basiques de sécurité.

 

Y’a plus, je laisse ?

L’application StopCovid n’a été activée que par 2 % des Français

Échec pour StopCovid. Du 2 au 9 juin, seuls 2 % des Français ont téléchargé et activé l’application. Un chiffre beaucoup trop bas pour qu’elle soit utile. Au moins 60 % de la population d’un pays doit utiliser un outil de pistage numérique de ce type pour que celui-ci puisse détecter des chaînes de contamination du virus.