Atteindre le service interne : reconnaissance réseau depuis un shell

Dès que vous avez un shell sur un hôte à l'intérieur d'un réseau, vous héritez de la portée de cet hôte. Un service de monitoring ou de santé isolé du réseau public par un pare-feu reste grand ouvert à tout ce qui tourne sur une machine déjà présente sur le sous-réseau interne. C'est tout l'intérêt de cet exercice : le service n'a jamais été conçu pour être exposé, donc ses concepteurs se sont reposés sur la frontière réseau comme seule protection contre les attaquants. À l'instant où vous obtenez un pied dans la place, cette frontière est derrière vous.

C'est exactement cette confiance qu'une vulnérabilité de type Server-Side Request Forgery exploite depuis l'extérieur. Une SSRF piège un serveur exposé publiquement pour qu'il envoie des requêtes en votre nom, de sorte que celles-ci arrivent depuis l'intérieur du périmètre et atteignent des services qui supposent que tout appelant interne est de confiance. Ici, vous le faites directement : c'est vous l'appelant interne. Le service interne exige bien un jeton, mais un contrôle de jeton ne vaut que par le secret de ce jeton, et les jetons ont tendance à finir quelque part où l'on peut les lire.

La seconde leçon concerne l'endroit où se cachent les secrets. Un fichier de configuration peut poliment vous indiquer qu'il ne contient pas le secret, mais l'agent qui dialogue avec le service doit connaître le jeton pour l'envoyer. Si ce jeton a été compilé dans le binaire livré, il s'y trouve en clair, juste à côté de l'URL à laquelle il est ajouté. Un programme compilé n'est pas un coffre-fort opaque ; c'est un fichier plein de chaînes lisibles.

• Supposer qu'un service interne est sûr parce qu'internet ne peut pas l'atteindre : le pare-feu ne sert à rien dès lors que vous appelez depuis l'intérieur du sous-réseau.
• Abandonner après avoir lu le fichier de configuration, qui indique clairement que le jeton n'y est pas stocké, au lieu d'examiner le binaire de l'agent juste à côté.
• Oublier purement et simplement de scanner la plage interne et essayer de deviner le port du service au lieu de laisser nmap indiquer celui qui est ouvert.
• Appeler l'endpoint sans le jeton et s'arrêter à la réponse 401, au lieu de récupérer l'identifiant et de rejouer la requête.

Traiter la frontière réseau comme votre seule authentification est l'erreur de fond. Un service interne devrait toujours vérifier qui l'appelle, pas seulement d'où vient l'appel. La segmentation réseau est une couche utile, mais elle doit venir en complément d'une véritable authentification par appelant, pas la remplacer.

• Authentifiez chaque appelant avec des identifiants de courte durée, propres à chaque client, délivrés par un gestionnaire de secrets, jamais un jeton statique unique partagé.
• Gardez les secrets hors des artefacts livrés : injectez-les au moment de l'exécution via des variables d'environnement ou un coffre-fort, de sorte qu'un binaire divulgué ne révèle rien. Lancez strings sur vos propres builds avant publication pour le vérifier.
• Faites tourner tout jeton dès qu'un hôte est compromis, et limitez la portée de chaque jeton pour qu'une fuite n'ouvre que le strict minimum.
• Appliquez des principes de zero-trust en interne : TLS mutuel ou requêtes signées entre services pour qu'un attaquant présent sur un hôte ne puisse pas interroger librement le suivant.