SCADA под прицелом: анализ защищенности АСУ ТП

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

Насколько дыра широка?

Важные инфраструктурные объекты тщательно охраняются, поэтому пройти туда или
пронести на территорию что-то стороннее - крайне затруднительно. В связи с этим
наибольший интерес представляет возможность удаленной атаки. На сегодняшний день
каждое государство определяет для себя список наиболее важных узлов. И хотя этот
список составляет государственную тайну, абсолютно очевидно его содержание:
объекты электроэнергетики, ядерной и атомной отраслей, сектор транспортировки
углеводородов, нефтехимия, стратегические военные сооружения. Естественно,
многие из этих объектов подвергаются процессу автоматизации с использованием
информационных технологий, что в комплексе представляет собой автоматизированную
систему управления технологическими процессами (АСУ ТП). В состав типовой АСУ ТП
входят три основных компонента: система диспетчеризации (SCADA), телеметрическая
подсистема, инфраструктура коммуникации на базе доступных промышленных
протоколов передачи данных. Зачастую в зарубежной литературе термин "АСУ ТП"
опускают, говоря только о системах SCADA, но важно понимать, что диспетчеризация
не позволяет интерактивно управлять процессом всей системы управления.

 

Наиболее интересные инциденты

Русская компания НТЦ "Станкоинформзащита", занимающаяся безопасностью АСУ
ТП, опубликовала аналитический отчет с анализом инцидентов информационной
безопасности АСУ ТП зарубежных государств за 2008-2010 годы. Наиболее
интересные из них:

• 7 марта 2008 года, Блок 2 ядерной станции "Hatch" (штат Джорджиа,
  США), внештатное
  аварийное выключение на 48 часов после установки обновления
  программного обеспечения (похожий инцидент случился в 2006 году на
  ядерной станции "Browns Ferry" из-за нештатного сбоя программируемого
  логического контроллера при получении аномального выходного сетевого
  трафика из производственной сети);
• Май 2008 года, Корпорация Tennessee Valley Authority (TVA) (в
  ведомости данной энергетической корпорации находятся 11 угольных
  станций, 8 ТЭС, 3 ядерных станции, 29 ГЭС США), проверка регуляторов (GAO,
  HHS) выявила
  порядка 2000 уязвимостей разной степени критичности. Среди брешей в
  безопасности были выявлены сегменты производственной сети, подключенные
  к интернету, множественные уязвимости прикладного ПО, отсутствие
  обновлений безопасности, ошибки в проектировании архитектуры сети и
  каналов обмена данными;
• 26 августа 2008 года, Центр полетного планирования Федерального
  управления гражданской авиации США, диспетчерские трех десятков
  американских аэропортов выведены из строя в результате компьютерного
  сбоя в центре полетного планирования.

Инструментальная подготовка

Какой инструментарий потребуется для анализа безопасности АСУ ТП, учитывая,
что дело придется иметь с системами диспетчеризации и управления
технологическими процессами? Здесь придется работать на стыке известных тебе
технологий и отдельных специальных решений, поскольку 60% известных АСУ ТП и
систем SCADA развертывается на традиционных платформах (Windows, Linux). При
необходимости используют платформы реального времени (жесткого, мягкого), такие
как QNX, которые гарантируют исполнение той или иной операции с заданным
интервалом времени в условиях СРВ (системы реального времени), хотя большее
применение они находят в продукции военного назначения (БПЛА, бортовое
управление). На сегодняшний день известно не так много узкоспециализированных
программных средств анализа защищенности АСУ ТП / SCADA:

• ПК "SCADA-Аудитор" (отечественный сканер для анализа защищенности
  технологических сетей, АСУ ТП/SCADA);
• Teenable Nessus (содержит несколько модулей проверок систем SCADA и ряда
  программируемых логических контроллеров в коммерческой версии);
• Rapid7 Metasploit Project (там совсем все грустно: в разделе "exploits/scada/"
  всего лишь несколько пар узкоориентированных сплоитов).

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

 

Как находить зараженные Stuxnet’ом узлы

В состав NMAP’a новой версии (5.51) вошел интересный плагин, написанный
на языке программирования LUA для NMAP Scripting Engine, имя ему -
stuxnet-detect. Исследовать узел на предмет наличия червя Stuxnet через
SMB-сессию очень просто:

nmap --script stuxnet-detect -p 445 <host>

Кроме этого, для обнаружения зараженных узлов можно пользоваться
сканером, созданным специалистами компании Trend Micro. Взять его можно либо
на нашем DVD, либо на сайте
компании. Как же работают эти сканеры, и как вообще работает Stuxnet?

Stuxnet регистрирует свой RPC-сервер для осуществления внутреннего и
внешнего взаимодействия с зараженными узлами в качестве отдельной ноды.
Функционал RPC-сервера настроен на выдачу (проверку) версии червя, а также
на выполнение функции обновления (загрузку новых экземпляров).
Соответствующие RPC-вызовы могут быть исполнены от центра управления этим
"промышленным" ботнетом. Центр дает команду на проверку версии (0x00), в
случае ее "старости" осуществляется вызов функции обновления (0x04).
Предварительно проверяется доступность службы SMB-over-TCP (TCP 445), после
чего эксплуатируются уязвимости, заложенные в данную версию Stuxnet
(например, MS10-061), осуществляется биндинг к характерному именованному
пайпу через DCE/RPC ("//browser" - в большинстве случаев), поиск UUID и его
последующий анализ. Красиво!

Вторым способом является поиск "вгруженного" в планировщики задач
зловредного кода Stuxnet. На основе данной методики и работает сканер Trend
Micro.

Типовые угрозы

Рассмотрим наглядно, какие угрозы влечет за собой типовая топология
технологической сети. В ней выделяют (в зависимости от природы технологических
процессов) три зоны: корпоративную (не имеет никакого отношения к управлению,
занимается исключительно бизнес-процессами), исполнительную (звено, где
непосредственно выполняются технологические процессы - например,
перерабатывается аммиак или осуществляется управление движением нефти) и зону
диспетчеризации (там сидят операторы АСУ ТП, которые могут повлиять на ход
выполнения технологического процесса).

1. Исполнительные устройства и подсистема телеметрирования.

Очень часто электронная компонентная база используемых устройств не позволяет
внедрить туда столь популярные технологии как IPSec или SSL, организовать VPN.
Тем не менее, доступ к этим девайсам нужен всегда. Более того, некоторые из них
выступают в качестве устройств сбора информации (телеметрии) о показателях
выполнения технологического процесса с датчиков и так далее. В них же могут
накапливаться сообщения о тревогах и авариях, что весьма критично. В связи с
этим очень важно назначать им публично доступный IP-адрес, что, к сожалению,
встречается сплошь и рядом. В некоторых ситуациях избежать этого невозможно при
допущениях ошибок проектировки сети. Например, современные промышленные
контроллеры могут быть соединены напрямую или через модем. При подключении через
модем их часто объединяют с GPRS/GSM-модемами, что по умолчанию наделяет
устройство IP-адресом мобильного оператора. При такой конфигурации они очень
уязвимы для атак извне. Специализированными утилитами и методами злоумышленник
может выявить подобные девайсы и натворить много плохих дел. Сами исполнительные
устройства, как правило, подключаются по последовательному интерфейсу (RS-232 /
RS-485) к MODBUS-серверу, а непосредственно MODBUS-сервер имеет управление по
TCP/IP через канал Ethernet/Industrial Ethernet с операторами.

 

Как MODBUS передает данные

В сетях MODBUS может быть использован один из двух способов передачи
данных: ASCII или RTU. Пользователь выбирает необходимый режим вместе с
другими параметрами (скорость передачи, режим паритета и так далее) во время
конфигурации каждого контроллера. При использовании ASCII-режима каждый байт
сообщения передается как два ASCII-символа. Главное преимущество данного
способа - время между передачей символов может быть до секунды без
возникновения ошибок при передаче. В ASCII-режиме сообщение начинается с
"двоеточия" (:, ASCII 3A hex) и заканчивается последовательностью "возврат
кареткиперевод строки" (CRLF, ASCII 0D и 0A hex). Допустимые символы для
передачи - это шестнадцатиричные цифры 0-9, A-F. Монитор сетевого устройства
в сети непрерывно отслеживает символ "двоеточие". Когда он принят, каждое
устройство декодирует следующее поле сообщения (поле адреса) и так далее.

2. Парк АРМ-операторов и системы SCADA.

Эти товарищи находятся в самом сложном положении, поскольку вопросы режима
среди них зачастую не соблюдаются. Вторая проблема - к ним часто допускают
иностранных специалистов, которые могут иметь не самые благие намерения.
Например, в истории червя Stuxnet на атомной станции в Бушере ключевую роль
сыграл инженер-инсайдер обслуживающего подразделения, который пронес на станцию
USB-носитель с вредоносным софтом. Сколько таких товарищей бродит по атомным
станциям в мире - остается вопросом. Операторы имеют возможность подключаться к
системе SCADA, как правило, с разным уровнем привилегий, планировать и внедрять
новые проекты, изменять существующие. Несмотря на множество уязвимостей в ПО
систем диспетчеризации, основной угрозой по-прежнему остается инсайдерство.

3. Корпоративная зона (BAN - Business Area Network).

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

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

Обозначив для себя диапазон сети, было решено выявить в нем пограничный шлюз
доступа. Искать долго не пришлось, это был Cisco Router and Security Device
Manager на маршрутизаторе Cisco 7301, более известный в народе как CISCO SDM.
Мне требовалось получить к нему доступ, по возможности изучить его
конфигурационный файл, обозначить для себя диапазоны внутренних сетей и выявить
там самое ценное.

Как ни странно, на самом шлюзе было целых две уязвимости:

• обход авторизации level 15;
• интегрированная учетная запись "cisco" (шлюз был только введен в
  эксплуатацию, так что сами администраторы еще не успели там ничего наладить
  с безопасностью).

Получив доступ, первым делом я вбил команду "show running config", чтобы
просмотреть конфигурационный файл. Как и ожидалось, внутри я обнаружил
захэшированные пароли. Изучив подсети, я сразу взялся за анализ сети прямо с
пограничного маршрутизатора. Естественно, эту задачу можно было решить двумя
способами:

• активно, с использованием скриптов TCL, которые бы бегали по узлам сети
  и осуществляли подключения на известные порты для сбора информации о
  сервисах;
• пассивно, здесь все немного сложнее, потому что только современные
  прошивки оборудования CISCO содержат Cisco IOS Embedded Packet Capture (EPC)
  - весьма полезную вещь, выступающую в качестве пакетного анализатора для
  диагностики сети.

Чтобы не наделать много шума, я пошел по второму пути, для чего мне
требовалось превратить шлюз в один большой сниффер, как раз с помощью EPC:

# включение режима EXEC
enable
# задаем буфер захвата с именем "pktrace1", размером 256 байт,
# с ограничением по максимальному размеру элемента буфера в
# 100 байт
monitor capture buffer pktrace1 size 256 max-size 100 circular
# задаем точку захвата, в качестве интерфейса мониторинга
# используем FastEthernet, в отношении как входящего трафика,
# так и исходящего
monitor capture point ip cef ipceffa0/1 fastEthernet-type0/1 both
# ассоциируем точку захвата с буфером
monitor capture point associate ipceffa0/1 pktrace1
# организация старта захвата
monitor capture point start ipceffa0/1
# вывод захваченной информации
show monitor capture buffer pktrace1dump

Обнаружив в трафике строки с указанием порта TCP 502, мне многое стало ясно,
потому что данный порт характерен для протокола MODBUS TCP. По маршрутизации
пакетов и адресу назначения можно было судить о том, где находится центр
управления. Собственно, таким способом можно вести вполне полноценную пассивную
сетевую разведку с маршрутизирующего оборудования, в частности - с любого
маршрутизатора CISCO, имеющего актуальную версию прошивки. Запустив сканер, я
понял, что там уже кто-то продуктивно побывал до меня: несколько узлов было
заражено червем, каждый из которых образно говорил мне: "Мы ждем своего
хозяина". Следует отметить интересный факт, что настройки по умолчанию многих
систем SCADA рекомендуют организовать анонимный доступ к DCOM ОС Microsoft
Windows, что порождает огромные бреши в безопасности. Также многие из
промышленных протоколов по ряду причин (сложность реализации на оборудовании
телеметрии, увеличение объема трафика) не поддерживают шифрование. Тем временем,
хэши, взятые из конфигурации SDM, расшифровывались. На этот раз вместо родного
CISCO "secret 7" в качестве алгоритма хэширования применялся MD5.

 

Пароли на роутерах CISCO

Иногда вместо ожидаемых "secret 7"-хэшей на CISCO-роутерах встречаются "secret
5" (CISCO type "5" passwords). Процесс получения пароля по хешу отличен от
взлома "secret 7", который можно расшифровать с помощью известных скриптов,
Cain and Abel и многих других программ. Пример того, как выглядят и хранятся
хэши паролей:

username jbash enable secret 5 $1$iUjJ$cDZ03KKGh7mHfX2RSbDqP.
username jbash password 7 07362E590E1B1C041B1E124C0A2F2E206832752E1A01134D

Нетрудно заметить, что алгоритм хэширования аналогичен md5, поэтому в
данном случае можно прибегнуть к помощи современных программных средств,
умеющих восстанавливать такие типы хэшей, а именно Passwords Pro, John The
Ripper, EGB и так далее, чтобы провести атаку по словарю. Конструктивно это
выглядит так:

$1$FKKk$t2NOQP.vSScMbwJWERNU0/ (type "5"),
где "FKKk" - соль (salt)

Самодельный брутфорсер мог бы выглядеть примерно так:

openssl passwd -1 -salt FKKk cisco

На месте "cisco" - перебирающиеся слова из словаря с паролями.

Система диспетчеризации

Расшифровав пароли, я начал изучать периметр сети. Некоторые из хостов имели
алиасы внешних IP-адресов, что позволяло мне подключиться к ним извне. Получив
доступ к одной из рабочих станций в пределах сети, я начал проводить активный
поиск всех устройств АСУ ТП с помощью софтины "SCADA-Аудитор". Любой другой
сканер показал бы мне доступные TCP 502-порты, характерные для MODBUS, но
установить нативное соединение и узнать оттуда служебную информацию - этого они,
конечно, не умеют. С использованием "SCADA-Аудитора" требовалось выявить в
диапазонах сетей те узлы, которые содержат признаки размещения систем
диспетчеризации или элементов телеметрии. Сделать это можно по целому ряду
признаков, если знаешь, что искать. Одним из возможных критериев для поиска
является вывод опроса SNMP-протокола в случае его доступности. Так же в пределах
самой сети, по административной панели и встроенному web-серверу, я нашел саму
SCADA - это была Каскад-АСУ. Изучив систему, я выявил целый ряд уязвимостей:

1) Неавторизированное чтение директории с проектом технологического процесса:
KASKAD/Web_Clnt.dll/ShowPage?Web_Clnt.ini. Из него же можно узнать полный путь
до базы:

Project="C:\Program
Files\Kaskad\Projects\KVisionDemoProject\kaskad.kpr"

2) Раскрытие пользовательской информации:

KASKAD/Web_Clnt.dll/ShowPage?../../../ Projects/KVisionDemoProject/Configurator/Events.ini

3) Чтение пароля и юзера к базе данных

UserName=sysdba
Password=ЬРВЕФГЪФИ (пароль извлекается XOR’ом на 0x1B)

4) Раскрытие служебной информации:

KASKAD/Web_Clnt.dll/ShowPage?../../../ Projects/KVisionDemoProject/Configurator/Stations.ini

ClntIPAdr1=127.0.01
Порт = 3050

5) Отказ в обслуживании с помощью записи в порт TCP 3050 следующей строки
(уязвимость характерна для СУБД Firebird):

\x00\x00\x00\x35\x4a\x4a\x4a\x4a\x4a\x4a\x4a\x4a\x4a\x4a\x4a\x4a\x4a

6) Неавторизированное добавление пользователя SCADA:

INSERT INTO USERLIST (USERNAME, USERPASSW, NAME, GRPNAME, FULLNAME,
FLAGS, FLAGS_, ALLOWTIME, REGISTERTIME, LASTENTERTIME, LASTPWDCHANGETIME,
PWDKEEPPERIOD, STATIONS, DROPTIMEOUT, PSPRDACCESS, PSPWRACCESS, PSPRDACCESS_,
PSPWRACCESS_) VALUES ('ITD', '745F87A6B56BACAB', 'itd', 'Пользователи', Юрий
Каминков', 3, null, null, '2002-01-30 13:11:36.0', '2002-01-30 13:11:36.0',
'2002-01-30 13:11:36.0', 0, null, null, null, null, null, null);

Не MODBUS’ом единым!

Обнаружив узлы телеметрии, управляемые по MODBUS, я взялся за работу.
Поковырявшись в протоколе, можно выявить много интересных особенностей.

1) Например, существует возможность перевести устройства PLC в режим listen
only. Данный режим позволяет отключить PLC от обработки и исполнения команд на
некоторый интервал времени, что может привести к останову системы в целом.
Согласно архитектуре MODBUS только одно устройство (Master) может инициировать
передачу (сделать запрос). Другие устройства (Slave) передают запрашиваемые
главным устройством данные или производят запрашиваемые действия. Типичное
главное устройство включает в себя ведущий (HOST) процессор и панели
программирования. Типичное подчиненное устройство - программируемый контроллер.
Перевод PLC-устройств в режим listen only реализуется с помощью рассылки
специальных пакетов либо конкретному slave-устройству, либо сразу всем
подчиненным устройствам с помощью широковещательного запроса. Slave-устройство
возвращает сообщение в ответ на запрос, адресуемый именно ему. При
широковещательных запросах ответы не возвращаются.

2) Другой характерной ошибкой (правда, никак не связанной с реализацией
протокола) является некорректная обработка входных данных на стороне устройства,
работающего с промышленным протоколом. Разработчики зачастую забывают
контролировать предельные размеры пакетов, что приводит к крешу и нарушает
работу устройства. Например, драйвер Modbus SCADAPack известного пакета
ClearSCADA, способен обрабатывать пакеты от 60 до 260 байт. Что будет с девайсом,
если заслать ему пакеты подлиннее, можешь проверить сам :).

3) Схожей проблемой являются ошибки проектирования штатных служб и сервисов,
используемых на контроллерах. Начиная с интегрированных web-серверов и
заканчивая ftp-демонами. Скажем, известный Appweb Embedded Web Server валится с
помощью флуда, генерируемого утилитой Apache Benchmarking Tool (ab), пример:

ab -n 1000 -c 50 http://xxx.xxx.xxx.xxx/index.html

-n - суммарное количество запросов
-c - количество одновременных запросов

4) Поделюсь с тобой одной хитрой уловкой. Если отключить один из контроллеров
телеметрии MODBUS, у Администратора начнется паника, и он точно полезет туда,
чтобы перезагрузить контроллер, а потом зайдет в админку, чтобы посмотреть все
настройки. Здесь-то можно и перехватить его пароль, отсниффав трафик в сегменте
ЛВС с помощью ARP-спуфинга.

У нас проблема

Беда существующей нормативной базы очевидна: нет ясных и явных требований к
столь критически важным системам как АСУ ТП и, в частности, SCADA. Недавно наши
специалисты обнаружили типовое ТЗ, нашедшее свою реализацию в одной из
автоматизированных информационно-измерительных систем коммерческого учета
электроэнергии (АИИС КУЭ). Требования по защите от несанкционированного доступа,
согласно РД ФСТЭК РФ, которые учитывались разработчиками, - 2Б. К сожалению,
данный класс не учитывает множество вопросов, таких как сигнализация попыток
нарушения защиты, контроль доступа субъектов к программам, узлам сети, каналам
связи, и много чему еще. Проблема!

 

Links

Многие факты проникновения хакеров в подобные системы так и остаются за
кадром. То, что вырвалось на публику, попадает в специальные базы, одна из
них - RISI:
securityincidents.org.