Анализирую прошивки контроллеров Schneider Electric
Введение
Schneider Electric — один из крупнейших производителей ПЛК, в ассортименте которого есть множество серий устройств, отличающихся ценой и возможностями: поддержкой протоколов, наличием специфических портов и т.д. Рассмотрю две серии устройств — Quantum и Modicon.
Немножко юмора)
Для анализа нам понадобятся: IDA Pro (именно Pro, потому что Free поддерживает только x86 архитектуру), любой HEX редактор (в целом хватит и встроенного в IDA), binwalk (я буду его запускать под WSL).
Из-за санкций скачать сами прошивки с сайта напрямую не дает, поэтому скачиваем через VPN, либо можно забрать с githib’а (https://github.com/OlegBezverhii/SchEl-firmware/).
Quantum
Старая серия контроллеров, поддержка прекращена (но критические обновления выпускаются), поэтому производитель предлагает обновляться на серию Modicon. Включает в себя следующие модули:
140 CPU: 31110, 43412U, 65150, 65160, 65260, 67160, 67261, 65860 — серии центральных модулей,
140 NOE: 77101, 77111 — модули ETHERNET-TCP/IP,
140 CRA: 31200, 93100 — адаптеры удаленного ввода/вывода по сети RIO (интересное решение, кто не знает погуглите),
различные модули ввода/вывода, блоки питания и так далее, которые физически не имеют прошивку.
Типовая корзина в сборе
Unity processor Modicon Quantum 140CPU650 Series
Единственное изображение внутренностей, которое смог найти
В среде Unity Pro (официальная утилита для программирования ПЛК от SE) при создании корзины так же указывается, что процессор серии 486 (80486) — отличаются только частотой разные модели.
Модуль NOE в разборе не нашел, но судя по постам в интернете, сделано на архитектуре PowerPC 860 (скорее всего производства Motorolla). Перейдем к внутренностям файлам, предоставляемые производителем.
140CPU67160__SV360.bin
И так, образ прошивки ЦПУ — видно, что используется система реального времени VxWorks (возможно с правки от SE, потому что во всех материалах они пишут, что используемая ОС — Unity OS). Образ пожат bzip2, имеет внутри себя ещё пожатые данные алгоритмом lzma. Я пробовал удалять header, подсовывал полученный файл binwalk’у и другим утилитам для распаковки, но распаковать так и не удалось. Неудача, но что поделать.
Прежде чем приняться смотреть файл прошивки NOE, я решил поискать старые уязвимости по данным модулям. И не прогадал — в старом CVE-2011–4859 была уязвимость с паролями по умолчанию. Плюс CVE в том, что иногда приводятся ссылки на ресурсы, где были выявленные эти уязвимости. И вот как раз среди них есть хорошая статья от Ruben Santamarta, который в 2011 году пытался «взломать CERN», которые как раз использовали модули NOE от SE. Сейчас статья не доступна на сайте, но web.arhive всё помнит (ссылка). Плюс я поискал по похожим вхождениям в google и наткнулся ещё на два азиатских сайта, в которых авторы в 2015 и 2018 годах пробовали повторить тоже самое. Я попробовал повторить и вот что у меня получилось.
Архив 140NOE77111 Exec V7.1.zip представляет из себя сборник файлов, загружаемых по ftp при обновлении в случае использования bat скрипта. В самом архиве много файлов для встроенного веб-интерфейса модуля, среди которых есть jar файлы — в одном из них как раз и прописан логин/пароль по умолчанию для соединения по FTP. Обновить прошивку модуля можно и рекомендуется производителем через OSLoader, используя готовый bin файл, расположенный по пути /osl/rohs (norohs). Он из себя представляет ZIP архив с аналогичным содержанием.
Содержимое bin файла.
По пути \FLASH0\wwwroot\conf\exec нас ждет уже нужный нам файл прошивки. Опять загоняем в binwalk и смотрим:
Распаковываю тем же binwalk’ом, перехожу в полученную папку и вновь смотрю на полученный результат:
Отлично, то что нужно.
Теперь по внутренностям содержимого файла уже можно увидеть, что перед нами та же самая VxWorks, только ничем не запакованная и если посмотреть на самую последнюю строчку, то можно увидеть таблицу символов, которая нам позже понадобится.
Полученный файл загружаем и IDA Pro со следующими параметрами:
При выборе начального адреса ROM и входного файла указываем 0×10000 (адрес не изменился, так как это связанно с архитектурой — по ссылкам выше есть описание, почему именно этот адрес)
Так как на сайте reversemode.com и веб-архиве нет нужного нам скрипта для восстановления наименования функций из отладочных символов, пришлось искать в интернете по названию — может у кого остался. Мне повезло и в одном из репозиториев лежал данный файл. Начальный адрес мы уже знаем от binwalk, теперь в hex редакторе найдем конец данной последовательности:
Начало последовательности
Конец последовательности
В скрипте указываем нужный нам диапазон, в IDA нажимаем ALT+F7 (либо через File → Script File…), выбираем наш файл и ждем выполнения:
Теперь список функций имеет осознанные имена
Функцию usrAppInit я не нашел (которая в старых версиях точно присутствовала), но это и не было целью. Теперь, зная синтаксис ассемблера для PowerPC можно посмотреть, как работает и ведет себя система, но это уже тема для другого разговора.
Modicon
Новая серия контроллеров построена уже на архитектуре ARM — это относится как и к центральным контроллерам, так и к модулям TCP/IP и МЭК.
Меня привлекла больше именно эта линейка, потому что в 2020 году компания Armis нашла очень крупную уязвимость — ModiPwn. Прекрасное объяснение того, что в текущих условиях Modbus TCP соединение ничем не защищено. Оставлю дополнительный материал на русском от Касперского — https://ics-cert.kaspersky.ru/publications/reports/2022/09/29/the-secrets-of-schneider-electrics-umas-protocol/ И вот в статье от Armis зацепился глаз на следующие слова:
The hardcoded secret used by this mechanism can be observed in the unencrypted UMAS traffic, or located by reverse engineering a Modicon PLC firmware.
Я было подумал — ну раз у них вышло, то и у меня должно получиться, но оказалось, что нет)
Все файлы ldx представляют из себя Zip архивы, поэтому просто извлекаем.
BMXNOR0200H_SV1.70_IR24.ldx
Загружаем в binwalk:
BMEH584040
BMEH584040
BMXNOR0200H
Образы CPU u-boot uImage распаковать я не смог -dumpimage не видит разделов для извлечения (единственный русскоязычный туториал есть на linux.org.ru). Образ NOR на вид выглядит несжатым, но опыта дизассемблирования ARM у меня нет. Но, судя по стартовым адресу ЦПУ в 10000 я предполагаю, что у и модулей тоже самое.
Интересно так же посмотреть и на содержимое папок прошивки NOR. Папка J9 указывает популярную в узких кругах реализацию JVM — OpenJ9 (Eclipse OpenJ9 или известная до этого под именем IBM J9). Так же в jar файлах можно увидеть упоминание нашумевшего в своё время Log4j — видимо применяется для записи логов на карту памяти. Как минимум, уже есть две уязвимые точки при использовании java — не думаю, что производитель так часто обновляет модули системного ПО.
Заключение.
Почему я решил написать эту небольшую статью. На это есть несколько причин.
Отсутствие статей в русскоязычном сегменте. Понимаю, что тема слишком специфичная, но хотелось бы больше статьей с подобным разбором — очень интересно, как в АСУТП применяются технологии из сферы IT. Плюс пока всё это выясняешь, успеваешь попользоваться и изучить новые инструменты для анализа/разбора/кодирования.
Санкции. Производитель ушёл из России, а так же с ним и техподдержка в общем случае. В случае больших отказов модулей (плохая прошивка модуля, неверная работа функции Access control и т.д.) — все решалось через французскую техническую лабораторию. В текущих условиях это не выполнимо, плюс российский филиал теперь хочет денюжку за свою работу (что в целом и логично).
ФСТЭК. Смотрим свежую уязвимость CVE-2022–45788 (она же BDU:2023–00228). Цитата с сайта:
Установка обновлений из доверенных источников. В связи со сложившейся обстановкой и введенными санкциями против Российской Федерации рекомендуется устанавливать обновления программного обеспечения только после оценки всех сопутствующих рисков.
Как говорится «Спасение утопающих — дело рук самих утопающих».
Банальное любопытство и отсутствие инструментов от производителя. Ниже расскажу две небольших истории.
Когда работаешь с одним и тем же инструментом, то иногда и не задумываешься, а как оно все работает внутри. Ты, как конечный пользователь, можешь совершать ошибки, которые как бы и не могли проявиться, но они произошли. Пример с тем же NOR модулем. Через веб-интерфейс можно закинуть свою конфигурацию для МЭК в виде XML файла. А что, если этот файл некорректно применился? Получаем нерабочий модуль. Он рабочий, но конфигурация сломалась. Починить можно заменой SD-карты производителя на чистую, заново руками набить конфигурацию и дальше использовать модуль. А что делать с старой SD картой? Выкинуть? Так она денег приличных стоит. Отформатировать не получится — у неё своя какая-то разметка, которую понимает модуль. А как посмотреть внутренности в побайтовом формате? Статей нет, инструментов нет, спросить не у кого (если знаете утилиты, напишите в комментариях или в личные сообщения).
Тот же протокол UMAS. OFS сервер опрашивает ПЛК по данному протоколу, а коды и внутренности его я узнал только из статьи от Armis. В целом, мне до этого и не важно было, но когда начинаешь спускаться уже до этого уровня обмена, то хотелось бы какого-то понимания протокола. Причем эту информацию узнаешь с сайтов по безопасности, а не от самого разработчика. Ужас, что сказать ещё.
Опять же привязанность к конкретной операционной системе. Многие среды разработки для ПЛК работают только под Windows — драйвера для соединения с устройством, компиляторы и т.д. Плюс можешь использовать только именно ПО от производителя, ничем другим его не заменить.
При текущем импортозамещении все ринулись переходить на разработки отечественных производителей. Но и у них все не гладко. Например, у Прософт — перезапуск драйвера «RegulBus OS» с периодом в 49 дней (ссылка). Сидите вы, сидите и тут бах — у вас локальная система отвалилась. Неприятно.
Как обычно предлагаю в комментариях упомянуть ресурсы, которые могут быть полезны, утилиты для прикладного анализа, советы, замечания, предложения — очень интересно послушать вашу точку зрения.
