Retour sur l'édition 2014 de la Hack.lu (Jour 1)

Cette année encore, XMCO était partenaire de la conférence Hack.lu. Retour sur l’édition 2014 qui s’est déroulée il y a peu.

Nous décrirons ici quelques une des présentations qui nous ont semblé les plus intéressantes.

Conférences

The Heartbleed test Adventure, par Filippo Valsorda (@FiloSottile)

Filippo Valsorda est un ingénieur au sein de l’équipe sécurité de la société CloudFare. Il est à l’origine du premier outil permettant de tester la célèbre vulnérabilité Heartbleed. Cette conférence n’avait pas pour ambition de faire une nième description technique de la vulnérabilité, mais plutôt d’observer l’évolution d’un service mis en place pour tester si son propre serveur est vulnérable.

Dès la publication de la vulnérabilité sur Twitter, le chercheur a développé une preuve de concept à l’aide du langage Go. Pour ce faire, il a analysé rapidement le correctif de sécurité publié par OpenSSL. Le développement de la preuve de concept fut très rapide grâce à la faible complexité de la vulnérabilité. En quelques heures seulement, il a su développer un script fonctionnel qu’il a publié sur Internet. Il a également développé un site web afin de distribuer des informations autour de cette vulnérabilité.

Il s’imaginait que seul son entourage proche visiterait le site. Mais la charge a évolué très rapidement pour atteindre près de 300 000 000 de tests au bout de 14 jours. Pour subvenir à cette forte demande, Filippo a dû commander plus d’une quarantaine de serveurs.

Dans cette opération de communications, il a pu noter plusieurs problématiques rencontrées :

• le test de la vulnérabilité provoquait un déni de service sur certains serveurs.
• Un administrateur d’une banque l’a contacté, car une erreur au sein des bibliothèques Go identifiait le site de la banque comme étant vulnérable.

Amazon a participé à cette vaste communication en se positionnant en première ligne face aux autorités, aux universités ou autres personnes mécontentes du service. Filippo Valsorda fut ainsi protégé contre les plaintes qui lui étaient adressées. Toutes ces plaintes furent prises en charge par l’équipe sécurité d’Amazon. Malgré le fait que ce service soit à la limite de la légalité, le chercheur n’a donc eu à craindre aucune poursuite judiciaire.

Funcap: Rapid reversing with IDA Pro, par Andrzej Dereszowski (@deresz666)

SLIDES

Aucun outil ne permet de faire le lien entre Ollydbg et IDA Pro, deux des principaux outils utilisés pour faire du reverse-engineering. Pourtant, ces deux outils sont complémentaires.

Ollydbg permet de faire l’analyse dynamique. Il est généralement utilisé pour étudier la phase dite de « unpacking » d’un malware. IDA Pro permet quant à lui de réaliser une analyse statique d’un malware. Un chercheur ne peut pas réaliser l’étude dynamique et l’étude statique de manière simultanée. Chaque phase est réalisée de manière séparée. Pour parer à cette lacune, Andrzej Dereszowski a développé un outil nommé FunCap qui permet d’interconnecter ces deux programmes.

Voici les principales fonctionnalités de FunCap :

• Support de nombreuses plateformes, et notamment des architectures ARM. Il devrait donc être également compatible avec iOS ou encore Android.
• Possibilité de réaliser un « RunTime graph » qui permet de comprendre comment fonctionne les différents packers utilisés. Ce type de graphique permet d’unpacker de manière simple les packers les plus compliqués.
• Fonctionnalité d’ajout de points d’arrêt sur chaque appel de fonction (permet d’identifier des appels indirects sur certaines fonctions).
• Déchiffre et affiche l’ensemble des variables passées au travers des différentes fonctions d’un malware. Cette technique permet notamment d’identifier les chaines de caractères obfusquées de manière simple. FunCap les surligne dans IDA Pro afin de pouvoir rapidement les identifier.
• L’ensemble des fonctions exécutées est surligné d’une couleur différente afin d’identifier les zones de code mort. Cette technique est assez courante chez les créateurs de malware afin de complexifier le travail des analystes.
• L’outil est utilisable directement via l’invite de commande IDA Pro.

