На этапе настройки роутер был подключен к интернету. Но устройства, подключенные к Wi-Fi почему-то интернет не получали. Я полез разбираться. В панели роутера была вкладка с возможностью воспользоваться утилитой ping, поэтому telnet можно не включать (надеюсь, все читатели понимают, чем опасен telnet, открытый наружу?). Выглядела форма вот так:
Реализована эта фича следующим образом. Программа роутера получает от пользователя строку, содержащую адрес, затем подставляет в строку вызова команды ping:
ping -c <число пакетов> <хост>
Насколько хорошо проверяет роутер строку, содержащую адрес? Именно этот вопрос возник у меня в голове. Тогда я подставил амперсанд и команду ls. Получил вот это:
Для тех, кто не в танке
В UNIX системах мы можем заставить bash выполнять команду в фоновом режиме, подставив после нее амперсанд. При этом, мы можем подставить после амперсанда команду, и она выполнится одновременно с первой. Чем я и воспользовался в данном случае. Подставив «8.8.8.8 & ls», я получил «ping -c 3 8.8.8.8 & ls». Роутер выполнил одновременно команду ping и ls. Затем вывел результат.
Будь этот баг допущен в любом другом месте, он стал бы очень серьезной угрозой. Ведь такая уязвимость помогла бы злоумышленнику заставить роутер выполнить любую команду, или даже получить полный контроль над устройством. Подобные уязвимости классифицируются как CWE-78 (OS Command Injection) .
Мне не сиделось на месте, и я поспешил написать производителю о найденном баге. Я подробно описал модель роутера, версию прошивки и сценарий воспроизведения бага. На что получил интересный ответ:
Перевод (дословно)Как оказалось, они не учли, что я пишу из России. Данная модель роутера распространялась только в нашей стране. Переписка закончилась тем, что мне выслали новую прошивку, в которой устранены все недостатки предыдущей и добавлено много фич, но почему-то она не оказалась в публичном доступе.
Не могли бы вы проверить версию аппаратного обеспечения на нижней этикетке продукта?
У нас нет Rev. Px. Вы знаете источник или место покупки этого устройства?
Комментарии (9)
slashd
28.04.2019 17:46+1Может стоит выложить модель уязвимого устройства и новую прошивку? Или ради чего весь этот пост?
DVoropaev Автор
28.04.2019 17:53+1Смысл этого поста в том, что необходимо ВСЕГДА проверять данные на входе. Особенно, данные полученные от пользователя
vladimirad
28.04.2019 19:05+4Правильным является полное игнорирование входного потока от пользователя и подмена его на заведомо правильный.
dartraiden
28.04.2019 22:22Если злоумышленник уже получил доступ к админке вашего роутера, то ему не нужно использовать эту уязвимость. Он просто включит ssh, добавит свой публичный ключ и зайдет с правами суперпользователя.
Но если в прошивке есть «гостевой» режим без авторизации, где можно только статистику посмотреть или хост пингануть, то да, это серьёзная уязвимость, позволяющая без авторизации выполнять произвольные команды.
DerRotBaron
29.04.2019 01:57+1Что-то подобное есть в прошивке GPON-роутера от OEM-китайцев, только там это проявляется в виде выхода из ограниченного ssh/telnet шелла для поддержки (с захардкоженным логином (совпадает с названием провайдера) и паролем из 6 символов из [a-z], даром что в WAN не торчит). Там в форме valid command<пробел>;shell command.
Помимо этого в прошивке есть несколько "красивых" решений вроде захардкоженного 1.1.1.1 на мультикаст-интерфейсе или принудительной соли VENDORNAME для всех паролей в passwd-файлах (хэши с другой солью не продходят проверку).
Эта уязвимость на сайтах и форумах уже пару лет лежит, так что, думаю, провайдеру на неё просто плевать, а людям это наоборот единственный способ получить полноценный шелл и нормально "исправить" работу роутера.
LoadRunner
29.04.2019 08:49Но устройства, подключенные к Wi-Fi почему-то интернет не получали. Я полез разбираться.
Я переживаю. Шалость в итоге удалась?
CrazyRoot
Скриншот можно было и не замазывать.
Итак понятно что это ДЛИНК