Simple service discovery protocol что это

Обновлено: 03.05.2024

Сеть с нулевой конфигурацией ( zeroconf ) - это набор технологий, которые автоматически создают пригодную для использования компьютерную сеть на основе пакета Internet Protocol Suite (TCP / IP), когда компьютеры или сетевые периферийные устройства соединены между собой. Не требует ручного вмешательства оператора или специальных серверов конфигурации. Без zeroconf сетевой администратор должен настроить сетевые службы , такие как протокол динамической конфигурации хоста (DHCP) и систему доменных имен (DNS), или настроить параметры сети каждого компьютера вручную.

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

Провести атаку с подделкой Host

Решение

Вообще, с точки зрения безопасности, это немного странная, но неопасная ситуация. Казалось бы, да, подставив свое доменное имя в Host, мы можем сделать так, чтобы на ресурс загрузились бы наши JS-скрипты (считай — XSS). Но заставить чужой браузер сделать то же самое (то есть вставить неверный Host), по сути, невозможно. Так что с точки зрения SOP здесь все вроде вполне нормально.

Но недавно я прочитал интересный пример эксплуатации данной фичи. Представь себе страницу восстановления пароля. Вводишь имя почты, и на нее отправляется ссылка со случайным токеном для смены пароля (классическая ситуация). Так вот, мы также можем подставить свой Host в запросе, и тогда письмо, которое придет пользователю, будет содержать наш домен! И как только пользователь кликнет на данную ссылку, на наш домен он перейдет вместе с токеном, который мы можем быстренько использовать для смены пароля.

Но все же в этой атаке что-то точно есть.

Случай, когда значение Host возвращается как путь к ресурсам страницы

Выбор адреса

Хостам в сети должны быть назначены IP-адреса, которые однозначно идентифицируют их для других устройств в той же сети. В некоторых сетях есть центральный орган, который назначает эти адреса при добавлении новых устройств. Были введены механизмы для автоматической обработки этой задачи, и теперь как IPv4, так и IPv6 включают системы автоконфигурации адресов , которые позволяют устройству определять безопасный адрес для использования с помощью простых механизмов. Для локальной адресации IPv4 использует специальный блок 169.254.0.0 / 16, как описано в RFC 3927, в то время как хосты IPv6 используют префикс fe80 :: / 10 . Чаще адреса назначаются DHCP-сервером , часто встроенным в обычное сетевое оборудование, такое как компьютерные хосты или маршрутизаторы.

Большинство хостов IPv4 используют локальную адресацию только в крайнем случае, когда сервер DHCP недоступен. В противном случае хост IPv4 использует свой назначенный DHCP адрес для всех коммуникаций, глобальных или локальных. Одна из причин заключается в том, что хосты IPv4 не обязаны поддерживать несколько адресов на интерфейс, хотя многие из них это делают. Другой заключается в том, что не каждый хост IPv4 реализует распределенное разрешение имен (например, многоадресный DNS ), поэтому обнаружение автоматически настроенного локального адреса канала другого хоста в сети может быть трудным. Обнаружение назначенного DHCP адреса другого хоста требует либо распределенного разрешения имен, либо одноадресного DNS-сервера с этой информацией; В некоторых сетях есть DNS-серверы, которые автоматически обновляются с помощью назначенных DHCP информации об узле и адресе.

Стандартизация

RFC 2608 , стандарт SLP для определения того, где получить услуги, был опубликован в июне 1999 года рабочей группой SVRLOC IETF.

RFC 3927 , стандарт для выбора адресов для сетевых элементов, был опубликован в марте 2005 года рабочей группой IETF Zeroconf. В группу входили представители Apple, Sun и Microsoft.

LLMNR был представлен для официального утверждения в рабочей группе IETF DNSEXT, однако не получил консенсуса и, таким образом, был опубликован как информационный RFC 4795 в январе 2007 года.

После того, как LLMNR не стал стандартом Интернета и с учетом того, что mDNS / DNS-SD используется гораздо шире, чем LLMNR, IETF попросила Apple представить спецификации mDNS / DNS-SD для публикации в качестве информационного RFC.

В феврале 2013 года mDNS и DNS-SD были опубликованы как предложения по отслеживанию стандартов RFC 6762 и RFC 6763 .

Обнаружение службы

Службы имен, такие как mDNS, LLMNR и другие, не предоставляют информацию о типе устройства или его статусе. Например, пользователю, ищущему ближайший принтер, может помешать, если принтеру будет присвоено имя «Боб». Обнаружение службы предоставляет дополнительную информацию об устройствах. Обнаружение службы иногда сочетается со службой имен , как в протоколе привязки имен Apple и NetBIOS от Microsoft .

Обнаружение службы NetBIOS

NetBIOS в Windows поддерживает отдельные хосты в сети для рекламы услуг, таких как общие файловые ресурсы и принтеры. Он также поддерживает, например, сетевой принтер, чтобы рекламировать себя как хост, совместно использующий принтер и любые связанные службы, которые он поддерживает. В зависимости от того, как устройство подключено (к сети напрямую или к хосту, который его разделяет) и какие протоколы поддерживаются. Однако клиенты Windows, подключающиеся к нему, могут предпочесть использовать SSDP или WSD с помощью NetBIOS. NetBIOS - один из поставщиков в Windows, реализующий более общий процесс обнаружения, названный обнаружением функций, который включает встроенных поставщиков для PnP, Registry, NetBIOS, SSDP и WSD, из которых первые два являются только локальными, а последние три поддерживают обнаружение сетевых устройств. Ни один из них не требует настройки для использования в локальной подсети. NetBIOS традиционно поддерживается только в дорогих принтерах для корпоративного использования, хотя некоторые принтеры начального уровня с Wi-Fi или Ethernet поддерживают его изначально, что позволяет использовать принтер без настройки даже в очень старых операционных системах.

WS-Discovery

Динамическое обнаружение веб-служб ( WS-Discovery ) - это техническая спецификация, которая определяет протокол многоадресного обнаружения для обнаружения служб в локальной сети. Он работает через TCP и UDP-порт 3702 и использует многоадресный IP-адрес 239.255.255.250 . Как следует из названия, фактическая связь между узлами осуществляется с использованием стандартов веб-сервисов, особенно SOAP-over-UDP . Windows поддерживает его в виде веб-служб для устройств и профиля устройств для веб-служб . Многие устройства, например принтеры HP и Brother, поддерживают его.

Обнаружение службы на основе DNS

DNS-SD позволяет клиентам обнаруживать именованный список экземпляров служб и преобразовывать эти службы в имена хостов с помощью стандартных DNS-запросов. Спецификация совместима с существующим одноадресным DNS-сервером и клиентским программным обеспечением, но одинаково хорошо работает с mDNS в среде с нулевой конфигурацией. Каждый экземпляр службы описывается с помощью записи DNS SRV и DNS TXT. Клиент обнаруживает список доступных экземпляров для данного типа службы, запрашивая запись DNS PTR с именем этого типа службы; сервер возвращает ноль или более имен в форме <Служба>. <Домен>, каждое из которых соответствует паре записей SRV / TXT. ЗаписьSRVпреобразуется в доменное имя, предоставляющее экземпляр, в то время как TXT может содержать параметры конфигурации для конкретной службы. Затем клиент может разрешить запись A / AAAA для имени домена и подключиться к службе.

История

В 1997 году Стюарт Чешир предложил адаптировать зрелый протокол привязки имен Apple к IP-сетям, чтобы решить проблему отсутствия возможности обнаружения сервисов. Впоследствии Чешир присоединился к Apple и разработал проект предложений IETF по mDNS и обнаружению служб на основе DNS, поддерживая переход от AppleTalk к IP-сетям. В 2002 году Apple объявила о реализации обоих протоколов под названием Rendezvous (позже переименована в Bonjour). Впервые он был включен в Mac OS X 10.2 , заменив протокол SLP, используемый в 10.1 . В 2013 году предложения были ратифицированы как RFC 6762 и RFC 6763 .

DNS-SD с многоадресной рассылкой

mDNS использует пакеты, аналогичные одноадресным DNS, для разрешения имен хостов, за исключением того, что они отправляются по многоадресной ссылке. Каждый хост прослушивает порт mDNS, 5353, передаваемый на известный многоадресный адрес, и разрешает запросы DNS-записи своего .local имени хоста (например, A , AAAA , CNAME ) на свой IP-адрес. Когда клиенту mDNS необходимо преобразовать локальное имя хоста в IP-адрес, он отправляет DNS-запрос для этого имени на известный многоадресный адрес; компьютер с соответствующей записью A / AAAA отвечает своим IP-адресом. Многоадресный адрес mDNS - 224.0.0.251 для IPv4 и ff02 :: fb для IPv6-адресации локального канала.

Запросы на обнаружение службы DNS (DNS-SD) также можно отправлять с помощью mDNS, чтобы получить DNS-SD с нулевой конфигурацией. При этом используются записи DNS PTR , SRV, TXT для рекламы экземпляров типов служб, доменных имен для этих экземпляров и дополнительных параметров конфигурации для подключения к этим экземплярам. Но записи SRV теперь могут преобразовываться в имена доменов .local , которые mDNS может преобразовывать в локальные IP-адреса.

Служба поддержки

UPnP имеет некоторые компоненты протокола, предназначенные для обнаружения служб.

Digital Living Network Alliance (DLNA) - еще один набор стандартов, использующий UPnP для обнаружения сетевых устройств. DLNA имеет длинный список известных производителей, выпускающих такие устройства, как телевизоры, NAS-устройства и т. Д., Которые его поддерживают. DLNA поддерживается всеми основными операционными системами. Обнаружение службы DLNA расположено поверх SSDP.

Попытки создать стандартный протокол IETF

