УДАЛЕННОЕ ИСПОЛНЕНИЕ КОДА (RCE) ДЛЯ STRUTS2

Решение: Struts2 — это знаменитый очень мощный Java-фреймворк. Он очень распространен и используется во многих крупных веб-порталах, а также во многих крупных приложениях (как часть веб-админок).

Так вот, этим летом там нашли конкретную багу — возможность проводить OGNL-инъекции, которая, в свою очередь, приводила к тому, что можно было выполнять произвольный Java-код, то есть RCE. Я надеюсь, суть ее уже кто-то описывал в предыдущих номерах, например в рубрике «Обзор эксплойтов», так что опущу этот момент.

WARNING

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

Бага действительно была конкретная, так как уязвимы были все версии Struts2, а обновлялись все небыстро. Это привело к массовым атакам на различные порталы. Под нее вроде бы даже червя сделали. Но к тому времени, когда ты будешь читать эту статью, думаю, все поуляжется :).

На самом деле тема с Java-фреймворками и со всякими специфическими инъекциями еще совсем-совсем не исчерпала себя. В том же Struts2 за последние пару-тройку лет ежегодно находили различные баги, приводящие к RCE. Меня эта тема тоже интересовала, и, покопав немного, я наткнулся на достаточно старую «багу».

Кавычки здесь потому, что баги на самом деле нет. А есть фича (ох как я это люблю) Struts2 — возможность запуска сервлета в Development mode. Это такой специальный девелоперский режим, который может помочь в отладке приложения. Насколько я знаю, когда он включен, разработчику отображаются ошибки приложения через сам портал (а не только пишутся в лог), а при обработке каждого запроса оно каждый раз подгружает разнообразные конфиги, что позволяет настраивать его без повторного деплоя. Как видишь, выглядит вполне удобно, и потому многие им пользуются (хотя по умолчанию он отключен).

Так вот. Самая интересная, с нашей точки зрения, возможность — напрямую и в любом месте передавать OGNL-выражения через параметры запроса! Да-да.

Мы можем передать параметр debug с одним из трех значений:

  • xml — вывод большого количества информации про сервлет и его окружение;
  • console — открытие окошка, через которое можно будет вводить OGNL-выражения (такой веб-дебаггер);
  • command — с этим значением из консоли на сервер передаются OGNL-выражения, которые фактически передаются в дополнительном параметре — expression.

Например:

http://127.0.0.1:8080/struts2-mailreader/Registration_input.do?debug=command&expression=ognl_expression

Таким образом, мы видим, что developer mode дает нам возможность выполнить и произвольный код, так как напрямую обрабатывает OGNL-выражения от пользователя :).

Хотелось бы еще отметить, что в Struts2 все-таки пытаются бороться с возможностью через OGNL выполнять произвольный Java-код. Не буду углубляться в подробности, но это происходит совсем не успешно, так сказать. Так что вот тебе пара «магических строк», которые позволят выполнить команду на самой последней версии Struts2 (2.3.15.1):

  1. #_memberAccess=new com.opensymphony.xwork2.ognl.SecurityMemberAccess(true), @java.lang.Runtime@getRuntime().exec('calc')
  2. new java.lang.ProcessBuilder(new java.lang.String[]{'calc'}).start()

Хотя в документации и написано, что development mode стоит всегда отключать при выводе продукта в продакшн из-за падения производительности, но многие этим пренебрегают (см. следующую задачу). Так что мы можем пользоваться этим при проведении пентестов.

Еще одну интересную особенность я выискал, когда тестил багу локально. У Struts2 есть ряд сервлетов-примеров. Так вот, в одном из них по умолчанию включен development mode. Какой конкретно, варьируется в зависимости от версии: либо mailreader, либо blank.

Struts2 development mode = RCE
Struts2 development mode = RCE
 

АВТОМАТИЗИРОВАТЬ ГУГЛОХАКИНГ

Решение: Мы уже не раз касались прекрасных возможностей гугла (и аналогичных поисковиков) для поиска всяких разных интересных штук. Нельзя, конечно, здесь не вспомнить и про прекрасный ресурс Google hacking database (GHDB). Много различных гуглодорков описывают параметры, с помощью которых можно искать уязвимые приложения, критичную информацию. Гугл позволяет найти тысячи и тысячи хостов с большими дырами.

