Эксплуатация IPv6
для MITM атак
Селезнев Александр,
инженер отдела средств защиты информации
Бутузов Юрий,
руководитель отдела средств защиты информации
Введение

Разговоров о IPv6 и его использовании в корпоративных сетях вместо почти иссякшего IPv4 велось и ведется очень много. Согласно данным, представленным региональным регистратором RIPE Network Coordination Centre (RIPE NCC) в Восточной Европе и Средней Азии на ежегодной конференции ENOG 16 (ENOG – евразийская экспертная группа специалистов), доля IPv6 трафика в России – 3,45%, в то время как в прошлом году он составлял всего 1%.

На сегодняшний день мало кто считается с IPv6 протоколом и задумывается о реализации механизмов защиты на своём сетевом оборудовании. Но стоит отметить, что при наличии должного функционала, реализовать, скажем, одну из наиболее популярных MITM атак в существующей IPv4 сетевой инфраструктуре не представлятся такой уж и непреодолимой задачей.

В данной статье мы технически разберем подобный вектор атаки и, в ходе реализации, сделаем некоторые выводы об особенностях работы протокола IPv6 в различных ОС.
Немного теории

Перед тем, как описывать вектор атаки, разберем основные аспекты работы протокола IPv6.

Основным протоколом в IPv6 является Network Discovery Protocol (NDP), являющийся аналогом ARP в IPv4, который при помощи протокола ICMPv6 осуществляет свою работу. При помощи данного протокола узлы (хосты и маршрутизаторы) определяют linklayer (канального уровня) адреса соседних узлов. Также, хосты используют NDP для поиска соседствующих маршрутизаторов в пределах одного канала, которые готовы будут транслировать пакеты от их имени. В завершении отметим, что узлы используют данный протокол еще и для постоянного поддержания актуальности таблицы соседних, доступных на текущий момент времени, узлов и их канального адреса. Для реализации вышеописанных механизмов, узлы используют определенные многоадресные группы, некоторые из которых будут описаны в процессе реализации вектора атаки.
Протокол NDP определяет 5 типов ICMPv6 пакетов:
Router Solicitation. Когда интерфейс переходит в активное состояние, хосты могут посылать данный тип пакетов, в котором запрашивают у маршрутизаторов отсылку пакетов «Router Advertisement» со всей необходимой информацией о подсети.

Router Advertisement. Маршрутизаторы объявляют о своём присутствии посредством данного типа пакетов, в котором содержится необходимая информация о текущей подсети. Данные сообщения отсылаются с определенной периодичностью, либо в ответ на запросы «Router Solicitation», поступающих от хостов.

Neighbor Solicitation. Отправляется хостом либо для определения соседних хостов, находящихся в одноранговой подсети, либо для проверки текущей доступности хоста, если ранее таковой был обнаружен.

Neighbor Advertisement. Данные пакеты отсылаются на сообщения «Neighbor Solicitation».

Redirect. Используется маршрутизаторами для информирования хостов о лучшем маршруте для пересылки пакетов.
Существует 4 способа конфигурации адресации хоста в IPv6:
  • Статическая конфигурация. Подобно IPv4, в настройках сетевого интерфейса указывается адрес IPv6 и его перфикс, а также маршрут по умолчанию и прочие параметры;

  • Stateless Auto Address Configuration (SLAAC) – автоматическая настройка без сохранения состояния. Параметры подсети (префикс и маршрут поумолчанию) предоставляет соседний маршрутизатор при помощи пакетов «Router Advertisement»;

  • Stateful DHCPv6 – аналог DHCPv4;

  • Stateless DHCPv6 – смесь SLAAC и DHCPv6. В данном случае хосты конфигурируют адрес и маршрут по умолчанию при помощи SLAAC, а при помощи DHCPv6 получают дополнительную информацию (например, DNS).
Для начала, опишем среду, в которой будут проводиться тесты. Ниже представлена схема тестовой среды (Рис. 1).
Рис. 1. Схема тестовой среды
Описание атаки

Для воспроизведения SLAAC-атаки нам потребуется следующий инструментарий:

«Evil FOCA» – ПО с открытым исходным кодом для пентестеров и аудиторов безопасности, целью которого является проверка безопасности в сетях передачи данных IPv4/IPv6. Приложение поддерживает только линейку ОС Windows, начиная с версии WindowsXP.

Конфигурация DNS64 + NAT64, позволяющая обрабатывать DNSv6 запросы и отправлять через IPv4 подсеть IPv6 пакеты. Для DNS64 была выбрана утилита Totd (DNS прокси), а для NAT64 – TAYGA.

Фиктивный DNS сервер. В данном случае выбор пал на Windows Server 2012 R2.

SLAAC-атаку будем тестировать на следующих ОС: Windows 7, Windows 10, CentOS 7, Ubuntu 18.04.

Для того, чтобы удобнее было разбираться в адресах хостов, существующих в рамках стенда, отразим их в таблице (Таблица 1).

Перед тестированием, необходимо исследовать подсеть на наличие в ней существующих хостов с помощью ПО Evil FOCA (Рис. 2).
Таблица 1. Адресация хостов
Рис. 2. Интерфейс Evil FOCA
При запуске, приложение запускает ping по адресам FF02::1 и FF02::2. Согласно RFC4291, FF02::1 адрес принадлежит к группе многоадресной рассылки, адресаты которой являются все хосты в link-local подсети, а FF02::2 – адрес многоадресной рассылки, принадлежащей маршрутизаторам. Ниже представлен скриншот Wireshark, запущенного на одном из соседних хостов (Рис. 3).
Рис. 3. Окно программы Evil FOCA
Далее, нам необходимо выбрать все те хосты, на которых мы собираемся сконфигурировать SLAAC + Stateless DHCPv6. Для этого, во вкладке «MITM IPv6» -> «SLAAC» в строке напротив надписи «Target Prefix (IPv6)» указываем желаемый префикс подсети. Для примера, укажем префикс «2000:bad:ffff:ffff::». Также, данный инструмент позволяет выбрать конкретные хосты, которым будут персонально рассылаться пакеты RA (Router Advertisement). Воспользуемся этой возможностью и укажем наши атакуемые хосты. Помимо этого, во вкладке DHCPv6 укажем необходимый нам сторонний DNS сервер, на который и будут отсылаться запросы пользователей (в нашем случае, этим адресом будет 2000:bad:ffff:ffff::2).

Стоит отметить, что инициировать процедуру запроса дополнительной информации по DHCPv6 (другими словами, Stateless DHCPv6) хост может по нескольким причинам, описанных в RFC3315:

  1. ввиду начальной конфигурации ОС (или конфигурации загрузочного процесса);
  2. ввиду запроса данной информации с уровня приложений (используются специфичные API);
  3. по требованию расширения жизненного цикла назначенного адреса и/или делегированного префикса подсети, используя Renew/Rebind сообщения.
Рис. 4. Финальная конфигурация Evil FOCA. SLAAC
Рис. 5. Финальная конфигурация Evil FOCA. DHCPv6
В ходе проведения тестирования было выявлено, что хосты с ОС семейства Linux (CentOS, Ubuntu) отправляют «DHCP Solicit» сообщения после того, как была завершена процедура SLAAC. В ОС Windows же данные сообщения отправляются сразу же после перезагрузки ОС, либо после перезапуска сетевого интерфейса. Таким образом, можно сделать вывод, что для успешного интегрирования настроек DNS в атакующий хост для ОС семейства Linux достаточно выполнить процедуру SLAAC, в ОС Windows же атакующий будет вынужден, вдобавок, ожидать перезагрузки ОС, либо перезапуска сетевого интерфейса.

После запуска отправки RA + DHCPv6 Stateless на Evil FOCA, мы можем наблюдать следующую картину в настройках на тестируемых хостах (Рис. 6 – Рис. 9).
Рис. 6. Конфигурация сетевого интерфейса на Windows 7
Рис. 7. Конфигурация сетевого интерфейса на Windows 10
Рис. 8. Конфигурация сетевого интерфейса на Ubuntu
Рис. 9. Конфигурация сетевого интерфейса на CentOS
Теперь, для того, чтобы у нашего DNS сервера была возможность отвечать на запросы хостов и перенаправлять их на нужный нам DNS сервер, сконфигурируем сервер DNS64+NAT64. Конфигурация утилит TAYGA и Totd приведена в виде скриншотов (Рис. 10).
Рис. 10. Конфигурация утилит для DNS64 и NAT64
На примере одного из атакуемых хостов продемонстрируем весь цикл атаки:
  1. После получения префикса подсети через SLAAC и настроек DNSv6, выполним разрешение доменного имени «web-server. test.icl.com», запись для которого имеется как у фиктивного, таки у реального DNS серверов (Рис. 11).
  2. Хост, который функционирует как DNS64 + NAT64, переадресует все DNSv6 запросы на фиктивный DNS сервер, который указан в настройках Totd.
  3. После того, как фиктивный DNS сервер отвечает на запрос, утилита Totd преобразует IPv4 адрес в IPv6 адрес, добавляя к префиксу 2001:db8:1:ffff::/96 IPv4 адрес в последних двух хексетах. Стоит отметить, что последние два хексета полностью покрывают все адресное пространство IPv4.
  4. Далее, атакуемый хост, при обращении на требуемый сайт, имея его IPv6 адрес, обращается по http/ https, а маршрут по умолчанию перенаправляет пакет на хост DNS64 + NAT64 (Рис. 12, Рис. 13)
Рис. 11. Результат разрешения доменного имени
Рис. 12. Перенаправление пакета на хост DNS64 + NAT 64
Рис. 13. Пакет перенаправляется на 2000:bad:ffff:ffff::2
Заключение

Как было показано выше, использовать интерфейс IPv6 имеющийся сейчас в каждой ОС в качестве вектора для развития атаки не составляет особого труда, обеспечивая при этом желаемый результат. Учитывая, что все повсеместно продолжают использовать IPv4 и о IPv6 даже не задумываются, отбрасывая всякие намёки на него словами – «У нас его нет», данный протокол следует рассматривать как дополнительный не контролируемый канал в сети каждой организации и на рабочей станции каждого пользователя.

Как минимум стоит проверить действительно ли отключены возможности работы посредством IPv6 на рабочих станциях и применены настройки, обеспечивающие его безопасность на сетевом оборудовании и средствах защиты.
ПОДЕЛИТЬСЯ В СОЦСЕТЯХ