Что это miniupnpd: GitHub — miniupnp/miniupnp: UPnP IGD implementation

Установка miniupnpd в Ubuntu / Linux Mint / Debian

Установка:

Для установки miniupnpd в Ubuntu / Linux Mint / Debian, введите в Терминал:

sudo apt update

sudo apt install miniupnpd

Подробная информация о пакете:

UPnP и NAT-PMP для шлюзовых маршрутизаторов

Сентябрь 2018

Источник: https://packages.ubuntu.com

Навигация по записям

• Зависимости:

• debconf

  Система управления конфигурацией Debian

• iproute2

  Сетевые средства и средства управления трафиком

• iptables

  Средства администрирования для фильтрации пакетов и NAT

• libc6

  Библиотека GNU C: общие библиотеки

• libip4tc0

  Библиотека netfilter libip4tc

• libip6tc0

  Библиотека netpilter libip6tc

• lsb-base

  Функциональность базового сценария Linux Standard Base

• net-tools

  Сетевой инструментарий NET-3

• uuid-runtime

  Компоненты времени выполнения для универсальной библиотеки идентификаторов

• debconf-2.0

Старая уязвимость в UPnP на новый манер / Хабр

Всё новое — это хорошо забытое старое (а лучше очень хорошо забытое старое). Следить за новыми уязвимостями, конечно же, правильно, но и о старых забывать не стоит. Тем более, когда о них позволяет себе «забыть» производитель. Кто-то должен помнить. Иначе мы снова и снова будем наступать на одни и те же грабли.

Речь в статье пойдет об одной старенькой, но, как оказалось, ни разу не потерявшей актуальности и по сей день, дыре UPnP.

P.S. Провайдера называть не буду, вины его в этом нет, но с другой стороны есть явный недосмотр политик безопасности, которые вкупе с архитектурой сети дали возможность проэксплуатировать эту уязвимость. Как это всегда бывает — звезды сошлись. Провайдер ставил на своей сети роутеры клиентам с нужными чипами и подключал с внешним ip адресом. Да, большинство портов были зафильтрованы, но почему-то не 52869.

P.P.S. Все события произошли в конце 2018 года. Герои вымышлены, а совпадения с реальными личностями случайны.

Краткий ликбез:Есть некоторая библиотека libupnp для разработки, которая «используется на тысячах устройств и называется Intel SDK для UPnP-устройств или Portable SDK для UPnP-устройств».

На английском:

«The portable SDK for UPnP Devices (libupnp) provides developers with an API and open source code for building control points, devices, and bridges that are compliant with Version 1.0 of the Universal Plug and Play Device Architecture Specification and support several operating systems like Linux, *BSD, Solaris and others.»

Первое упоминание об уязвимости было в далеком 2014 году: тык
Попытки связаться с производителем особого успеха не принесли и уязвимость была опубликована. Единственной рекомендацией по противодействию было:

«… ограничение взаимодействия со службой… Только клиенты и серверы, которые имеют законные процедурные отношения… должны иметь возможность общаться с ним.»

Недостаток существует в сервисе miniigd SOAP. Проблема заключается в обработке запросов NewInternalClient из-за невозможности очистки пользовательских данных перед выполнением системного вызова. Злоумышленник может использовать эту уязвимость для выполнения кода с привилегиями root.

Т.е. на всех роутерах с версией UPnP 1.0 можно выполнять произвольный удаленный код.

Без авторизации. От рута. Здорово, правда?

Любой желающий может на github’е найти готовый плагин для метасплоита, работоспособность которого проверена прожженными стульями наших дежурных инженеров.

Было неожиданно и совсем не весело.

Краткая хронология событий того дня:

14:00 В техническую поддержку начинают поступать обращение абонентов на плохо работающий интернет.

• Симптомы со стороны клиента: «медленно работает, после перезагрузки какое-то время работает нормально, потом снова медленно».
• Симптомы со стороны оборудования: небольшой всплеск трафика и загрузки CPU были списаны на нагрузку, которую генерирует сам клиент.

Регистрируются одиночные заявки для проверки линии на админов, либо на выезд монтажника. Никакого общего шаблона для действий нет. Ничего не понятно.

15:00 Количество заявок начинает превышать среднюю температуру по больнице и одиночные заявки начинают лепить в заявки по больше с типом «Авария». Заявки передаются на старших администраторов для проверки сегментов сети.

15:20 Админы закрывают массовые аварии, т.к. проблем на сети нет, все заявки клиентов с разных точек подключения и одиночные. (к примеру: коммутатор полный активных абонентов, а плохо работает у одного). В этот момент спадают обращения и всё затихает. Кто-то обращает внимание (наконец-то), что все заявки на плохую работу были с одной и той-же моделью роутера, все дружно делают вид, что всё хорошо.

15:30 Снова наплыв заявок от абонентов, снова регистрация массовой аварии и передача админам. В этот момент становится ясно, что что-то действительно не так и нужно что-то делать (кто работал с клиентским сервисом меня поймет, как это иногда сложно сделать. Клиенты всегда врут, а иногда и первая линия врет, чтобы эскалировать задачу дальше).

15:35 Дежурный инженер получает заявку на проблему с клиентским сервисом. Получает список всех клиентов, тип их подключения и модель устройства. А дальше начинается немного магии.

спойлер

Которая, кстати, не сработала и главного мага потом уволили (но говорят, что не за это).

15:40 Инженер прогоняет список клиентов через все диагностики какие есть, каждый роутер был проверен по всем стандартным метрикам и… ничего не нашлось. Роутер как роутер. Да, увеличилось CPU, но показатели не критичные, да он льет куда-то трафик, значит — работает.

Да, крутится на 52869 порту UPnP-сервис. Да там еще куча открытых портов, открыты значит нужны (логика железная), и он всегда там крутился и никаких проблем не было (еще один аргумент железной логики). Прямой ssh на данную модель роутера невозможен (откровенно говоря возможен, но внутри сильно урезанный busybox и политикой компании крайне не приветствовалось такое хождение по клиентским устройствам). Всё опять встало.

16:00 Только сейчас мы узнаем о том, что есть какие-то проблемы. Дежурный инженер докладывает своему руководителю, а руководитель телефонным звонком сообщает нам свои догадки по поводу 52869 порта и просит помочь.

16:05 Дальше всё происходило очень быстро. На тестовый стенд включается такая же модель роутера, у проблемного клиента забирается ip-адрес и вешается на тестовый. Включается wireshark. Это чтобы отловить запросы к устройству.

Чтобы отловить запросы от роутера (на тот момент еще неизвестна была общая схема, как происходит взаимодействие) клиент изолируется в тестовом сегменте и весь его трафик миррорится в ближайшую тестовую машину где поднят еще один wireshark.

Дальше ждем, смотрим в экран.

Таким способом уже ловили взломы — достаточно эффективно и поэтому решили не изменять привычкам.

16:10 Пока wireshark шуршит, в гугле находится уязвимость CVE-2014-8361 о чем сообщается инженерам. Инженер, не дослушав, принимает решение (и в принципе логичное) — фильтр данного порта на бордерах. Сказанно — сделано.

спойлер

Это не сработало.

16:25 Нам сообщают, что все говно миша переделывай не сработало. И мы уже знали, что не сработает. К тому моменту на тестовый роутер уже постучались, подняли реверс-шел на другом порту и начали параллельно использовать для DDOS-a через 1900(!) порт используя еще одну уязвимость. Господи, како же дырявое помойное ведроеще ликбезИспользование в DDoS атаках схемка

В 2014 неожиданно обнаружили, что SSDP использовался в DDoS атаках типа «Атака отражения и усиления при помощи SSDP» (SSDP reflection attack with amplification). Многие устройства, в том числе бытовые маршрутизаторы имели изъян в программном обеспечении UPnP, который позволял атакующему направлять ответы с порта 1900 на произвольный адрес в сети Интернет. В случае использования ботнета из многих тысяч подобных устройств, атакующий мог создать большой поток пакетов, достаточных для занятия пропускной полосы и насыщения каналов передачи данных атакуемой площадки, что приводит к отказу в обслуживании для обычных пользователей.

Самое интересное — были изменены правила файрвола на устройстве и nmap теперь не показывал открытые порты с внешки. Только в дампе трафика можно было обнаружить запросы по этим портам. Т.е. злоумышленник после взлома закрывал доступ для остальных. Не хай-тек подход, но всё равно — браво.

16:30 Собирается конфа с вопросами «кто виноват и что делать». Оставили забаннеными порты 1900 и 52869. Принимаются попытки уже на взломанных устройствах что-то исправить. Ребут — не помог, идею перепрошить сразу отвергли. Да, функционал такой имеется, можно было одной кнопкой на всех устройствах переставить удаленно ПО через TR069. Но т.к. устройство не первой свежести, а количество клиентов было большим — определенный процент окирпиченных устройств создал бы проблем.

16:40 Подводим краткий итог: устройства взломаны, участвуют минимум в ddos и по шифрованному каналу куда-то что-то передают. (Все на разных портах). Залезть внутрь не представляется возможным, вендор отказал в полном доступе по ssh к устройству и посмотреть, что именно там накрутили невозможно. Консоль запаролена.

Где-то ближе к 17:00 Было принято решение шить устройства как самый быстрый способ. После перепрошивки и перезагрузки — всё нормализовалось.

Вместо итогов

К сожалению, так до конца решить эту проблему мы не смогли.

Под «решить» я подразумеваю получить полную информацию по взлому и обновить наши политики для противодействия подобному в дальнейшем. Да, не все поставленные задачи решаются успешно и так как хотелось бы. Это нормально. Хоть и обидно.

Если хорошо поискать на шодане,

то можно найти себе что-нибудь

для экспериментов:
так или так

но я вам этого не говорил.

Критическая уязвимость во многих роутерах различных вендоров / Хабр

Как сообщалось ранее, компания DefenseCode обнаружила уязвимость нулевого дня в роутерах Cisco Linksys. Представители компании оповестили вендора и взяли тайм-аут на пару недель перед раскрытием деталей уязвимости. Время вышло, некоторые подробности были раскрыты и оказалось, что не только Cisco Linksys уязвима.Вот только часть вендоров, где присутствует уязвимость

• Broadcom,
• Asus
• Cisco
• TP-Link
• Zyxel
• D-Link
• Netgear
• US Robotics

Речь идёт о сразу нескольких уязвимостях, которые кроются в ряде реализаций протокола UPnP и SSDP (основанные на Intel/Portable UPnP SDK и MiniUPnP SDK):
Список CVE

1. CVE-2012-5958
2. CVE-2012-5959
3. CVE-2012-5960
4. CVE-2012-5961
5. CVE-2012-5962
6. CVE-2012-5963
7. CVE-2012-5964
8. CVE-2012-5965
9. CVE-2013-0229
10. CVE-2013-0230

Уязвимости позволяют вызвать отказ в обслуживании или выполнить произвольный код на устройстве без авторизации. А т.к. многие роутеры взаимодействуют с UPnP через WAN, это делает их уязвимыми не только к атаке из локальной сети, но и из удалённых сетей. Т.е. практически с любого компьютера Интернета. Уязвимыми могут оказаться не только роутеры, но вообще любое оборудование, использующее UPnP: принтеры, медиа-серверы, IP-камеры, NAS, smart TV и т.д. Т.е. речь идёт о миллионах устройств!

Компания rapid7 выпустила сканер для проверки своих устройств на наличие уязвимостей. Онлайн версия доступна здесь.

Мне повезло. А Вам?

Проверяется IP-адрес с которого пришёл пользователь. Т.е. ввести произвольный адрес для проверки не получится.

Оффлайн версию сканера уязвимости можно скачать по этой ссылке. Данный сканнер поддерживает только ОС Microsoft Windows. Пользователи Mac OS X и Linux могут использовать Metasploit для этой цели. Пример использования Metasploit:

$ msfconsole

msf>

msf > use auxiliary/scanner/upnp/ssdp_msearch

msf auxiliary(ssdp_msearch) > set RHOSTS 192.168.0.0/24

msf auxiliary(ssdp_msearch) > run

ответ будет примерно такой:

[*] 192.168.0.9:1900 SSDP Net-OS 5.xx UPnP/1.0 | 192.168.0.9:3278/etc/linuxigd/gatedesc.xml

[+] 192.168.0.254:1900 SSDP miniupnpd/1.0 UPnP/1.0 | vulns:2 (CVE-2013-0229, CVE-2013-0230)

На текущий момент известно, что TP-LINK выпустила бета-версию прошивки, которая закрывает уязвимость в оборудовании TD-W8960N. К концу февраля планируют выпустить официальную прошивку.

В качестве временной меры рекомендуется выключить поддержку UPnP на сетевом оборудовании.

Ссылки по теме:

1. Список устройств, где подтверждено наличие уязвимостей

2. Отчёт rapid7 об уязвимостях в UPnP

3. Отчёт DefenseCode об уязвимостях в UPnP

UPD: и сегодня же стало известно об Очередных уязвимостях нулевого дня в различных роутерах

Ubuntu – Подробная информация о пакете miniupnpd в xenial

Ссылки для miniupnpd

Ресурсы Ubuntu:

Исходный код miniupnpd:

Сопровождающий:

Please consider filing a bug or asking a question via Launchpad before contacting the maintainer directly.

Original Maintainer (usually from Debian):

It should generally not be necessary for users to contact the original maintainer.

Внешние ресурсы:

Подобные пакеты:

UPnP and NAT-PMP daemon for gateway routers

Другие пакеты, относящиеся к miniupnpd

• dep:
  debconf

  Debian configuration management system

• dep:
  debconf
  (>= 0.5)

  Debian configuration management system

  или
  debconf-2.0

  виртуальный пакет, предоставляемый

  cdebconf, cdebconf-udeb, debconf

• dep:
  iproute2

  networking and traffic control tools

  или
  iproute

  transitional dummy package for iproute2

• dep:
  iptables

  administration tools for packet filtering and NAT

• dep:
  libc6
  (>= 2.15)
  [не arm64, ppc64el]

  GNU C Library: Shared libraries
  также виртуальный пакет, предоставляемый

  libc6-udeb

  dep:
  libc6
  (>= 2.17)
  [arm64, ppc64el]

• dep:
  libnfnetlink0

  Netfilter netlink library

• dep:
  net-tools

  NET-3 networking toolkit

• dep:
  uuid-runtime

  runtime components for the Universally Unique ID library

Загрузка miniupnpd

Stupidly Simple DDoS Protocol (SSDP) генерирует DDoS на 100 Гбит/с / Хабр

В мае мы поделились статистикой по самым популярным атакам с отражением. Тогда средний размер атаки SSDP был в районе 12 Гбит/с, а крупнейшая атака SSDP с отражением была такой:

• 30 Мп/с (миллионов пакетов в секунду)
• 80 Гбит/с (миллиардов бит в секунду)
• 940 тыс. IP-адресов для отражения

Всё изменилось пару дней назад, когда мы заметили необычно крупное умножение пакетов SSDP. Это достойно более тщательного расследования, поскольку атака преодолела символический рубеж в 100 Гбит/с.

График пакетов в секунду:

Использование полосы:

Пакетный флуд продолжался 38 минут. Судя по выборке потока данных, использовались 930 тыс. отражающих серверов. По нашей оценке, каждый рефлектор отправил 120 тыс. пакетов на Cloudflare.

Отражающие сервера располагались по всему миру, больше всего в Аргентине, России и Китае. Вот уникальные IP-адреса по странам:

$ cat ips-nf-ct.txt|uniq|cut -f 2|sort|uniq -c|sort -nr|head

439126 CN

135783 RU

74825 AR

51222 US

41353 TW

32850 CA

19558 MY

18962 CO

14234 BR

10824 KR

10334 UA

9103 IT

...

Распределение IP-адресов по ASN вполне типично. Оно во многом соотносится с крупнейшими в мире домашними интернет-провайдерами:

$ cat ips-nf-asn.txt |uniq|cut -f 2|sort|uniq -c|sort -nr|head

318405 4837 # CN China Unicom

84781 4134 # CN China Telecom

72301 22927 # AR Telefonica de Argentina

23823 3462 # TW Chunghwa Telecom

19518 6327 # CA Shaw Communications Inc.

19464 4788 # MY TM Net

18809 3816 # CO Colombia Telecomunicaciones

11328 28573 # BR Claro SA

7070 10796 # US Time Warner Cable Internet

6840 8402 # RU OJSC "Vimpelcom"

6604 3269 # IT Telecom Italia

6377 12768 # RU JSC "ER-Telecom Holding"

...

Впрочем, что такое SSDP?

Данная атака состоит из UDP-пакетов с порта 1900. Этот порт используется протоколами SSDP и UPnP. UPnP — один из протоколов Zeroconf (Zero Configuration Networking), которые создают IP-сеть без конфигурации или специальных серверов. Скорее всего, ваши домашние устройства поддерживают его, чтобы их легче было найти с компьютера или телефона. Когда присоединяется новое устройство (вроде вашего ноутбука), оно может опросить локальную сеть на предмет наличия конкретных устройств, таких как интернет-шлюзы, аудиосистемы, телевизоры или принтеры. Подробнее см. сравнение UPnP и Bonjour.

UPnP плохо стандартизирован, но вот выдержка из спецификаций о фрейме M-SEARCH — основном методе обнаружения:

Когда в сеть добавляется контрольная точка, протокол обнаружения UPnP позволяет этой контрольной точке поиск интересующих устройств в сети. Он делает это с помощью мультивещания поискового сообщения на зарезервированный адрес и порт (239.255.255.250:1900) с шаблоном, или целью, соответствующей типу идентификатора для устройства или сервиса.

Ответы во фрейм M-SEARCH:

Чтобы быть найденным поисковым запросом, устройство должно отправить одноадресный ответ UDP на IP-адрес источника и порт, который прислал сообщение с помощью мультивещания. Ответ требуется, если в поле заголовка ST в запросе M-SEARCH указано “ssdp:all”, “upnp:rootdevice”, “uuid:”, а далее следует UUID, который в точности соответствует UUID устройства, или если запрос M-SEARCH соответствует типу устройства или типу сервиса, поддерживаемому устройством.

Так оно и работает на практике. Например, мой браузер Chrome регулярно опрашивает Smart TV, насколько я понимаю:

$ sudo tcpdump -ni eth0 udp and port 1900 -A

IP 192.168.1.124.53044 > 239.255.255.250.1900: UDP, length 175

M-SEARCH * HTTP/1.1

HOST: 239.255.255.250:1900

MAN: "ssdp:discover"

MX: 1

ST: urn:dial-multiscreen-org:service:dial:1

USER-AGENT: Google Chrome/58.0.3029.110 Windows

Этот фрейм отправляется на IP-адрес для мультивещания. Другие устройства, которые слушают этот адрес и поддерживают специфический многоэкранный тип ST (search-target), должны ответить.

Кроме запросов специфических типов устройств, существует два «общих» типа запросов ST:

• upnp:rootdevice: поиск корневых устройств
• ssdp:all: поиск всех устройств и сервисов UPnP

Для имитации этих запросов вы можете запустить такой скрипт Python (основанный на этой работе):

#!/usr/bin/env python2
import socket  
import sys

dst = "239.255.255.250"  
if len(sys.argv) > 1:  
    dst = sys.argv[1]
st = "upnp:rootdevice"  
if len(sys.argv) > 2:  
    st = sys.argv[2]

msg = [  
    'M-SEARCH * HTTP/1.1',
    'Host:239.255.255.250:1900',
    'ST:%s' % (st,),
    'Man:"ssdp:discover"',
    'MX:1',
    '']

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)  
s.settimeout(10)  
s.sendto('\r\n'.join(msg), (dst, 1900) )

while True:  
    try:
        data, addr = s.recvfrom(32*1024)
    except socket.timeout:
        break
    print "[+] %s\n%s" % (addr, data)

В моей домашней сети отзываются два устройства:

$ python ssdp-query.py
[+] ('192.168.1.71', 1026)
HTTP/1.1 200 OK  
CACHE-CONTROL: max-age = 60  
EXT:  
LOCATION: http://192.168.1.71:5200/Printer.xml  
SERVER: Network Printer Server UPnP/1.0 OS 1.29.00.44 06-17-2009  
ST: upnp:rootdevice  
USN: uuid:Samsung-Printer-1_0-mrgutenberg::upnp:rootdevice

[+] ('192.168.1.70', 36319)
HTTP/1.1 200 OK  
Location: http://192.168.1.70:49154/MediaRenderer/desc.xml  
Cache-Control: max-age=1800  
Content-Length: 0  
Server: Linux/3.2 UPnP/1.0 Network_Module/1.0 (RX-S601D)  
EXT:  
ST: upnp:rootdevice  
USN: uuid:9ab0c000-f668-11de-9976-000adedd7411::upnp:rootdevice 

Файрвол

Теперь, когда мы понимаем основы SSDP, будет легко понять суть атаки с отражением. На самом деле есть два способа доставки фрейма M-SEARCH:

• который мы показали, через адрес для мультивещания
• напрямую хосту UPnP/SSDP на обычном адресе (одноадресная передача)

Второй метод тоже работает. Мы можем конкретно указать IP-адрес моего принтера:

$ python ssdp-query.py 192.168.1.71
[+] ('192.168.1.71', 1026)
HTTP/1.1 200 OK  
CACHE-CONTROL: max-age = 60  
EXT:  
LOCATION: http://192.168.1.71:5200/Printer.xml  
SERVER: Network Printer Server UPnP/1.0 OS 1.29.00.44 06-17-2009  
ST: upnp:rootdevice  
USN: uuid:Samsung-Printer-1_0-mrgutenberg::upnp:rootdevice  

Теперь проблема легко понятна: протокол SSDP не проверяет, находится ли отправитель сообщения в той же сети, что и устройство. Оно с радостью ответит на запрос M-SEARCH, который пришёл из интернета. Требуется только чуть неправильная настройка файрвола, когда порт 1900 открыт внешнему миру — и вот идеальная мишень для умножения флуда UDP.

Если дать нашему скрипту такую мишень с неправильной конфигурацией файрвола, то он отлично сработает через интернет:

$ python ssdp-query.py 100.42.x.x
[+] ('100.42.x.x', 1900)
HTTP/1.1 200 OK  
CACHE-CONTROL: max-age=120  
ST: upnp:rootdevice  
USN: uuid:3e55ade9-c344-4baa-841b-826bda77dcb2::upnp:rootdevice  
EXT:  
SERVER: TBS/R2 UPnP/1.0 MiniUPnPd/1.2  
LOCATION: http://192.168.2.1:40464/rootDesc.xml

Умножение пакетов

Впрочем, самый реальный вред наносит тип ssdp:all ST. Его ответы намного больше по размеру:

$ python ssdp-query.py 100.42.x.x ssdp:all
[+] ('100.42.x.x', 1900)
HTTP/1.1 200 OK  
CACHE-CONTROL: max-age=120  
ST: upnp:rootdevice  
USN: uuid:3e55ade9-c344-4baa-841b-826bda77dcb2::upnp:rootdevice  
EXT:  
SERVER: TBS/R2 UPnP/1.0 MiniUPnPd/1.2  
LOCATION: http://192.168.2.1:40464/rootDesc.xml

[+] ('100.42.x.x', 1900)
HTTP/1.1 200 OK  
CACHE-CONTROL: max-age=120  
ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1  
USN: uuid:3e55ade9-c344-4baa-841b-826bda77dcb2::urn:schemas-upnp-org:device:InternetGatewayDevice:1  
EXT:  
SERVER: TBS/R2 UPnP/1.0 MiniUPnPd/1.2  
LOCATION: http://192.168.2.1:40464/rootDesc.xml

... и ещё 6 ответных пакетов....

В этом конкретном случае единственный пакет SSDP M-SEARCH вызвал 8 пакетов в ответ. Просмотр в tcpdump:

$ sudo tcpdump -ni en7 host 100.42.x.x -ttttt

00:00:00.000000 IP 192.168.1.200.61794 > 100.42.x.x.1900: UDP, length 88

00:00:00.197481 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 227

00:00:00.199634 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 299

00:00:00.202938 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 295

00:00:00.208425 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 275

00:00:00.209496 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 307

00:00:00.212795 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 289

00:00:00.215522 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 291

00:00:00.219190 IP 100.42.x.x.1900 > 192.168.1.200.61794: UDP, length 291

Мишень совершила восьмикратное умножение пакетов и 26-кратное умножение трафика. К сожалению, это типичный случай SSDP.

Спуфинг IP

Последний шаг, необходимый для проведения атаки — убедить уязвимые серверы отсылать ответные пакеты на адрес жертвы, а не злоумышленника. Для этого злоумышленнику необходимо подделать IP-адрес отправителя в своих запросах.

Мы опросили IP-адреса рефлекторов, которые использовались в вышеупомянутой атаке на 100 Гбит/с. Оказалось, что из 920 тыс. адресов только 350 тыс. (35%) по прежнему отвечают на пробные запросы SSDP.

Ответившим на пробные запросы мы отправляли, в среднем, 7 пакетов:

$ cat results-first-run.txt|cut -f 1|sort|uniq -c|sed -s 's#^ \+##g'|cut -d " " -f 1| ~/mmhistogram -t "Response packets per IP" -p

Response packets per IP min:1.00 avg:6.99 med=8.00 max:186.00 dev:4.44 count:350337

Response packets per IP:

value |-------------------------------------------------- count

0 | ****************************** 23.29%

1 | **** 3.30%

2 | ** 2.29%

4 |************************************************** 38.73%

8 | ************************************** 29.51%

16 | *** 2.88%

32 | 0.01%

64 | 0.00%

128 | 0.00%

Пакеты с запросами имели размер 110 байт. Пакеты с ответами — в среднем, 321 байт (± 29 байт).

Согласно нашим измерениям, используя тип ssdp:all M-SEARCH, злоумышленник может получить:

• 7-кратное умножение количества пакетов
• 20-кратное умножение трафика

Можно подсчитать, что атака на 43 млн пакетов в секунду и 112 Гбит/с была инициирована с помощью:

• 6,1 млн пакетов в секунду
• канала 5,6 Гбит/с

Другими словами, один хорошо подключенный сервер на 10 Гбит/с, способный на подделку IP, может сгенерировать значительную атаку SSDP.

Подробнее о серверах SSDP

Поскольку мы опросили уязвимые серверы SSDP, мы можем показать самые популярные значения заголовка Server:

104833 Linux/2.4.22-1.2115.nptl UPnP/1.0 miniupnpd/1.0

77329 System/1.0 UPnP/1.0 IGD/1.0

66639 TBS/R2 UPnP/1.0 MiniUPnPd/1.2

12863 Ubuntu/7.10 UPnP/1.0 miniupnpd/1.0

11544 ASUSTeK UPnP/1.0 MiniUPnPd/1.4

10827 miniupnpd/1.0 UPnP/1.0

8070 Linux UPnP/1.0 Huawei-ATP-IGD

7941 TBS/R2 UPnP/1.0 MiniUPnPd/1.4

7546 Net-OS 5.xx UPnP/1.0

6043 LINUX-2.6 UPnP/1.0 MiniUPnPd/1.5

5482 Ubuntu/lucid UPnP/1.0 MiniUPnPd/1.4

4720 AirTies/ASP 1.0 UPnP/1.0 miniupnpd/1.0

4667 Linux/2.6.30.9, UPnP/1.0, Portable SDK for UPnP devices/1.6.6

3334 Fedora/10 UPnP/1.0 MiniUPnPd/1.4

2814 1.0

2044 miniupnpd/1.5 UPnP/1.0

1330 1

1325 Linux/2.6.21.5, UPnP/1.0, Portable SDK for UPnP devices/1.6.6

843 Allegro-Software-RomUpnp/4.07 UPnP/1.0 IGD/1.00

776 Upnp/1.0 UPnP/1.0 IGD/1.00

675 Unspecified, UPnP/1.0, Unspecified

648 WNR2000v5 UPnP/1.0 miniupnpd/1.0

562 MIPS LINUX/2.4 UPnP/1.0 miniupnpd/1.0

518 Fedora/8 UPnP/1.0 miniupnpd/1.0

372 Tenda UPnP/1.0 miniupnpd/1.0

346 Ubuntu/10.10 UPnP/1.0 miniupnpd/1.0

330 MF60/1.0 UPnP/1.0 miniupnpd/1.0

...

Самые популярные значения заголовка ST:

298497 upnp:rootdevice

158442 urn:schemas-upnp-org:device:InternetGatewayDevice:1

151642 urn:schemas-upnp-org:device:WANDevice:1

148593 urn:schemas-upnp-org:device:WANConnectionDevice:1

147461 urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1

146970 urn:schemas-upnp-org:service:WANIPConnection:1

145602 urn:schemas-upnp-org:service:Layer3Forwarding:1

113453 urn:schemas-upnp-org:service:WANPPPConnection:1

100961 urn:schemas-upnp-org:device:InternetGatewayDevice:

100180 urn:schemas-upnp-org:device:WANDevice:

99017 urn:schemas-upnp-org:service:WANCommonInterfaceConfig:

98112 urn:schemas-upnp-org:device:WANConnectionDevice:

97246 urn:schemas-upnp-org:service:WANPPPConnection:

96259 urn:schemas-upnp-org:service:WANIPConnection:

93987 urn:schemas-upnp-org:service:Layer3Forwarding:

91108 urn:schemas-wifialliance-org:device:WFADevice:

90818 urn:schemas-wifialliance-org:service:WFAWLANConfig:

35511 uuid:IGD{8c80f73f-4ba0-45fa-835d-042505d052be}000000000000

9822 urn:schemas-upnp-org:service:WANEthernetLinkConfig:1

7737 uuid:WAN{84807575-251b-4c02-954b-e8e2ba7216a9}000000000000

6063 urn:schemas-microsoft-com:service:OSInfo:1

...

Уязвимые IP-адреса как будто принадлежат, в основном, домашним маршрутизаторам.

Открытый SSDP — это уязвимость

Само собой понятно, что разрешить входящий трафик 1900/UDP из интернета на ваш домашний принтер или другое устройство — не самая лучшая идея. Эта проблема известна по крайней мере с января 2013 года:
Авторы SSDP явно не думали о потенциале UDP как умножителя пакетов. Есть некоторые очевидные рекомендации об использовании SSDP в будущем:

• Авторы SSDP должны ответить, существует ли в реальном мире хоть какая-то возможность использования одноадресных запросов M-SEARCH. Насколько я понимаю, M-SEARCH имеет практический смысл только как многоадресный запрос в локальной сети.
• Поддержку одноадресных запросов M-SEARCH нужно либо отменить, либо ограничить по скорости, как действует ограничение DNS Response Rate Limit.
• Ответы M-SEARCH должны отправляться только получателям в локальной сети. Ответы за пределы локальной сети имеют мало смысла и открывают возможность использования описанной уязвимости.

В то же время мы рекомендуем:

• Сетевые администраторы должны убедиться, что входящий порт 1900/UDP заблокирован на файрволе.
• Интернет-провайдеры никогда не должны разрешать IP-спуфинг в своей сети. Подделка IP-адресов — вот истинная корневая причина проблемы. См. пресловутый BCP38.
• Интернет-провайдеры должны разрешить своим пользователям использовать BGP flowspec для ограничения входящего трафика 1900/UDP, чтобы рассредоточить скопление трафика при крупных атаках SSDP.
• Интернет-провайдеры должны собирать образцы netflow. Это нужно для определения истинного источника атаки. С netflow будет просто ответить на вопросы типа: «Кто из моих клиентов отправлял 6,4 млн пакетов в секунду на порт 1900?» Для соблюдения конфиденциальности мы рекомендуем собирать образцы трафика с максимальным промежутком выборки: 1 из 64 000 пакетов. Этого достаточно для выявления DDoS-атак, и в то же время сохраняется достаточная конфиденциальность отдельных пользовательских сессий.
• Разработчикам не следует выкатывать свои собственные протоколы UDP, не приняв в расчёт проблемы умножения пакетов. UPnP нужно нормально стандартизировать и изучить.
• Конечным пользователям рекомендуется запустить скрипт для сканирования своих сетей на предмет устройств с функцией UPnP и подумать, стоит ли разрешать им выход в интернет.

Более того, мы сделали веб-сайт для онлайновой проверки. Зайдите на него, если хотите узнать, есть ли на вашем публичном IP-адресе уязвимые сервисы SSDP:
К сожалению, большинство незащищённых маршрутизаторов, которые использовались в этой атаке, находятся в Китае, России и Аргентине — местах, которые исторически не славятся расторопностью интернет-провайдеров.

Итог

Клиенты Cloudflare полностью защищены от атак SSDP и других атак с умножением класса L3. Эти атаки хорошо отражаются инфраструктурой Cloudflare и не требуют дополнительных действий. Однако увеличение размера SSDP может стать серьёзной проблемой для других пользователей интернета. Мы должны призвать своих интернет-провайдеров запретить IP-спуфинг в своих сетях, включить поддержку BGP flowspec и настроить сбор потока данных в сети (netflow).

Статью подготовили совместно Марек Майковски и Бен Картрайт-Кокс.

Домашняя страница проекта MiniUPnP

Домашняя страница проекта MiniUPnP

Домашняя страница проекта MiniUPnP

Последнее изменение: 26 мая 2017 г.

Зеркала

Если у вас возникли проблемы с этим веб-сайтом, у вас есть альтернативы:

Предисловие

Проект MiniUPnP предлагает программное обеспечение, поддерживающее
Технические характеристики устройства Интернет-шлюза (IGD) UPnP.
NAT-PMP и
PCP
добавлена ​​поддержка в MiniUPnPd .
Для поддержки NAT-PMP на стороне клиента используйте
libnatpmp.
Демон MiniUPnP ( MiniUPnPd ) поддерживает
OpenBSD,
FreeBSD,
NetBSD,
DragonFly BSD,
(Открыть) Solaris и
Mac OS X
в сочетании с pf
или ipfw (ipfirewall)
или ipf
и Linux с
netfilter.
Клиент MiniUPnP ( MiniUPnPc ) и MiniSSDPd являются портативными и должны работать
в любой системе POSIX. MiniUPnPc также работает под MS Windows и
AmigaOS (версии 3 и 4).

Облегченная клиентская библиотека UPnP IGD и демон UPnP IGD

Протокол UPnP поддерживается большинством
домашние ADSL / кабельные маршрутизаторы и Microsoft Windows 2K / XP.Целью проекта MiniUPnP является
принести бесплатное программное решение для поддержки «Интернет-шлюза»
часть протокола.
Протокол MediaServer / MediaRenderer UPnP
(DLNA) также становится очень
популярно, но здесь мы говорим о IGD.
ReadyMedia
(ранее известный как MiniDLNA) — медиасервер UPnP.
используя некоторый код UPnP из MiniUPnPd.

Linux SDK для устройств UPnP (libupnp)
показалось мне слишком тяжелым. Я хочу самую простую библиотеку,
с наименьшей занимаемой площадью и без зависимостей
в другие библиотеки, такие как парсеры XML или
Реализации HTTP.Весь код — чистый ANSI C.

Скомпилирована на ПК x86, клиентская библиотека miniupnp имеет
размер кода менее 50 КБ.
Демон miniUPnP намного меньше любого другого демона IGD.
и по этой причине идеально подходит для использования на устройствах с низким объемом памяти.
Он также использует только ОДИН процесс без дополнительных потоков, не
используйте любой вызов system () или exec () ,
и, следовательно, сохраняет использование системных ресурсов
очень низкий.

Проект разделен на две основные части:

• MiniUPnPc, клиентская библиотека, обеспечивающая доступ приложений к
  услуги, предоставляемые
  UPnP «Internet Gateway Device», присутствующий в сети.В терминологии UPnP MiniUPnPc — это контрольная точка UPnP.
• MiniUPnPd, демон, предоставляющий эти услуги вашей сети из Linux.
  или ящик BSD (или даже Solaris), являющийся шлюзом. Следуя терминологии UPnP,
  MiniUPnPd — это устройство UPnP.

MiniSSDPd
разработан для совместной работы с MiniUPnPc, MiniUPnPd и другими
кооперативное программное обеспечение:
MiniSSDPd прослушивает трафик SSDP в сети, поэтому MiniUPnPc или другой
Контрольные точки UPnP не
необходимо выполнить процесс обнаружения и может работать быстрее, чтобы настроить
перенаправление.MiniSSDPd также может отвечать на запросы M-SEARCH SSDP.
от имени MiniUPnPd или другого серверного программного обеспечения UPnP.
Это полезно для размещения нескольких служб UPnP на одном компьютере,
такие как MiniDLNA
и MediaTomb и MiniUPnPd.
MiniUPnPd изначально использует
MiniSSDPd, если он запущен на том же компьютере, но для другого программного обеспечения UPnP может потребоваться
быть исправленным: читать
Патч MiniSSDPd для MiniDLNA (не требуется для MiniDLNA 1.0.22 и выше)
и патч MiniSSDPd для MediaTomb.

MiniUPnPd был впервые разработан
на OpenBSD 3.0+ с pf.
Вы можете увидеть часть работы, которую я проделал
интегрироваться с pf на этой странице
(устарело).

Поскольку pf также доступен во FreeBSD,
ребята из проекта pfSense
портировали miniupnpd в эту систему. Теперь это должно быть возможно
для компиляции и запуска на каждой платформе, где доступен pf.
Демон теперь также доступен для Linux 2.4.x и 2.6.x с использованием
netfilter. Это возможно сделать
запускать на маршрутизаторах, работающих под управлением OpenWRT.

Даррен Рид работал над
Реализация IP-фильтра (ipf).Боюсь, что не поддерживается …
Даррен также добавил поддержку Solaris / OpenSolaris.
Порт ipfw доступен для MacOS X. Должна быть возможность сделать
он работает и на FreeBSD, но я не получил никаких отзывов об этом.

По некоторым причинам это может быть не лучшим решением для вас.
код из проекта MiniUPnP напрямую.
Поскольку код небольшой и простой для понимания, это хорошая основа
черпать вдохновение для собственной реализации UPnP.
KTorrent
Плагин UPnP на C ++ — хороший тому пример.

Если вам интересно, какой домашний маршрутизатор работает с клиентом MiniUPnP,
вы можете найти ответ здесь. По факту,
вы, скорее всего, поможете мне заполнить список, отправив мне электронное письмо 🙂

Полезность клиентской библиотеки MiniUPnP

Использование клиентской библиотеки MiniUPnP полезно
всякий раз, когда приложению необходимо прослушивать входящие соединения.
Примеры: приложения P2P, клиенты FTP для активного режима,
IRC (для DCC) или IM-приложения, сетевые игры, любое серверное ПО.

Типичное использование возможностей UPnP IGD маршрутизатора — это файл
перевод через мессенджер MSN. Программное обеспечение MSN Messenger
использует UPnP API Windows XP, чтобы открыть порт для входящего соединения.
Чтобы имитировать программное обеспечение MS, неплохо также использовать UPnP.

Сделал патч для XChat
чтобы показать, как клиентская библиотека miniupnp может использоваться приложением.

Трансмиссия,
бесплатный программный клиент BitTorrent использует miniupnpc и libnatpmp.

Полезность демона MiniUPnP

UPnP и NAT-PMP используются для улучшения
подключение к Интернету для
устройства за NAT-маршрутизатором.Любое одноранговое сетевое приложение
такие как игры, обмен мгновенными сообщениями и т. д. могут получить преимущества от маршрутизатора NAT, поддерживающего
UPnP и / или NAT-PMP.

