Многие реализации протокола NAT-PMP (http://en.wikipedia.org/wiki/NAT_Port_Mapping_Protocol) в SOHO-маршрутизаторах различных производителей оказались (https://community.rapid7.com/community/metasploit/blog/2014/... подвержены уязвимости (http://www.kb.cert.org/vuls/id/184540), позволяющей удалённому неаутентифицированному атакующему изменить параметры переадресации портов, получить доступ к внутренним сетевым службам на стороне клиента и организовать перехват приватного и публичного трафика путём его перенаправление на внешний хост.
Причиной возникновения уязвимости является некорректная настройка работы NAT-PMP, применяемая во многих моделях SOHO-маршрутизаторов и разных потребильских сетевых устройствах. RFC 6886 (https://tools.ietf.org/html/rfc6886), определяющий требования к реализациям 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 (http://miniupnp.free.fr/). В результате сканирования глобальной сети было выявлено около 1.2 млн проблемных устройств, из которых 133 тысячи находятся в России. Из данных устройств 2.5% позволяют перехватить внутренний трафик, 86% - перехватить внешний трафик, 88% - получить доступ к сетевым службам в локальной сети, 88% - вызвать отказ в обслуживании, 100% - получить информацию об устройстве (например, сведения об IP-адресах и сетевых портах).
В качестве временного решения проблемы рекомендуется отключить в настройках поддержку NAT-PMP или ограничить на межсетевом экране доступ к UDP-порту 5351. Разработчики miniupnp уже представили несколько (https://github.com/miniupnp/miniupnp/commit/16389fda3c5313bf... изменений (https://github.com/miniupnp/miniupnp/commit/82604ec5d0a12e87... направленных на принудительный запрет приема запросов на WAN-интерфейсе и добавление в пример файла конфигурации miniupnpd.conf (https://github.com/miniupnp/miniupnp/blob/master/miniupnpd/m... примечания с советами о правильной настройке доступа (изначально, в примере запросы принимались и через интерфейс WAN, но блокировались через ACL).
URL: https://community.rapid7.com/community/metasploit/blog/2014/...
Новость: http://www.opennet.ru/opennews/art.shtml?num=40922
