Сегодня мы порассуждаем об одном событии, которое тихо произошло в середине июля. Мы будем говорить о скорости реакции на инцидент тех, кто должен защищать свои ресурсы, ну и, как водится, затронем проблемы индустрии ИБ.

 

16 июля

Тихим летним днем ребята из Apache Foundation выпустили advisory об очередной уязвимости в фреймворке Struts2. Как обычно, за этим фреймворком тянется шлейф уязвимостей, связанных с внедрением ONGL-выражений (есть такое в Struts2), и, как следствие, выполнение произвольного кода. Суперпростые баги, дающие фактически шелл атакующему. Так и в этот раз вышел патч и описание новой проблемы — удаленное выполнение кода через внедрение ONGL: struts.apache.org/release/2.3.x/docs/s2-016.html. Давайте я просто покажу, как это можно сделать — выполнить ID вслепую (для краткости):

http://host/path/blah-blah.action?redirect:${('#zlo%5C75@java.lang.Runtime@getRuntime().exec("id")')(e)}

То, что между ${ .. }, — это и есть ONGL-выражение. Например, для быстрого теста на уязвимость:

http://host/path/blah-blah.action?redirect:${31338-1}

и, если будет редирект на

http://host/path/31337

значит, ONGL-выражение прошло (вычитание единицы). Как видно, уязвимость простая и… массовая. Дело в том, что фреймворк Struts достаточно популярен, можно найти сайты банков, включая ДБО, правительственные сайты и даже военные сайты в домене .mil, которые работают на нем. Итак, у нас есть адвайзори и простая, но действенная уязвимость...

Опа, RCE. На скриншоте виден указатель на созданный процесс
Опа, RCE. На скриншоте виден указатель на созданный процесс
 

1-day or 0-day

Это, конечно, не 0-дей, и вроде, раз вышла адвайзори, то тема исчерпана и мир в безопасности. Ресерчеры нашли багу, сообщили вендору, вендор сделал патч и написал мимимишное адвайзори. Но некоторые товарищи из Китая сразу же, того же 16-го числа написали рабочий эксплойт (в адвайзори была урезанная версия, с анти-скрипт-кидди триками). Более того, они сделали однокнопочный пывнер и выложили где-то там у себя в китайском блоге (kuxoo.com/archives/260). И тут армия скрипт-кидди, кибертеррористов, ресерчеров и разных плохих и хороших китайцев бросилась взламывать интернет. Весь и сразу. Да это 1-дей... но подумай, кто УСПЕЛ и СМОГ бы защититься? Обновить фреймворк — это работа, а в некоторых часовых поясах люди еще спят. Кроме того, некоторые не могут просто так взять и обновить Struts2. Надо сделать это сначала в QA... И потом, более важное, — НИКТО адвайзори не читает, тем более что сообщение об уязвимости не было ни в CERT, нигде... Так, на сайте struts.apache.org очередное обновление. Who cares?

 

«Бумажная ИБ»

В это время кипит ИБ-бизнес, продаются услуги консультантов, услуги пентеста, дорогие сканеры безопасности и железки, которые предотвратят вторжение. Стандарты, сертифицированные специалисты, конференции... куча всего. Но как это поможет, если некоторые стандарты, такие как PCI DSS, дают месяц на установление критичного патча! А Китай пошел в атаку уже 17-го числа... то есть через один день после выхода патча. Например, 24 июля я проверил, стоит ли этот патч на системе ДБО, работающей с картами одного из крупнейших банков... и, конечно, там была дыра. Ну как, все о’кей... по стандарту. Более того, немного погуглив, я нашел уязвимый сервис госзаказов одного из регионов РФ (нет патча на 26-е число, спустя десять дней после начала атак)! А дело в том, что там нет людей, занимающихся ИБ. Нет, там есть CISO, но они сейчас читают блог А. Лукацкого и думают о рисках, о высоком... Есть админы, но они занимаются совсем другим (скорее всего, именно они обнаружат атаки — может, когда уже будет бот, — и сделают, конечно, фикс). Будем надеяться, что там есть хотя бы HIDS, которые обнаружат атакующего уже после вторжения... (кстати, банк поставил фикс 25-го числа, спустя девять дней).

Эксплойт не прошел, команда Apple среагировала на инцидент :)
Эксплойт не прошел, команда Apple среагировала на инцидент 🙂
Эксплойт не прошел, команда Apple среагировала на инцидент :)
Эксплойт не прошел, команда Apple среагировала на инцидент 🙂

