RCE — анализ дешевого повторителя Wi-Fi
Аппаратный и прошивочный анализ уязвимого устройства
Опубликовано 13 апреля 2023 г.
Несколько лет назад я получил от друга старый повторитель Wi-Fi. В то время он мне не пригодился, и в итоге я забросил его в угол своего дома. Несколько дней назад, когда я решил немного изучить его, я неудивительно обнаружил, что оно не очень безопасно, поэтому я решил сделать сообщение в блоге, чтобы показать, насколько интересным может быть анализ такого рода устройств.
Рассматриваемое устройство представляет собой повторитель Wi-Fi Aigital, показанный ниже во всей красе.
Анализ веб-приложения
Ретранслятор имеет веб-интерфейс, что является довольно распространенной функцией для устройств такого типа. Чтобы найти первую уязвимость, нам даже не нужно использовать какие-либо сложные инструменты или специальные методы, нам просто нужно войти в систему один раз, чтобы понять, что как только законный пользователь войдет в систему, любой другой пользователь, который сможет получить доступ к веб-интерфейсу, будет авторизован по умолчанию! Фактически, проверяя HTTP-запросы, мы видим, что файлы cookie сеанса не используются, а вместо этого используется механизм, основанный на времени. Это даст злоумышленнику простой способ обойти вход в систему .
Из того же веб-интерфейса мы можем даже загрузить учетные данные в виде обычного текста с/config.dat
и у нас также есть сохраненный XSS в поле SSID. Вот и все, да? Судя по тому, что мы видели до сих пор, я так не думаю. Теперь давайте откроем устройство и посмотрим, что внутри.
Аппаратный анализ + дамп прошивки
Для этого устройства мы пропустим этап разведки, поскольку все, что нам нужно, доступно прямо на наших глазах, как только мы снимем пластиковую крышку. Мы можем быстро распознать флэш-память SPI и с помощью мультиметра определить интерфейс UART, который наверняка является первым, к чему мы хотим попытаться получить доступ к устройству.
На следующем этапе мы используем логический анализатор для определения всех параметров, которые нам понадобятся для взаимодействия с UART. Для этого мы подключаем вывод UART TX устройства к первому каналу (в данном случае) нашего логического анализатора, а GND UART — к выводу GND логического анализатора. Затем мы загружаем устройство и получаем сигнал, показанный на изображении:
Как показано выше, ширина наименьшего фрагмента информации, полученной от устройства, составляет 26 мкс, что соответствует скорости передачи данных 38400 бит/с. На этом этапе мы можем установить эту информацию в программном обеспечении логического анализатора, чтобы проверить, получаем ли мы значимые данные от устройства.
Мы уменьшаем масштаб и… Да! мы получаем журналы загрузки. Теперь пришло время попробовать взаимодействовать с UART и посмотреть, что мы можем сделать. Для этого я использовал совершенно новую, еще не выпущенную плату Bruschetta от Луки Бонджорни, которая поддерживает UART, JTAG, SPI, I2C и использует сдвигатели уровня, чтобы мы могли работать с устройствами с разным напряжением. В данном случае у нас есть TX 3,3 В, поэтому нам просто нужно установить перемычку на Bruschetta на правильное напряжение, подключить TX, RX, GND соответственно и запустить приложение экрана на машине с Ubuntu следующим образом:
screen -L uart.log /dev/ttyUSB0 38400
Мы получаем много интересной информации из журналов загрузки, но, к сожалению, не получаем оболочку, защищенную паролем.
После нескольких попыток войти в систему с типичными слабыми комбинациями администратора и пароля я сдался и возложил все свои надежды на SPI, который мы видели ранее, я отпаял флэш-память и снова использовал Bruschetta, чтобы сбросить прошивку внутри.
Использование flashrom и команды
sudo ./flashrom -p <chip_type> -r ../../AIGITAL/aigital-dump.bin
Наконец-то я что-то получил. Давайте запустим binwalk, чтобы проверить, что у нас получилось:
Хороший! Мы видим, что получили файловую систему Squashfs, типичную крошечную файловую систему Linux, часто используемую для встраиваемых устройств. Теперь давайте извлечем файловую систему и посмотрим, что мы сможем найти.
binwalk -e aigital-dump.bin
Анализ прошивки + RCE
Из нашего первоначального анализа веб-приложения мы уже знаем, что используемый веб-сервер — Boa, программное обеспечение с открытым исходным кодом, обычно используемое во встроенных системах. Мы можем найти двоичный файл веб-сервера, _aigital-dump.bin.extracted/squashfs-root/bin/boa
а затем открыть его с помощью Ghidra, позволяя инструменту проанализировать двоичный файл для нас.
Как только Ghidra будет готова, первое, что мы хотим сделать (поскольку нас больше всего интересует поиск уязвимостей RCE), — это посмотреть, вызывается ли, где и как функция system
. Чтобы получить эту информацию, мы можем выполнить поиск системной функции в окне «Функции» , а затем использовать график вызовов функций , чтобы лучше понять:
После некоторого анализа кода я обнаружил, что функция FUN_00440290 — отличный кандидат на то, что мы ищем. Имя параметра «sysCmd» является большой подсказкой, и также очевидно, что функция неправильно обрабатывает ввод пользователя перед подачей его в системную команду.
Чтобы восстановить весь HTTP-вызов, вам просто нужно сравнить эту функцию с другими, которые мы видим при проверке веб-приложения: все функции POST следуют структуре /boafrm/<formName>
. Чтобы понять, что такое formName в этом случае, нам просто нужно найти sysCmd, и мы быстро найдем ссылку на функцию formSyscmd в форме в виде строки, хранящейся в двоичном виде. Следует отметить, что эта функциональность на самом деле не присутствует ни в одной из форм веб-приложения, но, как это часто бывает, код используется повторно без предварительного удаления ненужных функций. Это делает задачу более интересной для нас, поскольку мы таким образом получили RCE, как показано на изображении ниже.
Выводы
Подобные дешевые устройства очень интересно исследовать, и с их помощью можно проводить некоторые эксперименты. Я уверен, что анализировать можно было бы еще многое, но, если быть до конца честным, при перепайке SPI в прошлый раз я снес след печатной платы, и на этом мои эксперименты над этим устройством закончились :D.
CVE-2023-30402, CVE-2023-30404 и CVE-2023-30405 были присвоены уязвимостям, о которых сообщалось в этом сообщении. Спасибо за прочтение
Теги: взлом RCE Wi-Fi ретранслятор аппаратное обеспечение прошивка ghidra