Вирус Petya и правильная комплексная защита от него и подобных следующих вирусов

29 июнь, 2017 - 11:59Игорь Шаститко

Посмотрим пошагово, чего же такого пропустили CIO, что могло бы предотвратить эпидемию в украинских компаниях «на корню», что есть в базовых рекомендациях Defense-in-Depth и реализовать которые не является большой проблемой. Напомню, требования Defense-in-Depth (DiD) достаточно простые и предусматривают реализацию тех или иных сервисов защиты на всех уровнях ИТ-инфраструктуры.

Вирус Petya и правильная комплексная защита от него и подобных следующих вирусов

Есть и более «продвинутые» методы защиты, которые обеспечивают высокий уровень защиты от современных типов атак, которые в том числе, использовались и в Petya — Securing Privileged Access.

Итак, начнем с первичного заражения. В данной эпидемии рассматривается 2 основных сценария — проникновение через почтовые сообщения в виде вложения к письму и через систему обновлений MEDoc, так называемую атаку «software supply chain attacks», когда взламывается поставщик ПО. Подробно, кто еще не прочитал — «разбор полетов» можете посмотреть здесь.

При этом в первом сценарии запущенный пользователем из почты исполнимый файл атакует ОС через уязвимости SMBv1 (EternalBlue/EternalRomance) и получает все требуемые права, чтобы выполнить свои процессы — шифрование и распространение.

Какие методы противодействия Defense-in-Depth помогут от подобной атаки:

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

  • Приложения — антивирусы, которые ловили Petya.A с самого начала эпидемии. Надо обновлять сигнатуры — нет, не слышали?

  • Хост — бронирование ОС — накатить готовые политики с рекомендованными настройками безопасности от Microsoft Security Compliance Manager или доточить их под рекомендации — например, отключить SMB v1 как класс и прочие ненужные устаревшие сервисы — плевое дело, управление обновлениями (совсем не сложно, особенно, если Windows не пиратская), с IDS сложнее, но даже тут — всего лишь подписка на Defender Advanced Thread Protection, который, как показала практика, ловит атаки подобного типа на корню.

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

Так что в данном случае — сам факт заражения существенно снижается...

Сценарий второй — вирус «прилетел» через обновление той или иной LoB-системы и здесь пока почти без шансов — скорее всего компьютер будет заражен, поскольку код выполняется от прав системы.

Но не будем расстраиваться. Мы потеряли один компьютер и далее все зависит исключительно от устойчивости ИТ-инфраструктуры в целом.

Дальнейший сценарий распространения вируса Petya проходит по нескольким направлениям:

  • Механизм, использующий уязвимость SMBv1 (EternalBlue/EternalRomance) на находящихся в одной подсети с зараженным ПК компьютерах,

  • Или механизм pass-the-hash/pass-the-ticket, используя имеющиеся на зараженном ПК сеансы пользователей.

Первый вариант распространения вируса на соседние ПК блокируется очень просто с Defense-in-Depth:

  • LAN — сегментирование и изоляция (VLAN) — совсем просто, особенно учитывая кол-во накупленных в компаниях Cisco и прочего оборудования, надо только сесть и чуть подумать, какой же трафик куда должен ходить между сегментам пользовательских ПК (многочисленных и разнесенных тоже) и серверами приложений (тоже сегментированных между собой по типам приложений и требуемого сетевого доступа). Мы не говорим даже об NDIS — даже без обнаружения вторжения (хотя если Cisco — так чего бы не активировать?) — сегменты сетей стали бы непреодолимым барьером для проникновения вируса вне группы ПК.

  • Хост — с его firewall, который, как ни странно, сейчас включается в Windows по умолчанию и только дурацкий ответ на вопрос — «хотите ли вы расшарить свои файлы в сети» — «да, хочу!» — портит всю картину. Ну вот зачем, зачем пользовательскому ПК вообще что-то публиковать в сети? Зачем все админы так любят отключать firewall? Легче работать? А не легче ли написать правила в групповых политиках... И все, даже в рамках одного сегмента сети — такие ПК c firewall будут защищены от посягательств зараженного ПК. А что насчет контроллеров домена и прочих файловых помоек — читай выше, обязательных обновлений и «бронирования» и тут никто не отменял.

  • ЛПП — и да, не забываем о персональной ответственности админов и сетевиков за каждый следующий поломаный по сети комп.

Второй вариант распространения вируса чуть сложнее — Petya использует для атаки на другие ПК в сети наличие открытых пользовательских сеансов/кэшей паролей на зараженном ПК, а учитывая парадигму того, что многие админы на ПК используют один и тот же пароль локального администратора или учетную запись администратора домена для работы на любом ПК компании — здесь для Petya широкое поле деятельности с использованием механизмов атак pth/ptt. Имея на руках администраторские пароли и открытые «всем ветрам» порты соседних ПК — Petya успешно копирует себя через административные шары (Admin$) и запускает удаленно свой код на атакуемой машине.

НО, если обратиться к Defense-in-Depth, то можно обнаружить, что:

  • Хост — рекомендовано использование технологий VBS и Device Guard для защиты от кражи идентити подобными способами. Но — VBS есть только в Windows 10 — Ok, но никто не мешает познакомиться с рекомендациями по защите хостов от Pass-the-hash/pass-the-ticket атак для Windows 7 и т.д. — ничего сложного, кроме опять же — использования рекомендованных шаблонов безопасности (их же можно использовать и для Windows 10 без VBS/DG) начиная с отключения кеширования идентити при входе и т.п.

  • Хост — простейшая гигиена аутентификации, связанная с использованием уникальных администраторских паролей на каждой рабочей станции/сервере — утилита Local Administrator Password Solution (LAPS) — избавит от головной боли «по запоминанию» каждого пароля, а далее — более сложные процедуры гигиены для администраторов, которые говорят, что для выполнения определенных действий на ПК должны быть использованы определенные учетные записи, не обладающие полнотой прав на уровне всей сети (а что, никто не в курсе, что с доменным админом ходить по рабочим станциям категорически запрещено?).

  • Плюс — уже упомянутые выше механизмы обнаружения вторжения — тот же Defender ATP или Microsoft ATA («заточенный» как раз на обнаружение атак pth/ptt) и, безусловно — firewall и сегментирование сетей для того, чтобы завладевший теми или иными учетными записями вирус не смог подключиться к соседям.

  • ЛПП — а здесь уже может «прилететь» и админу компании в целом, если окажется, что его учетная запись «гуляет» почему-то по рабочим местам пользователей или используется на ПК совместно с такими гуляющими админами.

ВСЕ! Было «охренеть как сложно», мы потратили от силы 3 рабочих дня (24 часов и 24×75=1800евро денег высококвалифицированного специалиста) из предоставленных 43 дней с предыдущей атаки для того, чтобы защититься от разрушительного действия вируса типа Petya.

Да, тут некоторые коллеги в комментах дискутировали насчет того, что «нельзя так просто взять и поделить сеть на подсети пользователей и банкоматов — есть моменты администрирования и удобства работы» — но, в любом случае, у CIO было еще минимуму 3-5 дней на подумать, а потом решить, что удобство работы перед угрозой полномасштабной вирусной атаки — отходит на второй план. В общем — даже не думали и не сделали НИЧЕГО.

Наши потери от Petya после принятых общих мер — мы потеряли, скорее всего, все машины, которые заразились путем приезда «обновления от MEDoc» (хотя, при использовании IDS типа Defender ATP — и эти потери могут быть сведены к минимуму), мы потеряли 10% от тех машин, которые получили «письма счастья», а компания — потеряла работавших на них сотрудников. ВСЕ! Никакой эпидемии, никаких отключившихся касс и банкоматов (!!!), никаких тысяч часов на восстановление ИТ-инфраструктуры. Осталось восстановить требуемые данные из бекапов (или вообще ничего не восстанавливать, кроме ОС на ПК — если ИТ-инфраструктура сделана правильно и все хранится и бекапится централизованно, к тому же — в облако).

Так что это было, добродии?! Почему Petya гулял по украинским сетям, вынося всех и вся (и не надо рассказывать, что «в Европе/России тоже пострадали», «это была спланированная атака на Украину») — как не лень, некомпетентность и пофигизм CIO попавших под раздачу организаций и полный пофигизм Microsoft Ukraine по отношению к наземной угрозе?!

Ах да, Microsoft и «облака наше все»... Сейчас пойдут разговоры о том, что если бы «все было в Azure», то ничего бы не было. Было бы — с тем же результатом — ваши виртуальные машины в Azure были бы в той же ситуации — локальная сеть, открытые порты и т.п. — потому что в гибридной инфраструктуре облачная часть IaaS по безопасности ну никак не отличается от наземной по необходимости настроек.

Таким же образом, через обновления, Petya успешно бы пролез и на виртуалки в Azure, дальше бы пошел гулять по виртуальным сетям Azure (которые вы бы не поделили на сегменты, не изолировали, не использовали firewall на каждой), а потом и через Site-to-Site VPN залез бы и на наземные ПК пользователей... Или наоборот — с тем же результатом в такой незащищенной от угрозы изнутри «обланой» инфраструктуре.

А то было бы и хуже — учитывая умение Petya считывать учетные записи админов и зная безалаберность этих админов — Petya.Cloud (с модулем работы в облаке — дописать в код пару строчек) давно бы уже имел административные права на ваши подписки в облаках и делал бы там все, что заблагорассудится, кидая вас еще и на деньги — например — поднимал бы виртуалки для майнинга или ботсетей в вашей облачной подписке, за которые вы бы потом платили по 100К-300К уе/мес.

И даже использование облачного Microsoft Office 365, который вроде как SaaS и его инфраструктура защищается Microsoft — при такой дырявой инфраструктуре на местах — не спасет — с тем же успехом вирус добирается до админского аккаунта O365, используя воровство учетных записей — и дальше подписка O365 уже «не ваша».

Вам об этом не сказали Microsoft, Google, Amazon — все, кто продает «облака»? Так это, им же продать надо, а не решать ваши проблемы — а все проблемы облаков — находятся «на местах», а туда особо уже и не продашь — значит, и инвестировать в наземные части заказчиков не стоит ни копейки — даже тренингами и семинарами...

И всем — приготовиться — это была только следующая волна, ждем следующей, как только ребята найдут следующий механизм «заброски» и инфильтрации вируса в корпоративные сети. И этот вирус также не будет обнаруживаться антивирусами по сигнатурам и будет эксплуатировать свежие уязвимости сетей и незакрытые механизмы типа Pass-the-hash/Pass-the-ticket. И вот просто «перенести все в облака» вам не поможет, а подписка на облачные Microsoft ATA/Defender ATP в дополнение к описаным выше мерам — вполне.

И небольшой ликбез для тех, кому интересно (некоторые доклады – почти годичной давности):

Вирус Petya и правильная комплексная защита от него и подобных следующих вирусов