SSTIC 2013 – Jour 2

DreamBoot et UEFI

S. Kaczmarek

S. Kaczmarek est employé chez QuarksLAB, il s‘est intéressé à l’UEFI (Unified Extensible Firmware Interface), un composant logiciel s’interposant entre le matériel et le système d’exploitation. Il a pour vocation de remplacer le BIOS.

Avant de se lancer dans sa présentation, l’orateur a laissé la parole, pour une courte présentation de l’UEFI, à Pierre Chifflier qui a mené parallèlement, et sans que S. Kaczmarek ne le sache, le même type de recherche.

Finalement, leurs deux présentations sont complètement différentes : l’un présentant un développement (bootkit) permettant d’obtenir les permissions SYSTEM sur un Windows 8 (x86 et x64) à partir d’une ISO bootable dont les travaux sont ici présentés, l’autre à partir d’un composant se logeant dans la carte graphique et permettant également d’obtenir les droits SYSTEM sur Windows 8.

L’UEFI est assez différent du BIOS vieillissant qu’il remplace. En effet, c’est quasiment un véritable système d’exploitation, doté de fonctionnalités telles qu’un Secure Boot, de la cryptographie, une gestion de disques durs supérieurs à 2,2To, un interpréteur Python, un serveur Web pour faire du diagnostic et bien d’autres fonctions encore…

Le bootkit présenté opère une succession d’étapes ayant pour but final d’obtenir les permissions de niveau SYSTEM.

Il s’accorche (hook) au chargeur de démarrage UEFI (bootmgfw.efi) dans le but de patcher le chargeur du noyau en mémoire (winload.efi) avant son exécution. Après plusieurs opérations, s’en suit une corruption du noyau ainsi que la désactivation de plusieurs protections, comme PatchGuard et le bit NX.

Le noyau ainsi modifié va alors patcher lsass.exe pour permettre l’authentification d’un utilisateur sans mot de passe sur Windows avec les mêmes droits que l’utilisateur courant préconfiguré sur le système. À ce stade Windows est lancé, la page de demande de mot de passe est affichée et l’utilisateur courant peut se loguer sans mot de passe.

Vient la phase où le bootkit va récupérer le token d’un processus ayant les permissions de niveau SYSTEM et attendre qu’un processus cmd.exe soit lancé pour placer ce token sur le processus. Il en résulte l’obtention de permissions de niveau SYSTEM par le processus dès qu’il est lancé par l’utilisateur. L’utilisateur est alors administrateur sur l’ordinateur depuis le shell cmd.exe.

Ce genre d’attaque existait déjà avant l’UEFI et Windows 8 mais l’implémentation est ici assez différente. Ceci est dû aux spécificités et nouveautés mises en place par ces systèmes. Si le développement n’a pas été aisé, l’utilisation de cet outil est très simple.

Par conséquent, il est recommandé de désactiver le démarrage sur média externe (clé USB, DVD…), de définir un mot de passe UEFI et de chiffrer son disque dur.

UEFI et bootkits PCI : le danger vient d’en bas

Pierre Chifflier

Pierre Chifflier travaille actuellement à l’ANSSI. En parallèle, il est « Core Developper » sur le projet Debian et participe au maintien de Grub2.

L’objectif de la conférence est d’expliquer les étapes de la création d’un bootkit sur une architecture avec un UEFI.

Pour commencer, Pierre explique les plus gros défauts des bootkits « classiques » : ils sont soit temporaires et ne permettent pas de garder une emprise durable sur une machine, soit permanents et impliquent de modifier le système de fichiers, ce qui les rend détectables.

Ensuite, il commence la présentation de ses choix techniques pour la réalisation de sa preuve de concept. Il a choisi de placer sa charge malveillante dans la ROM d’extension d’une carte graphique PCI qui, bien que supposée être en lecture seule, est accessible en écriture. Cette ROM peut être flashée sans avoir à manipuler l’électronique… sauf en cas d’erreur, la machine se mettra alors à biper et refusera de démarrer. Il faudra alors flasher la puce matériellement.

En effet, lors du chargement des drivers, l’UEFI charge cette ROM, mais pour des raisons de compatibilité entre les cartes graphiques et les BIOS, l’UEFI est capable de charger plusieurs drivers en parallèle. Ce mode de compatibilité permet donc de ne pas avoir à s’attaquer aux drivers, il suffit de placer un second driver à la suite.

Cependant, la puce ayant 64k de mémoire, dont 40k sont déjà utilisés par le vrai driver, la charge devra tenir dans 24k.

Les étapes suivantes sont une succession de phases qui font penser à la pose de breakpoints. Il faut d’abord patcher la fonction « ExitBootServices » appelée à la fin de l’exécution de Grub2, pour placer un breakpoint matériel au début de l’exécution du kernel.

Puis, arrivé à ce breakpoint, il faut placer le suivant après la décompression du kernel. Ce dernier breakpoint permet la mise en place de l’élévation de privilèges dans l’appel système fork. Cet appel système n’est en fait plus utilisé au profit de clone.

Une fois sur le système, il suffit de créer un petit programme en C qui utilise la méthode « syscall » pour faire appel à « fork ».

Pour pouvoir se protéger contre de telles attaques, les méthodes classiques, comme les antivirus et grsec, sont totalement inefficaces. Les méthodes plus avancées, comme l’utilisation de TPM, peuvent être contournées comme l’ont montré J. Butterworth, C. Kallenberg et X. Kovah à la NoSuchCon. Enfin, la Secure Boot pourrait supprimer le problème mais rendrait obsolète tous les anciens matériels.

Finalement, une des meilleures protections serait peut-être que les constructeurs produisent des ROM qui soient uniquement accessibles en lecture, conformément aux spécifications.

Les slides sont disponibles sur la page de la conférence : https://www.sstic.org/2013/presentation/uefi_et_bootkits_pci/.

Programmation d’un noyau sécurisé en Ada

Arnault Michelizza

Arnault Michelizza travaille à l’ANSSI. Il a développé par le passé un micronoyau, développé en C qu’il a appelé « Pépin ». Depuis qu’il est à l’ANSSI, il a été sensibilisé à la sécurité et s’est intéressé au développement d’un noyau sécurisé. C’est le résultat de ses recherches et du développement associé qu’il présente ici.

Lors de la conférence, l’orateur est revenu brièvement sur les différents mécanismes de protection existant sur les noyaux modernes : PAX, ASLR, Canaris, bits SMAP, bit SMEP… Il a également montré les différents types de vulnérabilités qui ont touché récemment les noyaux et en a conclu que 80% de ces vulnérabilités entrainaient des dépassements de tampon (buffer/integer overflow) ou des déréférencements de pointeurs.

Dans sa recherche pour trouver la meilleure manière de concevoir un noyau sécurisé, il a fait deux constats :

• Comme le nombre de bugs augmente proportionnellement au nombre de lignes de code, l’utilisation d’un micronoyau est préférable pour réduire la surface d’attaque. De plus, dans un micronoyau, les drivers ont leur propre espace d’adressage ce qui réduit l’impact de la découverte d’une vulnérabilité ;
• Un langage de programmation ne permettant pas de débordement de tampon ou d’utilisation de pointeur, celui-ci serait privilégié. L’Ada, bien qu’inconnu de l’orateur au moment du choix du langage, a été sélectionné car il répond à ces prérequis, il est encore maintenu et il permet de faire du code bas niveau. Ainsi, Arnault a notamment éliminé Java, C, OCaml entre autres, pour ne plus retenir qu’un langage : l’Ada.

L’Ada est peu utilisé, il a été développé par des militaires, il est souvent employé dans des domaines où la vie de l’être humain est en jeu. Arnault a mis 6 mois pour le maîtriser et assure que ces six mois d’investissement seront rapidement rentabilisés tant il est facile de debugger et de retrouver où se produisent les erreurs des programmes en Ada.

Actuellement, son noyau en Ada est plutôt au stade de preuve de concept. En effet, même s’il fonctionne parfaitement, son créateur n’y voit qu’un domaine d’application  très localisé (firmware, UEFI…) car quasiment aucun driver n’est développé pour, ce qui le rend inutilisable sur un poste de travail.

Comparé à un micronoyau développé en C, le sien a seulement 60% de cycle d’horloge supplémentaire.

Arnault n’a pas eu le temps de faire une démonstration de son noyau lors de la conférence mais il a profité des rumps sessions pour en faire une avec un driver (stack TCP/IP) qui affiche les paquets ICMP reçus et cela a fonctionné sans problème.

Les slides sont disponibles sur la page de la conférence : https://www.sstic.org/2013/presentation/programmation_d_un_noyau_securise_en_ada/.

La Couleur du Net (conférence invitée)

Laurent Chemla

Laurent Chemla est un des cofondateurs du célèbre registraire et hébergeur français, Gandi. Il est également l’auteur du livre Confessions d’un voleur : Internet, la liberté confisquée (Éditions Denoël, 2002) et connu pour ses prises de position et de parole en faveur de la neutralité d’Internet.

Il est invité par le SSTIC pour nous parler d’un sujet tout autre que la sécurité, mais un sujet qui lui tient aussi à cœur : Internet dans notre société.

Il commence la présentation en nous annonçant qu’il nous a menti.

Il le dit et le répète, haut et fort, à coup de photographies de de Gaulle (cf « Je vous ai compris »). En effet, pendant des années il s’est attelé à expliquer lors de conférences diverses et variées (par exemple, au Sénat) qu’Internet était un outil comme un autre ne nécessitant pas de régulation particulière. Il préconisait une régulation de l’usage plutôt que de l’outil, se servant de l’analogie autoroute/cambrioleur (On ne sanctionne pas une autoroute parce qu’elle est utilisé par un cambrioleur).

