Введение

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 (скорее всего производства Motorola). Перейдем к содержимому файлов, предоставляемых производителем.

И так, образ прошивки ЦПУ - видно, что используется система реального времени 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 архив с аналогичным содержанием.

По пути \FLASH0\wwwroot\conf\exec нас ждет уже нужный нам файл прошивки. Опять загоняем в binwalk и смотрим:

Распаковываю тем же binwalk'ом, перехожу в полученную папку и вновь смотрю на полученный результат:

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

Полученный файл загружаем и IDA Pro со следующими параметрами:

• Выбираем PowerPC big-endian

• При выборе начального адреса ROM и входного файла указываем 0x10000 (адрес не изменился, так как это связанно с архитектурой - по ссылкам выше есть описание, почему именно этот адрес)

• при выборе устройства указываем mpc860 (можно и ppc - я первый раз указал именно его, различий не увидел)

• ну а дальше просто везде щелкаем ok

Так как на сайте reversemode.com и веб-архиве нет нужного нам скрипта для восстановления наименования функций из отладочных символов, пришлось искать в интернете по названию - может у кого остался. Мне повезло и в одном из репозиториев лежал данный файл. Начальный адрес мы уже знаем от binwalk, теперь в hex редакторе найдем конец данной последовательности:

В скрипте указываем нужный нам диапазон, в IDA нажимаем ALT+F7 (либо через File -> Script File..), выбираем наш файл и ждем выполнения:

Функцию usrAppInit я не нашел (которая в старых версиях точно присутствовала), но это и не было целью. Теперь, зная синтаксис ассемблера для PowerPC можно посмотреть, как работает и ведет себя система, но это уже тема для другого разговора.

Modicon

Новая серия контроллеров построена уже на архитектуре ARM - это относится как и к центральным контроллерам, так и к модулям TCP/IP и МЭК.

Меня привлекла больше именно эта линейка, потому что в 2020 году компания Armis нашла очень крупную уязвимость - ModiPwn. Прекрасное объяснение того, что в текущих условиях Modbus TCP соединение ничем не защищено (пример реализации от компании TALOS). Оставлю дополнительный материал на русском от Касперского. И вот в статье от 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 архивы, поэтому просто извлекаем.

Загружаем в binwalk:

Образы CPU u-boot uImage распаковать я не смог -dumpimage не видит разделов для извлечения (единственный русскоязычный туториал есть на linux.org.ru). Образ NOR на вид выглядит несжатым, но опыта дизассемблирования ARM у меня нет. Но, судя по стартовым адресу ЦПУ в 10000 я предполагаю, что у и модулей тоже самое.

Интересно так же посмотреть и на содержимое папок прошивки NOR. Папка J9 указывает популярную в узких кругах реализацию JVM - OpenJ9 (Eclipse OpenJ9 или известная до этого под именем IBM J9). Так же в jar файлах можно увидеть упоминание нашумевшего в своё время Log4j - видимо применяется для записи логов на карту памяти. Как минимум, уже есть две уязвимые точки при использовании java - не думаю, что производитель так часто обновляет модули системного ПО.

Заключение.

Почему я решил написать эту небольшую статью. На это есть несколько причин.

1. Отсутствие статей в русскоязычном сегменте. Понимаю, что тема слишком специфичная, но хотелось бы больше статьей с подобным разбором - очень интересно, как в АСУТП применяются технологии из сферы IT. Плюс пока всё это выясняешь, успеваешь попользоваться и изучить новые инструменты для анализа/разбора/кодирования.

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

3. ФСТЭК. Смотрим свежую уязвимость CVE-2022-45788 (она же BDU:2023-00228). Цитата с сайта:

   Установка обновлений из доверенных источников. В связи со сложившейся обстановкой и введенными санкциями против Российской Федерации рекомендуется устанавливать обновления программного обеспечения только после оценки всех сопутствующих рисков.

   Как говорится "Спасение утопающих – дело рук самих утопающих".

4. Банальное любопытство и отсутствие инструментов от производителя. Ниже расскажу две небольших истории.

Когда работаешь с одним и тем же инструментом, то иногда и не задумываешься, а как оно все работает внутри. Ты, как конечный пользователь, можешь совершать ошибки, которые как бы и не могли проявиться, но они произошли. Пример с тем же NOR модулем. Через веб-интерфейс можно закинуть свою конфигурацию для МЭК в виде XML файла. А что, если этот файл некорректно применился? Получаем нерабочий модуль. Он рабочий, но конфигурация сломалась. Починить можно заменой SD-карты производителя на чистую, заново руками набить конфигурацию и дальше использовать модуль. А что делать с старой SD картой? Выкинуть? Так она денег приличных стоит. Отформатировать не получится - у неё своя какая-то разметка, которую понимает модуль. А как посмотреть внутренности в побайтовом формате? Статей нет, инструментов нет, спросить не у кого (если знаете утилиты, напишите в комментариях или в личные сообщения).

Тот же протокол UMAS. OFS сервер опрашивает ПЛК по данному протоколу, а коды и внутренности его я узнал только из статьи от Armis. В целом, мне до этого и не важно было, но когда начинаешь спускаться уже до этого уровня обмена, то хотелось бы какого-то понимания протокола. Причем эту информацию узнаешь с сайтов по безопасности, а не от самого разработчика. Ужас, что сказать ещё.

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

При текущем импортозамещении все ринулись переходить на разработки отечественных производителей. Но и у них все не гладко. Например, у Прософт - перезапуск драйвера «RegulBus OS» с периодом в 49 дней (ссылка). Сидите вы, сидите и тут бах - у вас локальная система отвалилась. Неприятно.

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