🥇Всичко е много лошо или нов вид прихващане на трафик

На 13 март в работната група на RIPE за борба с злоупотребите постъпи предложение да се разглежда BGP-прихващането (hjjack) като нарушение на политиката на RIPE. В случай на приемане на предложението, интернет доставчикът, атакуван чрез прихващане на трафика, би имал възможност да изпрати специално искане за изваждане на нарушителя на светло. Ако експертната група събере достатъчно доказателства, то такъв LIR, който е източник на BGP-прихващане, ще се смята за нарушител и може да бъде лишен от статус LIR. Имаше и някои аргументи против такова промяна.

В настоящата публикация искаме да покажем пример за атака, при която не само истинският нарушител беше под въпрос, но и целият списък на пострадалите префикси. Освен това, такава атака отново поставя въпроси относно мотивите за бъдещите прихващания на трафик от този тип.

През последните години в пресата като BGP-прихващания бяха отразявани само конфликти от типа MOAS (Multiple Origin Autonomous System). MOAS е частен случай, при който две различни автономни системи анонсират конфликтни префикси с съответните номера на ASN в AS_PATH (първият ASN в AS_PATH, по-надолу в текста - origin ASN). Въпреки това, можем да назовем поне 3 допълнителни типа прихващане на трафик, позволяващи на нарушителя да манипулира атрибута AS_PATH с различни цели, включително и за заобикаляне на съвременните подходи за филтриране и мониторинг. Известен тип атака Пилосова-Капела е последният тип такова прихващане, но съвсем не по значение. Напълно възможно е именно такава атака да наблюдавахме през последните седмици. Такова събитие има обясним характер и доста сериозни последствия.

Тези, които търсят TL;DR версия, могат да превъртат до подзаглавието „Идеалната атака“.

Мрежов бекграунд

(за да разберете по-добре процесите, участващи в този инцидент)

Ако искате да изпратите пакет и имате няколко префикса в таблицата на маршрутизацията, които съдържат IP адрес на целта, то ще използвате маршрута за префикса с максимална дължина. Ако в таблицата на маршрутизацията съществуват няколко различни маршрута за един префикс, ще изберете най-добрия (съгласно механизма за избор на най-добър път).

Съществуващите подходи за филтриране и мониторинг се опитват да анализират маршрутите и да вземат решения, анализирайки атрибута AS_PATH. Рутерът може да промени този атрибут на всяка стойност по време на анонсирването. Просто добавянето на ASN на собственика в началото на AS_PATH (като origin ASN) може да е достатъчно за заобикаляне на текущите механизми за проверка на източника. Освен това, ако съществува маршрут от атакувания ASN до вас, се появява възможност да изтеглите и използвате AS_PATH на този маршрут в другите ваши анонси. Всяка проверка на валидността само на AS_PATH за вашите създадени анонси накрая ще бъде премината.

Съществуват и няколко достойни за споменаване ограничения. На първо място, в случай на филтриране на префикси от по-висок доставчик, вашият маршрут все пак може да бъде отфилтриран (дори с коректен AS_PATH), ако префиксът не принадлежи на вашия клиентски конус, настроен при апстрима. Второ — валиден AS_PATH може да стане невалиден, ако създаденият маршрут е анонсиран в некоректни направления и така нарушава политиката за маршрутизиране. И накрая — всеки маршрут с префикс, нарушаващ ROA дължината, може да бъде считан за невалиден.

Инцидент

Преди няколко седмици получихме оплакване от един от потребителите. Видяхме маршрути с неговия origin ASN и префикси /25, докато потребителят твърдеше, че те не са анонсирани.

TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|НЕПЪЛЕН|xxx|0|0||NAG|| TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|НЕПЪЛЕН|xxx|0|0||NAG|| TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|НЕПЪЛЕН|xxx|0|0||NAG|| TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|НЕПЪЛЕН|xxx|0|0||NAG|| TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|НЕПЪЛЕН|xxx|0|0||NAG|| TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|НЕПЪЛЕН|xxx|0|0||NAG|| TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|НЕПЪЛЕН|xxx|0|0||NAG|| TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|НЕПЪЛЕН|xxx|0|0||NAG||
Примери за анонси в началото на април 2019

NTT по пътя за префикса /25 го прави особено подозрителен. По време на инцидента LG NTT не знаеше нищо за този маршрут. Така че да, някой оператор създава цял AS_PATH за тези префикси! Проверка на други рутери позволява да се открои един особен ASN: AS263444. Следвайки други маршрути с тази автономна система, се сблъскахме със следната ситуация:

TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG|| TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG|| TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG|| TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG|| TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG|| TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG|| TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG|| TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG|| TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG|| TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
Опитайте се да познаете какво не е наред тук

Изглежда, че някой е взел префикса от маршрута, разделил го на две части и анонсирал маршрут със същия AS_PATH за тези две префикси.

TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG|| TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG|| TABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG|| TABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG|| TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG|| TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG|| TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG|| TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
Примери за маршрути за една от двойките разделени префикси

Възникват няколко въпроса. Наистина ли някой е опитал на практика такъв тип прихващане? Някой ли е приел тези маршрути? Какви префикси бяха засегнати?

Тук започва нашият пореден провал и още един кръг разочарование в настоящото здравословно състояние на интернет.

Пътят на провалите

Нека започнем от самото начало. Как можем да определим кои маршрутизатори са приели такива прихванати маршрути и чий трафик може да бъде пренасочен вече днес? Помислихме да започнем с префикси /25, защото те „просто не могат да имат глобално разпространение“. Както можете да предположите — дълбоко се заблуждавахме. Тази метрика се оказа твърде шумна и маршрути с такива префикси могат да се появят дори от оператори от Tier-1. Например, NTT има около 50 такива префикси, които разпространява сред своите клиенти. От друга страна, тази метрика е лоша, защото такива префикси могат да бъдат филтрирани, ако операторът прилага филтриране на малки префикси, във всички посоки. Затова този метод не е подходящ за намиране на всички оператори, чийто трафик е бил пренасочен в резултат на подобен инцидент.

Още една добра идея изглеждаше да погледнем на POV. В частност на маршрути с нарушение на правилото maxLength на съответния ROA. По този начин можем да намерим броя на различните оригинални ASN с статус Invalid, които са били видими за този AS. Въпреки това, има „малък“ проблем. Средното значение (медие и мода) на това число (броя на различните оригинални ASN) е около 150 и дори ако филтрираме малките префикси, то остава над 70. Такова положение има напълно просто обяснение: има само няколко оператора, които вече прилагат ROA-филтри с политика „да се откажат от Invalid маршрути“ на входните точки, така че навсякъде в реалния свят, където се появи маршрут с нарушение на ROA, той може да се разпространява във всички посоки.

Последните два подхода позволяват да намерим оператори, които са видели нашия инцидент (тъй като той беше достатъчно голям), но като цяло те не са приложими. Добре, но можем ли да намерим нападателя? Какви са общите характеристики на такава манипулация AS_PATH? Има няколко основни предположения:

Префиксът не е бил забелязан никъде преди;
Origin ASN (напомняне: първият ASN в AS_PATH) е валиден;
Последният ASN в AS_PATH е ASN на нападателя (в случай, че съседът проверява ASN на съседа на всички входящи маршрути);
Атаката произлиза от един провайдър.

Ако всички предположения са верни, то на всички неправилни маршрути ще бъде представен ASN на нападателя (освен origin ASN) и, така, това е „критична“ точка. Сред истинските хакери е и AS263444, въпреки че имаше и други. Дори когато отстранявахме маршрутите на инцидента от обхвата. Защо? Критичната точка може да остане критична дори за правилни маршрути. Тя може да е либо резултат от лоша свързаност в някой регион, либо ограничения на нашата собствена видимост.

Като резултат: има начин да се открие нападателят, но само при спазване на всички изброени по-горе условия и само когато перехватът е достатъчно голям, за да премине праговете за мониторинг. Ако някои от тези фактори не са спазени, можем ли да изолираме префиксите, пострадали от подобен перехват? За определени оператори — да.

Когато нападателят създава more specific маршрут, такъв префикс не се обявява от истинския собственик. Ако имате динамичен списък на всички негови префикси, то имате възможност да направите сравнение и да намерите изкривените more specific маршрути. Ние събираме този списък от префикси чрез нашите BGP сесии, тъй като ни предават не само пълния списък на маршрутите, видими за оператора в момента, но и списък на всички префикси, които той иска да обяви на света. За съжаление, в момента има няколко десетки потребители на Radar, които не изпълняват последната част напълно коректно. В близко бъдеще ще ги уведомим и ще се опитаме да решим този проблем. Всички останали могат да се присъединят към нашата система за мониторинг точно сега.

Ако се върнем към първоначалния инцидент, и нападателят, и обхватът на разпространение бяха открити от нас чрез търсене на критични точки. Учудващо, но AS263444 разпространяваше фалшифицирани маршрути не на всички свои клиенти. Въпреки това, има и по-странен аспект.

BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG|| BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
Наскоро имаше опит за перехват на нашето адресно пространство

Когато бяха създадени more specific’и за нашите префикси, беше използвано специално създадено AS_PATH. Въпреки това, този AS_PATH не можеше да бъде взет от нито един от нашите предишни маршрути. Нямаме даже връзка с AS6762. Нека разгледаме другите маршрути в инцидента: някои от тях имаха истински AS_PATH, който е бил използван преди, докато при други нямаше такъв, дори да изглеждаше като истински. Допълнителната промяна на AS_PATH няма никакъв практичен смисъл, тъй като трафикът все пак ще бъде пренасочен към нападателя, но маршрутите с “лош” AS_PATH могат да бъдат филтрирани от ASPA или от друг проверяващ механизъм. Тук се замисляме за мотивацията на хакера. В момента ни липсват данни, за да твърдим, че този инцидент е бил планирана атака. Въпреки това — това е възможно. Нека опитаме да си представим макар и хипотетична, но потенциално напълно реална ситуация.

Идеална атака

Какво имаме? Да предположим, че сте транзитен доставчик, който предава маршрути за своите клиенти. Ако вашите клиенти имат множество присъствия (multihome), ще получите само част от техния трафик. Но колкото повече трафик — толкова повече доходи. Затова, ако започнете да анонсирате префиксите на подсетите на тези същите маршрути с един и същ AS_PATH, ще получите останалата част от техния трафик. В резултат ще получите остатъчната част от парите.

Ще помогне ли тук ROA? Вероятно да, ако решите напълно да се откажете от използването на maxLength. Освен това, при това е изключително нежелателно да имате записи ROA с припокриващи се префикси. За някои оператори такива ограничения са неприемливи.

Разглеждайки други механизми за осигуряване на безопасността на маршрутизацията, в този случай ASPA също няма да помогне (поради използването на AS_PATH от допустим маршрута). BGPSec все още не е оптимален вариант заради ниския процент на приемане и оставащата възможност за downgrade-атаки.

Така имаме явна печалба за атакуващия и недостатък на сигурността. Отлична смес!

Какво трябва да се прави?

Очевидният и най-радикален ход е преразглеждането на текущата ви маршрутизираща политика. Разделете адресното си пространство на най-малките парчета (без припокрития), които искате да обявите. Подпишете ROA само за тях, без да използвате параметъра maxLength. В този случай текущият POV може да ви спаси от подобна атака. Въпреки това, за някои оператори този подход не е разумен заради изключителното използване на more specific маршрути. Всички проблеми с текущото състояние на ROA и обектите на маршрути ще бъдат описани в един от нашите бъдещи материали.

Освен това можете да се опитате да наблюдавате подобни прихващания. За целта ни е нужна надеждна информация за вашите префикси. Така че, ако установите BGP сесия с нашия колектор и ни предоставите информация за вашата видимост в Интернет — можем да открием обхвата на разпространение и за други инциденти. За тези, които все още не са свързани с нашата мониторингова система — за начало ни е достатъчен списък с маршрути само с вашите префикси. Ако вече имате сесия с нас, моля, проверете, че всички ваши маршрути са изпратени. За съжаление, трябва да напомним за това, тъй като част от операторите забравят един или два префикса и по този начин създават пречки за нашите методи на търсене. Ако всичко се направи правилно, то ще имаме надеждни данни за вашите префикси, които в бъдеще ще помогнат за автоматично определяне и откриване на такъв (и други) типове прихващане на трафик за вашето адресно пространство.

Ако в реално време научите за такова прихващане на вашия трафик, можете да се опитате да му се противопоставите сами. Първият подход е да обявите маршрути с тези more specific префикси сами. В случай на нова атака върху тези префикси — повторете.

Вторият подход е да накажете извършителя и тези, за които той е критичен момент (за добри маршрути), отрязвайки достъпа на вашите маршрути до извършителя. Това може да се направи, като добавите ASN на извършителя в AS_PATH на вашите стари маршрути и по този начин да ги накарате да избягват това AS, използвайки вградения механизъм за откриване на цикли в BGP. за собственото си благо.

Източник: habr.com