Poussant son raisonnement à l‘extrême, il nous annonce donc qu’Internet est bien la cause du terrorisme, de la grippe A, des photos de chatons, de la guerre, etc. . On s’en doutait…

Il prétend donc avoir menti car bien qu’un outil, en soi, ne doive pas être régulé, on ne peut considérer Internet uniquement du point de vue technique, son influence sociale importe également. Or il remarque que dans les débats ayant lieu depuis plusieurs années, les différents protagonistes ne veulent en réalité pas réguler la même chose, ce qui développe un sentiment de frustration de part et d’autre. Il y aurait donc la neutralité technique et la neutralité sociale d’Internet.

Par la suite, il donne l’exemple de Free qui est un assez bon acteur neutre techniquement alors que sur les aspects sociaux, ce n’est pas le cas (filtrage du port 25, filtrage de la pub, peering Google/YouTube). Cependant, chacune des atteintes à la neutralité dite sociale a eu un impact médiatique bien différent. Le filtrage du port 25 a eu très peu de répercussion alors que non seulement les médias mais aussi l’état se préoccupent du blocage de la publicité et du peering Google/YouTube.

En clair, il a été beaucoup question de vouloir protéger la neutralité dans ces débats alors qu’il s’agit, de la part des médias et de l’état, plutôt d’un acte protectionniste envers l’écosystème de la publicité ainsi que la société de manière générale.

Il nous dit donc que défendre la neutralité technique d’Internet ne serait pertinent qu’à la marge, l’objectif réel des partisans de cette neutralité n’étant pas tant la pérennité de l’outil Internet mais la garantie qu’il continue à changer  notre société dans le bon sens. En d’autres termes, il s’agirait d’une lutte entre les personnes déjà au pouvoir et le reste de la population qui n’a jamais eu les outils des puissants pour s’exprimer, ce qu’un Internet « neutre » leur permettrait.

Il pointe aussi le fait qu’Internet engendre la disparition d’un certain nombre d’éléments tels que :

• Les intermédiaires dans le commerce des biens matériels, dans l’industrie culturelle, dans le journalisme, dans l’économie et en politique ; cette « désintermédiarisation » menant soit à une totale décentralisation, soit à une hypercentralisation. Il cite notamment l’invention  du feu ou de l’imprimerie, ou plus récemment Bitcoin comme exemples d’inventions/révolutions qui dérangent le pouvoir en place (les états et la banque, plus particulièrement pour Bitcoin) ;
• Les frontières dans l’application des lois nationales, dans la fiscalité « numérique », dans la diffusion de l’industrie des loisirs et dans la diffusion de la culture en général, allant même jusqu’à nous dire que la mondialisation mène à une dictature libérale planétaire ou à l’utopie libertaire, en est pour exemple la réponse de Twitter face à  une plainte  de l’UEJF (Union des Étudiants Juifs de France) pour injures raciales et diffamation, rétorquant qu’en tant qu’entreprise américaine, il ne répond pas du droit français ;
• Les supports physiques et la numérisation permettent l’abondance pour le plus grand nombre ou l’accumulation des richesses pour quelques-uns. Il n’y a aujourd’hui quasiment plus de logiciels en boite, la musique et les films se consomment de plus en plus de manière numérique. Tout ceci résulte d’une évolution du support, les produits en eux-mêmes existent toujours. Le summum de la numérisation étant l’impression 3D qui pourrait nous permettre demain de tout numériser et d’imprimer à volonté.

Tous ces points mènent à une perte de valeur globale des biens qui laisse entrevoir deux futurs différents. Le premier dans lequel tout le monde devient très, très riche : il est possible d’imprimer, via des imprimantes 3D, sa propre nourriture, sa propre maison, etc… et le deuxième dans lequel une majeure partie de la population est pauvre tandis que quelques personnes s’enrichissent grâce aux DRM et aux copyrights.

Laurent Chemla trouve donc amusant que depuis des années, on entende les mêmes dires : Internet est une révolution qui ira dans le bon sens alors qu’en même temps on dit vouloir préserver une neutralité qui n’a jamais existé. Tous les soi-disant défenseurs ne veulent pas pérenniser Internet, mais veulent pérenniser les changements induits par la création et l’existence d’Internet.

Pour conclure, Laurent Chemla nous dit qu’à défaut de neutralité, Internet devrait être transparent à tous les niveaux (blog, Twitter, donnée publiques, etc.). Il est assez favorable à ce que l’on perde toute vie privée, que l’on perde certains éléments de la vie passée (comme les intermédiaires susmentionnés), mais qu’en échange nous bénéficions d’une distribution massive du pouvoir de se surveiller les uns les autres. La solution de 1984, de George Orwell (1949) serait donc dans The Shockwave Rider de John Brunner (1975).

Présentations courtes

