Nous sommes aussi surpris que quiconque d’annoncer qu’un autre mois s’est écoulé. Et, bien que cela soit passé rapidement, le mois d'août était plein de nouvelles sur la sécurité. Ce mois-ci, nous allons examiner:
- Internet des objets vulnérable via des protocoles de communication non sécurisés
- Blocs de Chine TLS 1.3 et ENSI
- Vulnérabilité wolfSSL découverte
- Publication de la troisième version de la norme OASIS PKCS # 11
L'Internet des objets laissé ouvert grâce à des protocoles de communication non sécurisés
Plus de 3.7 millions d'appareils IoT (Internet des objets) ont été laissés ouverts aux attaques via deux protocoles de communication peer-to-peer non sécurisés: CS2 Réseau P2P et Shenzhen Yunni iLNKP2P.
Un article de Shaun Nichols dans Le registre entre dans les problèmes qui ont laissé des éléments tels que les webcams, les moniteurs pour bébé et d'autres appareils connectés à Internet vulnérables au détournement. Les deux protocoles sont utilisés par des millions d'appareils dans le monde, ce qui signifie que tous ceux qui souhaitent fouiner, ou pire, peuvent accéder à ces appareils.
Les bugs ont été trouvés par Paul Marrapese, qui a tout un site, caméra piratée, dédié aux vulnérabilités. `` En août 2020, plus de 3.7 millions d'appareils vulnérables ont été trouvés sur Internet '', lit-on sur le site, qui répertorie les appareils concernés et donne des conseils sur la marche à suivre si vous possédez un équipement à risque. (Résumé: jetez-le ou essayez de le désactiver.)
Bien sûr, comme le note Nichols, les vulnérabilités ne s'arrêtent pas aux appareils sur lesquels les protocoles de communication fonctionnent.
… Gardez à l'esprit que ces gadgets sont installés sur les réseaux Wi-Fi et LAN des gens, donc une fois que vous avez réquisitionné une caméra de sécurité, ou quoi que ce soit, vous pouvez atteindre les machines adjacentes pour exploiter, ou utiliser les adresses MAC du réseau sans fil à proximité pour identifier exactement emplacement du matériel à partir des bases de données de Google, etc.
Pour le plein, «et ainsi de suite», ce qui est beaucoup, nous vous recommandons de lire l'article dans son intégralité, nous conduit également à un Discussion DEFCON de Paul Marrapese qui donne un regard approfondi pour toute personne intéressée ou préoccupée par les risques de sécurité:
Les grands blocs de pare-feu TLS 1.3 et ENSI
Août a également apporté nouvelles que le grand pare-feu chinois bloque désormais HTTPS trafic qui utilise TLS 1.3 et ESNI (indication du nom du serveur chiffré). Les deux technologies rendent plus difficile pour les censeurs chinois de voir à quels sites les citoyens tentent de se connecter et pour les censeurs de contrôler l'accès à ces sites.
Un joint rapport d'IYouPort, l'Université du Maryland et le Great Firewall Report ont confirmé l'interdiction, selon un article par Catalin Cimpanu de ZDNet. L'interdiction, qui est entrée en vigueur fin juillet, autorise toujours le trafic HTTPS qui utilise des versions plus anciennes de TLS et non chiffré SNI, permettant aux censeurs du gouvernement de voir quels domaines les citoyens tentent d'atteindre.
Pour le moment, les groupes qui ont publié le rapport ont identifié six façons de contourner l'interdiction côté client et quatre façons de l'éviter côté serveur, mais le groupe et l'article de ZDNet reconnaissent que ces solutions de contournement ne sont pas une solution à long terme en tant que «jeu du chat et de la souris» entre la technologie et La censure chinoise progresse.
Vulnérabilités dans wolfSSL découvertes
Gérald Doussot du cabinet de cybersécurité Groupe de la CCN a publié un conseil technique le 24 août décrivant un TLS 1.3 Vulnérabilité dans les versions de loupSSL avant 4.5.0. La version 4.5.0 de la bibliothèque wolfSSL, contenant un correctif, a été publiée le 17 août, avant la publication de l'avis du groupe NCC, et le groupe NCC recommande aux utilisateurs de mettre à jour vers la nouvelle version sécurisée.
Selon le groupe NCC:
wolfSSL implémente incorrectement le TLS 1.3 machine d'état client. Cela permet aux attaquants bénéficiant d'une position privilégiée sur le réseau de se faire complètement passer TLS 1.3 serveurs et lire ou modifier les informations potentiellement sensibles entre les clients en utilisant la bibliothèque wolfSSL et ces TLS les serveurs.
Comme décrit sur Site Web de wolfSSL, la bibliothèque SSL embarquée wolfSSL en question «est un SSL léger, portable et basé sur le langage CTLS bibliothèque destinée aux environnements IoT, embarqués et RTOS principalement en raison de sa taille, de sa vitesse et de ses fonctionnalités. Le fait que ces vulnérabilités se trouvent sur l'Internet des objets et que les «choses» que wolfSSL se trouvent en nombre de milliards en valent la peine. Une mise à jour de la version fixe et disponible de la bibliothèque est fortement conseillée.
Publication de la troisième version de la norme OASIS PKCS # 11
Un août 19 annonce sur le blog de PrimeKey nous a informés du fait que la version 3 de l'interface de jeton cryptographique PKCS # 11 standard OASIS a été publiée en juin 2020.
PKCS # 11 existe depuis 1995 et, comme le blog lui-même le décrit, est une «API indépendante de la plate-forme pour accéder et utiliser des fonctions cryptographiques dans les modules de sécurité matérielle (HSM), les cartes à puce, les jetons USB, les TPM et autres. "
Selon Clé principale (fournisseurs du logiciel d'autorité de certification EJBCA), la norme PKCS # 11 a rencontré des problèmes de standardisation liés aux mécanismes définis par le fournisseur dans les jetons matériels qui limitent son utilité en tant qu'API standard. La version précédente de la norme a également eu du mal à suivre le rythme rapide du développement cryptographique de nos jours, donc la troisième version est un changement bienvenu et nécessaire. Comme le note le blog:
En général, cela a étonnamment bien fonctionné au fil des ans, mais il y a eu des nuances subtiles à prendre en compte lors de la tentative d'utilisation d'un nouveau jeton prétendant être conforme à PKCS # 11, provoquant des problèmes d'interopérabilité entre les clients et les serveurs.
L'ajout de nouveaux mécanismes cryptographiques standardisés dans PKCS # 11 v3.0 (y compris les signatures SHA3 et EdDSA) permettra à PrimeKey et à d'autres éditeurs de logiciels de les implémenter de manière standardisée sur les modules de sécurité matérielle et les jetons qui prennent en charge la nouvelle norme.
