- PVSM.RU - https://www.pvsm.ru -
Многие современные компьютерные системы (материнские платы в ПК, смартфоны, сетевое оборудование…) работают под управлением прошивки, которая, как правило, разрабатывается под конкретное железо, может использовать весь спектр доступных аппаратных ресурсов и имеет самые высокие привилегии. Защите прошивок необходимо уделять особое внимание, иначе она будет настоящей Ахиллесовой пятой в безопасности системы.
Этому вопросу будет посвящён небольшой цикл статей, мы покажем слабую и сильную модели безопасности прошивок на реальных примерах.
Кстати, в основе этой статьи – наше исследование защищённости промышленных сетевых коммутаторов, которое было представлено мной на хакерской конференции ZeroNights 2015 [1] (доклад «Модификация прошивок промышленных свитчей», презентация лежит здесь [2]).
Вначале расскажем об объектах нашего исследования – промышленных коммутаторах.
Сердцем любой современной инфраструктуры АСУ ТП является среда передачи данных. В подавляющем большинстве случаев она представляет собой промышленную сеть типа Industrial Ethernet, т.е. основанную на семействе технологий Ethernet. Такая сеть от обычной отличается, прежде всего, использованием протокола реального времени (например, Profinet, EtherCAT, Ethernet/IP и другие).
Пример промышленной сети [картинка отсюда [3]]:
Различного рода устройства (ПЛК, панели HMI, управляющие ПК, полевые устройства и прочие) к сети подключаются через сетевые коммутаторы (свитчи) промышленного типа. В отличии от обычных коммутаторов они менее требовательны к условиям эксплуатации (расширенный диапазон рабочих температур, защита от перепадов напряжения, ударопрочность, возможность крепления на DIN-рейку и т.д.) и поддерживают промышленные сетевые протоколы.
Таким образом, промышленные коммутаторы являются критическим элементом структуры промышленной сети. Очень важно должным образом защищать их от компрометации потенциальным злоумышленником потому, как это позволит получить практически безграничные возможности контроля над технологическим процессом: компрометация других устройств в сети, вмешательство и изменение данных внутри различных соединений между ПЛК и SCADA, между шлюзами и ПЛК, подделывание данных, передаваемых на HMI и в системы журналирования и т.д. Всё это может повлечь за собой потерю контроля оператором над реальным состоянием технологического процесса и, как результат, остановку или аварию.
Чтобы этого не произошло:
О последнем и поговорим.
Для исследования мы взяли по одной модели управляемых промышленных коммутаторов от двух самых распространённых производителей промышленного сетевого оборудования:
Управлять работой этих свитчей можно через COM-порт (у обоих есть разъём RS-232) или на сетевом уровне.
При работе через COM-порт мы имеем дело с консолью для ввода команд:
Доступ к консоли требует ввода логина и пароля. Тем не менее, до экрана аутентификации доступны некоторые опции, например, вывод на экран информации о железе и прошивке, обновление прошивки и т.п.
При работе со свитчом по сети можно достучаться (по его IP-адресу) до веб-интерфейса:
Для доступа к нему требуется аутентификация.
Ещё один вариант управления свитчом на сетевом уровне — протокол SNMP (Simple Network Management Protocol), в котором тоже есть аутентификация. Однако, поддержка SNMP в исследуемых свитчах имеет несколько недостатков:
Вначале поговорим об исследовании коммутатора Hirschmann RS20, затем обозначим особенности Phoenix Contact FL SWITCH MM HS в сравнении с этим свитчом.
Сначала необходимо достать прошивку, понять, что за процессор её исполняет, и оценить возможность подключения программатора/отладчика. Для этого мы заглянули внутрь и увидели:
Микросхема флэш-памяти выполнена в корпусе BGA. Если мы её выпаяем, будет очень сложно впаять её обратно без инфракрасной паяльной станции. Поэтому прошивка (версии 8.0.07) для этого коммутатора была слита с открытого ftp-сервера Hirschmann [4].
Один из файлов в скачанном архиве – бинарник rsL2E.bin (около 4 МБ), это и есть образ прошивки. Покопавшись в нём, мы увидели, что он состоит из двух модулей. Каждый модуль имеет заголовок (их структура одинакова), а также сжатое тело.
Первый модуль сжат по алгоритму zlib (RFC 1951). Именно в нём хранится исполнимый код. В распакованном виде модуль весит примерно 7 МБ.
Второй модуль сжат по алгоритму gzip (RFC 1952), в нём находится pack200-архив, после распаковки которого получается JAR (Java Archive) файл, представляющий собой реализацию веб-интерфейса устройства. После распаковки модуль весит примерно 3 МБ. Кстати этот файл передаётся на хост (управляющий ПК) при обращении к коммутатору по его IP-адресу (т.е. при попытке доступа к веб-интерфейсу устройства) и исполняется именно на нём (на хосте).
Видно, что суммарный объём распакованных модулей составляет 10 МБ, а объём флэш-памяти на системной плате устройства – 8 МБ. Поэтому мы предположили, что образ прошивки хранится в запакованном виде. А значит, должен быть и загрузчик, который эту прошивку распаковывает и запускает. Но о загрузчике позже.
Размер каждого заголовка модуля составляет 256 байт. Структура его нигде не документирована, поэтому пришлось разбирать методом научного тыка. Поля, которые привлекли наше внимание:
Исходя из этого, можно сделать вывод о наличии контроля целостности прошивки. Но контроль подлинности, обычно это ЭЦП (электронно-цифровая подпись), отсутствует.
Возможность подделывать эти прошивки обязательно надо проверить, для этого мы написали небольшой скрипт, позволяющий быстро извлекать оба модуля из образа прошивки, и, после внесения в них изменений – собирать обратно в готовый образ:
Но, прежде чем вносить изменения, надо подумать. И поревёрсить.
Оказалось, внутри прошивки находится код ОСРВ (операционная система реального времени) VxWorks, причём довольно древней версии 5.4.2 (где-то 1998 год). На момент написания статьи самая последняя версия — 7.
В китайских «интернетах» [5] мы нашли исходники для VxWorks 5.5, что существенно облегчило идентификацию различных функций ОС, libc-процедур и прочего. Тот, кто сталкивался с задачей анализа VxWorks кода наверняка сейчас подумает: «Посмотри в конец, у VxWorks-образов всегда есть таблица символов!». Она есть, но в таком виде почти бесполезна:
VxWorks — продукт модульный, и состав модулей определяет заказчик, когда покупает исходники. В этом случае, помимо базовых компонентов, мы увидели модули веб-сервера (EmWeb), SnmpOverHttp (да-да, в снятом трафике мы видели SNMP-пакеты внутри HTTP-запросов) и прочие.
О наполнении вендор определённо позаботился.
А вот о безопасности — не очень. Здесь линейное адресное пространство, исполнение кода может осуществляться из любого места в памяти, защиты от переполнений на стеке тоже нет и т.д. Элементарные механизмы защиты от эксплуатации бинарных уязвимостей отсутствуют напрочь. Может, они не нужны? Но ведь зарегистрированных уязвимостей для этой версии VxWorks полно [6]:
Выбирай на любой вкус: DoS (Denial of Service), RCE (Remote Code Execution), возможности для подбора (brute-force), возможности для обхода авторизации. Перечень не полный.
Но не надо расстраиваться! Ведь в ходе анализа прошивки были найдены очень интересные фрагменты кода:
Поревёрсили, теперь можно похачить.
Для этого следует грамотно выбрать место для внедрения кода: нельзя допустить, чтобы он препятствовал нормальному функционированию коммутатора, и лучше всего, если он будет вызываться по требованию.
Очевидным выбором стал один из обработчиков консольных команд. Конкретнее, обработчик команды «logout». На его место в прошивке мы записали код, считывающий память заданного размера по заданному адресу (всё задаётся в переменных в конце вставленного фрагмента), и выводящий снятый дамп в COM-порт:
Мы сделали готовый образ, обновили им коммутатор (обновлять прошивку можно и через COM-порт, и через веб-интерфейс). Успех! Действительно, после ввода команды logout вместо того, чтобы разлогиниться, теперь выводился дамп памяти:
Тем самым, подтвердилась возможность подделывать прошивки.
Но как злоумышленник может внедрить свою прошивку в коммутатор, реально использующийся на промышленном объекте?
Рассмотрим возможность обновления через COM-порт (т.е. через консольный интерфейс). Как уже говорилось, чтобы обновить прошивку коммутатора не требуется знать логин и пароль, но необходимо иметь физический доступ к устройству (чтобы воткнуться в RS-232). В этот вариант слабо верится, если устройство уже используется на объекте.
Тем не менее, с завода-изготовителя свитч сразу не попадает на промышленный объект. В схеме доставки до заказчика всегда есть промежуточные организации, которые имеют возможность, в качестве бесплатного бонуса, загрузить на коммутатор неоригинальную прошивку.
Еще вариант (правда это уже вектор распространения): заразить прошивку свитча можно с предварительно скомпрометированного управляющего ПК, который уже подключён к свитчам по COM-порту.
Удалённо модифицировать прошивку свитча сложнее, но attack surface гораздо шире. Вспомним, что для доступа к веб-интерфейсу коммутатора требуется аутентификация. Что можно сделать? Попробовать:
Кстати, удалённо — это не только с ПК, подключённого к коммутатору. А также с одного из полевых устройств, которые, бывает, находятся на неохраняемой территории. А значит должны быть обязательно похачены!
Вывод следующий. Потенциальный злоумышленник при внедрении своего кода в прошивку коммутатора имеет возможность:
Заметим, что скомпрометированный коммутатор можно «вылечить» путём штатной процедуры обновления прошивки. Главное, чтоб в подлинности нового образа вы были уверены.
В любом случае, это сразу наводит на вопрос о возможности закрепления на устройстве с тем, чтобы вносимые в прошивку изменения «переживали» бы любые обновления. И тут мы вспомнили про загрузчик, дампа которого у нас не было.
Понадеявшись, что загрузчик оставил след в оперативной памяти, мы дампили (при помощи вышеописанного фрагмента кода) её в разных местах, но ничего не нашли. И решили попробовать достать его из флэш-памяти коммутатора, дёргая ранее найденные процедуры для чтения флэш-памяти. И снова успех.
Итак, содержимое флэш-памяти можно условно разделить на три региона:
Код загрузчика позволил нам реконструировать ранние этапы процесса загрузки коммутатора.
При старте первые 4 КБ флэш-памяти (а это как раз размер стартового кода) проецируются в адресное пространство CPU по адресу 0. С этого адреса начинается исполнение.
Задача стартовой части загрузчика заключается в конфигурировании карты памяти, распаковке основной части загрузчика в память и передаче ей управления.
Основной код загрузчика должен:
Сразу на ум приходит способ модификации загрузчика. Коммутатор обновляется модифицированной версией прошивки, которая, используя штатные процедуры для работы с флэш-памятью, перепишет область bootblock.
В дальнейшем, модифицированный загрузчик будет иметь возможность при каждой загрузке вносить изменения в распакованный образ прошивки. Скомпрометированный таким образом коммутатор «вылечить» уже не так просто.
Возможно ли «вылечить» свитч штатными средствами? Для этого надо обновить на оригинальные и прошивку, и загрузчик.
В консольном интерфейсе возможности обновлять загрузчик нет, хотя в коде прошивки были найдены процедуры, предназначенные для обновления области bootblock таким же образом, как обновляется прошивка. Но эти функции нигде не вызываются, стало быть, это недокументированный отладочный функционал.
А вот в веб-интерфейсе коммутатора была найдена вполне себе штатная опция для обновления загрузчика:
Вопрос только в том, чем обновлять? А ничем!
В архиве с образом прошивки для многих моделей своих устройств Hirschmann не прикладывает образ загрузчика. И исследуемая модель в их числе.
Получить образ загрузчика, связавшись с техподдержкой, тоже не получится. Мы пытались, и получили ответ, что образы загрузчика не распространяются. Единственное, что удалось от них добиться, – предложение отправить девайс им, воспользовавшись формой RMA. Однако они всячески будут отговаривать вас это делать, искренне считая этот процесс бесполезным.
Таким образом, потенциальный злоумышленник имеет возможность через модификацию прошивки закрепляться в загрузчике устройства. И выцепить его оттуда штатными средствами практически невозможно.
На данный момент у нас нет ответа на этот вопрос, но идею озвучит стоит.
Вспомним, что у этого устройства есть ещё одна исполнимая среда, со своей, в некотором роде, прошивкой. Это ПЛИС (программируемая логическая интегральная схема), типа CPLD от Marvell с внутренней энергонезависимой конфигурационной памятью.
Программы для них пишутся на языке описания логики (VHDL, Verilog – самые распространённые). Напомним, что в коде прошивки коммутатора, мы нашли функции для чтения и перезаписи этой конфигурационной памяти.
При исследовании этого свитча мы прошли тот же путь, только быстрее. Что интересного внутри:
Образ прошивки для этого коммутатора мы скачали с официального сайта вендора и таким же способом разобрали её структуру. У неё есть заголовок и сжатое по алгоритму zlib (RFC 1951) тело:
Основные поля в структуре заголовка:
Здесь тоже отсутствует контроль подлинности прошивки, мы это экспериментально проверили.
Здесь тоже VxWorks, правда немного более новой версии 6.1 имеющая те же проблемы: отсутствие механизмов защиты от эксплуатации бинарных уязвимостей и пачка зарегистрированных CVE.
Обновлять прошивку можно теми же способами:
К слову о пароле. Согласно документации, существует инженерный пароль, на случай если текущий пароль утерян (ну или никогда не приобретался, если ты хакер). Для этого необходимо обратиться в техподдержку, предоставив им MAC-адрес и серийный номер коммутатора.
Это говорит о том, что есть алгоритм преобразования этих чисел в инженерный пароль.
У данного коммутатора тоже есть загрузчик, который может быть перезаписан. И это экспериментально доказано. Штатных возможностей для обновления загрузчика нет вообще.
В результате проведённого исследования выявлены следующие недостатки в архитектуре промышленных коммутаторов:
В ходе исследования мы показали возможность подделывать прошивки коммутаторов, а также возможность закрепления модификаций в загрузчике.
Короче, похачено.
Реальный пример правильной, на наш взгляд, модели безопасности прошивки, будет рассмотрен в следующей статье.
Автор: Digital Security
Источник [7]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/111045
Ссылки в тексте:
[1] ZeroNights 2015: http://2015.zeronights.ru/
[2] здесь: http://2015.zeronights.ru/assets/files/13-Ermolov.pdf
[3] отсюда: http://www.icpdas.com/root/product/solutions/industrial_communication/fieldbus/ethernet_ip/ethernet_ip_intro.html
[4] открытого ftp-сервера Hirschmann: https://www.pvsm.ruftp://ftp.hirschmann-usa.com/INET-IndustrialNetworking/Firmware/RS20-30-40/RS20-30-40_Enhanced/
[5] китайских «интернетах»: http://en.pudn.com/downloads182/sourcecode/embed/detail848724_en.html
[6] полно: http://www.cvedetails.com/vulnerability-list/vendor_id-95/product_id-15063/Windriver-Vxworks.html
[7] Источник: https://habrahabr.ru/post/276345/
Нажмите здесь для печати.