Hack Android/Samsung, à l’attaque du noyau

Étienne Comet

Étienne Comet est consultant en sécurité informatique chez Lexfo.

Il existe beaucoup de moyens pour attaquer un smartphone Android à distance. Cependant, l’accès obtenu reste assez restreint. Pour aller plus loin, il est donc nécessaire d’élever ses privilèges. C’est pour cela que l’on s’intéresse à l’attaque du noyau.

Le noyau Android est basé sur un noyau Linux, avec de nombreux patchs supplémentaires. On retrouve donc toutes les failles du noyau Linux, mais la surface d’attaque est étendue : comme indiqué précédemment il y a beaucoup de patchs en plus. Ainsi, le noyau est compilé avec des options peu auditées, Android tourne sous ARM (failles potentielles spécifiques à ARM comme le CVE-2011-1759).

Si on se concentre ensuite sur un téléphone spécifique, le constructeur ajoute des périphériques, des applications, ce qui élargit d’autant plus les possibilités de compromissions. Le noyau est donc un vecteur d’attaques prometteur.

Ensuite, l’orateur revient sur les différentes techniques de debug, avec ou sans les droits « root », notamment via KGTP (Linux Kernel debugger and tracer, http://code.google.com/p/kgtp/), un projet naissant.

L’intervention se termine par la présentation de deux bugs exploitables : un 0day et un second qui a été corrigé depuis sa découverte.  L’exploitation des failles prend la forme d’une application Android, donc en Java. Pour exploiter du code natif, il est nécessaire d’utiliser JNI qui permet d’utiliser du code natif dans une classe Java.

Compromission d’un environnement VOIP Cisco

Deuxième présentation courte de la journée, réalisée par un autre chercheur de Lexfo.

La présentation tourne autour du retour d’un audit sur environnement VOIP Cisco. L’orateur revient sur le schéma d’architecture classique VOIP Cisco. De nombreuses conférences ont présenté des vulnérabilités au sein de VOIP Cisco mais aucune n’a ciblé le call manager.

L’orateur revient sur le détail d’un audit en trois grandes phases :

• Black box : récupérer les credentials administrateur ;
• White box : obtenir une exécution de code ;
• Audit du système : élever ses privilèges vers « root ».

Il détaille les six vulnérabilités (des 0 day non remontés à l’éditeur) permettant la compromission du call manager et effectue une démonstration. Il n’est pas prévu de remonter ces failles à l’éditeur, point qui a d’ailleurs fait débat auprès des participants du SSTIC.

Observatoire de la résilience de l’Internet français

Guillaume Valadon

La dernière présentation courte de la journée est effectuée par Guillaume Valadon (ANSSI).

Comme il existe des bonnes pratiques de développement, il existe également des bonnes pratiques au niveau du réseau. L’un des objectifs de l’Observatoire de la résilience de l’Internet français est de vérifier que les acteurs Internet respectent ces préconisations. L’application de ces préconisations permettra d’assurer la résilience de l’Internet français.

Il existe plusieurs définitions de la résilience, dans notre cas de figure,  on utilise celle issue du Livre blanc de la défense nationale de 2008 : « Capacité de fonctionner pendant un incident et de revenir à l’état nominal ».

Cependant, il n’est pas possible de tester si Internet est robuste car trop grand, trop gros et trop fragile. L’Observatoire, en plus d’émettre des préconisations, effectue une vaste opération de surveillance et d’analyse.

L’orateur revient rapidement sur quelques notions de BGP (Border Gateway Protocol) et présente les risques liés à de mauvaises utilisations du protocole. Cependant, il existe peu d’AS qui, s’ils tombaient, casseraient l’Internet français.

Ensuite, Guillaume nous présente le cas du DNS. Le constat effectué par l’Observatoire, est que, sur les zones gérées par l’AFNIC, quasiment tout le monde utilise plus d’un serveur DNS pour sa zone. Cependant, 80% des zones sont chez un unique AS. De plus, le DNS permet d’analyser le taux de pénétration d’IPV6 (soit environ 10%).

Pour conclure, l’orateur rappelle quelques bonnes pratiques : déployer IPV6, répartir les DNS faisant autorité au sein de différents opérateurs, etc. Pratiques que l’on retrouve dans l’état des lieux 2011 disponible sur le site de l’Observatoire (http://www.ssi.gouv.fr/observatoire/).

De plus, le rapport 2012 sera disponible d’ici la fin du mois et un guide des bonnes pratiques BGP sera disponible en septembre 2013.

Les slides sont disponibles sur la page de la conférence : https://www.sstic.org/2013/presentation/resilience_internet/.

Sécurité des applications Android constructeurs et réalisation de backdoors sans permission

André Moulu

André est actuellement en alternance chez QuarksLAB, il est spécialisé dans la recherche de vulnérabilités sur Android.

Il a choisi Android car c’est actuellement le système leader sur le marché. Sa sécurité est souvent mise en cause par des annonces sur des malwares. Il rappelle que ces malwares sont téléchargés par les utilisateurs sur des markets alternatifs et que le système Android est correctement sécurisé. Cependant, il nuance ses propos et montrera ultérieurement que les surcouches du constructeur dégradent également cette sécurité apparente.

Il a donc décidé de s’attaquer à ces surcouches. Il prend comme téléphone cible un Samsung Galaxy S3 (car il s’est vendu à 50 millions d’exemplaires pour le moment) mais ses recherches sont finalement communes pour tous les téléphones possédant une surcouche Samsung (S2/S4/Notes). Les vulnérabilités exposées permettent de plus de s’attaquer à un utilisateur au courant des problématiques de sécurité et vérifiant les permissions des applications qu’il installe.

Généralités sur Android

Le système Android est un système d’exploitation Mobile détenu par Google, développé en C et en Java. Il utilise sa propre machine virtuelle Java (Dalvik) qui est une machine à registre, contrairement à la JVM classique. Les applications installées sont des fichiers .apk, mais ceux-ci ne sont finalement que des fichiers .zip contenant les fichiers d’applications. Parmi les fichiers présents dans .apk on peut notamment citer :

• AndroidManifest.xml : c’est un fichier de configuration de l’application qui contient les demandes de permissions, les composants ainsi que le SDK cible ;
• Classes.dex : qui contient le code exécutable (bytecode) ;
• Les bibliothèques de fonctions natives en .so.

Description d’une application

Les applications sont composées de :

• Activity : c’est l’interface graphique, chaque Activity correspondant à un écran de l’application ;
• Broadcast Receiver : permet de récupérer les événements extérieurs, comme l’insertion d’une carte SD ou la perte de la connexion Internet ;
• Content Provider : permet à l’application de communiquer avec les bases de données ou la liste des contacts ;
• Services : qui permettent à l’application de rester en mémoire et, par exemple, de récupérer les mails en fond de tâches.

La dernière notion importante est l’Intent : c’est la source de communication sous Android, il peut être inter-composants ou inter-applications. Par exemple, c’est un l’Intent qui demande l’ouverture du navigateur lorsque l’on souhaite ouvrir une page Web. L’Intent communique avec des composants. Par défaut, ces composants ne sont pas accessibles depuis l’extérieur de l’application, sauf si ceux-ci sont déclarés explicitement comme exportables dans l’AndroidManifest.xml. Il est aussi possible d’exporter un composant tout en le protégeant par une permission.

Modèle de sécurité sur Android

Il existe 2 types de sécurité implémentés dans Android.

1)      Sécurité par cloisonnement

Le système attribut un UID à chaque application. Cela permet d’avoir les processus isolés en mémoire et les systèmes de fichiers des applications ne sont accessibles que par elles-mêmes.

Il y a un cas particulier : deux applications peuvent partager le même UID, pour cela il faut le déclarer dans l’AndroidManifest, il faut également que les applications soit signées avec le même certificat.

2)      Sécurité par moindres privilèges

Par défaut une application ne possède aucun privilège, le développeur doit demander explicitement toutes les permissions de l’application dans l’AndroidManifest. Les permissions sont affectées à chaque UID. Par conséquent, les permissions sont cumulées pour toutes les applications qui partagent le même UID.

Réalisation d’une backdoor

L’idée est de réaliser une exploitation de vulnérabilité sur les applications constructeur qu’un simple utilisateur ne peut pas désinstaller. L’exploitation de la vulnérabilité se fait donc en user land.

André Moulu a donc listé les applications constructeur présentes dans /system/app et /system/framework. 216 Fichiers .apk sont présents correspondant à 500Mo d’applications (contre 91 fichiers pour un téléphone Nexus « nu »), à cela il indique que certains opérateurs ajoutent une surcouche eux aussi, étendant d’autant plus la surface d’attaque.

Des contraintes entrent en jeu ; en effet, le nombre conséquent d’applications oblige l’automatisation de la recherche d’applications potentiellement vulnérables, puis la rétro-conception dans le but de trouver des permissions pouvant être détournées de leur usage premier.

Pour cela, il a développé plusieurs modules Androguard :

• ASA manifest : analyse le manifeste et indique les éléments accessibles ou non et sous quelles conditions ;
• ASA Database : analyse et enregistre les informations des applications dans une MongoDB ;
• ASA Diff : développement en cours.

Son objectif est maintenant clair : avoir un maximum de permissions depuis sa backdoor !

Accès à la carte SD

Historiquement, toutes les applications avaient accès en lecture et en écriture à la carte SD. Depuis, seul l’accès en lecture est toléré par le système, uniquement dans un souci de rétrocompatibilité. Si dans le manifeste le SDK cible est inférieur ou égal à 3, alors le système autorise les accès en écriture à la carte SD.

