Into The Breach : du Mod à la backdoor

I. Présentation

Dans cet article nous allons voir en quoi la modification d'un jeu, lorsqu'elle est possible, peu mettre en danger les joueurs, notamment par l'intermédiaire des mods. Le cobaye du jour est le jeu Into The Breach.

Je m'intéresse depuis un petit temps à la sécurité des jeux vidéo, business en pleine croissance dans lequel la sécurité informatique et la sécurité de l'information est de plus en plus présente. Triche, harcèlement de joueur, vol de compte, déni de service sont quelques exemples de cas et d'attaques pouvant toucher les jeux vidéo, ces attaques impactent directement la réputation, jouabilité et intérêt du jeu pour les joueurs, et donc in fine l'argent généré par ce jeu.

Bref, sujet passionnant, je vous recommande la lecture et visualisation des éléments suivants :

• https://github.com/dsasmblr/game-hacking
• Slide sur la sécurité des jeux video sur Slideshare
• OWASP Game Security Framework Project

Dans ce contexte, je me suis intéressé au jeu Into The Breach, un jeu en local uniquement (on commence doucement), rogue-like (https://fr.wikipedia.org/wiki/Rogue-like), sortie en ce début d'année 2018. Je vous recommande d'ailleurs chaudement d'y jouer, ainsi que FTL (Faster Than Light) du même éditeur. Il s'agit en gros d'un jeu de stratégie tour par tour.

L'objectif de cet article est donc de commencer à parler de la sécurité des jeux vidéo, comprendre leur fonctionnement, mesures de protection et notamment la façon dont nous pouvons appliquer les éléments de la sécurité informatique, forensic (investigation numérique), test d'intrusion, etc. aux jeux vidéo. Nous allons ici commencer par étudier le fonctionnement du jeu (les éléments qui nous intéressent), essayer quelques techniques simples de triche et ensuite voir comment nous pouvons utiliser ces informations afin d'insérer du code malveillant à l'intérieur du jeu. J’émettrai enfin quelques "pistes" ou méthodes connues qui pourraient permettre, dans un contexte réel, de diffuser ce code malveillant.

II. Étude du fonctionnement du jeu

Commençons donc pour étudier le fonctionnement général du jeu, c'est à dire l'exécutable (ou binaire) permettant d'exécuter le jeu. J'utiliserai pour cela les outils suivants :

• Process Explorer : fait partie des Windows Sysinternals, il s'agit d'un gestionnaire de tâche avancé permettant de récupérer un grand nombre d'informations sur les processus en cours d'exécution.
• Process Monitor : fait partie des Windows Sysinternals, permet de suivre avec précision les activités d'un ou plusieurs processus (activités concernant le registre, le réseau, le système de fichier, etc.).

L'activité, pour l'utilisateur, du jeu peu se résumer en trois phases :

• accès au menu du jeu, qui permet de modifier les options, reprendre ou commencer une partie ;
• préparation du lancement de partie, permet de composer et personnaliser sa squad (équipe) et de choisir le niveau de difficulté ;
• déroulement de la partie, un enchainement de niveaux de plus en plus difficiles.

Voici une vue de cette cette dernière phase :

On exécute donc le jeu une première fois, ainsi que Process Explorer :

Par défaut, Process Explorer nous permet donc de voir plusieurs informations, telles que les fichiers actuellement ouverts par le processus qui nous intéresse (Breach.exe), c'est également l'occasion de voir si Breach.exe ouvre d'autres processus, ce qui pourrait être le cas s'il possédait un anti-cheat, l'ouverture d'un processus par un autre processus pourrait se constater dans l'arborescence des processus, par exemple :

Process Explorer nous permet également d'obtenir plusieurs informations à propos du processus Breach.exe et de son contexte d'exécution, on fait pour cela un clic droit > Properties.... On peut ainsi voir, par exemple, le chemin d'accès à l'exécutable :

On constate également l'état des protections pouvant être positionnées sur l'exécutable, (Data Execution Prevention, ASLR, Control Flow Guard), etc. Pour rappel, ces informations peuvent également être visualisées pour l'ensemble des processus grâce à l'ajout de colonnes dans la fenêtre principale :

Le panneau Properties permet également de voir les connexions ouvertes par le processus :
Ou encore les variables d'environnement de celui-ci :

Parmi les information intéressantes ici, le chemin APPDATA, INSTALLEDIR, etc .Bref, Process Explorer permet de faire un premier tour du processus. Nous allons à présent utiliser Process Monitor et son système de filtre afin de tracer l'exécution de Breach.exe. Dés son ouverture, Process Monitor nous affiche son interface de filtre, permettant notamment de créer un filtre pour cibler un processus spécifique, comme ci-dessous :

Je cible donc les activités qui concernent le processus Breach.exe. L'intérêt de Process Monitor est également qu'il peut être démarré avant l'exécution du processus qui nous intéresse, ce qui permet de tracer les premières actions de celui-ci dés son démarrage et son historique tout au long de son exécution. :

On peut par exemple constater ici qu'un ensemble de dll sont ouverts par le processus, on constate également la présence de fichiers .dat, .bank et de fichiers de journalisation (log.txt) :

J'observe également l'ouverture d'un grand nombre de fichier .lua :
Afin d'avoir une vue plus claire de l'ensemble des fichiers, j'ajoute un filtre sur les opérations QueryOpen et sur les chemins qui finissent pas ".lua" :

Cela permet d'obtenir la liste complète des fichiers .lua ouverts dés le démarrage du processus :

Intéressant, j'y reviendrai plus tard. J'applique le même filtre, cette fois-ci pour les fichiers .dll :
Process Monitor permet donc de tracer avec précision les actions d'un processus, celui-ci est souvent utilisé, notamment en sécurité pour les activités de reverse de malware (entre autres). Ici, il nous a permis de voir quels étaient les fichiers lus par Breach.exe. Jetons un œil au répertoire du jeu :

J'y retrouve les dll, les scripts .lua, les fichiers de logs et les ressources (.bank et .dat). Je m'intéresse rapidement aux fichiers de ressources pour voir ce qu'ils contiennent, pour une étude plus rapide, je les transfert sur une machine KaliLinux qui dispose d'un ensemble d'outils permettant d'effectuer ce type d'opération :

root@kali:/tmp/resources# ls -al
total 172180
drwxr-xr-x 2 root root 4096 Mar 24 20:50 .
drwxrwxrwt 14 root root 4096 Mar 24 20:50 ..
-rw-r--r-- 1 root root 100800 Mar 4 22:53 'Master Bank.bank'
-rw-r--r-- 1 root root 25764 Mar 4 22:53 'Master Bank.strings.bank'
-rw-r--r-- 1 root root 9669216 Mar 4 22:53 ambience.bank
-rw-r--r-- 1 root root 113497952 Mar 4 22:53 music.bank
-rw-r--r-- 1 root root 36681498 Mar 7 18:36 resource.dat
-rw-r--r-- 1 root root 16312256 Mar 6 18:50 sfx.bank
root@kali:/tmp/resources# file *
Master Bank.bank: RIFF (little-endian) data
Master Bank.strings.bank: RIFF (little-endian) data
ambience.bank: RIFF (little-endian) data
music.bank: RIFF (little-endian) data
resource.dat: PGP\011Secret Sub-key -
sfx.bank: RIFF (little-endian) data

La commande file permet permet d’avoir quelques informations sur les types de fichier, rien de bien parlant. J'utilise l'outil foremost pour tenter d'extraire les fichiers contenus dans le fichier resource.dat :

root@kali:/tmp/resources# foremost resource.dat
Processing: resource.dat
|*|
root@kali:/tmp/resources# ls
'Master Bank.bank' ambience.bank output sfx.bank
'Master Bank.strings.bank' music.bank resource.dat

J'obtiens alors un ensemble d'images, qui sont celles utilisées pour afficher le visuel utilisateur, ce qui permet de comprendre comment fonctionne l'affichage des informations :

Chaque visuel vu par l'utilisateur est donc un ensemble d'images positionnées tel qu'ordonné par le jeu. Cela peut notamment être intéressant si l'on souhaite crée un mod (j'y reviendrai) afin de changer, par exemple, l'aspect visuel du jeu (panneau de contrôle, aspect des ennemis, etc.).

Les fichiers .bank opposent un peu plus de résistance, l'utilisation de foremost sur ceux-ci ne donne rien, j'utilise donc binwalk qui va tenter de me dire quels sont les types de fichier contenus dans le fichier music.bank :

root@kali:/tmp/resources# binwalk music.bank
DECIMAL HEXADECIMAL DESCRIPTION
 --------------------------------------------------------------------------------
 1905669 0x1D1405 MySQL ISAM index file Version 5
 8207261 0x7D3B9D StuffIt Deluxe Segment (data): f
 11827947 0xB47AEB MySQL MISAM index file Version 6
 17252787 0x10741B3 StuffIt Deluxe Segment (data): f
 19688536 0x12C6C58 StuffIt Deluxe Segment (data): f
 27311935 0x1A0BF3F Cisco IOS experimental microcode, for "z"
 66127348 0x3F105F4 StuffIt Deluxe Segment (data): f
 86886121 0x52DC6E9 StuffIt Deluxe Segment (data): f
 91632984 0x5763558 StuffIt Deluxe Segment (data): f
 97794565 0x5D43A05 StuffIt Deluxe Segment (data): f
 109069865 0x6804629 VMware4 disk image

Rien de bien parlant, je me renseigne sur le format de fichier .riff (indiqué par la commande file précédemment) et trouve quelques dépôts Github qui semblent pouvoir extraire des informations de ce type de fichier, notamment l'outil suivant : https://github.com/panzi/mediaextract

git clone https://github.com/panzi/mediaextract.git
cd mediaextract
make buidldir
make
make install PREFIX=/usr
mediaextract -f riff,ogg,aiff,mp4,image,audio ../resources/music.bank

J’obtiens alors un très grand nombre de fichiers, qui semblent constituer la bande sonore (musiques et effets) du jeu :

Bien, nous avons à présents un ensemble d'informations sur la constitution du jeu et son activité.

III. Modification des informations de profil & de la partie (triche)

Lors de notre première analyse, nous avons pu distinguer différents fichiers qui étaient lus par le processus Breach.exe. L'un d'entre eux l'est d'ailleurs de façon très fréquente lors des combats, le fichier saveData.lua :

Intéressons nous donc à ce fichier en particulier. Process Monitor nous permet d'ailleurs de connaitre son chemin, afin de le retrouver rapidement, comme vous pouvez le voir ci-dessus.

Après analyse, qui nécessite d'avoir quelques connaissances sur le jeu, je déduis que ce fichier sert à enregistrer la partie courante, j'y trouve donc mon score, la vie et la capacité de mes unités et des ennemis du combat courant. Une bonne chose, ce fichier est accessible et compréhensible. Après une première lecture, je tente de tracer son évolution (les changements apportés) après avoir joué quelques minutes. J'utilise pour cela le Plugin "Compare" de Notepad++, qui permet de comparer et pointer les changement entre deux fichiers. J'expose l'ensemble de la démarche en vidéo :

Vous l'aurez compris, on peut modifier librement les fichiers saveData.lua et profile.lua afin de tenter de modifier les statistiques de nos unités, des unités ennemis, notre score global, les squad débloquées, débloquer des succès Steam, etc.

IV. Modification du jeu ("mod")

Bien, nous avons à présent réussi à modifier les informations de notre profil afin d'obtenir un meilleur score, d'améliorer nos unités et d'affaiblir l'ennemi par des vecteurs autres que le jeu lui même (aussi connu sous le nom de "triche"). Voyons si nous pouvons modifier le comportement du jeu de façon durable, par exemple en modifiant des éléments dans son exécution. La possibilité de modifier le jeu de cette façon ouvre la voie vers les Mods.

Dans le monde du jeu vidéo, un mod (abréviation de modification) est un jeu vidéo créé à partir d'un autre, ou plus souvent une modification du jeu original, sous la forme d'un greffon qui s’ajoute à l'original, le transformant parfois complètement. Les mods les plus courants se rencontrent sur PC (Source:  https://fr.wikipedia.org/wiki/Mod_(jeu_vid%C3%A9o) )

Pour cela, nous allons revenir quelques instants sur les fichiers LUA chargés dés le lancement du jeu. Ceux-ci sont situés dans le répertoire /scripts/ du jeu :

Visiblement, ils contiennent les scripts d'exécution du jeu, écrit en LUA :

Lua est un langage de script libre, réflexif et impératif. Créé en 1993, il est conçu de manière à pouvoir être embarqué au sein d'autres applications afin d'étendre celles-ci. (Source : https://fr.wikipedia.org/wiki/Lua).

On peut donc parcourir librement ces scripts, et pourquoi pas les modifier. A noter que ces fichiers sont chargés uniquement au démarrage du jeu, ils sont donc en mémoire ensuite et leur modification n'aura aucun effet sans un redémarrage du jeu. Dans cet exemple, je modifie la portée de mouvement de mes unités :

Ici, je modifie la disposition de la carte, ce qui peut laisser entrevoir la possibilité d'ajouter d'autres éléments à l'intérieur :

Dans ce dernier exemple, je modifie les possibilités de couleur des unités, ce qui peut tout à fait faire partie d'un mod que les joueurs pourraient télécharger :

Bref ! Le code du jeu est totalement ouvert, j'ignore si cela est intentionnel ou non, mais le fait est que n'importe quel joueur est libre de modifier le jeu comme il le souhaite. En cherchant un peu, je pense également que l'on peut modifier les images contenues dans le fichier resource.dat, "recompresser" ces images et constater leur utilisation dans le jeu. Mais je n'ai pas pris le temps de le faire.

V. Injection d'une porte dérobée ou d'un code malveillant

Bien, nous sommes donc maintenant de parfait tricheur, nous pouvons modifier le code du jeu afin d'obtenir un avantage face à l'ordinateur, modifier notre score, la vie des unités alliées et ennemies, etc. Mais cela ne présente que peu d'intérêt car le jeu est en local uniquement, la seule conséquence concrète de cette manipulation est de détruire sa propre expérience en tant que joueur, à quoi bon passer des heures à jouer pour finir le jeu si je peut le faire en modifiant un fichier de configuration ? L'autre intérêt peut être la conception de mod, c'est à dire une version modifiée du jeu afin d'introduire de nouveau éléments, des difficultés supplémentaires, pourquoi pas de nouveaux ennemis, des couleurs à l'image d'unité à l'image de l'évènement du moment (Noël, Halloween, etc.), et plus encore.

Nous allons donc continuer notre aventure en essayant d'injecter du code malveillant dans les scripts LUA qui permettent l'exécution du jeu. Par code malveillant, j'entends par exemple :

• un adware, par exemple l'ouverture automatique du navigateur afin que l'utilisateur se rende sur une page contenant de la pub, ce qui va me rapporter de l'argent;
• une porte dérobée (backdoor), par exemple un reverse shell TCP;
• du code permettant le vol d'informations sur le joueur et l'envoi de ces informations à l'attaquant (compte steam ?);
• autre malware, ransomware, etc.

Nous avons pour cela tous les éléments nécessaires, nous savons déjà que le code est modifiable, que tous les fichiers LUA sont chargés lors du démarrage du jeu. Sans aucune connaissance en LUA, voyons ce que l'on peut faire.

A. Conception d'un adware

Par adware, j'entends donc l'ajout d'un bout de code qui va me permettre, en tant que moddeur ou en tant qu'"attaquant", de gagner de l'argent grâce à la de publicité une fois que ma version modifiée du jeu sera installée sur les postes des joueurs. Habituellement, l'adware va parfaitement s'intégrer dans le jeu, mais je vais ici faire quelque chose de plus rudimentaire. Par exemple ouvrir le navigateur du joueur pour qu'il se rende automatiquement sur une page contenant de la publicité. Cela est faisable à partir d'un terminal Windows avec la commande suivante par exemple :

explorer https://ogma-sec.fr

Il faut donc faire quelque chose d'équivalent en LUA, et l'intégrer dans un des scripts LUA chargé au démarrage du jeu. Après quelques recherches, je remarque que l'on peut exécuter la fonction os.system, qui permet d'exécuter des commandes systèmes en LUA. J'intègre donc la commande suivante dans le script global.lua :

Cet ensemble de commandes va donc simplement ouvrir plusieurs fois une page web en direction de l'URL indiquée. Premier test, j'enregistre le fichier et exécute le jeu, mon adware est bien en place et m'ouvre plusieurs page en direction de l'URL indiquée.

B. Ajout d'une porte dérobée

Nous allons à présent insérer une porte dérobée dans notre jeu vidéo modifié, je récupère pour cela le code d'un reverse shell TCP en Powershell tout simple sur le dépôt Github suivant : https://gist.github.com/staaldraad/204928a6004e89553a8d3db0ce527fd5

L'idée est donc de mettre en place :

• Un service web basique sur lequel le jeu (code modifié) pourra télécharger ce reverse shell;
• modifier le code du jeu pour qu'il télécharge ce reverse shell, puis qu'il l'exécute.

Sur mon poste d'attaque, je télécharge donc ce script depuis Github et le modifie pour qu'il contacte mon IP d'attaquant, j'ouvre ensuite un service web simple en Python pour que ce script puisse être téléchargé. En ce qui concerne la modification du code du jeu pour qu'il télécharge et exécute ce script, la voici, toujours dans le fichier global.lua :

Voila le tout en cours d'exécution, en première partie j'expose l'action de l'adware, puis de la porte dérobée. A noter qu'il s'agit uniquement de PoC et qu'ils ne sont pas discrets du tout (le reverse shell bloque d'ailleurs l'exécution de la suite du jeu). Mais peu importe, un attaquant ayant le temps et la motivation réelle pourra librement effectuer des opérations bien plus furtives.

V. Diffusion de la version modifiée

Comme indiqué plusieurs fois, le code modifié l'est ici uniquement en local. Il existe cependant plusieurs moyens d'implanter du code malveillant, notamment au travers la diffusion d'un mod.

En effet, le monde du jeu vidéo contient des milliers de forums qui permettent d'interconnecter les joueurs autours d'un même genre de jeu ou d'un même jeu. C'est également sur ces forums que sont diffuser des mods. Si vous avez finis un jeu et que vous souhaitez continuer à découvrir des choses, les mods permettent d'obtenir de nouveau contenus (comme dit précédemment, nouveaux ennemis, difficultés supplémentaires, etc.) souvent produits par les joueurs eux-mêmes.

Un attaquant n'aura donc qu'à créer un mod qui semble légitime (par exemple via une modification des couleurs du jeu) et à inclure dans celui-ci du code malveillant. Les mods étant diffusés et installés par les joueurs, et non via un mécanisme propre au jeu, aucun contrôle de sécurité ne sera effectué.

Également, le code malveillant peut être diffusé selon le même modèle, mais cette fois si sous la forme d'une triche, par exemple "Insère ce ficher à la place du fichier existant dans le répertoire /scripts/ du jeu et tous tes unités seront presque invincible".
Bref, ce ne sont pas les idées qui manquent, et peu nombreux seront les joueurs qui penseront à regarder (et comprendre) le contenu du mod afin de vérifier qu'il ne contient pas de code malveillant à l'intérieur.

VII. Conclusion

Quelques leçons à tirer de cet article :

• L'étude du fonctionnement d'un jeu utilise les mêmes techniques et outils que l'analyse de malware ou de n'importe quel autre logiciel.
• Un jeu modifiable (souvent pour laisser la possibilité aux joueurs de créer des mods) possède souvent une plus grand surface d'attaque car les développeurs laissent intentionnellement le code du jeu et son fonctionnement interne consultables par les joueurs.
• Les jeux qui tournent en local uniquement (c'est à dire non multijoueurs) ne possèdent souvent aucun mécanisme de protection ou de solution anti-cheat, ils font donc une cible de choix pour s'entrainer.
• Soyez vigilants lorsque vous téléchargez et installez un mod, également lorsque que vous installez des jeux "non officiels".

Mickael Dorigny Co-founder

Co-fondateur d'IT-Connect.fr. Auditeur/Pentester chez Orange Cyberdéfense.

See Full Bio