SLP поддерживается сетевыми принтерами Hewlett-Packard , Novell и Sun Microsystems . SLP описан в RFC 2608 и RFC 3224, и его реализации доступны как для Solaris, так и для Linux .

AllJoyn

СОДЕРЖАНИЕ

Уязвимость Firefox

Firefox для Android до версии 79 неправильно проверял схему URL-адреса, полученного в SSDP, и был уязвим для удаленного выполнения кода. Злоумышленник в той же сети может создать вредоносный сервер, выдавая себя за устройство, поддерживающее трансляцию, но вместо файла конфигурации он вернет intent:// URL-адрес. Firefox запустит намерение (если оно поддерживается устройством) и, таким образом, выполнит произвольный код. Это не ошибка SSDP, а просто неправильная проверка, выполненная службой кастинга Firefox.

Easy Hack: Хакерские секреты простых вещей

Технологий становится все больше и больше. Они рождаются, меняются, исчезают и перерождаются. Все это создает большой ком, который растет и растет. Зачастую во многих компаниях разобраться с тем, что вообще используется в корпоративной инфраструктуре, — уже большая задача, не говоря о том, чтобы это все безопасно настроить… Это я к тому, что мест, через которые мы можем что-то где-то поломать или хотя бы выведать, — огромное количество. Сегодня этого мы и коснемся. И первым примером будет электронная почта.

СОДЕРЖАНИЕ

Компьютерные сети используют числовые сетевые адреса для идентификации конечных точек связи в сети участвующих устройств. Это похоже на телефонную сеть, которая назначает строку цифр для идентификации каждого телефона. В современных сетевых протоколах передаваемая информация делится на серию сетевых пакетов . Каждый пакет содержит адреса отправителя и получателя для передачи. Сетевые маршрутизаторы проверяют эти адреса, чтобы определить лучший сетевой путь при пересылке пакета данных на каждом этапе к месту назначения.

Подобно тому, как телефоны маркируются своим телефонным номером, в ранних сетях было обычной практикой прикреплять адресные метки к сетевым устройствам. Динамический характер современных сетей, особенно жилых сетей, в которых устройства включаются только при необходимости, требует механизмов динамического назначения адресов, которые не требуют участия пользователя для инициализации и управления. Эти системы автоматически получают общие имена, выбранные либо производителем оборудования, такие как марка и номер модели, либо выбираемые пользователями для идентификации своего оборудования. Затем имена и адреса автоматически вводятся в службу каталогов .

Ранние компьютерные сети были построены на технологиях телекоммуникационных сетей, и поэтому протоколы, как правило, делились на две группы: те, которые предназначались для подключения локальных устройств к локальной сети (LAN), и те, которые предназначались в первую очередь для междугородной связи. Последние системы глобальной сети (WAN), как правило, имели централизованную настройку, когда сетевой администратор вручную назначал адреса и имена. Системы ЛВС, как правило, обеспечивали большую автоматизацию этих задач, так что новое оборудование можно было добавить в ЛВС с минимальным вмешательством оператора и администратора.

Ранним примером системы LAN с нулевой конфигурацией является AppleTalk , протокол, представленный Apple Inc. для первых компьютеров Macintosh в 1980-х годах. Mac, а также другие устройства, поддерживающие протокол, можно было добавить в сеть, просто подключив их; вся дальнейшая настройка была автоматизирована. Сетевые адреса автоматически выбирались каждым устройством с использованием протокола, известного как протокол разрешения адресов AppleTalk (AARP), в то время как каждая машина создавала свою собственную локальную службу каталогов с использованием протокола, известного как протокол привязки имен (NBP). NBP включал не только имя, но и тип устройства, а также любую дополнительную информацию, предоставленную пользователем, такую как его физическое местонахождение или доступность. Пользователи могут искать любое устройство в сети с помощью приложения Chooser , которое фильтрует имена в зависимости от типа устройства.

В сетях Интернет-протокола (IP) база данных системы доменных имен для сети изначально поддерживалась администратором сети вручную. Усилия по автоматизации обслуживания этой базы данных привели к внедрению ряда новых протоколов, обеспечивающих автоматизированные услуги, таких как протокол динамической конфигурации хоста (DHCP).

Основные реализации

Apple Bonjour

Bonjour от Apple использует mDNS и DNS Service Discovery. Apple изменила свою предпочтительную технологию zeroconf с SLP на mDNS и DNS-SD между Mac OS X 10.1 и 10.2 , хотя SLP по-прежнему поддерживается Mac OS X.

MDNSResponder от Apple имеет интерфейсы для C и Java и доступен в BSD, Apple Mac OS X, Linux, других операционных системах на базе POSIX и MS Windows. Загрузки для Windows доступны на веб-сайте Apple.

Авахи

Avahi - это реализация Zeroconf для Linux и BSD . Он реализует IPv4LL , mDNS и DNS-SD. Он входит в состав большинства дистрибутивов Linux и в некоторых устанавливается по умолчанию. Если запускается вместе с nss-mdns, он также предлагает разрешение имени хоста.

Avahi также реализует библиотеки двоичной совместимости, которые имитируют Bonjour и историческую реализацию mDNS Howl, поэтому программное обеспечение, созданное для использования этих реализаций, также может использовать Avahi через интерфейсы эмуляции.

MS Windows CE 5.0

Microsoft Windows CE 5.0 включает собственную реализацию LLMNR от Microsoft .

Systemd

Systemd реализует как mDNS, так и LLMNR в systemd-resolved .

Link-локальные IPv4-адреса

Если DHCP-сервер недоступен для назначения хосту IP-адреса, хост может выбрать свой собственный локальный адрес канала . Таким образом, хосты могут общаться по этой ссылке, но только локально. Доступны несколько реализаций IPv4-адресов с локальной связью :

Apple Mac OS и MS Windows поддерживают адреса с локальными ссылками с 1998 года. Apple выпустила свою реализацию с открытым исходным кодом в пакете Darwin bootp.
Avahi содержит реализацию IPv4LL в инструменте avahi-autoipd.
IP без конфигурирования (zcip).
BusyBox может включать простую реализацию IPv4LL.
Stablebox, форк от Busybox, предлагает слегка измененную реализацию IPv4LL под названием llad.
Zeroconf, пакет, основанный на Simple IPv4LL, более короткая реализация Артура ван Хоффа .

Вышеупомянутые реализации представляют собой автономные демоны или плагины для DHCP- клиентов, которые работают только с локальными IP-адресами канала. Другой подход - включить поддержку в новых или существующих DHCP-клиентах:

Элвис Пфютценройтер написал патч для клиента / сервера uDHCP.
dhcpcd - это DHCP- клиент с открытым исходным кодом для Linux и BSD, который включает поддержку IPv4LL. Он входит в стандартную комплектацию NetBSD .

Гостевая статья Evil SSDP:спуфинг SSDP и UPnP устройств

Злой SSDP воспроизводит и создает поддельные устройства UPnP для фишинга учетных данных и запроса / ответа NetNTLM.

Вступление
- Что такое SSDP?
- Что такое устройства UPnP?
- Конфигурация шаблона
- Манипуляции пользователем
- Захват учетных данных
- Конфигурация шаблона
- Манипуляции пользователем
- Захват уетных данных
- Конфигурация шаблона
- Манипуляции пользователем
- Захват учетных данных
- Конфигурация шаблона
- Манипуляции пользователем
Что такое устройства UPnP?

UPnP или Universal Plug and Play - это набор сетевых протоколов, который позволяет сетевым устройствам, таким как персональные компьютеры, принтеры, интернет-шлюзы, точки доступа Wi-Fi и мобильные устройства, обнаруживать доступность друг друга в сети и устанавливать сетевые сервисы для связи, обмен данными и развлечения. Архитектура UPnP поддерживает работу в сети с нулевой конфигурацией. Совместимое с UPnP устройство любого поставщика может динамически подключаться к сети, получать IP-адрес, объявлять свое имя, передавать свои возможности по запросу, а также узнавать о наличии и возможностях других устройств.

Теперь, когда мы поняли основные функции SSDP или UPnP, давайте использовать его для манипулирования целевым пользователем с целью кражи его учетных данных.

Злой SSDP был разработан initstring . Этот инструмент размещен на GitHub. Мы будем использовать команду git clone для клонирования всего содержимого git на нашу атакующую машину. Команда git clone создаст каталог с тем же именем, что и на GitHub. Поскольку инструмент разработан в Python версии 3, для запуска программы нам потребуется использовать python3, за которым следует имя файла .py. Здесь мы можем увидеть основной экран справки инструмента.

В клонированном каталоге мы найдем каталог с именем templates. Он содержит все предварительно собранные шаблоны, которые можно использовать для фишинга целевого пользователя.

Спуфинг Сканер SSDP
Теперь, когда мы запустили инструмент, давайте использовать его для получения учетных данных. В этом первом практическом упражнении мы будем имитировать надежное устройство UPnP. Для начала нам нужно будет настроить шаблон.

Конфигурация шаблона

Чтобы использовать инструмент, нам нужно будет предоставить сетевой интерфейс. У нас есть «eth0» в качестве нашего интерфейса, вы можете найти свой интерфейс с помощью команды «ifconfig».

После предоставления интерфейса мы будем использовать параметр «–template» для передачи шаблона, который мы нашли ранее в каталоге шаблонов. Чтобы подделать сканер, мы запустим следующую команду. Как мы видим, инструмент выполнил свою работу и разместил несколько файлов шаблонов на нашей машине злоумышленника на порту 8888. У нас также есть указатель SMB.

Манипуляции пользователем

Следующий логический шаг - манипулировать пользователем. Находясь в той же сети, что и цель, наш фальшивый сканер отобразится в проводнике. Здесь работает UPnP. Средство Evil SSDP создает этот подлинно выглядящий сканер в системе на цели без какого-либо принудительного взаимодействия с целью.

