Assiste.com
Faille Heartbleed OpenSSL affecte les mots de passe
Faille Heartbleed de la couche SSL de chiffrement entre clients et serveurs. Affecte tous les internautes du monde sur les sites sécurisés nécessitant identification et authentification par mot de passe, soit presque tous les sites sécurisés du monde.
cr 10.04.2014 r+ 08.08.2021 r- 20.04.2024 Pierre Pinard. (Alertes et avis de sécurité au jour le jour)
|
Dossier (collection) : Encyclopédie |
|---|
| Introduction Liste Malwarebytes et Kaspersky ou Emsisoft (incluant Bitdefender) |
| Sommaire (montrer / masquer) |
|---|
Une faille appelée Heartbleed a été découverte en 2012 et annoncée officiellement le 07.04.2014 dans l'implémentation open source de la couche SSL (Secure Sockets Layer) de chiffrement des communications entre clients et serveurs. Elle affecte tous les internautes du monde consultant un site sécurisé nécessitant une identification et une authentification par mot de passe, lorsque ce site est hébergé sur un serveur utilisant la sécurisation OpenSSL, c'est-à-dire presque tous les sites sécurisé du monde.
En sécurité informatique, un exploit est une action, selon diverses techniques, consistant à exploiter une faille de sécurité. Ne jamais perdre de vue qu'il n'a jamais existé, qu'il n'existe pas et qu'il n'existera jamais de programme 100% sans erreur (error free).
| Aidez Assiste – autorisez quelques publicités et cliquez-les |
Utilisez l'action rapide suivante pour savoir si un site sécurisé (auquel vous accédez en HTTPS et non en HTTP) sur lequel vous allez est hébergé sur un serveur affecté par la failleHeartbleed.
Faites ceci pour chacun des sites sécurisés que vous utilisez sur lesquels vous êtes obligé de vous identifier (identifiant et mot de passe) et n'utilisez plus les sites vulnérables tant que les administrateurs des serveurs qui les hébergent n'ont pas corrigé la .failleHeartbleed
Recherche de vulnérabilité Heartbleed (Heartbleed vulnerability-checking).
 Test de vulnérabilité Hearthbleed du serveur d'un domaine Le serveur d'Assiste.com n'est pas vulnérable (10.04.2014 - 22h30) En sus, Assiste.com ne vous demande jamais de vous identifier |  Test de vulnérabilité Hearthbleed du serveur d'un domaine Wikipedia.org est vulnérable (10.04.2014 - 22h30) |
| Aidez Assiste – autorisez quelques publicités et cliquez-les |
Le transport de données dans le mode client/serveur, entre le « client » (votre appareil) et le « serveur » sur lequel se trouve un site utilisé, peut être sécurisé ou non sécurisé. Le « client » (votre appareil) est essentiellement opéré par votre navigateur Web comme Firefox, Internet Explorer, Opera, Google Chrome, Safari, etc., le client de messagerie, comme Outlook Express, Outlook, Thunderbird, etc., toutes les applications communicantes, dont les applications client/serveur comme FileZilla... et toutes les technologies de votre système d'exploitation.
Lorsque vous consultez un site de recettes de cuisine, il n'est généralement pas utile de s'identifier et il n'est pas utile de sécuriser le transport de données.
Lorsque vous travaillez sur vos comptes bancaires, sur le site de votre banque, d'une administration, etc. il est indispensable de vous identifier et il est indispensable que le transport de données (les transactions entre client et serveur) soit chiffré.
Il existe donc des protocoles de sécurisation (ou non) des échanges, sur le Web (HTTP, HTTPS, FTP, FTPS, etc.), qui sont reconnus automatiquement par votre navigateur (qui vous le signale avec l'apparition d'une clé ou un cadenas fermé au début de la barre d'adresse. L'adresse elle-même de la page sécurisée commence par https:// au lieu de hhttp:// pour les transactions non sécurisées.).
Ce protocole s'appelait initialement SSL. Il s'appelle, depuis 2001, TLS (Transport Layer Security), mais SSL (Secure Sockets Layer) reste le terme employé. Un autre protocole, appelé DTLS (Datagram Transport Layer Security) est une variante de SSL.
Il existe plusieurs implémentations de SSL, dont openSSL, GnuTLS et JSSE.
Heartbleed - Faille de sécurité dans openSSL
| Aidez Assiste – autorisez quelques publicités et cliquez-les |
Les deux protocoles TLS et DTLS sont affectés par une faille découverte et annoncée publiquement le 07.04.2014. Il ne s'agit pas d'une annonce Zero Day. Cette faille existe dans plusieurs mises à jour successives d'openSSL, depuis deux ans.
Qui est affecté par la faille Heartbleed ?
La faille Heartbleed affecte tous les internautes du monde consultant un site sécurisé nécessitant une identification et une authentification par mot de passe, lorsque ce site est hébergé sur un serveur utilisant la sécurisation OpenSSL, c'est-à-dire presque tous les sites sécurisés du monde.
Toutes les données qui transitent entre votre appareil et le serveur (identifiant, mot de passe, et toutes les données, dont les numéros de cartes bancaires ou de comptes bancaires, etc.) sont chiffrées selon le protocole TLS ou DTLS. Toutes les applications de communication utilisent cette couche de chiffrement.
OpenSSL, qui est un logiciel installé côté serveur, gère le chiffrement et le déchiffrement des transactions sécurisées.
La découverte, baptisée Heartbleed (cœur qui saigne), est créditée, initialement, à Neel Mehta de Google Security. Une équipe d'ingénieurs sécurité (Riku, Antti and Matti) de Codenomicon revendique également un travail sur cette faille et la mise en place de l'outil (Heartbleed vulnerability-checking) permettant de voir si vos sites, et donc vos transactions avec ces sites, sont affectés par cette faille.
| Aidez Assiste – autorisez quelques publicités et cliquez-les |
Cette faille est d'une gravité extrême. Sur une échelle de 1 à 10, elle est classée 11.
Elle permet aux cybercriminels de pénétrer dans une zone de 64 KO de mémoire, sur les serveurs utilisant les versions 1.0.1 ou 1.0.2-beta releases d'OpenSSL (incluant les releases 1.0.1f et 1.0.2-beta1).
Dans ces zones peuvent être récupérés, en clair (après décryptage), des identifiants, mots de passe et autres données (numéros de cartes bancaires...) privées et censées être hautement protégées.
Les limites d'exploitation de cette faille sont inconnues. Les conséquences à moyen et long terme sont insoupçonnables : des certificats de sécurité eux-mêmes pourraient être compromis et leurs clés de déchiffrement, privées, pourraient avoir été accédées, ce qui rendrait le protocole TSL/DTSL inutile (les cybercriminels pourraient toujours accéder au déchiffrement, même après l'application du correctif). Or les clés privées de chiffrement représentent le Saint des Saints, le naos de la forteresse de la sécurité, celle du chiffrement. Avec ces clés, tous les trafics peuvent être lus dans le texte, y compris tous les trafics futurs.
Outre l'application du correctif de sécurité, il faudrait mettre à jour tous les identifiants/mots de passe, côté internautes, et utiliser de nouveaux certificats côté domaines (ce qui est payant).
L'attaque ne laisse strictement aucune trace. Elle peut être réitérée un nombre illimité de fois pour capturer des contenus différents dans les 64 KO de mémoire des serveurs.
| Aidez Assiste – autorisez quelques publicités et cliquez-les |
https://www.openssl.org/news/secadv_20140407.txt.
OpenSSL Security Advisory [07 Apr 2014] ======================================== TLS heartbeat read overrun (CVE-2014-0160) ========================================== A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1. Thanks for Neel Mehta of Google Security for discovering this bug and to Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for preparing the fix. Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. 1.0.2 will be fixed in 1.0.2-beta2.
| Aidez Assiste – autorisez quelques publicités et cliquez-les |
Inscription de la faille dans la BdD mondiale des CVE (http://cve.mitre.org)
L'intégralité mondiale des déclarations de failles de sécurité (les CVE - Common Vulnerabilities and Exposures) se fait dans une base de données unique : https://cve.mitre.org.
Les enregistrements se font, initialement, de manière totalement « vide » (sans aucune description) tant que la faille n'est pas corrigée afin de ne donner aucune idée aux cybercriminels. Cela permet uniquement au découvreur de la faille de fixer la date de sa découverte dans la compétition qui peut exister entre chercheurs.
Le découvreur signale de manière détaillée sa découverte aux auteurs de l'application faillible et leur laisse un délai pour développer et publier un correctif (par exemple 1, 2 ou 3 mois) en les prévenant (menaçant) de publier la faille et son mode d'emploi au-delà.
Une fois la faille corrigée, les auteurs de l'application faillible corrigée publient le/les correctifs.
Voir la liste quotidienne des alertes et avis de correctifs aux failles de sécurité.Généralement, 1 mois après la publication des correctifs, https://cve.mitre.org ajoute le détail de la faille, dont les correctifs sont censés être appliqués, au CVE.
| Aidez Assiste – autorisez quelques publicités et cliquez-les |
Concerne les administrateurs et opérateurs des serveurs concernés. Le bug étant patché, il faut :
Appliquer le patch.
Créer une nouvelle paire de clé publique/clé privée.
Mettre à jour le certificat SSL.
Changer (obliger les utilisateurs du service à changer) les identifiants/mots de passe.
| Aidez Assiste – autorisez quelques publicités et cliquez-les |
