Все, что необходимо знать об уязвимости Shellshock

Автор: Troy Hunt

Помните историю с Heartbleed? (уязвимость в OpenSSL). Если вы почитываете желтую прессу, то история с Shellshock в чем-то напоминает тот случай. Такое же запоминающееся имя, хотя без крутого логотипа (маркетологам следует обратить на это внимание). А теперь о серьезном. Эта уязвимость может привести к более серьезным и масштабным последствиям. Как и в случае с Heartbleed, в этой статье я постараюсь собрать воедино всю информацию и отделить слухи и домыслы от реального риска, связанного с данной уязвимостью.

Для начала приведу некоторые выдержки из статьи Роберта Грехема, который провел прекрасный анализ этой проблемы. Представим себе такой HTTP-запрос:

target = 0.0.0.0/0
port = 80
banners = true
http-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
http-header = Host:() { :; }; ping -c 3 209.126.230.74
http-header = Referer:() { :; }; ping -c 3 209.126.230.74

При «применении» этого запроса против уязвимых IP-адресов получаем следующие результаты:

Рисунок 1: Массовый пинг со стороны нескольких внешних машин

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

Что такое Bash, и зачем он нужен?

Если вы уже знаете, что такое Bash, можете не читать этот раздел. Я буду вещать для тех, кто не знаком с этим вопросом. Bash – командная оболочка в системах *nix или другими словами – интерпретатор, позволяющий выполнять различные команды, обычно после подключения к машине через SSH или Telnet. Bash также может выполнять роль парсера CGI-скриптов на веб-сервере, что мы обычно наблюдаем на запущенном Apache. Интерпретатор Bash зародился в конце 80-х годов (имя унаследовалось от Bourne shell) и приобрел огромную популярность. Существует и другие командные оболочки, но Bash по умолчанию используется в операционных системах Linux и Mac OS X, которые чрезвычайно распространены. Именно из-за этого фактора («повсеместность» Bash или как еще говорят – «наиболее часто устанавливаемая утилита в Linux») проблемы, связанные с уязвимостью в этой оболочке, потенциально могут быть весьма серьезными.

Представление о масштабах использования Bash можно получить из последних данных Netcraft о процентном соотношении веб-серверов в интернете:

Рисунок 2: Динамика процентного соотношения веб-серверов в интернете

Когда на половине всех серверов установлен Apache (который обычно используется в Linux), то можно примерно представить количество систем, где установлен Bash (огромный кусок пирога). В этой же статье Netcraft сообщает, что недавно пройдена отметка в миллиард веб-сайтов, многие из которых разделяют те же самые хосты. Даже несмотря на это, количество систем, где установлен Bash, огромно. Ах, да, ведь до этого речь шла только о веб-серверах. Не забывайте, что есть и другие Linux-системы, и мы также коснемся их чуть позже.

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

В чем суть уязвимости?

Изучение вопроса начнем с описания уязвимости, что даст хорошее представление об уровне угрозы.

GNU Bash (включительно до версии 4.3) обрабатывает присоединенные строки (trailing strings) после объявлений функций внутри переменных окружения, что позволяет злоумышленнику удаленно выполнять произвольный код через специально сконструированную переменную. Уязвимость была продемонстрирована при использовании ForceCommand в OpenSSH sshd, mod_cgi/mod_cgid модулей веб-сервера Apache, при запуске скриптов произвольными DHCP-клиентами и других ситуациях, когда происходила установка переменных окружения из Bash (в обход прав доступа).

Уязвимости был присвоен самый высокий уровень опасности (10 из 10), то есть хуже некуда. Кроме того, этот факт отягощается легкостью выполнения атаки (уровень сложности самый низкий) и, что самое важное, отсутствием необходимости аутентификации при эксплуатации Bash через CGI-скрипты. Описание, приведенное выше, немного запутанно, так что давайте по подробнее разберемся с технической стороной вопроса.

Основная угроза заключается в возможности произвольной установки переменных окружения внутри интерпретатора, в которых объявляются функции. Проблема возникает тогда, когда Bash продолжает обрабатывать команды после объявления функции, в результате чего мы наблюдаем атаку, связанную с внедрением кода. Давайте еще раз взглянем на следующую строку из примера Роберта:

http-header = Cookie:() { :; }; ping -c 3 209.126.230.74

Объявление функции - () { :; };, после чего идет команда ping с соответствующими параметрами. При обработке этой строки внутри Bash выполняется произвольная команда. В контексте веба это означало бы использование, например, CGI-скриптов, когда необязательно прописывать команду в заголовке запроса. Более подробно можно ознакомиться с seclists.org advisory, где детально рассмотрен этот вопрос и заявляется о том, что переменные path и query string могут использоваться злоумышленниками.

Самый простой способ предотвратить угрозу – запретить использование интерпретатора команд через CGI. Некоторые рекомендуют это сделать. Хотя после подобных изменений следует тщательно протестировать функциональность веб-сайта, поскольку могут возникнуть проблемы. И часто такие проблемы возникают.

Пример с HTTP-запросом, упомянутый выше, - прост и эффективен, однако реализация подобной схемы не ограничивается только одним протоколом. Этот метод можно применить и при использовании Telnet, SSH и, очевидно, DHCP, а область действия потенциальной угрозы значительно увеличивается, не ограничиваясь лишь веб-серверами (вероятно, риск присутствует только в SSH post-auth, однако на такой ранней стадии появления описания угрозы, мы неизбежно видим другие потенциальные направления атак).

Все, о чем нужно помнить, - потенциальная сфера применения уязвимости выходит далеко за рамки простого пинга из примера Роберта (который, очевидно, был продемонстрирован лишь с целью демонстрации проблемы). Главный вопрос – какой ущерб могут нанести злоумышленники, если у них будет возможность запускать любые команды на уязвимой машине?

Потенциальные последствия от угрозы

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

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

Кроме того, при помощи тех же самых методов, можно не только скачивать, но и перезаписывать файлы, что позволяет не только взламывать сайты, но и распространять вредоносные программы.

После появления информации об этой уязвимости, я часто слышу слово «червь»:

Перевод с рисунка: «Я на конференции Virus Bulletin 2014 и принимаю ставки на то, как скоро появится червь, эксплуатирующий уязвимость Shellshock»

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

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

Люди уже работают над эксплуатацией этой уязвимости. Ближайшее время будет интересно понаблюдать за баталиями между теми, кто пишет патчи и теми, кто пытается атаковать уязвимые системы.

Какие версии Bash подвержены угрозе?

Заявляется, что угрозе подвержены все версии вплоть до 4.3 (то есть все версии, вышедшие за последние 25 лет). Многие продолжают сравнивать HeartBleed и Shellshock. Однако в случае с HeartBleed были затронуты версии OpenSSL, вышедшие за последние два года, что является каплей в море по сравнению с Shellshock. Даже несмотря на то, что в системах обновляется программное обеспечение, делается это не столь последовательно, и количество уязвимых машин будет значительно выше.

Кроме того, новые версии также могут быть подвержены риску. Мы уже наблюдаем за отчетами о патчах, которые не столь эффективны. Это неудивительно, учитывая скорость появления новых патчей. При обновлении системы следует «держать ухо востро», а не просто «пропатчить и забыть».

Когда появилась информация об уязвимости?

Впервые короткое упоминание об этой уязвимости появилось 24 сентября в 14:00 (по GMT). Через час в бюллетене, о котором я упоминал ранее, появилась детальная информация. Новость все еще остается популярной и сопровождается стандартными спекуляциями в прессе. Слишком рано говорить о масштабах распространения в «дикой природе», но, полагаю, очень скоро мы об этом узнаем, если хотя бы небольшая часть потенциала этой уязвимости будет реализована.

Просматривая более раннюю информацию о публично раскрытых уязвимостях, весьма вероятно, что брешь была обнаружена на прошлой неделе Стефаном Чазеласом, специалистом по Unix/Linux, сетям и телекоммуникациям из Великобритании. С другой стороны, в блоге компании Akamai говорится о существовании уязвимости «в течение продолжительного времени» и, конечно, о том, что брешь присутствует во всех версиях Bash, выпущенных за последние 25 лет. Главный вопрос (как и в случае с Heartbleed) - владели ли этой информацией злоумышленники, и эксплуатировалась ли данная уязвимость до настоящего момента.

Подвержены ли наши «штучки» этой угрозе?

С этого момента все становится еще интереснее. У нас есть множество «штучек», где установлен Bash. Под «штучками» я подразумеваю интернет вещи (Internet of Things, IoT), которые являются следствием повального желания «еще куда-нибудь» прицепить IP-адрес и воткнуть беспроводной адаптер, начиная от столовых приборов и заканчивая дверными замками и лампами накаливания.

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

В связи с этим появляется много новых проблем. К примеру, кто размышляет о том, что нужно регулярно обновлять программное обеспечение у ламп накаливания? Также учитывайте долгий срок службы подобных устройств. В качестве примера можно привести случай с уязвимыми камерами компании Trendnet. Несомненно, до сих пор в интернете можно найти огромное количество уязвимых устройств, которые в основном относятся к категории «установил и забыл». Есть даже специальный канал в Twitter, где публикуются снимки с камер, хозяева которых даже не подозревают о том, что их устройства уязвимы. Главная проблема в том, что обновить программное обеспечение на подобных устройствах не так-то просто, и это будет продолжаться еще долгое время.

Интерпретатор Bash присутствует и в более «традиционных» устройствах, например, в домашних роутерах, которые, как правило, подключены к интернету. Помните ли вы, когда в последний раз обновляли прошивку у вашего роутера? Если вы читаете эту статьи и технически подкованы, то, возможно, эта проблема к вам не относится. Однако поставьте себя на место среднестатистического покупателя, и задайте этот вопрос сами себе снова.

Подвержены ли риску те, кто пользуется софтом от компании Microsoft?

