PDA

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


Suicide
09.06.2020, 20:20
Раскрыты (https://www.tenable.com/blog/cve-2020-12695-callstranger-vulnerability-in-universal-plug-and-play-upnp-puts-billions-of) сведения об уязвимости (https://kb.cert.org/vuls/id/339275) (CVE-2020-12695 (https://security-tracker.debian.org/tracker/CVE-2020-12695)) в протоколе UPnP, позволяющей организовать отправку трафика произвольному получателю, используя предусмотренную в стандарте операцию "SUBSCRIBE". Уязвимости присвоено кодовое имя CallStranger (https://callstranger.com/). Уязвимость может применяться извлечения данных из сетей, защищённых системами предотвращения утечек данных (DLP), организации сканирования портов компьютеров во внутренней сети, а также для усиления DDoS-атак при помощи миллионов подключённых к глобальной сети UPnP-устройств, таких как кабельные модемы, домашние маршрутизаторы, игровые консоли, IP-камеры, TV-приставки, медиацентры и принтеры.

Проблема вызвана (https://github.com/yunuscadirci/CallStranger/blob/master/CallStranger%20-%20Technical%20Report.pdf) тем, что предусмотренная в спецификации функция "SUBSCRIBE" позволяет любому внешнему атакующему отправить HTTP-пакеты с заголовком Callback и использовать UPnP-устройство в качестве прокси для отправки запросов на другие хосты. Функция "SUBSCRIBE" определена в спецификации UPnP и используется для отслеживания изменений в других устройствах и сервисах. При помощи HTTP-заголовка Callback можно определить произвольный URL, на который устройством будет установлена попытка соединения.

https://www.opennet.ru/opennews/pics_base/0_1591710382.png (https://www.tenable.com/sites/drupal.dmz.tenablesecurity.com/files/images/blog/CVE-2020-12695%20-%20CallStranger%20Vulnerability.png)

Проблеме подвержены почти все реализации UPnP, основанные на спецификации (https://openconnectivity.org/upnp-specs/UPnP-arch-DeviceArchitecture-v2.0-20200417.pdf), выпущенной до 17 апреля. В том числе наличие уязвимости подтверждено (https://w1.fi/security/2020-1/upnp-subscribe-misbehavior-wps-ap.txt) в открытом пакете hostapd (http://w1.fi/hostapd/) c реализацией беспроводной точки доступа (WPS AP). Исправление пока доступно в виде патчей (https://w1.fi/security/2020-1/). В дистрибутивах обновления пока не выпущены (Debian (https://security-tracker.debian.org/tracker/CVE-2020-12695), OpenWRT (https://openwrt.org/advisory/start), Ubuntu (https://people.canonical.com/~ubuntu-security/cve/CVE-2020-12695), RHEL (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-12695), SUSE (https://bugzilla.suse.com/show_bug.cgi?id=CVE-2020-12695), Fedora (https://bodhi.fedoraproject.org/updates/?releases=F32&type=security), Arch (https://security.archlinux.org/)). Проблема также затрагивает (https://github.com/pupnp/pupnp/issues/180) решения на основе открытого UPnP-стека pupnp (https://github.com/pupnp/pupnp/), информации об исправлениях для которого пока отсутствует.

Протокол UPnP определяет механизм для автоматического обнаружения устройств в локальной сети и взаимодействия с ними. При этом протокол изначально спроектирован для использования во внутренних локальных сетях и не предусматривает каких-либо форм аутентификации и проверки. Несмотря на это миллионы устройств не отключают поддержку UPnP на внешних сетевых интерфейсах и остаются доступными (https://www.shodan.io/search?query=upnp) для запросов из глобальной сети. Атака может быть совершена через любое подобное UPnP-устройство. Например, приставки Xbox One могут быть атакованы через сетевой порт 2869, так как позволяют отcлеживать через команду SUBSCRIBE такие изменения, предоставление совместного доступа к контенту.

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

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

09.06.2020

https://www.opennet.ru/opennews/art.shtml?num=53123​

DartPhoenix
09.06.2020, 20:39
Лет эдак 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 закрываешь все что успел наоткрывать.

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