Pour sa troisième édition, XMCO était partenaire média de la BotConf. Nous vous proposons un bref résumé de cette dernière édition.
Seules 4 présentations seront décrites dans ces colonnes. L’ensemble des résumés des présentations sera quant à lui disponible dans le prochain numéro de l’ActuSecu (#43).
Jour 1
Ponmocup, the full story: A giant hiding in the shadows, par Maarten van Dantzig (@MaartenVDantzig) & Yonathan Klijnsma (@ydklijnsma)
La première conférence de la Botconf, présentée par les chercheurs de FoxIT Maarten van Dantzig et Yonathan Klijnsma, a fait sensation. Ces derniers ont exposé leur analyse du botnet Ponmocup. Détecté en 2006 pour la première fois, ce botnet est l’un des plus vieux botnets encore en activité et a affecté plus de 15 millions de machines.
Dans leur présentation, les chercheurs décrivent leurs découvertes sur le botnet. Ponmocup a permis de dérober des millions de dollars depuis les comptes bancaires de ses victimes.
Aujourd’hui composé d’un demi-million de machines actives, il a connu un pic en 2011 où 2,5 millions de machines étaient infectées au même moment. L’infrastructure de Ponmocup est très sophistiquée et les criminels s’expriment pour la plupart en russe. Un autre indice confirmant ses origines russes est qu’il n’infecte pas les postes localisés en Russie (si l’IP d’une victime est Russe, le malware n’est pas activé). Afin d’empêcher le « sinkholing » (redirection du trafic malveillant vers les machines des chercheurs pour analyse), les domaines ne sont pas tous déployés en même temps et dépendent de la version du malware distribué.
Les chercheurs ont découvert 25 plug-ins et 4000 variantes de Ponmocup. Parmi ses plug-ins, les chercheurs ont découvert un « tueur » d’antivirus, un voleur de cookie Facebook, un voleur de porte-monnaie virtuel (fichier .wallet), un scanner SIP, etc. Plus qu’un malware, c’est un véritable framework que les chercheurs ont découvert.
Cette conférence a montré qu’aucune action majeure des autorités ne semble avoir porté ses fruits depuis sa création.
Sandbox detection for the masses: leak, abuse, test, par Zoltan Balazs (@zh4ck)
Une courte présentation des techniques de détections de sandbox a été présentée par Zoltan Balazs. L’orateur a montré comment les malwares détectent les sandbox, de façon triviale, pour empêcher leur analyse. Pour ce faire, Zoltan a développé un malware capable d’exfiltrer (en HTTP) les informations d’un système compromis afin de déceler la présence d’une machine virtuelle.
Les principaux indicateurs permettant de détecter une machine virtuelle sont les suivants :
- la résolution de l’écran (généralement basse)
- les programmes installés (python, Tracer, WMWareTools)
- le type de processeur
- le nombre de cœur du CPU (généralement un seul sur une sandbox)
- les mouvements de la souris (seulement 20 % des sandbox les simulent)
- la taille de la mémoire vive (faible)
- le nom de la machine
- la connexion à certains périphériques (tels que les imprimantes)
- le nombre de fichiers créés/modifiés récemment
- le nombre de fichiers sur le bureau (généralement nombreux sur un poste de travail)
Grâce à ces indicateurs, les malwares sont capables de s’assurer qu’ils ont infecté un véritable poste de travail avant d’aller plus loin et de se dévoiler. Ces techniques de détection montrent que les malwares sont de plus en plus ciblés et que les analystes doivent redoubler d’ingéniosité pour être véritablement infectés au sein de leur sandbox.
Jour 3
The Story of Cryptowall: a historical analysis of a large scale cryptographic ransomware threat, par Yonathan Klijnsma (@ydklijnsma)
La dernière journée de conférence a commencé par une présentation du ransomware Cryptowall et de son évolution au fil du temps. Ce dernier a commencé en tant que clone du ransomware CryptoLocker (lui-même cousin de CTBLocker, voir ActuSecu #40).
Cette première version du malware chiffrait les fichiers de sa victime à l’aide de l’algorithme RSA, utilisait le protocole HTTP afin de communiquer avec son serveur C&C (« Control & Command », le serveur maître permettant d’effectuer diverses actions sur les victimes). Une de ses caractéristiques est la multitude de méthodes de paiement disponibles pour la victime afin de récupérer ses données (Litecoin, Bitcoin, Ukash, etc.). L’architecture réseau étant quant à elle composé d’un serveur proxy (privoxy) communiquant à son tour avec le C&C basé sur Tor.
La deuxième version de Cryptowall était appelée « CryptoDefense ». Cependant, cette version du ransomware a vite été évincée suite à la découverte d’une faille dans l’implémentation du chiffrement. En effet, l’API Windows utilisée pour générer les clés de chiffrement publiques et privées gardait la clé privée en mémoire. Il était alors possible de récupérer les données chiffrées sans payer de rançon.
Il est intéressant de constater que les auteurs de Cryptowall ont su évoluer et rapidement apprendre de leurs erreurs. Le nom « CryptoDefense » étant mal vu suite à la découverte de cette faille, l’équipe reviendra par la suite au nom « Cryptowall » (en version 1.0), après avoir corrigé l’implémentation de l’algorithme de chiffrement, notamment en générant les clés de chiffrement sur le serveur. Ils en profitent aussi pour se passer de proxy et passer directement par le réseau Tor pour effectuer toutes les actions nécessaires.
De nouvelles souches du malware utilisant le réseau I2P plutôt que Tor ont vu le jour, mais le fonctionnement étant difficile à mettre en place, les pirates ont finalement abandonné l’idée. Ils ont profité de cette phase expérimentale pour définir une nouvelle architecture. Plutôt que de passer directement via le réseau Tor, ces derniers utilisent maintenant des serveurs légitimes piratés, un serveur proxy (privoxy) ainsi qu’un serveur C&C sur le réseau Tor. Cette infrastructure permet d’éviter les mécanismes de blacklists plus longtemps (les serveurs contactés pour infecter la victime étant légitimes, mais infectés).
Les méthodes cryptographiques utilisées ont aussi été améliorées. L’algorithme de chiffrement est maintenant AES-256, dont la clé de chiffrement est elle-même chiffrée avec l’algorithme RSA-2048. Le nombre d’extensions de fichiers visées par le malware a quant lui quasiment doublé, avec au total, 312 extensions visées.
Le chercheur à l’origine de ces études a invité les experts en sécurité à ne pas publier publiquement les failles potentielles trouvées sur ce genre de malware puisque les auteurs sont très actifs et les corrigent vite. Il conseille ainsi de contacter les services compétents pour diffuser les résultats de certaines recherches.
Powered by JavaScript, par Renaud Bidou (@rbidou)
Au travers de cette présentation, Renaud Bidou a voulu nous faire prendre conscience du danger que représente JavaScript et à quel point la situation pouvait être amené à se complexifier dans le futur. Le JavaScript s’appuie sur le standard ECMAscript, dont est aussi issue l’Actionscript (le langage utilisé au sein de Flash). C’est donc une énorme part de l’Internet qui repose sur cette technologie.
Les avantages du JavaScript notamment pour la construction de Botnet sont multiples : persistance, agilité, propagation, injection… Le langage semble idéal pour les pirates. Le point d’entrée pour commencer une attaque via un botnet en JavaScript est d’autant plus très simple à trouver sur bon nombre de sites web : les failles de type « Cross-site scripting » ou « XSS ». Souvent minimisées, elles sont très communes et encore très (voire trop) facilement trouvables sur le Net. Une seule faille permet de faire exécuter des scripts JavaScript potentiellement dangereux sur le poste de nombreuses victimes.
Malgré des protections disponibles, telles que le SOP (Same Origin Policy) permettant d’interdire l’exécution d’un script si le serveur, le protocole et le port utilisés pour l’exécuter diffèrent lors de l’accès d’une page à une autre, de nombreuses techniques de contournement existent. On découvre également des techniques encore balbutiantes, mais prometteuses, telles que les failles « XSS » via FTP.
Renaud a ainsi présenté de nombreuses techniques permettant de faire exécuter du code JavaScript malveillant sur le poste d’un utilisateur. L’utilisation d’un loader dynamique, d’une extension pour un navigateur ou encore d’images pour cacher du code malveillant ne sont que quelques exemples parmi la multitude de techniques existantes. Il a aussi porté son attention sur l’utilisation de C&C basés sur des sites légitimes, qu’il est donc très difficile de supprimer (des services comme Twitter sont ainsi utilisés pour envoyer des instructions).
Enfin, Renaud a démontré qu’il était possible, notamment via l’utilisation de HTML5 ou de protocoles tels que WebRTC, d’effectuer des actions malveillantes en JavaScripts : Keylogger, prise de capture d’écrans, vol de données sensibles, vol d’images de la webcam et/ou du micro, récupération d’informations systèmes et même scan de ports sont possibles, sans que l’utilisateur ne s’en aperçoive !
Ces différentes techniques sont, à l’heure actuelle, peu utilisées et exploitées séparément, mais il est fort possible que durant les années à venir, des malwares en JavaScript disposant de tout un arsenal de fonctions malveillantes fassent leur apparition…
Nous avons hâte de découvrir la prochaine édition de la Botconf, qui se tiendra à Lyon le 30 novembre , 1er décembre et 2 décembre prochain.
En attendant cette nouvelle édition, vous pourrez retrouver l’intégralité des résumés des conférences de la Botconf 2015 dans notre prochain numéro de l’ActuSécu (#43) !
