What can be learned from recent BGP hijacks targeting cryptocurrency services?
Summary
On August 17, 2022, an attacker was able to steal $235,000 in cryptocurrency by employing a BGP hijack against Celer Bridge, a cryptocurrency service. While this incident is the latest such attack, there are lessons beyond the world of cryptocurrency for any organization that conducts business on the internet.
On August 17, 2022, an attacker was able to steal approximately $235,000 in cryptocurrency by employing a BGP hijack against the Celer Bridge, a service that allows users to convert between cryptocurrencies.
This blog post discusses this and previous infrastructure attacks against cryptocurrency services. While these episodes revolve around cryptocurrency theft, the underlying attacks hold lessons for securing the BGP routing of any organization that conducts business on the internet.
The Attack Against 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 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 sure its malicious BGP announcements wouldn’t get filtered by an upstream network by taking two steps. First, it inserted 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 in 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
<br />
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: ALTDBSince 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 from 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 out 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.
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.
Prior Infrastructure Attacks Against Crypto
The Celer Bridge attack wasn’t the first time a cryptocurrency service was targeted using a BGP hijack. In April 2018, Amazon’s authoritative DNS service, the former Route 53, was hijacked to redirect certain DNS queries to an imposter DNS service, as is illustrated below.
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 would not be the last to target cryptocurrency.
Earlier this year, another incident involved the manipulation of BGP to target a cryptocurrency service. Attackers were able to make off with over $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.
This is because Kakao hosted a JavaScript library 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.
Explainer Department
What is BGP Hijacking?
BGP hijacking, or IP hijacking, refers to a malicious attempt by attackers to illicitly take control of a group of IP prefixes via the Border Gateway Protocol (BGP). By manipulating the internet’s routing tables, the attacker reroutes internet traffic to a system under their control or in a manner that disrupts the intended path of data, leading to significant disruptions and potential cybersecurity breaches.
The core mechanism of BGP hijacking is founded on the inherent trust in the internet’s infrastructure. BGP, an essential protocol used to route web traffic between IP networks, doesn’t have intrinsic security measures, making it susceptible to hijacking. The attacker announces fake BGP routes that confuse routers into redirecting traffic meant for a particular IP address range to a different, unanticipated route. This strategy allows the hijacker to eavesdrop, manipulate data, or halt the traffic, causing substantial harm.
The consequences of BGP hijacking can be far-reaching. In addition to the immediate impact of traffic disruption, it can lead to severe security incidents, such as data breaches and violation of privacy. For example, an attacker could potentially capture sensitive information transmitted over the hijacked path, modify the content of data in transit, or use the hijacked routes for activities like DDoS attacks. Due to these high-risk scenarios, securing BGP and developing strategies to detect and mitigate BGP hijacking have become critical to maintaining internet security.
While malicious intent is undoubtedly a concern, it’s important to note that not all instances of BGP hijacking are intentionally harmful. Many instances result from inadvertent misconfigurations rather than from malicious activity. For example, a simple typo in a configuration file can unintentionally lead to the announcement of incorrect BGP routes, causing unintended traffic redirection. Despite the lack of malice in these cases, the effect on internet traffic and the potential for information exposure remains significant.
What Can be Done to Protect Against BGP Hijacks?
While the abovementioned incidents involved the targeting of cryptocurrency services, the underlying issues are universal and can affect any organization that uses internet-based services. To safeguard against attacks like these, BGP and DNS monitoring need to play a central role in your monitoring strategy. 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), an alert should have drawn 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 an ROA for the hijacked prefix, so why didn’t RPKI ROV help here? It is important first to 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:
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 updating an 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.
Conclusion
As mentioned, 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 and any internet-based dependencies they may have.
Additionally, companies should reject RPKI-invalid routes while creating strict ROAs for their IP address space by including maximum prefix lengths that 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 significantly reduce the window of opportunity for an attacker to subvert your internet infrastructure.
