Туннелирование при пивотинге

Туннелирование пивотинг пентест

Мы уже рассказывали про техники туннелирования при пентесте. Сегодня продолжим эту тему и рассмотрим тему туннелирования при пивотинге. В этом неболь­шом иссле­дова­нии я про­демонс­три­рую нес­коль­ко тех­ник пивотин­га с исполь­зовани­ем про­вай­дер­ских про­токо­лов. Это кон­цепция в духе «living off the land»: я прос­то буду исполь­зовать осо­бен­ности сетевых про­токо­лов и добьюсь импакта для ата­кующей сто­роны. При этом я не буду исполь­зовать сто­рон­ние пен­тестер­ские ути­литы.

Еще по теме: Ethernet-туннели при пивотинге

Туннелирование при пивотинге

В этом сце­нарии ата­кующий пос­тро­ит GRE-тун­нель меж­ду собой и пог­ранич­ным роуте­ром, а затем сквозь сам роутер поверх GRE-тун­неля смо­жет вза­имо­дей­ство­вать с тре­мя сег­мента­ми и рас­ширить свое при­сутс­твие в сети.

Нас­трой­ка на сто­роне ата­кующе­го (я выб­рал Kali Linux) выг­лядит сле­дующим обра­зом:

Об­рати вни­мание на адре­сацию 10.10.10.0/24. Это внут­ренняя адре­сация в GRE-тун­неле, нуж­ная для его кор­рек­тной работы.

Те­перь нас­тра­иваем пог­ранич­ный роутер Cisco:

Ра­бота GRE-тун­неля, пинг Cisco IOS
Ра­бота GRE-тун­неля, пинг Cisco IOS

GRE-тун­нель акти­вен, теперь самое вре­мя про­писать мар­шру­ты до целевых сег­ментов. Ата­кующий, ока­зав­шись на пог­ранич­ном роуте­ре (сце­нарий пос­тэкс­плу­ата­ции), может сам изу­чить таб­лицу мар­шру­тиза­ции и узнать, до каких сег­ментов ему писать мар­шру­ты. В лабора­тор­ной сети этих сег­ментов три:

Шлю­зом для этих под­сетей выс­тупа­ет уда­лен­ная сто­рона GRE-тун­неля (10.10.10.2), то есть мы таким обра­зом про­писы­ваем мар­шру­ты сквозь пог­ранич­ный роутер, как и пред­полага­лось в сце­нарии. Пос­ле нас­трой­ки мар­шру­тов ата­кующий может вза­имо­дей­ство­вать с эти­ми сег­мента­ми и раз­вивать новые век­торы атак.

TCP-ска­ниро­вание внут­ри GRE тун­неля
TCP-ска­ниро­вание внут­ри GRE тун­неля

Как мы видим, 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 выг­лядит сле­дующим обра­зом, здесь ничего экс­тра­орди­нар­ного:

На взло­ман­ном сер­вере с Debian нас­трой­ка такая же, но наобо­рот:

Те­перь IPIP-тун­нель меж­ду ата­кующим и взло­ман­ным сер­вером ста­новит­ся активным и ата­кующий смо­жет раз­вивать ата­ки на сеть 192.168.252.0/24 (Warehouse):

TCP-ска­ниро­вание внут­ри IPIP-тун­неля
TCP-ска­ниро­вание внут­ри IPIP-тун­неля

Как вид­но на скрин­шоте, полез­ная наг­рузка при 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-инкапсу­ляции, которая будет тран­спор­тировать всю полез­ную наг­рузку. Сама ситу­ация «тун­нель в тун­неле» быва­ет не всег­да, это прос­то при­мер из головы.

Схе­ма сети с GRETAP
Схе­ма сети с GRETAP

С нас­трой­ками здесь будет пос­ложнее по срав­нению с L3-тун­нелями. В дело всту­пают bridge (брид­жи/мос­ты). Это спе­циаль­ные логичес­кие устрой­ства, куда помеща­ются физичес­кие интерфей­сы. Что­бы обес­печить себя L2-дос­тупом, ата­кующий дол­жен соз­дать мост на взло­ман­ной машине, а так­же помес­тить туда ее физичес­кий интерфейс и вир­туаль­ный TAP-интерфейс, при­чем необ­ходимо соб­людать порядок команд и исполнить их как одну с помощью точ­ки с запятой. Кон­фигура­ции L2-тун­нелей не про­щают оши­бок: если ты где‑то напутал, есть риск потерять дос­туп к ском­про­мети­рован­ной машине, а это очень боль­шой удар для пен­тесте­ра.

Нач­нем с нас­тро­ек на сто­роне ата­кующе­го. GRETAP-тун­нель меж­ду 10.10.10.1 (Kali) и 10.10.220.3 (целевая машина Debian с рутовым дос­тупом):

На сто­роне взло­ман­ной машины нас­трой­ка про­исхо­дит в нес­коль­ко эта­пов:

  • соз­дание GRETAP-интерфей­са и его акти­вация;
  • соз­дание брид­жа;
  • до­бав­ление в бридж GRETAP-интерфей­са;
  • уда­ление сущес­тву­юще­го адре­са с интерфей­са и его переме­щение на bridge (это дела­ют, что­бы не потерять сетевую связ­ность, так как пос­ле добав­ления интерфей­са в бридж сам интерфейс под­чиня­ется брид­жу, и
  • по‑хороше­му бы сто­ит наз­начить адрес на сам бридж);
  • до­бав­ление физичес­кого интерфей­са ОС в бридж;
  • ак­тивация работы брид­жа;
  • наз­начение адре­са шлю­за по умол­чанию (ког­да мы уда­ляли адрес из интерфей­са — исче­зал и мар­шрут по умол­чанию).

Те­перь на GRETAP-интерфей­се ата­кующе­го пошел движ. Мы видим здесь при­сутс­твие про­токо­ла STP — это уже доказы­вает, что мы обес­печили себя имен­но L2-тун­нелем, так как STP — про­токол каналь­ного уров­ня.

Тра­фик на GRETAP-интерфей­се
Тра­фик на GRETAP-интерфей­се

Те­перь необ­ходимо получить адрес на GRETAP-интерфейс из прос­транс­тва 10.10.220.0/24.

Ус­пешно получен­ный адрес на TAP-интерфей­се
Ус­пешно получен­ный адрес на TAP-интерфей­се

На этом нас­трой­ка GRETAP под­ходит к кон­цу, ата­кующий теперь может поз­волить себе ата­ки каналь­ного уров­ня.

Пе­рех­вачен­ный NTLMv2-SSP по GRETAP-тун­нелю
Пе­рех­вачен­ный NTLMv2-SSP по GRETAP-тун­нелю

Та­ким обра­зом мож­но про­вес­ти L2-пивотинг с помощью GRETAP-интерфей­сов.

VXLAN (L2)

VXLAN (Virtual EXtensible LAN) — сетевой про­токол, поз­воля­ющий стро­ить L2-тун­нели поверх UDP (UDP/4789). VXLAN-пивотинг тоже может раз­вивать­ся из любой точ­ки инфраструк­туры, но я пов­торю ситу­ацию «тун­нель в тун­неле», где ата­кующий попал внутрь сети с помощью GRE. Опять же не зацик­ливай­ся на этом, это прос­то мой при­мер. Мне было удоб­нее собирать для тебя прак­тичес­кий ману­ал, находясь в той же лабора­тор­ной сети в EVE-NG.

Ма­шина ата­кующе­го и ском­про­мети­рован­ная машина будут VTEP’ами. VTEP (Virtual Tunnel Endpoint) — устрой­ства, на которых стро­ится и тер­миниру­ется тун­нель VXLAN, они занима­ются инкапсу­ляци­ей и деин­капсу­ляци­ей VXLAN-заголов­ков.

VXLAN-тун­нелиро­вание
VXLAN-тун­нелиро­вание

Прис­тупим к нас­трой­ке тун­неля меж­ду ата­кующим (Kali Linux, 10.10.10.1) и целевой Debian-машиной (10.10.220.2). Так­же наз­начим VNI (это иден­тифика­тор VXLAN-тун­неля), он будет равен 10. UDP-порт наз­начения с обе­их сто­рон оди­нако­вый — 4789. VXLAN может работать в двух режимах: multipoint и point-to-point, я выберу вто­рой вари­ант.

На сто­роне целевой машины c Debian VXLAN нас­тра­ивает­ся так же, одна­ко при­дет­ся сно­ва попотеть над нас­трой­кой брид­жа, как это было с GRETAP.

