Voilà comment le trafic chiffré peut être analysé en interposant un man-in-the-middle

La nouvelle version de Burp Proxy est conçue pour améliorer l'analyse des connexions SSL chiffrées sur les smartphones Android. A ses débuts, Burp Proxy était utilisé par les développeurs et les chercheurs en sécurité pour examiner le trafic web sur PC mais maintenant il est aussi possible de le faire sur n'importe quel smartphone. Par exemple pour analyser le comportement de diverses applications du smartphone.

Pour analyser le trafic web, le serveur Burp est entré comme proxy pour les connexions HTTP et HTTPS sur le périphérique, et un certificat CA auto-signé est installé. Ce certificat CA permet à Proxy Burp de générer à la volée des certificats afin d'imiter un serveur HTTPS et agir comme un man-in-the-middle.

Cependant, le problème avec les smartphones Android c'est que le périphérique récupère d'abord l'adresse du serveur cible via le DNS puis utilise le proxy pour y accéder directement en utilisant la requête CONNECT. Comme Burp ne connait pas le nom du serveur lors de la génération du certificat, il utilise l'adresse IP du serveur comme nom, ce qui provoque des messages d'erreurs ou coupe la connexion sur le smartphone. La nouvelle version 1.4.12 par contre établit d'abord une connexion SSL au serveur cible et imite au mieux le certificat du serveur.

L'équipe de développement du projet OpenVAS a annoncé la sortie de la version 5 de son système vulnerability assessment (ou évaluation de vulnérabilités) open-source.

Selon les développeurs, cette mise à jour majeure met l'accent sur la simplification des analyses de vulnérabilités quotidiennes et des outils de gestion. Elle apporte également son lot de nouveautés avec 20 nouvelles fonctionnalités, y compris un asset management qui montre d'un autre oeil les résultats d'analyse. Cela permet aux utilisateurs d'examiner ces résultats sur des machines spécifiques d'un réseau.

La version 5 de la plateforme logicielle OpenVAS introduit le support des paramètres utilisateurs, y compris les fuseaux horaires et des rapports "delta" de telle sorte que les utilisateurs puissent analyser les différences entre deux résultats d'analyse.
Une bonne chose également est la mise en place d'un SCAP (Security Content Automation Protocol) qui manquait cruellement et qui a été ajouté à la base de données sécurisée et peut être mise à jour via plusieurs flux. D'autres changements inclus la capacité de trier les résultats par score CVSS et supporte l'utilisation de clés SSH.

La liste complète des changements peut être trouvée sur l'annonce officielle de la sortie de cette version 5. Les codes source et binaires d'OpenVAS sont disponibles en téléchargement depuis leur site. A l'heure où j'écris ces lignes, la Virtual Appliance n'a pas encore été mise à jour vers la version 5 mais ça ne saurait tarder

Pour ceux qui me lisent assez régulièrement, vous allez me dire : "Mais quelle rigolade!".
Pour mes nouveaux/récents lecteurs qui n'ont pas tout compris, Oracle a connu récemment une vulnérabilité sur son système de bases de données et suite à ça, Oracle a fait une annonce dans laquelle il offre le support SSL pour ses clients.

Un article sur leur blog explique pourquoi la société a fait cette annonce, Oracle Security Alert for CVE-2012-1675 distingue deux types supports. L'un pour les clients sans Oracle Real Application Clusters et un pour ceux avec Oracle RAC.

Pour ceux sans RAC, Oracle recommande de limiter les inscriptions de nouveaux listeners et des protocoles IPC. Toutes les instructions sont fournies dans l'annonce d'Oracle : Using Class of Secure Transport (COST) to Restrict Instance Registration.

Pour ceux avec RAC ou Exadata, le problème est un peu plus complexe et l'utilisation de COST signifie dans ce cas la mise en place du SSL/TLS comme indiqué dans Using Class of Secure Transport (COST) to Restrict Instance Registration in Oracle RAC. Le problème est que l'utilisation de SSL/TLS est vendu pour un coût supplémentaire non négligeable. Mais maintenant (et ça aurait dû être le cas dés le début...), Oracle a mis à jour sa licence afin que les clients puissent utiliser le SSL/TLS afin de se protéger contre cette vulnérabilité.

Avec le changement de licence et la disponibilité du workaround (solution de contournement) efficace, il est peu probable qu'Oracle mette en place un patch pour ses base de données d'ici peu de temps. Le problème affecte actuellement les base de données Oracle 11gR2 11.2.0.2 et 11.2.0.3, 11.1.0.7 11gR1, et 10g 10.2.0.3, 10.2.0.4 et 10.2.0.5. Les utilisateurs de Oracle Fusion Middleware, Enterprise Manager ou E-Business Suite devraient également prendre note de cette vulnérabilité, car ces produits incluent le système de base de données d'Oracle.

Le Trustworthy Internet Movement (TIM) (ou Mouvement de confiance du Net) a lancé Pulse SSL, un tableau de bord en "temps réel" dans le cadre d'une initiative visant à améliorer la qualité des implémentations SSL en cours d'utilisation sur le web. Le TIM est une associaction à but non lucratif lancée par le président de Qualys, Philippe Courtot, en Février lors de la conférence RSA. Dans sa prochaine étape, il a décidé de créer un groupe de travail appelé "TIM SSL Taskforce" pour avoir un oeil sur la mise en oeuvre du protocole SSL à travers Internet. Ce groupe de travail comprend :

• Michael Barrett, une pointure de la sécurité chez Paypal.
• Taher Elgamal, un sacré cryptographe et l'un des créateurs du protocole SSL
• Ryan Hurst, directeur technique de GlobalSign
• Adam Langley, ingénieur chez Google trvaillant sur le protocole SSL/TLS sur Chrome
• Moxie Marlinspike, fondateur Whisper Systems (récemment acquis par Twitter) et créateur de Convergence.
• Et Ivan Ristić, directeur de Qualys et créateurs des labs SSL.

Autant vous dire que c'est un sacré gratin! Cette équipe fournira des critiques objectives et des propositions pour résoudre les problèmes qui entourent les écosystèmes SSL et autorités de certification (CA).

Le projet SSL Pulse, créé par Ristić, traque déjà prés de 200.000 sites web du haut de la liste d'Alexa et évalue la mise en œuvre du SSL régulièrement. Environ la moitié des sites obtiendront un grade A, tandis que les autres pourraient revoir la configuration de leur système.

Dans son blog, Ristić dit que c'est un bon résultat car les enquêtes précédentes rapportées seulement 33% de sites bien configurés et il suggère que les sites les plus populaires soient mieux configurés. Parmi les sites de grade A, 8.5% supportent encore la renégociation d'insécurité et 72.4% sont toujours vulnérables à l'attaque BEAST (rappelez-vous de l'histoire avec Paypal) malgré des solutions envisageables. Au final, seul 9.6% de tous les sites sont "véritablement sécurisés à ce niveau d'analyse".

Voilà c'est fait, Twitter vient d'annoncer que le protocole HTTPS serait activé par défaut pour tous les utilisateurs connectés.

En utilisant ce protocole, toutes les informations transmises aux serveurs tel que les informations d'identification lors de la connexion, se feront via le chiffrement SSL. En gros cela signifie que toutes les données seront transmises sous une forme chiffrée afin de ne pas être lues ou exploitées par des pirates.

Utiliser le protocole HTTPS sur Twitter était bien sûr déjà possible avec l'option Always use HTTPS disponible depuis Mars 2011 mais il fallait l'activer. Un peu plus tard en Août 2011, Twitter a commencé à mettre cette option par défaut pour certains utilisateurs. Pour ceux qui ne souhaitent pas utiliser le protocole HTTPS, vous pouvez toujours le désactiver en vous rendant sur la page des paramètres du compte puis en décochant Toujours utiliser le HTTPS.

Si vous voulez plus d'informations sur la protection de votre compte, il y a un billet sur le centre d'assistance de Twitter.

Et en ce qui concerne les concurrents de Twitter, il y a par exemple Google qui a déjà mis en place le protocole HTTPS par défaut pour ses services depuis le mois d'octobre 2011. Pour Gmail ça remonte à Janvier 2010. Voilà pour la petite histoire