Массовые атаки: особенности противодействия на опыте последних лет

    Многие центры безопасности смыслом своей работы, а то и жизни делают борьбу с хакерами и атаками. Дело действительно важное и интеллектуально очень емкое. Исследуем данные Threat Intelligence, собираем атрибуцию на группировки и её TTP (tactics, techniques and procedures), разрабатываем отдельные сценарии и правила выявления инцидентов, внедряем мощные технологические решения. Это огромный и важный кусок работы любой команды по безопасности, а уж тем более любого зрелого SOC.

    image

    Но периодически все классические подходы к безопасности через мониторинг просто умножаются на ноль, когда в жизнь приходит большая и неприятная массовая атака. Та самая, о которой узнаёт даже ваша бабушка. Условно назовем такую атаку медиакиберпандемией, чтобы не путать с регулярными рассылками Cobalt или хитрыми инструментами Silence (для бывалых они уже стали чем-то вроде белого шума). Речь о Heartbleed, Shellshock, WannaСry, уязвимости в оборудовании Cisco и прочих. Что их отличает от прочих кибердиверсий? Как в этом случае стоит (или не стоит) вести себя SOC и просто ИБ-службе компании? Давайте разбираться под катом.

    Новая угроза или старая проблема?


    Если посмотреть на такие инциденты внимательнее, достаточно быстро становится понятно, что отличает их от всех остальных: за каждым из них стоит некоторая фундаментальная критическая уязвимость. Eternal Blue собрал свой урожай в 2017 году, маскируясь под разными именами (DoublePulsar, WannaCry, NotPetya), апрель 2018 года бушевал уязвимостью CVE-2018-0171, время BlueKeep пока не пришло (но это не точно). В итоге отличие от продвинутых атак — в ключевых составляющих:

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

    image

    Образно говоря, речь идет о молоте, а не о рапире. К сожалению, вендоры могут косячить не дают нам скучать, и злоумышленники получают в свои руки такие молоты достаточно часто. За каждой большой и массовой атакой стояла своя большая и страшная уязвимость от одного из вендоров. В таких условиях отслеживание критических уязвимостей и своевременная работа с ними становятся одними из основных аспектов деятельности ситуационного центра информационной безопасности, который так часто приравнивают к Security Operations Center.

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

    Просто добавь воды поставь патчи


    Очень популярное возражение: «Да какой же (тут меня покарала цензура) умник вывесил сервис в интернет без патчей?!», «Уязвимости уже столько времени — неужели не могли вовремя обновиться?» и так далее.

    image

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

    Что стоит на пути офицера ИБ?

    • Огромный парк рабочих станций, которые никогда не бывают доступны одновременно, а у части пользователей еще и невозможна их автоматическая перезагрузка.
    • Необходимость тестирования патчей ОС и оборудования на совместимость с прикладным ПО, специализированными протоколами и т.д.
    • Нагрузочное тестирование по ключевым системам, чтобы патч не прикончил случайно быстродействие системы (кто не помнит историю Spectre/Meltdown, прошу сюда xakep.ru/2018/01/10/meltdown-spectre-slowdown).
    • Простой бизнес-процессов и сервисов, который даже в корпоративной среде согласовать непросто, а когда речь касается уязвимостей в оборудовании АСУ ТП… ну это вообще отдельная история.

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

    image

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

    Волки, волки, или Без сплойта нещитово


    image

    Казалось бы, при всех ранее названных проблемах и сложностях обновления имеет смысл патчить только самые критичные бреши. Или, как написано в комментарии одного из экспертов к нашей новости про BlueKeep-1, только те, для которых уже есть готовый эксплойт в паблике. Позиция действительно имеет право на существование: зачем зря гонять айтишников и портить с ними отношения? И басню про мальчика, которую мы обозначили в названии раздела, наверняка все знают, но, как всегда в такой ситуации, есть нюанс.

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

    image

    Time2Attack

    Это выдержка из большой аналитики по тому, какие интервалы времени проходят между фактической публикацией уязвимости с начала и до появления публичного эксплойта, а потом от эксплойта до первой публичной (известной) атаки злоумышленников. Оставим пока за скобками ситуацию с BlueKeep, который действительно пока в свободной природе никак себя не проявил, но по всем остальным ситуация достаточно показательная: речь, как правило, идет не о месяцах, а о неделях до появления эксплойта, и о днях с момента его первого использования. Особенно печально ситуация смотрится для уязвимости Adobe (CVE-2018-15982), которая использовалась в атаке уже через сутки после появления эксплойта. Скроллим пост немного наверх и видим, что в среднем мы просто не успеем поставить патчи на инфраструктуре, если будем ждать эксплойта. Поэтому в реалиях нашей жизни без него вполне «щитово» и лучше проявить заботу о своей инфраструктуре раньше, не опасаясь потенциальных проблем с ИТ-подразделениями.

    Несколько полезных/бесполезных (нужное подчеркнуть) советов


    К чему приводят нас все эти рассуждения? Что в идеале компании нужно иметь карту или методику реагирования на каждую выявленную критическую уязвимость? В каждом случае она будет индивидуальна до дьявола, но я хочу поделиться несколькими полезными советами от себя.

    • Отслеживаем уязвимости на регулярной основе, начинаем «паниковать» до появления эксплойта — процесс организовать не так сложно, как кажется. Собираем информацию с сайтов вендоров (patch Tuesday и т.д.), новостных лент, подписываемся на несколько тематических Хабра-аккаунтов и других блогов, добавляем рассылки от специфических для инфраструктуры вендоров и хотя бы раз в день с утра читаем опубликованную информацию. Как правило, это неплохой первый шаг, чтобы оставаться в курсе.
    • Проверяем периметр организации на открытые сервисы — сложность инфраструктур сейчас все выше, да и контроль за работами ИТ-подразделений усложнен (поэтому RDP на периметре даже в крупных компаниях не удивляет). Значит, нужно проверять свои внешние адреса аккуратным сканом хотя бы разово по факту обнаружения критичной уязвимости, а в идеале делать это регулярно (инструментов море — от почти бесплатного shodan до коммерческих сервисов). И да, к этому процессу стоит относиться примерно как к чистке зубов.

      NB! Конечно, это будет работать, только если мы на самом деле знаем свой внешний периметр и внешние адреса и занимаемся его инвентаризацией.
    • При уязвимостях RCE на операционной системе или офисном ПО в зону патчинга необходимо включать в первую очередь рабочие станции. Конечно все самое критичное хранится в серверном сегменте, но первой точкой поражения при закрытом периметре с высокой вероятностью станут пользователи (посредством фишинговых писем, зараженных флешек и т.д.) и уже от них эпидемия будет расползаться по сети. Плюс установка патчей на АРМ, как правило, проходит менее болезненно с точки зрения согласования и цикла тестирования.
    • Если мы используем СОА/IPS между сетями, ждем от вендоров сигнатуры по выявлению признаков эксплуатации уязвимостей или пишем ее сами (если обладаем требуемой экспертизой). Изоляция угрозы в конкретном сегменте существенно сократит область поражения.
    • Но тем не менее не успокаиваемся, пока мы не поставили патчи на всей инфраструктуре. Вектора доставки ВПО и атаки злоумышленников крайне разнообразны, а гарантию в нашей жизни уже не дает даже сберегательная книжка.

    Надеюсь, что наши рекомендации помогут кому-то быстрее отбиваться от очередных зомби массовых атак.
    • +18
    • 3,4k
    • 8
    Ростелеком-Солар
    221,57
    Безопасность по имени Солнце
    Поделиться публикацией

    Комментарии 8

      0
      Даже со штатом порядка 50-60 сотрудников самое обычно, банальное обновление винды которое, кстати, само скачается и предложит себя установить уже может стать проблемой т.к. люди неделями игнорируют его и делают все возможное лишь бы не устанавливать. А нажать кнопку «установить» прямо перед уходом с работы им уже религия не позволяет. А про обновление того, что еще и скачивать нужно вообще слышать не хотят :(
        +1

        Да вы что! У меня же тогда 100500 вкладок в браузере закроется! ©
        Для решения этой проблемы применять GPO расписанием установки и принудительной перезагрузкой.

          +1

          Я вот недавно так и нажал "Обновить и завершить работу" перед уходом с работы. А надо было нажать "Обновить и перезагрузить". Итог — минус 3 часа рабочего времени следующим утром...


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

            0
            Вот этот момент тоже минус, тоже промахиваюсь иногда. К сожалению во многих фирмах почему-то подразумевается, что если рабочий день (условно) с 9 до 18, то это «для людей», а айтишники вполне могут работать, ну, с кажем, с 8:40 до 19-20 + в выходные, отпуска и больничные.
          0
          Я думаю вскоре стоит ожидать массовых атак через BlueKeep
          github.com/rapid7/metasploit-framework/blob/f528d3e332e8e2a5b91226a036741b7f6fb0f64c/modules/exploits/windows/rdp/cve_2019_0708_bluekeep_rce.rb
            0
            А почему RT-шный CERT уже 7 месяцев не может дыру закрыть и вообще на письма не отвечает? :-D
              0
              Адрес CERT «Ростелекома» — cert@rt.ru. Попробуйте написать туда.
                0
                Дырка должна закрываться независимо от моего попинывания после репорта о ней, нет?

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое