Содержание статьи
Что такое mDNS?
Официальные сайты и способны скорее запутать, чем пролить свет на суть этих технологий. Поэтому — прежде чем погружаться в вопросы безопасности mDNS и DNS-SD — мы обсудим, почему вообще эти протоколы существуют и чем они на самом деле занимаются.
Оба протокола являются частью Zeroconf — пакета технологий, который помогает сетевым устройствам находить друг друга автоматически. Когда ты отправляешь документ на печать, а твой компьютер сам предлагает на выбор ближайшие принтеры, скорее всего, он использует именно Zeroconf. Протоколы связаны с DNS, так что здесь нужно хотя бы на базовом уровне понимать, как устроена система .
Обычно DNS работает «одноадресно» (unicast) — это значит, что каждый запрос отправляется на конкретный IP-адрес. Слово multicast (то есть «многоадресность») в mDNS означает, что запрос веерно рассылается всем девайсам широковещательного домена (broadcast domain). Сам по себе термин «» означает, грубо говоря, все сообщающиеся устройства второго уровня — например, компьютеры, соединенные сетевыми коммутаторами. Это важный момент, ведь запросы mDNS не проходят через роутеры — потому что роутеры уже устройства третьего уровня.
Разберемся на примере. Мой MacBook Pro имеет в системе mDNS имя MehBook.local. Выяснить это можно во вкладке «Общий доступ» (Sharing) системных настроек.
Чтобы вычислить IP макбука, мы можем использовать инструмент DNS-запросов вроде dig:
Вместо того чтобы посылать запрос DNS-серверу на порт 53, мы используем порт 5353 и специальный адрес 224.0.0.251 — собственно, мультикастомный. Этот конкретный адрес зарезервирован специально для mDNS. Когда на адрес 224.0.0.251 приходит запрос, все устройства сети получают копию этого запроса и могут на него ответить. В нашем примере мой макбук увидел запрос и вернул по нему свой собственный айпишник — 10.105.0.203.
IP моего макбука динамический, через какое-то время он поменяется — а вот mDNS-имя останется прежним! Так что мы можем взаимодействовать с доменными именами без запуска DNS-сервера. Сам понимаешь, чем это полезно в домашних и небольших офисных сетях.
Что такое DNS-SD?
В примере с mDNS мы выясняли айпишник устройства с уже известным именем. Но что, если ты хочешь связаться с девайсом, имя которого не знаешь, — например, с принтером? Эту проблему как раз и решает протокол обнаружения сервисов (Service Discovery). Он позволяет устройствам заявлять о конкретных сервисах, которые они предлагают, — так, чтобы можно было обнаружить их без централизованной настройки.
Начнем с вычисления принтеров:
Если ты хочешь запросить устройства с другими сервисами, то стоит свериться с их . Например, там есть любопытная служба RAOP — она же протокол Apple, известный как AirTunes. Давай-ка его вычислим:
На Linux тот же набор инструментов предлагает пакет Avahi (на Debian/Ubuntu он называется avahi-utils).
Теперь ты видишь, чем пакет Zeroconf интересен пентестерам: благодаря ему можно быстро найти целый список доступных устройств буквально за пару запросов. А Avahi еще и позволяет автоматизировать этот процесс. Например, вполне реально упаковать обнаружение сервисов и пробивание IP через mDNS в один шаг.
Использованная здесь команда — отличный способ пересчитать все устройства конкретного типа, однако Avahi способен на большее! Следующая команда вычисляет вообще все типы сервисов сразу.
И конечно, нельзя не упомянуть, что Nmap поддерживает вычисление устройств Zeroconf с помощью скрипта .
Немного об ограничениях
Окей, вычисление устройств — это прикольно и все такое, но есть ли здесь что поэксплуатировать? Мы нашли связку принтеров и Apple TV — и?..
Во-первых, держи в уме, что продукты для домашней и небольшой офисной сети, использующие Zeroconf, с высокой вероятностью имеют неправильные настройки и уязвимости. Один простой пример: если принтер аутентифицируется через LDAP-сервер, а у того стоит дефолтный пароль производителя, ты можешь захватить контроль над сервером, заставить принтер к нему обратиться и таким образом украсть LDAP-аттестат принтера. Этим способом можно довольно быстро угнать доменный аккаунт!
Во-вторых, в плане безопасности Zeroconf похож на : подразумевается, что локальная сеть — доверенная. Как мы уже убедились, Zeroconf не заботится о конфиденциальности: мы можем фоново прослушивать внутри сети все запросы типа DNS-SD. Аутентификации в Zeroconf тоже нет: любое устройство в сети может отозваться на запрос типа mDNS или DNS-SD. Следовательно, злоумышленник может, например, отвечать на запросы с опечатками в именах (реальный домен такое просто проигнорирует). А если запрос составлен корректно — попытаться обогнать ответ реального устройства и предложить службы, которых на самом деле не существует.
Если ты еще не знаком с , то самое время познакомиться: это фантастический инструмент для спуфинга (отравления кеша) локальных сетей. Кроме mDNS, он умеет отправлять NetBIOS и LLMNR, что делает его идеальным орудием пентеста.
Запускаю Responder на машине, с которой буду атаковать.
Responder ждет, пока какое-нибудь устройство в сети сделает запрос. Этот запрос я делаю с машины-жертвы: пытаюсь запросить айпишник своего макбука, но «случайно» опечатываюсь.
12:18:31.228 ...STARTING...
Timestamp A/R Flags if Hostname Address TTL
12:18:31.229 Add 2 5 MehBok.local. 10.105.0.2 120
Заметь: несмотря на опечатку в имени хоста, ответ я получаю. Логи Responder показывают, что это он ответил — и перенаправил жертву на атакующую машину.
[*] [MDNS] Poisoned answer sent to 10.105.0.203 for name MehBok.local
А если жертва отправляет реальное и корректно написанное имя? В таком случае Responder пытается обогнать запрошенное устройство и ответить на запрос раньше. Вот, например, я пробиваю имя моего принтера.
12:27:50.695 ...STARTING...
Timestamp Hostname Address TTL
12:27:50.696 brotherB85F3190.local. 10.105.0.3 240
12:27:51.916 brotherB85F3190.local. 10.105.0.2 120
Первый результат — ответ реального принтера. Второй, пришедший почти на 1,2 секунды позже, — отравленный ответ от Responder. Большинство клиентов принимают только первый ответ и игнорируют все последующие, так что в нашем конкретном случае Responder не преуспел.
Заключение
Вообще Zeroconf — отличная и доступная технология. Скорее всего, ты уже используешь ее дома или на работе, даже если не отдаешь себе в этом отчет. Ну а пентестеры могут использовать Zeroconf для тихого или даже фонового вычисления устройств. В то время как сканирование через Nmap генерит кучу трафика и очень характерных примет, вычисление через Zeroconf занимает совсем мало трафика и походит на нормальную сетевую активность. К тому же отравление mDNS с помощью Responder — куда более надежный способ реализовать атаку посредника, чем то же отравление ARP.
- Что такое mDNS?
- Что такое DNS-SD?
- Вычисляем устройства
- Немного об ограничениях
- Эксплуатация
- Заключение
Что такое mDNS?
Официальные сайты и способны скорее запутать, чем пролить свет на суть этих технологий. Поэтому — прежде чем погружаться в вопросы безопасности mDNS и DNS-SD — мы обсудим, почему вообще эти протоколы существуют и чем они на самом деле занимаются.
Оба протокола являются частью Zeroconf — пакета технологий, который помогает сетевым устройствам находить друг друга автоматически. Когда ты отправляешь документ на печать, а твой компьютер сам предлагает на выбор ближайшие принтеры, скорее всего, он использует именно Zeroconf. Протоколы связаны с DNS, так что здесь нужно хотя бы на базовом уровне понимать, как устроена система .
Обычно DNS работает «одноадресно» (unicast) — это значит, что каждый запрос отправляется на конкретный IP-адрес. Слово multicast (то есть «многоадресность») в mDNS означает, что запрос веерно рассылается всем девайсам широковещательного домена (broadcast domain). Сам по себе термин «» означает, грубо говоря, все сообщающиеся устройства второго уровня — например, компьютеры, соединенные сетевыми коммутаторами. Это важный момент, ведь запросы mDNS не проходят через роутеры — потому что роутеры уже устройства третьего уровня.
Разберемся на примере. Мой MacBook Pro имеет в системе mDNS имя MehBook.local. Выяснить это можно во вкладке «Общий доступ» (Sharing) системных настроек.
Чтобы вычислить IP макбука, мы можем использовать инструмент DNS-запросов вроде dig:
Обрати внимание, что имя заканчивается на .local — это домен верхнего уровня, зарезервированный специально под mDNS. Если ты видишь подобное имя — то, вероятно, сможешь вычислить айпишник, используя mDNS. Такие доменные имена называются именами локальной связи (link-local names), потому что увидеть их можно только внутри локальной сети.$ dig @224.0.0.251 -p 5353 +short MehBook.local
10.105.0.203
Вместо того чтобы посылать запрос DNS-серверу на порт 53, мы используем порт 5353 и специальный адрес 224.0.0.251 — собственно, мультикастомный. Этот конкретный адрес зарезервирован специально для mDNS. Когда на адрес 224.0.0.251 приходит запрос, все устройства сети получают копию этого запроса и могут на него ответить. В нашем примере мой макбук увидел запрос и вернул по нему свой собственный айпишник — 10.105.0.203.
IP моего макбука динамический, через какое-то время он поменяется — а вот mDNS-имя останется прежним! Так что мы можем взаимодействовать с доменными именами без запуска DNS-сервера. Сам понимаешь, чем это полезно в домашних и небольших офисных сетях.
Что такое DNS-SD?
В примере с mDNS мы выясняли айпишник устройства с уже известным именем. Но что, если ты хочешь связаться с девайсом, имя которого не знаешь, — например, с принтером? Эту проблему как раз и решает протокол обнаружения сервисов (Service Discovery). Он позволяет устройствам заявлять о конкретных сервисах, которые они предлагают, — так, чтобы можно было обнаружить их без централизованной настройки.
Начнем с вычисления принтеров:
Тут нам помогут те же мультикастомный DNS-адрес и порт, но на сей раз мы запрашиваем PTR-записи и используем специальное доменное имя _printer._tcp.local — оно как раз предназначено для распознавания принтеров. В ответ на этот запрос мой принтер Brother вернул свое локальное доменное имя.$ dig @224.0.0.251 -p 5353 -t ptr +short _printer._tcp.local
Brother\032DCP-L2540DW\032series._printer._tcp.local.
Если ты хочешь запросить устройства с другими сервисами, то стоит свериться с их . Например, там есть любопытная служба RAOP — она же протокол Apple, известный как AirTunes. Давай-ка его вычислим:
Запрос показывает устройство в моей сети, предлагающее сервис RAOP, — это Apple TV под названием «Гостиная» (Living Room). На самом деле в моей сети два Apple TV, но dig выводит только первый полученный ответ. К счастью, есть инструменты и получше. На macOS это команда dns-sd в программном модуле Rendezvous (Bonjour), эппловской реализации Zeroconf.$ dig @224.0.0.251 -p 5353 -t ptr +short _raop._tcp.local
C8D083XXXXXX\@Living\032Room._raop._tcp.local
Эта команда разошлет запрос и отобразит все полученные ответы (чтобы избавиться от них, нужно будет нажать Ctrl-C). Теперь мы видим оба моих Apple TV.$ dns-sd -B _raop._tcp
Browsing for _raop._tcp
DATE: ---Sun 16 Sep 2018---
10:02:18.236 ...STARTING...
Timestamp Domain Service Type Instance Name
10:02:18.237 local. _raop._tcp. D0D2B0XXXXXX@Bedroom
10:02:18.238 local. _raop._tcp. C8D083XXXXXX@Living Room
^C
На Linux тот же набор инструментов предлагает пакет Avahi (на Debian/Ubuntu он называется avahi-utils).
Avahi умеет переводить имена служб типа _raop._tcp.local в более понятные — AirTunes Remote Audio local, например. Также Avahi может вычислить айпишник с помощью mDNS, так что dig здесь вообще не нужен:$ avahi-browse _raop._tcp
+ IPv6 D0D2B0XXXXXX@Bedroom AirTunes Remote Audio local
+ IPv6 C8D083XXXXXX@Living Room AirTunes Remote Audio local
+ IPv4 D0D2B0XXXXXX@Bedroom AirTunes Remote Audio local
+ IPv4 C8D083XXXXXX@Living Room AirTunes Remote Audio local
^C
Вычисляем устройства$ avahi-resolve --name Bedroom.local
Bedroom.local 10.105.0.230
Теперь ты видишь, чем пакет Zeroconf интересен пентестерам: благодаря ему можно быстро найти целый список доступных устройств буквально за пару запросов. А Avahi еще и позволяет автоматизировать этот процесс. Например, вполне реально упаковать обнаружение сервисов и пробивание IP через mDNS в один шаг.
В результате мы получаем локальное имя хоста, IP-адрес и порт (tcp/515 — дефолтный порт для Line Printer Daemon). Плюс много информации о возможностях принтера в поле txt.$ avahi-browse --resolve _printer._tcp
+ enp4s0 IPv4 Brother DCP-L2540DW series UNIX Printer local
= enp4s0 IPv4 Brother DCP-L2540DW series UNIX Printer local
hostname = [brotherB85F3190.local]
address = [10.105.0.3]
port = [515]
txt = ["UUID=e3248000-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
"TBCP=F" "Transparent=T" "Binary=T" "PaperCustom=T"
"Scan=T" "Fax=F" "Duplex=T" "Copies=T" "Color=F" …]
^C
Использованная здесь команда — отличный способ пересчитать все устройства конкретного типа, однако Avahi способен на большее! Следующая команда вычисляет вообще все типы сервисов сразу.
Наконец, Avahi может слушать запросы по протоколам Zeroconf от других устройств, что позволяет вычислять девайсы фоново.$ avahi-browse --all
+ IPv6 8FB20F14F5966F78620XXXX iPod Touch Music Library local
+ IPv6 276A1455BC533567B08XXXX iPod Touch Music Library local
+ IPv4 8FB20F14F5966F78620XXXX iPod Touch Music Library local
+ IPv4 276A1455BC533567B08XXXX iPod Touch Music Library local
+ IPv6 8FB20F14F5966F78620XXXX _appletv-v2._tcp local
+ IPv6 276A1455BC533567B08XXXX _appletv-v2._tcp local
+ IPv4 8FB20F14F5966F78620XXXX _appletv-v2._tcp local
+ IPv4 276A1455BC533567B08XXXX _appletv-v2._tcp local
^C
Обе эти команды можно сочетать с --resolve, чтобы получить информацию об айпишниках и портах каждого девайса. Все устройства сети как на ладони!$ avahi-browse -a
+ IPv6 MehBook _companion-link._tcp local
+ IPv6 Bedroom _companion-link._tcp local
+ IPv6 Living Room _companion-link._tcp local
+ IPv4 MehBook _companion-link._tcp local
^C
И конечно, нельзя не упомянуть, что Nmap поддерживает вычисление устройств Zeroconf с помощью скрипта .
Этот скрипт не включен в категорию default — его можно найти только в safe.$ nmap --script=broadcast-dns-service-discovery
Starting Nmap 7.60 ( ) at 2018-09-18 11:40 EDT
Stats: 0:00:03 elapsed; 0 hosts completed (0 up)
NSE Timing: About 0.00% done
Pre-scan script results:
| broadcast-dns-service-discovery:
| 224.0.0.251
| 80/tcp privet
| txtvers=1
| ty=Brother DCP-L2540DW series [ACD1B8XXXXX]
| note=Brother DCP-L2540DW series
| url=
| type=printer
| id=10d70d78-XXXX-XXXX-XXXX-XXXXXXXXXXXX
| cs=online
| Address=10.105.0.3
…snip…
Немного об ограничениях
- Это работает только внутри локальной сети, так что нужно иметь к ней доступ.
- Большие корпоративные сети обычно сегментированы, поэтому потребуется опорная точка именно внутри интересующего тебя сегмента.
- Есть много важных служб, которые не заявляют о себе через DNS-SD, — такие устройства в большинстве случаев придется вычислять как-то иначе.
- Из-за того, что это широковещательные протоколы, нужно хорошенько подумать — позволяют ли твоя тактика и стратегия их использовать?
Окей, вычисление устройств — это прикольно и все такое, но есть ли здесь что поэксплуатировать? Мы нашли связку принтеров и Apple TV — и?..
Во-первых, держи в уме, что продукты для домашней и небольшой офисной сети, использующие Zeroconf, с высокой вероятностью имеют неправильные настройки и уязвимости. Один простой пример: если принтер аутентифицируется через LDAP-сервер, а у того стоит дефолтный пароль производителя, ты можешь захватить контроль над сервером, заставить принтер к нему обратиться и таким образом украсть LDAP-аттестат принтера. Этим способом можно довольно быстро угнать доменный аккаунт!
Во-вторых, в плане безопасности Zeroconf похож на : подразумевается, что локальная сеть — доверенная. Как мы уже убедились, Zeroconf не заботится о конфиденциальности: мы можем фоново прослушивать внутри сети все запросы типа DNS-SD. Аутентификации в Zeroconf тоже нет: любое устройство в сети может отозваться на запрос типа mDNS или DNS-SD. Следовательно, злоумышленник может, например, отвечать на запросы с опечатками в именах (реальный домен такое просто проигнорирует). А если запрос составлен корректно — попытаться обогнать ответ реального устройства и предложить службы, которых на самом деле не существует.
Если ты еще не знаком с , то самое время познакомиться: это фантастический инструмент для спуфинга (отравления кеша) локальных сетей. Кроме mDNS, он умеет отправлять NetBIOS и LLMNR, что делает его идеальным орудием пентеста.
Запускаю Responder на машине, с которой буду атаковать.
Responder ждет, пока какое-нибудь устройство в сети сделает запрос. Этот запрос я делаю с машины-жертвы: пытаюсь запросить айпишник своего макбука, но «случайно» опечатываюсь.
DATE: ---Tue 18 Sep 2018---~ $ dns-sd -G v4 MehBok.local
12:18:31.228 ...STARTING...
Timestamp A/R Flags if Hostname Address TTL
12:18:31.229 Add 2 5 MehBok.local. 10.105.0.2 120
Заметь: несмотря на опечатку в имени хоста, ответ я получаю. Логи Responder показывают, что это он ответил — и перенаправил жертву на атакующую машину.
[*] [MDNS] Poisoned answer sent to 10.105.0.203 for name MehBok.local
А если жертва отправляет реальное и корректно написанное имя? В таком случае Responder пытается обогнать запрошенное устройство и ответить на запрос раньше. Вот, например, я пробиваю имя моего принтера.
DATE: ---Tue 18 Sep 2018---~ $ dns-sd -G v4 brotherB85F3190.local
12:27:50.695 ...STARTING...
Timestamp Hostname Address TTL
12:27:50.696 brotherB85F3190.local. 10.105.0.3 240
12:27:51.916 brotherB85F3190.local. 10.105.0.2 120
Первый результат — ответ реального принтера. Второй, пришедший почти на 1,2 секунды позже, — отравленный ответ от Responder. Большинство клиентов принимают только первый ответ и игнорируют все последующие, так что в нашем конкретном случае Responder не преуспел.
Заключение
Вообще Zeroconf — отличная и доступная технология. Скорее всего, ты уже используешь ее дома или на работе, даже если не отдаешь себе в этом отчет. Ну а пентестеры могут использовать Zeroconf для тихого или даже фонового вычисления устройств. В то время как сканирование через Nmap генерит кучу трафика и очень характерных примет, вычисление через Zeroconf занимает совсем мало трафика и походит на нормальную сетевую активность. К тому же отравление mDNS с помощью Responder — куда более надежный способ реализовать атаку посредника, чем то же отравление ARP.