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

Мы привыкли, что киберпреступность пытается обмануть, взломать и обворовать несчастных пользователей интернета. Но время всегда заставляет людей двигаться дальше, за новыми результатами и новой прибылью. То же самое происходит и в отношении плохих парней. Можно еще с десяток лет строить ботнеты, воровать номера 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 и лично  Александру Матросову за их работу в московской лаборатории. Также спасибо лаборатории Касперского и их блогу, в котором Александр Гостев делился своими мыслями и красивыми картами :). Ну и спасибо тебе, мой читатель, переваривший этот важный материал.

http://www.xakep.ru