{"partition": "head_middle", "source_domain": "exploitability.blogspot.com", "digest": "sha1:P7B5BR5GPFN3W44KNTHIDBOEYZ6VCNDN", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2016-26/000_00046.parquet"}
Exploitability
Le sujet à la mode dont on parle en ce moment concerne google.Scoop, ils se sont fait inflitrer par des pirates chinois. On en a entendu parler jusque sur TF1, et même le gratuit donné dans le métro le matin comportait un article sur la question.Abandonnons un peu le monde journalistique toujours prompt aux grands titres et aux raccourcis rapides. Que s'est il passé? Tout d'abord, l'article de google lui-même:http://googleblog.blogspot.com/2010/01/new-approach-to-china.htmlOn apprend simplement que google s'est fait pirater, qu'ils sont suffisement sûrs de la provenance des attaques pour incriminer directement la chine. L'affaire semble suffisement grave pour qu'ils menacent de se retirer du pays. Sur l'attaque en elle-même, rien si ce n'est quelques mots sybillins: "In mid-December, we detected a highly sophisticated and targeted attack". Mais pas grand chose de plus.Quelques recherches faites sur internet m'ont mené à un rapport du Northrop Grumman: NorthropGrumman_PRC_Cyber_Paper_FINAL_Approved Report_16Oct2009.pdfCe rapport mentionne que les chinois deviennent de plus en plus fort et développent eux-mêmes leurs propres exploits. Ils sont dans la capacité de mener des cyber-attaques. Les moyens évoqués: l'envoi ciblé de mails contenant une pièce jointe avec une charge offensive.Parrallèlement, on lit sur d'autres blogs que l'attaque s'est produite à l'aide de mails ciblés utilisant une faille d'un format de document largement répandu; on soupçonne immédiatement le pdf.Adobe, de son côté, publie plusieurs failles de sécurité. Mais microsoft publie également de son côté des advisories: http://blogs.technet.com/msrc/archive/2010/01/14/security-advisory-979352.aspx.Je suis surpris du battage médiatique fait autour de cette attaque. De deux choses l'une. Soit l'attaque a été particulièrement violente et nous n'en avons pas encore entendu parler (j'en suis d'ailleurs fort curieux). Est-ce que google s'émouvrait du fait qu'ils se fassent attaquer par une attaque d'envoi de mail ciblés suivis de troyens? C'est même la première ligne de leur message de blog. La seconde option consiste a penser qu'il s'agit plus d'un coup médiatique reposant sur un pseudo non-évènement. Google s'est fait attaquer, ainsi que quelques compagnies américaines. Il ne s'agit que d'un prétexte pour mener une politique. Mais cette option m'intéresse beaucoup moins :-) Peut-être verrons nous bientôt l'attaque "highly sophisticated" publiée.EDIT: 18/01/2010Pour ceux qui n'auraient pas suivi les dernières annonces, c'est apparemment une faille 0-day sur IE qui a été utilisée contre Google (et d'autres sociétés comme Adobe)Faille IE exploitable sur IE6, 7 et 8 (rien que ça...) : http://isc.sans.org/diary.html?storyid=7993Les gouvernements allemands et français (via leur agence spécialisée) ont d'ailleurs publié une alerte déconseillant fortement d'utiliser IE jusqu'à correction de la faille : http://www.zdnet.fr/actualites/informatique/0,39040745,39712274,00.htm
mardi 12 janvier 2010
SSL/TLS: fiable ou faible?
Le SSL/TLS est une manière particulièrement efficace pour protéger les communications sur internet. L'application de SSL/TLS la plus connue est HTTPS.Je propose un petit tour d'horizon sur la sécurité liée à SSL/TLS en me basant quasi essentiellement sur l'application de ce protocole sur HTTPS. Les conclusions restant généralement vraies pour les autres protocoles (IMAPs, POP3s, etc..).L'échange HTTPS permet d'une part de chiffrer la communication entre un serveur et un client, d'autre part d'authentifier le serveur distant, et éventuellement d'authentifier le client (Par exemple, le site des impots français authentifie le client distant).Les pirates souhaitant accéder à des informations protégées par SSL/TLS ont donc deux moyens; s'attaquer à HTTPS tout d'abord, ensuite chercher à contourner HTTPS.1/Attaquer HTTPSUne communication chiffrée HTTPS débute par un échange cryptographique (RSA ou DiffieHelmann) permettant d'échanger une clé de chiffrement symétrique.Un pirate peut s'attaquer au protocole de chiffrement symétrique. Généralement, il s'agit d'AES. Le brute force sur AES est ajourd'hui hors de portée. Un calcul rapide mettant en oeuvre 1 milliards de machines, 32 cores à 30GHz, sachant calculer un bloc par cycle (ce qui dans l'ensemble semble exagéré) mettra à peu près 6 milliards d'année pour tester 2^127 clés AES.La cryptanalyse actuelle indique une baisse de niveau d'AES-256 à 2^119 et AES-192 à 2^176. AES-128 n'est pas touche.L'autre option consiste donc à attaquer le RSA afin de déchiffrer cette clé symétrique. Les clés RSA font aujourd'hui au minimum 1024bits, et la plupart 2048bits. Le site des impôts cité plus haut utilise une clé publique de 2048bits.Le 12 janvier 2010, un groupe de recherche explique avoir réussi un challenge consistant à casser une clé RSA-768. Contrairement à ce qu'on a pu lire, RSA-768 n'est pas cassé, pas plus que RSA, c'est seulement une clé qui a été cassée. La clé se lit ici. Il a fallu deux ans et demi de calculs pour parvenir à ce résultat. Même si la loi de Moore veut que les machines calculent de plus en plus vite, je pense qu'une clé de 2048 permet d'être tranquille un certain temps. Le site keylength donne les tailles de clés nécessaires selon une durée de conservation souhaitée.D'autres méthodes permettant de casser plus rapidement une clé RSA existent, néanmoins, elles imposent un accès privilégié au CPU afin de pouvoir le monitorer pendant le calcul RSA.La solidité de RSA repose sur l'impossibilité de factoriser facilement un très grand nombre, problème mathématique qui n'est toujours pas résolu.Toutefois il a existé quelques temps une attaque protocolaire sur SSL/TLS, basée sur la renegociation des clés de session. J'avais blogué sur celle-ci. C'est aujourd'hui corrigé par une RFC.2/ Contourner HTTPSLe pirate va donc s'ingénier à contourner HTTPS s'il veut accéder aux informations souhaitées. Et là, il existe plusieurs méthodes efficaces.Tout d'abord, le pirate peut tenter des attaques en deux temps. Tout d'abord il peut compromettre le poste client, lui faire ajouter dans son navigateur des Browser Helper Object. Ces BHO vont ajouter dans des formulaires bancaires d'autres champs demandant le numéro de carte bancaire, date de péremption etc.. afin de les renvoyer vers le pirate. Les utilisateurs sont peu méfiants, ils sont bien sur le site de la banque, HTTPS est fonctionnel. (Je n'ai plus l'URL montrant ces attaques, un botnet l'utilisait comme charge active).Ensuite, le pirate peut attaquer le serveur et casser le générateur aléatoire. Les clés de chiffrement symétriques sont générés aléatoirement. Si elles ne le sont pas, un pirate pourra facilement décoder tous les messages. J'ai vu cette méthode sur le blog de Julien Tinnes lors d'un de ses posts. Appelée 'Debian Emulation' pour une raison amusante liée aux déboires de debian quant à la qualité de leurs aléas, elle consiste à faire:ln -s /dev/zero /dev/urandomOu alors, le pirate peut envoyer les requêtes du client sur une machine maîtrisée, machine qui reproduira la site officiel afin que le client envoie de lui-même ses informations. Pour se faire, plusieurs moyens:-s'appuyer sur des failles DNS (chercher Kaminsky DNS sur google par exemple)-s'appuyer sur des failles BGP (pour rediriger le trafic sur un réseau maitrisé)-faire du phishingPour le phishing il existe la campagne de mail, ou plus dernièrement les IDN ou l'internationalisation des noms de domaines. Qui irait confondre paypal et raural?Il reste le problème mineur des sites qui sont http et pas https. Mais disposer d'un site https qui ne remonte pas d'alerte visible à l'utilisateur (petit cadenas fermé, couleur dans la barre d'adresse) est toutefois possible.-Il est possible de générer un vrai-faux certificat. (Tant qu'on paye, les CA fournissent des certificats)-La faille MD5 a permis de posséder un certificat de sous-CA parfaitement valide.-Moxie Marlinspike a montré qu'un certificat non-CA peut signer un certificat. Certains navigateurs accepteront cette signature comme valide! Le programme sslsniff fait beaucoup plus de choses que signer des certificats, mais il s'appuye sur cette méthode.-L'IDN permet de substituer une URL à une autre. Ainsi, l'URL firstname.lastname@example.org peut être lue comme étant l'utilisateur "www.mabanque.com/variable=2&tot=3" se connectant sur evil.com. Bien entendu la barre oblique est un caractère exotique et non pas le /. Le site evil.com possède un certificat valide. sslstrip utilise ce moyen pour rediriger de manière transparente un utilisateur d'un site légal vers un autre.-Le Nul prefix certificate permet de se faire passer pour un autre site lors de la vérification du CN de ce site par le navigateur.Ces failles ne sont pas toutes techniquement corrigeable. Il semble en effet particulièrement difficile d'empêcher le phishing et la naïveté des gens cliquant dessus.Toutefois, la majorité de ces attaques peuvent être évitées via un minimum de vigilance de la part de l'utilisateur: vérifie-t'il les certificats qui lui sont présentés?En conclusion, je dirais que le SSL/TLS est fiable, et ferai confiance aux protocoles s'appuyant dessus, tant que l'utilisateur et l'administrateur du site sont vigilants.
A propos de l'auteur.
Work in Progress:
- Etude sur cryptsetup
- Utilisation d'une puce TPM sous linux
Pour m'écrire: kevin2nis chez gmail point com.
"Ceci est un blog personnel, ce qui est exposé ici est donc le reflet des mes réflexions et positions personnelles et n'engagent donc que moi"
Achievements Unlocked
SSTIC:2014 : Haka, un langage orienté réseaux et sécuritéRMLL:2013: Le chiffrement de disque sous linux, deuxième round.2012: L'accès à internet est un sport de combat.2011: Certificats openSSH: gérez vos identités dans l'espace et dans le temps.2010: Le chiffrement de disque sous linux, vrai ou faux sentiment de sécurité?MISC:2012: Le talon d'Achille de la plausible deniability2011: Openssh, un protocole ouvert au chiffrement et fermé aux attaques. (Hors série)2010: Route par défaut.2009: Les conséquences de la faille MD5Linux Magazine:2012: Mysql administration2011: Compiler son noyau linux2010: Le boot d'un système linux2009: Lguest, un virtualiseur simple2009: Le système de fichiers ext42008: Le chiffrement de disque sous linux2007: Installation d'une solution de mail globale à gestion centralisée2005: Sécurisation antivirale des flux HTTP, HAVP2005: Sécurisation antivirale des flux POP3, p3scanLinux magazine Hors Série:2008: Le protocole SMTP par les RFC