SecurityInsider
Le blog des experts sécurité Solucom

Reverse Engineering - focus sur l’analyse dynamique de malware

L’analyse dynamique d’un fichier correspond à analyser l’exécution de ce fichier. Cette analyse permet alors de déterminer le comportement réel du malware, là où certains éléments de l’analyse statique peuvent être présents uniquement pour détourner l’attention de l’analyste, ou lui compliquer la tâche.
Une première forme d’analyse dynamique correspond à l’exécution du malware et à l’observation des modifications qu’il entraine sur le système. Cette analyse a le plus souvent pour but de déterminer les actions à effectuer pour supprimer le malware, et/ou créer une signature.
Attention, ce type d’analyse doit absolument être fait dans un environnement contrôlé (machine virtuelle, poste dédié et déconnecté du SI, etc.) afin de ne pas risquer la propagation de l’infection.

1)     Analyse des opérations

L’analyse dynamique permet la surveillance de nombreuses informations : les registres, le système de fichiers et les processus. Cette étape est au début assez fastidieuse étant donné que de nombreuses informations sont accessibles. Il existe différents outils permettant d’accéder à ces informations. ProcessMonitor est l’un de ces outils qui a l’avantage de permettre à l’analyste de filtrer ses recherches sur un exécutable, ce qui est très pratique pour l’analyse de malwares.
Figure 1 : Résultat d’une analyse de ProcessMonitor sur un malware appelé mm32.exe
L’analyse de ces différents éléments permet à l’analyste d’avoir une meilleure compréhension de l’activité du malware. Cependant, étant donné le nombre d’informations renvoyées par ProcessMonitor dont la plupart représentent des évènements standards du lancement d’un exécutable, l’analyse demande beaucoup de pratique et de la patience.
Un autre outil permettant une analyse poussée des processus est Process Explorer. Il permet de lister les processus, les bibliothèques chargées par un processus, différentes informations sur ces processus, ainsi que des informations globales sur le système. L’avantage de cet outil est qu’il présente les informations sous forme d’arbre, exposant ainsi les relations entre les processus parents et enfants.
Les informations que Process Explorer renvoie sont le nom du processus, le PID (numéro d’identification du processus), l’utilisation du CPU, une description ainsi que le nom de l’entreprise ayant créé le binaire (champs laissés libres au créateur du binaire…). Par défaut les services sont surlignés en rose, les processus en bleu, les nouveaux processus en vert et les processus terminés en rouge. La vue se met alors à jour à chaque seconde. Lors de l’analyse de malware il est donc intéressant de repérer les différents processus qui sont modifiés ou créés afin de pouvoir enquêter dessus de manière plus approfondie.
Figure 2 : Résultat de Process Explorer sur un exécutable
Ces techniques sont très efficaces pour comprendre ce que fait un exécutable, mais il ne faut pas négliger leur utilité pour déterminer si un document est malveillant ou non. Un moyen rapide de savoir si un PDF est malveillant, par exemple, est de lancer Process Explorer puis d’ouvrir le PDF et de regarder si de nouveaux processus sont créés.
Remarque : Pour l’analyse de documents, il est souvent intéressant d’utiliser des versions intentionnellement non patchées des logiciels afin de s’assurer que l’attaque est efficace. Une bonne manière de faire cela est par exemple de créer plusieurs snapshots d’une machine virtuelle d’analyse, chaque snapshot ayant une version différente, et généralement assez âgée, des logiciels.
Pour l’analyse de registres, l’outil Regshot permet de comparer les registres sur deux snapshots différents. Un extrait de résultat de Regshot peut ressembler à la figure 3.
Dans ce résultat, le premier constat est la création d’un mécanisme de persistance HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run par le programme ckr.exe, le deuxième est la modification de la valeur de la seed pour le générateur de nombre aléatoire, ce qui représente un bruit habituel.
Figure 3 : Extrait de résultat de Regshot après lancement du programme ckr.exe

2)     Analyse réseau

De nombreux malwares récupèrent des ressources ou transmettent des informations sur le réseau (en particulier vers des serveurs C2 « Command & Control »). De ce fait il est très intéressant de réaliser une analyse réseau pour déterminer les actions du malware. L’environnement d’analyse n’étant pas connecté à internet, il se peut qu’une partie des fonctionnalités du malware restent non accessibles. Cependant il est préférable de récupérer de telles informations en faisant une analyse manuelle approfondie plutôt que de permettre au malware de se propager (une sortie directe vers Internet peut néanmoins être fortement utile aux équipes d’analyse).
Quelques outils peuvent permettre d’effectuer une analyse réseau d’un malware :
  ApateDNS permet de récupérer les requêtes DNS faites par le malware. Il permet également de simuler les réponses d’une adresse IP spécifiée en écoutant sur le port 53 de la machine locale via le protocole UDP. Il affiche alors les requêtes reçues en hexadécimal ou en ASCII. Par défaut ApateDNS utilise la passerelle (gateway) ou les paramètres de DNS courants dans les réponses DNS.
Figure 4 : Interception des requêtes DNS et simulation des réponses par ApateDNS en utilisant l’IP 192.168.120.1
  Netcat permet le scan de port, tunneling, proxying, transfert de ports et bien d’autres choses sur des connections aussi bien entrantes que sortantes. Il existe deux modes de fonctionnement pour Netcat, le mode écoute, pour lequel Netcat agit comme un serveur, et le mode connexion pour lequel il agit comme un client.
Remarque : les malwares utilisent souvent les ports 80 et 443 (HTTP et HTTPS respectivement) car ces ports ne sont généralement pas bloqués par les différents équipements de sécurité sur le réseau des entreprises (firewall, proxy, etc.).
Remarque 2 : certains malwares simulent des connexions usuelles afin de cacher leur comportement et tirer parti d’une méconnaissance de nombreux analystes réseau qui ne se concentrent que sur le début d’une session. Par exemple, en figure 5 le reverse shell RShell est instancié avec une redirection du domaine www.google.com vers l’hôte local 127.0.0.1 à l’aide d’ApateDNS. L’analyste écoute ensuite le trafic réseau sur le port 80 local avec Netcat.
Dans ce résultat, RShell simule une requête POST à www.google.com (comme le montre le point 2 sur la figure) mais par la suite, l’analyste récupère bien un shell (visible sur le point 3).
Figure 5 : Résultat renvoyé par Netcat lors de l’exécution de RShell en redirigeant les requêtes vers l’hôte grâce à ApateDNS
  Wireshark permet la capture de paquets et de création de logs pour le trafic réseau. Il permet la visualisation, l’analyse de trames et l’analyse en détail de paquets individuels.