De nombreuses autres permissions ont été détournées, comme l’envoi de SMS, sans en faire la demande explicite, en exploitant des vulnérabilités dans ui.MMS.BGSender.apk. Il suffit de lui envoyer un Intent le forçant à envoyer un SMS.

Une élévation de privilèges est aussi possible en utilisant une vulnérabilité trouvée dans une application partageant son UID avec l’utilisateur « system », une fois ce niveau de privilèges atteint.

Forwading de SMS

L’application DSMLawmo.apk reçoit un Intent à l’arrivée d’un SMS, dans le cas où le SMS n’aurait pas déjà été reçu il n’y a pas longtemps (afin d’éviter le SPAM). Ensuite, l’application transfère le SMS au numéro présent dans la base de données. Ce numéro n’est pas renseigné par défaut. Simplement, après  avoir obtenu les droits système, il est possible de modifier cette base. Ainsi, on ajoute son numéro dans la base de données et il est possible de transférer les SMS de la victime de manière tout à fait transparente.

Pour cela, les antivirus sont inefficaces.

Conclusion

La surface d’attaque augmente avec chaque nouveau terminal. En effet, la surcouche constructeur est de plus en plus grande, mais les innovations qu’Android met en place, notamment SELinux, permettent petit à petit de résoudre ce problème. Il est aussi possible de se protéger en achetant des téléphones « nus », sans surcouche constructeur.

Les slides sont disponibles sur la page de la conférence : https://www.sstic.org/2013/presentation/securite_applications_android_constructeurs_et_realisation_de_backdoors_sans_permission/.

Limites des tables rainbow et comment les dépasser en utilisant des méthodes probabilistes optimisées

Cédric Tissieres, Philippe Oechslin, Pierre Lestringant

Concrétisation de la mission de stage de Pierre Lestringant au sein de Objectif Sécurité, société suisse, notamment éditrice d’Ophcrack, cette conférence débute par une rapide présentation du principe de fonctionnement des tables rainbow et de leurs applications.

L’objectif est donc d’effectuer la majorité, voire l’intégralité, des calculs en amont de la phase de cassage, tout en gardant un rapport performant entre la durée d’exécution et le taux de réussite.

Suite à la démocratisation des calculs sur GPU, l’intérêt des tables rainbow peut sembler plus limité dans un contexte où les délais d’accès au contenu des tables rainbow tend à représenter une plus grosse contrainte que l’exhaustivité d’une attaque par brute force.

Par conséquent, il devient nécessaire de procéder à des optimisations sur les tables rainbow par le biais de fonctions déterministes : la détection de patterns et les chaînes de Markov.

La détection de patterns consiste à identifier les comportements habituels des utilisateurs lors de la définition de leur mot de passe : alternance de casse, remplacement de caractères par des équivalents numériques, ajout de ponctuation…

Ainsi, avec l’application d’un algorithme de sac à dos (approche heuristique de l’algorithme glouton), il devient possible de trier par ordre de fréquence d’occurrence les différents patterns.

Une fois cette étude probabiliste réalisée, on connaît donc, pour chaque bloc, sa probabilité et l’impact qu’elle aura sur la taille des tables rainbow.

Suite à des tests effectués sur des bases de données « leakées » dernièrement, il a été constaté qu’une réduction de taille des tables rainbow par un facteur 10 000 (sur les mots de passe de 9 caractères) engendre une simple réduction de 4% de la probabilité de cassage de la chaîne (de ~99% à ~95%).

Les chaînes de Markov permettent de considérer qu’un utilisateur définit un mot de passe proche de sa langue maternelle. De fait, on peut raisonnablement considérer qu’un caractère sera influencé par les deux caractères le précédant (chaîne de Markov d’ordre 2).

La phase d’optimisation des recherches correspond à une implémentation de la méthode Alias. Elle permet d’assimiler la sélection des patterns au tirage d’un dé biaisé dont chaque face représente un pattern, pondéré par sa probabilité d’occurrence.

Cette méthode Alias permet d’optimiser le découpage des espaces de résultats et de limiter le nombre de cycles nécessaires à la recherche. Elle présente aussi l’avantage de ne pas pouvoir réduire les performances de la recherche, même en cas de sets inadaptés à cette méthode.

Ces optimisations permettent donc d’améliorer la viabilité des tables rainbow face à la parallélisation des calculs apportée par les GPU. De plus, de nombreuses fonctions de réduction des hash étant incluses dans les calculs des tables rainbow, la génération de celles-ci peut, à son tour, bénéficier des améliorations apportées par les capacités de calcul des GPU .

Rumps

1. Des Trucs en Stock Sur SSTIC – L’équipe du SSTIC

