The Label Distribution Protocol, initially specified in the RFC 3036, is a signaling protocol for distributing labels for a label switched path in an MPLS network. In 2007 RFC 5036 was released and replaces the old specification. LDP serves a set of procedures and messages by which Label Switched Routers (LSRs) establish Label Switched Paths through a network by mapping network routing information to data-link layer switched paths. The procedures consist of four kinds of functions: discovery functions, session management, advertisement and notification.
Trust Model
LDP uses TCP to establish sessions between two LSRs. UDP is used for basic operations like discovery mechanisms which are periodically sent over the network to a well-known discovery port for all routers of a specific subnet. As these are sent to the “all routers on this subnet” group multicast address, with regard to the discovery process all routers on the local link are regarded trustworthy.
Security Controls Inherent to Technology
To protect the authenticity and integrity of LDP messages, LDP supports the TCP MD5 signature options described in RFC 2385. It has to be activated at the LSRs and may protect the messages by validating the segment by calculating and comparing the MD5 digest. To use the MD5 option a preconfigured password on each LSR is necessary.
Abusing LDP
Loki contains a universal LDP module, written in python. It implements the most common used LDP packet and data types and can be used to participate in the LDP discovery process, as well as establish targeted LDP sessions for advanced signaling. If such a targeted session is established, the tool starts a background thread which sends keep-alive packages to hold the connection open and the signaled data valid. To create such signaling data e.g. EoMPLS virtual circuits signaling, the module provides build-in data types which can be merged to the appropriated signaling packet.
An Example for signaling EoMPLS virtual circuits
The peer is a Cisco 3750ME was configured, but not activated virtual circuit:
Loki is the used to establish an LDP session and to send the necessary signaling information:
First Loki needs to take part in the LDP discovery process; this is done by activating the Hello-Thread via clicking on the “Hello” button. Next the remote host tries to connect the attacks host via TCP, so Loki needs to listen for that incoming connection; this is done by activating the Listen-Thread via clicking on the “Listen” button. Once the Connection is established, the remote Host will show up in the Host-List. The next step is to configure the LDP update message, which defines the signaling message to publish to the remote host. In this case I generate a LDP Label-Mapping-Message. In the end I send the prepared update message by selecting the designated host from the host list and clicking on the “Update” button.
After sending the LDP Label-Mapping-message the configured virtual circuit is activated on the remote side:
So, I activated the virtual circuit and mapped it to a label defined in the update message. A tool like mplstun could be used to set up a valid endpoint on the attacker’s side.
Loki’s MPLSmodule is designed to relabel specified MPLS traffic with a given label. It can be used to manipulate the transport label and change the destination of the packet, or to redirect traffic into another MPLS-VPN. The module automatically detects all MPLS labeled traffic on the wire and let the user easily set up relabeling rules. It is possible to add a tcpdump filter to the relabeling rule, if the module should only redirect some special kind of traffic. Last but not least one can define which label in the label stack should be modified.
It should be noted that this attack requires that the attacker has access to the traffic path of the respective packets. The setup for this example looks like this:
The attacker is in a Man-in-the-Middle situation inside the data path between Provider Edge 1 and Provider Edge 2 in the MPLS backbone.
On PE1 the label association for the both MPLS-VPNs looks like this:
Console: Cisco 3750 Label Overview
Which means outgoing traffic for customer RED’s location 2 is tagged with the MPLS label 18. In the other direction, traffic tagged with MPLS label 20 is sent out to customers RED’s location 1. The same for customer GREEN, outgoing traffic for location 2 is tagged with label 19, incoming traffic with label 21 is sent out to location 1. Both customers use the same IP address space for the two locations, which is possible, as I got a logical separation in the routing of each customer.
Let’s further assume I got a client with the IP address 192.168.113.100 connected to customer GREEN’s location 2. So, it’s possible to ping this client from PE1 in the context of customer GREEN. I need to specify the virtual routing and forwarding context of customer GREEN to use the customer’s specific routing table. If I run the same command in the context of customer RED, no response will be visible:
Next the attacker starts to redirect traffic from PE1 to PE2 in the backbone from customer RED’s MPLS-VPN to customer GREEN’s MPLS-VPN and redirect traffic from PE2 to PE1 in the backbone from customer GREEN’s MPLS-VPN to customer RED’s MPLS-VPN by Loki like this:
Once the redirection is in place it is possible to ping my assumed host from both, customer RED’s and customer GREEN’s context:
So this actually means that with right position in the traffic path and the right tool (e.g. Loki) an attacker can easily redirect a given site’s traffic of a given customer to a different destination (provided the IP addresses are the same which presumably is a valid assumption when it comes to addresses like 10.1.1.1 or 192.168.10.1).
Недавно ко мне обратились грамотные люди с просьбой проконсультировать по теме временного изменения маршрутизации трафика в сети одного очень крупного провайдера интернет Восточной Европы. Парни очень хотели перенаправить трафик ASIC аппаратов на их кастомный майнинговый пул. Кроме этого им ещё очень хотелось временно перенаправить весь трафик по теме крипты на свою площадку. Давайте посмотрим, какие варианты возможны для этого кейса.
По моему предыдущему опыту перво-наперво стоит провести анализ транзитного сетевого трафика с помощью любого сетевого анализатора в «неразборчивом» режиме работы сетевой карты (promiscuous mode). В качестве сетевого анализатора для подобных целей замечательно подходит WireShark или CommView. Чтобы выполнить этот первоначальный этап, мне обычно хватает и пары часов работы. По прошествии этого времени у меня как правило накапливается достаточно много данных для проведения анализа перехваченного трафика. И в первую очередь при его анализе я обращаю внимание на следующие протоколы:
протоколы коммутации (STP, PVST+, CDP, DTP, VTP, и им подобные)
протоколы маршрутизации (LDP, BGP, EIGRP, OSPF, IS-IS и другие)
Что касается открытых протоколов, – вероятность того, что они попадутся мне во время сбора пакетов проходящего мимо трафика в коммутируемой сети, достаточно мала. Однако, если такого трафика много, то в обследуемой сети явно наблюдаются проблемы в настройках сетевого оборудования.
Во всех остальных случаях у меня присутствует возможность проведения красивых сценариев:
классическая MITM (Man in the middle) в случае, когда используется ARP, DHCP, RIP или LSP
получение роли корневого узла STP (Root Bridge), что позволяет перехватывать трафик соседних сегментов
перевод порта в магистральный режим с помощью DTP (enable trunking), позволяет перехватывать весь трафик своего сегмента сети
Для реализации этих сценариев взаимодействия с сетевыми протоколами коммутации я обычно использую такой замечательный инструмент как Yersinia.
В процессе анализа трафика я часто выявляю пролетающие мимо DTP-пакеты (смотри скриншот). Тогда отправка пакета DTP ACCESS/DESIRABLE может позволить мне перевести порт коммутатора в магистральный режим. Дальнейшее развитие этого сценария позволяет мне прослушивать весь Ethernet сегмент этой сети.
После тестирования канального уровня я обычно переключаю внимание на третий уровень модели OSI. Дошла очередь и до проведения сценария взаимодействия через ARP-poisoning. Тут все просто, я очень люблю инструмент Ettercap NG, но всё дело в том, что в случае успешной реализации сценария ARP-poisoning в отношении всего доступного сегмента сети может наступить ситуация, когда MiTM компьютер по середине не справится с потоком поступающих данных и, в конечном счете, это может стать причиной отказа в обслуживании целого сегмента сети, что обязательно заметят. Поэтому наиболее правильным будет выбрать единичные цели, например, рабочие места администраторов и/или разработчиков, какие-либо определенные серверы (возможно контроллер домена, СУБД, терминальный сервер, bgp маршрутизатор и другие важные элементы сети).
Успешно проведенная мною ARP-poisoning позволяет получить в открытом виде пароли к различным информационным ресурсам – СУБД, каталогу домена (при понижении проверки подлинности NTLM), SNMP-community string, bgp пакеты UPDATE, пароли для сетевого оборудования с уровнем доступа level 15 и другие приятные вещи. В менее удачном случае я могу получить хеш-значения от паролей к различным системам, которые нужно будет постараться восстановить по радужным таблицам (rainbow tables), по словарю или методом «в лоб». Перехваченные пароли могут использоваться где-то ещё на других сайтах в сети интернет, но впоследствии это также необходимо мне подтвердить или опровергнуть.
Кроме того, мне стоит проанализировать весь перехваченный трафик на присутствие CAV2/CVC2/CVV2/CID/PIN, передаваемых в открытом виде. Для этого обычно пропускаю сохраненный .pcap файл с дампом трафика через NetResident и/или 0x4553-Intercepter. Второй, кстати, замечательно подходит для анализа накопленного трафика в целом.
Встраивание в уже созданную BGP сессию и реализация bgp hijacking
Сразу стоит обозначить результат — поменять маршруты движения трафика, но не управлять каким-то bgp роутером через консоль, то есть не проникая в его систему управления от слов совсем и никак, просто модифицировать данные его таблиц маршрутизации.
Для этого я использую обычная реализацию IP Spoofing + TCP hijacking = BGP Spoofing сценария для того, чтобы перенаправить все общение между двумя bgp роутерами через свой хост, то есть осуществление полного перехвата и фильтрации BGP сессий этих роутеров. Об инструментах, которые позволяют сделать это внутри транзитной сети поговорим немного позже.
Реализация BGP spoofing сценария через консоль роутера
После того, как был получен доступ к bgp роутеру, конечный результат реализации сценария bgp hijacking будет зависеть от настроек его bgp соседей. Есть вероятность, что этому bgp роутеру доверяют все его bgp соседи, а им — их bgp соседи и так далее, так можно незаметно поменять пути маршрутизации и сделать bgp обход целых сетевых сегментов, манипулируя при этом огромными объемами сетевого трафика в Интернет.
А возможно, что через этот bgp роутер можно будет изменить пути только в сети, в которой он сам и находиться или в автономной системе этого bgp роутера, но и это на самом деле не такой уж и плохой результат, даже если сеть или Автономная Система небольшие.
Для начала надо определить, из каких AS у нас наиболее вероятен перехват трафика, а это, как правило, соседние AS относительно той, в которой находиться BGP-роутер. Принадлежность определенного IP к AS и соседи определенной AS могут быть получены различными сервисами, например, тот же bgp.tools либо простым выполнением команды show ip bgp neighbors на роутере.
Еще есть интересные сервисы, такие как asnmap.com или bgplay от RIPE. Интерфейс BGP роутера — консоль с ограниченными, определенными командами для управления и конфигурирования текущего BGP демона или устройства и некоторых прилагающихся сетевых сервисов. То есть попав на этот интерфейс можно в реальном времени без каких-либо перезапусков и перезагрузок менять конфигурацию bgp процесса или всего устройства, хотя если попасть в файловую систему роутера, то можно и поменять конфигурацию с его перезапуском.
Какой сценарий выбрать для понимания bgp в крипте?
Эксплуатация уязвимостей протокола BGP в контексте криптовалют и блокчейнов — это довольно специфическая область, которая требует углубленного изучения. Сейчас я расскажу о том, какие сценарии могут быть наиболее востребованы в контексте процессинга крипты.
В сети блокчейнов первого уровня маршрутизация между нодами использует протокол BGP для установления соединений между ними через Интернет, например, Bitcoin или Ethereum. Новые блоки, содержащие транзакции, также распространяются по сети Интернет при помощи BGP, и оно играет важную роль в синхронизации состояния всего блокчейна. BGP помогает поддерживать согласованность состояния блокчейна между всеми нодами.
Децентрализованные биржи (DEX) также осуществляют обмен ордерами при помощи BGP и стабильность его работы влияет на эффективность маршрутизации ордеров между различными DEX. BGP также может помочь в распределении ликвидности по различным пулам.
Так какой же сценарий выбрать?
Выбор конкретного сценария зависит от ваших целей. Если вы новичок и только начинаете изучать BGP в контексте криптовалют, то лучше начать с простых сценариев, таких как маршрутизация в сети Bitcoin и управление bgp роутером через консоль. Но для этого Вам предстоит сначала найти этот роутер и получить к нему доступ ранее озвученными методами.
Если вы уже разрабатываете блокчейн-приложения, то вам будет полезно изучить, как BGP используется для масштабирования и создания децентрализованных сетей. Тажке если вы занимаетесь администрированием блокчейн-инфраструктуры, то вам необходимо понимать, как BGP используется для обеспечения надежности и доступности сети. BGP — это сложный протокол, и его полное понимание требует времени и усилий.
Начните с простых концепций и постепенно углубляйтесь в более сложные темы. Для воздействия на таблицу маршрутизации bgp роутера без доступа в его консоль вам понадобится специализированное программное обеспечение, например ciag-bgp-tools-1.00.tar.gz или Insinuator (ex loki).
Хотите более конкретные рекомендации? Расскажите о ваших текущих знаниях и целях мне в личном сообщении, и я смогу подобрать для вас наиболее подходящий сценарий. Какие из этих сценариев вы хотели бы изучить подробнее?
Как показывает стабильный рост числа инцидентов, система Интернет-маршрутизации не так безопасна, как мы бы того желали.
Давайте для начала разберемся, что собственно представляет из себя интернет маршрутизация. Маршрутизация основана на автономных системах (AS), которые обмениваются префиксами (диапазоны IP адресов) используя Border Gateway Protocol (BGP). Автономные системы это первые и главные интернет провайдеры (ISP). Но некоторые организации подключены к двум или более провайдерам одновременно. IP адреса, которые ISP выдают своим клиентам, сгруппированны в относительно небольшое число префиксов, покрывающих большие адресные блоки. Эти префиксы «анонсируются» или «рекламируются» через BGP в AS. Префиксы идут от AS к AS, так что в конце концов весь Интернет знает, куда отсылать пакеты с данным адресом назначения.
Понятие BGP (Border Gateway Protocol, протокол граничного шлюза) было более осязаемо 20 лет назад, когда слово «шлюз» использовалось для название того, что мы сегодня называем маршрутизатор. Итак BGP это протокол, используемый между пограничными маршрутизаторами – роутерами, которые находятся на периферии соседствующих автономных систем. AS представляют собой иерархию, которая выглядит примерно таким образом:
Между поставщиками Интернет-услуг (ISP) и потребителями услуг показаны отношения сверху вниз: пользователь платит провайдеру. Пунктирные линии показывают отношения, где трафик обменивается без участия денежных операций. При такой экономической модели трафик идет вверх по иерархии, затем в сторону и в конце концов вниз. Маршруты, которые ведут в сторону, затем вниз или вверх, а потом опять в сторону возникают только тогда, когда кто-либо предоставляет бесплатные услуги, что случается довольно таки редко.
Таким образом, AS 6 может идти к AS 5 по маршруту 6 – 3 – 1 – 2 – 5, где AS 6 платит AS 3, который в свою очередь платит AS 1, при этом AS 5 оплачивающем услуги AS 2. Получается, что все ISP получают деньги, даже несмотря на то, что AS 1 не платит AS 2. Однако маршрут 6 – 3 – 4 – 2 – 5 не действенен для доставки трафика от AS 6 к AS 5. В этом случае, AS 4 пришлось бы платить AS 2 за этот трафик, но так как AS 3 ничего не платит AS 4, получилось бы, что AS 4 предоставляет свои услуги бесплатно. С другой стороны, маршрут 6 – 3 – 4 – 8 от AS 6 к AS 8 работает нормально, так как AS 8 это клиент AS 4 и следовательно AS 8 оплачивает AS 4 входящий трафик.
Сам по себе BGP не в курсе денежных проблем. В своем дефолтном состоянии BGP поверит всему и с радостью предоставит услуги бесплатно. Чтобы этого избежать, BGP-маршрутизаторы должны обладать фильтрами, которые удостоверяются, что только корректная информация передается по протоколу. В дополнении, «реклама» префиксов, являющаяся способом BGP привлекать входящий трафик, должна высылаться только в соответствии с бизнес отношениями.
Зная то, как автономные системы взаимосвязаны с другими автономными системами, будь то клиент/ISP соединение или равноправный информационный обмен, можно точно узнать, как может быть достигнута искомая точка назначения из любого источника. Также, необходимо знать какой диапазон IP адресов принадлежит к какой AS. Расчеты перемаршрутатизации после неудачи несколько усложняют дело, но это не слишком большая проблема.
Знание графа сети и отношений префиксов AS позволило бы создать фильтры, которые утверждали бы информацию, получаемую через BGP и отклоняли некорректную или ложную информацию. Есть специальные базы данных маршрутизации, где отмечается такая информация. К сожалению, не всегда удается пополнять их и информация зачастую ненадежна. IETF и региональные регистраторы, которые раздают IP адреса и AS номера, сейчас работают над базой данных и инфраструктурой сертификатов, которые как раз позволили бы это делать. Хотя пока это только разработки.
Как бы то ни было, где же эти сервера?
Операторы сети просто напросто сами не знаю где находится сервера CNN, в Атланте или в Пекине. И когда приходит обновление BGP, утверждая последнее, у провайдеров — точнее у их роутеров, нет другого выбора: им приходится устанавливать обновления и посылать трафик в новом направлении. 999 раз из 1000 перемаршрутизация это вполне обыденное явление. Но 1 раз это все-таки либо ошибка, либо какого-нибудь рода атака.
В 1990 году, случился как раз такой инцидент, который послал трафик в Китай. При этом сетевые инженеры потратили часы, решая проблему. На сегодняшний день подобные случаи это обычное дело. В результате ряд систем мониторинга доступен по всему Интернету. И они постоянно контролируют ситуацию, которая не может остаться незамеченной.
Это ведет к неприятному состоянию когнитивного диссонанса. С одной стороны, непостижимо, как Интернет-маршрутизация может быть столь наивной. С другой стороны, ведь в большинстве случаев она работает. Исправление ситуации было бы делом непростым, дорогим и окупилось бы далеко не сразу.
(Я пошел на мое первое IETF собрание в 2002 году, когда в разработке находилась система маршрутизации inter-AS. Я помню у нас был ланч в пицеррии в Атланте. Было 20 человек из Cisco, которые все время неистово изображали топологию сетей на салфетках. К этому времени уже было два предложения для того, чтобы сделать BGP более безопасным: S-BGP от BBN и soBGP от Cisco. Вот уже почти десять лет прошло в спорах о том, какое из этих предложений лучше и вообще стоит ли что-нибудь предпринимать… Но результатов как не было так и нет…)
Не стоит недооценивать сложности, возникающие при обеспечении безопасности Интернет маршрутизации. Что если сертификат используемый S-BGP или soBGP истечет? Если это означает, что соединение будет прервано, пожелаем успехов в скачивании нового сертификата…
Маршрутизация это критическая система реального времени. В таких системах традиционная модель отключения не подтвержденных систем не работает. Когда система работает, важно использовать механизмы безопасности, чтобы не позволить хакерам подорвать ее работу. В то же время важно, чтобы сами механизмы безопасности не вставали на пути исправления проблемы, когда происходят сбои в системе или сбой близок. К сожалению, существующие меры безопасности не имеют такого баланса.
Спасает маршрутизацию то, что большинство ISP тщательно фильтруют то, что клиенты им присылают. И если я настрою свой BGP-маршрутизатор сообщить моему провайдеру, что я владелец IP адреса Windows Update, то мой ISP должен проявить бдительность и игнорировать подобную BGP «рекламу». И так как между ISP и клиентами имеют место быть бизнес-отношения, обе стороны заинтересованы быть в курсе всех последних изменений в префиксах.
Однако как только некорректная информация перешла границу клиент/провайдер, она быстро распространится по равноправным соединениям практически не встречая никаких преград на своем пути. Это происходит потому, что на данный момент нет никакой официальной базы данных маршрутизируемой информации. Единственный способ ISP отфильтровать равноправных ISP – это постоянный обмен обновленным данным по принципу тет-а-тет. Но по причине постоянной смены клиентов и введения новых префиксов, большого количества пиров у крупных ISP — это способ просто неосуществим.
Китайская маршрутизация
Так что же на самом деле случилось в Китае, что повлекло перенаправление маршрутов 15% Интернет-префиксов – а не 15% трафика – на эту страну в апреле? И был ли это несчастный случай или что-то более опасное? Я не был в офисе China Telecommunications Corporation и не наблюдал за случившимся лично, поэтому не могу сказать наверняка, был ли это дьявольский и совершенный план или очень глупая ошибка сетевого инженера. Но я порассуждаю на эту тему позже, не только из-за принципа «Лезвия Хэнлона» («Никогда не приписывайте злонамеренности тому, что вполне может быть объяснено глупостью»).
Обычный сбой протокола BGP — утечка всей таблицы маршрутизации. В настоящее время существует 341 000 Интернет-префиксов, образующих Интернет, и чтобы работать со всеми ними BGP-маршрутизатору нужно иметь их все в таблице маршрутизации. Если по какой-либо причине BGP-маршрутизатор не имеет никаких фильтров, он просто отправляет всю копию этой таблицы всем маршрутизаторам в соседних автономных системах, к которым он подключен.
Утечка всей таблицы – ошибка, которая случается достаточно часто, и, казалось бы, это и произошло в Китае. Но вот что могло иметь место на самом деле.
После обновления фильтра, он может перестать функционировать. Обычно, такое случается с фильтром «максимального префикса» последней инстанции – это останавливает сессию BGP если получено большее количество префиксов нежели возможно. Но, даже не беря в расчет это, подобная утечка должна была быть не настолько разрушительной, потому что обход через (например) Китай означает преодоление дополнительных автономных систем, а BGP предпочитает долгим путям короткие. Это обусловлено тем, что для каждого префикса автономные системы на пути к адресу назначения записываются в «AS путь» — самый короткий путь по количеству автономных систем.
Однако простая утечка целой таблицы, или хотя бы большей ее части, в данном случае была осложнена любопытным проектным решением China Telecom. Это решение наводит на мысль, что China Telecom очистила AS путь от всех префиксов, которые утекли и таким образом наилучший путь к американским сайтам начал пролегать через китайского провайдера. С точки зрения клиентов China Telecom, адрес назначения, например, CNN, находился внутри сети China Telecom, а не просто достигался через эту сеть.
Поэтому относительно многие автономные системы начали отдавать свой трафик Китаю. Освобождение AS путей случается когда информация из BGP экспортирована в другой протокол маршрутизации, используемый локально, а потом возвращается обратно в BGP. Такая практика кажется опасной из-за подобного обсуждаемого здесь ранее инцидента. К тому же нет никакого логичной причины зачем делать это – есть правда несколько нелогичных – но я не могу допустить мысли, что такое могло произойти совершенно случайно.
Таким образом утечка целой таблицы BGP или ее части сама по себе не настолько подозрительна, хотя провайдерам размера China Telecom следовало бы в этом разбираться лучше. Но то, что AS пути были очищены, можно расценить как причину для умеренного подозрения.
Если бы я был еще большим параноиком, я бы, тем не менее, начал искать в Интернете неправильные префиксы/комбинации автономных систем, которые случайно проявлялись бы на некоторое время. Тот, кто хочет перехватить трафик, наверняка бы создал несколько серверов и BGP-маршрутизаторов в дата-центрах с хорошей связью, а потом попытался бы посмотреть, какой Интернет-провайдер дает сбой в фильтрации. С таким провайдером нацеленная атака могла бы вызвать перемаршрутизацию трафика гораздо дольше чем на 18 минут. Перенаправление префиксов Северной Америки внутри самой Америки выглядело бы менее подозрительно, чем перенаправление их в Китай.
Пока мы ждем появления какой-то формы безопасности для BGP, мы все должны задуматься о том, что бы случилось, если бы адреса удаленных систем, с которыми мы общаемся, были перенаправлены и наш трафик был бы перехвачен. Шифрование и закрытая аутентификация типа HTTPS или VPN защищают от этого. Однако есть проблема и в шифровании: центрам выдачи сертификатов нельзя так уж доверять. А как справиться с этим – расскажу в следующий раз.