La conférence se conclut avec la présentation, en vidéo, de l’analyse de 3 malwares afin de mettre en valeur les bénéfices de l’outil. En quelques clics, les serveurs de Commandes et Contrôle (C&C) utilisés par les différents malwares ont ainsi pu être identifiés.

Stripping the controversial FinFisher application for Android phones, par Attila Marosi (@0xmaro)

Durant cette conférence, Attila Marosi nous a présenté FinFisher, un logiciel malveillant utilisé par de nombreuses agences gouvernementales. FinFisher est en effet un spyware commercial édité par la société anglaise Gamma Group International. Sa première apparition remonte à septembre 2012 après avoir été analysée en détail par une société canadienne.

En août 2014, Gamma International a été piratée. 40 GB de données de documents ont ensuite été publiées sur Internet, avec notamment le code source de l’application Android FinFisher. De nombreuses versions du malware sont disponibles au sein des documents publiés. Néanmoins, seule la version 4.21 a été analysée, car elle correspondait à une version de Q&A. Par conséquent, elle n’était pas obfusquée et donc plus facile à analyser. De plus, la plupart des autres fichiers APK étaient chiffrés à l’aide d’une clé PGP.

Attila Marosi a commencé par étudier les permissions demandées par le malware. En effet, chaque application doit référencer toutes les permissions dont elle a besoin. L’application demande par exemple l’accès aux SMS, au logiciel WhatsApp, ainsi qu’à d’autres droits assez intrusifs.

Le chercheur a ensuite identifié le fichier de configuration utilisé par le malware. Ce fichier est obfusqué. Il s’agit d’un simple conteneur au format ZIP ne contenant aucun fichier. Dans celui-ci, de nombreuses chaines de caractères sont décimées au sein des fichiers fictifs. En rassemblant l’ensemble de ces blocs disséminés, Attila Marosi a été en mesure de reconstruire une chaine encodée en base64. Ce fichier de configuration décrivait :

• la gestion des données mobiles (3G) ;
• la gestion des SMS ;
• la passerelle à utiliser ;
• l’intervalle de rafraichissement entre les différents envois d’informations ;
• etc.

L’ensemble des données récupérées sur le téléphone (SMS, appels…) est ainsi exfiltré par le malware via la connexion 3G ou le WiFi du téléphone. De plus, les attaquants faisant partie des forces de l’ordre ou d’agences gouvernementales, ils sont en mesure de masquer de manière assez simple l’exfiltration des données.

Afin de piloter le malware, les commandes lui sont envoyées par SMS. Pour ne pas alerter leurs victimes, les appels systèmes d’Android étaient surchargés. Pour cela, tous les SMS reçus sont analysés. Si un SMS s’avère être une commande, la méthode « AboartBroadcast » est appelée afin qu’aucune application, ni même le système d’exploitation ne puissent avoir connaissance de ce message.

Une des principales faiblesses du malware provient de la clé de chiffrement utilisée. L’algorithme de chiffrement AES est utilisé avec une clé d’une longueur de 4 bytes. Cette clé peut donc être facilement cassée par recherche exhaustive. Lors de la démonstration, moins de 5 minutes ont suffi pour retrouver la clé à partir d’un fichier PCAP. Cette clé est notamment utilisée pour chiffrer les messages envoyés entre le serveur de commande (C&C) et le malware. Par ailleurs, aucune vérification n’est effectuée sur les commandes envoyées au malware. Le seul paramètre requis est l’IMEI de la victime. Ce mécanisme permettait de s’assurer que le message reçu arrivait à bonne destination. Ainsi, tous ceux qui possèdent la clé de chiffrement et connaissent le format des commandes utilisées sont en mesure d’envoyer des commandes à exécuter.

