Уязвимость в UPnP, подходящая для усиления DDoS-атак и сканирования внутренней сети

Discussion in 'Мировые новости. Обсуждения.' started by Suicide, 9 Jun 2020.

  1. Suicide

    Suicide Super Moderator
    Staff Member

    Joined:
    24 Apr 2009
    Messages:
    2,016
    Likes Received:
    4,843
    Reputations:
    693
    Раскрыты сведения об уязвимости (CVE-2020-12695) в протоколе UPnP, позволяющей организовать отправку трафика произвольному получателю, используя предусмотренную в стандарте операцию "SUBSCRIBE". Уязвимости присвоено кодовое имя CallStranger. Уязвимость может применяться извлечения данных из сетей, защищённых системами предотвращения утечек данных (DLP), организации сканирования портов компьютеров во внутренней сети, а также для усиления DDoS-атак при помощи миллионов подключённых к глобальной сети UPnP-устройств, таких как кабельные модемы, домашние маршрутизаторы, игровые консоли, IP-камеры, TV-приставки, медиацентры и принтеры.

    Проблема вызвана тем, что предусмотренная в спецификации функция "SUBSCRIBE" позволяет любому внешнему атакующему отправить HTTP-пакеты с заголовком Callback и использовать UPnP-устройство в качестве прокси для отправки запросов на другие хосты. Функция "SUBSCRIBE" определена в спецификации UPnP и используется для отслеживания изменений в других устройствах и сервисах. При помощи HTTP-заголовка Callback можно определить произвольный URL, на который устройством будет установлена попытка соединения.

    [​IMG]
    Проблеме подвержены почти все реализации UPnP, основанные на спецификации, выпущенной до 17 апреля. В том числе наличие уязвимости подтверждено в открытом пакете hostapd c реализацией беспроводной точки доступа (WPS AP). Исправление пока доступно в виде патчей. В дистрибутивах обновления пока не выпущены (Debian, OpenWRT, Ubuntu, RHEL, SUSE, Fedora, Arch). Проблема также затрагивает решения на основе открытого UPnP-стека pupnp, информации об исправлениях для которого пока отсутствует.

    Протокол UPnP определяет механизм для автоматического обнаружения устройств в локальной сети и взаимодействия с ними. При этом протокол изначально спроектирован для использования во внутренних локальных сетях и не предусматривает каких-либо форм аутентификации и проверки. Несмотря на это миллионы устройств не отключают поддержку UPnP на внешних сетевых интерфейсах и остаются доступными для запросов из глобальной сети. Атака может быть совершена через любое подобное UPnP-устройство. Например, приставки Xbox One могут быть атакованы через сетевой порт 2869, так как позволяют отcлеживать через команду SUBSCRIBE такие изменения, предоставление совместного доступа к контенту.

    Организация Open Connectivity Foundation (OCF) была уведомлена о проблеме в конце прошлого года, но вначале отказалась рассматривать её как уязвимость в спецификации. После повторного более детального отчёта наличие проблемы было признано и спецификацию было добавлено предписание по использованию UPnP только на LAN-интерфейсах. Так как проблема вызвана недоработкой в стандарте, на исправление уязвимости в отдельных устройствах может уйти много времени, а для старых устройств обновления прошивки могут и не появиться.

    В качестве обходных путей защиты рекомендуется изолировать UPnP-устройства от внешних запросов межсетевым экраном, блокировать внешние HTTP-запросы "SUBSCRIBE" и "NOTIFY" на системах предотвращения атак или отключить протокол UPnP на внешних сетевых интерфейсах. Производителям рекомендовано отключить функцию SUBSCRIBE в настройках по умолчанию и ограничить при включении только приёмом запросов из внутренней сети. Для тестирования подверженности своих устройств уязвимости опубликован специальный инструментарий, написанный на языке Python и распространяемый под лицензией MIT.

     
    CKAP, CyberTro1n and ms13 like this.
  2. DartPhoenix

    DartPhoenix Elder - Старейшина

    Joined:
    15 Sep 2013
    Messages:
    601
    Likes Received:
    6,266
    Reputations:
    15
    Лет эдак 8 назад я занимался внедрением сией чудесной feature в ПО. Это какой-то кошмар.

    У мелкомягких это было реализовано кажется по технологии COM.
    Т.е. пишем (грубо говоря)

    Code:
    if (SUCCEEDED(InitializeInterface))
      if (SUCCEEDED(Еще что-то делаем))
        .... ; Пятидесятый уровень вложенности
        if (SUCCEEDED(делаем проброс порта))
        else CloseHandle(a);
      else CloseHandle(b);
    else CloseHandle(c);
    И так далее.

    И вот ты это дело запускаешь - а оно не работает. Сначала я делал без всех этих Close - но так - вообще не работало. Ну тоесть как... Оно или срабатывает с первого раза - или не срабатывает вообще.
    Сообщения которые отдает тебе свитч ты не видишь. Просто видишь ошибку которая ни о чем не говорит и все. Мне нельзя было юзать более другие либы, нужно было то, что идет в комплекте с Вендой и ни либой больше.
    Это какой-то ад. И вот чтобы как-то работало - вот все эти действия надо поместить в цикл и однажды оно срабатывало. Ну какбэ работает.

    До сих пор не знаю как работает сея технология по rfc - ибо после того как я этим отзанимался - больше и близко к ней не подходил.
    ======================
    Но есть мнение что таки багов там больше чем в данном disclosure.

    UPD:
    А нет, даже не так. Там надо было закрыть все хендлы которые ты открыл до этого, поэтому все решалось через goto. Тоесть идет список закрытий хендлов и ты через goto после else закрываешь все что успел наоткрывать.

    Можно конечно (нужно тоесть) использовать объектный подход - но это в том случае если у тебя есть возможность подключить соответствующую либу.
     
    CKAP, CyberTro1n and Suicide like this.
Loading...