На этом нас­трой­ка VXLAN с обе­их сто­рон закан­чива­ется, на VXLAN-интерфей­се ата­кующе­го мы видим тра­фик про­токо­лов каналь­ного уров­ня (STP, CDP), что доказы­вает получе­ние имен­но L2-дос­тупа.

Тра­фик на VXLAN-интерфей­се ата­кующе­го
Тра­фик на VXLAN-интерфей­се ата­кующе­го

За­тем получа­ем адрес на интерфей­се VXLAN с пос­леду­ющим уда­лени­ем шлю­за по умол­чанию.

По­лучен­ный адрес на VXLAN-интерфей­се
По­лучен­ный адрес на VXLAN-интерфей­се

И в этот раз не поб­резгую запус­тить Responder.

Пе­рех­вачен­ный NTLMv2-SSP по VXLAN-тун­нелю
Пе­рех­вачен­ный NTLMv2-SSP по VXLAN-тун­нелю

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.

Сеть с пог­ранич­ным RouterOS
Сеть с пог­ранич­ным RouterOS

Ата­кующий из интерне­та может ока­зать­ся в целевой сети на уров­не L2, но это край­не спе­цифи­чес­кий сце­нарий и име­ет пра­во на сущес­тво­вание толь­ко в момент пос­тэкс­плу­ата­ции.

Нас­трой­ки на сто­роне ата­кующе­го выг­лядят сле­дующим обра­зом: соз­дает­ся TAP-интерфейс, запус­кает­ся модуль, тун­нелю зада­ется ID 100:

На сто­роне RouterOS ана­логич­но, но при этом нуж­но помес­тить соз­данный EoIP-интерфейс в сущес­тву­ющий бридж внут­ри RouterOS для получе­ния L2-дос­тупа. Тут исполь­зует­ся вер­сия RouterOS v6:

Пос­ле этих нас­тро­ек EoIP-тун­нель будет уста­нов­лен. На TAP-интерфей­се ата­кующе­го уже есть тра­фик, адрес по DHCP получен.

Тра­фик на TAP-интерфей­се внут­ри EoIP
Тра­фик на TAP-интерфей­се внут­ри EoIP
От­работав­ший Responder внут­ри EoIP
От­работав­ший Responder внут­ри EoIP

Та­ким обра­зом мож­но про­вес­ти сво­еоб­разный пивотинг сквозь RouterOS и про­водить ата­ки каналь­ного уров­ня. Век­тор край­не необыч­ный, одна­ко есть шанс, что им мож­но будет вос­поль­зовать­ся в кор­поратив­ных сетях.

Пивотинг vs Windows

Как ты заметил, все опи­сан­ные выше при­емы про­демонс­три­рова­ны имен­но на Linux. Почему так получи­лось? Потому что дес­ктоп­ные редак­ции Windows не под­держи­вают про­токо­лы тун­нелиро­вания вро­де GRE и VXLAN. Воз­можно, их под­дер­жка есть в Windows Server, но в эту тему я не углублял­ся. Одна­ко и здесь есть решение, хоть и доволь­но экзо­тичес­кое.

В июле это­го года я сде­лал «ремикс» статьи «Пин­гвин‑супер­шпи­он» в исполне­нии s0i37. Мне приш­ла в голову мысль раз­вернуть вир­туаль­ный мар­шру­тиза­тор CHR на VirtualBox внут­ри самой Windows. Так я про­вел L2-пивотинг и ата­ки каналь­ного уров­ня в целевой сети, исполь­зуя хост с Windows. Метод ско­рее экспе­римен­таль­ный, но работа­ет. Вир­туаль­ный CHR под­держи­вает про­токо­лы EoIP, VXLAN, IPIP, GRE и дру­гие.

Вот как это выг­лядело на бумаге
Вот как это выг­лядело на бумаге

Заключение

Методы край­не спе­цифи­чес­кие, но, если ты понима­ешь всю кар­тину и зна­ешь мат­часть, у тебя не воз­никнет проб­лем и эти при­емы при­ведут к успе­ху.

ПОЛЕЗНЫЕ ССЫЛКИ:

Дима (Kozhuh)

Эксперт в области кибер-безопасности. Работал в ведущих компаниях занимающихся защитой и аналитикой компьютерных угроз.

Добавить комментарий