SecurityInsider
Le blog des experts sécurité Wavestone

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 :

Aucun commentaire:

Enregistrer un commentaire