Compte rendu (partiel) de PacSec 2008

Mon 17 November 2008 by christophe

Fred et Guillaume étant partis au pays du soleil levant pour présenter leurs travaux sur les menaces dues au format PDF (Malicious origami in PDF), voici leur compte-rendu sur la 1ère journée de cette édition 2008 de PacSec. Suite à quelques soucis de démos, de stress et tout ça le 2ème jour, ils n'ont pas vraiment suivi les autres conférences, préférant se concentrer sur la leur.

Living in the RIA world - David Thiel - iSEC Partners

David fait d'abord remarquer que sa communication est sensée durer 1h15 mais qu’il ne dispose finalement que de 45 minutes.

Le Web 2.0 présente de grandes disparités entre la conception de ses caractéristiques et de sa sécurité. Il devient facile pour n'importe qui de développer des applications utilisant ces technologies.

AIR : AIR peut charger du contenu externe ou accéder à des sandboxes (applications, externes, ...). Adobe pense que certains développeurs pourraient vouloir sortir de ces sandboxes, donc plutôt que de les laisser faire n'importer quoi, ils fournissent des "sandboxes bridges".

AIR permet de signer du code. Il peut être signé par une entité certifiée comme Adobe, mais quand il est non-signé ou auto-signé, le pop-up change afin de mieux avertir l’utilisateur. Quoi qu’il en soit, par défaut, le code non-signé ou auto-signé peut aisément être installé en un seul clic.

Silverlight : L'équivalent Microsoft de Flash. Il n’en dit presque rien pour des raisons de temps, mais également parce qu’il s’agit d’un plug-in assez récent.

Google Gears : Peut fonctionner en mode hors-ligne, et une synchronisation est opérée quand l’utilisateur se reconnecte. Il est supposé interagir avec toutes les applications Google. « Workerpool » est conçu pour pré-charger du code JavaScript demandant beaucoup de ressources. Il est fondé sur une sécurité de zone. À partir de Gears 3, il est possible de configurer la fenêtre utilisée pour les alertes de sécurité. Un attaquant peut donc modifier ce qui est affiché, avec par exemple : « Verisign fait entièrement confiance à ce site, utilisez-le ». Yahoo! BrowserPlus : Un plugin pour navigateur basé sur MPAPI, et permettant à tous de développer un plug-in pour un navigateur. Il permet aux pages d'interroger des applications telles que Flickr ou un interpréteur Ruby… Les plug-ins peuvent être modifiés une fois la signature vérifiée.

Mozilla Prism : Navigateur Web stand-alone limité à un domaine. Les applications sont supposées être séparées les unes des autres via des Sandbox. En passant par une application Prism, les préférences peuvent être modifiées. Par exemple, il est possible d’ajouter un nouveau proxy malveillant pour la navigation Web/mail. HTML5 : Introduit le stockage DOM, soit pour la session (durée indéfinie), soit de façon permanente (jusqu’à 5 Mb).Injection de code SQL + vol de données… mais je n'ai pas compris ni comment ni pourquoi. Dans le cas de FireFox 3, le gestionnaire de protocoles peut ajouter des proxy ou de nouveaux gestionnaires de protocoles. Un tel gestionnaire peut être installé en un seul clic. Avec FireFox 3.1, plus de "fonctionnalités" : « Web workers » à la Gears, cross-site XMLHTTPRequest, géolocalisation, … Aucune mention des aspects sécurité ou vie privée. Cette technologie est conçue par les développeurs du Web 2.0, elle ne vise pas les utilisateurs. L’interface de programmation est en perpétuel changement. Parfois, il arrive même que les développeurs procèdent à des ajouts ou des changements sur l’interface avant de mettre à jour les spécifications.

Conclusion :

Toutes ces technologies utilisent un stockage SQL local, ce qui offre la majeure partie du temps de nouvelles opportunités pour des injections XSS/SQL, souvent pre-auth.

Les frameworks RIA sont beaucoup moins standardisés, comportent de nombreuses fonctionnalités dangereuses, et ne prennent pas en compte l’aspect sécurité comme cela devrait être.

Script Fragmentation Attacks - Stephan Chenette - WebSense