La dernière version du malware est la 4.51. Elle dispose d’une fonctionnalité de capture d’écran. Cependant, pour effectuer ce type d’action, l’application doit disposer des droits les plus élevés. Le malware embarque pour cela un code d’exploitation lui permettant d’élever ses privilèges. Au sein de cette nouvelle version, le fichier de configuration est désormais chiffré. Néanmoins la longueur de la clé de chiffrement n’est toujours que de 4 bytes.

L’ensemble des outils présenté est disponible à l’adresse suivante : http://finspy.marosi.hu/tools-for-finspy/

Bypassing Sandboxes for fun… Profit will be realized by sandbox vendors, par Paul Jung

SLIDES

Dû à la forte croissance de l’utilisation des machines virtuelles et des moyens de protection de type sandbox, le premier réflexe d’un attaquant est d’identifier si son malware est exécuté dans un environnement « hostile ». En effet, même pour les attaquants, time is money.

Afin de détecter si le programme est exécuté au sein d’une sandbox voici quelques techniques utilisées par les pirates :

• Exécuter des instructions non supportées.
  • En effet, une sandbox doit émuler le maximum d’instructions bas niveau afin de pouvoir faire le lien avec le micro-processeur. Néanmoins, certaines de ces instructions ne sont pas implémentées. Leur exécution déclenche une erreur qui permettra d’identifier la présence de la sandbox.
• Détection du nombre de CPU.
  • En effet, en 2014, tous les ordinateurs ou serveurs disposent de plus d’un processeur. Donc tout environnement possédant un seul processeur sera identifié comme une sandbox.
• Interprétation du comportement des CPU (différents).
  • Les processeurs ont un comportement différent dans un environnement émulé. Toutefois, un benchmark des différentes sandbox est nécessaire afin d’utiliser cette technique.

Par ailleurs, toutes ces méthodes de détection des Sandboxs par les malwares se basent sur des marqueurs bien précis. Un éditeur de malware est donc en mesure de prendre en compte ces éléments pour adapter ces produits rendant ces méthodes de détection inexploitable et relançant de nouveau le jeu du chat et de la souris entre éditeurs et créateurs de malwares.

Extreme Privilege Escalation On Windows 8/UEFI Systems, par Corey Kallenberg, Xeno Kovah, John Butterworth and Sam Cornwell

Le MITRE est une organisation américaine à but non lucratif. Elle travaille notamment pour le département de la défense américain (DOD). Après toutes les révélations faites par Snowden, il est compliqué de statuer sur les intentions réelles du MITRE.

Les problématiques abordées au cours de cette présentation sont assez inhabituelles. Généralement, lorsqu’un attaquant obtient les droits administrateurs sur un serveur, il s’arrête là. Pour les consultants réalisant les tests d’intrusion, c’est le « saint Graal ». Mais que peut-on faire une fois qu’un attaquant a obtenu les droits NT/System. ?

Le premier scénario, pour obtenir un accès privilégié au niveau du noyau (ring 0), consiste à charger un driver signé. Pour obtenir un certificat, il suffit de prouver que vous êtes une société afin de pouvoir acheter un certificat pour 99$ auprès de Microsoft. Mais cette compromission n’est pas suffisante. Il est possible d’aller encore plus loin et de compromettre le poste en amont au niveau du SMM, ou pire, au niveau du firmware (UEFI).

Microsoft a bien compris cette problématique. En compromettant directement le BIOS, un attaquant peut prendre le contrôle d’un système avant même que le système d’exploitation ne soit lancé. Dans ce cas, Microsoft est dans l’incapacité de mettre en place une quelconque protection. C’est la raison pour laquelle les dernières versions de Windows imposent l’utilisation de l’UEFI. Microsoft estime sans doute qu’il n’est affecté par aucune vulnérabilité…

Xeno Kovah a présenté la vulnérabilité liée aux variables EFI. Cette vulnérabilité fut détaillée par son collègue Corey Kallenberg à la conférence HITB 2k14 (voir ActuSécu #38). Pour résumer, sous Windows 8, la méthode nommée « SetFirmwareEnvironmentVariable » permet de modifier les variables non volatiles (stockées au sein de la mémoire flash du processeur). Plusieurs vulnérabilités affectent ce mécanisme.

Notamment, en définissant la variable « Setup » à « ALWAYS_EXECUTE », il est possible de désactiver la « Secure Boot Policy ». De plus, l’exploitation de corruptions mémoires est possible, par exemple la célèbre CVE-1999-0046 (dépassement de tampon au sein de la variable d’environnement TERM). Toutes ces vulnérabilités provenaient d’une mauvaise implémentation de l’UEFI.

Les chercheurs du MITRE se sont donc intéressés au standard UEFI afin d’identifier des vulnérabilités propres au standard et non à une mauvaise implémentation. Ils ont analysé les phases les plus critiques et notamment la gestion des mises à jour.

Lors de l’une d’elles, le système d’exploitation divise le nouveau firmware à installer en de nombreux paquets appelés « Capsules ». Cette opération évite d’écrire de trop larges volumes de données d’un coup. Au cours du redémarrage suivant, la signature de l’enveloppe qui regroupe toutes les capsules est vérifiée. Puis, toutes les capsules sont réorganisées pour installer le firmware.

Pour compromettre l’UEFI, les chercheurs utilisent une technique similaire au Heap Spray. Pour cela, ils vont créer une multitude de variables d’environnement à l’aide de l’API décrite précédemment. Ils vont ainsi créer une mise à jour malveillante en remplissant les différentes capsules. Ensuite, lors du redémarrage, ils sont parvenus à lancer l’installation de la mise à jour malveillante avant que la vérification de la signature soit réalisée.

Il est cependant possible d’obtenir davantage de privilèges grâce au SMM. Le SMM est un espace mémoire protégé. Lors de l’exécution de code au sein du SMM, le programme peut accéder depuis le SMM à l’ensemble des espaces mémoire, mais aucun programme ne peut accéder au programme exécuté dans le SMM. Cette fonctionnalité avait été introduite à l’origine par Intel pour augmenter le niveau de sécurité des systèmes informatiques. Donc, en ayant compromis l’UEFI, il est donc possible d’exécuter du code au sein du SMM, car ce dernier n’est pas protégé pendant un laps de temps assez long au démarrage du système.

Cet accès privilégié permet de réaliser toutes les tâches possibles. Pour démontrer cela, les chercheurs ont décidé de faire une preuve de concept nommée « The Watcher ». Il s’agit d’un petit programme qui va s’exécuter au sein du SMM pour scanner toute la mémoire du système à la recherche d’une signature particulière. Dès qu’il identifiera cette suite d’octet, il exécutera le code ASM qui suivra la signature. Pour des raisons évidentes de performance, toute la mémoire n’est pas scannée par The Watcher. Seules certaines pages mémoires sont scannées. Il suffit donc de remplir une page mémoire avec la signature pour garantir que le watcher identifie la signature. Ce concept permet donc de prendre le contrôle de n’importe quel système infecté. On pourrait imaginer prendre le contrôle d’un serveur avec un simple ping (toutes les données sont à un moment stockées en mémoire).

Un autre exemple serait de réaliser un déni de service en modifiant la première instruction réalisée par le processeur. En effet, à ce stade du démarrage du système, aucun mécanisme de gestion d’erreurs n’existe. De ce fait, la moindre erreur provoque la « destruction » du processeur.

À l’heure actuelle, aucune protection n’existe contre ce type d’attaque. Seuls deux scripts (Copernicus) développés par le MITRE permettent de détecter la présence d’une backdoor à partir du firmware du constructeur. Ils réalisent pour cela un différentiel entre le BIOS du constructeur et celui présent sur le poste.

Nous attendons avec impatience la prochaine édition de cette conférence. En attendant, rendez-vous dans le numéro 39 de l’ActuSécu pour un résumé complet et détaillé de cette édition.

Toutes les slides des présentation réalisées durant la conférence sont disponibles à l’adresse suivante : http://archive.hack.lu/2014/

Twitter : @hack_lu