Метка: BGP MiTM

 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.

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.

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.

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.

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