The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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

09.06.2020 15:27

Раскрыты сведения об уязвимости (CVE-2020-12695) в протоколе UPnP, позволяющей организовать отправку трафика произвольному получателю, используя предусмотренную в стандарте операцию "SUBSCRIBE". Уязвимости присвоено кодовое имя CallStranger. Уязвимость может применяться для извлечения данных из сетей, защищённых системами предотвращения утечек данных (DLP), организации сканирования портов компьютеров во внутренней сети, а также для усиления DDoS-атак при помощи миллионов подключённых к глобальной сети UPnP-устройств, таких как кабельные модемы, домашние маршрутизаторы, игровые консоли, IP-камеры, TV-приставки, медиацентры и принтеры.

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

Проблеме подвержены почти все реализации 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.

  1. Главная ссылка к новости (https://www.openwall.com/lists...)
  2. OpenNews: Релиз OpenWRT 19.07
  3. OpenNews: Новые уязвимости в технологии защиты беспроводных сетей WPA3 и в EAP-pwd
  4. OpenNews: Выпуск hostapd и wpa_supplicant 2.7
  5. OpenNews: Раскрыты детали критической уязвимости в устройствах с поддержкой UPnP от различных производителей
  6. OpenNews: Предупреждение о задействовании UPnP/SSDP в качестве усилителя DDoS-атак
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/53123-callstranger
Ключевые слова: callstranger, upnp
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (55) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, ilyafedin (ok), 17:09, 09/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > В том числе наличие уязвимости подтверждено в открытом пакете hostapd c реадлизцией беспроводной точки доступа (WPS AP)

    А iwd?

    > Проблема также затрагивает решения на основе открытого UPnP-стека pupnp, информации об исправлениях для которого пока отсутствуют.

    А miniupnpd?

     
  • 1.2, Michael Shigorin (ok), 17:24, 09/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +17 +/
    <-- удобство | безопасность -->
     
     
  • 2.4, Аноним (4), 17:26, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вообще непонятно в чём удобство UPnP на WAN интерфейсе, зачем он там? Он же очевидно и по спецификации — только для LAN.
     
     
  • 3.7, arfh (?), 17:40, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Для того же, для чего он и для LAN -- открытия портов без настройки роутера. Или на ноутбуке с Wi-Fi гораздо удобнее настраивать порты, чем на ПК? Разницы нет.
     
  • 3.12, Аноним (12), 18:22, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В LAN тоже нормалек, судя по описанию.
     
  • 3.20, Михрютка (ok), 20:31, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Он же очевидно и по спецификации — только для LAN.

    сходите почитайте pdf по ссылочке, там пример вынимания из LAN во внешнюю сеть 16 метров данных за http запрос. это вам не туннели поверх icmp или dns строить.

     
     
  • 4.32, Аноним (32), 23:26, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Почитал, там речь идёт об отправке данных _изнутри_ LAN, через легитимное устройство с UPnP. Да, для массовых устройств такое поведение по умолчанию — не ок. Но простите, если атакующий _уже_ внутри LAN, то у вас явно проблемы не с UPnP.
     
     
  • 5.45, Аноним (-), 19:19, 10/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Однако если в LAN прямые коммуникации между клиентами не были частью плана, эта штука может сие успешно "починить" - с роутером то вы коммуницировать по любому будете...
     
  • 2.13, Аноним (12), 18:23, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >  <-- удобство | безопасность -->

    Ну вам же не нравится IPv6 - вот и наслаждайтесь счастьем с костылями и подпорками. И сотнями unxepected в них.

     
     
  • 3.18, Аноним (18), 20:22, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Правильно. IPv6 не подвержен этой уязвимости!
     
  • 3.19, Михрютка (ok), 20:26, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    да понятно, в ipv6 сразу +2 к безопасности против ipv4, все строго авторизованное, сетевые экраны сами себя строят, и даже злоумышленники идут сдаваться, едва заметив в своей голове противозаконные мысли.
     
     
  • 4.22, Аноним (22), 20:42, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    В ipv6 такие фееричные угребища как upnp просто не требуются. Достаточно одного файрвола, который пустит что надо и не пустит что не надо. А когда начинается вот такое вот - у вас точки контроля раскиданы по 20 разным закоулкам. И в результате оказывается что по факту у вас должен крутиться open proxy чтобы вообще вкостылить ipv4 для работы некоторых программ.

    При том мало того что этот open proxy сам по себе совершенно отдельный и может шарахаться везде, так еще это совершенно не очевидно когда вы наруливали какой-нить там файрвол.

     
     
  • 5.24, Михрютка (ok), 20:48, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Достаточно одного
    > файрвола, который пустит что надо и не пустит что не надо.
    >>  сетевые экраны сами себя строят,

    ну да ну да

    > При том мало того что этот open proxy сам по себе совершенно
    > отдельный и может шарахаться везде, так еще это совершенно не очевидно
    > когда вы наруливали какой-нить там файрвол.

    иван васильевич, когда вы говорите, такое ощущение, что вы бредите.

     
     
  • 6.27, Аноним (27), 21:55, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Так это не я такое говорю, это стандарт на эту пакость, вот ведь в чем все западло.
     

  • 1.3, Аноним (4), 17:25, 09/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    > спецификацию было добавлено предписание по использованию UPnP только на LAN-интерфейсах

    Интересно как производители мотивировали своё решение открыть доступ к UPnP снаружи на WAN-интерейсах? зачем?

     
     
  • 2.5, Нанобот (ok), 17:29, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Производители телевизоров и игровых консолей мотивировали своё решение отсутствием wan-портов на своих продуктах
     
     
  • 3.31, Аноним (32), 23:13, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    И соответственно они не доступны из интернета, речь то не про них.
     
     
  • 4.49, Аноним (-), 16:49, 11/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > И соответственно они не доступны из интернета

    ...пока юзер прововское кабло в их порт не воткнул.

     
  • 2.6, Аноним (6), 17:35, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чтобы сьекономить полмиски риса однако.
     
  • 2.8, Аноним (8), 17:57, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    IGD.
     
  • 2.10, Аноним (10), 18:16, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Запланированным уст^Wвых^W<censored>, когда люди спохватятся - им придётся купить новые рутеры.
     
     
  • 3.15, Аноним (12), 18:25, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А отключить в морде фичу - слишком просто и дешево? Походу аноним заодно с производителями.
     
  • 2.21, Михрютка (ok), 20:32, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    сдуру.
     
  • 2.51, Аноним (-), 16:50, 11/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно как производители мотивировали своё решение

    Укуренностью китайцев делавших прошивку.

     

  • 1.9, Аноним (10), 18:13, 09/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >В качестве обходных путей защиты рекомендуется

    купить новый роутер.

     
     
  • 2.14, Аноним (12), 18:24, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И новое авто при заполнении пепельницы. Еще не хватало пройти в вебморду и выключить это.
     
  • 2.16, Аноним (16), 18:26, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Или проверить свой имеющийся в списке поддержаеиого оборудования на https://openwrt.org/. Прошивку заливать, разумеется, уже с исправленной уязвимостью.
     
     
  • 3.26, Аноним (27), 21:53, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А что, они уже новые прошивки собрать успели?
     
  • 3.33, КО (?), 06:19, 10/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ха-ха-ха, откуда бы там взяться моему древнему гомну?
    Они ж любители теперь поддержку прекращать
     
     
  • 4.36, Аноним (36), 10:54, 10/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Старые устройства поддерживаются и обновляются. Прекратили поддержку устройств 4/32 flash/ram
     
     
  • 5.55, Аноним (55), 14:38, 22/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да, прекратили, но можно пересобрать прошивку. Выкинуть лишнее и тяжёлое. Мой роутер стабильно на последней прошивке работает.
     

  • 1.11, Аноним (12), 18:21, 09/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Что вы хотите? По одному виду этого стандарта заметно что его проектировали полные вебмакаки.
     
     
  • 2.29, Аноним (-), 22:32, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не поверишь. Я как узнал за этот протокол - сразу пошёл смотреть стандарт, и пришёл к такому же мнению. С той поры отключал и не использовал, а за такой подход они называли меня старпёром-параноиком.

    Вобщем я стар, я очень - хотя и не супер - стар, временами использую OpenBSD, a ещё кое-какие другие протоколы - не использую из брезгливости. Например я никогда (то есть с конца 90-х, да-да) не использовал в своих сетях шифрование 802.11 - всегда сеть была "скрыта" и незашифрована, а вот траффик в ней - зашифрован более надёжными методами. Насканившему без ключей - подключение не давало ничего. Могу продолжать...

     
     
  • 3.46, Аноним (-), 19:26, 10/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Есть нюансик, в такой конфиге хаксор может спихивать вас с точки доступа как пожелает, оставив без вафли малой кровью. Впрочем WPA3 все-равно мало кто умеет чтобы management frames защищать.

    Кстати, ничего не мешает и шифровать вафлю + потом свое шифрование. Но идея неплохая.

    > Могу продолжать...

    (вы бы охренели увидев мои конфиги, и нифига бы не поняли)

     

  • 1.17, mos87 (ok), 18:49, 09/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    зойчем выставлять упнп в wan?
     
     
  • 2.25, Аноним (25), 20:55, 09/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да он и в LAN в принципе ничего так дыра - позволяет класть на всякие фаеры и прочие глупости, делая действия не вон той машиной, а вот этим вашим роутером. Очень прикольно и удобно.
     

  • 1.23, Gefest (?), 20:44, 09/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Они воплотили в жизнь анекдот , ну тот самый "Здравствуйте, я ольбанский вирус, мой создатель не уметь взламывать маршрутизатор ..."
     
  • 1.30, Аноним (30), 23:08, 09/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    - What you gonna do after drinking too much beer?
    - UPnP...nP...
     
  • 1.34, Аноним (34), 06:20, 10/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    miniupnpd дырявый тоже?
     
     
  • 2.53, AnonPlus (?), 13:02, 12/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Some UPnP stacks like miniupnp (after 2011) are not vulnerable
     

  • 1.35, Аноним (35), 09:49, 10/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что-то я не понял. А если запрос пришёл из LAN, то коллбэк надо бы отправить обратно в LAN, а не куда-попало? Но это может быть не так однозначно в некоторых конфигурациях. И сразу теряется удобство)) Ну так пусть эти "некоторые конфигурации" уже настраивают отдельные "некоторые специалисты".
     
  • 1.37, Корец (?), 11:06, 10/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я один отключаю UPnP на роутерах?
     
  • 1.38, Аноним (38), 11:49, 10/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очевидно что проблема - устройства с прошивками закрытыми исходными кодами. Приставки - это вообще помойка! Если устройство снимается с поддержки то исходный код обязательно должен быть открыт! Вообще это касается всего что производится как проприетарный продкут: документации на автомобили, принципиальные схемы на железо, исходный код к прошикам.
     
     
  • 2.39, Корец (?), 11:56, 10/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Они удавятся за копейку. Они лучше отправят всё в /dev/null, чем отдадут на халяву.
     
     
  • 3.40, Аноним (38), 12:17, 10/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вы не непоняли меня. Причем тут халява? Закрытый исходный код - это преступление приводящее к катострофическим последствиям. Вот результат - описано в статье. Перестать воровать и обманывать, перестать быть бандитом не означает "отдать на халяву". Это говорит о том что изначально было престулпнеием закрытие исходного кода. Еще раз "халява" тут не причем.
     
     
  • 4.41, Корец (?), 13:12, 10/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Причем тут халява?

    Я полагаю, что изначально код делается закрытым чтоб никто другой не мог украсть разработку. Поэтому я и выразился именно так.

     
     
  • 5.42, Аноним (38), 14:35, 10/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нельзя украсть то, что свободно. Чтобы это украсть нужно сначала это закрыть.
     

  • 1.43, microsoft (?), 15:39, 10/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    угу, not a bug
     
  • 1.44, Ivan_83 (ok), 17:51, 10/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Действительно стандарт писали вебмакаки.
    Чтобы гарантировать что это будет работать только в локалке достаточно выставить TTL=1 для TCP и UDP сокетов задействованных в работе UPnP и не надо ни фаерволов ни каких то ещё настроек. Даже риск что сосед с wan порта увидит будет минимальным.
     
     
  • 2.47, Аноним (47), 19:29, 10/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по дизайну протокола, вебмакаки делавшие это таких слов вообще не знают. Алсо, возможность одного клиента LAN фигачить другого не от своего лица, а от лица роутера - тоже очень так себе.
     
     
  • 3.48, Ivan_83 (ok), 20:47, 10/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Оно для дома сделано - не критично совсем.
    Все проблемы UPnP сводятся к тому что кто то извне получает доступ и злоупотребляет, а TTL=1 это решает на корню.
     
     
  • 4.50, Аноним (-), 16:50, 11/06/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Думаю, тут важно _основание_ для этого самого уважения

    Очегь узкое мышление - сэр никогда не слышал про SOHO.

     
     
  • 5.52, Ivan_83 (ok), 17:27, 11/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Чем по вашему плох вариант с выставлением TTL=1 для всех сокетов обслуживающих UPnP/DLNA сервисы?
     

  • 1.54, Аноним (54), 22:40, 12/06/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На до мной ржали, что я ufw сношу и прописываю васянским скриптом нужные правила. А ненужные не прописываю. И где вы, ржуны сейчас с вашими высшими образованиями?
     
     
  • 2.56, Аноним (56), 02:56, 25/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    осилили ufw и делаем в нём то же самое.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру