11 декабря 2010 г.

Война 2.0. S01E01. Stuxnet. P05. Профайлинг нападающего

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

И аналитики Symantec, и Р.Лангнер практически с самого начала утверждали, что вирус такого уровня, как Stuxnet, невозможно создать в любительских условиях, «на коленке». Над вирусом работала команда – высоко квалифицированная, хорошо оснащенная технически и не стесненная в финансовых средствах. И, скорее всего, команда, пользовавшаяся поддержкой государственных структур. В качестве стран наиболее вероятного происхождения Stuxnet чаще всего назывались Израиль и США – и этим версиям, вроде бы, было достаточно конспирологических подтверждений (см. мой пост на тему Stuxnet-конспирологии). Но... Не слишком ли явные следы оставлены в коде вируса для вычисления возможных авторов? Можно ли поверить, что люди, до тонкостей проработавшие код «цифровых боеголовок», просто забыли убрать из загрузочных модулей следы сборки проекта Myrtus?

Р.Лангнер решил проанализировать код вируса более глубоко – и прежде всего, в тех его частях, которые нацелены на работу внутри программируемых логических контроллеров. Дело в том, что Windows-ориентированные части кода Stuxnet практически ничего не говорят о его авторах - кроме того, что с финансированием у разработчиков все было хорошо (3 уязвимости «0-day» и 2 цифровых сертификата таки стоят денег...). А вот код для PLC способен привести к гораздо более серьезным выводам. Лангнер называет этот код Myrtus Control System Unit (CSU) и выделяет в нем три больших блока – CSU-GEN, CSU-315 и CSU-417.

Первый блок (CSU-GEN) предназначен для эксплуатации общих возможностей программных продуктов Siemens (WinCC, Simatic Manager, S7). Основная задача этого кода – доставка до места назначения (в программную логику контроллеров) «цифровых боеголовок» CSU-315 и CSU-417 и обеспечение их срабатывания.
При разработке CSU-GEN были задействованы следующие знания:
  1. Дефолтный пароль базы данных WinCC (это был первый эксплойт, нацеленный на систему промышленной автоматизации, выявленный при анализе кода Stuxnet). Хотя этот пароль и не был широко «засвечен», в сообществе разработчиков, имеющих дело с продуктами Siemens, он, конечно, был известен. Так что, факт знания пароля ничего нам не дает для установления авторов вируса.
  2. Детальные знания по структуре проекта Step7 (они использовались, чтобы заставить WinCC исполнить вредоносный код). Такие знания крайне сложно получить путем обратного инжиниринга (reverse engineering), т.е. анализом декомпилированного кода.
  3. Детальные знания по структуре проекта WinCC. Также маловероятно, что они были получены обратным инжинирингом.
  4. Функциональные знания по динамически загружаемой библиотеке s7otbxdx.dll, используемой WinCC и Simatic Manager. Достаточно просто получить обратным инжинирингом, при условии, что вы обладаете хорошими знаниями по указанным продуктам и у вас есть подходящая тестовая среда.
  5. Знания по API-вызовам (с параметрами) библиотеки s7otbxdx.dll. Как с любой DLL, выявить экспортируемые функции несложно. А вот понять поведение этих недокументированных функций – задача совершенно другого порядка. И самое сложное – установить правильные параметры вызовов; надежное решение этой задачи путем обратного инжиниринга очень затруднено.
  6. Встраивание кода в начало операционного блока (OB) программной логики. Это наиболее яркий аспект Stuxnet, и ничего подобного раньше не встречалось. Поэтому обратный инжиниринг здесь просто не работает – необходимо очень хорошее знание продукта, чтобы придумать и реализовать такой эксплойт.
  7. Отключение программных «датчиков тревоги» (в данном случае – мониторинг времени цикла исполняемого кода) путем записи соответствующей команды в соответствующий операционный блок. В принципе, несложно.
  8. Перехват системных функций S7. Снова – обратный инжиниринг невозможен, т.к. ничего подобного раньше не было. Только очень немногие люди с хорошим знанием Step7 знали, что это можно сделать.
  9. Интерпретация системного блока данных (SDB) – Stuxnet проверяет содержимое SDB в ходе своей процедуры «дактилоскопирования» (т.е. выявления контроллера, подлежащего заражению). Это неопубликованная информация, и ее крайне сложно установить путем обратного инжиниринга.

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

Единственное назначение CSU-GEN – проложить дорогу для «боеголовок» CSU-315 и CSU-417, которые содержат атакующий код, способный разрушить цель. И неверны утверждения тех, кто говорит, что Stuxnet атакует управляющие промышленные системы или, что еще ошибочнее, SCADA-системы. Stuxnet атакует физические процессы. CSU-315 и CSU-417 содержат логику, нацеленную именно на это. И, конечно же, обе «боеголовки» демонстрируют крайне высокий уровень инсайдерских знаний:
  • об оригинальном проекте Step7, работающем на атакуемых контроллерах;
  • о точных логических и физических конфигурациях атакуемой установки;
  • о точных характеристиках атакуемых процессов, включая уязвимости физических процессов;
  • о том, как задействовать уязвимости физических процессов с использованием имеющейся системы управления.
Другими словами, парни, разработавшие Stuxnet – это не студенты-недоучки, разбирающиеся только в компьютерных играх и хакинге, а спецы с основательными инженерными и естественнонаучными знаниями. Сравнение блоков CSU-315 и CSU-417 выявляет существенную разницу в структуре и исполняемом коде – это значит, что каждый блок писался отдельной командой, состоящей, как минимум, из двух человек. Таким образом, весь проект Myrtus CSU разрабатывали, по крайней мере, 6 человек, РЕАЛЬНО знающих, с чем они имеют дело, и обладающих многолетним опытом в своих областях. Не будем забывать, что надежность была главной проблемой при разработке Stuxnet. У разработчиков не было возможности проводить тесты на реальном объекте – им оставалось рассчитывать только на свою квалификацию, и что они ничего не упустили из виду. У них все должно было получиться с первой попытки.

И поскольку вычислить специалистов, обладающих столь обширными инсайдерскими знаниями, не так уж и сложно, команда разработчиков Stuxnet просто обязана была работать под «крышей» разведывательной или военной организации. Посмотрим же, насколько хорошо в вышеописанный профиль нападающих укладываются характеристики 5+1+1 стран (с последним +1 относящимся к Израилю):

  • Израиль. Лучший источник разведывательных данных по иранской ядерной программе (Моссад). Израильтяне также хороши в компьютерной безопасности и стандартном хакинге, но никогда не были замечены в глубоких знаниях по промышленным системам управления, которые необходимы для разработки «цифровых боеголовок» Stuxnet.
  • США. Очень хорошие возможности в компьютерной безопасности и хакинге; кроме того, владеют технологиями создания обогатительных центрифуг (ORNL – Окриджская Национальная Лаборатория), а также знают, как взрывать генераторы («Aurora Vulnerability»). Чего им не хватает – необходимых знаний по продуктам автоматизации от Siemens.
  • Германия. Безусловно, лучший источник знаний в области промышленной автоматики; имеют также экспертизу в сфере обогащения урана. При этом – средние возможности в области компьютерной безопасности и хакинга.
  • Россия. Экспертиза в сфере ядерных технологий и генерации энергии сопоставима с американской – этого более, чем достаточно, для разработки Stuxnet. Интересно, что знания российских специалистов по части немецких продуктов промышленной автоматизации гораздо лучше, чем многие могут себе представить. Если у вас хватит терпения и знаний, чтобы продраться через достаточно нудные инженерные публикации, вы обнаружите, что они даже умеют интегрировать TPS (Turbine Protection System) и TCS (Turbine Control System).
  • Китай, Франция, Великобритания. Недостаточно информации, чтобы провести адекватный анализ возможностей этих стран в части разработки Stuxnet.
Мой (А.Б.) заключительный комментарий. Вообще-то, анализ Лангнера весьма недвусмысленно указывает на Россию, как страну, способную в одиночку, без коалиций с кем-либо, разработать Stuxnet и организовать его атаку в Иране – что выглядит достаточно правдоподобно, если вспомнить о степени присутствия Siemens в России.
Если же это не Россия, то любая другая жизнеспособная комбинация обязана включать участие Германии (Siemens!) – например, Германия+США или Германия+Израиль.
Вообще-то, насколько мне известно, продукция Siemens присутствует и в США, что делает США еще одним кандидатом на роль нападающего-одиночки. Да и сравнение отношений Ирана с Россией и США все-таки дает больше оснований думать именно о США, как авторе и исполнителе атаки Stuxnet.

Хотя, конечно, правды мы никогда не узнаем...

Комментариев нет:

Отправить комментарий