| |
Многие реализации протокола NAT-PMP в SOHO-маршрутизаторах различных производителей оказались подвержены уязвимости, позволяющей удалённому неаутентифицированному атакующему изменить параметры переадресации портов, получить доступ к внутренним сетевым службам на стороне клиента и организовать перехват приватного и публичного трафика путём его перенаправления на внешний хост.
Причиной возникновения уязвимости является некорректная настройка работы NAT-PMP, применяемая во многих моделях SOHO-маршрутизаторов и разных потребильских сетевых устройствах. RFC 6886, определяющий требования к реализациям NAT-PMP, запрещает принимать запросы на переадресацию портов, приходящие на внешний IP-адрес шлюза или через внешний сетевой интерфейс. Допускается только отправка запросов из внутренней (intranet) сети и их обработка на внутреннем IP (192.168.x.x, 172.16.x.x, 10.x.x.x). Многие производители устройств проигнорировали данное требование и обеспечили приём запросов на внешних сетевых интерфейсах, что в силу простоты протокола NAT-PMP, подразумевающего, что запросы приходят только из intranet-сети, позволило любому внешнему злоумышленнику отправлять управляющие запросы на перенаправление сетевых портов.
Проблеме подвержены некоторые модели устройств от компаний ZyXEL, Netgear, ZTE, MikroTik, Ubiquiti, Technicolor, Speedifi, Radinet и Grandstream, в котрых, как правило, используется код свободного UPnP/NAT-PMP-сервера miniupnp. В результате сканирования глобальной сети было выявлено около 1.2 млн проблемных устройств, из которых 133 тысячи находятся в России. Из данных устройств 2.5% позволяют перехватить внутренний трафик, 86% - перехватить внешний трафик, 88% - получить доступ к сетевым службам в локальной сети, 88% - вызвать отказ в обслуживании, 100% - получить информацию об устройстве (например, сведения об IP-адресах и сетевых портах).
В качестве временного решения проблемы рекомендуется отключить в настройках поддержку NAT-PMP или ограничить на межсетевом экране доступ к UDP-порту 5351. Разработчики miniupnp уже представили несколько изменений, направленных на принудительный запрет приема запросов на WAN-интерфейсе и добавление в пример файла конфигурации miniupnpd.conf примечания с советами о правильной настройке доступа (изначально, в примере запросы принимались и через интерфейс WAN, но блокировались через ACL). Для тестирования наличия уязвимости подготовлены metasploit-модули natpmp_portscan, natpmp_external_address и natpmp_map.
|
|
- Главная ссылка к новости (https://community.rapid7.com/community/m...)
| Тип: Проблемы безопасности | Ключевые слова: nat-pmp, (найти похожие документы) | При перепечатке указание ссылки на opennet.ru обязательно | Реклама |
id=adv>
| |
|
1.1, Famman, 20:23, 24/10/2014 [ответить] [смотреть все] [к модератору]
| +1 +/– |
Когда я вижу подобные новости, у меня возникает один вопрос, они вообще мозги включают (писатели, внедрятели, использователи), когда что-то делают. Это какая-то уникальная способность в наши дни - думать на пару шагов вперед??? Сам по себе NAT-PMP не защищен by design, так вы еще и открываете возможность использовать его снаружи.
У Зюха железки не самые дешевые, что за быдло-кодо-сборщики там сидят...
Хотя чего я о Зюхеле, если у них, перейдя на Кинетиках с прошивки 1.Х на 2.Х, у меня сложилось впечатление, что меня за полного дауна держат, судя по интерфейсу.
| | |
1.2, Нимо Ан, 20:25, 24/10/2014 [ответить] [смотреть все] [к модератору]
| –1 +/– |
От MikroTik не ожидал, это всё-таки не то же самое, что SOHO-классика...
| | |
2.6, Andrew, 21:00, 24/10/2014 [ ^] [ ответить] [ смотреть все] [ показать ветку] [ к модератору] +1 +/–
В RouterOS, в общем случае, все инртерфейсы равноправны. Какой из интерфейсов WAN- решает администратор, а не ОС. В настройках UPnP есть возможность выбрать активные интерфейсы. По-умолчанию служба UPnP вообще отключена. Если криворукий админ включил ее на всех интерфейсах, не разбираясь, что и зачем он делает, это НЕ проблема вендора.
Вывод: Микротик в данном конкретном случае не виноват, и мне не понятно, зачем авторы этого исследования на него бочку катят.
2.16, Аноним, 21:56, 24/10/2014 [ ^] [ ответить] [ смотреть все] [ показать ветку] [ к модератору] +/–Это обычное хомяковое железо, чаще всего атерос, на котором запустили опаскуженн... весь текст скрыт [ показать] [ показать ветку]
1.10, Нанобот, 21:10, 24/10/2014 [ ответить] [ смотреть все] [ к модератору] +1 +/–
Таким образом мы в очередной раз убеждаемся, что роутеры д-линк защищены лучше, чем какой-то непонятный мокротык
1.14, Аноним, 21:38, 24/10/2014 [ ответить] [ смотреть все] [ к модератору] +/–Онлайн сканер портов пишет, что 5351 закрыт Значит у меня всё нормуль ... весь текст скрыт [ показать]
1.19, Аноним, 22:15, 24/10/2014 [ ответить] [ смотреть все] [ к модератору] +/–openwrt данная проблема не затрагивает ... весь текст скрыт [ показать]
1.21, Ivan_83, 22:36, 24/10/2014 [ ответить] [ смотреть все] [ к модератору] +/–
Ещё часто вешают на 49152
Проброс портов добавляется так:
POST /upnp/control/WANIPConn1 HTTP/1.1
HOST: 192.168.1.254:49152
CONTENT-LENGTH: 610
CONTENT-TYPE: text/xml; charset="utf-8"
SOAPACTION: "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping"
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
<NewPortMappingDescription>DESCR</NewPortMappingDescription>
<NewLeaseDuration>0</NewLeaseDuration>
<NewInternalClient>192.168.1.18</NewInternalClient>
<NewEnabled>1</NewEnabled>
<NewExternalPort>20003</NewExternalPort>
<NewRemoteHost></NewRemoteHost>
<NewProtocol>TCP</NewProtocol>
<NewInternalPort>3389</NewInternalPort>
</u:AddPortMapping>
</s:Body>
</s:Envelope>
Там ещё есть xml файл со всякой инфой о девайсе.
Ваш комментарий
Read more |