BEEMKA – Electron Post-Exploitation When The Land Is Dry

Lors de les BSides Las Vegas 2019, Pavel « @ sadreck » Tsakalidis a présenté un nouveau framework de post-exploitation qui repose sur l’utilisation d’Electron par des « applications desktop ». Sa présentation démontre que l’utilisation massive d’Electron ces dernières années peut être utilisée pour injecter du code malveillant dans des applications légitimes.
Le projet peut être retrouvé sur le dépôt GitHub suivant : https://github.com/ctxis/beemka.

Introduction

Electron est un framework permettant de développer des applications multiplateformes avec des technologies web (Javascript, HTLM et CSS).
Son fonctionnement est assez simple, Electron utilise « node.js » en backend et « Chromium » en frontend :
Electron a notamment permis de développer des applications aujourd’hui incontournables en entreprise :
Applications Electron

Principe de l’attaque

Les applications Slack, GitHub ou encore Microsoft Teams utilisent le dossier « App Data » lors de l’installation. Il est donc possible pour l’utilisateur d’accéder en écriture au répertoire d’installation.
Toutes les applications Electron possèdent un dossier « resources » dans leur répertoire d’installation :
Illustration avec GitHubDesktop
 
Ce dossier contient généralement :
  • Le dossier « app » qui contient l’application ;
  • Le fichier « electron.asar » qui prépare l’environnement Chronium au lancement de l’application.
Le fichier « electron.asar » peut être considéré comme une archive qui contient des scripts « *.js » :
Conteneur « electron.asar »
Le fichier « chrome-extension.js » permet la gestion de l’environnement Chronium :

 

Pavel propose ainsi d’injecter directement dans ce fichier du code javascript, permettant de lancer une action malveillante lors d’un évènement spécifique :

app.on(‘browser-window-focus‘, function (event, bWindow) { bWindow.webContents.executeJavaScript(« alert(Hello Github !!’);« ) })

 

Lors de l’ouverture de l’application (après avoir packé le fichier « electron.asar » et redéposé dans le répertoire « resource »), un pop-up (XSS style) va s’ouvrir dans l’application GitHub Desktop :
Illustration avec GitHub Desktop
Le code est donc correctement exécuté.

Démonstration

La vidéo suivante présente une démonstration du module « rshell_cmd » dans GitHub Desktop, permettant d’ouvrir un reverse shell vers notre listener :
La commande utilisée est la suivante :

$ python3 ./beemka/beemka.py —inject module rshell_cmd —asar ./electron_safe.asar —output ./electron.asar

De plus, l’exécutable de l’application « GitHub Desktop » n’est jamais modifié durant la modification du fichier « asar ». Cette technique peut donc permettre de contourner une politique de filtrage présente sur le poste.

Conclusion

Le framework présenté par Pavel est très intéressant pour compléter ses techniques de persistance. En effet, il se base sur le fonctionnement intrinsèque d’Electron et ne nécessite pas d’exploiter une vulnérabilité présente dans les applications.
Le framework permet aussi d’aller plus loin en accédant aux données des applications mais aussi de réaliser d’autres opérations comme déposer un keylogger, prendre un Screenshot, …
A ce jour, aucune solution n’était proposée par Electron pour mieux vérifier l’intégrité des fichiers des applications. Le plus simple est d’installer les applications dans « Programmes files » avec les privilèges administrateurs pour ne pas permettre à un utilisateur standard d’éditer le fichier « electron.asar ».
Ps : BloodHound est aussi une application Electron, une bonne « blague » à faire aux équipes Red/Blue Team :
Back to top