Figure 6 : Capture d’écran d’une analyse Wireshark
Une des fonctionnalités très utiles de Wireshark est la fonctionnalité Follow TCP stream qui permet à partir d’un paquet de reconstituer le flot entier auquel il appartient.
Figure 7 : Fonctionnalité Follow TCP Stream de Wireshark
Wireshark peut permettre à l’analyste de comprendre comment le malware réalise ses communications réseau.

3)     Analyse via débogueur

Étape la plus complexe de l’analyse, l’analyse dynamique avancée correspond au passage de l’exécutable dans un débogueur afin de déterminer les actions qu’il effectue les unes après les autres, ainsi que les différents états qu’il génère sur le poste analysé. Il existe plusieurs débogueurs utilisables pour cette étape, notamment IDA Pro, OllyDbg et WinDbg.
Cette étape est extrêmement efficace mais nécessite de nombreuses connaissances et beaucoup de temps. Dans cette partie sera présenté un aperçu de ce qu’il est possible de faire avec un débogueur. Il est important de retenir que l’analyse dynamique révèle ce que le malware fait véritablement, contrairement à l’analyse statique qui montre ce que le malware est en théorie capable de faire. Certains bouts de code présents dans le malware peuvent en effet ne jamais être appelés, et les repérer durant l’analyse statique peut induire en erreur l’analyste sur l’action du malware.
L’utilisation d’un débogueur permet également d’obtenir des informations impossibles à récupérer avec un désassemblage, comme par exemple les valeurs prises par les registres au fur et à mesure de l’exécution.
Il existe en fait deux types de débogueurs, ceux dits source-level qui sont généralement intégrés dans les IDE et bien connus des développeurs, leur permettant d’agir sur le code source afin de déterminer les comportements étranges de leurs programmes, et ceux dits assembly-level ou low-level qui agissent sur le code assembleur. C’est ce deuxième type de débogueur qui est utilisé par les analystes de malware, étant donné qu’ils n’ont pas accès au code source de l’application.
De même il existe deux niveaux de débogage, celui en mode utilisateur, où le débogueur est lancé sur le même système d’exploitation que le programme en cours d’exécution, et celui plus complexe en mode noyau, qui permet de déboguer des applications ayant ce niveau d’interactions, mais qui nécessite deux machines reliées, l’une faisant tourner le programme, et l’autre permettant le débogage. Une deuxième machine est en effet nécessaire car il n’existe qu’un noyau par système d’exploitation, et si un breakpoint est mis sur une instruction exécutée par ce noyau, plus aucune application ne pourra répondre, le débogueur compris.
Dans les deux cas d’exécution, le résultat sera la mise en suspens du programme. Dans le premier cas le programme sera stoppé dès le point d’entrée (sauf configuration particulière) alors que dans le deuxième il sera arrêté là où il se trouvait. Une fois cela effectué, il est possible d’agir de différentes manières sur le programme :
  Avancer d’une instruction (single-stepping) : cette action est généralement utilisée uniquement sur les passages identifiés comme importants afin d’obtenir des détails sur le fonctionnement comme les valeurs prises par les registres.
  Avancer d’une fonction (Stepping-over) : cela peut permettre de passer des détails inutiles. Par exemple si le programme appelle la fonction LoadLibrary, il n’est pas nécessaire de rentrer dans les détails de cette fonction.
  Rentrer dans une fonction (Stepping-into) : en opposition à l’action précédente, il peut parfois être intéressant de rentrer dans une fonction pour en comprendre les détails.
  Avancer jusqu’au prochain breakpoint : pour cela il faut souvent placer un breakpoint plus loin dans le code et relancer l’exécution, le débogueur s’arrêtera automatiquement au breakpoint.
  Modifier l’exécution d’un programme : par exemple pour éviter l’appel à une fonction, il est possible de mettre un breakpoint sur cette fonction et, lorsque l’interruption est levée, changer le pointeur d’instruction à après son appel.
Il existe trois types de breakpoints :
  Les software breakpoints : ces points d’arrêt sont utilisés pour faire en sorte que le programme s’arrête lorsque l’instruction sur laquelle ils sont placés est appelée. Pour réaliser cela, le débogueur remplace le premier octet de l’instruction par 0xCC, l’instruction pour INT3.
Figure 8 : Remplacement du premier octet de l’instruction par 0xCC lors d’un software breakpoint.
  Les hardware breakpoints : ils sont placés sur une adresse mémoire, et déclenchés lorsque le programme tente d’accéder à cette ressource. L’avantage est qu’ils ne dépendent pas de la valeur présente dans cette adresse mémoire, et qu’ils interviennent à l’accès et non à l’exécution. Néanmoins ils nécessitent des registres particuliers qui sont en nombre limités sur un système.
  Les conditional breakpoints : ce sont des software breakpoints qui ne vont déclencher l’arrêt que si une certaine condition est vérifiée. Cela peut par exemple être utile si l’on veut s’arrêter à l’appel d’une fonction que si un certain paramètre est appelé.
Ces différentes techniques d’analyse dynamique viennent en complément d’une analyse statique.
Il convient néanmoins de prendre toutes les précautions nécessaires avant de se lancer dans une analyse de malware. Chaque résultat obtenu par les analystes doit être contrevérifié pour s’assurer qu’aucune technique anti-reverse n’est mise en œuvre dans le binaire. Nous recommandons au lecteur de poursuivre son voyage au sein du monde du reverse engineering par notre « Tour d’horizon des techniques anti-reverse engineering » (http://www.securityinsider-solucom.fr/2015/05/tour-dhorizon-des-techniques-anti.html).
Vincent NGUYEN

CERT-Solucom : retour sur l'actualité de la semaine du 6 juin


Comme chaque semaine, retrouvez notre revue d'actualité de la sphère cyber-sécurité. Cette compilation de brèves vous permettra d'alimenter les discussions des prochaines pauses cafés !

[Brève] Les dangers du typosquatting, désormais sur les “packets manager”
Après les risques liés à une faute de frappe lorsqu’il s’agit de taper le nom de votre site préféré dans la barre d’adresse, il faut désormais aussi faire attention à ne pas se tromper pour installer des bibliothèques avec votre gestionnaire de paquets. En effet, il est possible de créer un projet avec un nom très similaire à un paquet connu, un utilisateur peu attentif pourrait donc installer sans s’en rendre compte la version malveillante du paquet souhaité. (ex: sudo pip install reqeusts au lieu de sudo pip install requests).
Source :
http://incolumitas.com/2016/06/08/typosquatting-package-managers/
[Brève] Twitter nie la fuite de 32 millions identifiants
Source :
https://blog.twitter.com/2014/keeping-your-twitter-account-safe
[Brève] Keepass et les mises à jour en HTTP(S)
La semaine dernière, nous vous avions parlé des critiques que subissait le fameux logiciel de gestion de mots de passe. En réponse, le développeur principal du projet a décidé de modifier le fonctionnement des mises à jour en passant celles-ci en HTTPS et en ajoutant une signature sur le fichier contenant le numéro de la dernière version disponible.
Source :
http://keepass.info/help/kb/sec_issues.html#updsig
[Brève] La fin des exploits sur la pile?
Intel a dévoilé cette semaine un nouveau mécanisme de sécurité qui pourrait signer la fin des ROP (Return-oriented programming) et JOP (jump-oriented programming). La technique consiste simplement en une shadow stack sur laquelle les adresses de retour sont aussi stockées, ainsi lorsque le processeur atteint une return instruction il va alors vérifier que l’adresse présente sur la stack correspond bien à celle dans la shadow stack.
Source :
http://www.theregister.co.uk/2016/06/10/intel_control_flow_enforcement/
[Brève] Une exécution de code arbitraire dans le lecteur PDF de Google Chrome
Source :
http://www.theregister.co.uk/2016/06/09/chromes_pdf_reader_has_arbitrary_code_execution_flaw/
[Brève] Pourquoi vous ne devriez pas partager de liens sur Messenger
Des chercheurs de Checkpoint ont découvert que les liens partagés au travers de Facebook Messenger peuvent être accédés au travers de l’API proposée par Facebook.
Source :
https://medium.com/@intideceukelaire/why-you-shouldnt-share-links-on-facebook-f317ba4aa58b#.cah8w6w8v
[Brève] Le ransomware Jigsaw contient désormais un chat en ligne pour aider ses victimes
Payer la rançon n’a jamais été aussi simple !
Source :
http://www.darkreading.com/attacks-breaches/ransomware-now-comes-with-live-chat-support/d/d-id/1325879
[Brève] LetsEncrypt fuite 8000 adresses mails par erreur
L’autorité de certification notamment connue pour ses certificats SSL/TLS gratuits a déclaré avoir dévoilé accidentellement un peu moins de 8000 adresses à cause d’un bug dans son système d’envoi automatique de mail.
Source :
https://community.letsencrypt.org/t/email-address-disclosures-preliminary-report-june-11-2016/16867
[Brève] Bitdefender démontre qu’il est possible d’intercepter des flux TLS au niveau de l’hyperviseur
Source :
https://www.helpnetsecurity.com/2016/06/10/telescope-technique/
[Brève] Mozilla va financer des audits pour des projets open source
La fondation Mozilla a annoncé avoir mis en place un fond dédié pour aider des projets open source à se débarrasser des vulnérabilités présentent dans leur code. Le montant alloué est dans un premier temps de $500 000, 3 projets (PCRE, libjpeg-turb et phpMyAdmin) ont déjà eu la possibilité de participer à cette offre qui aurait déjà permis de corriger 43 vulnérabilités.
Source :
https://www.helpnetsecurity.com/2016/06/10/mozilla-will-fund-code-audits/
[Brève] Lava, un système pour injecter des bugs dans votre code
Ou comment tester les auditeurs ?
Source :
http://moyix.blogspot.fr/2016/06/how-to-add-a-million-bugs-to-a-program.html

Xavier GERONDEAU

Compte-rendu du SSTIC 2016 - Jour 1


Du mercredi 1er au vendredi 3 Juin 2016 s’est tenu le Symposium sur la Sécurité des Technologies de l’Information et de la Communication (SSTIC), qui a rassemblé plus de 450 participants pour sa 14e édition.
Trois jours de conférences techniques se sont enchaînés, alternés d’un cocktail et du traditionnel « Social Event » en centre-ville de Rennes. Pas moins de 35 conférences ont été présentées par 59 orateurs, et 35 rumps (présentations très courtes de 3 minutes maximum) ont permis de détendre l’atmosphère jeudi après-midi. Le programme complet est disponible sur le site du SSTIC https://www.sstic.org/2016/programme/.

Voici le compte-rendu de la première journée.
Conférence d’ouverture
La conférence d’ouverture a été présentée par Brad Spengler, auteur du projet grsecurity. Pour rappel, grsecurity est un projet de durcissement du noyau Linux visant à améliorer sa sécurité et à le protéger d’un large éventail d’attaques. Brad a commencé par détailler les nombreuses améliorations qui ont récemment été apportées à grsecurity (support ARM, protection contre des exploits récents, blocage des périphériques USB qui n’étaient pas branchés au boot – désactivable à la demande), y compris dans PaX, le patch en charge de la gestion de la mémoire (le but étant d’empêcher les corruptions de mémoire, qui peuvent conduire à de l’exécution de code).
Ensuite, l’auteur a donné son point de vue sur l’écosystème de la sécurité de l’information dans son état actuel : les acteurs de la sécurité manquent de recul et de regard critique, et succombent parfois au sensationnalisme (ce qui n’est pas sans rappeler le kickstarter proposant un routeur Tor pour protéger ses communications qui avait rencontré un vif succès avant que plusieurs failles de sécurité ne soient révélées). Il y a selon lui trop de conférences, décevantes au niveau de la qualité des articles et des présentations, qui ne sont par ailleurs pas forcément le meilleur moyen d’effectuer des transferts de connaissance. Il y a également trop « d’experts » qui se plaignent de l’état de la sécurité sans rien créer ou publier.
Enfin, d’après Brad : “il y a de plus en plus de bugs, mais la sécurité s’améliore”. Les attaques à l’état de l’art deviennent plus difficiles à réaliser, tandis que beaucoup de menaces plus « anciennes » continuent de peser sur les utilisateurs, comme les macros Office.
La conclusion de cette conférence d’ouverture, qui fait écho à la conférence de clôture est la suivante : « Security will never be achieved through bug reduction ». La sécurité doit être prise en compte dès la phase de conception, au lieu de consister à réparer les différentes failles au fur et à mesure de leur découverte.

La journée s’est poursuivie avec plusieurs conférences :
Démarche d'analyse collaborative de codes malveillants
A. Chevalier, S. Le Berre, et T. Pourcelot (ANSSI / SOGETI) ont présenté un outil d’analyse collaborative de logiciels malveillants nommé Polichombr, publié sur le Github de l’ANSSI. Dans leurs travaux d’analyse et de rétro-ingénierie des logiciels malveillants, les auteurs ont été confrontés à la difficulté de traiter un grand volume de code de manière collaborative et ont décidé de créer Polichombr pour les assister. Cet outil permet notamment :

  • Une centralisation des informations et du stockage des fichiers ;
  • L’automatisation de tâches d’analyse (calcul des empreintes, découvertes des zones intéressantes dans le binaire…) ;
  • La classification automatique des logiciels malveillants à l’aide de l’algorithme maison « MACHOC », qui utilise des patterns dans le « graphe de flot de contrôle » (Control Flow Graph en anglais) invariants lors d’une recompilation ;
  • La synchronisation avec IDA pour récupérer le travail d’autres analystes (plugin Skelenox) ;
  • L’export de règles de détection Snort et d’IOC (Indicators of Compromission) OpenIOC.
Gunpack
Julien Lenoir (Airbus) a présenté un outil développé en interne permettant de développer facilement des scripts d’unpacking en Python, pour des binaires Windows 32 bits. Les techniques de « packing » consistent à compresser, voire chiffrer tout ou une partie d’un binaire original. Dans le cas d’un logiciel malveillant, la charge utile est donc dissimulée et peut échapper aux contrôles des antivirus. Gunpack, qui s’est inspiré du moteur d’unpacking MutantX-S, effectue une reconstitution dynamique du payload à l’exécution en instrumentant l’OS pour suivre l’exécution du packer, et en tirer les informations utiles à l’écriture d’un unpacker.
Cryptanalyse en boite noire de chiffrement propriétaire : étude de cas
Pierre Capillon (ANSSI), a présenté de manière didactique une analyse récemment effectuée sur un boîtier utilisant un algorithme de cryptographie propriétaire. L’accès physique au boîtier étant interdit, seules les attaques logiques ont pu être réalisées. Pendant 6 semaines, l’auteur a étudié les mises à jour du fimware disponibles publiquement pour comprendre le format de fichier utilisé, l’architecture de la puce, et a fini par trouver des vulnérabilités dans le firmware. De nombreuses techniques d’analyse, fructueuses ou non, ont été présentées, parmi lesquelles le calcul d’entropie du fichier à l’aide de binwalk (permet de savoir s’il s’agit d’un payload chiffré notamment), l’observation des modifications au niveau binaire entre des versions différentes du firmware, le fingerprinting de données binaires (formats de fichiers connus par exemple) et de structures habituelles de code… On retiendra notamment la capacité de l’auteur à identifier l’empreinte SHA256 de la chaîne vide dans un blob binaire, ou l’utilisation par le constructeur de l’algorithme ROT13 pour obfusquer des en-têtes ASCII. En conclusion, l’auteur souligne que la cryptographie propriétaire peut s’attaquer beaucoup plus facilement qu’on ne le croit.
Eurisko : développement d’une carte électronique sécurisée
7 agents de l’ANSSI sont ensuite venus présenter le projet Eurisko, prototype d’une carte électronique mettant en œuvre une chaîne de démarrage sécurisé intégrant un mécanisme d’authentification pré-boot. Eurisko a des objectifs fonctionnels et de sécurité et embarque notamment deux interfaces Gigabit ethernet sur une carte de 7x7cm à faible dissipation thermique (pas de ventilation), sur une base Linux grsecurity et une « base de code maîtrisée ». La chaîne de démarrage ne repose pas sur la sécurité de la BootROM (interne au System on Chip – abrégé SoC – puce centrale d’un circuit imprimé) mais sur un composant sécurisé dédié, certifié EAL 5+, contenant une mémoire flash protégée en confidentialité et en intégrité, ainsi que de sa propre source d’entropie et de fonctions d’accélération cryptographie matérielles. Notamment, l’intégrité et la sécurité des communications au sein même du circuit imprimé (notamment avec le SoC) sont vérifiées, pour qu’enfin le système d’exploitation soit déchiffré et exécuté depuis une carte microSD. La partie logicielle a également été durcie en respectant la norme C99, en interdisant l’allocation dynamique (prévention de la corruption de mémoire) et en gardant le code linéaire et synchrone (prévention des race conditions).
Évolution et dé-évolution des systèmes multimédia embarqués
F. Pollet (Thales) et N. Massaviol (Toucan System) ont présenté une étude anonymisée de la sécurité des systèmes embarqués dans les véhicules, basée sur leurs expériences avec des grands constructeurs français. Ils ont notamment pu constater les différences d’architecture des systèmes multimédias. Les résultats sont sans appel : backdoors présentes dans certains composants (souvent à l’insu du constructeur) livrés par des prestataires, interfaces de développement non désactivées, ou mires de login facilement accessible, les points d’entrée sont nombreux et relativement facilement accessibles. Il leur a ainsi été possible de récupérer le contenu du fichier /etc/passwd (ou /etc/shadow) pour « rooter » le véhicule, ou d’exploiter l’absence de signature des mises à jour pour flasher un firmware arbitraire. Les systèmes d’exploitation utilisés dans les exemples étudiés étaient soit Android 2.2 ou 4.0 – pour lesquels plusieurs vulnérabilités sont connues – soit Linux, utilisant parfois un compte root sans mot de passe.
L’exploitation de ces vulnérabilités permet le détournement des fonctionnalités légitimes (diffuser du son à fort volume ou désagréable pour déstabiliser le conducteur), l’accès à internet, et potentiellement le contrôle des composants connectés au bus CAN. Enfin, les évolutions à venir dans le domaine de l’automobile comme le contrôle à distance pour le covoiturage (ouverture par smartphone), le platooning (véhicules qui se suivent de manière automatique pour former des convois) ou l’apparition de véhicules complètement autonomes, vont présenter des risques encore plus importants et nécessitent une maîtrise des risques bien plus rigoureuse de la part des constructeurs.
USB Toolkit : USBIQUITOUS
Benoît Camredon (Airbus Group) a présenté une série d’outils open-source d’analyse USB, permettant d’interagir avec les composants connectés ou directement avec l’hôte. Parmi les nombreuses possibilités offertes, nous pouvons noter la présence d’un proxy USB intégrant un dissecteur de paquets, d’un « pare-feu USB » en mesure de bloquer les clés USB, d’un keylogger, d’un fuzzer, mais aussi d’un scanner permettant de connaître les drivers USB disponibles sur l’hôte. Un mode « keyboard » permet aussi de réaliser des attaques similaires au Rubber Ducky en émulant un clavier, et un mode « replay » permet de rejouer des trames USB, qu’il s’agisse d’un lance-missile USB ou d’une impression vers une imprimante.
Confusion de type en C++
Florian Saudel, d’AMOSSYS, a expliqué la problématique des confusions de type en C++, où des hypothèses non vérifiées sur le type des objets passés à une fonction permettent d’exécuter du code arbitraire. Ces attaques reposent sur une mauvaise utilisation du polymorphisme et la présence de « bad cast ».
Composants logiciels vérifiés en F* : Poly1305
Jean-Karim Zinzindohoué (INRIA, équipe Prosecco) a présenté un langage de programmation fonctionnelle moderne dédié à la vérification formelle : F*, ainsi que son utilisation dans l’implémentation d’une primitive de code d’authentification de messages (Message Authentication Codes, mieux connus sous l’abréviation MAC) : Poly1305. Pour rappel, la vérification formelle permet d’assurer par des preuves mathématiques certaines propriétés d’un programme, comme le fait qu’il ne peut pas crasher, ou la confidentialité des données. Ces travaux font notamment suite à la publication d’une implémentation formellement vérifiée de TLS : miTLS, également développée par l’équipe Prosecco de l’INRIA.
My friends botnet: How to use your friends to perform Cyber Int?
Amaury Leroy (CERT Airbus Group) a présenté son projet de crawler dont le but est de récupérer des données diverses dans le cadre d’une veille : détection de mots-clés ou de changements significatifs dans l’infrastructure réseau (Whois, SSL, DNS par exemple).  Le passage à l’échelle sur les solutions cloud classiques comme Amazon EC2 est problématique car effectuer des millions de requêtes DNS ou de recherches Google par jour provoque un blocage rapide du crawler. L’auteur a donc réalisé un botnet en utilisant des Raspberry Pi et en les déployant chez des amis pour récupérer les informations nécessaires. Sa solution utilise notamment du SSH avec port knocking, le framework Rebus pour la communication, et Selenium / PhantomJS pour le scrapping d’informations.
Broken Synapse
Ivan Kwiatkowski a présenté une attaque contre le jeu de stratégie Broken Synapse, lui permettant de lever le brouillard de guerre et de gagner un avantage significatif dans ses parties en ligne. Il a pour cela d’abord intercepté les données HTTP échangées avec le serveur, sans réussir à interpréter les données retournées par le serveur. Il a ensuite choisi de reverser le code du jeu pour désactiver le brouillard de guerre quel que soit le mode de jeu, ce qui peut permettre à un attaquant de gagner facilement des parties et de monter au classement sur Steam de manière déloyale.
Un FizzBuzz pour le cyber
Éric Jaeger et Olivier Levillain ont présenté un questionnaire élaboré pour la sélection des candidats à la formation « Experts en SSI » du centre de formation de l’ANSSI, autour de la question : « comment évaluer efficacement un candidat lors d’un entretien ? ». FizzBuzz est un jeu (il faut compter jusqu’à 100 et dire « Fizz » pour les multiples de 3, « Buzz » pour les multiples de 5, et « FizzBuzz » pour les multiples de 3 et de 5) qui est également utilisé comme exercice lors du recrutement de développeurs, de manière apparemment efficace. Plusieurs autres exemples de tests en apparence simple mais révélateurs d’un état d’esprit ont été présentés.

La journée s’est terminée par un cocktail et a permis aux participants de se rencontrer et de discuter des sujets de la journée (et de la crue de la Seine).


Mickaël BERGEM

Retour sur l’affaire SWIFT : synthèse des faits !

Le réseau interbancaire SWIFT a fait beaucoup parler de lui ces dernières semaines. Il est effectivement au cœur d’une affaire cybercriminelle, certainement l’une des plus importantes depuis Anunak / Carbanak en 2015.
Que s’est-il passé exactement ? La sécurité de SWIFT est-elle remise en question ? Quels éléments expliqueraient un potentiel lien avec l’attaque Sony ? Quelles leçons en tirer ? Plusieurs questions auxquelles nous allons tenter de répondre.
Nous vous proposons ici de partager avec vous les résultats de nos efforts de consolidation et de recoupement des nombreuses informations obtenues sur l’affaire.
SWIFT en quelques mots
Créé en 1973, SWIFT pour Society for Worldwide Interbank Financial Telecommunication, est un réseau bancaire permettant la gestion de transactions financières entre plusieurs banques et ce, à l’échelle internationale.
C’est également le nom de l’entité qui est en charge de son fonctionnement ; cette organisation coopérative, basée à Bruxelles, est aujourd’hui détenue et contrôlée par plus de 3 000 représentants des plus importantes banques mondiales.
Le réseau SWIFT traite chaque jour plus de trente millions de transactions pour assurer les besoins de ses 11 000 utilisateurs.
Longtemps considéré comme le réseau de transaction financière le plus fiable au monde, SWIFT permet avant tout d’assurer la non-répudiation des échanges. Autrement dit, aucun tiers n’est censé pouvoir renier une transaction. Dans la pratique, nous verrons que cela dépend d’un certain nombre de prérequis sous la responsabilité des utilisateurs.
Retour sur la première affaire de la Bangladesh Bank
C’est au cours du mois de mars 2016 que l’on apprend par les médias que 81 millions de dollars provenant de la Bangladesh Bank ont disparu de la circulation.
Figure 1 : logo de la Bangladesh Bank
Retour sur le cheminement de cette fraude majeure :
  Le 15 mai 2015, quatre comptes bancaires sont ouverts au sein de la Rizal Commercial Banking Corporation (RCBC), située aux Philippines. Par la suite, on découvrira qu’ils ont été créés sous de fausses identités et deviendront la destination finale de l’argent avant de disparaître dans la nature.
  Les 4 et 5 février 2016, soit neuf mois plus tard, 35 transactions SWIFT (représentant 951 M$) sont exécutées à la demande de la Bangladesh Bank à destination de la RCBC. Au final :
  30 de ces transactions sont bloquées par « manque de précisions », représentant tout de même 850 M$ soit 90% de la requête initiale.
  Sur les 101 M$ restants, 20 sont également rejetés suite à une faute de frappe sur le nom du destinataire.
  81 M$ finissent tout de même par arriver sur les quatre comptes frauduleux de la RCBC.
  Le 9 février, des retraits massifs sont réalisés sur ces comptes et l’ensemble des 81 M$ se perdent dans les caisses de plusieurs casinos philippins.
Pourquoi donc des casinos philippins ? Dans une optique « d’aider le développement des jeux d’argent » dans le pays, le Gouvernement Philippin n’oblige pas les casinos à dénoncer les transactions jugées suspicieuses. Ils deviennent donc une cible parfaite pour de telles fraudes. Les derniers évènements ont entraîné d’importants débats aux Philippines et la situation pourrait évoluer rapidement.
De ce que l’on sait aujourd’hui, ces retraits massifs ont été acceptés malgré l’avis d’alerte reçu par la RCBC. La raison reste inconnue à ce jour. C’est bien là le point central des procédures en cours, qui s’annoncent longues, complexes et lourdes de conséquences.
  Le 15 février, c’est officiel, les 81 M$ perdus sont à l’origine d’une fraude bancaire majeure. Le Président de la Bangladesh Bank démissionne. Les médias s’emparent de l’affaire.
Figure 2 : synthèse du cheminement de la fraude SWIFT Bangladesh Bank
Que s’est-il passé ?
La piste d’une attaque cybercriminelle a été très vite étudiée. C’est plusieurs semaines après, au cours du mois d’avril, que les premières révélations des investigateurs sont tombées.
C’est effectivement une cyberattaque et ce n’est pas par l’originalité de son mode opératoire qu’elle est étonnante. En effet, quatre étapes classiques auraient été suivies :
1.Intrusion dans le SI de la banque.
2.Vol d’identifiants d’opérateurs SWIFT permettant la création, l’approbation et l’exécution de transactions bancaires.
3.Lancement des 35 ordres frauduleux.
4.Suppressions immédiates des traces générées par les attaquants.
Les trois premières étapes sont à date encore assez floues. Pour autant, certains experts parlent d’une intrusion physique et plus particulièrement liée à une clef USB branchée sur un poste opérateur. Jillian STICKELS, porte-parole du FBI, est allé un cran plus loin en déclarant qu’à ce stade, une complicité interne était suspectée.
Par ailleurs, FireEye aurait découvert non seulement que les attaquants étaient encore présents au moment de leurs investigations mais surtout que trois autres acteurs, a priori étatiques, seraient eux aussi en place dans le SI. Reuters, une agence de presse londonienne très investie dans l’affaire, a déclaré de source confidentielle que deux de ces trois acteurs pourraient être le Pakistan et la Corée du Nord. Ils expliqueraient notamment ces intrusions simultanées par un niveau de sécurité très faible du système d’information (absence de pare-feu, switchs très obsolètes, etc.).
Ces deux acteurs ont-ils un lien avec l’attaque ? Nous verrons par la suite que d’autres éléments suspects pourraient le confirmer. En revanche, rien n’est aujourd’hui certain. Nous connaissons tous d’ailleurs la difficulté pour déterminer la source réelle d’une attaque.
« 4 – Suppressions immédiates des traces générées »
C’est plutôt la dernière étape qui rend cette attaque impressionnante. Plusieurs études poussées ont été réalisées sur le malware intitulé Trojan.Banswift par Symantec. Ce dernier aurait justement été un élément clef de cette ultime étape.
Un puissant malware, une attaque furtive
Deux chercheurs de BAE Systems, une entreprise anglaise réputée dans le milieu de la sécurité de l’information, ont réussi à récupérer une majeure partie du présumé malware Trojan.Banswift.
Une étude poussée de rétro-ingénierie a été menée. Les résultats décrivent alors les trois fonctions principales de l’outil :
  Fonction 1 : superviser les exécutions de transactions légitimes et récupérer ainsi les plages horaires de connexion de l’opérateur SWIFT concerné.
À son lancement sur le poste de l’opérateur, le malware entre dans une boucle dans laquelle une requête régulière est lancée auprès de de la base de données d’Alliance Access (nom du logiciel permettant de se connecter au réseau SWIFT et de gérer les transactions). Cette requête permet de récupérer le contenu du journal d’évènements. Le malware parcourt ce journal afin d’identifier les actions relatives aux connexions de l’opérateur.
Figure 3 : requête SQL permettant de récupérer le contenu du journal d’évènements

Toutes les heures, le malware indique alors aux attaquants, par le biais du serveur C&C, si l’opérateur s’est connecté, déconnecté ou bien si aucun changement d’état n’a été relevé. Il en profite également pour envoyer des informations détaillées sur les transactions récemment exécutées permettant ainsi d’alimenter les attaquants en connaissances (optique d’apprentissage progressif).
  Fonction 2 : effacer les traces des transactions frauduleuses dans la base de données locale.
Dans l’un des fichiers de configuration utilisés par le malware, se trouvent les références des transactions frauduleuses émises par les attaquants (n.b. ces dernières ne sont pas exécutées par ce malware ; pour le moment, nous n’avons pas plus de détails sur cette partie).
Dès qu’une ou plusieurs références de transaction sont présentes dans le fichier, le malware requête la base afin d’identifier les clefs primaires des enregistrements associés. Il demande ensuite une suppression de toutes les informations qui y sont rattachées.
Figure 4 : requêtes SQL permettant d’effacer les traces des transactions dans la base
Par ailleurs, afin que les soldes des comptes concernés restent cohérents, le malware s’occupe d’aller mettre à jour les champs ad hoc de la base. Ces manipulations SQL permettent également aux attaquants de connaître systématiquement les soldes d’ouverture et de fermeture pour ne jamais initier une transaction d’un montant trop élevé. Ils limitent ainsi tout risque de lever une alerte.
  Fonction 3 : intercepter les confirmations de transaction et modifier leur contenu avant impression.
Au-delà de tracer l’ensemble détaillé des actions dans la base de données, Access Alliance Software s’occupe également d’imprimer une confirmation de chaque ordre réalisé. Pour rester furtif, les attaquants sont allés jusqu’au bout de leur logique.
Le malware intervient lors d’une étape intermédiaire à ce processus d‘impression. Le contenu des transactions est parcouru puis transformé en fichiers PRT temporaires (fichiers contenant du PCL, un langage interprétable par une imprimante et décrivant le texte à imprimer).
C’est à ce moment-là que le malware agit. Il intercepte le contenu PLC de ces fichiers, le parcourt puis supprime toutes les données relatives aux transactions frauduleuses. L’exécutable en charge de leur impression récupère le fichier « corrompu » et termine son travail. La confirmation « papier » falsifiée est alors imprimée et aucune alerte ne pourra être levée à court terme.
  Permettre l’accès systématique à la base de données SWIFT : il ne s’agit pas là d’une fonctionnalité en soi mais il est intéressant de comprendre la manière dont le malware s’octroie les droits d’accéder à la base de données Alliance Access et de manipuler les données.
À son lancement, le malware parcourt l’ensemble des processus en cours d’exécution sur le poste et identifie celui qui aurait chargé la bibliothèque « liboradb.dll ». On comprend alors que le malware cherche à mettre la main sur le processus qui permet d’initialiser et de gérer les connexions avec la base locale SWIFT.
Figure 5 : instructions assembleur avant la modification apportée par le malware
Une fois identifié, le malware s’occupe alors de « patcher » dynamiquement ce dernier en remplaçant deux octets précis par la valeur 0x90. En langage assembleur, cette valeur représente l’instruction NOP ayant pour simple rôle de ne rien faire ; l’instruction « passe son tour ». Autrement dit, quand le processeur arrivera à ce niveau du programme, au lieu d’exécuter l’action initialement prévue, ce dernier ne fera rien de spécifique pendant deux tours d’exécution successifs.
Figure 6 : instructions assembleur après la modification apportée par le malware
Le choix des octets écrasés est important. Le malware vise à supprimer la vérification d’un certain nombre de critères permettant au programme d’accepter ou non l’initialisation de la base. En supprimant cette vérification, le programme retourne alors systématiquement un avis favorable. Le malware peut ainsi continuer son chemin et accéder à la base en toute liberté.
Il ne fait aucun doute que ce malware est nécessairement le fruit d’un apprentissage approfondi du fonctionnement de SWIFT et des processus internes de la Bangladesh Bank. On le constate ici grâce à l’exhaustivité des moyens de camouflage (rien n’a été oublié ni négligé), à la précision des requêtes SQL prévues dans le malware (présence de mots clefs propres à la banque) mais surtout au moyen technique poussé prévu pour contourner les contrôles d’accès à la base.
Les attaquants sont très certainement présents depuis de nombreux mois dans le SI. En effet, cette nouvelle attaque met une fois de plus en lumière le principe de « l’attaquant qui prend le temps d’apprendre », tendance constatée dans les dernières cyberattaques majeures !
Malgré cette forte contextualisation, les chercheurs de BAE Systems sont d’accord pour dire qu’avec une telle philosophie, le code de Trojan.Banswift pourrait être réutilisé aisément dans d’autres attaques similaires. Ils précisent également qu’il ne serait qu’une partie d’un ensemble d’outils plus global ayant permis de mener la totalité de l’attaque.
Une deuxième affaire toujours plus pointue (puis une troisième, une quatrième, …)
C’est aux alentours de mi-mai que l’on apprend qu’une deuxième banque aurait été victime d’une attaque similaire à celle de la Bangladesh Bank.
SWIFT parle « d’une banque commerciale », BAE Systems parlent eux « d’une banque commerciale vietnamienne » tandis que TPBank, une banque justement originaire de Hanoi, déclare en toute indépendance avoir été victime d’une attaque sur leur système de transaction SWIFT. Tout porte donc à croire que ces informations se recoupent mais personne ne le souligne dans ce sens. Le doute qu’il s’agisse là d’un ou plusieurs cas différents subsiste encore. Dans la suite de cet article, nous admettrons qu’il s’agit bien de TPBank.
Le mode opératoire suivi dans cette nouvelle attaque a été très similaire à celui de la Bangladesh Bank. Cependant, SWIFT a précisé une spécificité non-négligeable : le malware aurait permis de remplacer le lecteur PDF utilisé par les opérateurs pour vérifier leurs transactions (un équivalent à la « confirmation papier » de la Bangladesh Bank). Ce nouveau lecteur PDF compromis permettait alors aux attaquants de camoufler à la volée leurs tentatives de transactions frauduleuses (toujours dans le but de ne lever aucune alerte sur le court terme).
Cette particularité, non des moindres, prouve à quel point les attaquants possèdent une haute maîtrise du contexte dans lequel ils agissent et une importante expertise technique.
Il est à noter que ce ne sont pas directement les systèmes de TPBank qui ont été visés pour initier l’attaque. Les attaquants sont passés par le biais d’un prestataire externe singapourien, qui fournissait du chauffage et de la climatisation l’infrastructure nécessaire pour se relier au réseau SWIFT.
Une tentative de fraude qui se termine tout de même bien pour TPBank. En effet, les mouvements suspicieux ont été détectés à temps et la tentative de détournement de 1,1 M$ n’a finalement pas abouti.
Fin mai, plusieurs autres cas similaires à Bangladesh Bank et TPBank ont été dévoilés. La banque équatoriale Banco Del Austro et une banque philippine dont on ignore encore le nom semblent effectivement à leur tour avoir été victimes. De plus, des références SWIFT d’au moins sept autres institutions financières (Japon, Corée du Sud, Chine, Australie, etc.) ont été découvertes dans le code du malware.
Comment la Corée du Nord est devenue le suspect n°1…
Grâce à leurs travaux de recoupement, les chercheurs de BAE Systems ont réussi à montrer que le même groupe d’attaquants était potentiellement à l’origine des différentes attaques SWIFT remontées (entre Bangladesh Bank et TPBank notamment).
Les chercheurs de Symantec, eux, se sont chargés de montrer qui pouvait être derrière ce fameux groupe. Après un travail conséquent de Threat Intelligence, ils ont pu déclarer que les attaquants pourraient avoir un très probable lien avec le groupe nord-coréen Lazarus.
Figure 7 : principales cibles du groupe Lazarus depuis 2009 (source : rapport Kaspersky)
Pour comprendre, commençons par revenir sur trois malwares majeurs que les équipes Symantec ont pointés du doigt :
  Backdoor.Destover : ce malware a été utilisé dans deux affaires majeures :
  L’attaque contre Sony Pictures Entertainment en 2014.
  Une violente campagne contre les USA et la Corée du Sud qui dure maintenant depuis 2010 (qui sera plus tard à l’origine du lancement de Blockbuster, une opération lancée pour combattre les auteurs de cette campagne).
Destover a justement été développé par le groupe d’attaquants Lazarus qui serait lui-même rattaché au régime de la Corée du Nord. Ces informations ont été annoncées par le FBI après leurs études approfondies de l’attaque Sony.
  Backdoor.Contopee : ce malware, accompagné de ses deux frères Backdoor.Fimlis et Backdoor.FimlisB, aurait été au centre d’une série d’attaques contre plusieurs entreprises financières d’Asie du Sud-Est ces deux dernières années.
  Trojan.Banswift : on ne le présente plus, ce malware est celui utilisé dans les différents cas d’attaques SWIFT présentés dans cet article.
En étudiant chacun de ces trois malwares, Symantec a alors découvert de nombreuses similitudes ; entre Destover & Contopee d’une part, puis entre Contopee & Banswift d’autre part. Ces similitudes sont liées à des morceaux de code permettant d’effacer de la donnée (wiping code). Ils illustreraient une technique d’effacement unique et peu commune. D’après les chercheurs, il serait donc très peu probable que plusieurs groupes distincts, développant chacun de leur côté, puissent tomber sur ce même code.
BAE Systems ont eux aussi trouvé d’autres similitudes entre ces trois malwares : des clefs de chiffrement, des noms de fonctions, des mutex, des erreurs courantes de typo ou encore des intitulés de structures & variables. Tous ces éléments sont laissés à la main du développeur ; ils sont pourtant majoritairement identiques d’un malware à l’autre.
Les travaux d’attribution sont toujours très complexes à mener et peuvent être discutés de nombreuses heures. Il n’en reste pas moins que ces similitudes sont un faisceau d’indice qui peut laisser croire que le groupe nord-coréen Lazarus aurait également développé les malwares Banswift et Contopee.
Comment réagir face à une telle menace sectorielle ?
Au-delà du respect des bonnes pratiques usuelles de sécurité des systèmes d’information, plusieurs actions peuvent être adressées :
  À très court terme, mettre en place la dernière mise à jour d’Alliance Access et suivre les remontées d’incidents de l’équipe support ; la mise à jour permet d’empêcher certaines actions du mode opératoire connu de l’attaque. De plus, les équipes SWIFT se sont engagées à remonter toutes les informations utiles provenant des investigations en cours et futures. Rendez-vous donc sur votre plateforme client !
La connaissance de ces remontées permettra notamment de lancer des recherches de présence d’IOC (indicateurs de compromission) sur vos systèmes. Nous en avons parlé plus en détail dans un autre article.
  À moyen terme, analyser votre attractivité aux yeux des cybercriminels afin de déterminer vos activités les plus exposées et risquées ; cela permettra de reprioriser vos actions sur les prochains mois.
  Réaliser des exercices de crise sur la base de scénarios de fraudes pour vous préparer à une situation similaire réelle et identifier dès maintenant les manques & axes d’amélioration.
  Enfin, faire un audit approfondi de vos systèmes anti-fraude afin d’évaluer leur efficacité, leur fragilité et de les adapter en fonction des dernières menaces connues. Ces systèmes, on le voit dans le cas de l’attaque SWIFT, peuvent effectivement être directement la cible des attaquants afin de les rendre inopérants.

Quatre affaires ont donc été officialisées jusqu’à aujourd’hui. Malheureusement, il y a de fortes chances qu’il ne s’agisse là que du début d’une conséquente campagne cybercriminelle visant le secteur financier mondial. Une chose est sûre : affaire à suivre … !

Baptistin BUCHET

Sources :