Нет, я согласен, ситуация тяжелая, но можно ли с ней бороться? Возьмем как пример платежную систему QIWI. Милые и открытые ребята, но и у них все построено на Struts2. Тем не менее 18-го числа уязвимости уже не было. Они запатчили за два дня, что в некотором, высоком приближении могло случиться до того, как IP-сканеры из Китая доберутся до российского сегмента. Крупнейший банк проиграл более технологичному QIWI. А еще у QIWI багбаунти, что также могло повлиять на скорость реакции, например, какой-нибудь ресерчер успел сообщить о баге. Но важен результат — QIWI показали, что защищаться они умеют хорошо. Например, мы узнали об уязвимости от китайских коллег и уже 16–17-го числа стали разворачивать фиксы. При этом 18 июля в логах уже стали светиться китайские IP-адреса с шаблонами атак. Благодаря тому что наши специалисты по ИБ мониторили блоги (по собственной инициативе) с паблик-сплоитами в китайском регионе, мы оказались быстрее. К слову, от CERT мы получили уведомление 22-го числа, что могло быть поздно... а для кого-то и было поздно. Так, был взломан developer.apple.com. Он крутился именно на Struts2 и не успел обновиться... всего каких-то три дня с момента выхода патча. Только прогремели новости о взломе ресурса Apple, как тут же выясняется, что хакеры получили доступ к базе данных OVH.com (один из крупнейших хостингов). На сайте пишется что-то про взлом по email и кражу VPN-ключей... но я нашел там Struts2, причем непатченный! Может, хакеры проникли и через почту, но как-то даты уж больно близки... В общем, суть одна: нельзя полагаться на законы, бумаги, инструкции и стандарты — это совершенно другая реальность, должны быть люди, которые понимают, что происходит в ИБ, в IT Security, — без них никуда. Подумай — сейчас висит уязвимость удаленного выполнения кода на сайте госзаказов одного из регионов РФ... То есть на момент написания в РФ только один QIWI показал достойный результат, а госзаказы… ладно, пусть Китай поучаствует :). И дело не в том, что есть какая-то бага, баги будут всегда — дело в том, что индустрия ИБ не работает так, как хотелось бы тем, кто действительно парится о защите своей информации. Она работает так, как надо продавцам ИБ-решений. Хотя дело не только в технологиях и индустрии, а еще и в людях и в процессах.

Как-то непатриотично. Давай посмотрим другой пример, связанный с инженерной реакцией: система аутентификации в Sony Entertainment Network построена на Struts2, как и один из сервисов Apple — expresslane.apple.com. Ребята (особенно из «Эппл») были уже не понаслышке знакомы с этой начавшейся волной атак. Они быстренько замутили хотфикс, и поэтому китайский эксплойт не работает (сделали это в районе 18–19-го числа). Надо сказать, мы удачно догадались проверить, что эксплойт работает еще и в POST. Поэтому наш хотфикс это учитывал, зато ребята из «Сони» и «Эппл» не додумались и в итоге опять оказались уязвимы. Тем не менее после моего репорта им и Sony, и Apple отреагировали на репорт в течение десяти часов; это говорит о том, что люди там есть, а пропустить менее стандартный вектор атаки и слишком довериться инструменту защиты, будь то WaF или IPS, может каждый.

 

Выводы

Скорость и качество реакции на событие в контексте современных угроз достаточно важный элемент. Как видно из примеров, тебя не спасет модная железка, тебя не спасут стандарты PCI DSS или ISO, умный CISO не поможет и талантливый админ не успеет. Однако такая мелочь, как багбаунти, может неожиданно прокнуть! Или сотрудники компании, которые понимают, что такое хакеры и как ломать, вовремя просекут фишку и успеют предупредить угрозу в реальной среде с реальными данными. Это люди, это процесс (например, можно провести инвентаризацию стека ПО и анализировать каждый вышедший апдейт, хотя для больших компаний это не вариант). Есть разные пути решения, и даже в гонке, где каждый день на счету и кажется, что успеть нельзя, при хорошей security/response-команде можно отбиться. Нужна ли вам такая команда или достаточно CISO-блогера — решать, конечно, бизнесу. Моя мысль проста: озаботиться регуляторами, бумажками, рисками и забить на инженерные дела — это провал ИБ, но сейчас индустрия движется именно в эту сторону, особенно в РФ, и в ваших силах попытаться изменить это :).

 

Алексей Синцов

Известный white hat, докладчик на security-конференциях, соорганизатор ZeroNights и просто отличный парень. В данный момент занимает должность Principal Security Engineer в компании Nokia, где отвечает за безопасность сервисов платформы HERE

Теги:

Check Also

Номер триста. Колонка главреда

О приближении трехсотого номера коллеги начали мне напоминать примерно два года назад: ког…

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

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

    Подписаться

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