Введение
Разговоров о 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.jpg _1.jpg](/upload/medialibrary/61e/61e13e0650de1b8df92439dfe30176c1.jpg)
Рис. 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 (1).jpg _1 (1).jpg](/upload/medialibrary/039/0390f5e621ba0690f06d916da64a9de7.jpg)
Таблица 1. Адресация хостов
![_2.jpg _2.jpg](/upload/medialibrary/6d8/6d80a4de1b2d24c88ec99f4040afbb0d.jpg)
Рис. 2. Интерфейс Evil FOCA
При запуске, приложение запускает ping по адресам FF02::1 и FF02::2. Согласно RFC4291, FF02::1 адрес принадлежит к группе многоадресной рассылки, адресаты которой являются все хосты в link-local подсети, а FF02::2 – адрес многоадресной рассылки, принадлежащей маршрутизаторам. Ниже представлен скриншот Wireshark, запущенного на одном из соседних хостов (Рис. 3).
![_3.jpg _3.jpg](/upload/medialibrary/328/328de1f21a7756ebb6b19d9111022368.jpg)
Рис. 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:
- ввиду начальной конфигурации ОС (или конфигурации загрузочного процесса);
- ввиду запроса данной информации с уровня приложений (используются специфичные API);
- по требованию расширения жизненного цикла назначенного адреса и/или делегированного префикса подсети, используя Renew/Rebind сообщения.
![_4.jpg _4.jpg](/upload/medialibrary/13b/13bd0649af482ffbc3d3eae09f775a78.jpg)
Рис. 4. Финальная конфигурация Evil FOCA. SLAAC
![_5.jpg _5.jpg](/upload/medialibrary/b15/b156926efa28b4bf1a072d887f4d5ba7.jpg)
Рис. 5. Финальная конфигурация Evil FOCA. DHCPv6
В ходе проведения тестирования было выявлено, что хосты с ОС семейства Linux (CentOS, Ubuntu) отправляют «DHCP Solicit» сообщения после того, как была завершена процедура SLAAC. В ОС Windows же данные сообщения отправляются сразу же после перезагрузки ОС, либо после перезапуска сетевого интерфейса. Таким образом, можно сделать вывод, что для успешного интегрирования настроек DNS в атакующий хост для ОС семейства Linux достаточно выполнить процедуру SLAAC, в ОС Windows же атакующий будет вынужден, вдобавок, ожидать перезагрузки ОС, либо перезапуска сетевого интерфейса.
После запуска отправки RA + DHCPv6 Stateless на Evil FOCA, мы можем наблюдать следующую картину в настройках на тестируемых хостах (Рис. 6 – Рис. 9).
![_6.jpg _6.jpg](/upload/medialibrary/557/5574adafbd1a843f445b84c53bfa9b86.jpg)
Рис. 6. Конфигурация сетевого интерфейса на Windows 7
![_7.jpg _7.jpg](/upload/medialibrary/a29/a29a3ef1bb74ccba733089ac26665d66.jpg)
Рис. 7. Конфигурация сетевого интерфейса на Windows 10
![8.jpg 8.jpg](/upload/medialibrary/709/7093f6c4b890832e871c8d0c365fd369.jpg)
Рис. 8. Конфигурация сетевого интерфейса на Ubuntu
![9.jpg 9.jpg](/upload/medialibrary/179/1795f9582815e6ba1d7dbf7173faa61e.jpg)
Рис. 9. Конфигурация сетевого интерфейса на CentOS
Теперь, для того, чтобы у нашего DNS сервера была возможность отвечать на запросы хостов и перенаправлять их на нужный нам DNS сервер, сконфигурируем сервер DNS64+NAT64. Конфигурация утилит TAYGA и Totd приведена в виде скриншотов (Рис. 10).
![10.jpg 10.jpg](/upload/medialibrary/b19/b192702b278105c8bcd06c350e46f84e.jpg)
Рис. 10. Конфигурация утилит для DNS64 и NAT64
На примере одного из атакуемых хостов продемонстрируем весь цикл атаки:
- После получения префикса подсети через SLAAC и настроек DNSv6, выполним разрешение доменного имени «web-server. test.icl.com», запись для которого имеется как у фиктивного, таки у реального DNS серверов (Рис. 11).
- Хост, который функционирует как DNS64 + NAT64, переадресует все DNSv6 запросы на фиктивный DNS сервер, который указан в настройках Totd.
- После того, как фиктивный DNS сервер отвечает на запрос, утилита Totd преобразует IPv4 адрес в IPv6 адрес, добавляя к префиксу 2001:db8:1:ffff::/96 IPv4 адрес в последних двух хексетах. Стоит отметить, что последние два хексета полностью покрывают все адресное пространство IPv4.
- Далее, атакуемый хост, при обращении на требуемый сайт, имея его IPv6 адрес, обращается по http/ https, а маршрут по умолчанию перенаправляет пакет на хост DNS64 + NAT64 (Рис. 12, Рис. 13).
![11.jpg 11.jpg](/upload/medialibrary/dd3/lnmhpuwj5wr1h8mgdsr4uykk168q55ng/image_2022-10-18_14-40-25.png)
Рис. 11. Результат разрешения доменного имени
![_12.jpg _12.jpg](/upload/medialibrary/8de/8de7e79fe3cba3673fbc5e85561a6c83.jpg)
Рис. 12. Перенаправление пакета на хост DNS64 + NAT 64
![13.jpg 13.jpg](/upload/medialibrary/708/708fec3d542a6ebb2ed19f59147e66b8.jpg)
Рис. 13. Пакет перенаправляется на 2000:bad:ffff:ffff::2
Заключение
Как было показано выше, использовать интерфейс IPv6 имеющийся сейчас в каждой ОС в качестве вектора для развития атаки не составляет особого труда, обеспечивая при этом желаемый результат. Учитывая, что все повсеместно продолжают использовать IPv4 и о IPv6 даже не задумываются, отбрасывая всякие намёки на него словами – «У нас его нет», данный протокол следует рассматривать как дополнительный не контролируемый канал в сети каждой организации и на рабочей станции каждого пользователя.
Как минимум стоит проверить действительно ли отключены возможности работы посредством IPv6 на рабочих станциях и применены настройки, обеспечивающие его безопасность на сетевом оборудовании и средствах защиты.