Как проверить, уязвим ли мой сервер к ошибке ShellShock?

80

Как я могу убедиться, что моя установка Bash больше не уязвима для ошибки ShellShock после обновлений?

Джованни Тирлони
источник
Обратите внимание, что в bash все еще не исправлены две другие уязвимости (CVE-2014-7186 и CVE-2014-7187).
Охотник на оленей
Патчи, которые исправляют CVE-2014-7186 и CVE-2014-7187, доступны вскоре после того, как Deer Hunter опубликовал свой комментарий. Если у вас есть исправление, предоставленное дистрибутивом для CVE-2014-7169, у вас может быть достаточно для блокировки 7186/7187, протестируйте свою систему с помощью приведенных ниже команд и посмотрите. Также проверьте наличие обновлений безопасности для вашего дистрибутива.
BeowulfNode42

Ответы:

83

Чтобы проверить уязвимость CVE-2014-6271

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

это не должно отражать слово уязвимым.


Чтобы проверить уязвимость CVE-2014-7169
(предупреждение: если у вас ничего не получится, он создаст или перезапишет файл с именем, /tmp/echoкоторый вы можете удалить после, и необходимо удалить перед повторным тестированием)

cd /tmp; env X='() { (a)=>\' bash -c "echo date"; cat echo

он должен сказать слово дата, а затем пожаловаться с сообщением, как cat: echo: No such file or directory. Если вместо этого он говорит вам, что текущее время и дата, то ваша система уязвима.


Проверить на CVE-2014-7186

bash -c 'true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF' || echo "CVE-2014-7186 vulnerable, redir_stack"

это НЕ должно отражать текст CVE-2014-7186 vulnerable, redir_stack.


Проверить на CVE-2014-7187

