Посты
Сегодня у меня для вас обзор статьи «Blackbox-Fuzzing of IoT Devices Using the Router TL-…
13 августа 2025 г. в 20:01•Max Knyazev is typing…Зеркало Telegram
Сегодня у меня для вас обзор статьи «Blackbox-Fuzzing of IoT Devices Using the Router TL-WR902AC as Example», которую написал Тобиас Мюллер, и которую я прочитал с очень большим интересом 😅
Это прям дневник начинающего исследователя, который решил найти уязвимость в роутере TP-Link, не имея ни исходников, ни API (по сути, вообще ничего). Только черный ящик, QEMU, AFL++ и немного упрямства
Автор в статье пытался найти баг памяти в прошивке TP-Link TL-WR902AC через blackbox-фаззинг, не зная админских логов и не имея доступа к исходному коду. Он выбрал путь боли: реверс прошивки, поиск подозрительных бинарей, хук на функции внутри и создание harness, чтобы обойти ограничения архитектуры и симулировать сетевые вызовы. Самый яркий пример — wscd, демон UPnP, в котором он нашёл функцию parser_append, подающую надежду на буферный оверфлоу
Звучит просто, да? А вот и нет😳
Тобиас выяснил, что «найти уязвимость» — это только половина задачи. Другая половина — заставить программу ее по факту вызвать. Почти каждая функция требует хитро подготовленного состояния: нужный init, определенный порядок вызовов, конкретные значения в байтах и так далее. Поэтому без хорошего harness далеко уехать не получится. А harness, если что, собирается вручную, с перекрестной компиляцией под mipsel, использованием LD_PRELOAD и даже подменой libc функций
Особенно мне понравился момент с httpd_parser_main: автор нашел уязвимость в парсинге HTTP-заголовков, где strcpy делает свою грязную работу при отсутствии ожидаемой ;. Это прямо textbook буферный оверфлоу. Проблема — как туда попасть и заставить код отработать. Через Ghidra, gdb-multiarch, и подмену rsa_tmp_decrypt_bypart на простой base64-декодер — все это, чтобы просто дойти до точки, где все крашится. В какой-то момент автор даже исправлял ошибку, вызванную отсутствием \r после \n в заголовках, из-за чего получал 408 вместо нормального ответа
Если подытожить, тестирование IoT на безопасность — это вообще не про быстрые победы. Это про возню с бинарями без отладочной информации, про костыли, грабли и фиг пойми какой по счету запуск QEMU в надежде, что на этот раз не отвалится libc. Тут даже неважно, чем ты занимаешься — фаззингом, реверсом или симуляцией окружения — все упирается в одно: устройства закрытые, прошивки мутные, а документация иногда и вовсе отсутствует. Но именно в этом и кайф. В возможности вскрыть черный ящик и понять, как все устроено под капотом. И если ты все-таки находишь баг — это не просто строчка в отчете, это победа над хаосом🧐
Если вы когда-нибудь думали, что хотите заняться фаззингом железа (есть ли у вас личная жизнь?), эта статья — отличный образчик, с которым можно ознакомиться
Ух, сегодня вышел заумный пост про заумную статью. Обещаю, в следующий раз будет что-то попроще❤️
#информационная_безопасность
#интернет_вещей
Открыть исходный пост в TelegramЭто прям дневник начинающего исследователя, который решил найти уязвимость в роутере TP-Link, не имея ни исходников, ни API (по сути, вообще ничего). Только черный ящик, QEMU, AFL++ и немного упрямства
Автор в статье пытался найти баг памяти в прошивке TP-Link TL-WR902AC через blackbox-фаззинг, не зная админских логов и не имея доступа к исходному коду. Он выбрал путь боли: реверс прошивки, поиск подозрительных бинарей, хук на функции внутри и создание harness, чтобы обойти ограничения архитектуры и симулировать сетевые вызовы. Самый яркий пример — wscd, демон UPnP, в котором он нашёл функцию parser_append, подающую надежду на буферный оверфлоу
Звучит просто, да? А вот и нет
Тобиас выяснил, что «найти уязвимость» — это только половина задачи. Другая половина — заставить программу ее по факту вызвать. Почти каждая функция требует хитро подготовленного состояния: нужный init, определенный порядок вызовов, конкретные значения в байтах и так далее. Поэтому без хорошего harness далеко уехать не получится. А harness, если что, собирается вручную, с перекрестной компиляцией под mipsel, использованием LD_PRELOAD и даже подменой libc функций
Особенно мне понравился момент с httpd_parser_main: автор нашел уязвимость в парсинге HTTP-заголовков, где strcpy делает свою грязную работу при отсутствии ожидаемой ;. Это прямо textbook буферный оверфлоу. Проблема — как туда попасть и заставить код отработать. Через Ghidra, gdb-multiarch, и подмену rsa_tmp_decrypt_bypart на простой base64-декодер — все это, чтобы просто дойти до точки, где все крашится. В какой-то момент автор даже исправлял ошибку, вызванную отсутствием \r после \n в заголовках, из-за чего получал 408 вместо нормального ответа
Если подытожить, тестирование IoT на безопасность — это вообще не про быстрые победы. Это про возню с бинарями без отладочной информации, про костыли, грабли и фиг пойми какой по счету запуск QEMU в надежде, что на этот раз не отвалится libc. Тут даже неважно, чем ты занимаешься — фаззингом, реверсом или симуляцией окружения — все упирается в одно: устройства закрытые, прошивки мутные, а документация иногда и вовсе отсутствует. Но именно в этом и кайф. В возможности вскрыть черный ящик и понять, как все устроено под капотом. И если ты все-таки находишь баг — это не просто строчка в отчете, это победа над хаосом
Если вы когда-нибудь думали, что хотите заняться фаззингом железа (есть ли у вас личная жизнь?), эта статья — отличный образчик, с которым можно ознакомиться
Ух, сегодня вышел заумный пост про заумную статью. Обещаю, в следующий раз будет что-то попроще
#информационная_безопасность
#интернет_вещей