Comments 15
Очень увлекательно, спасибо, что делитесь!
Через «запредельные» DevOff к самой прошивке не подобраться? Или к какой-нибудь области RAM, где мелькает ключ обновления в процессе установки? Наверняка же попробовали :)
Дотянуться через DevOff до чего-то "вкусного" типа прошивки или ключей пробовал многими возможными способами и через разные устройства. :-)
Там есть какие-то данные и они активно используются, поскольку запись в них приводит к DoS. Чтобы понять как их можно использовать более "умно" нужен код прошивки, которого нет. :-)
Антон, вопрос чисто из любопытства: на какой операционной системе работает ПЛК SIEMENS S7-1500?
Конкретно эту модель ПЛК не исследовал, поэтому здесь ничего ответить не могу. Возможно, кто-то из моих коллег смотрел ее, попробую узнать.
Уточнил. По информации от коллег в ПЛК SIEMENS S7-1500 используется проприетарная OS Adonis версии S14.3.13.
Вспомнилось: есть ещё младшее семейство, FX3, на базе уязвимых STM32, их китайцы вовсю копируют и на Али продают. У них, случайно, кодовая база с FX5 не общая? Возможно, удалось бы сдампить прошивку FX3 и почерпнуть из неё что-то применимое на FX5, чем чёрт не шутит?
Насколько мне известно у FX5 и FX3 нет ничего общего. Коллега подсказал по FX3, что китайцы воспроизводят только линейки младших серий из-за того, что им отдали урезанные прошивки. Это ПЛК с маркировкой на конце -00 или -A, которые Митсубиши поставлял для внутреннего рынка Китая.
Почему STM32 сразу уязвимы? Это же просто микроконтроллер.
а я видел примеры самопальных прошивок (в исходниках) которые упрощенно реализуют протокол младших ПЛК этого производителя, чтобы их родной софт можно было использовать. Продают же недоПЛК где один контроллер (причем уже даже и не STM) и немного обвязки.
я вот не очень пнял похоже: протокол вообще не шифрованный, без аутентификации особой и вообще много чего можно натворить просто передавая байты? При этом в описании CVE - сплошняком пароли и хеши.
Это тем более удивительно что прошивку сильно закрыли от считывания. Похоже это не ставило цели повысить защиту информационного обмена, а тупо защита от пиратства
В вашем комментарии несколько мыслей, попробую ответить по порядку.
протокол вообще не шифрованный
Не шифрованный, как и большинстве промышленными протоколов. В них редко применяется шифрование по следующим причинам.
Шифрование может мешать требованиям по надёжности.
Предполагается, то оборудование стоит в защищённом периметре.
без аутентификации особой
При этом в описании CVE - сплошняком пароли и хеши.
Этому будет посвящена вторая часть статьи.
вообще много чего можно натворить просто передавая байты?
Если есть знание протокола, нет никакой защиты или она не включена, то можно сделать очень многое.
Это тем более удивительно что прошивку сильно закрыли от считывания.
От считывания она защищена возможностями микрочипа и обновления прошивки зашифрованы. Это частое явление в мире ПЛК, принтеров и различных IoT устройств.
защита от пиратства
Про это тоже будет во второй части статьи.
интересная статья
ПЛК Mitsubishi: как разобрать сетевой протокол и найти уязвимости в устройстве без использования прошивки