Как диагностировать программу plc
Перейти к содержимому

Как диагностировать программу plc

  • автор:

ДОПОЛНИТЕЛЬНЫЙ МАТЕРИАЛ. ОТЛАДКА ПРОГРАММ ПОЛЬЗОВАТЕЛЯ

Для отладки и тестирования программ пользователя без использования контроллера необходимо использовать программный модуль PLCSIM. S7-PLCSIM позволит Вам выполнить и протестировать Вашу программу на имитаторе программируемого логического контроллера (ПЛК), который установлен на Вашем компьютере. Поскольку имитатор функционирует совместно с программным обеспечением STEP 7, нет необходимости подключаться к какому либо оборудованию S7 (ЦПУ или модулям ввода/вывода). С помощью имитатора ПЛК S7 Вы можете протестировать и отладить программы для ЦПУ S7-300 и S7-400. S7-PLCSIM обеспечивает простой интерфейс для мониторинга и модификации различных параметров, используемых программой (например, логических, таких как включено — выключено). Пока программа выполняется на имитаторе ПЛК, Вы также можете использовать различные приложения STEP 7. Следовательно, Вы можете использовать такие инструменты, как таблица переменных (VAT) для наблюдения и модификации переменных. Дополнительно S7-PLCSIM обеспечивает следующие возможности: Кнопка включения или выключения имитатора на панели SIMATIC Manager. Нажмите на кнопку имитатора, чтобы открыть программное обеспечение S7-PLCSIM вместе с имитатором ЦПУ. Когда S7-PLCSIM работает, любая новая связь происходит автоматически. Имитатор ПЛК выполняет программы для каждого модуля ЦПУ S7-300 или S7-400. Вы можете создать «видимый объект», что обеспечивает доступ к области памяти входов и выходов, аккумуляторам и регистрам имитируемого ПЛК; Можно выбрать время выполнения автоматически или установить его вручную. Вы можете устанавливать таймеры индивидуально или все вместе; Допустимо изменение рабочего режима ЦПУ (STOP, RUN и RUN-P) как на реальном ЦПУ; Дополнительно S7-PLCSIM обеспечивает свойство Stop, чтобы немедленно остановить ЦПУ без привязки к состоянию программы; Вы можете записать ряд событий (манипуляция областями памяти входа и выхода, сумматорами, регистрами) и воспроизвести запись в режиме автоматического тестирования программы. Использование всех инструментов STEP 7 для мониторинга и изменения деятельности имитатора ПЛК. Хотя имитатор ПЛК существует полностью в программном обеспечении (не требует аппаратного обеспечения), STEP 7 работает так, как если бы имитатор ПЛК был частью аппаратного обеспечения , с несколькими отличиями . ОТЛИЧИЯ ОТ РЕАЛЬНОГО ПЛК S7 Имитатор ПЛК обеспечивает следующие функции, которых нет в реальном ПЛК:

Команда Stop останавливает имитатор ЦПУ и позволяет возобновить программу с того места, где она была остановлена. Вы можете изменить рабочий режим (RUN, RUN-P и STOP) как на реальном ЦПУ. Однако, в отличие от реального ЦПУ, установка имитатора ЦПУ в режим STOP не позволяет изменить состояние выходов. Любые изменения , которые Вы делаете в видимом объекте , немедленно сохраняются в ячейках памяти . ЦПУ не дожидается начала или конца цикла для обновления данных . Выполнение контрольных функций позволяет Вам выбрать, как будет выполнена программа на ЦПУ: — Одиночный цикл выполняется программой для одного цикла и затем ждет начала следующего цикла. — Непрерывное функционирование выполняется программой как на реальном ПЛК: начало нового цикла следует сразу же за концом предыдущего. Вы можете позволить таймеру выполняться автоматически или можете устанавливать каждую величину вручную. Также Вы можете сбросить все или отдельные таймеры. Вы можете вручную привести в действие прерывания OB: от OB40 до OB47 (аппаратные прерывания), OB70 (ошибка резервирования входов/выходов), OB72 (ошибка резервирования ЦПУ), OB73 (ошибка резервирования связи), OB80 (ошибка времени), OB82 (диагностическое прерывание), OB83 (вставка/удаление модуля), OB85 (ошибка программной последовательности) и OB86 (неисправность стойки). Область отображения процесса и периферийная память: Когда Вы делаете изменения входной величины в видимом объекте, S7-PLCSIM немедленно копирует их в периферийную память. Это значит, что при записи периферийной входной величины в регистр образа процесса в начале следующего цикла, изменения не будут потеряны. Соответственно, когда Вы изменяете выходную величину, она немедленно копируется в периферийную память выхода. Имитатор ПЛК отображает четыре аккумулятора, как в ЦПУ S7-400. В специальных случаях поведение программы, выполняемой на S7-PLCSIM с четырьмя аккумуляторами может отличаться от поведения той же программы на ЦПУ S7300, который использует только два аккумулятора. БЫСТРЫЙ СТАРТ Если Вы начинаете работать в S7-PLCSIM, следующие процедуры помогут Вам начать работу. Режим имитации доступен из SIMATIC Manager. 1. Откройте SIMATIC Manager. 2. Нажмите на или выберите команду меню Options > Simulate Modules (Опции > Имитация модулей). Этим действием открывается приложение S7PLCSIM с видимым объектом CPU (со значением, по умолчанию, адреса MPI 2). 3. В SIMATIC Manager откройте нужный Вам проект. 4. В выбранном проекте откройте папку Blocks (блоки).

• В SIMATIC Manager выделите необходимые блоки программы и нажмите на или выберите команду меню PLC > Download (ПЛК > Загрузить) для загрузки блоков программы в имитатор ПЛК. • На вопрос «хотите ли Вы загрузить системные данные?», выберите No (Нет), если Вы не хотите загрузить аппаратную конфигурацию в имитатор ПЛК, или Yes (Да) для загрузки аппаратной конфигурации (например, для использования часового меркера). 5. В приложении S7-PLCSIM создайте необходимые для отладки программы «видимые объекты» для наблюдения информации в имитаторе ПЛК: • Нажмите на или выберите команду меню Insert > Input Variable (Вставить > Входные переменные). Появляется видимый объект IB0 (входной байт 0). • Нажмите на или выберите команду меню Insert > Output Variable (Вставить > Выходные переменные) для того, чтобы отметить второй видимый объект QB0 (выходной байт 0). • Нажмите на или выберите команду меню Insert > Timer (Вставить > Таймер) три раза для того, чтобы пометить три видимых объекта. Наберите 2, 3 и 4 (для таймеров T 2, T 3 и T 4) в соответствующих текстовых боксах, нажимая клавишу Enter (Ввод) после каждого ввода. 6. Переключите имитатор ЦПУ в режим RUN, отметив бокс выбора RUN или RUN-P. 7. Устанавливайте биты IB0 в различные состояния, чтобы имитировать вход 0.0 и наблюдайте за выходными переменными и таймерами. ИСПОЛЬЗОВАНИЕ STEP 7 ДЛЯ МОНИТОРИНГА ИМИТАТОРА Вы можете также использовать инструменты STEP 7 для мониторинга имитатора Вашей программы: 1. Когда у Вас есть созданный видимый объект, войдите в SIMATIC Manager 2. Нажмите на или выберите View > Online (Вид > Подключено) , чтобы включить режим online. 3. Выберите объект «Blocks» в проекте и откройте блок, работу которого требуется проконтролировать. Это действие загружает редактор «LAD/STL/FBD». 4. Если имитатор ЦПУ в режиме RUN, войдите в окно приложения «LAD/STL/FBD» и выберите Debug > Monitor (Отладка > Наблюдение) , чтобы наблюдать влияние изменений состояний входов на действия операторов в Вашей программе.

РАБОЧИЕ РЕЖИМЫ ЦПУ Режим RUN-P ЦПУ выполняет программу и позволяет Вам изменять программу и ее параметры. Для того, чтобы использовать инструменты STEP 7 для изменений любых параметров программы, пока она выполняется, Вы должны перевести ЦПУ в режим RUN-P. Кроме того, Вы можете использовать видимые объекты, создаваемые с помощью S7-PLCSIM для изменения любых данных, используемых программой. Режим RUN ЦПУ выполняет программу: опрашивание входов, выполнение программы и затем обновление выходов. Вы не можете загрузить любую программу или использовать инструменты STEP 7 для изменения параметров (таких как входные величины), если ЦПУ находится в режиме RUN. Кроме того, Вы можете использовать видимые объекты, создаваемые с помощью S7-PLCSIM для изменения любых данных, используемых программой. Режим STOP ЦПУ не выполняет программу. В отличие от режиме STOP реального ЦПУ, выходы не устанавливаются в предопределенные безопасные значения, но остаются в состоянии, в котором они были, когда ЦПУ перешел в STOP. Вы можете загрузить программу в ЦПУ, если он находится в режиме STOP. Переход из режима STOP в RUN вызывает выполнение программы, начиная с первой команды. Режимы работы ЦПУ, индикаторы ЦПУ и кнопка Clear/Reset (Сброс памяти) показаны на видимом объекте ЦПУ. Вы можете установить режим работы ЦПУ, используя переключатель режимов. Вы можете приостановить выполнение имитируемой программы ПЛК, если ЦПУ находится в режимах RUN или RUN-P. ИНДИКАТОРЫ ЦПУ Видимый объект CPU воспроизводит индикаторы, которые соответствуют светодиодам на реальном ЦПУ: SF (системная неисправность) сигнализирует, что ЦПУ встретил системную ошибку, приведшую к изменению рабочего режима. DP (распределенная периферия или удаленные ввод/вывод) показывает состояние связи с распределенным (удаленным) входом/выходом. DC (обеспечение питанием) показывает выключено или включено питание ЦПУ. RUN показывает, что ЦПУ находится в режиме RUN. STOP показывает, что ЦПУ находится в режиме STOP. ОБЛАСТИ ПАМЯТИ Вы имеете доступ к данным в ПЛК S7 адресуясь к определенным областям памяти. Эти области выполняют специальные функции:

PI (периферийный вход): обеспечивает прямой доступ к входным модулям. I (вход): обеспечивает доступ к области отображения входов. Эти величины обновляются ЦПУ в начале каждого цикла CPU. PQ (периферийный выход) обеспечивает прямой доступ к выходным модулям. Эти значения обновляются ЦПУ в конце каждого цикла ЦПУ. Q (выход): обеспечивает доступ к области отображения выходов. M (меркеры): обеспечивает хранение данных, используемых внутри программы. T (таймер): обеспечивает хранение таймеров. C (счетчик): обеспечивает хранение счетчиков. У Вас также есть доступ к данным, хранящихся в блоках данных (DB). Отображение периферийных входов и выходов и переменных, хранящихся в блоках данных доступно с помощью объекта «Обобщенная переменная (Generic Variable)». Для того, чтобы добавить этот видимый объект к имитатору, проделайте следующее: Выберите команду меню Insert > Generic (Вставить > Обобщенная переменная) или нажмите кнопку Insert Generic Variable (Вставить обобщенную перемен- ную) . Этот видимый объект позволяет Вам следить и изменять следующие дан- ные: периферийные (внешние) переменные входа и выхода: у Вас есть доступ к периферийным областям памяти входов (PI) и выходов (PQ) ЦПУ; области отображения входов и выходов: у Вас есть доступ к областям отображения входов (I) и выходов (Q) ЦПУ. ЦПУ перепишет память PI в память I в начале каждого цикла. Если Вы измените переменную памяти I, имитатор немедленно сделает копию в периферийную область. Таким образом, изменения не пропадут, когда периферийная величина перепишется в область отображения входов при следующем цикле; меркеры: у Вас есть доступ к переменным, которые хранятся в области меркеров (M) ЦПУ; таймеры и счетчики: у Вас есть доступ к таймерам и счетчикам, используемым программой; блоки данных: у Вас есть доступ к данным, которые хранятся в блоках данных программы. Адресация к четвертому слову десятого блока данных должна вводиться как DB10.DBW 4. ЦПУ немедленно реагирует на любые изменения, сделанные в просматриваемом объекте. Любые изменения, сделанные с помощью таблицы переменных STEP 7, дают правильный эффект времени в ЦПУ: входы читаются в начале цикла и выходы переписываются в конце. Вы можете выбрать числовой формат данных для обобщенной переменной, а также использовать символическую адресацию, если к имитатору присоединена символика.

ВЫБОР ОПЦИЙ ЦИКЛИЧЕСКОГО РЕЖИМА ВЫПОЛНЕНИЯ S7-PLCSIM предлагает следующие возможности для выполнения имитируемой программы: Однократное выполнение программы: ЦПУ выполнит один цикл, и затем будет ждать, когда Вы решите выполнить следующий. Каждый цикл состоит из чтения ЦПУ периферийных входов (PI), выполнения программы, и, затем, записи результатов в периферийные выходы (PQ). ЦПУ затем ждет, когда Вы начнете следующий цикл (используйте команду меню Execute > Next Scan ) или нажмите . Циклический режим: ЦПУ выполняет одно полный цикл и затем начинает другой. Каждый цикл состоит из чтения ЦПУ периферийных входов (PI), выполнения программы, и затем запись результатов на периферийные выходы (PQ). Для того чтобы выбрать режим однократного выполнения, нажмите на или выберите команду меню Execute > Scan Mode> Single Scan (Выполнить > Режим циклического функционирования > Однократное выполнение). Это позволяет Вам просмотреть изменения при каждом цикле. Несмотря на то, что реальный ЦПУ может работать быстрее, чем редактор может показывать данные, возможность однократного выполнения программы позволяет Вам фиксировать состояние программы от одного цикла к другому. Для того чтобы выбрать режим циклического выполнения, нажмите на или выберите команду меню Execute > Scan Mode > Continuous Scan (Выпол- нить > Режим циклического функционирования > Циклическое выполне- ние). (Режим по умолчанию — циклическое выполнение). УПРАВЛЕНИЕ ПРОГРАММОЙ ИМИТАТОРА Вы можете отобразить различные типы видимых объектов, которые позволяют Вам управлять и модифицировать программу, выполняемую на имитаторе ПЛК. Следующие семь видимых объектов активируются через меню Insert (Вставка) : Входная переменная : позволяет Вам иметь доступ к данным, сохраненным в области памяти входов (I). Значение адреса по умолчанию 0 байт 0 (IB0). Выходная переменная : позволяет Вам иметь доступ к данным, сохраненным в области памяти выходов (Q). Значение адреса по умолчанию 0 байт (QB0). Меркеры : позволяет Вам иметь доступ к данным, сохраненным в области меркеров (M). Значение адреса – это байт 0 (MB0). Таймер : позволяет иметь доступ к таймерам, используемым программой. Значение таймера по умолчанию T 0. Счетчик : позволяет иметь доступ к счетчикам, используемым программой. Значение счетчика по умолчанию C 0. Групповой : позволяет Вам иметь доступ к любой области памяти в имита- 211

торе ЦПУ, включая блок данных (DB). Вертикальные биты позволяют Вам видеть символические или абсолютные адреса каждого бита, наблюдать т модифицировать данные. Вертикальные биты могут использоваться для побитового показа переменных периферийных входов и выходов, областей отображения входов и выходов, меркеров и переменных в блоках данных. Вы можете использовать адресацию для любых из перечисленных объектов. Следующие три видимых объекта активируются меню View (Вид) : Аккумуляторы : позволяют Вам отобразить данные в различных аккумуля- торах в имитаторе ЦПУ, а также слово состояния и адресные регистры. Видимый объект отображает четыре аккумулятора, размещая четыре аккумулятора ЦПУ S7-400. Программа для ЦПУ S7-300 использует только два сумматора. Регистры блоков : позволяют Вам отображать содержание адресных регистров блоков данных в имитаторе ЦПУ. Также показывают номер выполняемого логического блока и номер предыдущего логического блока, с номером выполняемой инструкции (счетчика адреса, или SAC). Стеки : позволяют отображать сохраненные данные в аппаратных стеках и стеке команды MСR в имитаторе ПЛК. Вы также можете одновременно управлять приложениями в программе STEP 7 «LAD/STL/FBD». ИСПОЛЬЗОВАНИЕ СИМВОЛЬНОЙ АДРЕСАЦИИ Для использования символьной адресации в Вашей имитируемой програм- ме: 1. Выберите команду меню Tools > Options > Attach Symbols. (Инстру- менты > Опции > Присоединить символику…) . Эта команда вызовет окно диа- лога. 2. Просмотрите таблицу символов STEP 7, чтобы найти необходимые. 3. Нажмите кнопку «OK». 4. Создайте видимый объект для переменных, которым Вы хотите присвоить символьную адресацию. 5. Включите символы для всех видимых объектов, выбрав команду меню Tools > Options > Show Symbols ( Инструменты > Опции > Показать символи- ку ). Для того, чтобы скрыть символы, повторите команду. Для видимого объекта Vertical Bits (Вертикальные биты), битовые значения показываются вертикально, а символические или абсолютные адреса показаны за каждым битом. Для остальных видимых объектов, символьные подсказки доступны для полей адреса. Укажите поле мышью, чтобы увидеть символический адрес и закомментируйте (отделите двоеточием) в окне подсказки. ИСПОЛЬЗОВАНИЕ ЗАПИСИ/ВОСПРОИЗВЕДЕНИЯ Диалоговое окно Запись/Воспроизведение позволяет Вам записывать или

Последовательность поиска ошибки в программе ПЛК

Достаточно часто в литературе мне попадались описания ошибок и даже классификации их по типам.
Хотя, признаться, у меня не получается толком вспомнить ни одного случая, когда мне бы помогло знание того, к какому именно типу относится конкретная ошибка. Разве что уже после выяснения причин, для обьяснения их окружающим.
А вот как люди вычисляли место и докапывались до сути ошибки — мне всегда было интересно.

Сведения о системе и ошибке

С компьютера на ПЛК подаются уставки (времена, флаги режимов) и команды на устройство.
Из ПЛК на компьютер выдаются сигналы статуса устройства и времени до конца команды на это устройство. Сигналы пакуются в слова, для минимизации объемов приема и передачи.
Из ПЛК на устройство выдаются команды.
Устройство выдает на ПЛК свои статусы.

image

Изначально все работало, но через какое-то время при подаче команд, статусы на компьютере в SCADA начали моргать не по делу и вообще вести себя крайне недружелюбно. Причем только в одном месте, на одном объекте.

Но «танцы с саблями» появлялись стабильно, при каждой команде, что очень порадовало.

Поиск

Цифрами в круглых скобках показаны места проверок, соответствующие цифрам на схеме ниже.

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

Было установлено, что ошибка присутствует не только в SCADA (1) (там, где она собственно была обнаружена), но и в OPC сервере (2).

Дальнейший разбор показал, что ошибка присутствует и в ПЛК, как минимум в слове, формируемом для компьютера (3).

Проверка наличия ошибки в статусе, приходящем от устройства – отметает устройство, как возможный источник проблемы.

Изменения статуса от устройства вручную ничего не меняют. При изменении статуса от устройства форсированием (принудительно, постоянно) ошибка все равно сохраняется.
Соответственно это и не импульсы, которых не видно при мониторинге (4).

Сравнение с кодами других объектов, на которых этой ошибки нет – различий не выдает. Полная идентичность. Вероятность ошибки в программе ПЛК уменьшается (5).

Отключается компьютер, как возможный источник ошибки, записывающий что-то в данную область памяти. Ошибка сохраняется. Вероятность ошибки из-за компьютера стремится к нулю. Соответственно, не смотря ни на что, проблема все-таки в ПЛК (6).

Ремарка: Также можно было, отключив ПЛК, руками менять статусы в OPC. Но такой вариант был сложнее технически, а в целом эти две проверки практически равнозначны.

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

