Shells et reverse shells : comprendre le principe, sans code d'exploitation

Quand une exploitation réussit, elle se traduit souvent par l'obtention d'un « shell » : un accès en ligne de commande sur la machine distante. Comprendre comment cet accès s'établit, et pourquoi il prend souvent la forme d'une connexion « inversée », éclaire à la fois l'attaque et, surtout, la détection côté défense. C'est l'objet de cette leçon, volontairement centrée sur les principes.

Qu'est-ce qu'un shell, pour rappel

Vous avez déjà manipulé un interpréteur de commandes (shell) dans le cours sur Linux : un programme qui lit vos commandes et les exécute. Quand un attaquant (ou un testeur en labo) obtient un shell sur une machine distante, cela signifie qu'il peut désormais lui envoyer des commandes et en recevoir le résultat, comme s'il était physiquement devant cette machine.

Shell direct (« bind shell ») : le principe

Dans un schéma de connexion directe, c'est la machine cible qui se met à l'écoute sur un port et attend qu'on vienne s'y connecter. L'attaquant initie la connexion vers la cible, comme pour n'importe quel service réseau.

Ce schéma a une faiblesse pratique pour un attaquant réel : beaucoup de réseaux filtrent les connexions entrantes avec un pare-feu. Une machine qui ouvre un nouveau port en écoute a de bonnes chances d'être bloquée avant même qu'une connexion n'arrive.

Shell inversé (« reverse shell ») : le principe

Dans un schéma inversé, c'est l'inverse : c'est la machine compromise qui initie la connexion vers une machine contrôlée par l'attaquant (ou, en labo, par vous-même), qui se met préalablement à l'écoute. Cette approche contourne souvent les règles de pare-feu qui bloquent les connexions entrantes mais laissent passer les connexions sortantes initiées depuis l'intérieur du réseau, ce qui est très courant en pratique.

C'est pour cette raison que le schéma inversé est très répandu dans les scénarios réels, et c'est précisément ce qui en fait un signal important à surveiller côté défense : une machine qui initie soudainement une connexion sortante inhabituelle, vers une adresse inconnue, est un indice fort de compromission.

Schéma comparatif

Pourquoi aucune commande n'est fournie ici

De nombreux langages et utilitaires (y compris des outils très courants présents par défaut sur de nombreux systèmes) peuvent techniquement établir ce genre de connexion. Fournir une commande prête à l'emploi reviendrait à fournir une charge utile fonctionnelle, ce que ce cours exclut explicitement. Ce qu'il faut retenir, ce n'est pas « quelle commande taper », mais : pourquoi une connexion sortante initiée par une machine compromise est un schéma courant, et comment la détecter.

Shell interactif limité et amélioration

Un premier accès obtenu de cette façon est souvent « limité » : pas de réelle interactivité (pas d'autocomplétion, de combinaisons de touches), parfois des privilèges restreints. Les testeurs parlent d'« amélioration » du shell pour désigner le fait de transformer cet accès basique en une session plus confortable et plus fonctionnelle à administrer, toujours dans le même esprit méthodique que la leçon précédente : chaque étape est volontaire, observée et documentée.

Ce que la défense peut faire

Comprendre ce principe permet de bâtir des défenses concrètes, qui sont bien plus utiles à retenir que n'importe quelle commande d'attaque :

• Filtrer les connexions sortantes : un pare-feu qui ne laisse sortir que ce qui est nécessaire (une liste blanche de destinations et de ports) réduit fortement la facilité d'un shell inversé ;
• Surveiller les connexions inhabituelles : un système de détection qui repère un serveur web qui se met soudain à initier des connexions vers l'extérieur ;
• Journaliser les processus : savoir quel programme a ouvert quelle connexion, et depuis quel compte ;
• Segmenter le réseau : limiter ce qu'une machine compromise peut atteindre, même si elle établit une connexion ;
• Limiter les privilèges des comptes de service, pour que même un accès obtenu reste peu utile à un attaquant (principe du moindre privilège, déjà vu dans le premier cours du parcours).

Ces principes rejoignent les tactiques décrites par MITRE ATT&CK (attack.mitre.org), notamment celles liées à l'accès initial, à l'exécution et à la communication avec un serveur de commande. Un défenseur qui connaît ce vocabulaire peut configurer ses outils de détection pour repérer ces comportements précis.

Le point de vue du rapport

Dans un rapport de pentest, cette étape se décrit toujours en termes d'impact, jamais de recette : « l'exploitation de la faille X a permis d'obtenir une exécution de commandes à distance sur la machine cible, démontrée par une connexion de démonstration non destructive vers un poste de contrôle sous notre responsabilité, dans le respect du périmètre autorisé ». Le client comprend l'impact sans recevoir un mode d'emploi d'attaque.

À vous de jouer : concevoir une détection

Imaginez que votre labo contienne un outil de surveillance réseau simple (même une capture Wireshark comme vous l'avez appris au cours précédent). Décrivez, en langage non technique, trois signaux que vous chercheriez pour repérer un shell inversé sur votre propre réseau de labo : par exemple une connexion sortante vers une adresse qui n'a aucune raison d'être contactée, une activité réseau continue et interactive (plutôt que des échanges ponctuels), ou un programme inhabituel à l'origine d'une connexion. Puis proposez, pour chacun, une mesure de prévention correspondante.

Un accès initial, même limité à une seule machine, ouvre parfois la porte à d'autres parties du réseau. C'est le sujet de la dernière leçon de ce chapitre : le pivoting.