(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"

это НЕ должно отражать текст CVE-2014-7187 vulnerable, word_lineno.


Для проверки на CVE-2014-6277. Я не уверен на 100% в этом, так как он, кажется, полагается на частично исправленную систему, к которой у меня больше нет доступа.

env HTTP_COOKIE="() { x() { _; }; x() { _; } <<`perl -e '{print "A"x1000}'`; }" bash -c "echo testing CVE-2014-6277"

Результат прохождения - ТОЛЬКО эхо-ответ testing CVE-2014-6277. Если он запускает Perl или жалуется, что Perl не установлен, это определенно ошибка. Я не уверен ни в каких других характеристиках сбоев, поскольку у меня больше нет исправленных систем.


Для проверки на CVE-2014-6278. Опять же, я не уверен на 100%, если этот тест, так как у меня больше нет исправленных систем.

env HTTP_COOKIE='() { _; } >_[$($())] { echo hi mom; id; }' bash -c "echo testing CVE-2014-6278"

Проход для этого теста состоит в том, что он должен ТОЛЬКО отражать текст testing CVE-2014-6278. Если ваш ответ эхом возвращается в hi momлюбом месте, это определенно провал.

BeowulfNode42
источник
1
Можем ли мы добавить общий тест foo='() { echo not patched; }' bash -c fooк этому? Пока экспорт функций не будет помещен в отдельное пространство имен, мы не перестанем работать с одной ошибкой синтаксического анализатора на следующую.
Billyw
У этого теста есть CVE? У вас есть ссылки, чтобы описать эту проблему? Кроме того, информация такого рода может относиться к одному из других вопросов о шоковом ударе, поскольку этот вопрос о том, как проверить успех или неудачу существующих исправлений.
BeowulfNode42
Это из поста Михала Залевского в блоге о готовящемся выпуске Shellshock CVE ( lcamtuf.blogspot.com/2014/09/… ). Это его предлагаемый тест для CVE-2014-6278, который до сих пор не опубликован. Похоже, я ошибся в общности теста; Я уже сталкивался со случаем, когда тест Залевского прошел, но тест CVE-2014-7187 не удался.
Billyw
А вот полное раскрытие информации о CVE-2014-6277 и CVE-2014-6278, а также команды для их проверки: seclists.org/fulldisclosure/2014/Oct/9
billyw
Одно замечание: даже если версия BASH уязвима, если ее ничто не использует (т. Е. Все учетные записи, используемые демонами, такими как "www" или "cups" или что-либо другое), настроены с BASH в качестве оболочки по умолчанию, и ни одна из Ваши коды вызывают system () или тому подобное, поскольку уязвимая версия может быть менее рискованной, но, тем не менее, обновите BASH как можно скорее.
DTK
32

Экспортируйте специально созданную переменную среды, которая будет автоматически оцениваться уязвимыми версиями Bash:

$ export testbug='() { :;}; echo VULNERABLE'

Теперь выполните простое эхо, чтобы увидеть, будет ли Bash оценивать код в $ testbug, даже если вы не использовали эту переменную самостоятельно:

$ bash -c "echo Hello"
VULNERABLE
Hello

Если он показывает строку «VULNERABLE», ответ очевиден. В противном случае вам не нужно беспокоиться, и ваша исправленная версия Bash в порядке.

Обратите внимание, что в основных дистрибутивах Linux выпущено несколько исправлений, и иногда они не полностью устраняют уязвимость. Продолжайте проверять рекомендации по безопасности и запись CVE для этой ошибки.

Джованни Тирлони
источник
5
В дополнение к CVE-2014-6271, неполное исправление от Red Hat, в частности, имеет свое собственное, заслуживающее внимания: CVE-2014-7169 .
DocMax
3
Один вкладыш, который не загрязняет среду оболочки и работает, даже если вы используете альтернативную оболочку входа (о которой может не знать export):env testbug='() { :;}; echo VULNERABLE' bash -c "echo Hello"
Lloeki
1
Здесь есть некоторые подробности, специфичные для Ubuntu askubuntu.com/questions/528101/… - лично мне пришлось обновить Ubuntu с 13.10 до 14.04, чтобы исправить проблему
dodgy_coder
2

ShellShock - это практически совокупность более чем одной уязвимости bash , и на данный момент существует также вредоносное ПО, использующее эту уязвимость , поэтому ShellShock может быть проблемой, которая все еще остается открытой, существует ветка с обновлениями от RedHat по этой проблеме .

Redhat рекомендует следующее:

Команда Run:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"

Если вывод:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
vulnerable
bash: BASH_FUNC_x(): line 0: syntax error near unexpected token `)'
bash: BASH_FUNC_x(): line 0: `BASH_FUNC_x() () { :;}; echo vulnerable'
bash: error importing function definition for `BASH_FUNC_x'
test

у тебя нет никакого решения.

Если вывод:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
bash: error importing function definition for `BASH_FUNC_x()'
test

у тебя есть CVE-2014-6271починка

Если ваш вывод:

$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `BASH_FUNC_x'
test

ты не уязвим.

Другая часть проверки ShellShock - это проверка уязвимости CVE-2014-7169, которая обеспечивает защиту системы от проблемы создания файла. Чтобы проверить, уязвима ли ваша версия Bash к CVE-2014-7169, выполните следующую команду:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014

Если ваша система уязвима, отобразятся время и дата и будет создан файл / tmp / echo.

Если ваша система не уязвима, вы увидите вывод, похожий на:

$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
date
cat: /tmp/echo: No such file or directory
Эдуард Флоринеску
источник
2

Я написал утилиту CLI под названием ShellShocker для проверки вашего веб-сервера на наличие уязвимостей в CGI-скриптах. Чтобы проверить свой сайт, вы должны запустить:

python shellshocker.py <your-server-address>/<cgi-script-path>

т.е.

python shellshocker.py http://example.com/cgi-bin/possibly-vulnerable-script.cgi

РЕДАКТИРОВАТЬ: эта утилита была снята, извините: '(

Лиам Маршалл
источник
Ваша ссылка мертва
SSK
@SSK Извините;) Mistype.
Лиам Маршалл
Ваша ссылка все еще мертва.
Mxx
Да, извини, я снял его. Его эксплуатировали способами, которые мне не нравились.
Лиам Маршалл
1

Вы можете отправить свой CGI-URL в этот онлайн-тест:

http://shellshock.iecra.org

user245089
источник
4
Вежливо указывать причины отрицательных голосов.
Дэвид
4
"Мы регистрируем все сканы" ??? Жутко. Я бы скачал питон и запустил его сам.
Брэд
1
@Brad, по крайней мере, они говорят вам. Я уверен, что если бы я предоставлял услугу безопасности whitehat, которая предлагала эту услугу, я вполне мог бы вести журнал (если бы только счетчик без индивидуальных данных) того, сколько людей слепо вводили данные своего сайта в веб-сайт, который сказал, что это происходит. провести тест на проникновение, не зная много о подлинности сайта, предлагающего этот тест ... и они хотели бы получить журнал того, кто проверял, что в случае, если кто-то использует их сервис, чтобы найти уязвимые сайты, принадлежащие другим, тоже
Роб Мойр
-1

type env x = '() {:;}; echo уязвимый 'bash -c' echo это тест ”, и если это возвращает уязвимость, и это тест, это означает, что ваша машина OSX / Linux затронута. Помощь заключается в обновлении до последней версии bash.

Hen-Al
источник
6
Почему как root? Совершенно ненужно.
Мат