Например, предыдущая задачка. Пишем простой гуглодорк «intitle:"Struts Problem Report"» и получаем «158,000 results». Конечно, гугл здесь хвастается и по факту отдельных хостов около 400, но все равное это не меняет дела — мы можем почти на 100% быть уверены, что там есть RCE, так как включен development mode.

Теперь давай посмотрим с другой стороны. Вот проводим мы пентест какого-то ресурса. Погуглодоркать нужно? Нужно. И собрать информацию нужно. Но делать это через браузер — совсем не наш метод. Нам нужна автоматизация процесса.

Варианта здесь, на самом деле, два. Первый — использовать тулзу, которая эмулировала бы пользовательские запросы в гугл и парсила бы ответы. Минус здесь в том, что гугл не любит ботов и блочит их (капчу надо вводить). Но, используя большое количество прокси или отвечая на капчу «китайским методом» (то есть вручную), мы можем слить инфу с гугла. Второй — воспользоваться API гугла. Есть у него такая фича — Custom Search Engine, к которой можно получить доступ через специальное API. Здесь как раз автоматически можно получать инфу без проблем (капчи). Но есть другое ограничение — разрешено делать не более 100 запросов в день. Больше — платно (1000 запросов — 5 долларов, для примера). И вроде бы больше 100 ответов не получить. В зависимости от типа задачи (глубина или покрытие) можно выбрать один из вариантов соответственно.

Но для пентестерских задач могу порекомендовать такую тулзу, как SearchDiggity. Я уже частично ее описывал, в контексте поиска багов во флеше. Здесь же мы коснемся других ее возможностей — гуглохакинга.

Она проста в использовании, написана на C# и работает только под win, может работать как напрямую с гуглом, так и через API. В ней нативно представлена большая база различных гуглодорков (оооочень большая), а также имеется удобная возможность сортировки и выгрузки результатов в различные форматы. То есть то, что нужно :).

Итак, немного пробегусь по интерфейсу.

Queries — как раз набор различных гуглодорков. Все разгруппировано и вполне понятно. Ставим галки где нужно, и он ищет по ним.

Далее Settings. Можно выбрать методы получения инфы. Если галка Disable scraper не стоит, то данные будут получаться эмуляцией гугления (не через API). Для этого метода рекомендую сразу добавить перечень proxy в соответствующей вкладке, а то слишком быстро заблочат. Если стоит галка, то используется API Googl’а. Немного подробнее об этом.

Для того чтобы получить доступ к этому функционалу, тебе нужны Google Custom Search ID и API key.

  1. Заходим на https://www.google.com/cse/all и создаем там новый поисковик. С настройками можно сильно не запариваться. В поле Sites to search можно добавить любое название. Это поле важно, только если ты делаешь поиск по своему настоящему сайту (типа поиск для конкретного сайта). Для наших же целей, когда мы хотим искать много где, оно уже не важно. Потом заходим в настройки движка (edit search engine). Главное для нас здесь две вещи. Во-первых, в настройках движка установить для поля Sites to search значение Search the entire web but emphasize included sites. Так гугл будет искать по всем сайтам, а не только по нашим (потому и все равно введенное нами имя). Во-вторых, берем значение из Search Engine ID — это, как ты понял, идентификатор нашего кастомного поисковика. То есть полдела сделано.
  2. Заходим на https://code.google.com/apis/console/. Здесь нам нужно подключить сервис Custom Search API во вкладке Services соответственно. А также получить свой личный API key во вкладке API Access.

Все, теперь можно ввести оба этих значения в настройках SearchDiggity.

Следующий важный пункт — Sites, Domains, IP ranges. В нем как раз очень просто ограничить поиск для гуглодорканья. По сути, используется параметр site: от гугла. Так что можно сразу указать набор доменов, где хочешь совершать поиск, — очень удобно.

Последнее — Query appender, позволяет нам задать дополнительные строки при поиске, то есть прямо в него можно пихать гуглодорки.

Вот, в общем-то, и все. Получается очень удобно.

Еще хотелось бы отметить две фичи. Первая стоит в том, что в настройках можно увеличить количество значений в ответе на запрос (Options-Settings-Google) до 100. И вторая — можно отредактировать файл в поле Default Query Definition. В нем хранится база гуглодорков. Так что можно сделать свой личный набор и оперативно использовать его впоследствии.

Приличный список хостов с Struts devmode = true
Приличный список хостов с Struts devmode = true
 

