Le L de Linux signifie « mouvements latéraux »
Introduction
Outre l'adoption du protocole SSH, que pouvez-vous faire ?
Sélection des candidats
Protocoles permettant une exécution de code immédiate
SNMP
Protocoles de bureau à distance
Telnet
Commandes Berkeley distantes
Protocoles permettant un transfert de fichiers
FTP
Samba
NFS
rsync
Exécution à distance via un transfert de fichiers
Persistance distante
Web shells
Les conteneurs ne devraient permettre aucune fuite de données
Protégez-vous avant qu'il ne soit trop tard
Résumé
Introduction
Concernant les techniques de mouvement latéral qui ne reposent pas sur l'exploitation de vulnérabilités, il existe de nombreux protocoles et outils légitimes que les attaquants peuvent exploiter : PsExec, RDP, SSH, WMI, etc. En général, la plupart d'entre eux ne sont disponibles que sur les machines Windows. Cependant, lorsqu'il s'agit de machines Linux, un seul protocole vient à l'esprit : SSH. Dans ce billet de blog, nous allons examiner d'autres protocoles Linux que des acteurs malveillants peuvent utiliser pour se déplacer latéralement.
Bien sûr, Linux n'est pas un système d'exploitation, mais seulement le noyau. Il serait donc plus précis de dire que nous allons étudier les systèmes d'exploitation basés sur Linux, ou les distributions Linux. Il est pratiquement impossible de trouver un protocole ou service courant qui est pré-configuré pour fonctionner sur plusieurs distributions (même SSH n'est pas pré-installé dans toutes les distributions). Nous allons donc nous concentrer sur les protocoles et services les plus importants, quelle que soit la distribution Linux avec laquelle ils sont fournis.
Ce billet de blog n'a pas pour but de faciliter le piratage des machines Linux, mais d'informer les responsables de la protection réseau des menaces potentielles susceptibles d'affecter leurs réseaux.
Outre l'adoption du protocole SSH, que pouvez-vous faire ?
La plupart des protocoles (si ce n'est tous) que nous allons aborder dans ce billet ne sont pas pré-installés, mais doivent être configurés de manière spécifique pour permettre à un cybercriminel de se déplacer latéralement. Notre objectif n'est pas d'aider quiconque à utiliser de manière abusive les protocoles abordés dans ce billet.
Notre souhait est de faire découvrir d'autres protocoles qui peuvent être configurés de telle sorte qu'ils deviennent vulnérables et exploitables par des utilisateurs mal intentionnés. Un pirate déterminé n'a pas besoin de nous pour trouver et utiliser de manière abusive les protocoles abordés dans ce billet. Nous voulons que la Blue Team y soit préparée.
Pour aider davantage les défenseurs, nous avons collaboré avec notre équipe Infection Monkey. Infection Monkey est une plateforme open source de simulation de violations et d'attaques qui teste la résistance de votre réseau face à de nombreuses techniques courantes de mouvement latéral et de propagation sur le réseau.
L'équipe de développement a utilisé les résultats de nos recherches et les a intégrés comme nouvelle technique d'exploitation à l'intérieur de l'outil. Les défenseurs peuvent utiliser Infection Monkey pour tester la résistance de leur réseau face à certaines techniques d'exécution à distance mentionnées dans ce billet.
Sélection des candidats
[Remarque : cette section traite de la méthode que nous avons utilisée pour trouver des cibles intéressantes de mouvements latéraux. Si cette méthodologie ne vous intéresse pas et que vous préférez passer directement à l'action, accédez à la section « Protocoles permettant une exécution de code immédiate ».]
Puisque nous recherchons des services et protocoles de mouvement latéral, nous pouvons prendre en compte les aspects relatifs au système d'exploitation et au réseau lors de toute recherche de candidats potentiels. En d'autres termes, nous pouvons chercher les processus les plus courants sur les machines Linux ou examiner les ports d'écoute les plus courants. Nous ne devons pas en négliger un en faveur de l'autre, car un même protocole peut être mis en œuvre de différentes façons (nom de processus différent, même port) ou un processus unique peut avoir plusieurs ports ou changer de ports (comme les ports éphémères dans RPC).
Lorsque nous avons examiné les principaux ports utilisés pour communiquer avec les machines Linux, nous avons constaté que SSH (port 22) figurait en haut de la liste, mais que d'autres candidats pouvaient également s'avérer prometteurs : FTP (port 21), SNMP (port 161) et Sun RPC (port 111).
Certains ports étaient également gérés par sshd (processus démon SSH), même s'ils n'avaient rien à voir avec le protocole SSH. Nous partons du principe que ces ports sont utilisés dans des tunnels SSH et qu'ils n'entrent donc pas dans le cadre de nos recherches.
Prenons l'exemple des ports 135 et 5985 utilisés sous Windows, respectivement pour RPC et WinRM. Nous ne nous attendons pas à trouver ces ports sur des machines Linux, surtout quand le processus sshd les utilise comme ports d'écoute. Il est plus probable qu'un tunnel SSH était ouvert sur une machine Linux disponible en externe pour permettre l'accès aux machines internes. Étant donné que les tunnels SSH redirigent uniquement le trafic vers un autre destinataire, ils ont peu d'importance lorsqu'il s'agit d'envisager un mouvement latéral dans l'hôte du tunnel.
Nos conclusions ont fait ressortir deux processus intéressants : xinetd et rpcbind. Ils ne sont pas viables en tant que cibles de mouvement latéral, car ils n'offrent pas beaucoup de fonctionnalités. Ils sont principalement utilisés pour les opérations de recherche afin de mapper les communications et les ports à d'autres processus. En revanche, nous pouvons les utiliser pour trouver d'autres services intéressants.
xinetd (et son prédécesseur inetd) permet de contrôler et de gérer les démons. En consultant la liste par défaut des démons qu'il gère, nous pouvons trouver rexec, ainsi que rlogin et rsh, tous faisant partie de la suite de commandes Berkeley distantes . Nous pouvons également trouver divers démons FTP , VNC et Telnet.
rpcbind est le processus portmapper RPC pour Sun RPC. Les serveurs RPC s'enregistrent auprès du service portmapper et les clients peuvent interroger ce dernier pour trouver le port éphémère du serveur. Contrairement à MS-RPC, Sun RPC utilise des numéros de programme pour identifier des serveurs RPC spécifiques, et ceux enregistrés auprès de l'Internet Assigned Numbers Authority (IANA). En consultant les programmes enregistrés, des noms intéressants en ressortent, comme rexec et NFS.
Protocoles permettant une exécution de code immédiate
SNMP
24 % des machines Linux testées
Le protocole SNMP (Simple Network Monitoring Protocol) est utilisé pour la surveillance. Les machines exécutent un processus démon (généralement appelé snmpd) qui écoute les connexions sur le port UDP 161. Bien que le protocole SNMP soit généralement utilisé pour interroger les paramètres et statistiques des machines, il est également possible de définir des paramètres et configurations à distance à l'aide du protocole. Les versions antérieures de SNMP (v1 et v2) ne comptent pas beaucoup d'options de chiffrement ou d'authentification et exigent seulement un mot de passe (appelé « chaîne de communauté ») qui peut être détecté depuis le trafic réseau ou faire l'objet d'une attaque en force.
Il est également possible d'exécuter des commandes distantes via SNMP, en utilisant le plug-in EXTEND, chargé par défaut dans les versions antérieures de l'agent SNMP. Bien que cette option soit désactivée dans les versions plus récentes de SNMP (v5.8+), suite à une vulnérabilité CVE semi-connexe, nous avons tout de même observé des environnements dans lesquels la version vulnérable de SNMP était installée. Il est également possible de créer votre propre agent SNMP et d'activer le plug-in EXTEND (Figure 1).
Figure 1 : exécution d'un script distant à l'aide du plug-in SNMP EXTEND
Quelles que soient les fonctionnalités intégrées de SNMP, il s'agit également d'une cible pour les attaquants, certains acteurs malveillants utilisant les vulnérabilités de mises en œuvre SNMP dans des routeurs et terminaux IoT pour s'infiltrer dans les réseaux. L'utilisation abusive de SNMP a atteint un niveau tel que la Cybersecurity & Infrastructure Security Agency (CISA) a publié un avertissement concernant le protocole.
Pour vous aider à tester votre résistance face à cette menace, nous avons collaboré avec notre équipe Infection Monkey afin de développer un plug-in d'exploitation pour le plug-in SNMP EXTEND distant. Exécuter Infection Monkey vous permettra de simuler cette attaque dans votre environnement et de vérifier si votre stratégie de sécurité est suffisante pour y faire face. L'attaque SNMP est disponible dans la dernière version d'Infection Monkey, v2.2.1.
Protocoles de bureau à distance
10 % des environnements Linux testés
Non, nous ne parlons pas spécifiquement de RDP, le protocole de bureau à distance propriétaire de Microsoft (mais nous le mentionnerons, ne vous inquiétez pas). D'autres protocoles de bureau à distance peuvent être exécutés sur les machines Linux. Ils sont beaucoup moins courants que dans les environnements Windows, car ils ont pour but de partager des bureaux graphiques et la plupart des serveurs Linux sont installés sans environnement de bureau.
Cependant, nous avons vu ces protocoles utilisés dans quelques réseaux, et ils sont répertoriés ci-dessous :
Le système X Window est un système de fenêtrage disponible pour Unix, et il peut également écouter les connexions distantes. Il utilise les ports TCP à partir du port 6000. Ensuite, le numéro de port augmente pour chaque serveur de bureau exécuté.
VNC est basé sur le protocole RFB (Remote Framebuffer) et il utilise les ports TCP à partir du port 5900 (à l'instar du système X Window, le numéro de port augmente avec chaque serveur de bureau exécuté).
Xrdp est une mise en œuvre du protocole Microsoft RDP qu'il est possible d'utiliser sur des machines autres que Windows. En tant que mise en œuvre du protocole RDP, il utilise le port 3389.
Certains protocoles de bureau à distance sont plus sécurisés que d'autres, mais ils peuvent tous potentiellement être utilisés de manière abusive par des acteurs malveillants. Il existe également plusieurs mises en œuvre des protocoles sous Linux, c'est pourquoi nous avons mentionné les numéros de port au lieu des noms de programme.
Telnet
4 % des environnements Linux testés
À l'instar de SSH et rlogin, Telnet est un protocole utilisé pour assurer un contrôle ou une console à distance. Il est également non sécurisé et non chiffré, de la même manière que rlogin, et est vulnérable aux attaques par interception ou reniflage de paquets. Nous ne l'avons détecté que dans environ 4 % des réseaux que nous avons examinés, mais cela signifie qu'il est toujours utilisé et qu'il pourrait affecter votre réseau. Ce protocole utilise le port TCP 23 ou 2323.
Commandes Berkeley distantes
1 % des environnements Linux testés
Les commandes Berkeley distantes sont une suite de programmes permettant l'exécution d'opérations distantes sur les machines du réseau. Initialement développées dans le cadre du protocole BSD, elles ont été largement remplacées par SSH, principalement en raison de problèmes de sécurité (pas de chiffrement et authentification minimale, voire inexistante).
Pourtant, nous avons observé quelques démons parmi cette suite de programmes, et il est donc trop tôt pour les exclure entièrement. Voici notamment trois démons qu'il convient de mentionner :
rexec : assure l'exécution de commandes distantes et utilise le port TCP 512
rlogin : propose une console et une connexion à distance, et utilise le port TCP 513
rsh : similaire à rexec, mais ne nécessite pas d'authentification et utilise le port TCP 514
Protocoles permettant un transfert de fichiers
Même si un contrôle ou une exécution à distance n'est pas directement possible, le simple fait de pouvoir transférer des fichiers vers la machine cible peut s'avérer précieux pour les cybercriminels. Par exemple, examinons la technique courante et l'outil de mouvement latéral PsExec, même s'il est basé sur Windows.
Tout d'abord, cet outil copie son fichier binaire de service sur la machine cible via SMB, et il peut ensuite exécuter le service en communiquant à distance avec le gestionnaire de services. C'est pourquoi nous pensons qu'il est important de répertorier également les différentes façons dont les outils et fichiers binaires des attaquants peuvent être placés sur les machines cibles. Nous avons également émis des hypothèses concernant des méthodes d'utilisation abusive du transfert de fichiers pour réaliser une exécution à distance, que nous allons aborder ultérieurement dans ce billet.
FTP
31 % des environnements Linux testés
Le protocole FTP (File Transfer Protocol) est l'un des protocoles les plus classiques (il s'agissait du premier protocole de couche applicative enseigné en cours de gestion des réseaux). Utilisé pour le transfert de fichiers, il s'agit d'un protocole non sécurisé, car il repose sur du texte clair.
Samba
20 % des environnements Linux testés
Samba est une suite de programmes qui contribue à l'interopérabilité de Windows. Elle met en œuvre le protocole SMB (port TCP 445), peut héberger des serveurs de fichiers ou interagir avec eux, et peut également s'intégrer à Active Directory ou servir de contrôleur de domaine (Figure 2).
Alors que le protocole SMB, en tant que tel, n'est qu'un protocole de transfert de données, l'intégration à Active Directory permet d'observer plusieurs mises en œuvre de clients et serveurs RPC, ce qui multiplie les voies de propagation potentielles des mouvements latéraux.
Heureusement, nous n'avons pas trouvé de moyen clair d'utiliser Samba de manière abusive dans le cadre d'une technique de mouvement latéral. Le seul objectif de Samba étant d'assurer une bonne interopérabilité, de nombreuses logiques et fonctionnalités RPC inutiles n'ont pas été mises en œuvre. La surface d'attaque est donc limitée. Par ailleurs, le code est peu vérifié, comme l'indiquent divers commentaires dans le code source.
Il serait peut-être prudent de demander à une Red Team de vérifier la sécurité du contrôleur de domaine lors de l'utilisation d'un service Active Directory Samba, même si aucun mouvement latéral évident n'est observé vers ce service.
Figure 2 : commentaire TODO dans le code source de Samba
NFS
18 % des environnements Linux testés
Le protocole NFS (Network File System) est un autre moyen de créer des serveurs de fichiers. Il repose sur Sun RPC (port TCP 111). Nous pouvons observer de nombreuses fonctions RPC, mais nous n'avons pas trouvé de moyen direct pour assurer l'exécution de commandes distantes à l'aide de ces fonctions.
rsync
16 % des environnements Linux testés
rsync est un utilitaire de synchronisation et de transfert de fichiers entre les machines du réseau. Il peut s'exécuter en tant que service ou démon et partager des fichiers via son protocole dédié (port TCP 873), rsh ou SSH.
Exécution à distance via un transfert de fichiers
Nous pouvons parler de transfert de fichiers autant que nous le souhaitons, mais ce processus n'est pas très utile en tant que tel, à moins que les attaquants puissent exécuter les fichiers transférés d'une manière ou d'une autre. Outre le fait d'amener ou d'inciter l'utilisateur à exécuter le fichier lui-même, nous allons mentionner deux options qui répondent à cet objectif, les deux exigeant une mauvaise configuration ou un assouplissement important des paramètres de sécurité.
Persistance distante
De nombreux emplacements légitimes dans le système de fichiers Linux peuvent être utilisés pour installer une persistance. Toutefois, pour effectuer des mouvements latéraux, nous allons nous concentrer sur l'emplacement /etc/cron.hourly. Si un attaquant peut y charger un fichier, en disposant des autorisations d'exécution requises, il peut alors simplement exécuter ce fichier à la prochaine heure, ce qui lui permet de réaliser le mouvement latéral tant convoité.
Mais pour y parvenir, le cybercriminel a besoin d'autorisations sudo ou root, qui ne sont pas faciles à obtenir. Malheureusement, il est possible de configurer des serveurs de fichiers de manière non sécurisée, ce qui permettrait de réaliser ce scénario (voir rsync, par exemple). Pourquoi configurer ces services avec un niveau de sécurité si faible ? Car cela s'avère plus pratique et facilite la vie des utilisateurs. Ne faites pas cette erreur : protégez-vous.
Web shells
Autre scénario beaucoup plus plausible : au lieu d'utiliser l'emplacement /etc, l'attaquant accède à distance à un dossier racine Web d'un serveur Web actif. Il est alors possible de charger un web shell personnalisé et de l'utiliser pour exécuter des commandes distantes. De nombreux exemples de web shells sont disponibles en ligne, et les pirates n'ont donc qu'à se servir.
Les conteneurs ne devraient permettre aucune fuite de données
Ces dernières années, les conteneurs gagnent également en popularité. Au cours de nos recherches, nous avons observé plusieurs exemples de programmes de conteneurs qui écoutent et acceptent les connexions. Cela semble possible en raison de leur conception. Si les attaquants peuvent accéder à un gestionnaire de conteneurs distant, ils peuvent alors charger leur propre image malveillante et l'utiliser pour se propager davantage dans le réseau.
Protégez-vous avant qu'il ne soit trop tard
Maintenant que nous avons vu les différentes façons dont les cybercriminels peuvent prendre le contrôle des machines, voyons comment les en dissuader.
Visibilité
Comme nous l'avons déjà mentionné, aucun des protocoles dont nous avons parlé n'est pré-installé et pré-configuré avec Linux. Quelqu'un doit procéder volontairement à cette installation. Par conséquent, le premier réflexe consiste à avoir une bonne visibilité des services en cours d'exécution et de communication (ou des protocoles qui écoutent les communications) au sein de votre réseau. Comme l'a écrit Sun Tsu : « Si vous ne connaissez ni l'ennemi, ni vous-même, l'échec est inéluctable. »
Configuration
Après avoir fait l'inventaire de votre réseau et identifié l'un des services répertoriés dans ce billet de blog, l'étape suivante consiste à vérifier la configuration de ces services. Par exemple, un agent SNMP mis à jour et configuré pour utiliser SNMPv3 avec une authentification Kerberos convient parfaitement. Mais s'il est configuré pour utiliser SNMPv2 avec une chaîne de communauté facile à deviner, c'est une tout autre histoire.
Sécurité par l'obscurité
D'autres protocoles ou services peuvent être remplacés par des protocoles plus récents et plus sécurisés. Par exemple, il peut être judicieux d'utiliser SSH au lieu de la suite de commandes distantes ou de Telnet. Certains protocoles, comme FTP ou rsync, peuvent également être encapsulés via SSH afin de bénéficier du chiffrement. Il va s'en dire que vous devrez également vous assurer que le protocole SSH est correctement configuré, avec des ICP (infrastructures à clés publiques) ou des mots de passe forts, difficiles à deviner.
Segmentation
Même si toutes les communications sont sécurisées, cela ne signifie pas pour autant que tout le monde doit pouvoir accéder à l'ensemble des ressources. Dans un réseau plat, les cybercriminels peuvent s'infiltrer facilement, alors qu'un réseau segmenté leur pose beaucoup plus de difficultés (Figure 3).
Si les pirates doivent se démener et mobiliser de nombreuses ressources pour accéder peu à peu au réseau, ils risquent d'abandonner leur attaque en raison de son manque de rentabilité. En outre, plus les attaquants cherchent à s'infiltrer dans le réseau, plus la violation est susceptible d'être détectée et de déclencher l'alarme. Vous pouvez alors lancer une procédure de réponse aux incidents pour les chasser du réseau et mettre fin à la violation.
Figure 3 : la segmentation évite les violations de données. À gauche : sans segmentation. À droite : avec segmentation.
Résumé
Dans ce billet de blog, nous avons présenté plusieurs protocoles et programmes courants sur les machines Linux, qui peuvent être exploités par les cybercriminels lorsqu'ils tentent de se déplacer latéralement sur le réseau. Nous avons délibérément choisi de ne pas inclure d'exemples concrets, car nous voulons rester du bon côté de la barrière. Notre souhait est de sensibiliser les utilisateurs à ces protocoles afin de ne pas exposer les réseaux.
En ce qui concerne les mesures d'atténuation et les protections, nous recommandons d'utiliser les versions sécurisées des protocoles abordés dans ce billet (SNMPv3, SFTP au lieu de FTP, etc.). Par ailleurs, dans la mesure du possible, nous conseillons d'utiliser des stratégies de segmentation réseau.
Pour la plupart des protocoles présentés, il existe généralement un petit sous-ensemble de processus client ou serveur, ainsi que des numéros de port ou des plages de ports uniques. Ainsi, en bloquant des ports ou processus spécifiques, il devrait être possible de limiter l'accès réseau au sous-ensemble de serveurs qui l'exige, sans grand impact sur l'exploitation normale du réseau.