После нажатия на значок внутри Проводника мы будем перенаправлены в веб-браузер по умолчанию, открывая нашу размещенную ссылку. Здесь используются шаблоны, которые мы использовали. Теперь пользователь знает, что он действительно подключен к подлинному сканеру или поддельному устройству UPnP, которое мы создали. Непонятная цель, не имеющая подсказки, вводит действительные учетные данные в этот шаблон, как показано на рисунке ниже.

Захват учетных данных

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

Подмена Office365 SSDP
В предыдущей практике мы подделали сканер для целевого пользователя. Теперь, просматривая каталог шаблонов, мы нашли шаблон Office365. Давайте использовать это.

Конфигурация шаблона

Как мы делали ранее, давайте начнем с настройки шаблона и инструмента. Затем предоставим сетевой интерфейс, за которым последует параметр шаблона с office365.

python3 evil-ssdp.py eth0 --template office365

Как мы видим, инструмент выполнил свою работу и разместил несколько файлов шаблонов на нашей машине атакующего в порту 8888.

Манипулирование пользователем

Как только мы запустим инструмент, у нас будет устройство UPnP с именем Office365 Backups. Это было сделано инструментом без необходимости отправлять какой-либо файл, полезную нагрузку или любой другой тип взаимодействия целевому пользователю. Осталось только нажать на иконку.

После нажатия пользователем целевой пользователь перенаправляется на нашу поддельную страницу шаблона через браузер по умолчанию. Это очень подлинно выглядящая веб-страница Microsoft. Невежественный пользователь вводит свои действительные учетные данные на этой странице.

Захват учетных данных

Как только пользователь вводит учетные данные, и они передаются в качестве почтового запроса на сервер, который является нашей целевой машиной, мы видим, что на нашем терминале у нас есть учетные данные.

Переадресация пользователя на хранилище паролей SSDP
До сих пор мы успешно обманывали целевого пользователя, чтобы получить некоторые учетные данные сканера и некоторые учетные данные резервного копирования Office365. Но теперь мы переходим к самой важной вещи, которая используется в качестве UPnP, The Password Vault.

Конфигурация шаблона

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

python3 evil-ssdp.py eth0 --template password-vault

Манипулирование пользователем

Переходя к целевой машине, мы видим, что хранилище паролей UPnP видно в проводнике. Теперь предположим, что пользователь нажимает на устройство и попадает в нашу атаку. Увидев что-то вроде Password Vault, пользователь будет испытывать желание нажать на значок.

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

Подмена Microsoft Azure SSDP
При работе со спуфингом одна из самых важных задач - не дать целевому пользователю понять, что он/она стал жертвой спуфинга. Это может быть достигнуто путем перенаправления пользователя после того, как мы получим учетные данные, файлы cookie или все, что хотел получить злоумышленник. У инструмента evil_ssdp есть параметр (-u), который перенаправляет целевого пользователя на любой URL по выбору злоумышленника. Давайте посмотрим на работу этого параметра в действии.

Манипулирование пользователем

Теперь, когда мы запустили инструмент, он создаст устройство UPnP на целевой машине, как показано на рисунке ниже. Чтобы атака была успешной, цель должна нажать на устройство.

После нажатия на значок мы видим, что пользователь перенаправлен на официальную страницу Microsoft. Это может быть тем, что хочет атакующий.

На этом мы завершаем практическое использование этого удивительного спуфингового инструмента.

Поломать UPnP

Решение

Universal Plug and Play (UPnP) — это набор сетевых протоколов, которые были созданы для упрощения взаимного нахождения различными девайсами, а также для их взаимодействия. Девайсом в данном случае может быть почти все что угодно: роутер, принтер, smartTV, какие-то сервисы Windows… И хотя, возможно, термин UPnP кажется тебе незнакомым, фактически он очень и очень распространен.

Но если посмотреть на это с нашей хакерской точки зрения, то здесь есть чем поживиться… UPnP как технология появился еще в начале 2000-х и, возможно, потому имеет приличный ряд огрехов с точки зрения безопасности. Отсутствие аутентификации, например. Но давай обо всем по порядку.

UPnP основывается на нескольких протоколах, а также, что важнее, на определенной логической последовательности:

SSDP NOTIFY моего вай-фай-роутера

Кроме прослушки 239.255.255.250, мы «насильно» можем посылать M-SEARCH запросы на тот же 1900-й порт. UPnP-серверы должны будут ответить на данный запрос. Отвечают все тем же Notify-пакетом.

Итак, первая задача — это, по сути, получение списка UPnP-серверов, а также URL’ов до XML’ек, с полным описанием функциональных возможностей каждого из сервисов сервера. Это важно, так как и порт, и URL’ы могут быть различными у разных производителей.

Аутентификация, как я уже говорил, отсутствует, и сервер выполнит все действия, которые ему придут в SOAP-запросе.

А вот и SOAP-команда на проброс портов

В 2008 году GNUCitizen даже выложили специальную SWF’ку. Эта SWF’ка (Flash) посылала SOAP-запрос на роутер (его IP необходимо указать), чтобы тот прокинул произвольный внешний порт на порт хоста юзера-жертвы. И получается, что, как только юзер-жертва открывал сайт с данной SWF, флеш «пропиливал» дырку в роутере до юзера и мы могли его атаковать. Очень удобно!

К сожалению, данный способ больше не работает: с тех пор ужесточилась песочница Flash’а и мы уже не можем посылать произвольные POST-запросы (самое главное, нам надо добавить еще заголовок SOAPAction) на любой другой хост (так как сначала произойдет запрос на разрешающие правила в crossdomain.xml).

Итак, теперь, я думаю, мы видим, как это все работает. Давай еще посмотрим, что можно с этим сделать.

Во-первых, это прошитые возможности SOAP’а. Кроме примера с пробросом портов, есть случаи, когда мы можем сменить настройки роутера и выставить свой DNS-сервер. А это уже ого-го! Тут все зависит от конкретного устройства, сервисов и нашей фантазии.

В-третьих, мы можем поломать сами сервисы. Год назад Rapid7 сделали прикольнейшее исследование UPnP. Они просканили интернет на SSDP и на SOAP (на стандартных портах), пофингерпринтили их. Оказалось, что большинство UPnP-серверов построено на четырех SDK. Из них выделяются MiniUPnP и Portable UPnP (libupnp), на которых «держится» больше половины. Но что важнее, почти все серверы используют устаревшие версии библиотек, в каждой из которых есть пучок уязвимостей, в том числе приводящих к RCE. Причем и в SOAP’е, и в SSDP.

Кроме того, в этом исследовании показано, как на самом деле много таких устройств торчит наружу, хотя бы SSDP. То есть даже если тот же SOAP закрыт, мы можем захватить удаленный контроль над устройством через SSDP.

Конечно, здесь надо отметить, что с удаленным сплоитингом может быть не очень просто, так как устройства эти часто построены на всяких MIPS, ARM, что точно все затрудняет. К тому же придется бороться еще и с механизмами защиты памяти ОС (тот же ASLR). Но все-таки это возможно.

Что же нам надо, чтобы все поломать?

Тулз на деле немного. В метасплоите есть модуль для поиска UPnP (и детекта CVE по ним). Плюс есть два «комбайна», позволяющих выполнять SOAP-команды. Это Miranda и Umap. Оба написаны на Python’е, только под *nix и при этом не очень хорошо работают.

Надеюсь, прочтенное наполнило тебя энтузиазмом и жаждой жизни, так что если есть желание поресерчить — пиши на ящик. Всегда рад :). И успешных познаний нового!

Проблемы с безопасностью

Поскольку mDNS работает в рамках другой модели доверия, чем одноадресный DNS - доверяя всей сети, а не назначенному DNS-серверу, он уязвим для атак с подделкой со стороны любой системы в том же широковещательном домене . Подобно SNMP и многим другим протоколам управления сетью, он также может использоваться злоумышленниками для быстрого получения подробных сведений о сети и ее машинах. Из-за этого приложения должны по-прежнему аутентифицировать и шифровать трафик к удаленным хостам (например, через RSA , SSH и т. Д.) После обнаружения и разрешения их через DNS-SD / mDNS. LLMNR страдает аналогичными уязвимостями.

Получить список доменов

Решение

Продолжим сбор информации. Давай представим себе компанию, которую мы хотим поломать снаружи. Одна из первых задач для пентеста через интернет — получить список доменных имен / виртуальных хостов. Методов много, и они стары как мир: обратный резолв IP, перебор имен, гуглохакинг. И ни один из них не дает полного результата, так что попробуем использовать их все вместе, попутно добавив чего-нибудь новенького :).

«Новенькое» — это сбор информации об именах с помощью SSL. Итак, давай вспомним основу. При подключении по SSL к любому серверу он возвращает нам свой сертификат. Сертификат — это набор полей (в том числе и открытый ключ сервера), подписанный корневым центром сертификации. В нем также есть поле CN (Common Name), где содержится имя сервера, на который выдан данный сертификат. Это уже что-то.

Но это еще не все. Есть еще одно малоизвестно поле того же сертификата — SubjectAltName‎. Оно позволяет задавать альтернативные имена. То есть фактически один ключик может быть использован для совсем разных имен. Смотри рисуночки, и все станет ясно.

Собираем имена хостов из SSL

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

Простой протокол обнаружения сервисов - Simple Service Discovery Protocol

