3 декабря 2010 г.

Война 2.0. S01E01. Stuxnet. P03. Welcome to Matrix 2.0

Я долго боролся со своей креативной сущностью по поводу того, как назвать третий пост эпизода. Хотелось продолжить в рифму «-логия» («Хронология», «Конспирология»...) и назвать пост «Технология» - тем более, что это название было бы вполне в тему. Но в итоге пост получил то название, которое получил. Помните трилогию брата и сестры братьев Вачовски? Так вот – вирус Stuxnet делает реальной кинематографическую Матрицу и помещает в эту Матрицу программируемый логический контроллер фирмы Siemens. Кстати, за этот художественный образ (контроллер в Матрице) я благодарю ЖЖ-френда malaya_zemlya.

Пойдем по порядку.
В первом посте эпизода я писал, что основной анализ программного кода вируса был выполнен экспертами Symantec. Паралелльно с ними свое собственное расследование вел немецкий специалист в области компьютерной безопасности Ральф Лангнер. Правда, если Symantec публиковал свои сообщения чуть ли не в режиме реального времени с середины июля, Лангнер оттянул момент начала публикаций в своем блоге до сентября (первый пост – 13.09.2010). Но именно Лангнер первым высказал предположение, что целью атаки является иранская атомная программа. Точнее, сначала он только утверждал, что вирус нацелен на конкретную «точечную» цель, но не уточнял, какую именно. Конкретно об Иране он начал упоминать только через неделю, и то поначалу делал это в многочисленных интервью для СМИ, а не у себя в блоге (в общем, чувак пиарился по полной).
Однако, вплоть до середины ноября у экспертов не было уверенности в том, какой же именно из физических объектов является главной мишенью – сама ли АЭС в Бушере или завод по обогащению урана в Натанзе. Первыми про центрифуги в Натанзе (правда, без конкретных географических названий и точных указаний на вид оборудования) написали все-таки аналитики Symantec. Лангнер подтвердил их основные выводы, однако, посчитал анализ Symantec неполным. Дело в том, что в коде Stuxnet были обнаружены две «цифровые боеголовки» (digital warhead) (кстати, авторство этого красивого термина принадлежит именно Лангнеру, аналитики Symantec предпочитали термин «полезная нагрузка» - «payload»), и анализ Symantec относился только к одной из них.

Первая «боеголовка» была нацелена на контроллеры S7-315-2 (именно они используются при управлении центрифугами), а вторая – на контроллеры S7-417. Чем именно могут управлять контроллеры второго типа, аналитикам Symantec было неясно; к тому же, код «боеголовки 417» был намного больше по размеру (порядка 20 КБ) и сложнее, чем код «боеголовки 315». Возможно, именно из-за недостатка знаний в области устройств промышленной автоматики, люди из Symantec не смогли проанализировать вторую «боеголовку» до конца, ограничившись только построением диаграммы вызовов всех подпрограмм внутри нее и обратив внимание на тот факт, что в коде используются операции ввода-вывода с отображением в оперативной памяти (memory-mapped I/O). Относительно «боеголовки 417» в анализе Symantec было написано, что, скорее всего, этот код не полностью протестирован разработчиками вируса или вообще не дописан – и поэтому он неработоспособен в реальных условиях. Лангнер же с ними категорически не согласился, и в целой серии своих постов показал, что именно «боеголовка 417» несет основную угрозу реального «Большого Ба-Бах!». Правда, речь все-таки шла не о взрыве ядерного реактора...

Впервые Р.Лангнер упоминает о коде, атакующем контроллер S7-417, в своем посте от 11 ноября 2010, комментируя (точнее, критикуя) официальную презентацию Siemens относительно Stuxnet, появившуюся неделей раньше. Причем, называет этот код «вызывающим большое беспокойство». Отношение Siemens к угрозе, которую несет Stuxnet, вызывает резкую критику Лангнера (привожу без перевода - надеюсь, что и так все понятно; жирный шрифт мой):
«I also don’t want to believe that this should be all that Siemens can do. The technical detail they provide tells me that their technical understanding of Stuxnet is minimal, that they did not use their resources, which are much bigger than ours and Symantec’s combined, and that they are deliberately ignoring published and verified lab results from independent researchers. I don’t think that this puts them in a position that would allow them to educate the public on the threat, or to tell customers that they probably didn’t do all they could or should have done.»

Через 2 дня Лангнер публикует 2 поста, в одном из которых подтверждает, что целью атаки «боеголовки 315» является блок приводов газовых центрифуг. А вот второй пост – сенсация! Для непосвященных его название выглядит почти как шифровка – «Potential 417 target: K-1000-60/3000-3». Итак, потенциальной целью «боеголовки 417» является нечто, обозначенное последовательностью цифр «K-1000-60/3000-3». Не буду долго интриговать – за этим кодом скрывается паровая турбина номинальной мощностью 1000 МВт, т.е. главный компонент турбогенераторной установки 1-ой очереди Бушерской АЭС! Кстати, число 3000, стоящее после дроби, означает число оборотов ротора турбины в минуту, т.е. 50 оборотов в секунду. А выглядит этот ротор примерно вот так (на фото – только часть ротора, по некоторым данным, конструкция в Бушере достигает в длину более 40 метров):


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

Как рассуждает Лангнер?
Известно, что турбина в Бушере - это уже названная выше модель K-1000-60/3000-3, произведенная российским концерном «Силовые машины» (кстати, владельцем 25% акций «Силмашин» является – сюрпри-и-и-из – компания Siemens). Точно такая же турбина, стоящая на АЭС «Белене» в Болгарии, управляется именно контроллерами Siemens. Так что, скорее всего, и бушерская турбина также управляется сименсовскими контроллерами (вообще, достаточно странно выглядело бы, если бы Siemens поставил на оборудование, произведенное на предприятии, совладельцем которого он является, контроллеры кого-то из конкурентов).

Говоря о возможном сценарии катастрофы, Лангнер вспоминает эксперимент, проведенный в США в 2007 году и получивший известность как «Aurora vulnerability» (я планирую написать об этом эксперименте в одном из следующих эпизодов «Войны 2.0»). В ходе того эксперимента (см. видео) спецслужбы США продемонстрировали, к каким последствиям может привести хакерская атака на компьютерное оборудование, управляющее энергетической установкой.


Так вот, по сравнению с возможной катастрофой в Бушере, «Аврора» выглядит просто детской игрушкой (хотя там было все по взрослому – и даже разрушили настояший дизель-генератор стоимостью в 1 млн долларов).

Для того, чтобы разрушить турбину, атакующим нужно либо разогнать ее выше предельно допустимой скорости вращения, сняв с нее нагрузку (генератор) при максимальном давлении пара, либо удержать в «окне» критических оборотов, вызвав сильные вибрации. Конечно, это возможно сделать только в отсутствие внешней системы безопасности турбины (TPS – turbine protection system); есть ли она на бушерской турбине, Лангнер не знает. В то же время, в современных установках TPS обычно интегрирована в систему управления турбиной (TCS - turbine control system). И если допустить, что обе упомянутые системы интегрированы на базе контроллеров S7-417(F)H – то вот она, потенциальная цель атаки Stuxnet в Бушере.

Еще через пару дней появляются новые посты Лангнера, в которых он характеризует атаку «боеголовки 417» как относящуюся к типу «Man-In-The-Middle» - хотя я бы назвал ее, скорее, «Malware-In-The-Middle». Суть атаки заключается в том, что вредносный код внедряется в легитимную программную логику контроллера, перехватывает входные и выходные потоки данных и может манипулировать этими потоками. Понятно? Думаю, пока не очень :). Попробую объяснить на картинках из постов Лангнера – и без лишних технических сложностей.

Для начала постараюсь пояснить один существенный технический момент – и постараюсь при этом не сильно наврать. Программируемые контроллеры, управляя промышленным оборудованием, не делают это напрямую, а действуют через исполнительные механизмы (актуаторы), которые передают/получают сигналы в/от контроллер(а) путем записи/чтения информации из специальных регистров (ячеек памяти) контроллера. Т.е., когда актуатор передает сигнал контроллеру, он фактически записывает некое числовое значение в некую ячейку памяти контроллера; точно так же – запись некоего числового значения в некую (другую) ячейку памяти контроллера фактически означает передачу сигнала актуатору. Это и называется вводом-выводом с отображением в оперативной памяти (memory-mapped I/O), о котором я уже упоминал выше. Когда речь идет о сложном процессе управления, говорят, что в памяти контроллера присутствуют образы процессов ввода-вывода (process images). Причем, есть отдельный образ процесса ввода и отдельный образ процесса вывода. И есть внутренняя программная логика контроллера, которая анализирует образ процесса ввода (Input Process Image) и производит необходимые модификации в образе процесса вывода (Output Process Image)  – тем самым, собственно, и осуществляя управление.

Вот так выглядит – сильно упрощенно – диаграмма нормального функционирования контроллера. На ней изображено все то, что я выше описал словами. Обратите внимание на толстые белые стрелки – они показывают НОРМАЛЬНУЮ последовательность передачи информации внутри контроллера.


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


И наконец – картина активного поведения «боеголовки». Честно говоря, на этой картинке не хватает пары белых стрелок, идущих к/от коду вируса – но не я ее рисовал, так что попробуем обойтись без них.


Итак, что происходит, когда «боеголовка» начинает действовать? В контроллер поступает информация о реальном состоянии объекта управления (турбины, центрифуги, насоса – чего угодно...), которая уже может указывать на то, что физический объект ведет себя «как-то не так» - увеличились/уменьшились обороты, повысилось/понизилось давление и т.п. Но эта информация не попадает в образ процесса ввода – ее перехватывает код «боеголовки» и сохраняет в своей памяти. А вместо реальной информации в образ процесса ввода передается сделанный ранее «слепок» правильной картины поведения объекта – и этот же «слепок» из образа процесса ввода попадает в блок программной логики контроллера. Т.е., контроллер уже не находится в реальном мире, он существует в Матрице, созданной для него вирусом – и продолжает считать, что все идет нормально. При этом контроллер убеждает в нормальности всего происходящего человека-оператора, сидящего за монитором пульта управления и наблюдающего, например, вот такую картинку:


Все, что должно светиться зеленым светом - светится зеленым, все, что должно вращаться – вращается, как положено. А наружу – к объекту управления (которым теперь управляет «боеголовка», а не легитимный код контроллера) – поступает информация, сформированная вирусом...

The Matrix (2.0) Has You…

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

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