Перенесение куска кода с ошибкой в другой блок (условно функцию) тоже не влияет на ошибку. Соответственно вероятность того, что это влияет какая-то еще посторонняя команда, пишущая туда-же что-то свое – незначительна. Дело в этом куске.

  1. Подача команды (без нее не понятно как проверять).
  2. Таймер, с которого берется время до сброса команды.
  3. Формирование слова на компьютере из статуса и времени до сброса команды.

image

Удаляется таймер. Команда не сбрасывается, но ошибка пропадает и статусы перестают прыгать.

Взамен вставляется новый таймер. Тщательно осматривается на предмет нелепостей. Таймер самый заурядный, ничего необычного. Таких в программе еще штук 200. Но ошибка появляется (8)

  1. Запись статусов устройства в младший байт слова.
  2. Замена старшего и младшего байт местами командой SWAP_WORD (статусы переносятся в старший байт)
  3. По AND запись времени в младший байт слова

Вроде ничего необычного, причем полностью идентичная система работает с десятками идентичных устройств вокруг. Мозг скрипит и отказывается помогать.

  1. Запись времени устройства в младший байт слова.
  2. В промежуточной переменной статусы умножаются на 256, сдвигаясь в старший байт слова.
  3. По OR производится запись статусов в старший байт слова.

image

После разбора — ситуация становится окончательно понятной.

Причина ошибки:

Операторы увеличили стандартное время таймаута с 1,5 до 10 минут.
И если 1,5 минуты это 90 секунд, то 10 минут это 600 секунд.
600 секунд не влезали в младший байт (максимум 256), и часть времени писалась в старший.

Суть последней проверки:

При записи сначала времени, и лишь затем статуса – статус забивал биты переполнения, приходившие от значения времени. А при обратной последовательности команд, время наоборот забивало своими битами статус.

Решение:

Время и статусы были разбиты на 2 слова. Местным инженерам было предложено провести техобслуживание или заменить устройство с таймаутом, превышающим стандартное время более чем в 5 раз.

И они работали они долго и счастливо, и сломались в один день.

Выводы

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

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

  1. По максимуму собрать информацию о проблеме — где и как она проявляется. Осциллографы, снифферы, утилиты от Русиновича, логи, градусники, в общем всё, что можно использовать в данном случае. Не зависит ли она от времени года, прихода уборщицы, или барометрического давления.
  2. Вывести из-под подозрения как можно большую часть. Перерезая дорожки на печатных платах, отключая теги, выводя из системы отдельные компьютеры. Хуже, если есть какие-нибудь обратные связи и прочие хендшейки. Тогда можно попытаться либо организовать проверку приняв во внимание отсутствие части системы, либо пробовать проэмулировать часть, например искусственно подавая сигнал на вход обратной связи. В общем думать.
  3. По возможности доводить каждую проверку до конца, даже если вдруг появилась «мысль!». Потому-что «мысль!» может и не сработать (и до обидного часто не срабатывает), а результатов проверки лишаешься.
  4. В оставшемся куске — менять всё, что вызывает подозрения. Если это ПО — попробовать переустановить или заменить на аналогичное. В принципе есть вариант начать с этого пункта. Лично видел инженера, при ремонте платы на 40-50 микросхем К155 серии, выкусившего их все и впаявшего новые. Но это на мой взгляд скорее пример того, как не надо делать. Потому-что даже если все заработает, конкретики не получишь. Тем более, что в описанном случае этот вариант не прошел и неисправность сохранилась. В общем — я этого не говорил.

Хотя разумеется рецепты для одних ситуаций могут быть совершенно бесполезны по отношению другим.
Но у всех ошибок есть конкретная причина, и эту причину всегда можно выяснить.
Например как-то причиной был тракторист с бороной, проехавшийся над кабелем. И хотя сложностей в ее устранении не возникло, их хватило в процессе написания рекомендации, для избежания повторов…

Извиняюсь за вероятную сложность чтения.
Тема не очень художественная, плюс к этому попытался сократить, пропуская не очень существенные моменты, вроде вынужденного отказа от BreakPoint’ов, из-за цикличности выполнения программы в ПЛК и наличия таймера.

7.2 Диагностика с помощью online-функций STEP 7

Базовый пакет STEP 7 предоставляет в распоряжение пользователю различные online-функции для диагностики. Эта глава описывает эти функции и их использование на примере установки PROFIBUS-DP. 7.2.1 Функция Accessible Nodes в SIMATIC Manager C помощью функции Accessible Nodes в SIMATIC Manager можно проверить, какие активные и пассивные шинные участники находится на сети MPI или PROFIBUS. Также можно благодаря этой функции проводить для участников, подключенных к сети MPI или PROFIBUS, диагностику без данных соответствующего проекта STEP 7. Чтобы использовать эту диагностическую online-функцию, должны быть установлены скорость интерфейса PG/PC, такая же, как у сети PROFIBUS (при MPI – 187,5 кБод) и шинный пофиль. Online-интерфейс PG/PC при старте функции пассивно связывается с шиной и проверяет, совпадает ли его скорость

глава 7 “ Функции диагностики для PROFIBUS-DP ” (36стр) стр 6

передачи со скоростью передачи шины PROFIBUS. Если это не так, выдается соответствующее сообщение об ошибке. То же происходит, если подключенный PG/PC не имеет уникального шинного адреса. Если установлено совпадение скоростей и PG/PC имеет уникальный адрес, то он принимается в логическое маркерное кольцо. С помощью MPI/ISA-карты можно установить скорость передачи только до 1,5 Мбод. Чтобы функция выполнялась при более высоких скоростях, необходимо использовать другие коммуникационные карты, например, CP5411 (ISA-карта), CP5511 (PCMCIA-карта) или CP5611 (PCI-карта). Все названные устройства полностью поддерживаются базовым пакетом STEP 7, то есть не требует использования дополнительных средств. При активизации функции Accessible Nodes с помощью команды меню SIMATIC Manager появляется окно, в котором показаны все доступные программируемые модули (CPU, FM, CP) со своими MPI или PROFIBUS шинными адресами. Показываются также MPI- и PROFIBUS-участники, которые проектируются не с помощью STEP 7 (например, панель оператора). Шинный участник, с которым PG или РС связан напрямую, отмечен словом “direct” рядом с шинным адресом (см. рисунок 7.1). Рис. 7.1 Функция Accessible Nodes с MPI-узлами Диагностическая возможность Accessible Nodes предлагает прежде всего быстрый доступ к программируемому модулю. Обратите внимание, что изменения в online-представлении (например, выход из строя участника) автоматически не актуализируется в открытом окне Accessible Nodes. Актуализация достигается или с помощью функциональной клавиши “F5”, или с помощью View->Update . Если MPI-участник выбран с помощью правой клавиши мыши, то открывается контекстное меню. Если выбрать CPU, то открывается следующее подменю. Для диагностики имеют значение следующие пункты контекстного меню: • Monitor/Modify Variables. Выбор этой функции запускает утилиту STEP 7 Monitoring and Modifying Variables. Вслед за этим Вы можете наблюдать и управлять переменными. • Module Information (см. раздел 7.2.3). • Diagnose Hardware (см. раздел 7.2.4).

глава 7 “ Функции диагностики для PROFIBUS-DP ” (36стр) стр 7

Установка online-интерфейса PG/PC Выберите в SIMATIC Manager Option->Set PG/PC Interface . Открывается окно, показанное на рисунке 7.2. Рис. 7.2 Установка PG/PC интерфейса Используйте PG740 со встроенной MPI-картой, выберите в качестве модуля “MPI/ISA on Board (PROFIBUS)”. Войдите с помощью кнопки “Properties” в окно установки деталей модуля и выберите не занятый адрес PROFIBUS, с которым PG должен работать. Установите скорость передачи на значение, которое имеет Ваша установка, и сравните “Highest Station Address” и “Profile” со значениями, имеющимися на установке. Квитируйте заданные параметры с помощью “ОК”. Соедините MPI/DP-интерфейс Вашего PG c сетью PROFIBUS. Обратите внимание, что при подключении PG к PROFIBUS применяется активный кабель (PROFIBUS-кабель со встроенным репитером). Иначе Вы можете при подключении Вашего кабеля вызвать помехи. Если PG/PC физически связан с PROFIBUS, щелкните затем на кнопке Accessible Noes. Теперь PG “слушает” шину и отображает всех подключенных к ней участников. Здесь также показан тип станции, то есть активный это участник (DP-Master) или пассивный (DP-Slave). В случае, если программатор подключен к некоторому узлу напрямую, то у этого узла будет надпись “direct” (рис. 7.3).

глава 7 “ Функции диагностики для PROFIBUS-DP ” (36стр) стр 8

Рис. 7.3 Функция Accessible Nodes через PROFIBUS Функция Accessible Nodes может, например, применяться, чтобы контролировать установленные PROFIBUS-адреса DP-Slave или если предполагается обрыв шины. В этом случае можно установить достижимы ли модули и, если да, то какие. Дальнейшая диагностика подключенных PROFIBUS-участников возможна только тогда, когда выбранные участники поддерживают диагностические функции STEP 7. Например, S7-CPU с интерфейсом PROFIBUS-DP поддерживает эти диагностические функции. Щелчок на PROFIBUS-DP-адресе CPU открывает обычное контекстное меню. Через пункт меню CPU здесь можно также открыть диагностические функции, такие, как Monitor/Modify Variables, Module Information и т.д. Двойной щелчок на PROFIBUS-адресе CPU открывает объект и показывает контейнер блоков CPU. Опять с помощью двойного щелчка на контейнере модулей в правой половине окна SIMATIC Manager появляются применяемые блоки. Их можно открыть, изменить и опять загрузить в CPU для проверки. Конечно, в этом случае невозможно символическое программирование, так как для этого необходим offline-проект STEP 7. 7.2.2 ONLINE-функции в SIMATIC Manager Если Вы загрузили проект STEP 7 в контроллер, Вы можете в SIMATIC Manager при MPI–связи с помощью команды “online” перевести проект из offline-представления в online-представление, чтобы, например, открыть блоки STEP 7 c символическими именами. Эта функция возможна также при поддержке PG/PC через PROFIBUS. Откройте проект и установите интерфейс Вашего PG/PC, как это описано в главе 7.2.1, чтобы видеть актуальные значения на Вашей установке. Доступ к целевой системе вместе с управлением проектом тогда можно осуществить с помощью сконфигурированной аппаратуры или без нее. Чтобы осуществить доступ с помощью сконфигурированной аппаратуры, откройте соответствующий проект и выберите для online-представления станции команду меню View->Online. Выполните затем двойной щелчок на станции, которую Вы хотите открыть online, чтобы видеть содержащиеся в ней модули. Автоматически появится

глава 7 “ Функции диагностики для PROFIBUS-DP ” (36стр) стр 9

окно, в котором посредством закладок установите свойства соединения, как, например, PROFIBUS-адрес выбранного участника, а также номер слота (см. рисунок 7.4). Рис. 7.4 Свойства соединения (свойства папки S7-Programm в onlineрежиме) Задайте данные Вашего партнера, соответственно Вашего CPU и покиньте диалоговый бокс с помощью “ОК”. Опрос происходит только при первом online-доступе. Вводимые данные запоминаются в проекте STEP 7 и, таким образом, не должны при каждом online-доступе обновляться на экране. С помощью двойного щелчок на модуле, с которым Вы хотите установить связь, будет создана связь, принимающая во внимание установки и может иметь место online-диагностика через PROFIBUS-интерфейс. Для доступа без сконфигурированной аппаратной части, то есть без конфигурации аппаратуры в offline-проекте, откройте соответствующее окно проекта. Выберите для online-представления команду меню View->Online. Установите курсор на папку S7-Programm, расположенную непосредственно под проектом, с помощью правой клавиши мыши выберите в контекстном меню команду Object Properties. В открывшемся окне перейдите на закладку Addresses и задайте в окне для PROFIBUS-адреса адрес CPU, к которому Вы хотите получить доступ. Закройте диалоговое окно кнопкой “OK”. Связь установлена и Вы можете тестировать STEP 7-программу в режиме online. 7.2.3 Диагностика с помощью функции Module Information С помощью вызова функции Module Information открывается окно с несколькими закладками, которые показывают актуальную информацию о модулях. Объем этой информации зависит от типа выбранного модуля. Наряду

глава 7 “ Функции диагностики для PROFIBUS-DP ” (36стр) стр 10

с информацией на закладке показано состояние модуля. Если выбран не S7CPU, то выдается состояние, которое он имеет с точки зрения CPU (например, ОК, ошибка, модуль отсутствует). Таблица 7.10 показывает, какие закладки имеются для отдельных модулей в окне “ Module Information ”. Табл. 7.10 Информация о состоянии модулей для каждого типа модуля

CPU или Модули, Модули с Модули Стандарт-
Название закладки окна способные к без
диагнос- ные
М7-FM системной диагнос-
тикой DP-Slave
диагностике тики
General X X X X X
Diagnostic Buffer X X
Memory X
Scan Cycle Time X
Time System X
Performance Data X
Communication X
Stacks X
Diagnostic Alarm X X
DP-Slave-Diagnose X

Cпособностю к системной диагностике обладают, например, FM-модули (функциональные модули). Способностью к диагностике – в основном аналоговые сигнальные модули. Модули без диагностики – это в основном цифровые сигнальные модули. Окно “Module Information” может быть открыто несколькими путями: • С помощью функции “Accessible Nodes” из SIMATIC Manager щелкните на желаемом партнере правой клавишей мыши, после этого выберите в контекстном меню CPU->Module Information. • С помощью функции SIMATIC Manager “Online”. Откройте проект в Online-режиме, желаемая станция появится в левой половине окна SIMATIC Manager. Двойным щелчком открывается станция и выбирается программируемый модуль, то есть CPU. С помощью щелчка правой кнопкой мыши и контекстного меню CPU->Module Information открывается функция “Module Information” . • С помощью функции “Diagnosing Hardware” (см. раздел 7.2.4) Рисунок 7.5 показывает открытое окно “Module Information”, закладку “General”.

глава 7 “ Функции диагностики для PROFIBUS-DP ” (36стр) стр 11

Рис. 7.5 Диалоговое окно “Module Information” (для CPU) Отдельные закладки содержат различную информацию. Таблица 7.11 показывает список возможных закладок этого диалогового окна и их возможное использование. В конкретных случаях показываются только те закладки, которые имеют смысл для выбранного модуля. Следующая информация показывается в каждой закладке: • Online-путь к выбранному модулю; • Рабочее состояние CPU, которому принадлежит модуль; • Состояние выбранного модуля (например, имеет ошибку, ОК); • Рабочее состояние выбранного модуля (например, RUN, STOP), в той мере, в какой выбранный модуль этим располагает.

глава 7 “ Функции диагностики для PROFIBUS-DP ” (36стр) стр 12

Табл. 7.11 Обзор информация закладок окна “Module Information”

Название закладки Информация Использование
окна
Идентификационные данные Online-информация
General выбранного модуля, напр., тип, установленного модуля может
заказной номер, номер слота в быть сравнена с данными
стойке, состояние запроектированного модуля
Diagnostic Buffer Обзор событий в Для оценки причины останова
диагностическом буфере CPU
Memory Текущая загрузка рабочей и Для оценки возможности
загрузочной памяти выбранного переноса в CPU новых или
CPU обновленных блоков
Длительность наиболее Для контроля параметрирования
минимального и максимального
Scan Cycle Time короткого, длинного и
времени цикла, а также для
последнего циклов выбранного
контроля актуального времени
CPU или M7-FM
цикла
Time System Актуальное время, рабочее Для показа времени и даты
время и информация для модуля и для контроля
синхронизации часов синхронизации времени
Расширение памяти, области
операндов и блоки, имеющиеся Применяется для и во время
в выбранном CPU/FM. Показ создания пользовательской
Performance Data всех видов блоков, которые программы и для проверки
имеются в выбранном модуле. совместимости существующей
Список OB, SFC и SFB, которые программы пользователя с
могут применяться в данном данным модулем
модуле
Скорость передачи, обзор Для установления, как много и
Communication соединений, коммуникационная
какие могут быть связи CPU или
нагрузка, а также максимальная
M7-FM
величина телеграмм
Показывается cодержание B- Для установления причин
Stacks Stack’a, I-Stack’a и L—Stack’a.
останова и для корректировки
Дополнительно Вы можете
блоков
перейти в редактор блоков
Diagnostic Alarm Диагностические данные Для определения причин выхода
выбранного модуля из строя модуля
DP-Slave-Diagnose Диагностические данные Для определения причин
выбранного DP-Slave’а по
ошибок DP-Slave’a
EN 50170

При каждой смене закладки окна “Module Information” будут считываться новые данные из модуля. Во время показа закладки ее состояние автоматически не актуализируется. При нажатии на кнопку “Update” будут прочитаны новые данные из модуля без смены закладки. Далее описываются важнейшие закладки окна “Module Information”. Diagnostic Buffer Закладка “Diagnostic Buffer” считывает системную диагностику модуля (например, CPU) из его диагностического буфера. В диагностический буфер заносятся все диагностические события в порядке их наступления с подробной информацией (рисунок 7.6).

глава 7 “ Функции диагностики для PROFIBUS-DP ” (36стр) стр 13

Рис. 7.6 Закладка “Diagnostic Buffer” регистра “Module Information” При сбросе CPU содержимое диагностического буфера сохраняется. В качестве диагностических событий считываются, например, ошибки в модуле, системные ошибки в CPU, смена рабочего режима (например, RUN на STOP), а также ошибки программы пользователя. Ошибки в системе могут оцениваться благодаря диагностическому буферу спустя длительное время после их появления, чтобы установить причину перехода в STOP или чтобы знать порядок наступления диагностических событий. Если событие маркировать мышью, то можно с помощью кнопки “Help on Event” получить дополнительную информацию. Для записи в диагностический буфер, которая ссылается на место ошибки (тип блока, номер блока, относительный адрес), можно открыть соответствующий блок, чтобы устранить причину ошибки. Курсор в этом случае устанавливается прямо на команде, являющейся причиной события. Диагностический буфер – кольцевой буфер. Каждый модуль имеет определенное максимальное число записей. Если максимальное число записей достигнуто, то при новой записи в буфер самая старая запись стирается. Все

глава 7 “ Функции диагностики для PROFIBUS-DP ” (36стр) стр 14

записи сдвигаются вниз, а на место стертой записи заносится новая. Благодаря этому актуальная запись всегда находится на первом месте. Diagnostic Alarm На закладке “Diagnostic Alarm” показывается для модуля, способного к диагностике, информация о наступивших повреждениях модуля. В окне “Standard Diagnosis of the Module” представлены внутренние и внешние повреждения и сопутствующая диагностическая информация (см. рисунок 7.7). Рис. 7.7 Диалоговые регистры “DP Slave Diagnostics” и “Diagnostic Interrupt” В окне “Channel-Specific Diagnosis” показываются диагностические данные появившихся канальных ошибок, например: • Ошибка параметрирования; • Обрыв провода.

глава 7 “ Функции диагностики для PROFIBUS-DP ” (36стр) стр 15

Диагностика DP-Slave Закладка “DP Slave Diagnosis” информирует Вас о диагностических данных DPSlave’а, которые имеют структуру, согласно EN 50170 (см. рисунок 7.8). Рис.7.8 Диалоговое окно “DP Slave Diagnostics” В окне “Standard Diagnosis of the Slave” показывается общая и зависящая от прибора диагностическая информация для Slave’а. • Общая диагностическая информация для DP-Slave’а. Информация относится к корректной работе или ошибкам DP-Slave’а. К последним относятся, например, ошибки конфигурирования и параметрирования. • Диагностическая информация DP-Slave’а, зависящая от устройства. Показываемые диагностические записи определяются на основе специфического для прибора GSD-файла (Geräte Stamm Daten – нем.). Если диагностические сообщения не содержаться в GSD-файле, диагностика не может выдаваться в виде ясных текстов. В окне “Channel-Specific Diagnosis” показываются относящиеся к каналу диагностические записи для конфигурированного модуля DP-Slave. Для каждого вносимого диагностического сообщения выдается точно канал, послуживший причиной. Канал однозначно описывается благодаря номеру слота модуля и номеру канала.

