.:[ d4 n3wS ]:.

Via TheRegister :

Dernièrement on s’est habitué à voir des autorités de certification piratées, des grosses gaffes, des govs qui s’approprient des certificats etc.

Cette fois ça va encore plus loin : il n’y a pas eu de piratage mais un certificat valide a été donné à une entreprise fictive brésilienne se faisant appeler Buster Paper Comercial Ltda.
Ce certificat a ensuite été exploité pour signer des malwares (PDF piégé).

D’après l’autorité de certification qui a généré ce certificat, DigiCert, tout a été fait dans les règles de l’art.
Bref un certificat ça vaut plus rien !

Encore un coup dur pour le système de certificats SSL/TLS actuel :

Google a détecté dans la journée du 24 décembre l’existence d’un certificat frauduleux pour les domaines *.google.com.
En effet ce certificat n’a pas été créé par Google mais est valide dans le sens où il a été créé par une sous-autorité de certification dépendant d’un CA considéré sûr jusqu’à présent.

A l’origine de ce merdier se trouve l’autorité de certification TURKTRUST. Elle aurait issue par erreur (d’après TURKTRUST) deux certificat d’autorité de certification au lieu de deux certificats simples pour le gouvernement turc (*.EGO.GOV.TR et e-islem.kktcmerkezbankasi.org).
Ces deux certificats ont ensuite permis de créer un certificat frauduleux pour *.google.com.

A l’heure actuelle très peu d’infos sont disponibles sur le sujet. On ne sait pas si c’est un coup du gov turc, si l’erreur de TURKTRUST n’est pas volontaire etc.
Les sous-certificats (*.EGO.GOV.TR et e-islem.kktcmerkezbankasi.org) font bien sûr être bannis par les différents navigateurs mais on ne sait pas si TURKTRUST aura une punition pour cette erreur…

L’article de KrebsOnSecurity, l’article de ZeroDay

Le hack de DigiNotar par le “Comodo Hacker” remonte à fin aout 2011 (date des premières découvertes).

Mais le rapport final rendu par Fox IT sur l’analyse de ces intrusions est téléchargeable depuis peu.
On y découvre que le pirate avait bien plus d’accès que ce qui était imaginé précédemment et que son intrusion a duré environ 6 semaines.

Fox IT a fait un sacré boulot : le rapport PDF fait 100 pages.

Via HackerNews :

Sous ce titre alarmant se cache une étude menée par les Universités de Stanford et du Texas :
The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software

Le document PDF de 12 pages relève les erreurs d’utilisations de différentes librairies et API SSL qui rendent possibles les attaques MITM.
On découvre que même des librairies très utilisées comme CURL et OpenSSL sont souvent mal utilisées. Sans doute un must-read pour les développeurs qui ont à faire du SSL dans leur code.

Adobe a eu connaissance de l’utilisation de certificats leur appartenant et qui ont servi à signer un exécutable pwdump7 ainsi qu’un filtre ISAPI malicieux (peut-être un passlogger ou un injecteur de code html ?) pour IIS.

Adobe a commencé ses investigations et a déjà découvert que l’un de ses serveurs avait été compromis.

Dans cet article d’ArsTechnica vous saurez ce qu’il y a à savoir sur CRIME et vous pourrez même le voir à l’œuvre dans une vidéo.
La nouvelle information à prendre en compte c’est que au delà de la compression DEFLATE utilisée sous SSL/TLS, celà concerne aussi le protocole SPDY qui compresse les données.

L’article indique bien que ce type d’attaque est difficilement à la portée du “petit hacker” mais risque d’être exploité par des pays comme l’Iran.

Déjà discuté sur IT Security Stack Exchange, la supposition que l’attaque CRIME (qui doit être présentée prochainement à la EkoParty) se base sur la compression des données se vérifie.

En effet, Google a fait un patch pour son navigateur avec pour seule description

net: disable TLS compression with OpenSSL

C’est pas gentil pour les deux chercheurs qui comptaient sans doute faire du bruit avec leur présentation…

(à lire avec une voix du type bande annonce de Expendables 2 pour plus d’effet)

Un an après, ils reviennent et ils comptent bien remettre TLS dans les choux.

Les deux chercheurs à l’origine de BEAST avaient forcé les navigateurs à se patcher suite aux révélations faites il y a un an à la Ekoparty 2011 en Argentine.
Pour la Ekoparty de cette année, ils sont de retour et ils vont présenter CRIME. A lire les infos qui sont publiques pour le moment, la méthodologie semble similaire et repose sur des faiblesses cryptographiques de TLS.

Sauf que là, TLS 1.2 serait aussi concerné. C’est le retour de la vengeance !

A suivre…

 
Via SANS :

Microsoft a publié un advisory avertissant que des certificats délivrés par une autorité de certification dérivée ont permis de signer certains composants du ver Flame…
Du coup MS a du fournir en urgence un patch pour révoquer 3 autorités de certifications considérées comme compromises.

Va y avoir du sport troll

Nouvelle version disponible.

SSLsplit is a tool for man-in-the-middle attacks against SSL/TLS encrypted network connections. Connections are transparently intercepted through a network address translation engine and redirected to SSLsplit. SSLsplit terminates SSL/TLS and initiates a new SSL/TLS connection to the original destination address, while logging all data transmitted. SSLsplit is intended to be useful for network forensics and penetration testing.

Site officiel