.:[ d4 n3wS ]:.

Via HN :

Si vous tournez actuellement sous un NetBSD 6.0 et des poussières, il est conseillé de vous mettre immédiatement à jour car votre système et/ou vos données sont potentiellement piratables.

En effet en raison d’une bête erreur de parenthèse dans le code, le pseudo générateur d’aléa est cassé, où comme le dit l’advisory publié :

Due to a programming error, pseudorandom numbers supplied with a warning of “insufficient entropy at creation” may only contain sizeof(int) bits of cryptographic randomness.

Conclusions : passez tout de suite à NetBSD 6.1 et régénérez toutes vos clés cryptographiques (SSH, GPG, certificats & compagnie)

Via HN :

L’auteur du site Cryptocat qui permet de communiquer de façon confidentielle via un plugin de navigateur affirme sur son blog que son ordinateur portable a été backdooré par le CSIS (les renseignements canadiens).

Vrai menace ou besoin de faire le buzz une fois de plus ?
Par le passé, Cryptocat a été vivement critiqué avant d’abandonner la sécurité via javascript uniquement et beaucoup ont trouvé négatif qu’il y ait une telle attention médiatique pour un soft faillible…

Au lieu d’en parler sur son blog, l’auteur de Cryptocat ne devrait-il pas se sortir les doigts pour faire une analyse inforensique et du reverse du soit disant malware canadien ?

C’est le challenge qu’a dû surmonter Jeremiah Grossman de WhiteHat Sec et pas par plaisir.

Une mésaventure qui arrive à tout le monde : oublier son mot de passe. Et quand le mot de passe ne vous revient pas en tête après plusieurs jours, qu’il s’agit de données importantes chiffrées par FileVault avec un algo très fort il y a de quoi perdre la tête.

Heureusement d’autres experts sécu travaillant sur JtR / HashKill et avec d’importantes ressources matériel ont pu donner un coup de main.
Si le mot de passe de Jeremiah a finalement pu être cassé c’est tout de même parce qu’il s’en rappelait une bonne partie (le nombre de combinaisons a pu être fortement réduit) sans quoi même avec le matos à disposition cela aurait été impossible…

Une mésaventure qui aura profité à la communauté puisque un patch pour JtR a été fait pour l’utilitaire dmg2john.

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 !

Le buzz autour de la sortie de Mega a suscité bien des curiosités, notamment chez les chercheurs sécu qui sont allés chacun de leur critique.

Comme promis par Dotcom sur Twitter, une note de blog a été faite pour répondre à ces critiques.
Si certains points apportent une bonne clarification, d’autres explications sont moins convaincantes et d’autres restent sans réponse.

Un article de PCI passe en revu les réponses de l’équipe de Mega sur les critiques reçues.

Comme toujours avec ce type de service, le plus sûr est de chiffrer ses documents en local avant de les envoyer sur le cloud.
On peut espérer que des outils comme BoxCryptor ajouterons Mega aux services supportés.

Via Net-Security :

Des chercheurs polonais ayant analysé les communications Skype ont remarqué que les silences sont envoyés sous la forme de 70 octets contre 130 pour la voix.
Ils ont alors développé un PoC baptisé SkypeHide qui permet l’échange de données dans ces silences.

Leur programme sera présenté à une conf à Montpellier au mois de juin.

Un document de recherche qui nous vient de Stanford propose une nouvelle technique destinée à contrecarrer le filtrage des nodes Tor d’entrée, comme le font certains govs en se basant sur les listes publiques de nodes.

Cette nouvelle technique se base sur des “Flash Proxy” qui sont en réalité un morceau de code que tout le monde peut faire tourner simplement dans son navigateur (s’il support les WebSockets et Javascript).

A titre d’exemple, Bob vit à Kimland où les paquets à destination de nodes Tor sont bloquées.
Il télécharge et installe le “plugin de transport” (flashproxy-client) et l’exécute.

Ce plugin se connecte à un “facilitator”, sorte de base de données des internautes faisant tourner un Flash Proxy dans leur navigateur, en utilisant un protocole de rendez-vous spécialisé.
Le facilitator prend contact avec le navigateur d’un gentil internaute sur son Flash Proxy et lui donne l’adresse IP de Bob.
Le Flash Proxy établit une connexion avec Bob ainsi qu’une connexion avec une node d’entrée Tor et fonctionne ensuite comme un relais entre les deux.

Les deux participants profitent de l’anonymat qu’offre les 3 relais Tor utilisés ensuite dans la communication.
Bien sûr pour que ça fonctionne il faut que l’internaute ayant le Flash Proxy ne soit pas dans un pays où les communications sont filtrées.

A première vue, et sans avoir lu le document détaillé :
Avantage : comme il suffit d’un navigateur pour être Flash Proxy, on peut imaginer que le nombre de participants soit vite très élevé (beaucoup plus que le nombre de nodes Tor)
Inconvénients :
- dans quelle mesure serait-il difficile de filtrer ou surveiller les communications à destination des facilitator, via liste ou analyse réseau (DPI) ?
- le débit réseau est celui du plus faible maillon… le maillon faible peut être la connexion de l’internaute avec le Flash Proxy
- le nombre de fois où la connexion subira la fermeture d’un navigateur (efficacité ?)
- possibilités d’attaques de type MITM de la part d’un Flash Proxy ?

Les réponses se trouvent dans le document de recherche au format PDF pour les intéressés.

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

Via ISC Diary :

Le projet Honeynet a lancé un nouveau challenge orienté stéganographie.

De quoi vous occuper si vous avez terminé celui de CounterHack (hmm, quelqu’un a-t-il trouvé le pass avec stegbreak ?)

Via SlashDot :

Blake2 n’est pas une suite d’un film d’épouvante, il s’agit en fait d’une version améliorée de l’algorithme de hashage BLAKE qui était finaliste pour la compétition du SHA-3.

Cette version gagne en performances sans perdre au point de vue de la sécurité.
Les auteurs de l’algo n’hésitent pas à comparer les perfs de Keccac (le vainqueur du SHA-3) avec leur nouvelle version.

Peut-être un peu tard pour promouvoir et faire accepter BLAKE… l’avenir nous le dira.