Semaine des bonbons effrayants : KRACK et ROCA
Ce que vous devez savoir et ce que vous devez faire
Ce n’est pas une coïncidence si Halloween tombe en octobre. Nous, les humains, ressentons une peur accrue à cette période de l’année ; c’est une sorte de réponse vestigiale au raccourcissement des jours. Quel mois a connu le plus grand nombre de krachs boursiers inexpliqués à Wall Street ? Octobre. Si Halloween n’avait pas eu lieu à l’origine en octobre, nous l’aurions déplacé à un endroit où cela nous semblait plus naturel. Octobre est également le mois de la sensibilisation à la cybersécurité.
C'est donc doublement parfait que cette semaine nous n'ayons pas eu une horrible vulnérabilité de protocole du type « OMG, Internet est cassé ! », mais deux vulnérabilités du type « OMG, Internet est cassé ! ». Sortie le même jour, rien de moins, soit le lundi 16 octobre.
Ce qui est encore pire, c’est que les vulnérabilités pourraient s’accumuler les unes les autres de manière horrible, comme vous le verrez.
CRACK: Key Reinsertion Attaccusé de réception contre le WiFi WPA2
Le chercheur en sécurité belge Mathy Vanhoef a publié une attaque contre les clients WiFi utilisant le protocole d'authentification WPA2. Le client cible peut être amené à rejoindre un réseau Wi-Fi dupliqué, puis contraint d'installer une clé de chiffrement nulle (vierge), permettant ainsi à l'attaquant d'adopter une position d'homme du milieu.
Vanhoef explique succinctement l'attaque KRACK sur le site de vulnérabilité de marque et de logo krackattacks.com . Nous vous encourageons vivement à regarder la courte vidéo réalisée par Vanhoef démontrant l'attaque.
Une fois que l'attaquant a atteint la position intermédiaire entre le client et le point d'accès, il peut utiliser le bon vieil outil sslstrip pour tromper le navigateur client afin qu'il envoie des mots de passe en clair. L'exemple utilise les identifiants match.com (pour le plaisir), donc Vanhoef vient de vous donner tout ce dont vous avez besoin pour espionner les habitudes de rencontres de votre ex. Juste à temps pour Halloween ! [On plaisante, ne faites pas ça.]
Le lecteur astucieux pensera : « Hé, les réseaux non sécurisés sont la raison pour laquelle nous avons une protection SSL ! Donc nous sommes toujours en sécurité, n’est-ce pas ?
Eh bien, l’autre vulnérabilité effrayante publiée, par coïncidence, le même jour que KRACK, concerne les clés faibles générées à partir de périphériques cryptographiques hautement sécurisés. Waouh !
ROCA – Le retour de l’attaque de Coopersmith (CVE-2017-15361)
La dernière vulnérabilité SSL/TLS est ROCA – le retour de l'attaque de Coppersmith. Ars Technica a le meilleur article que nous ayons vu à ce jour sur la portée et l'impact du ROCA. ROCA affecte la génération de clés RSA publiques/privées effectuée dans des conditions de temps limitées où le logiciel Infineon tente de prendre un raccourci appelé « fast prime » pour approximer deux grands nombres premiers.
ROCA affecte les logiciels associés aux chipsets Infineon qui sont souvent utilisés dans les cartes à puce et les environnements embarqués à haute sécurité (informatique de confiance). Comme nous sommes en octobre, ces chipsets se trouvent bien sûr dans du matériel certifié FIPS 140-2 et CC EAL 5+, deux solutions pour lesquelles vous payez des dizaines de milliers de dollars pour garder vos clés privées, eh bien, privées. Le bug d'Infineon fait que la clé privée est pratiquement factorisable une fois qu'un attaquant connaît la clé publique (ce qui est presque toujours le cas, car elle est publique et intégrée dans des certificats, etc.).
Il en coûterait à un attaquant entre 20 000 et 40 000 dollars en temps CPU pour factoriser votre clé privée de 2 048 bits. Cependant, si l’agresseur est un État-nation, cela ne constitue pas un moyen de dissuasion important pour lui. Le coût de factorisation d’une clé de 1024 bits n’est que d’environ 50 $, soit le prix de deux bières à un match des Yankees. Selon les propres recherches de F5 Labs, seulement 7 % d’Internet utilise encore des clés aussi petites. Les attaques comme ROCA sont exactement la raison pour laquelle nous sommes tous passés à la version 2048 bits, n’est-ce pas ? Tant mieux pour nous. Les clés ECC ne sont pas vulnérables.
Jusqu’à présent, la grande majorité des clés vulnérables sont associées à des cartes à puce, mais les chercheurs ont trouvé une poignée de clés TLS et Github vulnérables. On ne sait pas encore grand chose sur les clés DNSSEC 1024 bits vulnérables ; ce serait terrible, car les attaquants pourraient alors signer leurs propres données de zone malveillantes.
Il est intéressant de noter qu’il est pratiquement gratuit et instantané de vérifier si une clé est vulnérable au ROCA. Si les modules de clé publique sont conformes à 38 petits nombres premiers d'une certaine manière, alors ils sont probablement vulnérables. Les chercheurs du ROCA ont fourni des outils en ligne et hors ligne pour vous permettre de vérifier vos clés SSL/TLS, IPSec et SSH.
Étant donné la facilité avec laquelle il est possible de vérifier la vulnérabilité, nous prévoyons que les navigateurs vous avertiront bientôt si vous visitez un site utilisant une clé vulnérable au ROCA. C'est nous qui vous l'avons annoncé en premier.
Attaque KRACK + ROCA : Quel est le pire scénario ?
C'est comme écrire un scénario de film d'Halloween. Imaginez que vous êtes dans un environnement de haute sécurité (bureau de gestion des espions). Vos ennemis sont les pires ennemis du monde ; pensez à S.P.E.C.T.R.E. ou similaire.
L’un de vos agents connecte son ordinateur portable Windows 10 au réseau sans fil de votre bureau d’Istanbul. Il ne sait pas qu'un agent anti-S.P.E.C.T.R.E. usurpe le Wi-Fi et envoie des balises de canal CSA à son ordinateur portable. En quelques secondes, l’ordinateur portable de votre agent est acheminé via le point d’accès des contre-agents. Votre agent active son SSL/VPN (pas celui de F5 malheureusement) pour accéder à certaines données d'entreprise top secrètes au siège.
Le contre-agent a déjà utilisé ses capacités d’État-nation pour extraire la clé privée SSL/VPN de la vulnérabilité ROCA. Il peut décrypter tout ce que votre agent télécharge depuis le serveur top secret. De plus, l’agent du comptoir obtient le mot de passe match.com de votre agent !
Pensez-vous que ce pire scénario ne pourrait pas se produire ? Des choses encore plus étranges se sont produites. [toux, <stuxnet>, toux, <bleu éternel>].
KRACK et ROCA: Êtes-vous vulnérable?
Matériel et logiciel F5 Networks : Pas vulnérable. F5 n'est pas dans le secteur du sans fil. Bien qu'il soit théoriquement possible d'utiliser notre plateforme TMOS comme point d'accès, personne ne le fait, Dieu merci. Pour KRACK, consultez la déclaration officielle KRACK de F5 Networks SIRT.
F5 Networks est définitivement dans le secteur des clés SSL/TLS. Là encore, les équipements et logiciels F5 ne sont pas vulnérables. Nous utilisons les chipsets Infineon dans quelques appareils, mais nous n’utilisons pas sa génération clé. Voir la déclaration officielle ROCA de F5 Networks SIRT.
Votre équipement (KRACK) : Vulnérable, mais… KRACK attaque le côté client d’une connexion WiFi. Donc, dans un sens, cela n’a pas vraiment d’importance que vos points d’accès soient corrigés ou non. Convenons que vous devez de toute façon patcher vos points d’accès (bonne pratique de sécurité), mais cela ne protégera pas vos utilisateurs de KRACK. Il n’est pas nécessaire de modifier vos mots de passe Wi-Fi WPA2 ; ils n’ont jamais fait partie du problème et leur modification n’aura aucun effet.
Votre équipement (ROCA) : Idéalement, vous devriez connaître chaque certificat SSL/TLS associé à votre entreprise. Nous disons « idéalement » car c’est rarement le cas ; les unités commerciales apportent désormais en permanence leurs propres certificats. Si vous disposez d'une solution de gestion de certificats robuste et complète, vous êtes probablement déjà au courant de tout cela. Dans le cas contraire, Venafi , partenaire de F5, peut analyser votre réseau à la recherche de clés SSL/TLS. Si vous devez rechercher rapidement des certificats, accédez à la base de données du projet Certificate Transparency ( crt.sh ) et recherchez les certificats de votre organisation. Utilisez ensuite les outils de test ROCA pour voir si ces clés publiques sont vulnérables.
Vos employés. Apple a corrigé iOS et MacOS dans un correctif furtif il y a quelques versions (ils ne disent pas encore lequel). Les clients Android et Linux semblent être les plus vulnérables. Les clients Microsoft sont également vulnérables. Votre priorité absolue pour KRACK devrait être vos employés.
Solutions F5 pertinentes
Pour les clients F5, il existe deux solutions de sécurité pertinentes contre KRACK et ROCA. La première s'effectue via le gestionnaire de trafic local BIG-IP (LTM) de F5, le module principal qui effectue le décryptage SSL/TLS et l'équilibrage de charge. Les clés LTM ne sont généralement pas vulnérables au ROCA (sauf si elles ont été générées ailleurs et importées dans LTM ; voir ci-dessous pour les informations de test).
LTM peut appliquer HTTP Strict Transport Security (HSTS), qui demandera à tous les navigateurs d'utiliser toujours SSL/TLS lors de la connexion à vos applications. C'est une case à cocher. Vérifie-le. Le HSTS à lui seul atténuera les pires aspects du KRACK.
La deuxième défense, plus complexe, est BIG-IP Access Policy Manager (APM) et son produit de point de terminaison associé, le BIG-IP Edge Client. Ensemble, ils créent un VPN SSL/TLS sécurisé doté d'une protection des points de terminaison et d'un moteur de politique sophistiqué pour garantir que vos employés se connectent aux ressources de l'entreprise en toute sécurité. Il prend en charge toutes les plates-formes populaires - Android, Windows, iOS et MacOS. APM dispose également d'une fédération, vous bénéficiez donc du SSO gratuitement.
Les utilisateurs de certains environnements de haute sécurité peuvent disposer des produits F5 WebSafe et MobileSafe. WebSafe sécurise les transactions devant un serveur. Ce dernier est une API de boîte à outils mobile permettant de créer des applications plus sûres qui se connectent au premier. La protection la plus pertinente que ces deux solutions peuvent offrir est le chiffrement de la couche application (ALE). ALE utilise des clés RSA temporaires pour crypter de manière asymétrique les mots de passe des utilisateurs avant qu'ils ne soient envoyés sur le réseau. MobileSafe fournit également une fonction de protection contre l'usurpation d'identité DNS qui devrait aider à contrecarrer l'attaque Man-in-the-Middle fournie par KRACK.
- Fiche technique WebSafe
- Fiche technique de MobileSafe
Votre liste de choses à faire pour Halloween
En plus de choisir votre tenue d'Halloween (suggestion : le Kraken pourrait être de mise cette année), vous avez quelques éléments à ajouter à votre liste de choses à faire pour KRACK et ROCA.
- Doublez votre solution SSL/VPN. Si votre appareil actuel ne dispose pas d’authentification multifacteur (MFA), remplacez-le par un appareil qui en dispose. L'authentification multifacteur empêchera les attaquants d'utiliser les informations d'identification compromises via KRACK pour accéder aux services de l'entreprise.
- Activez HTTP Strict Transport Security sur votre gestionnaire de trafic local F5 pour lutter contre l'outil sslstrip. Ouvrez un ticket auprès de votre équipe réseau si ce sont eux qui le prennent en charge (très probablement).
- Pour les clients WebSafe, activez le chiffrement de la couche d’application pour les champs sensibles de vos applications Web critiques.
- Pour les clients MobileSafe, implémentez la détection d’usurpation DNS et la validation des certificats.
- Auditez les certificats de votre organisation pour détecter la vulnérabilité ROCA. Utilisez Venafi ou un autre scanner de certificat SSL si nécessaire.
- Consultez la base de données du projet Certificate Transparency ( crt.sh ) pour connaître les certificats émis pour votre organisation.
- Déployez les correctifs du système d’exploitation sur les ordinateurs portables et les téléphones portables des employés.
- Expirer les mots de passe des utilisateurs. Supposons que leurs mots de passe aient pu être compromis, en particulier pour les utilisateurs d’Android ou tout utilisateur invoquant le protocole « ActiveSync ».
Notre site de renseignement sur les menaces, F5 Labs , et notre communauté de développeurs, DevCentral , continuent d'examiner ces sujets et mettront à disposition des documents supplémentaires si nécessaire. Si vous avez d'autres questions sur les deux vulnérabilités ou sur l'une des solutions dont nous avons parlé ci-dessus, n'hésitez pas à contacter un représentant F5 .
Dans le même ordre d'idées, l'équipe DevCentral de F5 a publié une vidéo expliquant plus en détail la vulnérabilité KRACK, et des commentaires supplémentaires sont disponibles dans la publication suivante de F5 Labs : Une nouvelle menace pourrait passer à travers le KRACK des politiques BYOD