Microsoft XBOX 360 последнего поколения и Sony Playstation 3
игровые машины используют команды UPnP для включения
онлайн-игра с сервисом XBOX Live и PlayStation Network.
Сообщалось, что MiniUPnPd корректно работает с двумя
консоли. Однако может потребоваться точная настройка конфигурации.
Поищите обсуждения по этой теме в
Форум.

Безопасность

Реализации

UPnP потенциально подвержены нарушениям безопасности.Плохо реализованные или настроенные IGD UPnP уязвимы.
Исследователь безопасности HD Мур хорошо поработал над выявлением уязвимостей
в существующих реализациях: Недостатки безопасности в Universal Plug and Play (PDF).
Распространенная проблема — позволить портам SSDP или HTTP / SOAP открываться в Интернет:
они должны быть доступны только из LAN.

В прошлом в MiniUPnPd было обнаружено несколько уязвимостей,
поэтому очень важно обновить ваш код до последней версии.

История обновлений

Теперь он доступен здесь.

Участвовать

Вы можете скачать исходный код на странице загрузки
или загрузите исходники на github.

Если у вас возникнут проблемы или вы хотите реализовать какую-то функцию,
пойти в
Форум.

Жду ваших комментариев и патчей!
Заранее благодарим вас за отзыв.

Пожертвовать

Лучший подарок, который вы можете сделать, — это внести свой вклад в
проект, отправив патч!
В любом случае, если это невозможно, вы можете использовать кнопку PayPal Donate
ниже.

Вы также можете поддержать TuxFamily,
некоммерческая организация, которая принимает
веб-форум и часть веб-сайта:
http://www.tuxfamily.org/en/support.

Карта сайта

Ссылки

Томас Бернар

Используйте форум
или свяжитесь со мной по электронной почте: miniupnp _AT_ free _DOT_ fr

.

Ubuntu — Подробная информация о пакете miniupnpd в xenial

Ссылки для miniupnpd

Ресурсы Ubuntu:

Загрузить исходный код miniupnpd:

Сопровождающий:

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

Исходный сопровождающий (обычно из Debian):

Обычно пользователям не нужно связываться с первоначальным сопровождающим.

Внешние ресурсы:

Подобные пакеты:

Демон UPnP и NAT-PMP для шлюзовых маршрутизаторов

Другие пакеты, относящиеся к miniupnpd

• деп .:
  debconf

  Система управления конфигурацией Debian

• деп .:
  debconf
  (> = 0.5)

  Система управления конфигурацией Debian

  или
  debconf-2.0

  виртуальный пакет, предоставленный

  cdebconf, cdebconf-udeb, debconf

• деп .:
  iproute2

  инструменты для работы в сети и управления трафиком

  или
  iproute

  переходной пакет-пустышка для iproute2

• деп .:
  iptables

  Инструменты администрирования для фильтрации пакетов и NAT

• деп .:
  libc6
  (> = 2.15)
  [не arm64, ppc64el]

  Библиотека GNU C: общие библиотеки
  также виртуальный пакет, предоставляемый

  libc6-udeb

  деп .:
  libc6
  (> = 2,17)
  [arm64, ppc64el]

• деп .:
  libnfnetlink0

  Библиотека netlink Netfilter

• деп .:
  сетевые инструменты

  Сетевой инструментарий NET-3

• деп .:
  uuid-runtime

  компоненты среды выполнения для библиотеки универсального уникального идентификатора

.Модуль

ClearOS — Демон MiniUPNP

Я создал и упаковал демон MiniUPNP, чтобы он работал с ClearOS
http://miniupnp.free.fr/

. Он зависит от вашей системы, настроенной в режиме шлюза, он также был протестирован только в одной среде WAN. MultiWAN является экспериментальным и может быть получен путем редактирования конфигурации (/etc/miniupnpd/miniupnpd.conf) и iptables (см. Ниже)

Его можно использовать как прямую замену LinuxIGD, что является недостатком, при котором будет создано несколько правил. с одним и тем же портом для нескольких устройств.

MiniUPNPD также поддерживает NAT-PMP

УСТАНОВИТЬ: —
Настройте репозиторий yum сообщества, следуя инструкциям ЗДЕСЬ

  yum --enablerepo = timb install miniupnpd  

Добавьте следующий код в /etc/rc.d/rc.firewall.local для создания таблиц MiniUPNPD, если это необходимо. что после перезапуска брандмауэра таблицы не исчезают.

  ## 

#MINIUPNPD обязательные таблицы 

## 

IPTABLES = / sbin / iptables 

# EXTIF = (не требуется, так как используется автоматическое определение WAN, можно указать вручную) 

# добавление цепочки MINIUPNPD для нац 

$ IPTABLES -t nat -N MINIUPNPD 

# добавление правила в MINIUPNPD 

$ IPTABLES -t nat -A PREROUTING -i $ EXTIF -j MINIUPNPD 
 # добавление цепочки MINIUPNPD для фильтра 

$ IPTABLES -t фильтр -N MINIUPNPD 

# добавление правила в MINIUPNPD 

$ IPTABLES -t фильтр -A FORWARD -i $ EXTIF -o! $ EXTIF -j MINIUPNPD 
 
  

Затем просмотрите конфигурацию в / etc / miniupnpd / miniupnpd.conf — никаких изменений не требуется …. Внешняя WAN определяется с помощью автоматической функции ClearOS.

Затем перезапустите брандмауэр, чтобы создать таблицы, и запустите службу

  перезапуск брандмауэра службы 

сервис miniupnpd start  

Вуаля! Теперь у вас должно быть работающее устройство шлюза UPNP, вы можете проверить журналы и записи, запустив

  grep upnpd / var / log / messages 

или 

iptables -t нат -L MINIUPNPD -n -v 

iptables -L MINIUPNPD -n -v  

Наслаждайтесь

.