ОРГАНИЗОВАТЬ MITM ЧЕРЕЗ DHCP

Решение: За последние пару-тройку лет здесь, в Easy Hack, были описаны, наверное, почти все возможные man-in-the-middle атаки. Во всяком случае, после данной атаки мой список закончится :).

Итак, задачка, как всегда: мы в одной сети с жертвой и хотим, чтобы ее трафик ходил через нас. Один из вариантов — использовать поддельный DHCP-сервер. Про саму технологию всезнающая вики говорит следующее. «Dynamic Host Configuration Protocol — протокол динамической настройки узла — сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Данный протокол работает по модели „клиент-сервер“».

По сути, как только хост подключается к сети, его операционная система посылает в сеть широковещательный запрос для того, чтобы найти DHCP-сервер. Тот в случае получения запроса ответит предложением с каким-то свободным IP-адресом, а также дополнительной информацией (IP gateway и DNS-серверов, маска сети, вроде бы еще может быть информация по прокси). Потом идет подтверждение, когда хост отправляет, что «согласен», а сервер отвечает: «ну и хорошо». Порт для DHCP используется 67 UDP. В запросе есть четырехбайтный случайный идентификатор и MAC-адрес клиента.

В общем-то, это все, что нам нужно знать для атаки. Как видишь, клиент пытается найти DHCP-сервер, используя широковещательный запрос (со всей вкусной инфой о себе), а возможности подтвердить, что сервер — это настоящий сервер, нет.

Отсюда вывод: все, что нам необходимо сделать, — это поднять свой DHCP-сервер и ждать клиентов. Тут есть небольшой элемент рулетки, так как получается некий raise condition. Официальный сервер и наш, получив широковещательный запрос, ответят на него, но только первый из ответов будет обработан клиентом. Но если наш хост будет находиться «ближе» к жертве (меньшее количество хопов), то шансы наши конкретно возрастают.

С практической точки зрения можно воспользоваться для атаки либо модулем Metasploit’а dhcp (auxiliary/server/dhcp), либо Ettercap. Второй метод более удобен, так как тулза берет на себя все для реализации самого перехвата данных.

Для атаки нужно выбрать MITM — DHCP spoofing и указать диапазон IP, маску подсети и DNS-сервера (можно повторить данные от официального DHCP-сервера). А IP нашего хоста будет автоматом подставлен как gateway. Пара кликов — и все, мы посередине.

 

ОБОЙТИ ГРАФИЧЕСКИЙ КЛЮЧ

Решение: Давай отойдем от привычных внутренних вещей и поговорим о чем-то более неформальном и «живом», что ли, — о физической безопасности. Вообще, многие хакеры интересуются этими вопросами. Взлом замков (lock picking) — тому подтверждение. Мне лично кажется иногда, что это такая «профдеформация». Появляется желание все ломать. А ломание чего-то физического — тот еще фан :). Но это так, вступление к последующим двум вопросам.

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

Да, исходя из этого, ОС на компах, по сути, не сильно защищены. Но компы стационарны, и защищать их несложно, а вот современные мобильники/смартфоны, которые содержат много критичной инфы, часто теряются, да и украсть их просто. А потому безопасности физической и доступу в информации в них уделяется приличное внимание.

Одним из методов защиты под Android служит графический ключ. Девять точек, которые необходимо соединить в определенной последовательности. Всем понятно, что это не самая секьюрная штука, но все же и ее тоже интересно поломать :). По этому поводу есть ряд интересных исследований. Одно из них, очень угарное, — получение графического ключа с девайса за счет анализа жировых следов, оставляемых от тыканья пальцами. Посмотреть фоточки и почитать подробно можно тут. Я лишь расскажу основные аспекты из работы.

Для начала, я думаю, понятно, что, когда мы тыкаем экран пальцем, на экране остаются жировые пятна. Когда проводим графический ключ —мы оставляем целый жировой след. «Заполучив» этот след, злой дядя может за две попытки ключ подобрать. Сначала попробовать его в одном направлении, потом — в другом. И даже если там будет не весь «трек», а только часть его, то с учетом особенностей человеков и того, как они придумывают свои графические ключи (чтобы их еще было удобно использовать), ключ подбирается за считаные попытки.

Съем же трека тоже дело простое. Нам потребуется источник света и твой глаз либо фотик. За счет того, как преломляется/отражается/рассеивается свет от чистой и грязной поверхности, мы можем различить сам трек. В этом исследовании народ запарился и провел изыскания — а под каким же углом лучше всего видно. После многочисленных экспериментов с различными моделями и углами пришли к выводу, что это 60 и 45 градусов (упертые парни). Кроме того, еще они провели ряд экспериментов (см. фотки в работе), в которой показали, что, сделав фото поверхности телефона, на которой плохо виден след, и обработав фотографию за счет контрастности и яркости, можно различить след.

Также интересной особенностью является многослойность жировых следов (вот честно, не знаю об этом ничего). Оставляешь след от ключа, например, а потом тыкаешь экран, и даже если весь затыкать, то старые следы почти не сотрутся. Под различными углами их можно четко различить. Магия! Кроме того, были проведены опыты, когда телефон пихали в карман и двигали в нем, и все равно след от ключа оставался. Таким образом, можно заключить, что если не чистить экранчик насильно, то графический ключ можно «слить» почти стопроцентно. Я думаю, пока народ исследовал эту тему, они отлично повеселились, да и получился крутой тру-хак!

Между прочим, не стоит воспринимать данную работу совсем уж фановой. Если трансплантировать опыт с андроидовских ключей на что-нибудь более критичное, то и итог может быть более критичен. Тачскрины сейчас внедряют повсеместно, а потому и жировые пятна наши пальцы оставляют все чаще. И чем не метод, например, для получения PIN-кода с банкомата. Сделал фото под определенным углом и узнал, из каких цифр состоит PIN предыдущего пользователя. Ну, это так… давай мыслить шире :).

 

ОБОЙТИ «КНОПОЧНЫЙ» ЗАМОК

Решение: О, а этот метод на самом деле безумен! Я прочитал его у одного очень известного парня — Михала Залевски. В своем блоге еще в 2005 году он поделился этой интересной находкой.

Итак, что мы имеем. Представь, что есть какой-то кнопочный кодовый замок. Например, на сейфе :). Задача получается перед нами серьезная и непонятная для взлома. Конечно, можно вспомнить школьные методы. Кнопочки, которые используются чаще всего, будут либо легче нажиматься (механически), либо иметь внешние затертости. Для входа в парадное, они, конечно, работали, но вот с чем-то более серьезным вряд ли прокатит.

К тому же подходить и анализировать кнопки, а также кликать и пробовать варианты — это все повышает шансы быть замеченным.

Что же делать? Михал предложил сногсшибательное решение. Воспользоваться специальным девайсом — инфракрасной камерой. Точнее, даже термокамерой (не знаю, как оно корректно по-русски, но ты понял), то есть камерой, которая «видит» теплоту предметов. Нужна с хорошей чувствительностью. Михал писал, что такую можно купить за 5–10 тысяч зеленых :).

Похоже, что это рука самого Михала (!!!) вводит пин 1–5–9
Похоже, что это рука самого Михала (!!!) вводит пин 1–5–9

Суть же атаки в следующем. Ждем, пока кто-то воспользуется сейфом, введет правильный код и уйдет. А дальше мы смотрим через камеру и видим, что те кнопки, которые были нажаты, имеют большую «теплость».

Так видит инфракрасная камера
Так видит инфракрасная камера

Причем кнопки, которые были нажаты раньше, будут холоднее. Таким образом очень просто мы получим необходимую кодовую последовательность.

Камера автоматом поднастраивается, и мы видим введенный пин 1–5–9
Камера автоматом поднастраивается, и мы видим введенный пин 1–5–9

Самая главная фича метода в том, как отмечает автор, что даже за те доли секунды, пока происходит нажатие кнопки, ей передается от человеческого тела достаточно тепла, чтобы быть «замеченным» камерой. В определенных ситуациях можно так же отследить кнопки, нажатые в перчатках. Причем кнопки рассеивают это тепло достаточно медленно. Примерно 5–10 минут! Добавь к тому же, что девайсы эти могли работать на расстоянии от 1 до 10 метров (может, сейчас они стали еще круче?).

В общем, атака из набора агента 007. Голова идет кругом! Подробнее читай тут.

Надеюсь, прочтенное наполнило тебя энтузиазмом и жаждой жизни, так что если есть желание поресерчить — пиши на ящик. Всегда рад :).

И успешных познаний нового!

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

  • Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии