9 ноября крупный российский банк зафиксировал атаку на свой основной публичный web-сайт. События совпали по времени с большим количеством политических медийных событий, связанных с подведением итогов выборов президента США.

В этот момент специалисты нашей компании проводили внешний пентест инфраструктуры банка (шел первый день работ). Банк был предупрежден о возможном влиянии проводимых работ на продуктивные системы, поэтому именно с внешним пентестом и были связаны первые предположения о причинах наблюдаемых трудностей в работе web-сайта.

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

По итогам анализа событий ИБ и журналов web-серверов была зафиксирована следующая хронология событий.

В течение 8 ноября злоумышленниками проводились попытки эксплуатации уязвимостей, связанных с обработкой скриптами web-сайта параметров запросов (попытки формирования запросов, приводящих к нарушению работы приложений). Шло изучение жертвы, искались способы создать специфическую атаку, которая бы гарантированно вывела именно сайт банка из строя. Существенного влияния на доступность сайта это не оказало. Судя по всему, ничего интересного злоумышленники найти не смогли и решили действовать «грубой силой».

9 ноября с полуночи и примерно до шести часов утра атака велась с помощью низкоуровнего флуда малой мощности (до 10 Мбит/с). Использовалась древняя атака syn flood, направленная на исчерпание ресурсов web-серверов. Локальная система защиты от DDoS успешно отражала эту небольшую атаку.

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

В первой половине 9 ноября оператор связи, каналы которого были выбраны основными, успешно отражал атаки мощностью до 350 Мбит/с. Системы банка сами бы с такими нагрузками не справились.

Оценив серьезность атаки, банк начал экстренно подключаться к одному из российских облачных сервисов по защите от DDoS. Это удалось сделать к концу дня. Угроза была донесена до руководства финансовой организации, что позволило максимально ускорить процесс.

Системы банка и отчеты провайдера давали понять, что злоумышленники видят неэффективность проводимых атак и перебирают разные варианты. Были испробованы различные виды: как низкоуровневые и простые (icmp flood, syn flood, spoofed syn flood), так и уровня приложений. Большая часть их была направлена на исчерпание доступных ресурсов web-серверов.

Анализ IP-адресов атакующих показывал, что они большей частью не относятся к числу известных прокси-серверов или выходных нод анонимной сети TOR, не определяются как какие-либо публичные сервисы, т.е. использовался ботнет в основном на реальных устройствах. Это и специфика проводившихся атак позволяет согласиться с аналитиками, которые утверждают, что в атаке участвует часть знаменитого ботнета Mirai. Исходный код составляющих ботнета недавно был выложен в сеть, поэтому мы допускаем, что это не оригинальный ботнет, а уже новый, меньшего масштаба, но также состоящий из взломанных IoT-устройств, в том числе домашних видеорегистраторов.

К сожалению, злоумышленники смогли в итоге нащупать слабое место в защите банка. Ни провайдер, ни сервис защиты от DDoS не смогли качественно разделить легитимный и вредоносный зашифрованный трафик (HTTPS). Атакующий понял это и направил основной поток атаки на данный вектор. Зараженные системы просто заходили на сайт по HTTPS с большой интенсивностью. Так как криптография требует много вычислительных ресурсов, системы банка не справились с нагрузкой. Сайт «лёг». Клиенты не могли зайти на главную страницу, воспользоваться интернет-банком.

Возможно, банку мог бы помочь WAF (специализированный межсетевой экран для защиты web). Он даже был установлен, но его не успели ввести в эксплуатацию и сайт банка не был к нему подключен.

Финансовой организации пришлось экстренно адаптировать инфраструктуру сайта к атаке: шифрование было вынесено на отдельные узлы повышенной мощности, на части страниц сайта пришлось отключить HTTPS вообще (там, где не обрабатываются конфиденциальные данные). Эти меры позволили выправить ситуацию, но все же несколько часов сайт работал со сбоями.

Помимо явного урона DDoS-атака создала повышенную нагрузку на инфраструктуру банка (фермы виртуализации, каналы связи и промежуточное сетевое оборудование), что привело к деградации производительности и проблемам в работе ряда систем, которые не относились напрямую к сайту.

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

P.S. 11 ноября атаке подвергся еще один наш клиент, банк далеко не из первой десятки. Однозначно сказать, что это часть той же атаки, нельзя, но в целом ее профиль очень похож.

Авторы: Андрей Янкин, руководитель отдела консалтинга Центра информационной безопасности компании «Инфосистемы Джет» и Сергей Павленко, начальник отдела инженерной поддержки и сервиса Центра информационной безопасности компании «Инфосистемы Джет».
Поделиться с друзьями
-->

Комментарии (20)


  1. wscms
    14.11.2016 15:50

    Даже в адресную строку посмотрел — хабр ли это?


    1. lostpassword
      14.11.2016 19:38
      +1

      Хабр вот. И вот тоже.


  1. lostpassword
    14.11.2016 19:40
    +2

    А чем мог бы в данной ситуации помочь WAF? Ему же приходилось бы точно так же «на лету» расшифровывать HTTPS-трафик, что потребовало бы таких же диких вычислительных мощностей…
    Или использовалась бы какая-то другая технология, не требующая расшифровки трафика?
    Хотелось бы этот момент уточнить поподробнее.


    1. itsecurity
      14.11.2016 20:28
      +3

      Да, если говорить о расшифровке HTTPS, то ничем бы не помог. Этот вопрос был решен в лоб переносом шифрования на более производительные серверы. WAF тут мог бы помочь, по нашему опыту, в трех вопросах:
      1) Мониторинг трафика. Средствами WAF намного проще разобраться, что происходит в данный момент и как можно блокировать очередную волну.
      2) К WAF можно прикрутить скрипты, которые позволяют по-разному обрабатывать различные запросы. Например, делать задержки.
      3) С точки зрения возможного развития атаки. Злоумышленник увидел, что наиболее пробивной является маскировка под реальных пользователей. Когда сайт перестал валиться из-за SSL, логично было бы переключиться на «тяжелые» запросы. Тем более в рамках разведки за день до атаки хакер их явно нащупал. Тут WAF бы очень пригодился для отделения реальных пользователей от ботов и мониторинга запросов.

      Конечно, все это можно сделать и без WAF, но не так удобно и быстро. Самое обидное, что WAF был, стоял чуть ли не в соседней стойке, но воспользоваться им возможности не было.


      1. lostpassword
        14.11.2016 20:46

        Спасибо, интересно было узнать мнение эксперта. Ещё два вопроса, если позволите.
        1. Я правильно понимаю, что в пунктах 2 и 3 всё равно потребовалась бы расшифровка трафика «на лету» (иначе у нас не будет возможности увидеть сами запросы, отделив их от коннектов) и, как следствие, пришлось бы сам WAF переносить на более мощный сервер (так как для расшифровки HTTPS «на лету» требуются значительные вычислительные мощности)? Или железо, отданное под WAF, уже заведомо мощнее железа, отведённого под веб-серверы?
        2. Как технически организуется прозрачная для пользователей расшифровка трафика «на лету»? В WAF импортируется сертификат с закрытым ключом веб-сервера?


        1. itsecurity
          14.11.2016 23:39
          +1

          Ответили с Сергеем по пунктам:

          1. Разумеется, железо, отдаваемое под WAF, планируется с учетом необходимости обработки SSL. Сама по себе нагрузка от выполнения криптографических операций никуда не исчезает, но ее перенос именно на WAF необходим для обеспечения работы с данными на L7. При этом нагрузка на серверы приложений может быть существенно снижена не только за счет переноса точки обработки SSL, но и за счет возможности фильтрации паразитного трафика или выполнения дополнительной оптимизации на стороне WAF.
          Железо WAF рассчитывается на такие нагрузки, поддерживает кластеризацию, балансировку, может иметь аппаратную ssl-акселерацию и т.п.

          2. Да, в общем случае на WAF импортируются ключ и сертификат, или же ключевая пара генерируется прямо на WAF, после чего сертификат подписывается и импортируется. Таким образом круг пользователей, которым доступен ключ, сокращается до администраторов ИБ. Далее функция ssl offloading'а выполняется на WAF, чаще всего в режиме reverse proxy с балансировкой, но возможны и более экзотические варианты. Для передачи от WAF до серверов приложений может использоваться как http, так и ssl в случае архитектурных ограничений и отсутствия по каким-либо причинам доверия к среде передачи данных.


          1. lostpassword
            15.11.2016 07:30

            Большое спасибо за ответ, было интересно узнать про эти вещи.)


      1. flx
        15.11.2016 14:15

        WAF — это не самая алгоритмически легкая задача, и при хорошо поставленной атаке — умрет первой. Именно поэтому работает только в связке с ddos mitigation.


        1. itsecurity
          15.11.2016 14:20

          Абсолютно согласен. С точки зрения DDoS, WAF — это уже последние рубежи обороны.


      1. ximaera
        15.11.2016 20:43

        Да, если говорить о расшифровке HTTPS, то ничем бы не помог. Этот вопрос был решен в лоб переносом шифрования на более производительные серверы.
        Ну это вам очень сильно повезло, что в атаке не участвовали ни Mirai, ни Wordpress. Иначе вам бы не то что серверов, а даже и аплинка могло бы не хватить.


        1. itsecurity
          15.11.2016 21:08
          +1

          Злоумышленники явно распыляли силы на большое число банков. Это видно и по небольшому объему атаки, и по тому, как они с задержкой реагировали на блокировку очередной волны.
          Будь это полноценный Mirai, такую драматичную историю можно было бы писать уже не от лица банка, а от лица Ростелекома:)
          Но не все же Брайны Кребсы. Обычные атаки, которым российские компании подвергаются каждый день, гораздо менее эпичны.


  1. pwrlnd
    15.11.2016 13:14

    После слов:

    Оценив серьезность атаки, банк начал экстренно подключаться к одному из российских облачных сервисов по защите от DDoS.


    Сомневаюсь вот в этом утверждении:
    Он даже был установлен, но его не успели ввести в эксплуатацию и сайт банка не был к нему подключен.


    Такие сервисы должны быть изначально под защитой от DDoS. Как минимум потому, что хорошие сервисы используют анализ трафика за несколько недель, чтобы отделить легитимный трафик.


    1. flx
      15.11.2016 14:16
      +3

      А вообще обидно когда терапевту к порогу доставляют покойника. Приходится подрабатывать реаниматологом. Очень нервная работа.


    1. itsecurity
      15.11.2016 14:18
      +1

      Рассказываем, как есть. Реальность, увы, всегда отличается от идеальных «правильных» случаев.
      Облачные сервисы оказываются по подписке и их можно подключить быстро. А ставить ненастроенный WAF в режиме блокирования в разрез — лучший способ полностью положить сайт. Но тут были и орг проблемы с его установкой.


      1. pwrlnd
        15.11.2016 14:30

        Я больше негодую про то, что подключать сервис защиты от DDoS во время атаки — очень дурной тон. Выше flx хорошо пояснил ситуацию. Сомневаюсь, что для банка так уж накладно постоянно оплачивать такие услуги.


        1. itsecurity
          15.11.2016 18:46

          Я думаю, большая часть клиентов облачного Anti-DDoS подключается после первого пожара. Хорошего в этом, конечно, мало.


  1. alex87is
    16.11.2016 11:19
    +1

    А что с такими атками делают на правовом уровне? Вы\компания подают потом заявление в отдел по киберпреступлениям(или как он там)?


    1. itsecurity
      16.11.2016 20:53
      +1

      По факту компании заявления подают только после хищения денег вследствие взлома, да и то не всегда. Если кто-то и пытался по факту DDoS возбудить уголовное дело, я не знаю ни одного случая в России, когда бы это принесло какие-то плоды.
      Наше законодательство сейчас абсолютно устарело в части компьютерных преступлений. Есть 272, 273 и 274 статьи УК РФ, которым сто лет в обед. Если кого-то и ловят из серьезных хакеров (например, выводящих деньги со счетов банков), то они идут по несколько притянутым за уши «смежным» статьям.


  1. altynos
    16.11.2016 15:28

    В этот момент специалисты нашей компании проводили внешний пентест инфраструктуры банка

    Довольно странное совпадение, похоже информация о тестировании утекла от пентестера или банка, а злоумышленники пользовались расслабленной CSIRT банка.


    1. itsecurity
      16.11.2016 20:56

      Не думаю. По опыту, спецы заказчиков во время пентеста наоборот бдят вдвойне.
      Гораздо более распространенный кейс, когда сам DDoS маскирует направленную атаку на компанию.
      В данном случае интриги и вовсе нет. Атака была массовая, сразу на десяток банков. Ее автор сообщил, что это заказ политически мотивирован и связан с местью за вмешательство России в выборы в США. Сам злоумышленник активно пиарился, надеясь найти новых заказчиков.