Simple Service Discovery Protocol ( SSDP ) представляет собой сетевой протокол на основе набора протоколов Интернет для рекламы и обнаружения сетевых сервисов и информации о присутствии. Это достигается без помощи механизмов конфигурации на основе сервера, таких как протокол динамической конфигурации хоста (DHCP) или система доменных имен (DNS), и без специальной статической конфигурации сетевого хоста. SSDP является основой протокола обнаружения Universal Plug and Play (UPnP) и предназначен для использования в жилых или небольших офисных средах. Она была официально описана в Engineering Task Force Интернет (IETF) Internet Draft по Microsoft и Hewlett-Packard в 1999 году Хотя предложение IETF с тех пор истекли (апрель, 2000), SSDP был включен в стек протокола UPnP, а также описание окончательная реализация включена в документы стандартов UPnP.

WARNING
Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.

Так работает почта

Но самое важное, что фактически письмо проходит больше чем через один MTA и каждый из них добавляет ряд своих заголовков. Причем здесь все очень и очень «разговорчивы». Например, если письмо приходит из какой-то корпоративной сети к нам на почту, то мы, скорее всего, увидим в заголовках IP-адрес оправившего его пользователя (то есть того, кто подключился к внутреннему MTA в корпоративной сети) и версию используемого почтового клиента. Далее мы увидим данные уже самого MTA: IP-адрес (или имя в корпоративном домене), версию серверного ПО. А после этого очень часто — аналогичную запись, но уже по другому сетевому интерфейсу MTA.

Как же посмотреть эти заголовки? Очень просто. Все почтовые клиенты поддерживают их. Например, в Thunderbird — <Ctrl + U>. В Gmail — стрелка «Еще» — показать оригинал. При анализе заголовков Received (то есть списке участвовавших в пересылке письма) нужно помнить, что они идут в обратном порядке. А для упрощения парсинга их рекомендую воспользоваться каким-нибудь онлайн-сервисом (которых немало), например E-Mail Header Analyzer.

Итог. Отправляем одно письмо секретарше в какую-то компанию, та нам отвечает. И мы уже знаем, что да как у них там :).

Посмотрим, что мы можем узнать из спама ВТБ24

Атаковать с использованием техники session puzzling

Решение

Логические уязвимости — это всегда весело. Они бывают простыми и сложными, но их объединяет одно — необходимость правильно подумать. Вот только есть с ними и небольшая проблема: их как-то не особо типизируют (возможно, как раз-таки потому, что они все такие разнообразные :)). Ну да ладно. Хочу рассказать тебе об интересной технике (или виде уязвимостей, это уж как посмотреть), которую презентовали относительно недавно, пару лет назад. Название ей — session puzzling или session variable overloading (по версии OWASP).

Все выглядит вполне четко, но здесь пропущен важный момент. Он состоит в том, что сервер хранит у себя информацию о сессии конкретного пользователя. То есть приходит кука от юзера, он берет ее и смотрит (в памяти, в БД — в зависимости от ПО), а что же к ней у него «привязано». Простейший пример: он может хранить имя пользователя в сессии. И по куке получать из сессии имя и точно знать, кто к нему обратился в данный момент.

Вообще, в сессии хранят обычно «временную» информацию, а что-то более-менее постоянное — уже в БД. Например, логично хранить имя юзера в сессии, а вот его «роль» можно хранить в БД и запрашивать только по необходимости. Здесь, на самом деле, многое зависит от конкретного приложения и разработчика ПО.

Например, хранение большого объема данных в сессии может привести к исчерпанию либо памяти веб-сервера (Tomcat), либо свободного места на жестком диске (PHP). С другой стороны, обращения в БД требуют больше времени. Обусловлен выбор обычно производительностью, и о безопасности здесь редко думают (конечно, ведь как можно повлиять на то, что хранится на серверной стороне?).

И вот мы подошли к самой сути данной атаки: в определенных ситуациях мы можем влиять на то, что хранится на сервере. В каких конкретно — это тоже зависит от ситуации. Чаще всего нам нужны несколько различных точек входа в приложения, данные из которых попадают в одну и ту же переменную сессии.

Я приведу классический пример, и все будет ясно. Та же ситуация, что описана выше. Клиент, который может входить в приватную зону на сайте через страницу логина. Сайт, который хранит имя клиента в сессии, а доступ к приватным страницам проверяет по имени пользователя из сессии.

Но добавим к этому страницу с восстановлением пароля, на которой ты должен ввести свое имя (1), а система в ответ задаст секретный вопрос (2), на который ты должен будешь ввести правильный ответ для сброса пароля (3). И, как ты вероятно уже понял, для того чтобы провести по этой последовательности тебя (от 1 до 3), сервер должен также воспользоваться сессией и хранить в ней имя пользователя.

Так вот, атака будет заключаться в том, что, когда мы заходим на страницу восстановления и вводим имя пользователя администратора, сервер в сессии отмечает, что юзер — админ, и выводит для админа секретный вопрос. Все! Мы можем ничего не вводить, а просто перейти на приватный раздел сайта. Сервер посмотрит сессию, увидит, что имя пользователя админа, и даст нам доступ. То есть во время восстановления пароля мы «поставили» необходимое нам значение и дальше пошли бороздить приватные части. Бага здесь и в том, что сайт использует одно имя переменной и при аутентификации, и при восстановлении пароля.

