Вирус-вымогатель WannaCrypt – ситуация и меры безопасности

Ransom:Win32.WannaCrypt и методы противодействия

300300

С 12 мая 2017 года в СМИ стали появляться сообщения о новом и достаточно серьёзном зловреде.

Его называют по разному – и WanaCrypt0r 2.0, и WannaCrypt, и WCry. В более-менее стандартизированной номенклатуре – Ransom:Win32.WannaCrypt.

Кратко про ситуацию и что предпринимать.

Причина заражения

В семействе ОС Windows обмен файлами в LAN-сетях практически полностью реализуется протоколом SMB. Данный протокол разработан фирмой IBM (в сотрудничестве с 3Com) в 1983 году, используется в OS/2, и оттуда уходит в состав сетевого стека Microsoft, более известного как “семейство протоколов и сервисов LAN Manager”.

Протокол SMBv1 живёт достаточно долго. Работает плохо и неэффективно – но не потому что он плохой, а потому что предназначался для универсальных задач – от сетевой печати до общего доступа к COM-портам – и поверх любых сетевых протоколов. То есть должен был он работать в следующей схеме:

  • Какой-то протокол сетевого уровня (IP, IPX, AppleTalk)
  • NetBIOS поверх транспортного протокола (в варианте IP – NetBT, NetBIOS Transport over TCP, используется 139й порт)
  • Запросы и ответы SMBv1

Всё это было снабжено большим количеством команд, долгими и многофазными согласованиями каждой мелочи, поэтому КПД протокола был откровенно не самым лучшим. Тянется это с Windows for Workgroups 3.11 до Windows XP / Server 2003.

В Windows 2000 Microsoft проводит первичную оптимизацию и запускает SMBv1 поверх “чистого” IP, снижая задачи прослойки NetBIOS и уменьшая overhead протоколов, чем улучшает соотношение “заголовки / данные”. Вы знаете этот вариант по открытому порту TCP 445. Но этот вариант работает параллельно с классическим, не являясь его заменой.

Начиная с ядра NT 6.0, где Microsoft первый раз серьёзно переписывает сетевой стек, появляется протокол SMBv2.

Он значительно упрощается в части количества команд, в него также начинает добавляться новый функционал. Данный процесс продолжается и после, выходят версии 2.1, 3.0, 3.0.2 и в текущих Windows Server 2016 / Windows 10 – SMB 3.1.1.

Microsoft двигает стандарт и дальше, публикуя свои открытые спецификации – их потом реализуют в сторонних продуктах типа Samba (пять лет по открытой документации реализовывали стандарт) и Apple (Apple делает свою копию Microsoft’овского SMBv2).

В результате на текущий момент на борту ОС от Microsoft обычно работает полный зоопарк – три версии SMB поверх двух сетевых портов (TCP 139 и TCP 445).

И вот в самой старой, ещё IBM’овской реализации SMBv1, была обнаружена уязвимость.

Матчасть здорового человека

Патч закрытия критической уязвимости в SMBv1 был выпущен 14 марта 2017 года, то есть 2 месяца назад: MS17-010.

Ссылки на патчи для различных ОС есть здесь: KB 4013389.

Какова реальная картинка с заражением?

Вот здесь можно посмотреть на ситуацию с заражением Ransom:Win32.WannaCrypt в реальном масштабе времени.

Как выглядит заражение?

Например вот так выглядит заражённый информационный стенд Сбербанка:

Как выглядит вирус?

По сообщениям ряда СМИ, вирус-вымогатель, работающий на международном уровне, требующий денег с различных организаций и государств, выглядит так:

Но нет точной уверенности, что он может что-то зашифровать.

Если всё плохо

Утилита, которая достанет ключ, при помощи которого можно расшифровать файлы – https://github.com/gentilkiwi/wanakiwi. Важная особенность – компьютер не должен быть ни разу перезагружен после появления окна WannaCry. Если это произошло, то утилита не поможет.

Штатные меры, которые не были использованы

Протокол SMBv1 может быть выключен полностью во всех сетях, где нет ОС младше Windows Vista и устаревших принтеров.

Как минимум, возможен переход на Direct SMB даже в случае Windows 2000 / XP / 2003, что уже упростит работу и снизит потенциальный attack surface.

Выключить SMBv1 можно и через PowerShell:

Set-SmbServerConfiguration -EnableSMB1Protocol $false

И через реестр:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters, параметр SMB1 типа DWORD = 0

Можно также удалить сам сервис, отвечающий за SMBv1 (да, за него лично отвечает отдельный от SMBv2 сервис):

sc.exe config lanmanworkstation depend=bowser/mrxsmb20/nsi

sc.exe config mrxsmb10 start=disabled

Все указанные методы не приведут к потере функционала передачи файлов поверх сети – они лишь отключат супер-древний (34 года ему) вариант протокола SMB.

Действия на современных ОС

Если у вас Windows Server 2012 R2 / Windows 8.1 / старше, то дело ещё проще – вы можете целиком удалить компонент “старые возможности LAN Manager”, в который входит сервис Computer Browser и SMBv1. Это делается штатно, через удаление компонентов ОС.

Действия на устаревших ОС

Microsoft уже не поддерживает ОС линейки NT 5.x – Windows Server 2003 и Windows XP. Однако для такого случая выпущены патчи для Windows Server 2003, Windows XP SP2 и SP3.

Предотвращение подобных проблем как класса

Можно также, в случае отсутствия необходимости открывать кому-то снаружи доступ к файлам на локальной системе, отключить на сетевом интерфейсе привязку к сервису File and Printer sharing, просто сняв галку:

Ну или вообще удалить этот сервис, если нет задачи предоставлять доступ к ресурсам данной системы по протоколу SMB (обычно для домашних компьютеров это самый практичный выход).

Хочу детальнее разобраться в этом вопросе

Желание разово и хорошо прояснить для себя функционирование одного из основных LAN-протоколов – весьма правильное. SMB не рассматривается в упрощённых авторизованных курсах Microsoft, но мы на данную тему проводим вебинар по детальному изучению протокола SMB, на котором можно будет разобраться во всех тонкостях – от SMBv1 до современного SMB 3.1.1. Для обладателей нашей клубной карты – подписки Knowledge Assurance – посещение этого вебинара бесплатно.

Вопросы

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

Ещё больший вопрос – как за 2 месяца корпоративные системы, обладающие букетом возможностей обновления – от Windows Update и WSUS до Microsoft System Center с его ConfMgr – не установили патч, закрывающий критическую уязвимость включённого по умолчанию протокола. Какая квалификация у персонала, который это администрирует, у архитекторов, которые делали и подписывали дизайн сети с такой системой управления обновлениями, у безопасников, которые должны отслеживать текущую ситуацию с используемыми компонентами и их безопасностью.

Самый большой вопрос – как уязвимость в протоколе прожила 30 с лишним лет, хотя исходник был и у IBM, и у Microsoft. Вроде как у этих фирм коллективы тестировщиков и разработчиков разные. Исходный код SMBv1 был отдан IBM в опенсорсный проект Samba и прошёл аудит – и там тоже находят и тоже в марте 2017 года оставшиеся с тех же лет уязвимости. То есть вся эта уйма людей, адресно занятых аудитом, что со стороны корпораций США, что со стороны “американского сертифицированного открытого ПО” – все они удивительно синхронно просмотрели одни и те же древние уязвимости в SMBv1. Товарищ Сноуден имеет на этот счёт весьма закономерные вопросы и заготовленные ответы – которые после официального заявления президента фирмы Microsoft, в котором он в явном виде указывает на причину происходящего, выглядят ещё более удручающе.

