Pour ceux qui se demandent encore si ils doivent vraiment changer leurs mots de passe suite à l'affaire Heartbleed, qui veulent comprendre pourquoi il ne fallait pas le faire trop tôt, ou qui n'ont pas vérifié si leur navigateur détecte les certificats révoqués, l'article Taxonomie des attaques Heartbleed recense et explique schématiquement les diverses attaques rendues possibles par le bug, y compris contre les logiciels clients (reverse heartbleed), Tor et les VPN.
« Heartbleed » est une des pires failles qui soient arrivées à la sécurité sur Internet. À cause d'elle, les pirates ont pu ou peuvent obtenir des données confidentielles sans avoir besoin d'intercepter les échanges. Après les premières réactions centrées sur la mise à jour des serveurs web vulnérables, la révocation des certificats et le renouvellement des mots de passe, il a fallu quelques jours de plus pour comprendre que la faille Heartbleed affecte également les logiciels clients, les échanges SSL/TLS autres que HTTPS, et une multitude d'appareils embarqués qui ne recevront jamais de mise à jour logicielle.
Plus de détails dans la suite de la dépêche.
Scénarios d'attaques et contre-mesures :
- Extraction de données sensible depuis un serveur HTTPS vulnérable
- Extraction de données d'authentification depuis un serveur HTTPS vulnérable
- Détournement de session sur un serveur HTTPS vulnérable
- Extraction de la clé privée SSL d'un serveur HTTPS vulnérable>
- Déchiffrement d'interceptions anciennes
- Déchiffrement d'interceptions récentes
- Imitation de sites sécurisés
- Extraction de données depuis un navigateur HTTPS vulnérable, par phishing
- Extraction de données depuis un navigateur HTTPS vulnérable, via des liens tiers
- Extraction de données depuis un aspirateur d'URL vulnérables
- Analyse et corrélation de trafic Tor
- Identification de serveurs cachés et d'utilisateurs par des noeuds Tor hostiles
- Attaques contre les services VPN
- Attaques contre les proxys HTTPS vulnérables
Au delà de HTTPS, de nombreux services et protocoles basés sur SSL/TLS risquent d'être touchés par la faille Heartbleed :
- le système sécurisé de noms de domaine DNSSEC ;
- des tiers de confiance d'horodatage ou de notarisation, où les clés privées sont utilisées à des fins de signature plutôt que de chiffrement ;
- des systèmes de téléchargement automatique de mises à jour de logiciels ;
- les protocoles d'authentification RADIUS, Diameter, etc ;
- le courriel avec SMTPS, POP3S, IMAPS ;
- la voix/vidéo sur IP avec SIPS ;
- des systèmes de monnaie électronique et des applications de porte-monnaie ;
- des infrastructures de développement open-source (git).
NdM : voir aussi les journaux sur l'émission 14h42, la sélection du meilleur des journalistes, le fork d'Openssl par OpenBSD, etc. Et d'autres liens comme Heartbleed : des cas français existent et les banques ne sont pas épargnées (NextINpact), HeartBleed : une chance qu'OpenSSL soit un logiciel libre ! (April). la réaction de la CNIL, les recommandations de l'ANSSI, Bug Heartbleed, vers un ralentissement mondial du Web ? (ZdNet), etc.
Aller plus loin
- Taxonomie des attaques Heartbleed (1490 clics)
- A taxonomy of Heartbleed attacks (125 clics)
# Linuxfr ?
Posté par nazcafan . Évalué à 5.
J'ai dû rater l'information, je n'ai pas vu de dépêche/journal spécifique… Linuxfr a-t-il été compromis par cette faille ?
[^] # Re: Linuxfr ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Le problème avec cette faille est que justement on ne peut pas trop savoir si on en a été victime ou pas… D'un point de vue sécurité, on peut donc supposer être dans le pire cas. Les différents serveurs (web, courriel, etc.) étaient concernés et ont été mis à jour très rapidement (informés à 23h40 le 7 avril, patch debian qui venait d'arriver déployé à 23h50, tous les services redémarrés à 0h11 le 8 avril). Ensuite il fallait attendre que les autorités de certification aient confirmé avoir patché/sécurisé de leur côté pour pouvoir réémettre des certificats. Les certificats sont à renouveler donc, et l'autre souci est le choix de l'autorité de certification à la vue des derniers changements. Tout cela a généré de longs débats internes et externes (aux JDLL notamment) sur le marigot de la certification. Je suis même étonné que personne n'ait posé la question plus tôt.
[^] # Re: Linuxfr ?
Posté par nazcafan . Évalué à 4.
On était trop occupés à faire du pop-corn pour regarder le film ; merci pour l'info en tout cas.
# Quelques âneries sur la fin
Posté par boarf . Évalué à 10. Dernière modification le 24 avril 2014 à 09:13.
Je voudrais faire remarquer qu'Heartbleed est une faille concernant uniquement la fonction heartbeat de TLS. Les fondamentaux de la cryptographie ne sont pas remis en cause.
Ça commençait bien en disant « de nombreux services et protocoles basés sur SSL/TLS risquent d'être touchés […] », la suite en revanche n'est pas correcte :
[^] # Re: Quelques âneries sur la fin
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Du coup, est-ce qu'un serveur Apache avec keep alive désactivé était vulnérable ?
[^] # Re: Quelques âneries sur la fin
Posté par Antoine . Évalué à 2.
On parle de la fonction heartbeat de TLS, pas d'un keep-alive TCP ou HTTP.
[^] # Re: Quelques âneries sur la fin
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Certes, mais si le process Apache ne garde pas le keep alive, cest peut-être un nouveau process qui répond à chaque fois, c'est un peu l'idée derrière mon interrogation.
Hearthbeat, c'est un peu comme un ping dans une connexion SSH si j'ai bien compris. D'où l'association d'idées, d'où la question.
[^] # Re: Quelques âneries sur la fin
Posté par Antoine . Évalué à 2.
Je ne pense pas qu'Apache soit assez bête pour lancer un processus neuf à chaque requête. Il y a certainement un pool de processus persistants qui traitent chacun un grand nombre de requêtes.
[^] # Re: Quelques âneries sur la fin
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Ce n'est pas forcément bête. Dans un contexte où la sécurité prime avant tout, utiliser un processus neuf à chaque requête (ou pour chaque client) pourrait se justifier. C'est une question de priorité.
Par contre ça risque de coûter cher en ressources B-)
[^] # Re: Quelques âneries sur la fin
Posté par Antoine . Évalué à 3.
Rares sont les contextes où la sécurité prime avant tout. Je suis sûr que même OpenBSD évite d'activer des garde-fous qui diviseraient les performances par un nombre entier supérieur à 1.
[^] # Re: Quelques âneries sur la fin
Posté par pabr . Évalué à 2.
Merci pour ces commentaires qui seront pris en compte dans la prochaine version du document.
En effet DNSSEC n'a pas sa place dans la dernière section, même si on peut raisonnablement imaginer que certaines implémentations aient des interfaces d'administration sur TLS (mais ce n'est apparemment pas le cas de bind).
Concernant les service d'horodatage, le risque est qu'une attaque sur un point d'accès sur TLS permette d'extraire des clés de signature. Tous ces scénarios avec potentiellement des fuites massives de clés privées diverses sont relativement nouveaux en matière de sécurité sur Internet.
Je crois qu'il existe une variante de RADIUS sur TLS (RFC6614). Evidemment, seules sont concernées les configurations avec TLS activé, avec une version vulnérable de OpenSSL, compilées sans l'option OPENSSL_NO_HEARTBEATS, et même dans ce cas on ne sait pas ce qui risque réellement de fuiter. Idem pour les VPN qui utilisent généralement IPSec plutôt que TLS. Toute cette section reste purement spéculative en l'absence d'attaques avérées.
J'aurais pu mentionner aussi les systèmes de vote électronique puisque les Français résidant à l'étranger ont semble-t-il pu voter par Internet aux législatives de 2012: http://www.numerama.com/magazine/29073-vote-par-internet-et-faille-heartbleed-faites-vous-encore-confiance.html
[^] # Re: Quelques âneries sur la fin
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Quelques infos sur le système utilisé pour le vote par internet aux législatives de 2012 et aux partielles de 2013 (où j'étais délégué du Parti Pirate auprès de l'unique (Paris, Ministère des Affaires étrangères) bureau de vote électronique
Il sera utilisé pour les européennes en mai aussi (dans le contexte Heartbleed et sortie de Java 8 donc).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.