Retour sur la Hack In The Box Amsterdam 2016

Retour sur la Hack In The Box Amsterdam 2016

Une semaine avant le très populaire SSTIC, XMCO était présent à Hack In The Box Amsterdam (#HITBSECCONF2016). Cette dernière a eu lieu les 26 et 27 juin 2016, au grand hôtel NH Collection Krasnapolsky.

Nous ne présenterons ici que quelques-unes des conférences, vous pourrez retrouver l’ensemble des résumés dans l’édition #44 de l’ActuSécu !

Les supports de présentation sont disponibles sur le site de la HITB, à l’adresse suivante : https://conference.hitb.org/hitbsecconf2016ams/materials/

Virtualization System Vulnerability Discovery Framework, par Tang Qinghao

SLIDES

La virtualisation est un élément de plus en plus populaire auprès des particuliers et des entreprises de par l’utilisation intensive du Cloud. La sécurité de ces environnements et des conteneurs est d’autant plus cruciale que le panel de services proposés au travers ces environnements cloud est de plus en plus diversifiés (Mail, Stockage, Calcul, hébergements) et que le nombre d’acteurs présents sur le marché se multiplie : Google, Dropbox, Amazon, Microsoft, etc.

L’introduction des hyperviseurs dans l’architecture (déjà complexe) des systèmes d’information introduit de nouveaux risques comme :

  • l’échappement d’un environnement virtualisé,
  • les fuites d’information entre systèmes invités,
  • la prise de contrôle du système hôte.

Tang Qinghao, un chercheur travaillant pour Qihoo 360, une société chinoise éditant un logiciel antivirus, a présenté les travaux de recherche de ses équipes sur un système de fuzzing dédié aux hyperviseurs. Le framework développé ne présente en soit pas de nouveautés particulières ; la méthodologie appliquée restant le propre du fuzzing:

  1. Analayser les données et les flux entres les différents composants de la machine virtuelle
  2. Altérer ces données et mesurer les temps d’exécution résultants
  3. Enregistrer toutes les activités anormales, dont les plus minimes
  4. Analyser ces activités et en trouver la raison

Parmi les points intéressants, on retiendra que le principal vecteur de failles de sécurité repose sur l’émulation des composants matériels et non sur l’émulation du système d’exploitation même. L’utilisation de ce framework dédié aux environnements virtualisés leur a ainsi permis de découvrir 9 vulnérabilités au sein de QEMU, et 2 vulnérabilités affectant VMWare Workstation en seulement 90 jours. L’exploitation de ces failles permettait à un attaquant accédant à un environnement virtuel de s’échapper de l’environnement cloisonné pour accéder au système hôte.

Les vulnérabilités découvertes par son équipe ont depuis été corrigées. Elles sont référencées CVE-2015-5225, CVE-2015-5279, CVE-2015-6815, CVE-2015-6855, CVE-2015-8345, CVE-2015-7504, CVE-2015-7549, CVE-2015-8567, CVE-2015-8568, CVE-2015-8558, CVE-2015-8613, CVE-2015-8701, CVE-2016-1568, CVE-2016-1570, CVE-2015-2392.

Telescope: Peering Into the Depths of TLS Traffic in Real-Time, par Caragea Radu

SLIDES

Caragea Radu, chercheur en sécurité travaillant pour BitDefender, a présenté un nouvel outil permettant d’extraire des clés TLS manipulées dans une machine virtuelle depuis l’hyperviseur. Cette nouvelle méthode détecte la création de clés de session TLS en mémoire lorsqu’une machine virtuelle se connecte à un site web.

Cette présentation ne faisait pas l’objet d’une attaque sur la cryptographie, ni sur les protocoles cryptographiques ou leur implémentation. L’objet de cette présentation était une extraction des données en mémoire depuis l’hyperviseur d’une machine virtuelle.

Après avoir présenté les différentes techniques d’interceptions et déchiffrement des flux TLS (tel que l’affaire controversée du certificat Superfish ou l’outil PANDA). Caragea Radu s’est basé sur l’outil PANDA mais a optimisé le processus de récupération des clés en rendant cette étape beaucoup plus rapide et portable.

Lorsque la connexion TLS est active, les clés sont stockées dans la mémoire de la machine virtuelle. Néanmoins, l’emplacement de ces clés est inconnu et copier le contenu intégral de la mémoire vive est beaucoup trop long pour déchiffrer les flux en temps réel (une copie de 4 Go de mémoire est supérieure à 10 secondes).

Pour optimiser cette étape, le chercheur traque les « handshake » SSL et copie uniquement le différentiel de mémoire avant et après l’établissement de ce handshake. Ceci a pour conséquence de réduire drastiquement la taille du « dump » mémoire.

Finalement l’application Telescope fonctionne de la façon suivante :

  1. Filtre les événements réseau de la cible et les envois à Netfilter
  2. Enregistre les messages « hello » du serveur (handshake TLS)
  3. Arrête l’enregistrement et copie (dump) les pages mémoires
  4. Création d’un très petit dump de la mémoire (entre 1 et 10 Mo pour une VM Linux et 15 à 60 Mo pour une VM Windows).
  5. Parcours du dump à la recherche des clés

Pour l’étape 5, le chercheur s’est appuyé sur une suite de bit constante des handshakes (14 00 00 0C) pour identifier et récupérer la clé de chiffrement.

Le chercheur a effectué une démonstration en déchiffrant une connexion au serveur Gmail de Google.

Cette nouvelle méthode implémentée dans Télescope pourrait être appliquée à d’autres protocoles. Ce « proof of concept » montre qu’il est possible de réaliser des attaques de type « hypervisor-in-the-middle ».

SandJacking: Profiting from iOS Malware, par Chilik Tamir

SLIDES

Chilik Tamir, chercheur travaillant pour la société californienne Mi3 Security, a découvert de nouvelles attaques permettant d’installer des applications malveillantes sur un appareil iOS non « jaibreaké ». L’une des vulnérabilités qu’il a réussi à exploiter n’est toujours pas corrigée par Apple.

Le chercheur a commencé sa présentation en expliquant que le processus de création de certificats pour développeur avait évolué depuis Xcode 7. Xcode est l’environnement de développement proposé par Apple pour Mac OS X et iOS. Il permet de programmer et de tester ses applications.

Depuis la version 7 d’Xcode, il est ainsi possible de créer un certificat en enregistrant simplement un identifiant Apple. Créer un identifiant Apple demande uniquement une adresse email et un nom. Ces informations peuvent facilement être falsifiées, permettant ainsi de dissimuler son identité et d’obtenir un certificat « anonyme ».

Ces certificats développeur permettent de déployer une application sur un appareil Apple, sans passer par l’Apple Store. Cela permet donc de contourner le processus de revue de code. Bien que ces applications n’aient pas accès à toutes les fonctionnalités offertes par Apple (Apple Pay, Game Center, iCloud, etc.), elles peuvent être de nature malveillante (accès aux données GPS, au carnet d’adresses ou encore aux données de santé contenues dans HealthKit).

Tamir a créé un outil « proof-of-concept » appelé « Su-A-Cyder » qu’il avait déjà présenté à la conférence Black Hat Asia. Son outil permet de remplacer une application légitime par une version malveillante qui se comporte de façon similaire à l’originale. Celle-ci permet ensuite à l’attaquant de prendre le contrôle de l’application. Néanmoins, l’installation s’effectue grâce au câble reliant l’appareil iOS au poste de travail et par conséquent, nécessite un accès physique à l’appareil et la connaissance du code de déverrouillage. Ce type d’attaque est donc très ciblé (espionné sa femme, ses enfants ou une personne très ciblée). Les lieux d’attaques idéals sont les réparateurs de téléphones, baptisés à l’occasion les « Pawn Store ».

Cette vulnérabilité a partiellement été corrigée par Apple. En effet, depuis iOS 8.3, il n’est plus possible de remplacer une application sur un appareil iOS par une version modifiée en indiquant le même numéro de bundle (paquet). Cependant, Tamir a découvert que son attaque est toujours réalisable et a créé un outil baptisé « SandJacking ».

Apple a en effet corrigé la vulnérabilité dans le processus d’installation, mais pas dans le processus de restauration. L’attaquant est en mesure de créer une sauvegarde de l’appareil, de supprimer ensuite l’application légitime pour installer l’application malveillante et enfin de restaurer la sauvegarde sur l’appareil.

Tamir a bien précisé que cette vulnérabilité donne accès uniquement à la « sandbox » de l’application.

  • La « sandbox » d’une application contient les éléments suivants :
  • Les documents, les fichiers et la base SQLite
  • Les cookies de sessions
  • Les préférences
  • Les fichiers temporaires

Une démonstration a été réalisée avec l’application Skype. Un attaquant souhaitant accéder à plus de données devra créer plusieurs applications malveillantes.

Il n’est pas trivial de se rendre compte qu’une application n’est pas légitime puisqu’il faut explorer les paramètres système de l’appareil afin de constater que l’application n’est pas signée par le certificat original. De plus, en modifiant le numéro de version avec un numéro très élevé, l’application malveillante ne sera jamais mise à jour.

La vulnérabilité a été reportée et confirmée en janvier 2016 à Apple. Lorsque le correctif sera déployé, Tamir publiera son outil SandJacker qui automatise le processus de restauration avec une application malveillante.

 

New Methods for Exploiting ORM Injections in Java Applications, par MMikhail Egorov et Sergey Soldatov

SLIDES

MMikhail Egorov et Sergey Soldatov ont présenté les techniques d’injection de code au sein des ORM les plus populaires pour développer des applications. Les « Object Relationnal Mapping » (ORM) sont des bibliothèques très utilisées par les développeurs afin de requêter des bases données et de manipuler leurs entrées sous forme d’objets. Le principe de base est de créer une base de données orientée objet à partir d’une base de données relationnelle en définissant des correspondances entre les données de la base de données et les objets du langage utilisé. Pour exemple, l’interface de programmation Java Persistence API (JPA) est généralement utilisé pour les applications développées en Java afin d’organiser des données relationnelles dans des applications. Un des objectifs de cette méthodologie est de s’abstenir de réaliser des requêtes SQL manuellement. Par nature, les injections basiques SQL ne s’appliquent donc pas aux ORM, car les données reçues en entrées sont typées et paramétrées. Toutefois, le manque de validation des données dans les codes des développeurs permet d’accéder quand même au contenu de la base de données sous-jacente en injectant du code propre à chaque ORM. Ces injections sont toutefois plus complexes à identifier que de simples injections SQL, car aucun outil aussi puissant que SQLMap ne permet de les mettre en évidence aisément.

L’interface de programmation JPA utilisée pour les ORM dispose également de deux sous langages : JPQL et HQL. C’est au travers ces deux interfaces que les injections ORM sont exploitées. C’est pourquoi ces injections sont également appelées injection JPQL ou injection HQL.

Parmi les ORM les plus populaires, les deux présentateurs se sont concentrés sur les injections ciblant les ORMs Java suivants :

  • EclipseLink (Glassfish)
  • TopLink (Oracle WebLogic)
  • Hibernate ORM (WildFly and Jboss)
  • OpenJPA (TomEE and IBM WAS)

Les injections présentées reposent principalement sur des fonctionnalités sur interfaces qui supportent l’intégration de code SQL directement depuis l’ORM, mais également des particularités propres à ces ORM dont les analyses syntaxiques diffèrent des SGDB.

  • EclipseLink ORM dispose d’une méthode « FUNCTION » (ou FUNC) permettant d’appeler des méthodes du SGDB sous-jacent. L’objectif principal est de permettre aux développeurs d’appeler depuis le moteur JPQL des fonctions SQL existantes qui n’existerait pas encore en JPQL. Or il est également possible d’utiliser cette méthode pour requêter non pas une méthode du SGDB mais une clause SQL entière.
  • De même, Oracle TopLink dispose d’une méthode permettant d’effectuer des clauses SQL directement depuis le moteur JPQL. Cette méthode est la fonction « SQL ».
  • La méthode d’injection présentée pour Apache OpenJPA ORM repose sur un défaut de traitement des simples quotes par le moteur JPQL. En effet, ce dernier substitue les séquences de 2 simples quotes par une seule. Par conséquent, après sa substitution le moteur SQL obtient une requête altérée qui est syntaxiquement valide.
  • De même, le moteur d’Apache OpenJPA interprète les doubles quotes comme des simples. Encore une fois, après l’interprétation par le moteur JPQL, le moteur SQL obtient une requête altérée qui est pourtant valide.
  • Enfin, 5 méthodes d’injections pour Hibernate SQL ont été présentées. Elles reposent sur un défaut d’échappement des simples quotes en HQL (pour MySQL), $-QUOTED-STRING (pour PostgreSQL et H2), les Magic fonctions (pour PostgreSQL et Oracle), sur encodage Unicode (pour MS-SQL et H2) et sur  les constantes Java (tous les SGDB à l’exception de MySQL).

 

 


Cert-XMCO