Помните Heartbleed? Shellshock можно отнести к той же «весовой категории», с таким же стильным названием, хоть и без классного логотипа (кому-то из департамента маркетинга этой уязвимости надо бы этим заняться). Но у 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, то получим такой результат:
Проще говоря, Роберт заставил кучу удалённых машин пинговать его, просто отправив в сеть специально сформированный запрос. Беспокойство вызывает тот факт, что он заставил эти машины выполнить произвольную команду (в данном случае безобидный ping), что открывает широчайшие возможности.
Что такое Bash и зачем он нам нужен?
Можете пропустить это раздел, если вы уже в теме. Но если вы не знакомы с Bash, то рекомендую ознакомиться с этим разделом для понимания общей картины. Bash — это командная оболочка (интерпретатор), широко используемая на Linux и Unix-системах, обычно с подключением через SSH или Telnet. Bash также может работать как парсер для CGI-скриптов на веб-сервере, например, на Apache. Свою историю Bash ведёт с 1980-х, где он развился из более ранних реализаций командной оболочки (название происходит от Bourne shell) и невероятно популярен. Конечно, есть и другие интерпретаторы, но Bash идёт по умолчанию в Linux и Mac OS X, которые, как вы понимаете, очень широко распространены. Этот интерпретатор даже признан «одной из наиболее распространённых утилит в Linux-системах». Именно распространённость Bash является главной причиной того, почему Shellshock столь опасен.
Этот график даёт наглядное представление о вездесущности Bash:
Половина интернета работает на Apache (обычно установленный под Linux), и это реально очень, очень много. В той же статье сообщается, что мы уже перешли рубеж в 1 млрд действующих веб-сайтов, а поскольку многие из них расположены на массовых хостингах, то мы имеем дело с огромным количеством установленных копий Bash. И помимо веб-серверов не забудьте ещё и о множестве других серверов и устроиств под управлением Linux. Но вернемся к этому позже.
Bash используется для широкого спектра управленческих задач, от конфигурирования веб-сайтов до управления встроенным ПО в периферийных устройствах, например, веб-камерах. Такие возможности не должны быть открыты всем желающим, и теоретически доступны только авторизованным пользователям, имеющим определённые права доступа. Теоретически.
В чём суть уязвимости?
Степень серьёзности ситуации можно оценить по следующей цитате из базы данных уязвимостей NIST:
GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.
Уязвимости присвоен уровень «10 из 10», то есть хуже некуда. Добавьте к этому лёгкость осуществления атаки (Access Complexity низкий) и, что ещё важнее, отсутствие необходимости аутентификации для использования Bash с помощью CGI-скриптов. Давайте разберёмся в сути самого бага.
Основная опасность заключается в возможности произвольно задать переменные среды внутри интерпретатора Bash, которая задаёт определение функций. Проблемы начинаются в тот момент, когда Bash продолжает обрабатывать команды интерпретатора после определения функции, что позволяет осуществить атаку с внедрением кода. Возьмём лишь одну строку из примера Роберта:
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
Определение функции — это () { :; };, а команда интерпретатора — ping и её параметры. При обработке этой строки интерпретатором Bash, может быть выполнена любая команда. В контексте веба, это можно сделать через такой механизм, как CGI-скрипт и необязательно через заголовок запроса. Больше информации можно найти на страничке seclists.org, еще там установлено, что путь и строка запроса также могут быть потенциальным вектором атаки.
Конечно, ситуацию можно смягчить просто отключив CGI-функционал. Но во многих случаях это окажет слишком серьёзное влияние на ваш веб-сайт и, как минимум, потребует активного тестирования, чтобы удостовериться в его работоспособности.
Приведённый выше HTTP-запрос прост и эффективен, являясь лишь одним из многих возможных использований этого протокола. Если принять во внимание Telnet и SSH, и, очевидно, даже, DHCP, то масштаб проблемы вырастает многократно, несмотря на то, что мы говорим лишь об атаках на веб-серверы. Пока что опасность имеется только после аутентификации в SSH, но в дальнейшем мы обнаружим и другие векторы атаки.
Необходимо помнить, что возможности злоумышленников простираются далеко за пределы пингования конкретных адресов, как в примере Роберта, это лишь небольшой пример самой возможности управления удалёнными машинами. Сейчас вопрос стоит так: какой вред способны нанести злоумышленники, выполняя различные команды в интерпретаторах удалённых машин?
Каковы потенциальные последствия?
Получение доступа к интерпретатору всегда было большой победой для атакующего, потому что это равнозначно получению контроля над сервером (с соотвествующими правами). Доступ ко внутренним данным, перенастройка окружения, распространение зловредов и так далее. Возможности почти безграничны и автоматизируемы. Есть уже очень много примеров эксплойтов, которые могут быть легко применены против большого количества машин.
К сожалению, когда дело доходит до выполнения произвольного кода в командных интерпретаторах половины веб-серверов интернета, возможности крайне велики. Одна из очевидных и наиболее скверных — это получение доступа ко внутренним файлам. Наибольший интерес будут представлять файлы с паролями и конфигурациями, но доступ можно будет получить вообще ко всем файлам.
То же самое относится и к возможности записи файлов на удалённую машину. Это один из самых лёгких способов замены страниц чужом веб-сайте, не говоря уже о распространении вредоносного ПО. Или как вам вот это?
Когда речь заходит о червях, то подразумевается зловредное ПО, которое создаёт собственные копии на системе-жертве. В качестве примера очень эффективного червя можно привести XSS-червя Samy, который инфицировал миллионы веб-страниц менее чем за один день.
Опасность Shellshock ещё и в том, что таким образом может начаться эпидемия заражений, особенно на ранней стадии, пока на большинстве машин не закрыта эта уязвимость. Сами инфицированные машины будут искать новые жертвы и инфицировать их. И опасности сейчас подвержены все публичные машины, а при проникновении за корпоративные файрволы уже нигде не будет спасения. Люди уже эксплуатируют это прямо сейчас. Сейчас в разгаре настоящая гонка вооружений между теми, кто хочет использовать брешь, и теми, кто хочет её закрыть.
Какие версии Bash подвержены уязвимости?Все версии за последние почти 25 лет, включая 4.3. Сравните с Heartbleed, опасности которого были подвержены версии OpenSSL за последние два года. Да, люди обновляют версии, но это не делается планомерно, и как ни крути, Shellshock угрожает гораздо большему количеству машин, чем Heartbleed.
Увы, но уязвимость может сохраниться и в последующих версиях. Уже есть сведения о патчах, которые оказались не слишком эффективны. Так что за этой уязвимостью нужно следить очень внимательно, она не из тех вещей, про которые можно забыть после установки патча.
Когда была обнаружена уязвимость?
Первое найденное мной упоминание было в очень короткой заметке на seclists.org, опубликованной в среду около 14-00 по Гринвичу. Более подробная информация была выложена на том же ресурсе час спустя. Так что это очень «свежая» новость, и пока слишком рано говорить о массовом появлении эксплойтов в «дикой природе». Но это может произойти очень скоро, вероятность увеличивается с каждым часом.
Как упоминалось выше, уязвимость существует во всех версиях Bash, созданных за последние 25 лет. Так что, теоретически, всё это время знающие люди могли её использовать.
Наши девайсы под угрозой?
Вопрос интересный, ведь существует множество приборов, потенциально использующих Bash. Я имею в виду «интернет вещей» (IoT), когда всё более широкое распространение получает присваивание IP-адреса каждой мелочи, от вилки до дверного замка и лампочки. Многие «интернет-вещи» используют встроенные версии Linux с Bash. Те же самые девайсы уже продемонстрировали серьёзные прорехи в безопасности, например, с лампочек LIFX можно получать идентификационные данные по Wi-Fi. Так что уже и без уязвимостей вроде Shellshock мы оказались в ситуации, когда, подключая к сети всевозможные приборы и предметы, мы получаем множество новых уязвимостей в тех сферах, которые ранее были абсолютно безопасны.
Это ставит перед нами множество новых задач. Например, кто-нибудь задумывается о том, чтобы регулярно ставить патчи на лампочки? Учитывая «долговечность» подобных устройств, вряд ли кто-то будет заниматься поддержкой встроенного ПО. Вспомните историю с камерами Trendnet, произошедшую пару лет назад. Несомненно, огромное их количество всё ещё остаётся подключёнными к сети, потому что с точки зрения обновления ПО их гораздо проще поставить и забыть. Есть Твиттер-аккаунт, целиком посвящённый публикации снимков с подобных камер, когда их владельцы даже не знают, что их снимают. Это большая проблема, ведь обновление ПО периферийных устройств зачастую затруднено, так что нас со временем будет окружать всё больше приборов и предметов со всевозможными уязвимостями.
Но интерпретатор Bash также уже присутствует во многих привычных приборах, например, домашних роутерах. Когда вы в последний раз обновляли его прошивку? Конечно, если вы читаете этот текст, то, вероятно, вы из тех, кто регулярно занимается подобными вещами. Но обычные пользователи об этом даже не думают.
У нас всё работает на ПО от Microsoft, нам надо беспокоиться?
Короткий ответ — нет, длинный — да. Несмотря на то, что существуют версии Bash под Windows, для этой экосистемы данная утилита не является сколь-нибудь распространённой. Также неясно, имеют ли уязвимость Shellshock Windows-версии Bash.
Однако тот факт, что вы работаете в исключительно в Windows-среде не означает, что Bash отсутствует на машинах, обслуживающих отдельные задачи вашего окружения. В качестве поясняющей картинки хочу привести иллюстрацию из поста Ника Крэйвера:
Как видите, трафик проходит от вашей Windows-среды через неWindows-устройства. Могут быть компоненты, имеющие привилегии над фаерволом, что можно будет натворить тогда с помощью Shellshock?
Я сисадмин, что я могу сделать?
Во-первых, очень легко можно определить, находитесь ли вы в зоне риска. Есть один очень простой тест, который просто выполняет эту команду в вашем интерпретаторе (позволил себе немного изменить изначальную команду — прим. pkruglov):
env X="() { :;} ; echo busted" bash -c "echo stuff"
У вас выведется «busted», если присутствует уязвимость Shellshock.
Конечно, нужно в первую очередь закрыть дыру. Патч существенно снизит риск выполнения чужого кода в конце Bash-функции. Для ряда Linux-дистрибутивов, например, Red Hat, уже появились инструкции, так что займитесь этим как можно скорее (на самом деле, уже для большинства дистрибутивов вышли патчи — прим. pkruglov).
Уже появились инструкции по обновлению систем обнаружения вторжений (IDS), и их немедленно надо взять на вооружение различным организациям, особенно тем, в которых нужно проводить длительные тестирования перед установкой патчей. Провайдер Qualys предложил свой способ определения атаки, наверняка и многие другие IDS-провайдеры работают над этой проблемой.
Более кардинальные способы включают в себя замену Bash на другой интерпретатор, или блокирование подверженной риску системы. Оба способа могут иметь далеко идущие последствия, их не стоит применять бездумно. Но именно это может стать главной особенностью Shellshock: быстрое принятие трудных решений, которые могут оказать серьёзное влияние на реальный бизнес, ради избегания потенциально куда более значительного ущерба.
Ещё один вопрос встаёт куда более острее: эксплуатировался ли Shellshock уже кем-то ранее? Это сложно определить, если не фиксировались векторы атаки. И часто этого не будет происходить, если атака будет проводиться через HTTP или POST-запрос. На вопрос «были ли мы атакованы через Shellshock» самым частым ответом будет такой: у нас нет доказательств, что мы закрыли эту уязвимость. Это оставляет владельцев веб-сайтов и прочих систем в неприятной неизвестности относительно того, были ли они скомпрометированы.
Я пользователь, что я могу сделать?
Зависит от конкретной ситуации. Если вы пользуетесь Mac OS X, то эта уязвимость будет легко (и, надеемся, быстро) закрыта с помощью стандартного механизма обновлений. Проверить, находитесь ли вы в зоне риска, можно легко с помощью теста:
Это простой тест, хотя я сомневаюсь, что средний пользователь Мас с лёгкостью последует советам и перекомпилирует Bash.
Большее беспокойство вызывают устройства, обновление ПО которых затруднено, например, роутеры. Проблема усугубляется тем, что зачастую роутеры предоставляются в аренду провайдерами и пользователи не имеют доступа к панели управления. Помножьте это на огромное количество моделей. При этом перепрошивка роутера тоже не входит в список привычных дел среднестатистического пользователя.
Вкратце, советы пользователям таковы: устанавливайте обновления системы безопасности, не игнорируйте советы своего провайдера и поставщиков используемого вами оборудования со встроенным ПО. Остерегайтесь писем, запрашивающих информацию или дающих инструкции по запуску ПО, подобные послания часто приходят во время фишинговых атак, эксплуатирующих «модные» пользовательские страхи.
Итог
По всем признакам, мы находимся только в самом начале нашего исследования всех глубин этой уязвимости. Конечно, проведено много параллелей с Heartbleed, и в чём-то нам это даже помогло. На примере Heartbleed мы знаем, что ситуация может ухудшиться очень быстро, а последствия мы будем разгребать ещё очень долгое время.
Но в данном случае всё может быть куда хуже, чем с Heartbleed. Если та уязвимость позволяла получить удалённый доступ к небольшому количеству данных в памяти заражённой машины, то Shellshock даёт возможность внедрить произвольный код, что потенциально гораздо опаснее. В этом плане я соглашусь с Робертом:
