Перехват трафика с помощью подмены BGP сессий.

До 2014 года в описании протокола BGP не было указано, что делать с маршрутизаторами, которые не объявлены в конфигурации (а в 2014 был выпущен RFC7132, в котором были педложены меры по устранению ряда угроз и потенциальных уязвимостей протокола). Иными словами, Текущая спецификация BGP (4 версии) позволяет реализациям протокола принимать соединения от не указанных в конфигурации партнеров, хоть и указано, что пограничные маршрутизаторы (то есть маршрутизаторы в разных автономных системах — AS), общающиеся через этот протокол должны быть соединены непосредственно (иначе быть в режиме multihop).

Но как оказалось, что если пару лет назад такие «штуки» прокатывали с некоторыми реализациями BGP (Quagga или Bird), то сейчас такое не канает (с последней версией Quagga и Bird точно, хотя есть другие менее популярные реализации), что было уже поулчено экспериментальным путем — я поднял у себя на машине BGP маршрушитзатор A, который настроил на работу с найденными мною роутерами из других сетей. И он отказывался устанавливать соединения, если его не было прописано в конфиге или установлено уже после запуска на роутерах, с которыми это соединение настраивалось, то соединение отбрасывалось.

Но даже если прописать соседство в конфиг, то соединение будет с одну сторону, так как надо роутеры не соединины непосредственно, то есть надо еще как-то установить атакуемый роутер в режим multihop’a. При чем это относиться еще и к IBGP, то есть к маршрутизаторам из одной AS, кроме режима multihop, который возможен только для роутеров из разных AS.

Таким образом, как-то повлиять на маршруты, передаваемые между BGP роутерами можно путем обычной отправки BGP сообщений на целевой роутер, только если его BGP демон позволяет это делать (установкой соответствующего бита в OPEN сообщении BGP), либо установлена старая версия.

Возможные выходы из ситуации.

Исходя из обозначенных выше ограничений, можно обозначить следующие решения:

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

Все остальные варианты попыток изменения маршрутов сводятся к одному — получению доступа к роутеру. А уже эту задачу можно решать различными ухищрениями и подходами, мне на ум пришло несколько нехитрых способов:

• брут пароля от интерфейса управления BGP;
• получение доступа посредством взлома почта/аккаунтов/компьютеров одного из сотрудников или администраторов какого-нибудь провайдера (который держит этот целевой роутер);
• поиск или эксплуатация уже существующих багов в BGP-сервере, запущенном на роутере (по моему опыту, это чаще всего Bird, Quagga или стандартный демон Cisco);
• получение доступа к роутеру через сторонние сервисы, запущенные на нем;
• «вклинивание» в уже установленную BGP сессию между определенными узлами;

О каждом чуть подробнее.

1) тут все ясно, основная задача — автоматизация процесса

2) при запуске BGP-сервера на хосте иногда также открывается 2605 порт, подключевшись на который через Telnet можно рулить BGP настройками и таблицами роутера, пароль как правило храниться в незашифрованном виде в конфигурационных файлах (если брать Bird и Quagga), так что если будет возможность читать файлы на роутере, то доступ к BGP обеспечен, ну а по канонам вытекает только решение брутить пароль;

3) это уже довольно обширная тема, в которую может входить исследование сети провайдера или даже личных компов его сотрудников, рассылка малвари, социальная инженерия и пр., в общем это уже сравни полноценной масштабной атаке на провайдера, попав в сеть которого еще придется закрепиться и распространиться, пока не достигнем цели — доступа к BGP роутерам;

4) если на роутерах стоит старая версия или мы нашли какой-то новый баг, позволяющий хотя бы читать содержимое памяти, то можно получить доступ к BGP, тут все ясно;

5) часто в роутерах работает сразу несколько служб, иногда даже попадались те, на которых размещался веб-сервер (не первой свежести) с сайтом компании и там же был запущен BGP сервис

