tezeb/accflyРаскрытие уязвимостей камер Accfly: CVE-2020-25782, CVE-2020-25783, CVE-2020-25784, CVE-2020-25785.
В начале 2020 года, на моём прежнем месте работы, мне довелось принять участие во внутреннем мероприятии в стиле pwn2own. Было несколько доступных целей, но больше всего меня заинтересовала беспроводная охранная камера Accfly. К сожалению, я не успел завершить своё исследование к самому мероприятию, но, поскольку других попыток взломать это устройство не было, я продолжил работу.
Основное внимание в исследовании было уделено уязвимостям, которые могут привести к удалённому выполнению кода (RCE). Такой тип уязвимости позволяет атакующему получить полный контроль над устройством, а в случае видеокамеры может привести к полной компрометации конфиденциальности владельца. К сожалению, прошивка устройства оказалась нашпигована подобными проблемами.
Во-первых, устройство не предоставляет никакой аутентификации. В результате атакующий, способный подключиться к нему, может свободно получить к нему доступ и перенастроить его. В простейшей форме можно постоянно перезагружать устройство, делая его полностью непригодным для легитимного пользователя. Масштаб этой атаки несколько ограничен, поскольку устройство предназначено для использования в сети Wi-Fi, обычно за NAT, и, таким образом, недоступно напрямую из Интернета. Однако отсутствие шифрования между устройством и приложением на смартфоне владельца, а также использование сервера производителя в качестве прокси для связи, создаёт возможность для атак MitM или манипуляций с DNS, которые могут обойти ограничение NAT в Wi-Fi.
Кроме того, приложение использует проприетарный бинарный протокол для связи. Он реализован на смеси C и C++ и, как выяснилось, полон небезопасных функций обработки строк. Основной исполняемый файл содержит огромное количество неиспользуемого кода, что говорит о том, что он повторно используется на других устройствах. Это усложняет сопровождение и увеличивает поверхность атаки. Приложение не включает никаких современных механизмов безопасности, которые защитили бы его от многих распространённых техник эксплуатации. Более того, оно даже не ограничивает права пользователя, работая от root — с максимально доступными привилегиями.
В результате этого исследования были задокументированы следующие четыре уязвимости.
CNetClientManage::ServerIP_Proto_Set при обработке входящих сообщенийCNetClientTalk::OprMsg при обработке входящих сообщенийCNetClientGuard::SubOprMsg при обработке входящих сообщенийCFtpProtocol::FtpLogin во время процедуры обновленияДля трёх из них были разработаны эксплойты RCE, которые позволяют атакующему получить полный контроль над устройством. Однако из-за отсутствия ответа производителя на попытки сообщить об уязвимостях этот репозиторий содержит только ограниченные PoC-эксплойты, которые просто вызывают крах приложения.
Проблемы были обнаружены в версии ПО V3.10.73 и подтверждены в версии ПО V4.15.77 — последней доступной на момент публикации (26 января 2021 года).
Если у вас возникнут вопросы, не стесняйтесь связаться со мной по электронной почте (см. git-коммит) или через GitHub issues. Если у вас есть IoT-устройство, которое, по вашему мнению, может быть интересно взломать, вы ищете исследователя безопасности или просто хотите поздороваться, я буду рад услышать вас. Вы также можете угостить меня кофе!
Целевое устройство — это видеокамера, управляемая сопутствующим мобильным приложением. Мой анализ начался с сетевого трафика камеры и продолжился изучением её прошивки. Для всей связи используется собственный бинарный протокол. Команды либо отправляются напрямую на мобильное устройство, когда оно находится в той же сети, либо проходят через сервер производителя устройства. Само программное обеспечение камеры прослушивает несколько портов: TCP (23456,34567) и UDP (34568, 34569). Сетевой трафик не шифруется и не аутентифицируется, что допускает MitM-атаки или прямой доступ, когда камера доступна в сети. Вероятно, доступ к видеопотоку также возможен без аутентификации, но я недостаточно изучил проприетарный протокол, чтобы проверить это.
После краткого обзора взаимодействия следующим шагом была попытка получить доступ к прошивке устройства. Моей первой попыткой было скачать её напрямую, перехватив процесс обновления устройства, но ничего подобного в сетевом трафике не происходило. Я бы застрял на этом этапе, если бы не своевременная помощь коллеги, который извлёк прошивку из флеш-памяти, что позволило мне продолжить исследование.
Выяснилось, что прошивка запускает Linux на MIPS-процессоре с little-endian порядком байтов. Есть ровно один интересный процесс, называемый Alloca, который отвечает за захват видео, а также обрабатывает все сетевые взаимодействия. Приложение написано на C++ и содержит много кода, который на этом устройстве не используется. Это указывает на то, что то же самое ПО используется и на других устройствах.
Хотя эта проблема была обнаружена последней, она имеет решающее значение для реальной эксплуатации большинства остальных, поскольку все они проистекают из использования небезопасных строковых функций языка C. Хотя существует несколько техник, которые можно использовать для успешного выполнения кода в аналогичных сценариях, приложение создано таким образом, что они в основном бесполезны. Основная проблема в том, что код и данные Alloca статически размещаются по низким адресам ( < 0x01000000). Поэтому попытки повторного использования существующего кода (то есть ROP и подобных) бесполезны, поскольку они требуют возможности записывать адреса в память программы. Поскольку строки языка C используют \x00 в качестве завершающего символа, а строковые функции прекращают обработку на первом таком байте, невозможно использовать более одного NULL-байта. Кроме того, расположение стека рандомизировано, а приложение интенсивно использует многопоточность, что делает другие техники гораздо менее надёжными.
Эта уязвимость является результатом совместного использования данных несколькими потоками и небезопасного использования strcpy. Хотя я долго анализировал эту конкретную проблему, мне не удалось заметить возможность использовать её в качестве вектора утечки данных вплоть до последних нескольких недель перед этой публикацией. Что довольно интересно, благодаря утечке адреса кучи C++-объекта эта уязвимость также позволяет выполнять удалённый код. Однако эта атака не включена в данный отчёт.
Приложение Alloca может обновлять себя через FTP. Эту операцию может запросить сервер, который также предоставляет необходимые имя пользователя, пароль и имя файла. Функция, которая запускает обновление, показана здесь:
Три вызова strcpy, очевидно, небезопасны и приводят к переполнению кучи, поскольку объект ftpUpgrade выделяется динамически. К сожалению, порядок выполнения копирований и структура объекта ftpUpgrade делают невозможным реальный запуск потока, который утечёт данные. Более внимательный взгляд на входящий пакет выявляет следующую структуру: