ANTICHAT — форум по информационной безопасности, OSINT и технологиям
ANTICHAT — русскоязычное сообщество по безопасности, OSINT и программированию.
Форум ранее работал на доменах antichat.ru, antichat.com и antichat.club,
и теперь снова доступен на новом адресе —
forum.antichat.xyz.
Форум восстановлен и продолжает развитие: доступны архивные темы, добавляются новые обсуждения и материалы.
⚠️ Старые аккаунты восстановить невозможно — необходимо зарегистрироваться заново.
 |

09.06.2020, 20:20
|
|
Познавший АНТИЧАТ
Регистрация: 24.04.2009
Сообщений: 1,730
Провел на форуме: 30140275
Репутация:
3256
|
|
Раскрыты сведения об уязвимости ( 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.
|
|
|

09.06.2020, 20:39
|
|
Guest
Сообщений: n/a
Провел на форуме: 295690
Репутация:
24
|
|
Лет эдак 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 закрываешь все что успел наоткрывать.
Можно конечно (нужно тоесть) использовать объектный подход - но это в том случае если у тебя есть возможность подключить соответствующую либу.
|
|
|
|
|
 |
|
Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
|
|
|
|