2.4.1 Rançongiciels policiers
Les rançongiciels sont des botnets dont le principe est de bloquer l’ordinateur des victimes et réclamer le paiement d’une rançon. Depuis 2011, une vague de rançongiciels policiers (menaçant la victime par des allégations de délits qu’elle aurait commis et une amende à payer) a déboulé sur l’Europe puis le reste du monde. Les débuts de cette vague semblent remonter au mois de mars 2011 en Allemagne, puis se poursuivre en France à la fin de l’année 2011 par une campagne utilisant l’image de la gendarmerie nationale, puis de très nombreuses variantes se sont signalées tout au long de l’année 2012 (cf. figure 2.6 page suivante).
Nous avons suivi et documenté une grande partie de ces rançongiciels policiers, notam-ment grâce aux échanges avec l’auteur du blog Malware don’t need coffee22et aux différentes publications des éditeurs de sécurité tout au long de cette période. L’écosystème du ran-çongiciel policier est passé par différentes étapes, nous permettant d’observer presque d’un seul coup, l’ensemble des scénarios possibles de commercialisation et de filiation au sein des familles de botnets.
Nota : les pages de rançonnement sont appelées “landing” pour “landing page”, car il s’agit en général d’une page Web sur laquelle atterrit la victime sans pouvoir en ressortir.
En effet, le principe semblant être particulièrement efficace, les premiers modèles ont intéressé d’autres cyberdélinquants qui s’en sont inspirés, soit en copiant le code ou les pages d’affichage de la demande de rançon, soit en le réinventant à leur façon. Ainsi, on est passé
Figure 2.6 – Familles de rançongiciels observés au cours de l’année 2012
de modèles simples avec un botnet isolé, vraisemblablement géré par une personne ou un petit groupe à des systèmes de kits prêts à personnaliser avec système d’affiliation intégré. Le principe du rançongiciel n’était pas nouveau, mais l’exploitation de l’image des services de police s’est révélée particulièrement efficace.
Les variations sont les suivantes :
• botnet indépendant / botnet commercialisé sous forme de kit ;
• avec ou sans système d’affilation (un maître principal qui recrute des personnes chargées d’infecter des victimes et sont rémunérées par une commission) ;
• les pays et les services de police ciblés ;
• le message de rançon (une page Web) peut être stocké sur un serveur distant et va s’adapter à la position géographique de la victime au moment de l’allumage de l’ordi-nateur, ou bien il est intégré au bot ;
• les mécanismes de paiement de la rançon (tickets prépayés que l’on achète dans les bureaux de tabac ou équivalents, comme Ukash et Paysafecard et plus tard via Bitcoin) ; • certaines variantes enfin ne sont pas des codes malveillants sous forme exécutable, mais sous forme de code Javascript qui est capable de s’installer de façon permanente dans la configuration d’un navigateur Web ;
Si on généralise ces observations à l’ensemble des botnets, les scénarios que l’on peut observer sont notamment ceux que nous avons représenté en figure 2.7 page ci-contre.
Ainsi, la combinaison de nos observations et de celles des chercheurs travaillant sur les ran-çongiciels policiers ont notamment permis d’établir qu’un certain nombre d’instances
de botnets qui paraissaient différentes (notamment parce que le visuel utilisé pour le message de rançon était très différent) étaient en réalité issues du même kit ou bien que certaines classes de botnets semblaient très liées à l’utilisation d’une même plate-forme d’exploitation Blackhole pour leur diffusion :
Figure 2.7 – Scénarios possibles de diffusion des botnets, depuis les botnets isolés jusqu’aux kits permettant y compris l’affiliation
• issus du kit “Silence Winlocker” : Americana Dreams, Jagfu, Gimemo, LockScreen.CI, Goscri ;
• issu du kit “ZOIE” : Epubb ;
• issus du kit “Multilocker” : Nertra, Vicas, IPeur et Mlano ;
• tandis que Reveton est bien l’oeuvre d’un acteur ou d’un groupe isolé, ne cherchant pas à faire profiter d’autres personnes des qualités éventuelles de leur codes malveillants ;
En particulier, les techniques développées par le LORIA (voir par exemple le papier [CFM12] qui détaille les méthodes de collecte de traces d’exécution et leur classification) avec qui nous avons eu plusieurs réunions de travail, nous ont permis d’arriver ensemble à la conclusion que les botnets appelés Tobfy et Ransom.IF avaient des bots dont le code présente de très grandes similitudes, nous permettant d’établir un lien supplémentaire.
Nota : L’évolution des rançongiciels que l’on a observée ensuite a été l’avènement à partir de 2013 de rançongiciels chiffrants (ou cryptolockers).
2.4.2 Les botnets et campagnes d’espionnage
Les botnets d’espionnage (notre catégorie “Spying”) sont un cas manifestement à part dans notre étude. En particulier, ils n’ont pas l’aspect classique d’un botnet souvent dé-crit comme un réseau de nombreuses machines infectées : chaque instance peut parfois ne concerner qu’un seul ou quelques systèmes et très souvent, l’infrastructure de commande et de contrôle sera dédiée à une cible particulière [Kam11]. Mais ils correspondent bien à notre définition, une ou plusieurs machines infectées étant reliées à une infrastructure de commande et de contrôle.
Une autre particularité des botnets d’espionnage est leur potentiel médiatique, les éditeurs de sécurité notamment n’hésitant pas à donner des noms percutants aux campagnes associées.
Enfin, on retrouve dans beaucoup de ces campagnes d’espionnage l’utilisation de logiciels malveillants relevant de la catégorie des RATs comme outil principal (tels Havex ou Poison Ivy).
Le scénario de ces campagnes et donc de l’installation de ces botnets implique la plupart du temps des courriels piégés (spear phishing, cf. définition 1.27 page 62) ou encore des opérations de waterholing. Pour inciter les victimes à cliquer sur les pièces jointes des courriels piégés, différentes techniques d’ingénierie sociale sont utilisées. Dans le cas d’Etumbot, les auteurs de [ASE14] ont par exemple relevé l’utilisation de la possibilité d’afficher les caractères de droite à gauche (RTLO pour right-to-left override), un caractère Unicode invisible (U+202e) positionné au bon endroit qui permet de faire croire qu’un fichier se terminant en slx.scr serait un fichier .XLS (Excel) alors qu’en réalité c’est un exécutable (.scr est l’extension des économiseurs d’écran sous Microsoft Windows, en réalité des fichiers exécutables). Parfois des techniques d’obfuscation rares sont utilisées telles que le string stacking (encore appelé
byte strings) qui consiste à charger les chaînes de caractères octet par octet dans le code
malveillant lui-même.
Il est difficile de tirer des conclusions à partir des informations publiées sur ces campagnes. En effet, les chercheurs qui publient sur ces menaces sont en général dans un pays différent de celui d’où semble provenir l’attaque et surtout leurs découvertes dépendent du fait que la campagne a été détectée, alors que bien évidemment beaucoup de précautions sont prises pour éviter la détection. Ce qui n’est jamais totalement clair c’est de savoir si les
campagnes sont menées par de véritables acteurs étatiques ou bien par des en-treprises ou groupes criminels qui revendraient ensuite leurs résultats au plus offrant.
Enfin, les objectifs de telles campagnes ne sont pas uniquement d’obtenir des informations, mais parfois de détruire l’infrastructure de leurs cibles. C’est ce qu’ont vécu des sociétés comme Aramco en 2012 avec Disttrack/Shamoon [Pan12] et plus récemment TV5 Monde.
Très souvent, la terminologie Advanced Persistant Threat (APT) est utilisée, que nous préférons traduire par attaque en profondeur. En effet, non seulement s’agit-il de placer un pied dans l’infrastructure de la cible, mais de s’y maintenir et d’être en capacité de l’explorer pour récupérer un maximum d’informations, puis d’y rester longtemps si nécessaire ou d’effacer les traces : le botnet est souvent utilisé pour servir de pivot entre l’intérieur et l’extérieur.
En résumé, voici quelques critères caractèristiques d’un botnet/d’une cam-pagne d’espionnage :
• instances de botnets de petite taille (quelques unités au maximum) ; • campagnes d’ingénierie sociale, notamment via spear phishing ;
• utilisation de méthodes supplémentaires pour camoufler l’attaque, la rendre plus discrète (serveurs de commande et de contrôle dédiés, en cascade, tech-niques d’obfuscation rares ou innovantes) ;
• attaque en profondeur dans le réseau de la victime et dans la durée (APT) ; • l’objectif principal est l’extraction d’informations confidentielles et parfois
la destruction de données ou de matériels ;
L’attribution à un acteur dit “étatique” n’étant jamais très claire, il est dif-ficile d’en faire un critère, toutefois de tels acteurs seront souvent cités dans les publications.
Enfin, certaines opérations de vol de données dans de grandes entreprises peuvent res-sembler par certains aspects – notamment par les méthodes employées – avec des opérations d’espionnage. Ainsi, en juillet 2013, le ministère de la justice américain rendait public [Nar13] l’acte d’accusation [Sim13] contre 4 russes et 1 ukrainien accusés des attaques contre Heart-land Payment Systems, JCPenney ou le NASDAQ. Ils ont utilisé différentes méthodes qui sont mises en avant dans le document (injections SQL), dont l’utilisation de logiciels malveillants de nature non précisée, vraisemblablement des RATs, et une infrastructure de commande et de contrôle très organisée. L’intention des délinquants était ici clairement de détourner de façon massive des numéros de carte bancaire utilisables. C’est la motivation qui est
déterminante pour différencier les campagnes d’espionnage des campagnes de détournements de données (“Stealing” dans notre classification).
2.4.3 Botnets bancaires
Les botnets bancaires constituent aussi une catégorie particulièrement intéressante. Peut-être est-ce celle qui permet rapidement les plus gros revenus pour les délinquants, c’est aussi l’une de celles où il y a le plus d’innovations. En effet, il s’agit d’une compétition permanente avec des équipes particulièrement motivées sur les questions de sécurité dans les banques elles-mêmes.
Dès le début de nos travaux [Fre12c], le botnet Citadel avait attiré notre attention. La publication du code source du botnet ZeuS – qui dominait réellement le “marché” à l’époque – en mai 2011 avait donné beaucoup de perspectives à de nouvelles équipes et on avait vu apparaître IceIX ; SpyEye puis Citadel, chacun rivalisant de nouveautés, y compris dans leurs relations avec les détenteurs de licences. Nous avons référencé plus de 40 botnets bancaires différents ; une grande partie des classes récentes sont liées à l’émergence des botnets ciblant les terminaux de point de vente.
Dans certains cas, ce sont des botnets de type RAT ou des chevaux de Troie aux fonction-nalités avancées qui sont utilisés pour cibler les organismes bancaires, comme on l’a beaucoup vu en Russie avec RDPdoor ou Sheldor [ER11] ou plus récemment avec la campagne Anu-nak/Carbanak [FI14], l’idée étant de s’en prendre directement aux banques ou à de gros clients, en combinant des botnets bancaires classiques (dont Carberp, Qadars) et des outils d’intrusion. Carbanak n’est pas en soi une nouvelle méthode, contrairement à ce qu’on a pu lire en début d’année 2015, mais plutôt exceptionnel par son ampleur.
Une des particularités de l’observation de ces botnets est qu’ils sont souvent diffusés en kit (ZeuS, Citadel, etc.) et donc le nombre d’instances de ces botnets est très important ([Abu10] évoque 250 serveurs de commande et de contrôle actifs au mois de mars 2010). Le modèle technique proposé par ZeuS, et repris ensuite par ses successeurs et concurrents, est de proposer la configuration des injections Web dans un fichier séparé qui peut être mis à jour (fonctionnalité de Webinject) : l’injection Web consiste, en fonction de certains paramètres caractéristiques dans la page Web affichée, d’injecter du code supplémentaire (HTML, Javascript, etc...) qui sera traité par le navigateur comme s’il provenait du site légitime.
Le format standard qui s’est imposé (celui de ZeuS puis SpyEye) contient – une fois déchiffré par le code malveillant :
• set_url puis l’URL cible (expression régulière si nécessaire) suivie de lettres expliquant la conduite à tenir (G pour l’inspection des requêtes de type HTTP GET, P pour l’inspection des requêtes de type POST, L pour journaliser les contenus entre les balises
d’injection et H pour journaliser le reste du contenu sur ces pages) ;
• data_before/data_end : l’injection doit se faire juste après le contenu décrit entre ces deux balises ;
• data_inject/data_end : le contenu à injecter est décrit entre ces deux balises ; • data_after/data_end : l’injection se fait juste avant le contenu décrit entre ces deux
balises ;
[Bou14] souligne les évolutions de ces injections Web : la prise en compte directe par ces techniques de l’interception des contenus remplis par les victimes dans les formulaires (plutôt que par une méthode complexe d’interception du flux réseau par exemple), la suppression d’avertissements affichés par la banque, la réalisation de virements bancaires (Automatic
Transfer Systems (ATS) [Kha12]), le contournement des codes de vérification à usage
unique (reçus par téléphone mobile notamment, appelés alors mTAN pour mobile
Tran-saction Authorization Number, en incitant l’utilisateur à installer une application sur
son téléphone mobile grâce à une injection dans le site Web de la banque), en camouflant les montants détenus dans le compte bancaire pour masquer un virement. La fabrication de ces fichiers de configuration d’injections Web est devenu un vrai métier cybercriminel : [Bou14] présente un certain nombre de ces services qui sont par exemple commercialisés $2 000 pour un kit ciblant une banque allemande.
Les évolutions sont aussi dans le code malveillant : Citadel par exemple a rajouté un cer-tain nombre de fonctionnalités par rapport à ZeuS dont il a repris le code [Mil12] : chiffrement AES 128 bits (au lieu de RC4), détection de l’examen en bac-à-sable, capture d’écran au for-mat vidéo, filtrage de requêtes DNS (pour bloquer les mises à jour des antivirus notamment), support de Google Chrome ou dénis de service (pour empêcher des victimes de se connecter sur leur site de banque en ligne.
A partir des informations collectées dans le cadre de nos travaux, nous propo-sons une synthèse des botnets bancaires sous forme de frise chronologique entre 2003 et 2015 (cf. figure 2.8 page ci-contre), indiquant notamment les héritages entre les différentes classes de botnets et le cas échéant certaines instances par-ticulières.
2.4.4 Les botnets de terminaux de point de vente
Ils constituent l’évolution naturelle après les botnets bancaires classiques, car ils per-mettent de récupérer de façon massive les données concernant de nombreux porteurs de carte bancaire qui se présentent dans les enseignes. Communément applés Point-of-sale malware
(PoS malware), ils ciblent traditionnellement des plates-formes sous système d’exploitation
Microsoft Windows qui équipent de nombreuses caisses enregistreuses, mais ils peuvent aussi cibler d’autres systèmes d’exploitation, voire directement les terminaux indépendants.
La fonctionnalité la plus couramment intégrée consiste à surveiller la mémoire du système, voire la mémoire de certains processus ciblés et d’y rechercher des identifiants bancaires (numéros de carte, date de validité). Si ces données ne sont pas imprimées sur les tickets de caisse, elles sont belles et bien traitées à un moment ou un autre par un composant du système de caisse enregistreuse. La société TARGET en a été une victime fracassante en 2013 (40 millions de numéros de carte bancaire détournés grâce au botnet BlackPOS[Kre14]), mais les sociétés victimes ont été ensuite très nombreuses.
Nous référençons 26 classes différentes de botnets de terminaux de point de vente, avec pour certains d’entre eux des héritages directs (même équipe cybercriminelle derrière les
Figure 2.8 – Botnets bancaires (hors b otnets ciblan t les terminaux de p oin ts de v en te) – ZitMo, CitMo, SpitMo et Ik ee.B ciblen t des plates-formes mobiles ; Sop elka est une instance particulière a v ec un p anel rassem blan t trois b otnets différen ts ; An unak/Carbanak est une c amp agne utilisan t notammen t Carb erp, Qadars et un tro y en sp écifique à An unak.
évolutions) ou indirects (suite à des fuites de code source[iP14]). En théorie, les points de vente destinés aux cartes bancaires à puce (donc dans la zone Euro, mais aussi dans de plus en plus de pays dans le monde) sont mieux sécurisés par nature, toutefois on n’est pas à l’abri de certains risques :
• des cartes bancaires émises par certaines banques qui reproduisent la piste magnétique dans un champ de données de la puce (champ 57 du standard de carte à puce EMV dit “Track 2 equivalent data” qui contient soit la copie de la seconde piste magnétique soit – et c’est plus sûr – une donnée permettant uniquement de vérifier la carte), mais de toutes façons on retrouvera sur la puce au moins le numéro de la carte, le nom du porteur, la date de validité ; on n’y retrouvera jamais le code de vérification CV2 qui est uniquement imprimé sur la carte ;
• la nécessaire compatibilité avec les acheteurs utilisant des cartes à piste magnétique (et donc un danger directe pour leurs identifiants) ;
• les éventuelles faiblesses d’implémentation dans certains équipements.
Et comme nous l’évoquons au début de cette section, il y a de fortes chances pour que des codes malveillants puissent être injectés jusque dans des terminaux indépendants : il se vend aujourd’hui sur les marchés underground(cf. figure 2.9) des terminaux modifiés pour réaliser une opération de skimming (la victime croit interagir avec un terminal légitime puisque c’est une modification d’un terminal original, sauf que sa piste, les informations de sa puce et son code PIN sont mémorisés par le code malveillant). Ici, le commerçant est malhonnête, mais on n’est pas à l’abri que des codes malveillants soient imaginés pour être installés à l’insu des commerçants ou qu’ils y soient incités par une méthode d’ingénierie sociale et que les données puissent être transmises à distance, ces appareils étant communicants. C’est théoriquement difficile parce que de nombreuses sécurités sont en place, mais les délinquants sont patients.
Figure 2.9 – Publicité pour des terminaux de point de vente modifiés permettant de réaliser des opérations de skimming
2.4.5 Prospective sur les objets connectés
Dans [MFB15] nous proposons une revue des architectures de botnets mobiles. Nous proposons d’étendre la réflexion à tous les objets qui – de plus en plus nombreux – sont connectés d’une façon ou d’une autre entre eux et éventuellement à Internet (très souvent par une communication sur un réseau de téléphonie mobile d’ailleurs). L’observation des
botnets ciblant les plates-formes de téléphonie mobile, des motivations de leurs auteurs nous indique très clairement que l’imagination des délinquants ne s’arrêtera pas là. Voici quelques raisons qui devraient les motiver à s’intéresser aux objets connectés :
• Les objets connectés sont généralement moins puissants et il ne semble pas que la sécurité soit toujours une priorité dans leur développement ;
• Ils collectent et contiennent énormément de données personnelles ;
• Si un grand nombre d’entre eux est compromis, ils constituent une puissance de calcul supplémentaire à abuser ;
• Et surtout, les possibilités sont potentiellement plus grandes, parce qu’on ne parle plus uniquement de systèmes d’information, mais, comme pour les systèmes de commande industriels (ou SCADA), d’objets qui ont des fonctions importantes dans nos vies (sé-curité domiciliaire, véhicules, dispositifs médicaux, etc.)
Ainsi, l’attaque spectaculaire démontrée à la conférence Blackhat 2015 contre des véhicules non modifiés, à distance, via le système de divertissement du véhicule nous donne une bonne idée des possibilités. En effet, dans le papier qu’ils ont publié suite à la conférence[MV15] détaille l’ensemble de la surface d’attaque d’un tel véhicule, des points d’entrée possibles aux points de pivotage possible entre les systèmes de divertissement et les systèmes vitaux.
On peut donc prédire, sans risque de se tromper, que nous verrons des bot-nets de montres connectées, systèmes domotiques, pèse-personne communicants, dispositifs médicaux et voitures intelligentes. Les usages seront d’abord semblables
à ceux des téléphones mobiles (détournement de données, banque en ligne, rançongiciel), mais pourraient s’étendre à de nouveaux usages : menaces de déni de service ciblant certains usages (contre un fabricant automobile), des manipulations de cours en bourse de fabricants, espionnage via les systèmes de sécurité domestique.