Вирус Petya и правильная комплексная защита от него и подобных следующих вирусов, которая должна была быть в каждой ИТ-инфраструктуре–то, что не сделали вовремя украинские CIO


А теперь послушайте страшную историю о том, что вы действительно должны были сделать, дорогие мои CIO – так сказать, «техническое алаверды» тому потоку негатива от обиженных CIO и “патриотов”, который последовал за публикацией предыдущего поста «про Petya» в ФБТрагедия и фарс–украинские CIO и 150долларовые админы,российский след и “атака ФСБ”,тотальный факап Microsoft Ukraine–все, что вам надо знать о причинах вчерашней вирусной атаки в Украине

Особенно «возбудились» почему-то некоторые «патриотические» деятели с дежурной фразой – «ты не живешь в Украине, какое право ты имеешь об этом писать!» – спасибо, повеселили, значит, мой «толстый» троллинг зацепил за живое…

Ладно, оставим лирику – все равно я всякое разное в ФБ комментах покилял, а самых ярых – заблокировал.

А мы посмотрим пошагово, чего же такого «провтыкали» CIO, что могло бы предотвратить эпидемию в украинских компаниях «на корню», что есть в базовых рекомендациях Defense-in-Depth https://msdn.microsoft.com/en-us/library/cc767969.aspx и реализовать которые не является большой проблемой. Напомню, требования Defense-in-Depth (DiD) достаточно простые и предусматривают реализацию тех или иных сервисов защиты на всех уровнях ИТ-инфраструктуры.

Уровень

Технологии

Данных

ACL/шифрование/классификация данных с RMS

Приложений

SDL, антивирусы, «бронирование» приложений и сервисов, App/Device Guard

Хостов

«Бронирование» ОС, аутентификация, управление обновлениями, FW, защита от вторжения (IDS), VBS, Device Guard

LAN

Сегментирование и изоляция (VLAN), шифрование (IPSec), защита от вторжения (NIDS)

Периметр

FW, контроль доступа, App FW, NAP

Физическая безопасность

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

Люди, политики, процедуры

Документирование, тренинги, предупреждения и уведомления, наказания…

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

Итак, начнем с первичного заражения. В данной эпидемии рассматривается 2 основных сценария – проникновение через почтовые сообщения в виде вложения к письму и через систему обновлений MEDoc, так называемую атаку «software supply chain attacks», когда взламывается поставщик ПО. Подробно, кто еще не прочитал – «разбор полетов» можете посмотреть здесь – https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/

При этом в первом сценарии запущенный пользователем из почты исполнимый файл атакует ОС через уязвимости 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) – http://aka.ms/pth – начиная с отключения кеширования идентити при входе и т.п.
  • Хост – простейшая гигиена аутентификации, связанная с использованием уникальных администраторских паролей на каждой рабочей станции/сервере – утилита Local Administrator Password Solution (LAPS) – http://aka.ms/laps – избавит от головной боли «по запоминанию» каждого пароля, а далее – более сложные процедуры гигиены для администраторов, которые говорят, что для выполнения определенных действий на ПК должны быть использованы определенные учетные записи, не обладающие полнотой прав на уровне всей сети – https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material (а что, никто не в курсе, что с доменным админом ходить по рабочим станциям категорически запрещено?).
  • Плюс – уже упомянутые выше механизмы обнаружения вторжения – тот же Defender ATP или Microsoft ATA («заточенный» как раз на обнаружение атак pth/ptt) и, безусловно – firewall и сегментирование сетей для того, чтобы завладевший теми или иными учетными записями вирус не смог подключиться к соседям.
  • ЛПП – а здесь уже может “прилететь” и админу компании в целом, если окажется, что его учетная запись “гуляет” почему-то по рабочим местам пользователей или используется на ПК совместно с такими гуляющими админами.

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

UPD 1: По просьбам комментаторов и просто друзей в Facebook и прочих социальных сетях – записал практическое видео с примером реальной лабы по заражению домена Petya.C с правильно настроенными политиками безопасности согласно требованиям Defense-in-Depth для защиты от современных типов угроз (типа того же Pass-the-Hash/Pass-tht-Ticket, которые использовал Petya.C) – при явном заражении одного ПК – влияние вируса на остальную лабу – нулевое:


СофТы: закрываем уязвимости ИТ-инфраструктуры от современных атак (типа Petya – pth/ptt)

Да, тут некоторые коллеги в комментах дискутировали насчет того, что «нельзя так просто взять и поделить сеть на подсети пользователей и банкоматов – есть моменты администрирования и удобства работы» – но, в любом случае, у 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 в дополнение к описаным выше мерам – вполне.

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


Webcast: как противостоять современным информационным атакам при помощи Microsoft Advanced Threat Analytics – про Pass-the-hash/pass-the-ticket атаки 


О безопасности гибридной/облачной ИТ-инфраструктуры в Azure IaaS

 

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

 

Подписывайтесь на мой Youtube канал iWalker2000 – для подписки просто кликните сюда

 

И еще – немного ссылок про ИТ-карьеру и тренинги/обучающие материалы для ИТ-профессионалов и Системных Администраторов:

 

Также, по просьбам посетителей – меня найти можно (добавляйтесь в друзья и подписчики):

 

Эмиграция для ИТ-профессионалов в Европу! Оформление ВНЖ в Словакии, возможность работы со всеми странами ЕС, открытие фирм, ЧП с соответствующими видами деятельности, оформление документов для членов семьи. Быстро, качественно, дешево и абсолютно легально ВНЖ в Словакии. www.slovakiago.com
Не упустите свой шанс жить и работать в Евросоюзе!

10 thoughts on “Вирус Petya и правильная комплексная защита от него и подобных следующих вирусов, которая должна была быть в каждой ИТ-инфраструктуре–то, что не сделали вовремя украинские CIO

  1. Игорь, спасибо за пост. Полностью согласен. Инфраструктуру нужно планировать. Изначально. Под все сервисы, которые будут эксплуатироваться. Я не слышал, чтобы были зам.директора ИТ по архитектуре инфраструктуры или по информационной безопасности. Менталитет? Авось? О гигиене рук или почистить утром и вечером зубы никто не забывает. Это вбили в советских детсадах и школе. А вот оставить трудовое место в чистоте… Или прочесть гайд 😛 Пожалуй, не все и не везде любят. И х-о-т-я-т! А правильная организация мыслей и обычная интуиция для многих просто недоступна 🙂 Удивило во всем этом бардаке то, что Майкрософт в официальном блоге ссылается на украинскую киберполицию… Это даже не смешно… А о том, что будут еще атаки – зачем об этом думать? 😀 Ведь мы героизмом по устранению инцидента покроем свою халатность 😀 Везет дуракам и дорогам – и те и другие существуют в своей выдуманной реальности

    Подобається

  2. А тем временем: “Держспецзв’язку попереджає про ймовірність повторної кібератаки” (www.pravda.com.ua/news/2017/07/6/7148924/) и дает новые рекомендации…
    плакать хочется…

    Подобається

  3. Доброе время суток, Игорь.
    Я не раз сталкивался с ситуацией, что пользователи подключают сетевые папки с документами как локальные диски: это удобно для работы и обмена данными и не надо запоминать путь к папке/ресурсу на системе хранения.
    Естественно, вирус “нахозяйничал” и там, но данные были спасены благодаря наличию теневого копирования и бекапов.
    Есть ли у МС рекомендации по защите подобных ресурсов? Я пошерстил течнет, но ничего годного не нашел. Хотя, по логике, защиту целостности данных должна обеспечивать система хранения данных.

    Подобається

Залишити коментар