И «да» и «нет». В основном Bash в Windows-системах, но существует реализация этого интерпретатора под Windows. Однако используется он не особо часто, и тем более вряд ли его можно найти на компьютере рядового пользователя. Кроме того, пока не понятно, уязвим ли win-bash.

С другой стороны, если вы используете только программное обеспечение от Microsoft, это не означает, что Bash не запущен на других машинах, предназначенных для строго определенных задач внутри вашей рабочей среды. Когда я писал о Heartbleed, то ссылался на пост Ника Кравера, где он рассказывал о переходе сайта Stack Over на протокол SSL. Вот диаграмма из той статьи:

Рисунок 3: Новая инфраструктура сервиса, заточенная под работу через SSL

Как видно из рисунка выше, в новой инфраструктуре присутствуют компоненты с программным обеспечением не от компании Microsoft. Вначале трафик должен пройти через эту цепь прежде, чем он доберется до веб-серверов. Также здесь присутствуют компоненты, которые могут иметь повышенные привилегии. И нетрудно спрогнозировать, что произойдет, если в тех компонентах присутствует уязвимость Shellshock. Все это я веду к тому, что потенциально могут быть подвержены риску системы, на которых не установлен Bash.

Рекомендации системным администраторам

Во-первых, проведите простейший тест (рекомендуемый The Register), запустив следующую команду в вашей оболочке:

env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"

Если после запуска команды появилось слово «busted», значит, ваша система уязвима. Естественно, нужно пропатчить систему, что после объявления функции код не запускался. К дистрибутиву RedHad уже выпущено руководство по исправлению уязвимости.

В системах обнаружения сетевых атак также появятся средства по обнаружению подобного рода атак. Для многих организаций это может стать хорошим решением, особенно там, где предъявляются строгие требования к тестированию систем, подверженных риску, перед установкой патчей. В компании Qualys уже работают над созданием решения по обнаружению атаки. Другие поставщики систем IDS также занимаются подобными разработками.

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

Другая проблема, в связи с которой возникает много вопросов, - эксплуатировалась ли уже уязвимость Shellshock. Если атака осуществима без авторизации (часто такое можно осуществить через HTTP-заголовок или тело POST-запроса). Но обнаружить подобные атаки намного проще, чем в случае с Heartbleed, когда отсутствуют достоверная информация о пакетах. Полезные нагрузки, используемые через уязвимость Heartbleed, обычно не авторизуются куда-либо. К сожалению, наиболее распространенный ответ на вопрос об эксплуатации Shellshock не будет таким «У нас есть доказательства, что системы не были скомпрометированы», а скорее таким «У нас нет доказательств, касающихся срока службы этой уязвимости». Мы сомневаемся, что это происходило часто, что оставляет владельцев с неприятной мыслью и непониманием того, какого рода компрометирование системы могло произойти (если оно вообще происходило).

Полагаю, что скоро начнутся спекуляции на тему того, стоит ли АНБ за этой уязвимостью или нет.

Рекомендации владельцам компьютеров

Все зависит от различных обстоятельств. Уязвимость присутствует OS X. С другой стороны, в этой ОС хорошо налажена система автоматических обновлений и будем надеяться, что компания Apple быстро выпустить обновление.

Если у вас Mac, можно протестировать уязвимость следующим способом (взято на Stack Exchange):

Рисунок 4: Тестирование Mac’а на присутствие уязвимости Shallshock

Довольно простой тест, однако я сомневаюсь, что рядовой пользователь Mac’а сможет исправить эту проблему при помощи рекомпиляции Bash.

Большее беспокойство доставляют устройства, где непросто обновить программное обеспечение (например, роутер). Если отсутствует проверка новых версий на сайте производителя, задача по обновлению становится еще более сложной. Обычно роутеры, предоставляемые провайдером, заблокированы, чтобы пользователь не мог случайно изменить конфигурацию или прошивку, а возможность удаленного обновления есть не всегда. Кроме того, ситуация осложняется большим разнообразием устройств. Короче говоря, рядовому пользователю будет довольно сложно самостоятельно решить эту задачу.

Если коротко, пользователям можно посоветовать следующее: следите за обновлениями, особенно для OS X. Следите за новостями от провайдера и производителей устройств. Будьте осторожны с письмами с просьбой предоставить информацию или советами о необходимости запуска программного обеспечения. Обычно по такой схеме реализуются фишинговые атаки, которые основываются на страхах пользователей. Если людей обманом заставляют положить iPhone в микроволновку, то я ни на секунду не сомневаюсь, что пользователей запустит «заплатку» для Shellshock.

Заключение

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

Но с другой стороны сравнение не совсем правильное, поскольку потенциально уязвимость Shallshock может привести к худшим последствиям. Heartbleed позволял получить удаленный доступ к небольшому участку памяти. Shallshock позволяет удаленно выполнять произвольный код без аутентификации, что намного опаснее. Здесь я согласен с Робертом:

Перевод с рисунка: «Дыра в bash намного серьезнее, чем Heartbleed»

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