глава 7 “ Функции диагностики для PROFIBUS-DP ” (36стр) стр 16

Специфические для прибора диагностические тексты определяются с помощью GSD-файла. Если диагностические сообщения не содержатся в GSD-файле, диагностика не дает ясных текстов. С помощью кнопки “Hex. Format” можно всю диагностическую телеграмму выдать в 16-ичном представлении. 7.2.4 Диагностика с помощью функции “Diagnosing Hardware” Функция “Diagnosing Hardware” может быть вызвана различными способами. • Через окно “Accessible Nodes”, вызов желаемого партнера с помощью правой клавиши мыши, потом – в контекстном меню PLC->Diagnosing Hardware. • Через функцию “Online” в SIMATIC Manager. Переключить проект в onlineпредставление, щелкнуть на желаемой станции правой кнопкой мыши и затем – в контекстном меню PLC->Diagnosing Hardware. Появляется окно “Diagnosing Hardware — properties”. В этом окне показываются символы для состояний блоков. Если, например, модуль поврежден, то в быстром просмотре рядом с CPU показывается также символом DP-Slave (рисунок 7.9). Рис. 7.9 Диалоговое окно “Diagnosing Hardware – Quick View” В таблице 7.12 описаны общие символы. Ошибки у модулей с диагностикой отображаются соответствующим символом, если диагностические прерывания деблокированы.

глава 7 “ Функции диагностики для PROFIBUS-DP ” (36стр) стр 17

Табл. 7.12 Общее описание диагностических символов

Диагностический Значение
символ
Красная Отличие заданной от действительной конфигурации: спроектированный
диагональная полоса модуль не представлен или установлен другой модуль
перед символом
блока
Красный круг с Модуль неисправен. Возможные причины: распознан диагностический
белым крестом сигнал или ошибка доступа к периферии
Изображение модуля Диагностика невозможна, так как нет online-соединения или CPU не
с пониженным получает диагностической информации от модуля (напр., от источника
контрастом питания).
В этом модуле проводится форсирование переменных, т.е. переменные
Красная скоба над заданы постоянными, программа их значения не может менять.
модулем Идентификатор для FORCE может появиться также в связи с другими
символами

Диалоговое окно “Diagnosing Hardware — properties” предлагает благодаря трем кнопкам различные функции на выбор (рисунок 7.9). Через кнопку “Module Information” открывается соответствующее окно. Через кнопку “Update” можно актуализировать содержание диалогового окна “Diagnosing Hardware – Quick View”. Через кнопку “Open Station ONLINE” загружается аппаратная конфигурация выбранной станции. При этом проверяется конфигурация каждого модуля. Неисправный модуль или модуль с ошибкой помечается соответствующим символом (рисунок 7.10). Рис.7.10 Загрузка конфигурации через “Diagnosing hardware ”

глава 7 “ Функции диагностики для PROFIBUS-DP ” (36стр) стр 18

ПЛК Mitsubishi: как разобрать сетевой протокол и найти уязвимости в устройстве без использования прошивки

Нас окружают умные устройства. Внутри каждого — микросхемы и прошивки с программным кодом, который содержит уязвимости. Представьте, что в руки исследователя безопасности попадает устройство с недокументированным сетевым протоколом. Возникают задачи: разобрать протокол, научиться общаться с устройством и найти слабые места — уязвимости. Для исследования нужна прошивка. Но что делать, если прошивку невозможно достать?

В статье я расскажу об опыте исследования ПЛК FX5U компании Mitsubishi без использования прошивки. Поделюсь, как собирал информацию и восстанавливал протокол на основе документации родственных протоколов, утилиты производителя, симулятора ПЛК, кодов ошибок, полного перебора и собственных наработок. Покажу, что знание протокола — это сила, и как это помогло нам с коллегами выявить 15 уязвимостей, среди которых CVE-2022-25161 и CVE-2022-25162. Опишу, как работают две эти уязвимости и как они влияют на технологические процессы на примере демонстрационных стендов.

Кто я и чем занимаюсь

Я Антон Дорфман, исследователь и реверс-инженер. Более 24 лет занимаюсь обратным проектированием, с 2007 года — кандидат технических наук, и вот уже 7 лет работаю ведущим специалистом в отделе анализа приложений в компании Positive Technologies.

Последние девять лет занимаюсь исследованиями промышленных ПЛК и embedded-устройств, особенно интересны прошивки с редкими процессорными архитектурами. Находил CVE в оборудовании и программных системах Mitsubishi Electric, Schneider Electric, WAGO, CODESYS.

Помимо этого, я увлекаюсь автоматизацией задач обратного проектирования и являюсь автором процессорного модуля NIOS II для IDA Pro, который участвовал в Hex-Rays Plug-In Contest 2018. Полученными знаниями делюсь на конференциях по безопасности: Positive Hack Days (2013-2018, 2022), ZeroNights (2013), OFFZONE (2023), HITBSecConf (Amsterdam, 2014), Hackron (Tenerife, 2018), Nullcon (Goa, 2023). Например, на PHDays 7 показал атаки на ПЛК с принтера с модифицированной прошивкой, а на PHDays 11 рассказывал про предобработку бинарных файлов в IDA Pro с помощью скриптов.

Моя специализация в проектах — разбирать сетевые протоколы и форматы данных ПЛК, чтобы продукты компании могли их понимать. Попутно в процессе исследований возникают задачи поиска уязвимостей. Иногда я разрабатываю шеллкоды — импланты в прошивки — для демонстрации различных proof of concept (PoC).

В своей работе я использую дизассемблер IDA Pro, дополняя его функции разработанными мной средствами автоматизации обратного проектирования и другими скриптами на IDAPython. Для анализа сетевых пакетов применяю Wireshark, а для взаимодействия с устройствами разрабатываю скрипты на Python. Чаще всего работаю с редкими архитектурами процессоров, в частности Hitachi, Renesas H8, SuperH, NEC, Siemens и NIOS. Нередко в проектах мне попадаются прошивки, в которых мало подсказок, иногда нет даже текстовых строк.

Для быстрой навигации:

  • Как устроены ПЛК и чем они отличаются от других систем
  • Способы атак на промышленный контроллер
  • Какие последствия могут быть при атаке на промышленный контроллер
  • Реальные случаи атак на технологические процессы
  • Контроллеры Mitsubishi Electric
  • Задачи исследования и первые шаги в поиске решения
    • M Protocol
    • M Protocol vs PCAP (Read Random)
    • PCAP vs Manual (Read Random)
    • M Protocol vs Manual (Read Random)
    • Правило RTFM и что можно достать из мануалов
    • Как может помочь GX Works 3 — утилита от производителя
    • Строение симулятора и его связь с ПЛК
    • Запуск симулятора и брутфорс команд
    • Документация для родственного протокола
    • Коды ошибок из документации
    • Проецирование адресов внутри симулятора
    • Описание протокола
    • Устройства и команды
    • Демо в стиле K.I.T.T., или Знание протокола — сила
    • Уязвимости и взаимодействие с вендором
      • Уязвимость CVE-2022-25161
      • Уязвимость CVE-2022-25162

      Вводная часть

      Как устроены ПЛК и чем отличаются от других систем

      В начале дадим основные понятия, чтобы было ясно, о чем будем говорить дальше.

      Программируемый логический контроллер (ПЛК, PLC) — это разновидность вычислительной машины для работы в системах реального времени. Применяется для автоматизации технологических процессов. Основной режим работы ПЛК — длительная автономная и надежная работа без обслуживания и вмешательства.

      Отличия ПЛК от других систем:

      • По сравнению с микроконтроллером — это самостоятельное устройство, а не отдельная микросхема.
      • В отличие от встраиваемой системы ПЛК отделен от управляемого им оборудования.
      • В отличие от компьютера, которым управляет оператор, ПЛК взаимодействует с датчиками и исполнительными устройствами через входы и выходы.

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

      Промышленные ПЛК — это развитые системы как с аппаратной, так и с программной точки зрения. Внутри них — современные процессоры, достаточное количество оперативной памяти, набор встроенных периферийных устройств, операционные системы реального времени и файловые системы.

      С точки зрения безопасности в ПЛК может применяться полный спектр средств защиты, используемых в других системах (мобильных, встраиваемых, клиентских, серверных). Самые часто используемые — это шифрование и криптографические подписи прошивок и их обновлений, парольные защиты доступа.

      На физическом уровне с ПЛК можно взаимодействовать по RS-232, RS-485 и Ethernet- интерфейсам. Как правило, для общения по сети ПЛК поддерживает как общеизвестные протоколы (TCP/IP, HTTP, FTP), так и чисто промышленные (Modbus, OPC UA и другие). Особый интерес исследователей вызывают недокументированные проприетарные протоколы для общения с ПЛК, которые вендоры реализуют в своих продуктах.

      Способы атак на промышленный контроллер

      Где может стоять промышленный ПЛК и как его можно атаковать?

      Посмотрим, как выглядит технологическая сеть глазами злоумышленника. На рисунке приведена упрощенная схема промышленной сети. Она состоит из трех частей: интернет, корпоративная сеть передачи данных (КСПД), технологическая сеть (ТС).

      В технологической сети есть три уровня. Верхний уровень включает управляющие рабочие места операторов и инженеров. На среднем уровне размещаются промышленные ПЛК, а на нижнем — датчики и исполнительные устройства.

      Как злоумышленник может атаковать ПЛК? В основном рассматривают атаку через смежные системы — путь атаки слева направо, то есть злоумышленник должен пройти всю цепочку из внешней сети интернет до ПЛК. Но это не единственный возможный вариант атаки. Представьте себе, что оператор принес USB-модем, чтобы выйти в интернет с рабочего места, или инженер подключил флеш-накопитель к серверу SCADA для обновления, или в одной подсети с ПЛК расположено многофункциональное устройство (МФУ) с дополнительным беспроводным доступом. И это все случаи из проектов и реальной жизни. Так что будем считать, что злоумышленник может подсоединиться к любому сегменту этой сети.

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

      Это зависит от двух моментов:

      1. Где установлен ПЛК. С одной стороны, можно повлиять на производство булочек, а с другой стороны — на более серьезный технологический процесс.
      2. Как можно повлиять на ПЛК и технологический процесс на его основе. Злоумышленник может остановить процесс, заблокировать его запуск, поменять управляющие воздействия, подменить входы или выходы, изменить параметры процесса или настройки ПЛК.

      В результате атаки злоумышленник может испортить качество изделий, вызвать аварию, остановить предоставление ресурсов: воды, тепла, электричества, газа — и даже вызвать техногенные катастрофы, такие как взрывы, потопы, пожары. На производствах, конечно, используется не один контроллер, потому не все так просто. Для серьезных атак злоумышленнику нужно глубоко разбираться в протоколах и технологиях взаимодействия с ПЛК. Также он должен понимать, за что отвечают разные параметры технологического процесса на конкретном объекте. Помимо этого, злоумышленник должен получить доступ к контроллерам, которые управляют этим технологическим процессом. Кроме того, на важных и опасных производствах может использоваться специальный контроллер противоаварийной защиты (ПАЗ), задача которого — независимо от работы управляющего контроллера предотвратить серьезную аварию. При этом он может остановить технологический процесс, что, безусловно, тоже является недопустимым событием для любого промышленного предприятия.

      Чтобы сопоставить эти возможности с реальностью, можно обратиться к истории и вспомнить имевшие место целенаправленные атаки на ПЛК.

      Реальные случаи атак технологические процессы

      На рисунке ниже в левой части собраны примеры вредоносов, представляющих опасность для технологических процессов. Считается, что все началось с обнаружения червя Stuxnet в 2010 году на заводе по обогащению урана в Натанзе, Иран. В проведенных позже расследованиях указывалось, что ранние версии Stuxnet существовали с 2007 года. Последние версии червя распространялись с помощью USB-флеш-накопителей, заражая рабочие станции под управлением Windows. Stuxnet перехватывал, разбирал и модифицировал пакеты протокола общения между ПЛК Simatic S7 и SCADA-системой Simatic WinCC компании Siemens. Таким образом, его создатели разбирались в протоколе и технологии взаимодействия с ПЛК. По оценке экспертов, Stuxnet нарушил работу 1368 из 5000 центрифуг для обогащения уранового топлива, таким образом замедлив ядерную программу Ирана. Следовательно, создатели Stuxnet хорошо разбирались в параметрах технологического процесса и соответствующим образом изменяли алгоритмы управления центрифугами в ПЛК. С него начался бум исследований промышленного оборудования и закрытие уязвимостей. Тем не менее такого рода вирусы стали проникать в нашу повседневную жизнь, поэтому давайте коснемся немного их современных представителей.

      Современные вредоносные программы Industroyer и Pipedream умеют работать с несколькими протоколами и семействами ПЛК. Их экземпляры были обнаружены на электрических подстанциях и в комплексах по производству сжиженного газа. Судя по поддерживаемым протоколам и семействам ПЛК, вредоносная программа Pipedream способна работать и в других технологических процессах.

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

      Контроллеры Mitsubishi Electric

      По данным сайта ladderlogicworld.com, Mitsubishi Electric в 2017 году занял третье место в мире на рынке промышленных контроллеров, выпустив свыше 17 миллионов компактных ПЛК. Серии ПЛК Mitsubishi MELSEC и масштабы систем, в которых они применяются, приведены на рисунке.

      Основные сферы применения ПЛК Mitsubishi (по информации вендора) — микроэлектроника, энергетика, автотранспорт, логистика и индустриальные роботы.

      В нашей стране контроллеры Mitsubishi часто применяются на насосных станциях и в системах вентиляции зданий. Есть еще редкие и экзотичные применения, которые встречались в проектах коллег на их прошлых работах: например, вагоноопрокидыватели, системы для ТЭЦ и даже шлюзы водохранилищ.

      Контроллеры FX линейки MELSEC iQ-F, представитель которой попал к нам на исследование, применяются для автоматизации инженерных систем зданий, в деревообработке, типографиях, пищевой и легкой промышленности, водном хозяйстве, судоходстве и других сферах.

      Теперь о том, как внешне выглядит этот ПЛК. На рисунке представлена лицевая панель Mitsubishi FX5U. Сносками обозначены индикаторы, наиболее важные из них: питания, ошибки, работы проекта и входы с выходами.

      Предварительное исследование

      Задачи исследования и первые шаги в поиске решения

      В исследовании мне предстояло разобрать протокол, научиться общаться с ПЛК по сети с помощью скриптов, найти уязвимости в прошивке и проприетарном протоколе.

      Коллеги записали и прислали сетевой трафик общения инженерной утилиты и ПЛК. На рисунке скриншот из программы — анализатора трафика Wireshark. Давайте внимательно на него посмотрим.

      Это TCP-поток, розовым выделены запросы, сиреневым — ответы. В левом столбце смещения байтов внутри TCP-потока, посередине — шестнадцатеричный дамп со значениями байтов, а справа — текстовое представление байтов дампа.

      Если внимательно посмотреть на скриншот с трафиком, то можно увидеть закономерности. Например, что у обоих запросов в начале — «57 01», а у ответов — «d7 01». Значит, используются некоторые постоянные байты, причем у ответов установлен старший бит.

      В первых строчках запросов и ответов видна последовательность «ff ff 03». В середине пакетов видим нули. В первом ответе — строка «FX5U-32MR/ES», очевидно, это номер модели ПЛК.

      На основе подобного анализа нескольких десятков пакетов протокола я получил предварительную схему, которая представлена на рисунке. Цветом выделена часть найденных закономерностей.

      В начале постоянные значения байтов, в запросах последовательность «ff ff 03» по смещению 0Ah, а в ответах — по смещению 0Eh. Зеленым выделена повторяющаяся последовательность, в которой у ответов в первом байте установлен старший бит. В конце этой последовательности число 14h, что соответствует 20 нулям, которые идут после этого поля. Далее голубым цветом выделен номер команды протокола. В ответах бордовым отмечены возвращаемые данные.

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

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

      Подобные схемы дают начальное понимание, как устроен исследуемый протокол. Мои коллеги из отдела безопасности промышленных систем в шутку называют такой тип анализа — «реверс глазами» или «глазной реверс».

      M Protocol

      Имея первоначальное описание, мы стали искать в сети Интернет открытые исследования протоколов для ПЛК Mitsubishi. Вдруг исследователи уже изучили и описали этот протокол? Этот поиск не дал результатов.

      Примерно за полгода до проекта, коллеги организовывали кибербитву на конференции Hack In The Box в Абу-Даби. Там он посетили доклад, посвященный безопасности промышленных систем и в нем упоминался М Protocol, который используется в контроллерах Mitsubishi. На рисунке представлено его краткое описание. Слева показано строение запроса, справа — строение заголовка ответа. Поля, на которые надо обратить внимание, увеличены.

      Что мы тут видим? В начале пакета фиксированные значения, есть размеры данных для запросов и ответов, в поле End Code — статус операции. Вроде подходит. Кажется, это наш протокол!

      M Protocol vs PCAP (Read Random)

      Давайте копнем глубже и сравним M Protocol с реальным трафиком.

      В обоих случаях первые байты — это фиксированные значения, которые похожи, но не совпадают. Байтовая последовательность «ff ff 03» видна в обоих случаях, но в реальном трафике она по другому смещению. В докладе представлена команда Read Random с кодом команды «03 04». В дампе с реальным трафиком нет этого значения. Следовательно, это другой протокол.

      PCAP vs Manual (Read Random)

      В документации ПЛК Mitsubishi FX5U упоминаются протоколы SLMP и MC Protocol (MELSEC communication protocol).

      Они имеют идентичное строение и два вида — текстовый и бинарный. Очевидно, что под наше описание подходит бинарный вид. Мы нашли мануал по протоколу MELSEC «FX5 User’s Manual (MELSEC Communication Protocol)» и теперь сравним его с нашим реальным трафиком.

      Здесь первые байты также фиксированные и тоже отличаются. В обоих случаях присутствует последовательность «ff ff 03», но в документации она по другому смещению. В мануале команда Device Read Random имеет код 0403h. Меняем порядок байтов, ищем последовательность «03 04» в дампе с реальным трафиком — и не находим это значение. Следовательно, это тоже другой протокол.

      M Protocol vs Manual (Read Random)

      Пробуем сравнить M Protocol с протоколом MELSEC из мануала по ПЛК Mitsubishi.

      Первые байты фиксированные и совпадают. Последовательность «ff ff 03» располагается по одинаковым смещениям. Код команды «03 04» также совпадает в обоих случаях. Получается, что M Protocol — это, по сути, то, что уже описано в мануале Mitsubishi как MC Protocol (MELSEC communication protocol).

      На рисунке выделено поле Device Code — это адресация внутренних устройств, о них мы поговорим позже. Давайте обратим внимание на значение A8 — и запомним его, оно еще пригодится.

      Предварительные результаты

      На рисунке приведен скан открытых портов, сделанный с помощью утилиты Nmap: открыты три UDP-порта и один TCP-порт. Забегая немного вперед, необходимо отметить, что по всем четырем портам работают наш исследуемый протокол.

      На основе визуального анализа пакетов я сделал предварительную спецификацию протокола и разработал начальный набор скриптов на Python для работы по нему. MitsuClass выполнял низкоуровневую работу: собирал и отсылал запросы-команды, принимал и разбирал входящие пакеты-ответы. Я посмотрел строение команд RUN, STOP и PAUSE в трафике инженерного софта и реализовал их в виде трех отдельных простых скриптов, которые базировались на MitsuClass.

      В это время началась пандемия и все сотрудники ушли на удаленку. Из-за этого мне не успели настроить удаленный доступ к ПЛК, но коллега смог забрать ПЛК домой. Поэтому я выслал скрипты ему и попросил запустить их. Далее приведен скриншот его письма с ответом.

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

      Исследование

      Для продолжения исследования требовалась прошивка. Я обратился к коллегам, чтобы они помогли ее достать.

      Эксперт по прикладной криптографии проанализировал строение файлов с обновлениями для разных серий ПЛК Mitsubishi. Его выводы:

      • обновления прошивок свободно скачиваются. Но они зашифрованы;
      • по косвенным признакам используется шифрование AES128, проверка целостности SHA256 и ECDSA256;
      • ключи AES и параметры ECDSA в прошивке (до расшифровки) не светятся, и без чтения флеша ничего извлечь не получится.
      • единственный выход — прочитать флеш-память и поискать там ключи для расшифровки обновлений.

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

      • прозвонил ножки CPU;
      • подцепил к ним JTAG;
      • успешно соединился программатором;
      • CPU вернул, что залочен и требуется ID Code для дальнейшего общения;
      • не смог сдампить флеш-память CPU.

      В итоге ни одним из примененных нами способов мы не смогли получить прошивку.

      В проектах встречались прошивки, в которых не было никаких подсказок, даже строк. Здесь впервые столкнулись с ситуацией, когда нет даже самой прошивки. Такого я еще не встречал. Я не стал опускать руки и решил продолжать исследование. Информацию для восстановления протокола я попробовал искать другими способами.

      Правило RTFM и что можно достать из мануалов

      Для начала я решил воспользоваться правилом RTFM (Read The Following Manual, «обратитесь к прилагаемому руководству»). Все знают об этом правиле, но мало кто любит его применять сразу.

      Из руководства я выделил основные особенности функционала ПЛК Mitsubishi FX5U — они приведены на рисунке. Управление ПЛК мы уже попробовали с помощью своих скриптов. Функции безопасности, обновление и настройки даты и времени я пока не стал глубоко копать.

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

      Помните значение A8 из раздела про сравнение M Protocol и мануала? Именно оно выделено на рисунке красным. Оказалось, это Data register, и тот трафик обращался к этому устройству, чтобы считать из него значения. Устройства имеют разную размерность доступа, например, Word означает, что значения считываются и записываются по 2 байта.

      Внутри ПЛК встроена своя файловая система и доступны как стандартные действия (чтение, запись, открытие и закрытие), так и расширенные (копирование, перемещение файла, удаление и другие). Настройка ПЛК Mitsubishi FX5U выполняется с помощью загрузки в него файлов с параметрами. Самые важные из них приведены на рисунке. Проект — программа, которая будет выполнятся внутри ПЛК, — также загружается через файл.

      Как может помочь GX Works 3 — утилита от производителя

      Программа GX Works 3 от Mitsubishi — это развитый продукт с большим количество функций. Ее внешний вид показан на рисунке. Давайте подробно исследуем особенности GX Works 3.

      Почему GX Works 3 — развитый продукт? Во-первых, это среда для разработки проектов и в то же время инженерная утилита. GX Works 3 позволяет настраивать параметры ПЛК, читать из устройств, писать в них, диагностировать ошибки и отлаживать проекты.

      Какую информацию можно получить из GX Works 3:

      • Команды через пункты меню.

      При выборе пунктов меню GX Works 3 запускается взаимодействие утилиты и ПЛК. С помощью Wireshark получаем трафик этого взаимодействия. Затем можно сопоставить выбранные команды и коды для них, которые встретились внутри трафика. Однако это не так-то просто: один пункт в меню часто приводит к отправке последовательности из нескольких команд.

      • Устройства через монитор пакетного чтения записи.

      В мониторе пакетного чтения записи выбираем устройство, с которым хотим работать, например Data register. Дальше задаем смещение внутри него и считываем значения, которые там хранятся. Затем в трафике видим, какой номер у конкретного устройства для исследуемого протокола.

      • Параметры настройки через разницу в файлах настроек.

      В древние времена компьютерных игр под MS-DOS использовали такой прием: в файле с настройками персонажа меняли значения байтов и проверяли, какие параметры поменялись внутри игры: жизнь, сила, выносливость и т. д. В исследовании применялся этот же прием, только наоборот. Внутри GX Works 3 изменялся параметр — устанавливались флажок или значение. Затем через разницу в файлах до и после установки параметра определялось, какие байты или биты отвечают за него.

      Строение симулятора и его связь с ПЛК

      В состав среды разработки GX Works 3 входит полезный компонент — симулятор ПЛК. В симуляторе можно запускать и отлаживать проекты для конкретной модели ПЛК, сам контроллер при этом не нужен. Симулятор поддерживает входы, выходы, таймеры и другие внутренние устройства. Для наглядности поддерживается индикация состояния как на лицевой панели ПЛК.

      Симулятор доступен на локальном сетевом интерфейсе localhost, работает только по TCP, при этом порт можно настраивать. По трафику симулятора выяснили, что в нем используется тот же протокол, что и для ПЛК.

      Так у нас появилась возможность исследовать работу ПЛК через симулятор: как он обрабатывает команды, какие исполняемые файлы используются и за что отвечают. Я решил подробно исследовать работу симулятора.

      Как это можно сделать? С помощью утилиты Process Explorer от Sysinternals узнаём, какой исполняемый файл отвечает за запуск и работу симулятора — им оказался FSimRun3.exe. Командная строка, с которой GX Works 3 запускает симулятор, представлена справа вверху. Краткий анализ показал, что исполняемый файл обращается к библиотеке FX5U.dll. Я выяснил, что эта библиотека содержит строки с именем и номером модели ПЛК, то есть симуляция ПЛК реализована в ней. Также внутри библиотеки я нашел реализацию исследуемого протокола.

      Запуск симулятора и брутфорс команд

      При запуске из-под GX Works 3 симулятор запускается в монопольном доступе и достучаться к нему не получается. Поэтому я научился запускать симулятор отдельно от GX Works 3, чтобы тестировать варианты команд. Скриншот запуска показан ниже. Через ключ —tcp можно задавать порт, на котором будет работать симулятор.

      Используя информацию о протоколе, собранную к этому моменту, я написал скрипт, который полным перебором находил все команды, реализованные в протоколе. Скриншоты с частичными результатами запуска скрипта на ПЛК и на симуляторе показаны на рисунке.

      В ПЛК было выявлено 83 команды, в симуляторе — 54. Часть команд в симуляторе — это процедуры-заглушки, которые не выполняют никаких действий, а просто возвращают сообщение об ошибке. Несмотря на это, симулятор качественно поддерживает основные команды протокола, поскольку результаты их работы идентичны командам в ПЛК.

      Реверс-инжиниринг

      И вот наконец-то мы с вами добрались до реверс-инжиниринга.

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

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

      И самая классная штука, прямо вишенка на торте — симулятор можно исследовать в отладчике.

      Дальше пойдет немножко хардкора — посмотрим, как документация и коды ошибок помогли при исследовании протокола и как это выглядит глазами реверс-инженера.

      Документация для родственного протокола

      Смотрим, какие подсказки можно вытащить из документации. Для реверс-инжиниринга динамическая библиотека FX5U.dll была открыта в дизассемблере IDA Pro.

      Слева вверху показан кусок x86-кода обработчика команд протокола. В нем вызовы обработчиков для двух разных типов команд: Type2_CmdHandler и Type1_CmdHandler . Эти имена присвоены процедурам в процессе исследования исходя из предположений о том, что они делают.

      Справа вверху представлена часть обработчика Type2_CmdHandler в виде псевдокода декомпилятора. В нем с помощью выбора case вызывается обработчик для одной из трех команд: «0401», «0403» и «0406».

      Последовательность значений «0403» нам уже встречалась. Это команда Device Read Random из документации родственного протокола.

      Смотрим подробнее процедуру Type2_Cmd_04_03 — обработчик команды «0403». В ее коде вызывается процедура sub_71927630 . Пока это имя нам ничего не говорит. IDA Pro при начальном открытии файла для всех процедур автоматически генерирует такие имена, которые содержат адреса их начала.

      IDA Pro поддерживает xrefs — перекрестные ссылки. С их помощью можно посмотреть, из каких мест в коде вызывается процедура. Слева внизу показаны перекрестные ссылки для процедуры sub_71927630 . Видим, что, помимо процедуры Type2_Cmd_04_03 , из которой мы пришли, текущая процедура вызывается из Type1_Cmd_04_11_12 . Делаем вывод, что команда из документации Device Read Random с кодом «0403» для исследуемого протокола будет иметь коды «0411» и «0412».

      Таким образом были восстановлены команды, которые имеют аналоги в документированном родственном протоколе, и сделаны общие предположения насчет групп команд.

      Коды ошибок из документации

      Рассмотрим подробнее, как могут помочь коды ошибок из документации.

      Встретился фрагмент кода (он показан в верхней части рисунка). Смотрим подробнее: это сравнение стековой переменной var_E с каким-то значением в регистре eax. Если стековая переменная меньше или равна значению, происходит переход на метку lod_718FCD24 . В ином случае в регистр ecx заносится код ошибки 413Ah (на рисунке он выделен желтым цветом). Следующей командой код ошибки заносится в поле EndCode в структуре исходящего пакета-ответа.

      В мануале код 413Ah означает, что задаваемый размер файла превысил уже существующий размер, то есть в файл попытались записать больше, чем он может вместить.

      Значит, стековая переменная var_E — задаваемый новый размер файла, и в нижней части рисунка показан результат ее переименования в ReadSizeLoc.

      С помощью кодов ошибок у меня получилось определить строение части команд и идентифицировать параметры для некоторых команд.

      Проецирование адресов внутри симулятора

      В процессе исследования я встретил интересные смещения. На рисунке примеры таких смещений выделены оранжевым цветом: 0x66184 и 0x66000. Процедура GetRealAddr берет такое смещение и проецирует на реальный адрес в памяти. Так что же это за смещения?

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

      Опытным путем получилось выяснить, что адреса вида 0x66000 содержатся в таком же виде внутри прошивки ПЛК. Получается, что симулятор тщательно моделирует работу ПЛК и совпадает даже внутренняя адресация. Это очень хорошо!

      Результаты исследования

      Описание протокола

      В результате исследования я восстановил протокол и сделал его описание. На рисунке показано общее строение пакетов исследованного протокола. Ниже в трафике цветом выделены поля для некоторых подзаголовков.

      Фиолетовым отмечен низкоуровневый заголовок — с фиксированными значениями, который мы уже рассматривали. Голубым выделен DstRouteHdr — в протоколе своя внутренняя маршрутизация, то есть он может через один ПЛК обращаться к другим. Зеленым выделен размер данных для пакета. Строение пакета для команды и ответа отличается на одно поле. В ответе дополнительно присутствует поле EndCode — статус операции, который отмечен красным цветом.

      Устройства и команды

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

      Первый столбец — это номера устройств для исследованного протокола, а последний столбец — их номера в документации для родственного протокола. Вспомним значение A8h — это Data register, и на рисунке он выделен красным цветом. Для исследованного протокола Data register имеет код 20h. Это означает, что каждый раз, когда в трафике будет обращение к устройству 20h, мы будем понимать, что идет обращение именно к устройству Data register.

      Также я смог определить предназначение большей части команд протокола. Часто используемые команды протокола приведены в таблице.

      В первом столбце указаны номера команд для исследованного протокола, а в последнем — для родственного протокола из документации. Красным выделена команда Random Read. В мануале она имеет код 0403, а в разобранном протоколе 0411. О ней упоминали в разделе про реверс-инжиниринг.

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

      Демо в стиле K.I.T.T., или Знание протокола — сила

      Итак, у нас есть протокол, но что в нем может быть интересного? Что он может дать? Какие-то таблички, описания — скучно! Но, зная только протокол, мы уже можем сделать многое с ПЛК. К примеру, вот одна ситуация, которую мы смоделировали.

      Был старый сериал «Рыцарь дорог». Главный герой владел умной машиной K.I.T.T., у которой впереди была лента из лампочек. Эта лента моргала лампочками в виде змейки, которая двигалась из стороны в сторону.

      Мы решили смоделировать эти действия на ПЛК Mitsubishi, чтобы он делал то же самое светодиодами, обозначающими сигналы на выходах. Я разработал скрипт, который, посылая команды разобранного протокола, напрямую манипулировал выходами. При этом он практически игнорировал программу, которая в данный момент выполняется на ПЛК, а в области светодиодов двигалась змейка, как у машины K.I.T.T. из сериала «Рыцарь дорог». Коллеги смонтировали наглядное демо и в шутку пририсовали мою голову к фигуре главного героя.

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

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

      Уязвимости и взаимодействие с вендором

      В результате исследования мы с коллегами нашли 15 уязвимостей. В декабре 2021 года мы отправили отчет с их описанием в Mitsubishi Electric. Они ответили достаточно оперативно и обещали быстро исправить восемь уязвимостей, связанных с самим ПЛК. По остальным семи уязвимостям внутри продукта GX Works 3 написали, что потребуется больше времени. Это вполне понятно, поскольку GX Works 3 — тяжеловесный продукт с большим количеством функций. В целом Mitsubishi Electric при взаимодействии показали себя как ответственный вендор: давали четкие ответы, согласовывали перенос релизов адвайзори и соблюдали заявленные сроки.

      В марте 2022 года вышел адвайзори с первыми шестью уязвимостями в ПЛК. Позже, в мае вендор выпустил еще один по двум уязвимостям в ПЛК, а также обновление информации по всем уязвимостям.

      Примечательно, что релиз информации о семи уязвимостях в GX Works 3 произошел в день моего выступления с этим докладом на конференции HighLoad++.

      Найденные уязвимости, связанные с ПЛК, можно разделить на два типа. Первый тип связан с защитными механизмами ПЛК, а второй — с его программным устройством. Примечательно, что мы исследовали FX5U-контроллер, но многим из обнаруженных нами уязвимостей подвержены все контроллеры серии iQ-F, а также других серий — iQ-R, Q и L.

      Дальше я рассмотрю две уязвимости, вызывающие отказ в обслуживании — CVE-2022-25161 и CVE-2022-25162. Они связаны с базовыми механизмами работы ПЛК — внутренними устройствами и файловой системой. При этом уязвимость CVE-2022-25161 имеет самую высокую оценку — 8,6.

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

      Уязвимость CVE-2022-25161

      При работе с устройствами можно задавать смещение внутри устройства, чтобы обратиться к конкретной ячейке — переменной. В коде симулятора есть процедура, которая преобразует смещение внутри устройства в реальный адрес в памяти ПЛК. В процессе исследования я назвал ее DevOff_To_RealAddr. Формула для преобразования приведена на рисунке. Реальный адрес RealAddr зависит от начального адреса устройства DevStartAddr, смещения внутри устройства DevOff и размера элементов UnitSize.

      Например, возьмем устройство с адресом DevStartAddr = 0x66000 и размером элементов в два байта — UnitSize = 2. Попробуем обратиться к смещению DevOff = 0xFFFCD000 внутри устройства. Если подставим эти значения в формулу, то реальный адрес RealAddr будет равен нулю. Возьмем это на заметку.

      Смещение DevOff проверяется на максимальное значение, чтобы не допустить обращения к памяти за пределами устройства. Привожу псевдокод части процедуры, которая вызывает процедуру DevOff_To_RealAddr:

      Видно, что если реальный адрес равен нулю, то происходит прыжок на метку RealAddr_is_Null. При этом проверки DevOff на максимальное значение не происходит. Поэтому, передавая в качестве смещения DevOff подобные большие значения, мы можем читать и писать за пределы памяти, доступной устройству, то есть обращаться напрямую к памяти самого ПЛК.

      Для рассмотренной уязвимости CVE-2022-25161 я написал PoC, который активировал уязвимость на ПЛК. Для демонстрации этой уязвимости мы использовали стенд, который моделирует работу нефтеперекачивающей станции на битве Standoff. На нем есть магистральные насосные агрегаты, запорные и регулирующие задвижки. ПЛК Mitsubishi FX5U управляет насосами и задвижками. На экране SCADA отображаются состояние и параметры технологического процесса.

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

      Уязвимость CVE-2022-25162

      Суть второй уязвимости в следующем: ПЛК Mitsubishi FX5U работает с файлами собственного формата, они состоят из тела файла (на рисунке выделено зеленым) и заголовка, который идет до этого тела. Заголовок файла содержит поле с его размером (оно выделено красным). При каждом закрытии файла выполняется подсчет контрольной суммы от содержимого тела файла. Для этого используется размер заголовка. Размер тела файла FileBodySize вычисляется вычитанием размера заголовка HeaderSize из размера файла FileSize.

      Посмотрим, что будет, если попробуем записать в ПЛК файл со строчкой «HACKER» внутри. Буквы «C» и «K» из середины строчки будут восприняты как размер заголовка. В шестнадцатеричном виде они имеют представление 0x43 и 0x4B. Получается, что размер заголовка HeaderSize достаточно большой — 0x4B43, а размер файла всего 6 байт. При вычитании получится отрицательное число, которое будет воспринято как очень большое положительное число — 0xFFFFB4C3. Подсчет контрольной суммы приведет к сбою при обращении к недопустимым адресам.

      Для демонстрации этой уязвимости мы использовали стенд, который воспроизводит работу водозаборной станции на кибербитве Standoff. На стенде есть установки забора и обработки воды, резервуары, насосы для перекачки, которыми управляет ПЛК Mitsubishi FX5U. Состояние и параметры техпроцесса отображаются на экране SCADA.

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

      Что же происходит? Давайте сравним эти два PoC.

      У уязвимости CVE-2022-25161 высокая оценка — 8,6. Можно сказать, она практически убивает ПЛК. Единственное, что может вернуть его к жизни, — аппаратная перезагрузка или сброс по питанию.

      В случае с уязвимостью CVE-2022-25162 теряется только связь с тем портом, по которому соединились. Поэтому мной была сделана добавка к PoC — скрипт, который предварительно отсоединял SCADA, затем соединялся по всем портам протокола и посылал последовательность пакетов для вызова DoS. После этих действий SCADA не может соединиться с ПЛК, то есть оператор не получает данные и не может управлять технологическим процессом.

      Заключение

      Подведем итоги исследования ПЛК Mitsubishi FX5U: у нас не было доступа к его прошивке, но это не остановило нас в исследовании ПЛК.

      По утилитам производителя, симулятору ПЛК, информации из трафика, мануалам и другим источникам мне удалось собрать информацию и восстановить протокол. Я научился общаться с ПЛК с помощью разработанного набора скриптов. Вместе с коллегами мы нашли пачку из 15 уязвимостей, которые признал производитель и выпустил для них обновления безопасности.

      Благодарности

      Благодарю за помощь в проекте соавторов найденных уязвимостей: Дмитрия Склярова, Владимира Назарова, Илью Рогачева и Артура Ахатова, а также весь отдел безопасности промышленных систем компании Positive Technologies.

      Понравилась статья? Жду ваши комментарии и вопросы.

      Кстати, это еще не финал моего исследования. На очереди вторая часть. В ней я расскажу о механизмах защиты ПЛК Mitsubishi FX5U и остальных 13 уязвимостях, которые связаны с этими механизмами, а также раскрою некоторые детали процесса исследования и его результаты.

      Антон Дорфман

      Ведущий специалист отдела анализа приложений Positive Technologies

      В нашем блоге есть еще много интересных статей про кибербезопасность, технологии, инструменты и новейшие подходы к защите от кибератак. Читайте и подписывайтесь, чтобы не пропустить новые посты.

      • реверс-инжиниринг
      • плк
      • прошивка
      • mitsubishi
      • уязвимости
      • промышленность
      • ida pro
      • сетевой протокол
      • промышленные системы управления
      • уязвимости и их эксплуатация
      • Блог компании Конференции Олега Бунина (Онтико)
      • Блог компании Positive Technologies
      • Информационная безопасность
      • SCADA
      • Реверс-инжиниринг
      Похожие публикации:
      1. В чем сходство и отличие
      2. Как в яндекс почте найти письмо по дате
      3. Как заработать в steam
      4. Как остановить меркурий 230 ам 01

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *