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

Как работает банк со своими корреспондентами по SWIFT

Итак, наш банк имеет открытые корреспондентские счета в США (CITIBANK N.A. NEW YORK), в Европе (VTB BANK DEUTSCHLAND AG), в России (Промсвязьбанк Москва и Собинбанк Москва). Соответственно, все расследования по платежам происходят через эти банки согласно  установленным корреспондентским отношениям с использованием соответствующих форматов SWIFT MT-195/295, MT-196/296, MT-199/299 и MT-192/292 Кроме прямых корреспондентских отношений с банками, нашим банком установлены отношения и с другими финансовыми организациями через процедуру обмена ключами, что даёт возможность использовать SWIFT-форматы МТ-195, МТ-196 и МТ-199 для проведения процедуры расследования по стандартным платежам и платежам с покрытием: - DEUTSCHE BANK TRUST COMPANY AMERICAS USA - COMMERZBANK AG Germany - CITIBANK N.A. London - CITIBANK N.A. Brussels - BANQUE DE COMMERCE ET DE PLACEMENTS S.A. Geneva - NORVIK BANKA JSC  LV - ABLV BANK AS  LV В среднем процедура расследования занимает от 3 до 14 дней (е

Почему инженеры электросвязи становятся продажниками

Давно предупреждал инженеров электросвязи - если вы не развиваетесь, то рано или поздно превратитесь либо в дворника, либо в ассенизатора. О чем не предупреждал, каюсь, - так это о том, что локальный апокалипсис наступит прямо сейчас. Взять, например, сетевых инженеров  Ростелекома, которые бодро так искали, кого ещё подключить к интернету последние пару недель в Сочи и в Адлере. Скажете, инженеров заставляют работать продажниками - произвол и несправедливость? Лично я в этом совершенно не уверен. Чтобы было сразу понятно, о чем речь, готов проиллюстрировать свою мысль как работодатель. Мы ведь имеем здесь потенциальный конфликт в отношениях между работником и Ростелекомом , верно? И пока возмущенная общественность твердо стоит на стороне работника, предлагаю посмотреть чуть шире — не со стороны работодателя даже, а так, сбоку. Давайте возьмем, например, меня — типичного работодателя. Так случилось, что на меня работает некоторое количество весьма лояльных и толковых людей, ч

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

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

Виртуальная сеть на базе Cisco CSR 1000V

Во время обучения, для того чтобы лучше разобраться как работает та или иная технология я пользовался и программой моделирования сетей DYNAGEN , и удаленным доступом к стенду с реальным оборудованием, любезно предоставленным нам организаторами обучения. Это, конечно же очень помогало, но меня все время не оставляла мысль найти какой-то вариант, который позволил бы иметь ощущение реальности при работе с устройством и в тоже время чтобы я мог его крутить так как мне захочется и в любое время, когда мне захочется. Я пробовал и GNS3, и IOU, при этом продолжая поиски. Так я узнал о таком продукте от CISCO как CSR 1000V Cloud Services Router -  http://www.cisco.com/c/en/us/products/routers/cloud-services-router-1000v-series/index.html  , скачать который можно в нашей подборке Cisco IOS . Небольшие выдержки из документации: «Развернутый на виртуальной машине Cisco CSR 1000V с IOS XE обеспечивает точно такую же функциональность, как если бы IOS XE работала на традиционной аппаратной платформе

М9 - точка обмена трафиком • Московский INTERNET EXCHANGE • MSK-XI

Вот так всё начиналось Изначально был всего один провайдер - Релком. Не было конкурентов - не было проблем. Рунет еще делал свои первые шаги, и все русскоязычные ресурсы были сосредоточены в одном месте. Позже Релком развалился на Релком и Демос, стали появляться другие провайдеры. Рунет тем временем подрос и... распался на множество отдельных сетей-сегментов, контролируемых разными провайдерами. Разумеется, конечные пользователи имели доступ ко всем ресурсам рунета, но прямого взаимодействия между провайдерами не было. Поэтому трафик шел с сервера одного провайдера по огромной петле через Америку, потом Германию, и только потом возвращался на сервер другого провайдера. Имела место неоправданная потеря и в скорости, и в деньгах. Пока трафик был незначительным, это мало кого волновало, но интернет бурно развивался, трафик по рунету стремительно увеличивался, и в один прекрасный день крупные провайдеры Москвы (по сути, Демос и Релком) сели друг напротив друга и решили, что им надо нал

Чем рискуют дропы и нальщики принимая заливы на свои карты

Зам.начальника управления Следственного департамента МВД Павел Сычев рассказал о криминальном бизнесе «нальщиков» - Глава Банка России Эльвира Набиуллина заявила о снижении объемов теневого оборота в конце 2013 года. Что показывает ваша статистика по выявлению незаконных операций? - В последние годы объем денежных средств, выведенных в теневой сектор, увеличивался, и криминогенная обстановка ухудшалась. Проблема находится в поле зрения президента -  в декабрьском послании Федеральному Собранию, он призвал избавить нашу финансовую систему от разного рода «отмывочных контор» и так называемых «прачечных». Оперативники уже получили ориентировку на более активное выявление этих преступлений. П о уголовным делам, расследованным МВД только в первом полугодии 2013 года, проходит 145 млрд рублей, обналиченных и незаконно выведенных заграницу. Это неуплаченные налоги, незаконный бизнес, хищения, взятки. Финансовый доход посредников от этих операций составил 8 млрд рублей. Расследовано 89