• Rapide rappel informatif sur le social event.
• Finance : tout va bien, les tarifs ont légèrement baissé cette année.
• Il est à noter que 75% du budget part dans l’alimentation (buffet tout au long des confs, social event, etc.) ;
• Soumissions : L’équipe invite tout le monde à soumettre des papiers pour l’année prochaine ;
• Inscriptions :
  • 1^ère vague : 150 places vendues en 4 minutes et 41 secondes,
  • 2^ème vague : 130 places vendues en 12 minutes,
  • 3/4/5^ème vagues : 96 places vendues en 50 minutes ;
  • Il y avait un système qui bannissait pendant 20 minutes les personnes rafraîchissant la page plus de 40 fois par seconde. Une personne a été bannie 1 seconde après l’ouverture… :s

2. MGCP, un protocole VOIP oublié –  Sn0rkY

MGCP est un protocole utilisé dans beaucoup d’infrastructures VOIP, mais très souvent oublié. Il utilise de l’UDP sans authentification, il est possible de modifier une connexion à la volée, de scanner toutes les grandes classes d’adresses. Interroger des « Endpoint » est également relativement aisé.

Sn0rkY a donc créé des scripts pour récupérer plus facilement des informations. Il peut également rediriger le flux pour un appel sortant et se positionner en écoute au milieu de flux (type Man in the Middle). Une attaque de ce type est faisable depuis Internet car beaucoup de gateways opérateurs sont ouvertes sur Internet. Le MGCP est donc à bannir.

3. Quel est l’OS de Kim Jong-un? – Pierre Capillon

Pierre Capillon est l’auteur de java-0day.com, une page qui donne le nombre de jours depuis le dernier 0day Java.

Il donne des statistiques des accès à sa page. Il y a beaucoup de hits provenant d’Oracle, mais également des IP d’APT1, de .gouv.fr, de Syrie, d’Iran, de Cuba, du Pentagone, de whitehouse.gov, etc.

Il a également eu un hit d’une IP nord-coréenne, et proclame : « L’IP de la Corée du Nord vous l’avez !! ». Kim Jung-un surferait donc avec un MAC pas du tout à jour. Il finit sa rump avec un silde spoil du dernier épisode de Game of Thrones, le 9 de la saison 3.

4. La sécurité est un ______ (complétez la phrase) – Nicolas Ruff

Il nous livre ses trouvailles lors d’un audit sur une appliance dont l’applicatif a été réalisé en PHP :

• Possibilité de contourner l’authentification dans l’URL (login=admin&password []=) ;
• SHA-1 en commentaire dans le code ;
• exec.php à la racine ;
• Clé privée disponible dans l’arborescence de l’application ;
• « La question n’est pas combien de secondes il faut pour passer « root », mais avec combien de méthodes différentes » ;
• Il y a un compte « root » disponible pour communiquer vers l’éditeur, une backdoor en somme ;
• Etc.

Et cela fait plusieurs années que le produit est certifié CSPN par l’ANSSI ! Toutes ces failles ont été remontées à l’éditeur.

5. Another perspective to IP-Darkspace Analysis – Alexandre Dulaunoy

C’est un sujet dont on parle depuis quelque temps. Il y a beaucoup de chercheurs, mais les résultats ne sont pas très intéressants. Quant à l’orateur, il a choisi de se focaliser sur les erreurs de frappes. Par exemple, 193.168.1.x au lieu de 192.168.1.X. Il a donc réussi à obtenir l’une de ces IP que l’on concocterait en faisant une erreur de frappe de ce genre et a pu récupérer plein d’informations provenant d’équipements différents (imprimantes, PC, serveurs, etc…) qui cherchaient à se connecter à une adresse légitime.

6. L’histoire d’un bug vieux de 20 ans – Florian Ledoux

Présentation de la détection et l’exploitation d’une faille vieille de 20 ans permettant une élévation de privilèges sur les plateformes Windows NT à Windows 8. Cette faille est publique et n’a toujours pas été patchée.

7. Cloud iso 14001 – Low-Power ARM-based grsec-enabled server – Arnaud Ebalard

L’orateur explique son cheminement, le choix matériel ainsi que la mise en place d’un mini serveur de stockage à la maison. Les informations détaillées sont disponibles ici : natisbad.org.

8. WTF avec Suricata – Éric Leblond

WTF : Word Terminator Flow

Création de règles Suricata/Netfilter pour éviter le transfert de fichiers Word :

• Possibilité de faire de la QoS avec TC ;
• Fonctionnalité d’anti-évasion avec stockage du fichier ;
• Version longue de la rump aux RMLL cet été et informations disponibles ici : https://home.regit.org/2012/10/defend-your-network-from-word/

9. Rump Pub!

• Botconf à Nantes, les 5 et 6 décembre 2013 ;
• GreHAck à Grenoble, le 15 novembre 2013 ;
• OWASP EU Tour 2013 à Sophia Antipolis, le 24 juin 2013.

10. Raspberry Spy – Antoine Cervoise (Devoteam)

Présentation d’une petite machine d’interception de paquets réseau basée sur le modèle du keylogger physique.

