The another Loki‘s usage case shows how to inject MPLS-VPN routing information (as described in RFC4364) into a MPLS Provider Edge router.
The peer again is a Cisco 3750ME with a MPLS-VPN virtual routing and forwarding table associated with the customer ‘RED’:
Loki is then used to inject the MPLS-VPN routing information:
Before setting up the session we need to overwrite the default session parameters with our custom BGP capabilities. This is done by filling in the optional connection parameters.
Next the AS number and the hold timer needs to be set. At last the target host is missing, which in this example is the host with the IP address 10.10.10.1. After clicking on “Connect” a session setup is performed.
If loki is able to establish the connection, a background keep alive thread is started, which sends an BGP keep alive packet every hold time / 4 seconds.
The next step is to assigns the BGP update message.
This message defines, which routing information to publish to the connected host. In the example case we build up a RFC4364 Multi-Protocol-BGP update packet, which says we are announcing the network 192.168.113.111/32 with the route distinguisher 100:0, which should be forwarded to the next hop 10.10.10.10. In the end we send the prepared update message by clicking on “Update”.
After publishing the routing information, the routers virtual routing and forwarding table for the customer ‘RED’ looks like this:
One can see the new route for the host 192.168.113.111 pointing to our attack host (10.10.10.10). Click here to dowload Loki.
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 kind 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.
Attacking 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 we generate a LDP Label-Mapping-Message. In the end we 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 we 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. Click here to download 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 защищают от этого. Однако есть проблема и в шифровании: центрам выдачи сертификатов нельзя так уж доверять. А как справиться с этим – расскажу в следующий раз.
Переводы на криптокошельки, связанные с нелегальной деятельностью, составили 0,14% от всех блокчейн-транзакций
Вслед за Facebook Audience Network интернет-гигант Google AdSense обратил свою волшебную рекламную палочку в сторону криптовалют и ряда других финансовых продуктов. $40,9 млрд в криптовалютах были получены нелегально в прошлом году, согласно отчету аналитической компании Chainalysis. Сумма средств, переведенных на криптоадреса, которые аналитики связывают с нелегальной деятельностью, снизилась по сравнению с предыдущим годом. В предыдущем периоде объём таких транзакций составляла $46,1 млрд. Абракадабра, и уже в июне реклама бинарных опционов, криптовалют, валютных бирж, криптообменников и контрактов на разницу цен (CFD) в сервисах Google оказалась под запретом. Зачем Google Ads наложил заклятие на крипторекламу и как сообщество реагирует на подобные трюки?
Вооружение предупреждением
«Нерегулируемые или спекулятивные финансовые продукты» — так обозначило руководство Google AdSense перечень не подлежащих рекламе категорий. На прямой вопрос о причине внесения изменений в рекламную политику Google AdWords в отношении финансовых продуктов в пресс-службе «Google Россия» мне ответили: «Это связано с тем, что в последнее время мы наблюдаем появление новых сложных финансовых продуктов и считаем необходимым ввести дополнительные меры по защите пользователей». Сумма $40,9 млрд — это предварительная оценка, основанная на данных, имеющихся у аналитиков на текущий момент. По мере того как будут выявляться больше адресов, помеченных как незаконные, связанные с ними транзакции за прошлый год будут включены в итоговую сумму. По прогнозу Chainalysis, через год она может достигнуть уже $51 млрд.
В сложившейся ситуации, несомненно, Google AdSense, как и Facebook Audience Network чуть ранее, в равной степени защищают и пользователей, и себя. Ограничения на рекламу — это своего рода превентивные меры, которые корпорации используют в качестве «волшебного щита» от финансовых регуляторов. В случае обнаружения схем дроповодов или прямого нарушения законодательства, надзирающие органы и регуляторы могут прийти и наложить штраф, и на рекламную площадку в том числе.
На данный момент как блокчейн-проекты и ICO, так и площадки вроде Google Ads и Facebook Audience Network вынуждены лавировать в отсутствие определенной, адекватной законодательной базы. Фактически у нас сегодня нет ни закона, ни конкретных запретов от финансовых регуляторов. Ни на международном уровне, ни тем более в России. Юридических обоснований на запрет финансовых инструментов просто не существует. От того интернет-гиганты и вынуждены ориентироваться в этой мутной воде и защищать и свою спину, и своих пользователей. Стоит заметить, что под запрет попадают не только криптовалютные проекты — ранее в истории запрещались и форекс-брокеры, и фармацевтические компании, и азартные игры. Рекламщики Google AdSense с настороженностью относятся и к реабилитационным центрам, предлагающим лечение от разного рода зависимостей. Незаконные переводы в ээтом году составили 0,14% от общего объема блокчейн-транзакций, говорится в отчете. Годом ранее показатель равнялся 0,61%.
С другой стороны, не все гиганты выбирают осторожную стратегию защиты. Например, с недавних пор за размещение рекламы на всех проектах такого весомого игрока, как Mail.Ru Group, и в партнерской сети компании можно заплатить в биткоинах или же Bitcoin Cash (BCH). Хозяева сетевых площадок смогут и получать доход в криптовалюте. О возможности внедрения биткоина в свою платежную сеть объявил Amazon — по неофициальным данным сервис может создать собственную криптовалюту и выйдет на блокчейн-рынок. Однако, в схемах дроповодов или отмывании денежных средств, полученных нелегално, используются все типы активов. Транзакции, связанные с нарушением санкций, перешли в основном на стейблкоины.
Дроповод своё возмёт
Что же до сообщества, то с выводом Google AdSense из набора инструментов крипторекламщика ситуация не станет плачевной. Упомянутая мной неопределенность в законодательной области здесь — в своем роде выгодный сумрак. Стандартные зарубежные площадки ограничивают возможность размещать рекламу определенного характера, и все начинают искать новые возможности. И, разумеется, находят. Подключают CPA-агрегаторы, создают свои СМИ и каналы, размещаются на специализированных криптомедиаплощадках, делают свои видеоканалы и так далее. Кстати, согласно вышеупомянутому ответу пресс-службы Google Ads, рекламные ограничения в некоторой степени затронут и видеохостинг YouTube.
С тех пор как Facebook Audience Network ввел запрет на рекламу ICO, у маркетологов лишь стало на один инструмент меньше. Проекты все так же проводятся, деньги собираются, жизнь маркетологов, и без того непростая, усложняется. Так же и запрет на крипторекламу на площадках Google Ads не смертелен и не убьёт на корню рекламу в индустрии. Наоборот, может стать весьма полезным скам-фильтром для быстро и мощно развивающейся криптоэкономики.
Одним из крупнейших игроков этого рынка на текущий момент аналитики называют китайский маркетплейс Huione Guarantee. По их данным, на площадке с начала двадцатых годов было проведено транзакций более чем на $70 млрд.
Исследователи предупредили о недостатках в программной реализации протокола BGP (Border Gateway Protocol), которые можно использовать для провоцирования отказа в обслуживании (DoS) на уязвимых одноранговых узлах BGP.
Уязвимости были найдены во FRRouting версии 8.4, популярном наборе протоколов интернет-маршрутизации с открытым исходным кодом для платформ Linux и Unix. В настоящее время он используется многими вендорами, включая NVIDIA Cumulus, DENT и SONiC, что создает риски для цепочки поставок.
Проблемы были выявлены в ходе анализа семи различных имплементаций BGP, проведенного Forescout Vedere Labs: FRRouting, BIRD, OpenBGPd, Mikrotik RouterOS, Juniper JunOS, Cisco IOS и Arista EOS.
Список обнаруженных недавно проблем выглядит следующим образом:
CVE-2022-40302 (6,5 балла по шкале CVSS) — out-of-bounds чтение при обработке искаженного сообщения BGP OPEN с опцией Extended Optional Parameters Length;
CVE-2022-40318 (6,5 балла по шкале CVSS) — out-of-bounds чтение при обработке искаженного сообщения BGP OPEN с опцией Extended Optional Parameters Length;
CVE-2022-43681 (6,5 балла по шкале CVSS) — out-of-bounds чтение при обработке искаженного сообщения BGP OPEN.
Наши эксперты пишут, что проблемы «могут использоваться нарушителем для провоцирования состояния отказа в обслуживании на уязвимых одноранговых узлах BGP, что приведет к сбросу всех сессий BGP и очистке таблицы маршрутизации, а сам одноранговый узел перестанет отвечать».
«Отказ в обслуживании может быть продлен на неопределенный срок путем многократной отправки искаженных пакетов. Основная причина — один и тот же уязвимый шаблон кода, скопированный в несколько функций, связанных с разными этапами анализа сообщений OPEN», — пишут наши исследователи.
К своему отчету наши аналитики приложили ссылку на опенсорсный инструмент BGP Fuzzer на основе Python, который поможет всем желающим протестировать безопасность BGP или найти новые проблемы в его различных реализациях.
«Современные реализации BGP роутеров по-прежнему имеют уязвимости, которые могут легко эксплуатироваться нарушителем, — говорят в Forescout. — Для снижения рисков использования уязвимых реализаций BGP, лучшей рекомендацией является как можно более частая установка патчей на устройства сетевой инфраструктуры».
