Помните Heartbleed ? Если вы верите, что шумиха сегодня, Шеллшок находится в той лиге и с таким же удивительным именем, хотя и лишенным классного логотипа (кто-то в отделе маркетинга этих злодеев должен с этим согласиться). Но, если серьезно, у него есть потенциал стать важной персоной, и, как я сделал с 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-адресов приводит к следующему:
Говоря кратко, Роберт только что организовал несколько внешних машин для проверки связи с ним, просто выполнив тщательно разработанный запрос через Интернет. Что действительно беспокоит, так это то, что он эффективно заставил эти машины выдавать произвольную команду (хотя и довольно мягкий пинг), и это открывает целый мир очень серьезных возможностей. Позволь мне объяснить.
Что такое Bash и зачем он нам?
Пропустите это, если это старые новости, но контекст важен для тех, кто не знаком с Bash, поэтому давайте установим базовое понимание. Bash — это оболочка * nix или, другими словами, интерпретатор, который позволяет вам управлять командами в системах Unix и Linux, как правило, путем подключения через SSH или Telnet. Он также может работать как синтаксический анализатор для CGI-скриптов на веб-сервере, который мы обычно видим на Apache. Он существует примерно с конца 80-х годов, когда он эволюционировал от более ранних реализаций оболочки (название происходит от оболочки Bourne ) и является чрезвычайнопопулярный. Существуют и другие оболочки для вариантов Unix, но в Bash главное — это оболочка по умолчанию для Linux и Mac OS X, которые, очевидно, являются чрезвычайно распространенными операционными системами. Это главный фактор того, почему этот риск так важен — повсеместное распространение Bash — и его называют «одной из самых установленных утилит в любой системе Linux».
Вы можете почувствовать присутствие Bash, посмотрев последние статистические данные веб-сервера Netcraft :
Когда половина сети работает на Apache (который обычно находится в Linux), это значительный размер очень, очень большого пирога. В той же статье о Netcraft сообщается, что мы только что прошли отметку в один миллиард веб-сайтов, и хотя куча из них используют одни и те же хосты, это все еще большая часть установок Bash. О — это тоже веб-серверы, не забывайте, что есть куча других серверов под управлением Linux, и мы вернемся к другим устройствам с Bash чуть позже.
Bash может использоваться для целого ряда типичных административных функций, от настройки веб-сайтов до управления встроенным программным обеспечением на устройстве, таком как веб-камера. Естественно, это не та функциональность, которая предназначена для того, чтобы быть открытой для всего мира, и теоретически мы говорим о проверенных пользователях, выполняющих команды, которые им разрешено запускать. Теоретически.
В чем ошибка?
Позвольте мне начать с CVE из базы данных уязвимостей NIST, поскольку она дает хорошее представление о серьезности (выделите мою):
GNU Bash через 4.3 обрабатывает конечные строки после определений функций в значениях переменных среды, что позволяет удаленным злоумышленникам выполнять произвольный код через специально созданную среду, что продемонстрировано векторами, использующими функцию ForceCommand в sshd OpenSSH, модулях mod_cgi и mod_cgid в Apache HTTP-сервер, сценарии, выполняемые неуказанными клиентами DHCP, и другие ситуации, в которых настройка среды происходит через границу привилегий от выполнения Bash.
Они продолжают оценивать его как «10 из 10» за серьезность или, другими словами, настолько плохо, насколько это возможно. Это усугубляется тем фактом, что атаку легко выполнить (сложность доступа низкая) и, что наиболее важно, при использовании 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 после авторизации , но на таком раннем этапе публичного раскрытия мы неизбежно увидим, что другие векторы атак пока не появляются.)
Также нужно помнить, что область потенциального ущерба простирается далеко за пределы проверки произвольного адреса, как в примере с Робертом, это просто аккуратное доказательство того, что он может организовать машину для выдачи команды оболочки. Возникает вопрос: какой урон может нанести злоумышленник, если сможет выполнить команду оболочки по своему выбору на любой уязвимой машине?
Каковы возможные последствия?
Потенциал огромен — «получение оболочки» на коробке всегда было главной победой для атакующего из-за контроля, который он предлагает им над целевой средой. Доступ к внутренним данным, реконфигурация сред, публикация собственного вредоносного кода и т. Д. Он практически безграничен и также легко автоматизируется. Уже есть много, много примеров эксплойтов , которые могут быть легко запущены против большого количества машин.
К сожалению, когда дело доходит до выполнения произвольного кода в оболочке почти на половине веб-сайтов в Интернете, потенциал довольно широк. Одним из очевидных (и особенно неприятных) является сброс внутренних файлов для публичного поиска . Файлы паролей и файлы конфигурации с учетными данными являются очевидными, но они могут распространяться на любые другие файлы в системе.
Аналогичным образом, тот же подход может быть применен для записи файлов в систему. Это потенциально самый простой вектор порчи веб-сайтов, который мы когда-либо видели, не говоря уже об очень простом способе распространения вредоносных программ.
Или как об этом: одно слово, которое я часто вижу, — «червь»:
Когда мы говорим о черве в контексте вредоносных вычислений, мы говорим о самовоспроизводящейся атаке, когда злоумышленник создает код, способный распространяться по целевым объектам. Например, мы увидели очень эффективную реализацию этого с MySpace XSS Worm от Samy, где некоторый тщательно продуманный JavaScript смог «заразить» страницы миллионов жертв менее чем за день.
Беспокойство в связи с Shellshock заключается в том, что атака такого типа может повторяться с угрожающей скоростью, особенно на ранних этапах, когда большинство машин остаются в опасности. Теоретически это может принять форму зараженной машины, сканирующей другие цели и распространяющей атаку на них. Это ни в коем случае не ограничивается общедоступными машинами; Получите это за корпоративным брандмауэром и небо это предел.
Люди сейчас работают над этим. Это то, что делает эти первые дни настолько интересными, что гонка вооружений между теми, кто борется за патчи, и теми, кто борется за атаку, нагревается.
Какие версии Bash затронуты?
В заголовках все говорится в 4.3 или, другими словами, в версиях Bash на 25 лет. Учитывая, что все продолжают сравнивать это с Heartbleed, учтите, что затронутые версии OpenSSL охватили всего два года, что является каплей в океане по сравнению с Shellshock. Да, люди обновляют свои версии, но нет, они не делают это последовательно и в зависимости от того, как вы их сокращаете, широта подверженных риску машин будет значительно выше с Shellshock, чем с Heartbleed.
Но риск также может выходить за рамки 4,3. Уже сейчас мы видим сообщения о том, что патчи были не совсем эффективными, и учитывая скорость, с которой они выпускаются, это не так уж удивительно. Это та вещь, на которую воздействуют люди, которые хотят следить очень внимательно, а не просто «залатать и забыть».
Когда мы впервые узнали об этом и как долго мы подвергались риску?
Первое упоминание, которое я нашел в эфире, было это очень краткое резюме на seclists.org, которое работает примерно в 18:00 по Гринвичу в среду (сегодня около 2:00 для тех из нас, кто живет в восточной части Австралии). Подробная информация появилась в рекомендации, о которой я упоминал ранее часом позже, поэтому ближе к полудню среды в Европе или к середине дня в США. Это все еще очень свежие новости со всеми обычными спекуляциями в прессе и прогнозами Chicken Little ; слишком рано наблюдать какую-либо широко распространенную эксплуатацию в дикой природе, но это также может произойти очень скоро, если риск оправдает свой потенциал.
Перейдите к тому, что было открыто, и, по-видимому, ошибка была обнаружена на прошлой неделе Стефаном Шазеласом , специалистом по Unix / Linux, сетям и телекоммуникациям в Великобритании. Сказав это, в сообщении Акамаи об ошибке они говорят, что она присутствовала «в течение длительного периода времени», и, конечно, уязвимые версии Bash уходят в прошлое на два с половиной десятилетия. Вопрос, как и в случае с Heartbleed, будет состоять в том, знали ли злоумышленники об этом раньше и действительно ли они активно его использовали.
Наши «вещи» затронуты?
Вот где это становится интересным — у нас есть много «вещей», потенциально работающих под управлением Bash. Конечно, когда я использую этот термин, я имею в виду «Интернет вещей» (IoT), который представляет собой растущую распространенность взлома IP-адреса и беспроводного адаптера во всем, от наших столовых приборов до дверных замков и наших светлых шаров .
Многие устройства IoT используют встроенные дистрибутивы Linux с Bash. Эти самые устройства уже продемонстрировали серьезную уязвимость безопасности в других областях, например, светлые глобусы LIFX всего пару месяцев назад обнаружили утечку учетных данных Wi-Fi . Хотя это и не уязвимость Bash, такая как Shellshock, она показывает нам, что, соединяя наши вещи, мы попадаем в совершенно новый мир уязвимостей в местах, которые никогда ранее не подвергались риску.
Это приносит много новых проблем; например, кто активно думает, что они должны регулярно исправлять свои лампочки? Также рассмотрите долговечность устройств, в которых это программное обеспечение появляется, и действительно ли они активно поддерживаются. В случае с уязвимыми камерами Trendnet, появившимися пару лет назад, несомненно, их огромное количество все еще находится в сети, потому что с точки зрения исправления они в значительной степени являются предложением «установи и забудь». На самом деле в этом случае есть целая учетная запись Twitter, посвященная трансляции изображений, снятых не подозревающими владельцами уязвимых версий. Это большая проблема без простых исправлений, и она останется с нами в течение очень долгого времени.
Но оболочки Bash также присутствуют во многих более распространенных устройствах, например, в наших домашних маршрутизаторах, которые обычно подключены к Интернету. Помните, когда вы в последний раз исправляли прошивку на своем роутере? Хорошо, если вы читаете это, то, возможно, вы из тех, кто действительно исправляет свой роутер, но поставьте себя на место обычного потребителя Джо и спросите себя снова. Точно.
Все наши вещи находятся в стеке Microsoft, мы в опасности?
Короткий ответ «нет», длинный ответ «да». Сначала я расскажу о простом: Bash изначально не обнаруживается в Windows, и, хотя есть реализации Bash для Windows , он, конечно, не распространен и не будет найден на потребительских ПК. Также не ясно, действительно ли такие продукты, как win-bash, на самом деле уязвимы для Shellshock.
Более длинный ответ заключается в том, что если вы работаете в среде, ориентированной преимущественно на Microsoft, Bash не работает на машинах, обслуживающих другие дискретные цели в этой среде. Когда я писал о Heartbleed , я ссылался на пост Ника Крейвера о перемещении переполнения стека в сторону SSL и ссылался на диаграмму их инфраструктуры:
Есть компоненты, не принадлежащие Microsoft, которые находятся перед их стеком приложений Microsoft, компоненты, через которые должен пройти трафик, прежде чем он попадет на веб-серверы. Это также компоненты, которые могут иметь повышенные привилегии за брандмауэром — как это повлияет на использование Shellshock? Это может быть важно, и это то, что я хочу сказать здесь; Shellshock обладает потенциалом влиять на активы, выходящие за рамки рискованных реализаций Bash, когда они существуют в более широкой экосистеме других машин.
Я системный администратор — что я могу сделать?
Во-первых, выяснить, подвержены ли вы риску, тривиально, поскольку это такой легко воспроизводимый риск. Есть очень простой тест, который предлагает Register, который просто запускает эту команду в вашей оболочке:
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"
Вы попадаете в тупик, и вы успешно использовали ошибку.
Конечно, приоритетом здесь будет исправление в системах риска, и исправление сводится к тому, чтобы после завершения функции Bash код не мог быть выполнен. Linux дистрибутивы, такие как Red Hat, выпускают руководство по исправлению рисков, поэтому используйте их в приоритетном порядке.
Мы также неизбежно увидим определения для систем обнаружения вторжений, и, безусловно, здесь будут общие шаблоны для поиска. Это вполне может оказаться хорошим немедленным внедрением для многих организаций, особенно там, где могут возникнуть обременительные требования к тестированию перед развертыванием исправлений для систем, подверженных риску. Qualys ‘стремятся иметь определение для быстрого обнаружения атаки, и неизбежно другие поставщики IDS также работают над этим круглосуточно.
Другие более радикальные варианты включают замену Bash на альтернативную реализацию оболочки или отключение систем, подверженных риску, которые могут иметь далеко идущие последствия и вряд ли будут приниматься без должного решения. Но это, вероятно, будет характерной чертой этой ошибки для многих людей — трудные решения, которые могут оказать ощутимое влияние на бизнес, чтобы избежать потенциально гораздо более значительных последствий .
Другая проблема, которая сейчас начнет подниматься, — это вопрос о том, эксплуатировался ли уже Shellshock в среде. Это может быть трудно определить, нет ли регистрации векторов атаки (часто не будет, если она передается заголовком HTTP-запроса или телом POST), но с большей вероятностью это будет обнаружено, чем с Heartbleed, когда не хватает полного на pcaps, полезные нагрузки сердцебиения обычно не регистрируются нигде. Но, тем не менее, наиболее распространенным ответом на «если мы атаковали через Шеллшок» будет такой :
к сожалению, это не «Нет, у нас есть доказательства того, что не было никаких компромиссов»; скорее, «у нас нет доказательств, охватывающих всю жизнь этой уязвимости». Мы сомневаемся, что многие люди это делают — и это оставляет владельцев системы в неудобном положении, когда они не знают, какие компромиссы могли случиться, если они вообще были.
Пусть начнутся спекуляции о том, был ли АНБ в этом деле …
Я потребитель — что я могу сделать?
Это зависит. Shellshock влияет на Mac, поэтому, если вы работаете с OS X, на данном этапе это, по-видимому, находится под угрозой, что, с одной стороны, плохо из-за распространенности OS X, но с другой стороны, будет легко (и, надеюсь, быстро) исправлено из-за довольно хорошо зарекомендовавший себя механизм обновления (т.е. Apple может удаленно загружать обновления на компьютер).
Если вы работаете на Mac, риск легко проверяется, как описано в ответе на Stack Exchange :
Это простой тест, хотя я сомневаюсь, что среднестатистический пользователь Mac будет чувствовать себя комфортно, выполняя предложенное исправление, которое включает в себя перекомпиляцию Bash.
Больше беспокойства вызывают устройства без лёгкого пути исправления, например, ваш роутер. Если не заглядывать на сайт производителя для получения обновленной прошивки, это будет действительно крепкий орешек. Часто маршрутизаторы, предоставляемые интернет-провайдерами, блокируются, так что потребители не изменяют случайно ни конфигурацию, ни микропрограмму, и не всегда можно запустить удаленный путь обновления. Объедините это с огромным множеством устройств и возрастов, которые там есть, и это может быть особенно сложно. Конечно, это также не то, что вашему среднему потребителю будет удобно делать самим.
Короче говоря, совет для потребителей заключается в следующем: следите за обновлениями безопасности, особенно в OS X. Также следите за любыми советами, которые вы можете получить от своего интернет-провайдера или других поставщиков устройств, на которых вы используете встроенное программное обеспечение. Будьте осторожны с электронными письмами, запрашивающими информацию или инструктирующими вас запускать программное обеспечение — за подобными событиями часто следуют фишинговые атаки, использующие страхи потребителей. В настоящее время у обманщиков есть люди, которые кладут свои айфоны в микроволновку, поэтому ни на минуту не думайте, что они не запустят случайную часть программного обеспечения, отправленную им по электронной почте, в качестве «исправления» для Shellshock!
Резюме
По всей вероятности, мы даже не начали понимать масштабы этой уязвимости. Конечно, с Heartbleed проводится множество сравнений, и мы многому научились из этого упражнения. Один из них заключается в том, что потребовалось немного времени, чтобы понять, насколько мы зависели от OpenSSL. Другое дело, что у него был очень длинный хвост — спустя месяцы после его попадания сотни тысяч известных хостов остались уязвимыми .
Но, с одной стороны, сравнение Heartbleed несправедливо — это потенциально намного хуже. Heartbleed разрешил удаленный доступ к небольшому количеству данных в памяти затронутых машин. Shellshock делает возможным удаленное внедрение кода произвольных команд перед аутентификацией, что потенциально намного более ужасно. В связи с этим я должен согласиться с Робертом:
Это очень, очень ранние дни — только полдня с момента его появления в эфире на момент написания статьи — и я подозреваю, что пока мы только царапаем поверхность того, что еще впереди.