Objectif : coûter moins de 50$, donc basé sur un Raspberry Pi avec, notamment l’ajout d’un deuxième port Ethernet (via USB). Fonctionne très bien, relativement discret, il a été posé en environnement de bureau pendant 2 semaines sans être vu.

Limites : alimentation en USB (machine cible ou secteur), ne supporte pas la PoE, batterie possible mais 3 heures maximum, pour le moment.

Les slides sont disponibles sur le site perso d’Antoine : http://www.antoine-cervoise.fr/wp-content/uploads/2013/06/SSTIC-2013-Raspberry-Spy-Rump-A.-Cervoise.pdf.

11. me@your.home – how to succeed in your robbery 2.0 – Deux stagiaires de QuarksLab

Géolocalisation via Twitter et autres, pour savoir si vous êtes à distance de votre logement et donc si votre appartement ou maison est sans protection.

12. IOC – Ivan Fontarensky

Présentation d’un outil  de classification des attaques, comme celui utilisé par Mandiant.

13. Démo de la présentation du noyau Ada ayant eu lieu le matin même – Arnauld Michelizza

L’orateur montre un exemple de retour console lorsqu’il y a une erreur dans le code. Il corrige cette erreur sous nos yeux, il n’y a alors plus d’erreur lors de l’exécution. Il « ping » la machine pour prouver que ça fonctionne.

14. Stack overflow vs stack-based buffer overflow – Aurélien Francillon

L’orateur explique la différence entre les deux et donne un exemple en Ada.

15. Analyse d’AD – Philippe Biondi

L’orateur présente un outil qu’il a créé pour analyser des AD. Il scan l’AD, ou la forêt d’AD, enregistre les informations (fichier ntds.dit) dans une base de donnée (mongodb), puis utilise des « miners » pour analyser les informations récupérées.

Son outil offre la possibilité de faire des analyses différentielles entre deux versions d’un même AD (une propre et une autre contenant une backdoor, par exemple).

Les rapports peuvent être exportés en dump live, REST ou CSV (via zip).

16. PandaOCR – Romain Leonard (Devoteam)

Présentation d’un outil d’OCR en Python pour capter les PIN de sites bancaires, donc sur des images minimalistes. Il a ensuite agrémenté son outil pour les CAPTCHA utilisant des polices rares. Le projet est disponible sur github : https://github.com/Plopi42/PandaOCR.

17. Hack my CCTP – Anonyme (capuche, lunettes et hélium)

Présentation humoristique sur la rédaction de réponse à un appel d’offres, ou comment faire jouer les chiffres en sa faveur.

Vidéo disponible ici : http://www.dailymotion.com/video/x10opn8_hack-my-cctp_fun

18. RW2 – XXX

Le RW2 est le format RAW utilisé par les appareils Panasonic. Il permet de corriger plus facilement les images et donc d’obtenir de bons résultats sans investir dans un reflex. Il y a plein d’outils sur Windows et MAC pour traiter ce format, mais rien sur Linux et Panasonic ne fournit de documentation permettant de créer son propre outil. L’orateur a tenté de « reverser » les outils existant, mais cela s’avère extrêmement complexe.

Il n’a donc pas réussi à créer un outil de traitement de RW2 sous Linux et cherche d’ailleurs des personnes souhaitant participer à son projet.

19. PhotoRec – Récupération de données – Christophe Grenier

Présentation de PhotoRec, un outil sous licence GPL et multiplateforme, permettant la récupération après suppression de photos ou tout autre type de fichiers. La grande nouveauté étant un mode graphique venant d’être ajouté à l’outil qui jusque là n’était disponible qu’en CLI. Le site du projet : http://www.cgsecurity.org/wiki/PhotoRec.

20. Je choisis l’option offensive ou pourquoi il ne faut pas s’auto-intoxiquer –  Florent Chaveau

Rapide prise de parole par le FSSI du Ministère de la Défense : « Est-ce que vous préférez être surveillé par votre État démocratique ou par une multinationale américaine ? ». Il précise que l’État n’a pas l’intention d’acheter de 0day, mais qu’il recrute activement !

21. TNS Hijack – Un employé de chez Synacktiv

Présentation d’une attaque de type Man In The Middle sur un TNS Oracle. Par défaut, Oracle ne met pas de protection sur sa couche transport.

Objectif de l’attaque : SQLi arbitraire, sans perturber le client, sans crasher.

Difficultés : pas de documentation, pas d’outil, pas de structure claire de type TLV, etc.

Résultat : hijacking du flux TNS, injection à la volée de requêtes SQL arbitraires.

Évolutions : interception de commandes, récupération de mots de passe, code propre.

L’orateur nous fait une démonstration pour conclure.

Propos recueillis par: Geoffrey Bertoli, Antoine Cervoise, Brice Duprieux, Yannick Fournel, Romain Léonard, Julien Vallet et relu par Isabelle Feetz.