Multicast DNS (mDNS) и Service Discovery (DNS-SD) — это повсеместно распространенные протоколы, их сейчас по дефолту включают во многие технические продукты, особенно предназначенные для дома или маленькой офисной сети. В этой статье я разберу, что пентестеру следует знать о mDNS и DNS-SD и как можно использовать эти технологии для собственных целей.
Что такое mDNS?
Официальные сайты Multicast DNS и DNS Service Discovery способны скорее запутать, чем пролить свет на суть этих технологий. Поэтому — прежде чем погружаться в вопросы безопасности mDNS и DNS-SD, — мы обсудим, почему вообще эти протоколы существуют и чем они на самом деле занимаются.
Оба протокола являются частью Zeroconf — пакета технологий, который помогает сетевым устройствам находить друг друга автоматически. Когда ты отправляешь документ на печать, а твой компьютер сам предлагает на выбор ближайшие принтеры — скорее всего, он использует именно Zeroconf. Протоколы связаны с DNS, так что здесь нужно хотя бы на базовом уровне понимать, как устроена система DNS.
Обычно DNS работает «одноадресно» (unicast) — это значит, что каждый запрос отправляется на конкретный IP-адрес. Слово multicast (то есть «многоадресность») в mDNS означает, что запрос веерно рассылается всем девайсам широковещательного домена (broadcast domain). Сам по себе термин «широковещательный домен» означает, грубо говоря, все сообщающиеся устройства второго уровня — например, компьютеры, соединенные сетевыми коммутаторами. Это важный момент, ведь запросы mDNS не проходят через роутеры — потому что роутеры уже устройства третьего уровня.
Разберемся на примере. Мой MacBook Pro имеет в системе mDNS имя MehBook.local. Выяснить это можно во вкладке «Общий доступ» (Sharing) системных настроек.
Чтобы вычислить IP макбука, мы можем использовать инструмент DNS-запросов вроде
Обрати внимание, что имя заканчивается на .local — это домен верхнего уровня, зарезервированный специально под mDNS. Если ты видишь подобное имя — то, вероятно, сможешь вычислить айпишник, используя mDNS. Такие доменные имена называются именами локальной связи (link-local names), потому что увидеть их можно только внутри локальной сети.
Имей в виду: некоторые сисадмины некорректно используют местный домен верхнего уровня вместе с одноадресным DNS. Следи за собой, будь осторожен!
Вместо того чтобы посылать запрос 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-адрес и порт, но на сей раз мы запрашиваем PRT-записи и используем специальное доменное имя _printer._tcp.local — оно как раз предназначено для распознавания принтеров. В ответ на этот запрос мой принтер Brother вернул свое локальное доменное имя.
Если ты хочешь запросить устройства с другими сервисами, то стоит свериться с их официальным реестром. Например, там есть любопытная служба RAOP — она же протокол Apple, известный как AirTunes. Давай-ка его вычислим:
Запрос показывает устройство в моей сети, предлагающее сервис RAOP, — это Apple TV под названием «Гостиная» (Living Room). На самом деле в моей сети два Apple TV, но dig выводит только первый полученный ответ. К счастью, есть инструменты и получше. На macOS это команда dns-sd в программном модуле Rendezvous (Bonjour), эппловской реализации Zeroconf.
Эта команда разошлет запрос и отобразит все полученные ответы (чтобы избавиться от них, нужно будет нажать Ctrl-C). Теперь мы видим оба моих Apple TV.
На Linux тот же набор инструментов предлагает пакет Avahi (на Debian/Ubuntu он называется avahi-utils).
Avahi умеет переводить имена служб типа _raop._tcp.local в более понятные — AirTunes Remote Audio local, например. Также Avahi может вычислить айпишник с помощью mDNS, так что dig здесь вообще не нужен:
Обрати внимание, что при mDNS-запросе мы не вставляем значения типа
Вычисляем устройства
Теперь ты видишь, чем пакет Zeroconf интересен пентестерам: благодаря ему можно быстро найти целый список доступных устройств буквально за пару запросов. А Avahi еще и позволяет автоматизировать этот процесс. Например, вполне реально упаковать обнаружение сервисов и пробивание IP через mDNS в один шаг.
В результате мы получаем локальное имя хоста, IP-адрес и порт (tcp/515 — дефолтный порт для Line Printer Daemon). Плюс много информации о возможностях принтера в поле txt.
Использованная здесь команда — отличный способ пересчитать все устройства конкретного типа, однако Avahi способен на большее! Следующая команда вычисляет вообще все типы сервисов за раз.
Наконец, Avahi может слушать запросы по протоколам Zeroconf от других устройств, что позволяет вычислять девайсы фоново.
Обе эти команды можно сочетать с --resolve, чтобы получить информацию об айпишниках и портах каждого девайса. Все устройства сети как на ладони!
И, конечно, нельзя не упомянуть, что nmap поддерживает вычисление устройств Zeroconf с помощью скрипта broadcast-dns-service-discovery.
Этот скрипт не включен в категорию default — его можно найти только в safe.
Немного об ограничениях
Эксплуатация
Окей, вычисление устройств — это прикольно и все такое, но есть ли здесь что поэксплуатировать? Мы нашли связку принтеров и Apple TV — и..?
Во-первых, держи в уме, что продукты для домашней и небольшой офисной сети, использующие Zeroconf, с высокой вероятностью имеют неправильные настройки и уязвимости. Один простой пример: если принтер аутентифицируется через LDAP-сервер, а у того стоит дефолтный пароль производителя, ты можешь захватить контроль над сервером, заставить принтер к нему обратиться и таким образом украсть LDAP-аттестат принтера. Этим способом можно довольно быстро угнать доменный аккаунт!
Об угоне принтера с помощью LDAP-сервера есть отличный пост на GrimBlog.
Во-вторых, в плане безопасности Zeroconf похож на ARP: подразумевается, что локальная сеть — доверенная. Как мы уже убедились, Zeroconf не заботится о конфиденциальности: мы можем фоново прослушивать внутри сети все запросы типа DNS-SD. Аутентификации в Zeroconf тоже нет: любое устройство в сети может ответить на запрос типа mDNS или DNS-SD. Следовательно, злоумышленник может, например, отвечать на запросы с опечатками в именах (реальный домен на такое просто не ответит). А если запрос составлен корректно, он может попытаться обогнать ответ реального устройства — и предложить службы, которых на самом деле не существует.
Если ты еще не знаком с Responder, то самое время познакомиться: это фантастический инструмент для спуфинга (отравления кеша) локальных сетей. Кроме mDNS он поддерживает отравление NetBIOS и LLMNR, что делает его идеальным орудием пентеста.
Мы сейчас рассмотрим небольшой пример с использованием Responder, но если тебе нужно больше деталей, советую пост на 4ARMED.
Запускаю Responder на машине, с которой буду атаковать.
Responder ждет, пока какое-нибудь устройство в сети сделает запрос. Этот запрос я делаю с машины-жертвы: пытаюсь запросить айпишник своего макбука, но «случайно» опечатываюсь.
Заметь: несмотря на опечатку в имени хоста, ответ я получаю. Логи Responder показывают, что это он ответил — и перенаправил жертву на атакующую машину.
А если жертва отправляет реальное и корректно написанное имя? В таком случае Responder пытается обогнать запрошенное устройство и ответить на запрос раньше. Вот, например, я пробиваю имя моего принтера.
Первый результат — ответ реального принтера. Второй, пришедший почти на 1,2 секунды позже, — отравленный ответ от Responder. Большинство клиентов принимают только первый ответ и игнорируют все последующие, так что в нашем конкретном случае Responder не преуспел.
Заключение
Вообще Zeroconf — отличная и доступная технология. Скорее всего, ты уже используешь ее дома или на работе, даже если не отдаешь себе в этом отчет. Ну а пентестеры могут использовать Zeroconf для тихого или даже фонового вычисления устройств. В то время как сканирование через nmap генерит кучу трафика и очень характерных примет, вычисление через Zeroconf занимает совсем мало трафика и походит на нормальную сетевую активность. К тому же отравление mDNS с помощью Responder — куда более надежный способ реализовать атаку посредника, чем то же отравление ARP.
Статья Марка Э. Хааса, впервые опубликованной в блоге Hyperion Gray
Перевела Алёна Георгиева
Что такое mDNS?
Официальные сайты Multicast DNS и DNS Service Discovery способны скорее запутать, чем пролить свет на суть этих технологий. Поэтому — прежде чем погружаться в вопросы безопасности mDNS и DNS-SD, — мы обсудим, почему вообще эти протоколы существуют и чем они на самом деле занимаются.
Оба протокола являются частью Zeroconf — пакета технологий, который помогает сетевым устройствам находить друг друга автоматически. Когда ты отправляешь документ на печать, а твой компьютер сам предлагает на выбор ближайшие принтеры — скорее всего, он использует именно Zeroconf. Протоколы связаны с DNS, так что здесь нужно хотя бы на базовом уровне понимать, как устроена система DNS.
Обычно DNS работает «одноадресно» (unicast) — это значит, что каждый запрос отправляется на конкретный IP-адрес. Слово multicast (то есть «многоадресность») в mDNS означает, что запрос веерно рассылается всем девайсам широковещательного домена (broadcast domain). Сам по себе термин «широковещательный домен» означает, грубо говоря, все сообщающиеся устройства второго уровня — например, компьютеры, соединенные сетевыми коммутаторами. Это важный момент, ведь запросы mDNS не проходят через роутеры — потому что роутеры уже устройства третьего уровня.
Разберемся на примере. Мой MacBook Pro имеет в системе mDNS имя MehBook.local. Выяснить это можно во вкладке «Общий доступ» (Sharing) системных настроек.
Чтобы вычислить IP макбука, мы можем использовать инструмент DNS-запросов вроде
dig:
Код:
$ dig @224.0.0.251 -p 5353 +short MehBook.local
10.105.0.203Имей в виду: некоторые сисадмины некорректно используют местный домен верхнего уровня вместе с одноадресным DNS. Следи за собой, будь осторожен!
Вместо того чтобы посылать запрос DNS-серверу на порт 53, мы используем порт 5353 и специальный адрес 224.0.0.251 — собственно, мультикастомный. Этот конкретный адрес зарезервирован специально для mDNS. Когда на адрес 224.0.0.251 приходит запрос, все устройства сети получают копию этого запроса и могут на него ответить. В нашем примере мой макбук увидел запрос и вернул по нему свой собственный айпишник — 10.105.0.203.
IP моего макбука динамический, через какое-то время он поменяется — а вот mDNS-имя останется прежним! Так что мы можем взаимодействовать с доменными именами без запуска DNS-сервера. Сам понимаешь, чем это полезно в домашних и небольших офисных сетях.
Что такое DNS-SD?
В примере с mDNS мы выясняли айпишник устройства с уже известным именем. Но что если ты хочешь связаться с девайсом, имя которого не знаешь — например, с принтером? Эту проблему как раз и решает протокол обнаружения сервисов (Service Discovery). Он позволяет устройствам заявлять о конкретных сервисах, которые они предлагают, — так, чтобы можно было обнаружить их без централизованной настройки.
Начнем с вычисления принтеров:
Код:
$ dig @224.0.0.251 -p 5353 -t ptr +short _printer._tcp.local
Brother\032DCP-L2540DW\032series._printer._tcp.local.Если ты хочешь запросить устройства с другими сервисами, то стоит свериться с их официальным реестром. Например, там есть любопытная служба RAOP — она же протокол Apple, известный как AirTunes. Давай-ка его вычислим:
Код:
$ dig @224.0.0.251 -p 5353 -t ptr +short _raop._tcp.local
C8D083XXXXXX\@Living\032Room._raop._tcp.local
Код:
$ 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-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_raop._tcp — потому что это название службы, а не устройства. Также мы ничего не пишем слева от символа @.Вычисляем устройства
Теперь ты видишь, чем пакет Zeroconf интересен пентестерам: благодаря ему можно быстро найти целый список доступных устройств буквально за пару запросов. А Avahi еще и позволяет автоматизировать этот процесс. Например, вполне реально упаковать обнаружение сервисов и пробивание IP через mDNS в один шаг.
Код:
$ 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-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
Код:
$ 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 с помощью скрипта broadcast-dns-service-discovery.
Код:
$ nmap --script=broadcast-dns-service-discovery
Starting Nmap 7.60 ( https://nmap.org ) 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=https://www.google.com/cloudprint
| type=printer
| id=10d70d78-XXXX-XXXX-XXXX-XXXXXXXXXXXX
| cs=online
| Address=10.105.0.3
…snip…Немного об ограничениях
- Это работает только внутри локальной сети, так что нужно иметь к ней доступ.
- Большие корпоративные сети обычно сегментированы, поэтому потребуется опорная точка именно внутри интересующего тебя сегмента.
- Есть много важных служб, которые не заявляют о себе через DNS-SD — такие устройства в большинстве случаев придется вычислять как-то иначе.
- Из-за того, что это широковещательные протоколы, нужно хорошенько подумать — позволяют ли твоя тактика и стратегия их использовать?
Эксплуатация
Окей, вычисление устройств — это прикольно и все такое, но есть ли здесь что поэксплуатировать? Мы нашли связку принтеров и Apple TV — и..?
Во-первых, держи в уме, что продукты для домашней и небольшой офисной сети, использующие Zeroconf, с высокой вероятностью имеют неправильные настройки и уязвимости. Один простой пример: если принтер аутентифицируется через LDAP-сервер, а у того стоит дефолтный пароль производителя, ты можешь захватить контроль над сервером, заставить принтер к нему обратиться и таким образом украсть LDAP-аттестат принтера. Этим способом можно довольно быстро угнать доменный аккаунт!
Об угоне принтера с помощью LDAP-сервера есть отличный пост на GrimBlog.
Во-вторых, в плане безопасности Zeroconf похож на ARP: подразумевается, что локальная сеть — доверенная. Как мы уже убедились, Zeroconf не заботится о конфиденциальности: мы можем фоново прослушивать внутри сети все запросы типа DNS-SD. Аутентификации в Zeroconf тоже нет: любое устройство в сети может ответить на запрос типа mDNS или DNS-SD. Следовательно, злоумышленник может, например, отвечать на запросы с опечатками в именах (реальный домен на такое просто не ответит). А если запрос составлен корректно, он может попытаться обогнать ответ реального устройства — и предложить службы, которых на самом деле не существует.
Если ты еще не знаком с Responder, то самое время познакомиться: это фантастический инструмент для спуфинга (отравления кеша) локальных сетей. Кроме mDNS он поддерживает отравление NetBIOS и LLMNR, что делает его идеальным орудием пентеста.
Мы сейчас рассмотрим небольшой пример с использованием Responder, но если тебе нужно больше деталей, советую пост на 4ARMED.
Запускаю Responder на машине, с которой буду атаковать.
Responder ждет, пока какое-нибудь устройство в сети сделает запрос. Этот запрос я делаю с машины-жертвы: пытаюсь запросить айпишник своего макбука, но «случайно» опечатываюсь.
Код:
~ $ dns-sd -G v4 MehBok.local
DATE: ---Tue 18 Sep 2018---
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
Код:
[*] [MDNS] Poisoned answer sent to 10.105.0.203 for name MehBok.local
Код:
~ $ dns-sd -G v4 brotherB85F3190.local
DATE: ---Tue 18 Sep 2018---
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Заключение
Вообще Zeroconf — отличная и доступная технология. Скорее всего, ты уже используешь ее дома или на работе, даже если не отдаешь себе в этом отчет. Ну а пентестеры могут использовать Zeroconf для тихого или даже фонового вычисления устройств. В то время как сканирование через nmap генерит кучу трафика и очень характерных примет, вычисление через Zeroconf занимает совсем мало трафика и походит на нормальную сетевую активность. К тому же отравление mDNS с помощью Responder — куда более надежный способ реализовать атаку посредника, чем то же отравление ARP.
Статья Марка Э. Хааса, впервые опубликованной в блоге Hyperion Gray
Перевела Алёна Георгиева