Впрочем, все эти вопросы – риторические.

  • Sergey Gruzdov

    “Можно также удалить сам сервис” – вот здесь написать, что остановить службу будет очень неплохо после ее отключения

  • Гость

    Это опасно для win7? В реестре не нашел указанного параметра, как и в удалении компонентов.

  • Я исходил из того, как первичный подход – убрать возможность атаки, оставляя функциональность.

    А так, в принципе, можно:

    – Зайти на настройку сетевого интерфейса и снять галку с “File and printer sharing”
    – И вообще удалить этот компонент
    – Или найти в services.msc и там застопить и отключить сервис Server
    – Или закрыть на advfw порты TCP 139/445

    Просто предполагается, что люди всё ж оставили его, SMB, включённым, потому что используют.

  • В реестре любой Windows 7 точно есть LanmanServer – даже если сервис штатно удалили, ключ останется. Так что, возможно, как-то не так искали.

  • Dmitriy Razbornov

    Вопросы, вопросы. А МС год назад умоляла отключать уже SMB1

    https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/

    Но зачем, и кому это надо. Опять одни вопросы без ответов.

  • только bowser/mrxsmb20/nsi

  • Максим Бондаренко

    Интересно, что после удаления из компонентов Win 10 Поддержка общего доступа к файлам SMB 1.0/CIFS перестал работать доступ к файловому серверу на NAS-е, а если компонент не удалять, а выключить только SMBv1 через powershell, то все работает как надо.

  • Да, исправил – а то “привычное” слово вбил на бегу.

  • Ну его сейчас если и оставлять, то выборочно для старых принтеров – у которых разово реализацию SMBv1 сделали когда-то и не модифицировали, ибо “работает и хлеб не просит”. Просто мало кто вообще что-то выборочно сейчас включает-выключает – это ж надо разбираться, изучать. Поэтому и ситуация – даже откидывая то, что критический патч вышел 2 месяца назад, у кучи народа включено неиспользуемое.

  • Alexander Litvin

    Отключил на работе smb1 – отвалилась аутентификация СЭД. Хотя тип оной внутри СЭД указан как NTLM2. Погромисты пишут на суперпоследних фреймворках, и используют smb1 проверки учётных данных…

  • Джонни

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

    А теперь взмах черной волшебной палочкой – оказалось по SMBv1 работает сканирование в папку у МФУшек в офисе. как минимум Kyocera, Samsung модели последних годов. Думаю у других вендоров та же история.

    Так что думайте дважды прежде чем следовать советам “выключи нафиг оно тебе не нужно” и тд

  • Да, от количества “Первым делом выключите и удалите всё сразу целиком” действительно, некая грусть. Табуны любителей простых решений класса “взять всё и поделить” прекрасны своей непосредственностью. Грустно также то, что матчасть большинство знает настолько, что даже не в курсе, как иначе поступать-то.

    Я уж не говорю про то, что для них открытие – что можно раздельно управлять SMB для клиента и для сервера. Что это вообще разные компоненты. Что можно отключить неиспользуемый SMBv1 “на вход”, чтобы по нему не могли подключиться к данной рабочей станции – и, следовательно, уйдут проблемы уязвимости – и оставить возможность работы с SMBv1 “наружу”, т.е. подключения с данной рабочей станции к хостам, с которыми надо согласовать SMBv1.

  • А там удаляется целый букет “старых” сервисов, включая согласовалку классического LAN Manager’а. Вполне возможен сценарий, что NAS пытается согласовывать по “классике” – например, на нём самба древняя – и в результате получается отбой.

    Так что да, удалять – это крайний случай, а так надо в общем-то патчить да закрывать от входящих подключений лишних. Сам по себе сценарий-то “к рабочей станции кто-то по SMB подключается, инициируя на неё сессию” – он нуждается в тщательной проработке. Если на машинах нет общих папок и принтеров – на них такое оставлять и не нужно.

  • volk

    я так понимаю что бы намотать эту заразу из лана наружу должен торчать порт 139 или 445 ?

  • Достаточно и внутри LAN’а чтобы торчал, чтобы при этом не было патчей, был включен SMBv1 (хотя в варианте Petya.A выбор методов заражения побогаче, чем у WannaCry) и не был никак защищён.

    Говоря проще, при дефолтной конфигурации и отсутствии patch management.