TunnelCrack супраць TunnelVision: што насамрэч ламае кожны з іх

Дзве даследчыя назвы ўжываюць узаемазаменна для любога VPN-трафіку, які выходзіць з тунэля, але механізмы за імі не аднолькавыя. TunnelCrack апісвае два сямействы выключэнняў маршрутызацыі; TunnelVision апісвае маршрут, які пастаўляе DHCP на канцавой прыладзе. Ні адзін з іх не ламае шыфраванне, і ні адзін не кажа вам, што робіць канкрэтная зборка кліента сёння. Пяць праверак аддзяляюць механізмы ад загалоўка.

Крок першы: назавіце механізм, які вы разглядаеце

Раскрыццё TunnelCrack у жніўні 2023 года апісвае два сямействы атак. У выпадку лакальнай сеткі трафік, які кліент лічыць належным да лакальнай сеткі, атрымлівае выключэнне лакальнага доступу і выходзіць з тунэля. У выпадку адрасу сервера маршрут, патрэбны кліенту, каб дасягнуць самога VPN-сервера, знаходзіцца па-за тунэлем, і супраціўнік, які кантралюе гэты адрас, можа скарыстацца выключэннем.

TunnelVision — асобная справаздача пра безкласавыя статычныя маршруты, якія пастаўляе DHCP. Шкодны DHCP-сервер можа выдаць канцавой прыладзе маршруты, што змяняюць шлях трафіку, уключна са шляхам да VPN-сервера. Справаздача прызнае ранейшую працу пра звязаныя эфекты маршрутызацыі, што нагадвае: асноўны механізм старэйшы за назву.

Трымайце назвы прывязанымі да іх механізмаў. Ужыванне выпраўлення для аднаго таму, што другі ў навінах, — гэта спосаб, якім праверка стварае рух без пакрыцця.

Крок другі: паглядзіце на выключэнне лакальнага доступу

Большасць кліентаў вызваляе трафік лакальнай сеткі, каб прынтары, трансляцыя і абагульванне файлаў працавалі, пакуль тунэль уключаны. Гэтае выключэнне — палітычнае рашэнне з коштам для бяспекі: супраціўнік у той жа сетцы можа прадставіцца лакальным хастом, і трафік, які да яго даходзіць, ніколі не ўваходзіў у тунэль.

Спытайцеся, ці патрэбна разгорнутаму профілю гэтае выключэнне наогул. Дыстанцыйная працоўная сіла, якая ніколі не выкарыстоўвае лакальнае выяўленне, часта можа яго адключыць, а тыя лакальныя сэрвісы, што засталіся, можна дасягнуць праз дакументаваны шлях. Там, дзе выключэнне неабходнае, пазначце, якія прызначэнні яно ахоплівае, замест апісання яго як лакальнага трафіку.

Праверка — гэта пытанне канфігурацыі, а не захоп пакетаў. Прачытайце наладу профілю і дакументацыю кліента для той зборкі, якую вы разгортваеце, бо прадвызначанае значэнне розніцца паміж прадуктамі і паміж версіямі аднаго прадукту. Запішыце адказ побач з профілем, каб наступны правяраючы не мусіў выводзіць яго з паводзінаў. Выключэнне, якога ніхто не задокументаваў, — гэта выключэнне, якога ніхто не правярае.

Крок трэці: паглядзіце, як вызначаецца адрас сервера

Кліент мусіць дасягнуць VPN-сервера раней, чым існуе які-небудзь тунэль, таму гэтае прызначэнне па задуме маршрутызуецца па-за тунэлем. Калі адрас атрымліваюць з імені, этап развязання ўваходзіць у шлях даверу, і супраціўнік, здольны адказаць на гэты запыт, можа накіраваць кліента на хост, які ён кантралюе.

Замацаванне адрасу, выкарыстанне праверанага сертыфіката з правільным імем і адмова ад вяртання да неправеранага сервера — усё гэта памяншае ўздзеянне. Ні адно з гэтага не здымае неабходнасці дасягаць сервера па-за тунэлем; яны змяняюць таго, хто можа адказаць за гэты адрас.

resolvectl query vpn.lab.example
ip route get 198.51.100.24
ip rule show

Пошук маршруту паказвае інтэрфейс, які кліент выкарыстаў бы для адрасу сервера, і гэта выключэнне ў канкрэтнай форме. Калі гэты пошук вяртае інтэрфейс тунэля, кліент наогул не можа ўсталяваць тунэль, таму вонкавы маршрут чаканы, і пытанне толькі ў тым, як выбіраецца яго прызначэнне.

Крок чацвёрты: паглядзіце на маршруты, якія пастаўляе DHCP

Безкласавыя статычныя маршруты дазваляюць DHCP-серверу выдаваць запісы табліцы маршрутызацыі, і канцавая прылада звычайна прымае іх, не пытаючыся. У сетцы, дзе супраціўнік можа адказаць на DHCP хутчэй за законны сервер, гэтыя запісы могуць перанакіраваць трафік, які карыстальнік лічыць унутры тунэля.

Параўнайце маршруты на канцавой прыладзе з маршрутамі, якія вы чакаеце. Прадвызначаны маршрут або шырокі прэфікс, накіраваны на лакальны шлюз, пакуль тунэль уключаны, — гэта прыкмета, вартая расследавання, і яна бачная без якога-небудзь трафіку атакі.

ip route show table all
ip route get 203.0.113.55
nmcli -g ipv4.ignore-auto-routes con show "Wired connection 1"

Апошняя налада — гэта кіраванне на баку канцавой прылады, якое многія кліенты і платформы прадстаўляюць у нейкай форме: ігнараваць маршруты, якія пастаўляе сетка. Адключэнне аўтаматычнага прыёму маршрутаў — кампраміс, бо яно адключае таксама законную раздзеленую маршрутызацыю ад карпаратыўнага DHCP-сервера, таму вырашайце гэта па класе сеткі, а не глабальна.

Крок пяты: аддзяліце паведамленне ад бягучай зборкі

Апублікаваная атака апісвае паводзіны, назіраныя на пэўных версіях кліента ў пэўны час. Яна не даказвае, што ноўтбук перад вамі закрануты, і не даказвае, што ён выпраўлены. Абодва сцверджанні патрабуюць фактычнага нумара зборкі і бягучага паведамлення вытворцы.

Запішыце версію кліента, платформу, налады профілю, якія кіруюць выключэннямі вышэй, і дату, калі вы правяралі. Гэты запіс старэе сумленна, а заўвага пра тое, што VPN заплатавалі супраць TunnelCrack, — не. Перачытвайце яго пры кожным абнаўленні кліента, бо прадвызначанае значэнне профілю можа змяніцца пад версіяй, да якой вы не дакрануліся.

Калі вы сапраўды правяраеце, выкарыстоўвайце ўхвалены план супраць уласнай канцавой прылады і бяспечнага прызначэння. Адпраўляць атаку супраць іншых карыстальнікаў у агульнай сетцы — не тэст, а адключэнне праверкі партнёра або шыфравання праграмы, каб зрабіць назіранне прасцейшым, здымае абарону, якую вы спрабавалі вымераць.

Нарэшце, трымайце ў полі зроку абарону на ўзроўні праграм. Выключэнне маршрутызацыі можа адкрыць трафік, які тунэль мог бы несці, а TLS праграмы ўсё яшчэ абараняе гэты трафік ад канца да канца. Два ўзроўні адмаўляюць незалежна, таму падключаны канал кіравання не з'яўляецца доказам таго, што кожны паток ішоў па прызначаным шляху.