Сначала может показаться, что данный тип уязвимости — редкость. На самом деле это не так. Я лично находил такие в достаточно распространенных продуктах. Вот только не знал тогда, что это так называется.

Кстати, кроме обхода аутентификации, использовать данную технику можно для повышения привилегий или перескока шагов на многошаговых операциях…

Как искать такого типа баги? Фактически какой-то суперметодики для этого нет. Но в качестве начала необходимо выискать входные точки в приложение, имеющие потенциальную возможность влиять на значения в сессионных переменных. А дальше — мозг, руки и тесты, тесты, тесты.

Если заинтересовался или хочешь попробовать на специальном уязвимом приложении — прошу к авторам изначального ресерча.

Транспортный протокол и адресация

Это приводит к следующим хорошо известным практическим групповым адресам для SSDP:
- 239.255.255.250 (локальный адрес сайта IPv4)
- [FF02 :: C] ( локальный канал IPv6 )
- [FF05 :: C] (IPv6 локально для сайта)
- [FF08 :: C] (локальная организация IPv6)
- [FF0E :: C] (глобальный IPv6)
Кроме того, приложения могут использовать зависящие от источника адреса многоадресной рассылки, полученные из локального префикса маршрутизации IPv6, с идентификатором группы C (десятичное число 12).

Реализации Microsoft IPv6 SSDP в проигрывателе и сервере Windows Media используют адрес локальной области связи. Microsoft использует номер порта 2869 для уведомлений о событиях и подписок на события. Однако ранние реализации SSDP также использовали порт 5000 для этой службы.

Обнаружение службы имен

Для поиска адреса с помощью DNS необходимо знать IP-адрес DNS-сервера. Обычно это достигается путем ввода адреса известного сервера в поле одного из устройств в сети. В ранних системах это обычно требовалось на каждом устройстве, но это было продвинуто на один уровень вверх в иерархии к серверам DHCP или широкополосным устройствам, таким как кабельные модемы, которые получают эту информацию от своего интернет-провайдера . Это снизило требования к администрированию на стороне пользователя и обеспечивает ключевой элемент доступа без настройки.

В 2000 году Билл Мэннинг и Билл Вудкок описали службу многоадресных доменных имен, которая породила реализации Apple и Microsoft. Обе реализации очень похожи. Multicast DNS (mDNS) от Apple опубликован как предложение по отслеживанию стандартов RFC 6762 , а Microsoft Link-local Multicast Name Resolution (LLMNR) опубликован как информационный RFC 4795 . LLMNR включен в каждую версию Windows, начиная с Windows Vista, и действует как параллельная альтернатива службе имен NetBIOS от Microsoft по IPv4 и как замена по IPv6, поскольку NetBIOS недоступен по IPv6. Реализация Apple доступна как служба Bonjour с 2002 года в Mac OS X v10.2. Реализация Bonjour (mDNSResponder) доступна по лицензии Apache 2 с открытым исходным кодом и включена в Android Jelly Bean и более поздние версии по той же лицензии.

Использование служб NetBIOS или LLMNR в Windows по существу является автоматическим, поскольку использование стандартных API-интерфейсов DNS-клиента приведет к использованию либо NetBIOS, либо LLMNR в зависимости от того, какое имя разрешается (является ли имя локальным или нет), сеть действующая конфигурация (например, действующие суффиксы DNS) и (в корпоративных сетях) действующие политики (независимо от того, отключены ли LLMNR или NetBIOS), хотя разработчики могут отказаться от использования этих служб для поиска отдельных адресов.

Протоколы mDNS и LLMNR имеют незначительные различия в подходе к разрешению имен. mDNS позволяет сетевому устройству выбрать имя домена в локальном пространстве имен DNS и объявить его, используя специальный IP-адрес многоадресной рассылки. Это вводит особую семантику для локального домена , что считается проблемой некоторыми членами IETF. Текущий проект LLMNR позволяет сетевому устройству выбирать любое доменное имя, что некоторыми членами IETF считается угрозой безопасности. mDNS совместим с DNS-SD, как описано в следующем разделе, а LLMNR - нет.

DDoS-атака

В 2014 году было обнаружено, что SSDP использовался в DDoS- атаках, известных как атака отражения SSDP с усилением . Многие устройства, включая некоторые домашние маршрутизаторы, имеют уязвимость в программном обеспечении UPnP, которая позволяет злоумышленнику получать ответы с порта с номером 1900 на адрес назначения по своему выбору. С помощью ботнета, состоящего из тысяч устройств, злоумышленники могут генерировать достаточную скорость передачи пакетов и занимать полосу пропускания для перенасыщения ссылок, вызывая отказ в обслуживании. Сетевая компания Cloudflare назвала эту атаку «глупо простым протоколом DDoS».

Читайте также: