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

 

Промышленный шпионаж

Мы привыкли, что киберпреступность пытается обмануть, взломать и обворовать
несчастных пользователей интернета. Но время всегда заставляет людей двигаться
дальше, за новыми результатами и новой прибылью. То же самое происходит и в
отношении плохих парней. Можно еще с десяток лет строить ботнеты, воровать
номера CC, но ведь есть еще огромная неизведанная ниша — промышленность, ее
технологии, секреты и ценные данные. Именно с ней и произошел инцидент в разгар
лета — беспрецедентная атака на промышленные системы
SCADA
, Supervisory Control And
Data Acquisition, что переводится как "Диспетчерское Управление и Сбор Данных"
(по-нашему это аналог АСУ ТП — Автоматизированная Система Управления
Технологическим Процессом). Такие системы контролируют процессы на производстве,
нефтяных вышках, атомных электростанциях, газопроводах и т.д. Естественно, такие
комплексы имеют свои базы данных, и та информация, что в этих базах, бесценна.
Именно на эту информацию и нацелилась свежая вредоносная программа, получившая
имя
Stuxnet
.

 

Stuxnet

Первыми обнаружили нового зверя братья-славяне из Белоруссии, а именно —
антивирусная контора VirusBlokAda. 17 июня ими было найдено тело виря, но лишь к
10 июля они выпустили пресс-релиз (объясняя это тем, что им было необходимо
уведомить компании, чье имя было в ходе дела "опорочено", и изучить экземпляр).
Компании эти достаточно известны — Microsoft и Realtek. Специалисты VirusBlokAda
зафиксировали использование червем 0day-уязвимости при обработке файлов ярлыков
(.lnk), и поэтому в дело оказались вмешаны Microsoft (о самой уязвимости
поговорим позже). А вот при чем тут Realtek? Дело в том, что устанавливаемые
червем драйвера имели действующий сертификат, заверенный Verisign и выданный на
имя Realtek. Такой оборот дела сильно усложняет процесс детектирования
вредоносного контента различными системами обнаружения и предотвращения
вторжения на уровне хоста (HIPS, антируткиты), так как такие системы безгранично
доверяют сертификатам, не обращая внимания на суть дела. Я вполне уверен, что
доверенный сертификат сильно продлил жизнь "малваре", прежде, чем ее обнаружили.
Как бы то ни было, после пресс-релиза белорусов, другие антивирусные компании
так же подключились к исследованию, как новой уязвимости, с помощью которой
распространялся червь, так и к боевой нагрузке.

 

Распространение

Механизм размножения червя, казалось бы, не особо-то и оригинальный — через
USB-флешки. Но autorun.inf тут уже ни при чем. В дело вступает новая уязвимость,
которая позволяет загружать произвольную .DLL-библиотеку, как только флешка
будет вставлена, и пользователь откроет ее содержимое. Дело в том, что на флешке
лежит .DLL-файл с вредоносным кодом (ну, фактически расширение, в случае с
червем, — .TMP) и .LNK-файл. Файл с расширением .LNK является обычным ярлыком.
Но в нашей ситуации ярлык не совсем обычный. При отображении ярлычка в
стандартной оболочке или Total Commander автоматически выполнится лежащий рядом
.DLL-файл со всеми вытекающими отсюда последствиями! Как такое могло произойти?

Как известно, ярлык указывает на исполняемый файл и при двойном щелчке
вызывает его. Но тут все без щелчков, да и .DLL-файл так не выполнить. Если
рассмотреть ярлык в HEX-редакторе, можно увидеть, что в его середине указан путь
до нашей .DLL. Кроме того, это не обычный ярлычок, а ярлычок на элемент панели
управления! Эта-то деталь все и объясняет. Любой элемент панели управления — .CPL-
апплет. Но CPL — это, по сути, простая .DLL, поэтому ярлык для панели управления
особый, он как бы понимает, что имеет дело с .DLL. Кроме того, такой ярлык
пытается ВЫТАЩИТЬ иконку из.DLL, чтобы отобразить ее в проводнике. Но для того,
чтобы вытащить иконку, надо подгрузить библиотеку. Что, собственно, оболочка и
делает с помощью вызова LoadLibraryW().

Справедливости ради стоит отметить, что вызов этой функции автоматически
влечет за собой выполнение функции DllMain() из подгружаемой библиотеки.
Поэтому, если такой ярлычок будет указывать не на .CPL-апплет, а на злую
библиотеку со злым кодом  (в функции DllMain()), то код выполнится
АВТОМАТИЧЕСКИ при просмотре иконки ярлыка. Кроме того, эту уязвимость можно
использовать и с помощью .PIF-ярлыков.

 

Боевая нагрузка

Кроме интересного метода распространения удивила и боевая нагрузка — никаких
ботнетов, краж банковских паролей, номеров CC. Все оказалось куда масштабнее.
Уязвимость .LNK провоцирует загрузку скрытого файла с именем ~wtr4141.tmp,
лежащего рядом с ярлыком. Файл этот исполняемый, но маленький (всего 25 Кб). Как
отметили специалисты из Symantec, очень важно на первых порах скрыть свое
присутствие, пока система еще не заражена. С учетом специфики 0day-уязвимости,
которая действует, как только пользователь увидит иконки, сработает и
~wtr4141.tmp, который в первую очередь вешает перехваты системных вызовов в
kernel32.dll. Перехватываемые вызовы:

  • FindFirstFileW
  • FindNextFileW
  • FindFirstFileExW

Хуки также вешаются и на некоторые функции из ntdll.dll:

  • NtQueryDirectoryFile
  • ZwQueryDirectoryFile

Все эти функции обрабатываются со следующей логикой — если файл начинается с
"~wtr" и заканчивается на ".tmp" (или на ".lnk"), то удалить его из
возвращенного оригинальной функцией значения, а затем вернуть, что осталось.
Другими словами, скрыть свое присутствие на диске. Поэтому пользователь просто
не увидит файлы на флешке. После этого ~wtr4141.tmp подгружает второй файл с
диска (~wtr4132.tmp). Делает он это не совсем стандартно, я бы даже сказал,
извращенно — установкой хуков в ntdll.dll на вызовы:

  • ZwMapViewOfSection
  • ZwCreateSection
  • ZwOpenFile
  • ZwCloseFile
  • ZwQueryAttributesFile
  • ZwQuerySection

Затем с помощью вызова LoadLibrary он пытается подгрузить несуществующий файл
со специальным именем, на это дело срабатывают ранее установленные хуки и грузят
второй файл, уже реально существующий — ~wtr4132.tmp, вернее, его
незакодированную часть, которая раскодирует вторую часть (по факту —
UPX-сжатие). Вторая часть представляет собой некие ресурсы, другие файлы,
которые вступают в дело после расшифровки и экспорта (аналогичным извращенным
методом с хуками на API функции).

Первым делом устанавливаются два драйвера — mrxcls.sys и mrxnet.sys (именно
из-за этих файлов червь получил такое название — Stuxnet). Устанавливаются они в
системную директорию, а функционал на них — руткит уровня ядра с той же логикой,
что и в первом файле. Это обеспечит защиту червя после перезагрузки и завершения
процесса ~wtr4141.tmp.

Драйвера эти, как уже было сказано, имеют легитимный сертификат Realtek,
поэтому их установка пройдет без проблем (на данный момент сертификат уже
отозван). Кроме руткита распаковываются файлы шаблона ярлыка и ~wtr4141.tmp для
организации заражения других USB-устройств. Потом экспортируется код, который
инъектится в системные процессы и добавляет в реестр вышеотмеченные .SYS-файлы
руткита (HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\MRxCls). Далее
раскодируются два .DLL-файла, которые заменяют существующие файлы системы SCADA
— Siemens Step 7.

Таким образом, все вызовы из системы SCADA переходят в поддельные библиотеки.
Там происходит "нужная" обработка, после чего вызовы передаются в оригинальные .DLL
(остальную часть функций вирь и вовсе эмулирует самостоятельно). Кроме всего
перечисленного, червь блокирует процессы антивирусов и пытается найти сервера
СУБД (MSSQL). Найдя таковые, он пробует выполнить вход с учетной записью
WinCCConnect и паролем по умолчанию — 2WSXcder. Это учетная запись от БД SCADA
типа Siemens Simatic WinCC. Как видно, червь заточен именно под продукт Siemens.
Если аутентификация прошла успешно, шпион выкачивает данные о процессах и прочую
секретную инфу. Кроме того, он не гнушается поискать в локальных файлах полезную
для шпионов информацию. Если удается обнаружить выход в интернет, то червь лезет
на один из командных серверов. Имена серваков такие:

  • mypremierfutbol.com
  • todaysfutbol.com

Туда червь и пытался достучаться и "что-то" слить в зашифрованном виде.
Ребята из Symantec разобрались и с этой задачей. Оказалось, что шифрование
представляет собой побайтовую операцию XOR с 31-битным ключом, который был
прошит в одной  из .DLL-библиотек. Ответ с сервера также приходит в
XOR-виде, правда, используется уже другой ключ из той же библиотеки. Троян
отсылает на сервер общую информацию о зараженной машине (версия винды, имя
компьютера, адреса сетевых интерфейсов, а также флаг наличия SCADA). В ответ от
командного центра могут приходить вызовы RPC для работы с файлами, создания
процессов, внедрения в процесс и загрузки новых библиотек и др.

 

Что это было?

Именно так… что же это было?! Простые блэкхаты не будут ввязываться в то, что
не принесет легких денег. Данные из SCADA-систем интересны лишь конкурентам.
Конкурентам в коммерческом или политическом планах. Если взглянуть на карту
распространения заразы (по данным лаборатории Касперского), то видно, что
эпицентр — Азия (а именно — Индия, Иран и Индонезия). Если взглянуть на
описанный функционал червя, то можно ужаснуться — контроль над .DLL и перехват
функций SCADA. Разве не круто — управлять индийской атомной электростанцией по
инету? Или проникнуть в иранскую ядерную программу? К тому же, мы имеем факт,
что драйвера руткита имеют легальный сертификат, который географически
принадлежит компании, базирующейся в той же зоне (в Тайланде)!

Этой историей занимаются не только антивирусные компании, но и
правительственные структуры (чтобы замести свои следы? :)). В результате
"захвата" указанных доменов и командных серверов удалось проанализировать
статистику стучащихся туда больных машин. В итоге данные Symantec практически
совпадают со сведениями Лаборатории Касперского — все те же страны. Кроме всего
этого уже подтвердились факты проникновения и в саму систему SCADA. Пока не так
много, около трех фактов (два из Германии и один из Ирана). Но ведь не все будут
публично говорить, что их поимели…

 

Что будет?

После всего случившегося, я думаю, возникнет неслабый интерес к безопасности
SCADA. До этого инцидента уже были и исследователи, и фирмы, которые
предупреждали о проблемах в безопасности и предлагали свои услуги, но этот
конкретный случай может помочь им очень неплохо заработать. Смею полагать, что
такая же модель червя годится и для ERP-систем, так как показанная схема
применима и для этой модели. ERP-системы отвечают за планирование и управление
бизнесом — деньгами, задачами, товарами и т.д., и т.п. (Я бы даже сказал, что
написать такого червя под ERP было бы легче, но раз была выбрана SCADA и регионы
Азии, то тут скорее попахивает политикой…). Так что все эти бизнес- и
промышленные системы еще ждут своих героев (привет Александру Полякову aka
sh2kerr). Но вот что касается .LNK-уязвимости, то, например, троянец Zeus уже
стал использовать ее для своего размножения. Кроме того, ребята из Rapid7
сделали эксплойт для Metasploit, который способен работать через HTTP с помощью
WebDav.

При этом шеллкод забивается в .DLL-файл, и ярлык его подгружает. Патча на
момент написания статьи еще не было, а угроза весьма существенная — тут все
антивирусные компании говорят, что они прекрасно детектируют виря по сигнатурам,
поэтому самое время обратить внимание, что сигнатуры — отстой. Сигнатура DLL нам
не так интересна, а вот сигнатура, по которой определяется, что данный ярлык —
эксплойт, определенно может хромать. Возьмем ярлык от публичного PoC
(suckme.lnk_) и отправим это чудо на virustotal.com. В итоге мы имеем 27
антивирусов, которые его обнаружили. Теперь откроем панель управления и создадим
пару ярлыков, один желательно от Java. Далее переименуем эти ярлыки через
консоль:

nopy Java.lnk Java.lnk_

Второй ярлык копируем аналогично первому. Теперь мы можем редактировать их в
HEX-редакторе. Обычно все ярлыки имеют указатель в виде Unicode-формата, но
Java-ярлык — нет. В итоге мы видим две ссылки на CPL-апплеты, причем для Java —
не в Unicode-виде. Меняем путь к CPL (DLL) на наш файл, удаляем посередине
лишние байты (fa ff ff ff 20) и сохраняем. Копируем обратно с расширением .LNK.
Итоги отправляем на virustotal.com. Для Unicode-ярлыка осталось 11 антивирусов,
для Java-ярлыка — 8, то есть 70% антивирусов перестали детектить эксплойт, и
среди этих антивирусов такие гиганты, как Symantec, Kaspersky, AVG, NOD32. Так
что антивирус тут — не панацея.

Это так… пять копеек от меня, чтобы там не расслаблялись, а вообще,
антивирусникам надо сказать спасибо за столь тщательную и интересную работу,
которую они проделали, чтобы помочь нам разобраться в этой угрозе. Спасибо Вам,
бойцам антивирусного фронта: AdBlokAda (первыми обнаружили и изучили), Symantec
(за подробный технический анализ в своем блоге), компании ESET и лично 
Александру Матросову за их работу в московской лаборатории. Также спасибо
лаборатории Касперского и их блогу, в котором Александр Гостев делился своими
мыслями и красивыми картами :). Ну и спасибо тебе, мой читатель, переваривший
этот важный материал.

1 комментарий

  1. Nitro

    30.06.2016 at 15:04

    Мощно вообще ….

Оставить мнение

Check Also

LUKS container vs Border Patrol Agent. Как уберечь свои данные, пересекая границу

Не секрет, что если ты собрался посетить такие страны как США или Великобританию то, прежд…