6) так как BGP работает поверх TCP и по дефолту не предоставляет никаких защитных механизмов от вторжения в сессию, модификацию сообщений или их удалению, то все атаки на TCP могут быть успешно использованы для получения возможности отправлять сообщения от третьего валидного лица. При чем BGP сессии для различных атак на TCP очень хорошо подходят, так как сессии между партнерами дляться очень долго, что дает возможность перебрать возможные SEQ и ACK ключи у взаимодействующих роутеров

Далее я опишу чуть подробнее опыт реализации некоторых пунктов из этого списка.

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

Моя выборка была относительно мелкой — около 5000 роутеров с открытыми 179 портами (BGP) я прочекал на возможность установить BGP соединение. Для этого был написан автоматизирующий скрипт, который отправлял TCP пакеты и анализировал соединения, на первый пакет с флагом SYN отправлялся ответный SYN, ACK, затем если на третий паекет с ACK’ом отправлялся ответный с флагами FIN, ACK — то это значит, что роутер фильтранул наше соединение и не сразу же его завершает (так как нас нет в конфиге или его таблице).

Если же при отправке SYN’a нам сразу же приходит RST, ACK, то 179 порт вообще закрыт (это на всякий случай тоже проверяется в скрипте). Скрипт поддерживает парсинг результатов Nmap’a и некоторые другие настройки в подробности которых я вдаваться не буду (есть —help), да и всем интересующимся работой скрипта отвечу, если будут вопросы.

Итогом выборки из 5k роутеров (каждый из которых был проверен на валидность и запущенный 179 порт) стал неутешительный 0, возможно просто не повезло и были выбраны роутеры из хорошо администрируемых автономных систем, а возможно сейчас крайне редко можно встретить роутеры, позволяющие установить BGP соединение из вне, так что если этот фокус и мог прокатить пару лет назад, то сейчас уже точно надо искать другие метода (при условии, что эта выборка отразила точные результаты в целом, так как по 5000 судить тоже не очень правильно).

Проникновение через другие порты.

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

Так первой мыслью было просканировать добытый скоуп IP-адресов транзитных роутеров на открытые 179 (BGP) и 80 (HTTP) порты, а после, попробовать пробиться через веб-уязвимости на роутер, получив доступ к BGP службе. А если быть более точным, то нам необязательно заливать шелл, чтобы получить возможность конфигурировать BGP роутер, так как можно просто получить пароль, прочитав конфиги (как было написано выше), то есть нам будет достаточно даже какого-нибудь Path Traversal бага, который пусть и не даст возможность выполнять команды, но доступ к чтению конфигов обеспечит (конечно, если правами ограничений не будет).

Я особо сильно не искал, но пару раз мне попались серверы, где был относительно старый wordpress, через который можно было вообще залить шелл, и осуществить листинг дерикторий и файлов через баги в старых плагинах. На втором была скуль инъекция при логине (!), раскрутив которую можно было получить доступ к админке, в которой также можно было просматривать файлы на сервере. Вообще сайты провайдеров почему-то очень щедры на разные дыры в вебе.
Но это только 80 порт, при желании можно сканить и любые другие, часто бывало, что были одновременно открыты 179 и 22, на котором порой была бажная версия OpenSSH.

Встраивание в уже созданную BGP сессию.

Ну и сразу стоит оговорить результат — мы сможем менять маршруты, но не будем управлять каким-то роутером, то есть не проникнем к нему, а просто повлияем на его данные (чем и является основная цель проникновеня в BGP маршрутизаторы).

Тут можно использовать обычные IP Spoofing + TCP hijacking атаки для того, чтобы попробовать направить все общение между двумя роутерами через нас. Для начала нам нужно определить цели, точнее нам известен айпишник какого-то BGP роутера, который очевидно общается с другими, так что возникает вопрос, как можно узнать его соседей? Это возможно сделать, например, с помощью Public Route Servers, где можно найти записи о том, от какого роутера к какому идет трафик, то есть можно косвенно определить соседа какого-нибудь роутера.

Далее есть момент, что большинство новых ядер linux делают эти атаки практически непроводимыми, так как значение seq при соединении TCP сильно рандомизируется. Но если ядро старое (1.2.x или более раннее), то значение примерно расчитывается. Но и даже у более новых версиях ядра часто бывают кривые настройки протокола IP, позволяющие перенаправить TCP соединение через себя, то есть позволяющие source routing.

Постэксплуатация.

После того, как был получен доступ к роутеру все будет зависеть от настроек его соседей. Есть вероятность, что этому роутеру доверяют все его соседи, а им — их соседи и тп, так можно несанкционированно поменять пути из целых сетевых сегментов и манипулировать огромными объемами трафика. А возможно, что через этот роутер можно будет изменить пути только в сети, в которой он находиться (или в автономной системе этого роутера), но и это на самом деле не такой и плохой результат, даже если сеть (или АС) небольшие.

Для начала надо определить, из каких AS у нас наиболее вероятен перехват трафика, а это, как правило, соседние AS относительно той, в которой находиться BGP-роутер. Принадлежность определенного IP к AS и соседи определенной AS могут быть получены различными сервисами, например, тот же ipinfo.io. Еще есть интересные сервисы, такие как asnmap.com или bgplay.

Интерфейс BGP роутера — консоль с ограниченными, определенными командами для управления и конфигурирования текущего BGP демона и некоторых прилагающихся сетевых сервисов. То есть попав на этот интерфейс мы можем в реальном режиме без каких-либо перезапусков и перезагрузок менять конфигурацию bgp-демона, хотя если попасть в файловую систему роутера, то можно и поменять конфиг с его перезапуском.

Перенаправление трафика из других (соседних) AS.

Сначала хочется заметить, что под «нашей» AS будет подразумеваться AS к BGP роутеру которой был получен доступ. А также некоторых особо удачных для нас ситуациях мы сможем перехватывать трафик далеко не только соседних AS, в основном зависит от того, насколько крупный провайдер той AS BGP маршрутизатор которой стал досутпен для контроля, ведь чем крупнее провайдер, тем больше к нему доверия и его влияния (связей с другими AS).

Представим такую схему топологии АС (AS4 — АС, роутер которой (R4) стал подконтролен атакующему, внутри каждой АС указан диопазон, который она анонсирует другим, то есть за который она отвечает):

На этой схеме все ясно, только стоит уточнить, что диопазоны адресов внутри каждой AS — это диопазоны которые они анонсируют дургим, только у AS4 указан диопазон, который мы будем анонсировать (а до этого анонсировался 14.0.0.0/8).

Чтобы перенаправить трафик, предназначенный для AS3 (точнее для ее сети 13.0.0.0/8), нужную нам точку (R4 c адресом, например, 14.0.0.1) надо ввести соответствующие команды на роутере, но заглянув вперед становится понятно, что есть проблема дальнейшей передачи трафика в случае, если мы не контролируем сам роутер (кроме bgp сервиса). Если же у нас под контролем весь роутер, то можно просто направить весь перехватываемый трафик через таблицы маршрутизации.

Иначе же нам надо пойти немного другим путем: надо поднять на другом компе (с адресом 15.0.0.1, например) еще один bgp-сервис (назовем его R5), который сконфигурировать на соединение с контролируемым роутером (R4). Далее надо от нашего BGP сервиса R5 начать анонсировать, будто мы обслуживаем сеть 13.0.0.0/8, эти анонсы будут приниматься роутером R4 и ретранслироваться его соседям (которые, если им буду позволять фильтры будут транслировать это своим соседям и так по цепочке).

То есть если какие-то фильтры не будут ограничивать подобные анонсы, то вполне вероятно, что для большинства компьютеров трафик к сети 13.0.0.0/8 будет идти на R4, а оттуда нам. Весь трафик, предназначенный для это сети идти к нам не сможет по причине того, что от некоторых AS путь до нас будет длиннее, чем до реальной сети 13.0.0.0/8. Так же стоит учитывать тот факт, что наши анонсы не будут приниматься роутерами, если они равноправны с предыдущими анонсами AS3.

В этом случае нам придется прибегнуть к такой хитрости: мы станем анонсировать 13.0.0.0/7, как нашу сеть, а это сделает так, что уже весь трафик, предназначенный этой сети, будет идти к нам, так как от нас анонсируется более узкий префикс (если конечно, фильтры другие роутеров будут эти анонсы пропускать).
Итак, нам надо запустить bgp сервис (я использовал bgpd из Quagga), со следующим конфигом:

hostname bgpd-R5
password pswd
enable password pswd

router bgp 5
 bgp router-id 14.0.0.1
 network 13.0.0.0/8
 neighbor 14.0.0.1 remote-as 4
 neighbor 14.0.0.1 ebgp-multihop
 neighbor 14.0.0.1 next-hop-self
 neighbor 14.0.0.1 timers 5 5

neighbor 15.0.0.1 remote-as 100
 neighbor 15.0.0.1 ebgp-multihop
 neighbor 15.0.0.1 next-hop-self
 neighbor 15.0.0.1 timers 5 5

Эти команды устанавливают контролируемому роутера сеть, за которую он (якобы) отвечает, номер соседней АС и адрес роутера, который на ней стоит, также выставляется режим multihop, если эти роутеры не соединены напрямую (а они не соеденины напрямую) и самое главное — в конфиге R5 указывается наш роутер, как следующий на пути к сети 13.0.0.0/8. После этого, если на R1 и не стоит никаких фильтров, то траф, предназначенный для AS3 пойдет к нам.

И еще раз стоит заметить, что если же трафик не пошел, то дело либо в фильтрах, либо в приоритете, если второе, то можно попробовать указать не всю сеть 13.0.0.0/8, а только ее часть 13.0.0.0/7, тогда несмотря на фиизчекое положение AS4 трафик большинство трафика для сети 13.0.0.0/8 будет идти именно к ней.

Теперь на роутере R5 прописать таблицу маршрутизации, куда сплавлять трафик для сети 13.0.0.0/8, можно его обрабатывать на этой же машине, а можно посылать другой. Для этого можно либо вручную поменять таблицу маршрутизации, либо запустить прилагающийся к Quagga демон zebra c таким конфигом:

hostname R5
password p@ssvv0rd
enable password p@ssvv0rd

interface lo
 ip address 127.0.0.1/32

interface R5-eth0
 ip address 13.0.0.0/8

Далее весь траф на нашей машине 15.0.0.1 будет приходить на интерфейс eth0. Тут уже можно делать с трафом все. Самое обыденное — фишинг, если мы знаем, что в сети 13.0.0.0/8 работает сайт www.site.com на серваке с айпишником 13.0.0.123, то на машине, обрабатывающей траф можно запустить веб-сервер, где создать виртуальный хост www.site.com и отдавать свои ответы на запросы этого сайта. Подобное у меня получилось провернуть уже не только на тестовой площадке.

Был получен доступ к одному из роутеров какого-то небольшого провайдера, в AS которого был хостинг сайтов, айпишник одного из них я и «позаимствовал», то есть черзе некоторое время различной правки конфигов и перезапуска BGP демона и собственного веб-сервера, который должен был заменить веб-сервер того сайта, я уже через 3-го провайдера обновлял страницу и спустя небольшое время вместо реального сайта попадал на подстроенную мной страницу.

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

Итог.

Если подытожить, то сейчас уже не так все просто, как это было еще год-два назад, но способы как-то воздействовать на трафик в глобальной сети все же есть и работают. Для меня было тяжелее всего получить в доступ роутреы (одной из причин этому была блокировка доступа к «общению» с этими роутерами из вне, так что приходилось тупо искать нужные и вручную пытаться в них попасть), чтобы можно было с ними что-то делать, а уже их натсройка и тестирование перехвата трафика — относительно быстрый и не особо сложный процесс. А вот с его модификацией можно повозиться, особенно если это какой-нибудь нестандартный трафик, нестандартного протокола, а втроить тот же iframe в обычный http траф трудностей особых может не вызвать, не говоря уже об обычной подмене.

Скрипт можно скачать здесь

По материалам сайта Damagelab.org