В прошлых двух частях (1, 2) было рассказано про найденные с помощью ИИ уязвимости, бэкдоры и недокументированные возможности для свитчей SNR и Huawei. В этой части пойдёт речь о бэкдоре в оборудовании OLT C-Data - операторском оборудовании для подключения абонентов по технологии EPON/GPON. В начале статьи будет описан сам бэкдор, а затем рассказано об особенностях использования ИИ для его поиска.
В прошлой статье было рассказано как “в три промпта” был получен shell для свитча SNR-2990X-24FQ (OEM DCN), в этой статье будет рассказано о более сложном реверс-инжиниринге свитча одного из топ-вендоров в мире сетевого оборудования.
Некоторые производители поставляют свои прошивки в незашифрованном виде, без защиты от реверс-инжиниринга и даже с debug-символами. Еще 5 лет назад, для того чтобы раскопать что-то в такой прошивке приходилось копаться с binwalk, делать свои скрипты и просматривать множество файлов вручную на предмет чего-нибудь интересного.
Некоторые языки программирования (например, Go и Zig) позволяют собрать приложение без каких-либо зависимостей, в том числе отвязаться от libc, тем самым создание distroless-контейнера на Go становится тривиальной задачей. Но эта же особенность может быть применена не только для создания контейнера, но и для запуска такого приложения в VM или на реальном хосте не используя какой-либо дистрибутив Linux, а используя только ядро Linux и само приложение, построенное с помощью Go (или, например, Zig). Такая возможность позволяет избавиться от дополнительных зависимостей, которые добавляют потенциальные риски с точки зрения атаки на цепочку поставок (supply chain attack).
ПО с открытым кодом (и особенно со свободными лицензиями) стало фундаментом многих (или даже большинства) информационных систем. Однако открытость кода, баг-трекера, списков рассылок и публичный способ передачи патчей/PR используются злоумышленниками.
Неопределённое поведение (Undefined Behavior, UB) в C и C++ — одна из причин, по которым разработчики всё чаще ищут языки с полностью определённой семантикой. Одним из самых коварных UB является unaligned access, с точки зрения стандарта C это, например, когда происходит попытка разыменовать указатель как uint32_t, а значение указателя (адрес) не кратно четырём. Один из частых сценариев использования, приводящих к такому UB - получение данных по сети и их интерпретация как чисел.
По разным оценкам, до 10% уязвимостей в коде на C и C++ являются следствием использования неинициализированной памяти (источники: 1, 2). Задача MemorySanitizer (далее, MSAN) - выявлять использование неинициализированной памяти в коде, то есть мусора, например в блоке кода типа if (uninit_var) {...}. Кроме уязвимостей, неинициализированная память даёт о себе знать при портировании приложения на другую платформу, смене компилятора (или поднятии версии используемого), изменении уровня оптимизации или изменении кода таким образом, что то, что раньше "случайно" инициализировалось нулями, стало инициализироваться мусором.
MSAN не является статическим анализатором, то есть для его работы требуется выполнение кода (нужны тесты/fuzzing/реальная нагрузка). Прежде чем переходить к самому MSAN, сначала разберемся почему недостаточно (или достаточно?) статического анализа, ведь даже компиляторы умеют предупреждать об использовании неинициализированных данных.