La question mise en avant est comment empêcher la détection d’un exploit, tout particulièrement sur les applications Web. Très (très très) longue introduction expliquant que du contenu malveillant est embarqué dans du code JavaScript, obfusqué, souvent envoyé en une seule requête.

Le but de cette attaque est donc de fragmenter le script attaquant, et le diviser en de petits morceaux de données.

Besoin d’un navigateur, de JavaScript et d'un objet XMLHTTPRequest.

À ce que je comprends, l’attaque ressemble à toutes les attaques basées sur la fragmentation. Dans le cas du TCP et de la couche HTTP, la fragmentation était déjà connue. Il existe désormais des manières de le faire en JavaScript, via XMLHTTPRequest par exemple. Aucun proxy ne réassemblera l’exploit malicieux chargé, et donc personne ne sera en mesure de détecter l’attaque.

Cross domain leakiness: Divulging sensitive information and attacking SSL sessions - Chris Evans & Billy Rios, Google, Microsoft

La présentation commence par une démonstration de nombreuses failles dans les navigateurs quand ils tentent de durcir la politique des zones de sécurité. Certaines sont expliquées et d'autres non (parce qu’elles ne sont pas encore résolues). Elles jouent avec la sécurité inter-domaines, en faisant en sorte qu'une requête HTTP accède à un fichier local (file://) ou vole les pixels d'une image. (!!)

Les limites de sécurité sont réellement difficilement gérables dans les navigateurs : faut-il passer par la JVM, dans le navigateur lui-même, dans le moteur JavaScript … ?

Compte tenu de toutes les nouvelles caractéristiques des navigateurs, une liste exhaustive spécifiant où et comment la politique inter-domaines doit être durcie devient nécessaire.

S'en suit une longue discussion sur le XML dans du XML. Je préparais ma présentation, je ne peux donc pas en dire plus.

Ils expliquent ensuite un MITM actif contre un site SSL. Très difficile à suivre. Ils ne présenteront qu’une seule diapo, sur laquelle on peut lire « FORCE the loadingof insecure script reference over HTTPS », et c'est tout. Pendant dix minutes, ils ont essentiellement parlé du fonctionnement du navigateur et de la manière de le casser.

Une nouvelle attaque appelée « cookie forcing » est ensuite introduite. Le flag secure sur les cookies est toujours dangereux. La « lecture » a été résolue, mais pas l’« écriture », http://bank.com peut donc écraser le cookie sécurisé de https://www.bank.com.

Globalement, tout le talk devait être à mon avis très intéressant, mais les diapos étaient de peu d’intérêt. Je n’ai pas compris l’intégralité du talk, essentiellement parce qu’il s’agit d’un domaine que je ne connais pas vraiment. Parler de XSS via JSON eval() combiné à du XSRF ne veut pas dire grand chose pour moi.

Flash XSS and Flash malwares - Rich Cannings, Google

Rich commence par un historique de Flash et de sa sécurité. Les premiers éléments rapportés datent de 2002. Puis, rien pendant 5 ans, jusqu’à ce que quelqu’un trouve un moyen de procéder à un « cross site Flashing ».

État du problème Flash : - 97% des internautes japonais ont Flash - les applications Flash sont communes - les applications Flash non-sûres sont communes

Donc, amusons-nous :)

ActionScript est un langage semblable à JavaScript embarqué dans Flash, incluant diverses caractéristiques. Par exemple, il permet de faire fonctionner du JavaScript normal :getUrl("javascript:alert(1)").

Puis viennent plusieurs diapos à propos de XSS sur Flash et toutes les fonctions vulnérables. Des exemples réels sont donnés, pour la "banque Y",ou via des fichiers de configuration, tous à travers la fonction getUrl(). La partie sur les malwares dans les SWF était trop courte. Il s’agissait plus de comment cacher des SWF malicieux, en séparant du JavaScript embarqué.

Browser Memory Protection Bypasses: Virtual Machines - Mark Dowd, IBM

Ce talk s'inspire de la présentation de Mark et Alex Sotirov à Black Hat, avec du matériel plus perfectionné. Il commence par des rappels concernant tous les mécanismes de protection mémoire disponibles sous Windows, puis se focalise sur Vista, le DEP et l'ASLR.

Il se focalise sur la manière dont la machine JavaScript, Java ou .Net utilisent ces protections. Il est important de se souvenir que les compilateurs VMs/JIT proposent de relâcher ces protections. Par exemple, la JVM Sun alloue toute la mémoire en RWX.

Avec .Net, les protections sont plus strictes. Les objets contrôlés par les utilisateurs ne sont pas en RWX. Cependant, le compilateur JIT génère du code dans de la mémoire allouée en RWX. Les codes générés pour la méthode sont donc utiles, il nous faut simplement savoir comment accéder à ces régions.

Ce qui est chose facile grâce à GetFunctionPointer(), qui fournit l’adresse de toute méthode en mémoire, et qui pointe donc vers la région allouée en RWX.

Mark propose ensuite une alternative au « heap spraying ».  Alternative nommée « stack spraying ». Quand on prend en considération les différences, des problèmes apparaissent, comme la taille limitée de la pile. Mais grâce à .Net et JVM qui sont threadées, il est possible de contrôler la taille de la pile. Il expose donc la marche à suivre pour organiser la mémoire de façon à réaliser ce « stack spraying ».

"User controls" sont les equivalent des .class en Java. Ils peuvent être embarqués dans les pages Web via des tags <object> offrant ainsi un accès à toutes les possibilités d’exploitations dont il vient justement de parler. Il explique tout particulièrement comment deviner avec précision quel est l’emplacement d'une DLL spécifique (l'user object) même avec l'ASLR.

Créer une grande DLL (d’environs 100 Mb) qui sera située non loin des DLL du système. La deuxième méthode est basée sur une DLL plus grande (200 Mb)… mais je n’ai pas saisi (pour la troisième méthode non plus).

Le fait est que ces DLL sont trop groses pour être téléchargées. Il faut donc soit utiliser du padding (des sections dont la taille est nulle sur le disque mais grande mappée en mémoire, et par la suite utiliser simplement un ret pour la remplir avec des NOPs) soit compresser (compression fournie par l'encodage du contenu).

Une autre méthode consiste à allouer de petites DLLs (4-8 K) et en charger beaucoup. Comme elles sont mappées tous les 64 bits, il devient aisé de passer de l’une à l’autre (Pourquoi alors ne pas allouer des DLL de 63 K… ?)

Les shellcode virtuels sont utiles pour passer la protection DEP, et ils sont indépendants des plate-formes. Objectif : se servir de la corruption de la mémoire pour la validation faite par la VM quand un code malveillant tente d’exécuter des caractéristiques « protégées ». La vérification du programme est très simple : placer un entier dans la mémoire à 0, cet entier restant à la même adresse tout le temps. Cet entier était dans une région non-random [S23] avant la version 3.5 de la VM .Net. Désormais, il s’y trouve, ce qui n’est pas un problème. Nous pouvons toujours appeler getFunctionAddress() pour récupérer l’adresse de ce flag.

C’est la même chose en Java, mais en plus compliqué. L’idée principale est de régler sur NULL le pointeur de la méthode supposée effectuer les vérifications sécurité (« protection domain »).

Conclusion : les langages Web sont utiles pour contourner les protections de sécurité fournies par les OS dans le contexte du navigateur…

Une communication impressionnante. Un retour sur les diapos est nécessaire, mais c'était intelligemment construite. Chaque étape est expliquée dans un ordre précis, si clairement et logiquement que tout semble évident (mais pas simple). Meilleure communication que j’ai jamais vue sur un sujet aussi complexe.

Gaining access through Kerberos - Emmanuel Bouillon

Kerberos est un vieux SSO essentiellement utilisé dans les gros réseaux. Il est multi-plateforme et est le protocole d’authentification utilisé par défaut chez Microsoft. Malgré cela, des erreurs importantes subsistent lors de la configuration de Kerberos.

Le protocole est conçu autour de l'idée que le réseau n’est pas sûr (l’adresse IP peut être usurpée). Si on ne peut pas faire confiance au réseau, le serveur Kerberos doit fournir un service de tiers de confiance (appelé KDC). Enfin, il utilise de la cryptographie symétrique.

Kerberos utilise trois types d’échanges :

Paquets 1, 2 : un échange pour obtenir un ticket d’authentification du KDC (où le mot de passe est requis). Paquets 3, 4 : un échange pour obtenir un ticket pour un service du KDC Paquets 5, 6 : un échange pour présenter le ticket à l’application.

Les deux derniers ne nécessitent pas que l'utilisateur fournisse de mot de passe, puisqu’ils sont basés sur le ticket obtenu lors du premier échange. Les paquets 1, 3, 5 sont envoyés par le client, et les paquets 2, 4, 6 par le serveur. Kerberos attend d’avoir le cycle complet pour assurer la sécurité.

Puis, Emmanuel présente tous les outils nécessaires pour tester (ou pentester) Kerberos : essentiellement keimdal, scapy, wireshark, ettercap, pyasn1 modifié pour supporter krb5.

Considérons à présent la première attaque connue : KDCSpoofing

Le protocole Keberos assure l’authentification mutuelle (utilisateur et serveur), et devrait empêcher une attaque MiTM. Cependant, certains logiciels d’authentification (comme le module PAM) utilisent des raccourcis pour authentifier le serveur. Il est donc possible d’usurper le KDC. La solution est de fournir un fichier lisible en root uniquement pour empêcher l’usurpation en assurant le processus d’authentification, vérifie l’ID du KDC. Le problème est que certaines applications ne peuvent pas lire ce fichier (comme l'économiseur d’écran). Donc, même quand la mitigation est active, cette attaque fonctionne toujours !

Attaques par rejeu :Dans de très vieilles versions, il était possible de rejouer la requête émise par le client à une application. Une fois la requête repérée, un attaquant a juste à la copier, la relancer au serveur d’applications, et il obtiendra un ticket valide. Ce problème à été résolu dans les versions récentes de Windows.

Que se passe-t-il si on combine ces deux attaques ? Un attaquant malveillant peut usurper l'identité de n’importe quel utilisateur dans l’AD (cette attaque vise un client).

L’attaquant doit sniffer la totalité d’un processus de connexion légitime.

L'attaquant obtient le ticket de service. L'attaque KDCSpoof fonctionne toujours. Cependant, l’implémentation de Windows est correcte. La simple usurpation n’est donc pas suffisante pour réussir l’authentification entière. Les paquets (3, 4) et (5, 6) doivent eux aussi être corrects.

Et voici venir le rejeu : Avant l’attaque, l’attaquant a établi un faux KDC supposé renvoyer un paquet 4, qui affiche au client « ok, vous pouvez utiliser mon service ». Le paquet est suffisamment sympathique pour que le client l’accepte et poursuive… Jusqu’à ce que l’authentification soit complète et validée : nul besoin de connaître le mot de passe de l’utilisateur. Ici, l’attaque fonctionne parce que le service attaqué est winlogon et est totalement local : il n’y a plus d’interaction avec le KDC. Le faux ticket de service semble localement correct, et l’accès est permis.

Advances in Automated Attack Planning - Carlos Sarraute & Alejandro David Weil, Core

Les tests d’intrusion à grande échelle sont essentiellement une question de stratégie, c'est à dire de planification. Comment être efficace ? En 1999, Schneier est le premier à avoir proposé les « attack trees ». Ces attaques ont évolué depuis.

Les nœud du graph sont des actions et des prédicats.

Ex. : Action IIS stack overflow

prereq : privilges(S) > user
         privilges(T) > root
         ...

La complexité des attaques croît de façon exponentielle. La plupart du temps, elles sont construites du point de vue du défenseur, ce qui implique une parfaite connaissance du réseau cible. De plus, construire une attaque complète est inutile, nous devons nous concentrer sur des scenarii qu’il est possible de résoudre.

Après cette présentation, ils ont discuté des RPT (Rapid Penetration Testing) ... mais je ne peux pas dire ce que c'est car je me suis mis à discuter avec Emmanuel pour vérifier ce que j'ai compris de sa présentation (ça tue).

Et voilà, c'est tout pour cette première journée ... et c'est tout pour ce résumé de PacSec. La 2ème journée a été remplie par des répétitions, des corrections de bugs et toutes les joyeusetés qui font que nous étions prêts uniquement 30 minutes avant de parler (***** de stagiaire ;-)