KlaySwap – Another BGP Hijack Targeting Crypto Wallets

It’s happened again. On 3 February, cryptocurrency platform KLAYswap had a security incident that allowed hackers to steal 2.2 billion (KRW), or about USD 1.9 million worth of digital (crypto currency) assets. KLAYswap published a blog post about it, noting that the attack lasted two hours and KLAYswap is currently issuing compensation for affected users. (Linked articles are in Korean.)

Here, we’ll dig into the technical details of what happened and how MANRS actions can help us all. We’re diving head-first into the deep end of BGP security so if you’re looking for basic information about routing security, start here.

What Happened to KLAYSWAP?

In this case, the attackers didn’t target KLAYswap directly, but instead went after the server infrastructure of KakaoTalk, a service KLAYswap was using for marketing and tech support communications.

South Korean cybersecurity firm S2W published a detailed post-mortem report (also in Korean) highlighting that the attackers used a BGP hijack to serve a malicious version of KakaoTalk’s JavaScript SDK file. The domain (developers.kakao.com) that is distributing the Kakao SDK file has been resolving with two IPs:

developers.gl.kakao.com. 83      IN          A            211.249.221.246

developers.gl.kakao.com. 87      IN          A            121.53.104.157

Both IPs are managed by a server hosting company called Dreamline, and Kakao Corp is the user that got the sub-assignment from Dreamline.

Current BGP table entry for IP address 211.249.221.246

RIPE Stat Link

Current BGP table entry for IP address 121.53.104.157

RIPE Stat Link

Before this month, 121.53.104.0/23 had very limited coverage through AS38099, which belongs to Kakao Corp. This network only peers with AS10158, which also belongs to Kakao Corp. AS10158 is a member of Korea Internet Exchange (KINX). Looking at the BGP dumps provided by PCH from KINX, AS38099 was only advertising 121.53.104.0/23 to KINX. The following snapshot was taken on 10January 2022 from the IX peering bgp dump.

The prefixes (211.249.216.0/21 and 121.53.104.0/23) are originated by two different ASNs that belong to Kakao Corp-AS7625 and AS38099 respectively-and then further propagated by AS10158 (Kakao Corp).

Even though 211.249.216.0/21 and 121.53.104.0/23 are advertised by different ASNs that belong to Kakao Corp, as per the APNIC whois database these prefixes are delegated to another entity called Dreamline Co and then are further assigned to Kakao Corp.

The KRNIC whois database confirms the same.

Here is the summary of BGP advertisements before the hijack.

At 1:04:20 UTC on 3 February 2022, the following specific routes entered the global routing table.

BGP routers always prefer to use the more specific (/24) route over the less specific (/21); that means all traffic diverted toward the new advertised route. The more specific 211.249.221.0/24 was advertised in three intervals starting from 1:04 UTC until 4:00 UTC as per the RIPE Stat data.

During this period, another 121.53.104.0/24 entered the global routing table. Remember, previously 121.53.104.0/23 was only advertised to KINX and not to the global routing table. The only way to reach this subnet was through 121.53.0.0/16 and 121.53.0.0/17 advertised by AS9457.

This most specific advertisement happened in two intervals starting at 2:09 UTC until 4:00 UTC.

In both cases of most-specific advertisement, the origin AS was AS9457, Dreamline Co. They are legitimate custodians of these prefixes, but have never advertised these specific routes before. The key takeaway is in the AS_Path of these advertisements.

AS9457 has no direct relationship with AS6461 (Zayo), yet it is shown as a direct peer in the AS_Path of the above announcement. The only reason for this to happen is that someone on the Zayo network hijacked the prefixes and originated it from AS9457.

Could This Have Been Prevented?

This is one of the hardest hijacks to filter out because both ASN and prefixes belong to the same entity. Also, there are no valid route objects for either of the specific routes in the APNIC whois db, though at least some exist in RADb.

How the attackers convinced Zayo to accept those routes requires some clarification from Zayo. As Zayo is a MANRS participant, the MANRS team has issued a request for more information about the incident and details on what steps Zayo is taking to avoid this happening again. MANRS takes conformance very seriously and will take measures to ensure its participants are working toward a strong and secure Internet for everyone.

This hijack could have been avoided-or at least its propagation would have been minimized considerably-if there were valid RPKI Route Origin Authorization (ROA) as per legitimate origin ASN. Unfortunately, there is no ROA of any routes originating from either of these ASN, as per rpki.cloudflare.com

If Dreamline Co created the following ROAs (2 options), this hijack could have been avoided or at least its impact minimized.

Another option, because it is not recommended to create ROA for routes not advertised, it would be better to create ROA with AS0 (zero) to show that this route will not be advertised. If someone tries to do that, it will become invalid.

An origin with AS9457 would have made that route invalid and been dropped by many operators across the global routing table.

What Do We Do Now?

This is not the first time a BGP hijack was used to steal cryptocurrency. Back in 2018 Amazon Route 53 routes were hijacked in order to take over Ethereum Cryptocurrency Wallets.

Mutually Agreed Norms for Routing Security (MANRS) calls for simple but concrete actions ALL network operators should take to reduce the most common routing threats. One is filtering, which prevents the propagation of incorrect routing information. If all the operators along the path had implemented the MANRS actions-especially filtering-this would not have propagated across the Internet like it did.

This can happen again, at any time. Network operators have a responsibility to ensure a globally robust and secure routing infrastructure. Your network’s safety depends on a routing infrastructure that weeds out bad actors and accidental misconfigurations that wreak havoc on the Internet. The more network operators work together, the fewer incidents there will be, and the less damage they can do.

Learn more about MANRS here. Implement the actions for network operators and join the community of security-minded operators working together to make the Internet safer for everyone.