Skip to main content

BGP hijacks targeting cryptocurrency services still having success

 On 17 August 2022, a BGP spoofer was able to steal approximately USD 235,000 in cryptocurrency by employing a BGP hijack against the Celer Bridge, a service that allows users to convert between cryptocurrencies.

In this blog post, I discuss this and previous infrastructure attacks against cryptocurrency services. While these episodes revolve around the theft of cryptocurrency, the underlying attacks hold lessons for securing the BGP routing of any organization that conducts business on the Internet.

The BGP hijack of Celer Bridge

In a detailed blog post earlier this month, the threat intelligence team from Coinbase explained how the attack went down (Note: Coinbase was not the target of the attack). In short, the attacker used a BGP hijack to gain control of a portion of Amazon’s IP address space.

Doing so allowed it to impersonate a part of the Celer Bridge infrastructure, which was hosted by Amazon, and issue malicious smart contracts. These ‘phishing contracts’ stole the victim’s assets by redirecting them to the attacker’s wallet.

To ensure the BGP hijack would be successful, the attacker needed to make certain its malicious BGP announcements wouldn’t get filtered by an upstream network by taking two steps. First, it managed to insert bogus route objects (shown below) for QuickhostUK in AltDB, a free alternative to the IRR databases managed by RADB and the five RIRs. At this time, it is unclear whether QuickhostUK was also a victim of this attack.


irrd.log-20220817.gz:31106270-ADD 96126

irrd.log-20220817.gz:31106280-

irrd.log-20220817.gz:31106281-as-set:     AS-SET209243

irrd.log-20220817.gz:31106306-descr:      quickhost set

irrd.log-20220817.gz:31106332-members:    AS209243, AS16509

irrd.log-20220817.gz:31106362:mnt-by:     MAINT-QUICKHOSTUK

irrd.log-20220817.gz:31106392-changed:    crussell()quickhostuk net 20220816

irrd.log-20220817.gz:31106438-source:     ALTDB


irrd.log-20220817.gz:31147549-ADD 96127

irrd.log-20220817.gz:31147559-

irrd.log-20220817.gz:31147560-route:      44.235.216.0/24

irrd.log-20220817.gz:31147588-descr:      route

irrd.log-20220817.gz:31147606-origin:     AS16509

irrd.log-20220817.gz:31147626:mnt-by:     MAINT-QUICKHOSTUK

irrd.log-20220817.gz:31147656-changed:    crussell()quickhostuk net 20220816

irrd.log-20220817.gz:31147702-source:     ALTDB

Credit: Siyuan Miao of Misaka on NANOG list

Since network service providers build their route filters using these IRR databases, this step was necessary to ensure upstream networks wouldn’t filter the bogus announcements coming from QuickhostUK.

Secondly, the attacker altered the AS-PATH of the route so that it appears to be originated by an Amazon ASN (specifically AS14618). This also caused the route to be evaluated as RPKI-valid; more on that later.

After the hijack in August, I tweeted the following Kentik BGP visualization showing the propagation of this malicious route. The upper portion shows 44.235.216.0/24 appearing with an origin of AS14618 (in green) at 19:39 UTC and quickly becoming globally routed. It was withdrawn at 20:22 UTC but returned again at 20:38, 20:54, and 21:30 before being withdrawn for good at 22:07 UTC.

Kentik BFP Monitor’s view of the Amazon BGP hijack

Amazon didn’t begin announcing this identical /24 until 23:07 UTC (in purple), an hour after the last hijack was finished and more than three hours after the hijacks began. According to Coinbase’s timeline, victims had cryptocurrency stolen in separate events between 19:51 and 21:49 UTC.

Previous BGP hijacks against cryptocurrencies

The Celer Bridge attack wasn’t the first time that a cryptocurrency service was targeted using a BGP hijack. In April 2018, Amazon’s authoritative DNS service, the former Route 53, was hijacked in order to redirect certain DNS queries to an imposter DNS service, as illustrated below.

Amazon’s authoritative DNS service was hijacked to redirect certain DNS queries to an imposter DNS service, in April 2018

The imposter authoritative DNS server returned bogus responses for myetherwallet.com, misdirecting users to an imposter version of MyEtherWallet’s website. When users logged into their accounts (after clicking past the certificate error, ∗sigh∗), the cryptocurrency was drained from their accounts.

Within a couple of months of this incident, Amazon had published ROAs for their routes including those of its authoritative DNS service. This move enabled RPKI ROV to help offer some protection against such an attack in the future.

Since public DNS services like Google DNS peer directly with Amazon and reject RPKI-invalids, it would be difficult, if not impossible, to fool Google DNS like this again. If an attacker surreptitiously appended an Amazon ASN to the AS-PATH of its hijack route in order to render it RPKI-valid, it would be unlikely to be selected over the legitimate route from Amazon because of its longer AS-PATH length.

The BGP hijack against Amazon was not to be the last to target cryptocurrency.

Earlier this year there was another incident that involved the manipulation of BGP to target a cryptocurrency service. Attackers were able to make off with over USD 2 million in cryptocurrency by employing a BGP hijack against KLAYswap, an online cryptocurrency exchange based in South Korea.

Henry Birge-Lee and his colleagues at Princeton authored an excellent post on this incident. In this incident, the attackers went after the users of the KLAYswap cryptocurrency exchange by performing a BGP hijack of the IP space of a South Korean hosting provider (Kakao), as illustrated below.

BGP hijack of Kakao’s IP space. Image credit Henry Birge-Lee

This is because Kakao was hosting a javascript library that was loaded when users were on the KLAYswap platform. The BGP hijack enabled the attackers to impersonate Kakao and return a malicious version of this library redirecting user transactions to destinations controlled by the attackers.

So what can be done to protect against BGP hijacks?

While the incidents discussed above all involved the targeting of cryptocurrency services, the underlying issues are universal and can affect any organization that uses Internet-based services. In order to safeguard against attacks like these, BGP and DNS monitoring need to play a central role in your monitoring strategy. Additionally, strict RPKI configuration can also increase the difficulty for someone to hijack your routes, as I will explain.

BGP and DNS monitoring

DNS monitoring exists for the scenario that unfolded with MyEtherWallet in 2018. It uses agents around the world to check that queries for a specified domain return expected results. If a response contains something other than what was expected, it will fire off an alert.

In the case of last month’s Celer Bridge attack, BGP monitoring could have alerted that a new /24 of Amazon address space was being announced, although the forged Amazon origin may have caused it to appear legitimate.

However, when this new /24 appeared with an unexpected upstream of AS209243 (Quickhost), that should have triggered an alert drawing attention to this anomaly. The key detail here that would have distinguished this alert from the appearance of just another peer of Amazon would have been that the new upstream was seen by 100% of BGP vantage points. In other words, this new Amazon prefix was getting exclusively transited by this relatively unknown hosting provider. That should have raised some eyebrows among the Amazon NetOps team.

RPKI ROV

Amazon had a ROA for the prefix that was hijacked, so why didn’t RPKI ROV help here? It is important to first emphasize that RPKI ROV is intended to limit the impact of inadvertent or accidental hijacks due to routing leaks or misconfigurations. This is because ROV alone cannot prevent a ‘determined adversary’ from forging the origin in the AS-PATH, rendering a malicious hijack RPKI-valid.

Having said that, it could have still helped if the ROA were set up differently. As it stands, the ROA for the address space in question is quite liberal. Basically, three different Amazon ASNs (16509, 8987, and 14618) can all announce parts of this address space with prefixes ranging in size from a /10 all the way down to a /24. See the output of the Routinator web UI, as shown in figure 4.

Validation results for 44.235.216.0/24 - AS16509 via the Routinator web UI

An alternative approach to ROA creation would be to do what other networks such as Cloudflare and Comcast have done — set the origin and maximum prefix length to be identical to how the prefix is routed. While this approach incurs an overhead cost of needing to update a ROA every time a route is modified, it also leaves little room for alternate versions of the route to come into circulation. Another consideration is the propagation time of the RPKI system itself — changes to ROAs take time to propagate around the world and networks only periodically update their RPKI data.

In its blog post following the June 2019 routing leak by Allegheny Technologies, Cloudflare made the argument that had Verizon deployed RPKI ROV and had been rejecting RPKI-invalid routes, the leak would not have circulated and the impact would have been minimal. As I discussed in my talk at NANOG 78 in February 2020, this statement is only true because the maximum prefix lengths in Cloudflare’s ROAs matched the prefix lengths of their routes. This is not true of many ROAs, including Amazon’s.

At NANOG 84 earlier this year, Comcast presented the story of how they deployed RPKI ROV on their network. In the Q&A, they confirmed that they adopted a strategy of using automation to maintain exact matches of maximum prefix lengths in their ROAs to avoid this route optimizer leak scenario.

Had Amazon created a ROA specifically for 44.224.0.0/11 with an origin of AS16509 and a max-prefin-len of 11, then the attacker would have to do one of two things to pull off this attack. One option would be to announce the same route (44.224.0.0/11 with a forged origin of AS16509). This route would have been RPKI-valid but would have had to contend with the real AS16509 for route propagation. Alternatively, if the attacker announced a more-specific route, it would have been evaluated as RPKI-invalid and had its propagation dramatically reduced if not completely blocked given the upstream in this case was Arelion and they reject RPKI-invalid routes.

Conclusions

The attacks against cryptocurrency services in recent years highlight universal problems that aren’t restricted to cryptocurrencies. Companies looking to secure their Internet-facing infrastructures need to deploy robust BGP and DNS monitoring of their infrastructure as well as that of any Internet-based dependencies they may have.

Additionally, companies should reject RPKI-invalid routes while also creating strict ROAs for their IP address space by including maximum prefix lengths that exactly match the prefix lengths used in their routes. In fact, RFC 9319 ‘The Use of maxLength in the Resource Public Key Infrastructure (RPKI)’ states that it is a ‘best current practice’ that networks entirely avoid using the maxLength attribute in ROAs, except in certain circumstances. Leaving the maxLength field blank in a ROA has the same effect as setting the maxLength field to match the prefix. These steps can greatly reduce the window of opportunity for an attacker to subvert your Internet infrastructure.

Comments

Popular posts from this blog

Сбербанк и дропы с площадки Dark Money, и кто кого?

Крупных открытых площадок в даркнете, специализирующихся именно на покупке-продаже российских банковских данных, обнале и скаме около десятка, самая большая из них – это Dark Money . Здесь есть нальщики, дропы, заливщики, связанный с ними бизнес, здесь льют и налят миллионы, здесь очень много денег, но тебе не стоит пока во все это суваться. Кинуть тут может любой, тут кидали и на десятки миллионов и на десятки рублей. Кидали новички и кидали проверенные люди, закономерности нету. Горячие темы – продажи данных, банковских карт, поиск сотрудников в скам и вербовка сотрудников банков и сотовых операторов, взлом аккаунтов, обнал и советы – какими платежными системы пользоваться, как не попасться милиции при обнале, сколько платить Правому Сектору или патрулю, если попались. Одна из тем – онлайн-интервью с неким сотрудником Сбербанка, который время от времени отвечает на вопросы пользователей площадки об уязвимостях системы банка и дает советы, как улучшить обнальные схемы. Чтобы пользова

Перехват BGP-сессии опустошил кошельки легальных пользователей MyEtherWallet.com

Нарушитель ( реальный заливщик btc и eth ) используя протокол BGP успешно перенаправил трафик DNS-сервиса Amazon Route 53 на свой сервер в России и на несколько часов подменял настоящий сайт MyEtherWallet.com с реализацией web-кошелька криптовалюты Ethereum . На подготовленном нарушителем клоне сайта MyEtherWallet была организована фишинг-атака, которая позволила за два часа угнать 215 ETH (около 137 тысяч долларов) на кошельки дропов. Подстановка фиктивного маршрута была осуществлена от имени крупного американского интернет-провайдера eNet AS10297 в Колумбусе штат Огайо. После перехвата BGP-сессии и BGP-анонса все пиры eNet, среди которых такие крупнейшие операторы, как Level3 , Hurricane Electric , Cogent и NTT , стали заворачивать трафик к Amazon Route 53 по заданному атакующими маршруту. Из-за фиктивного анонса BGP запросы к 5 подсетям /24 Amazon (около 1300 IP-адресов) в течение двух часов перенаправлялись на подконтрольный нарушителю сервер, размещённый в датацентре п

DDOS атаки на маршрутизатор и методы защиты Juniper routing engine

По долгу службы мне часто приходится сталкиваться с DDOS на сервера, но некоторое время назад столкнулся с другой атакой, к которой был не готов. Атака производилась на маршрутизатор  Juniper MX80 поддерживающий BGP сессии и выполняющий анонс сетей дата-центра. Целью атакующих был веб-ресурс расположенный на одном из наших серверов, но в результате атаки, без связи с внешним миром остался весь дата-центр. Подробности атаки, а также тесты и методы борьбы с такими атаками под катом.  История атаки Исторически сложилось, что на маршрутизаторе блокируется весь UDP трафик летящий в нашу сеть. Первая волна атаки (в 17:22) была как раз UDP трафиком, график unicast пакетов с аплинка маршрутизатора: и график unicast пакетов с порта свича подключенного к роутеру: демонстрируют, что весь трафик осел на фильтре маршрутизатора. Поток unicast пакетов на аплинке маршрутизатора увеличился на 400 тысяч и атака только UDP пакетами продолжалась до 17:33. Далее атакующие изменили стратегию и добавили к

Сброс BGP-сессии при помощи TCP Connection Reset Remote Exploit

Уже ни раз рассказывал о протоколе ТСР , так что повторятся особо не буду, напомню лишь основные положения: Transmission Control Protocol описывается в RFC 793 и преимуществом его является надежность передачи данных от одной машины к другому устройству по сети интернет. Это означает, что ТСР гарантирует надежность передачи данных и автоматически определит пропущенные или поврежденные пакеты. Что для нас важно из его конструкции? В общем виде заголовок ТСР пакета выглядит так: Программа передает по сети некий буфер данных, ТСР разбивает данные на сегменты и дальше упаковывает сегменты в наборы данных. Из наборов данных формируются пакеты и уже они передаются по сети. У получателя происходит обратный процесс: из пакетов извлекаются набор данных, его сегменты, затем сегменты передаются в ТСР стек и там проверяются, потом собираются и передаются программе. Sequence numbers Данные разбиваются на сегменты, которые отдельными пакетами направляются по сети получателю. Возможна ситуация, к

Как найти реального заливщика

Своего первого реального заливщика, который показал мне как можно скачать деньги в интернет с банковских счетов, я нашел случайно, когда еще трудился в Укртелекоме сменным инженером немного подрабатывая продавая трафик налево , но потом этот человек отошел от дел в связи со слишком уж скользкой ситуацией в данной сфере, и я решил поискать партнера на форумах, разместив рекламу на трёх электронных досках объявлений. Честно говоря поначалу даже был готов сразу закинуть 500 000 гривен в Гарант, но потом призадумался, а стоит ли? Ко мне начал обращаться народ обращается разных категорий 1. Дебильная школота, которая что-то любит повтирать про свою серьезность и просит закинуть 10 000 USD им на Вебмани в качестве аванса  2. Реальные мэны, которые  льют сразу большую сумму по SWIFT  без разговоров про гарантии и прочую шнягу, но после того, как им отдаёшь нал, они сразу пропадают, суть данных действий я так и не понял. зачем пропадать, если всё прошло гладко? 3. Мутные личност

Обзор внутренней инфраструктуры безопасности Google

Обычно компании предпочитают хранить в тайне особенности своей инфраструктуры безопасности, которая стоит на защите дата-центров, полагая, что раскрытие подобной информации может дать атакующим преимущество. Однако представители Google смотрят на этот вопрос иначе. На то есть две причины. Во-первых, публикация таких отчетов позволяет потенциальным пользователям Google Cloud Platform (GCP) оценить безопасность служб компании. Во-вторых, специалисты Google уверены в своих системах безопасности. На днях компания обнародовала документ Infrastructure Security Design Overview («Обзор модели инфраструктуры безопасности»), в котором Google достаточно подробно описала свои защитные механизмы. Инфраструктура разделена на шесть слоев, начиная от аппаратных решений (в том числе физических средств защиты), и заканчивая развертыванием служб и идентификацией пользователей. Первый слой защиты – это физические системы безопасности, которые просто не позволяют посторонним попасть в дата-центры. Эта част