Некоторое время назад мне предоставилась возможность поэкспериментировать с настройками одного заурядного роутера. Дело в том, что первое апреля обязывало меня разыграть своих товарищей с университета. В университете была Wi-Fi сеть. Мною было решено поднять на своем роутере поддельную сеть (задать имя, пароль и установить MAC-адрес одной из легитимных точек доступа), на ноутбуке запустить свой DNS, web сервер. Каждый случайно подключившийся к моей сети и попытавшийся зайти на какой либо сайт должен был перенаправляться на мою страничку с первоапрельской картинкой. Но история не об этом. Когда я ковырялся в настройках роутера я нашел интересный баг, о нем я сегодня и расскажу.

image

На этапе настройки роутер был подключен к интернету. Но устройства, подключенные к 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) .

Мне не сиделось на месте, и я поспешил написать производителю о найденном баге. Я подробно описал модель роутера, версию прошивки и сценарий воспроизведения бага. На что получил интересный ответ:

image
Перевод (дословно)

Не могли бы вы проверить версию аппаратного обеспечения на нижней этикетке продукта?
У нас нет Rev. Px. Вы знаете источник или место покупки этого устройства?
Как оказалось, они не учли, что я пишу из России. Данная модель роутера распространялась только в нашей стране. Переписка закончилась тем, что мне выслали новую прошивку, в которой устранены все недостатки предыдущей и добавлено много фич, но почему-то она не оказалась в публичном доступе.

Комментарии (9)


  1. CrazyRoot
    28.04.2019 17:31
    +1

    Скриншот можно было и не замазывать.
    Итак понятно что это ДЛИНК


  1. slashd
    28.04.2019 17:46
    +1

    Может стоит выложить модель уязвимого устройства и новую прошивку? Или ради чего весь этот пост?


    1. DVoropaev Автор
      28.04.2019 17:53
      +1

      Смысл этого поста в том, что необходимо ВСЕГДА проверять данные на входе. Особенно, данные полученные от пользователя


      1. vladimirad
        28.04.2019 19:05
        +4

        Правильным является полное игнорирование входного потока от пользователя и подмена его на заведомо правильный.


        1. osheinin
          29.04.2019 06:22

          Я даже знаю такие конторы, которые так разрабатывают


  1. dartraiden
    28.04.2019 22:22

    Если злоумышленник уже получил доступ к админке вашего роутера, то ему не нужно использовать эту уязвимость. Он просто включит ssh, добавит свой публичный ключ и зайдет с правами суперпользователя.

    Но если в прошивке есть «гостевой» режим без авторизации, где можно только статистику посмотреть или хост пингануть, то да, это серьёзная уязвимость, позволяющая без авторизации выполнять произвольные команды.


  1. 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-файлах (хэши с другой солью не продходят проверку).


    Эта уязвимость на сайтах и форумах уже пару лет лежит, так что, думаю, провайдеру на неё просто плевать, а людям это наоборот единственный способ получить полноценный шелл и нормально "исправить" работу роутера.


  1. LoadRunner
    29.04.2019 08:49

    Но устройства, подключенные к Wi-Fi почему-то интернет не получали. Я полез разбираться.
    Я переживаю. Шалость в итоге удалась?


  1. Myxa767
    29.04.2019 10:12

    Тема первоапрельской шутки не раскрыта, что в итоге с первоначальной затеей?