Shutting Down the BGP Hijack Factory

It started with a lengthy email to the NANOG mailing list on 25 June 2018: independent security researcher Ronald Guilmette detailed the suspicious routing activities of a company called Bitcanal, whom he referred to as a “Hijack Factory.” In his post, Ronald detailed some of the Portuguese company’s most recent BGP hijacks and asked the question: why Bitcanal’s transit providers continue to carry its BGP hijacked routes on to the global internet?

This email kicked off a discussion that led to a concerted effort to kick this bad actor, who has hijacked with impunity for many years, off the internet.

Transit Providers

When presented with the most recent evidence of hijacks, transit providers GTT and Cogent, to their credit, immediately disconnected Bitcanal as a customer. With the loss of international transit, Bitcanal briefly reconnected via Belgian telecom BICS before being disconnected once they were informed of their new customer’s reputation.

The following graphic illustrates a BGP hijack by Bitcanal via Cogent before Cogent disconnected them. Bitcanal’s announcement of 101.124.128.0/18 (Beijing Jingdong 360 Degree E-commerce) was a more-specific hijack of 101.124.0.0/16, normally announced by AS131486 (Beijing Jingdong 360 Degree E-commerce). The graphic on the right shows another prefix being initially transited by GTT (AS3257) and then briefly via BICS before those companies terminated service to Bitcanal.

Following the loss of these transit providers, these three prefixes (below), previously announced by Bitcanal, moved to a new home at Meerfarbig GmbH. However, when Meerfarbig learned where their new customer had come from, Meerfarbig quickly disconnected them as well.

The loss of transit also disconnected Routed Solutions (AS39536), ostensibly a customer of Bitcanal, although Bitcanal is listed as its admin contact on its WHOIS registration.

The leftmost graphic below shows a prefix moving briefly to Meerfarbig after Bitcanal was cut off by major transit providers. The rightmost graphic shows a prefix originated by AS39536 being disconnected when Bitcanal lost its transit, but returning to circulation via M247 (AS9009).

Internet Exchange Points (IXPs)

But Bitcanal didn’t only announce hijacked routes via transit providers, it has also extensively used Internet exchange points (IXPs) as a way to send hijacked routes directly to unsuspecting networks. While the German IXP DE-CIX reportedly dropped Bitcanal last year for bad behavior, it took behind-the-scenes coordination in recent days to get Bitcanal booted from LINX and AMSIX, the major IXPs in London and Amsterdam, respectively.

Latest disconnections

In the past 24 hours, there have been two additional significant disconnections which greatly limit Bitcanal’s ability to announce its hijacks. At 16:46 UTC on 9 July 2018, Hurricane Electric (AS6939) de-peered Bitcanal (AS197426) (graphic on left). Earlier today at 11:40 UTC Portuguese transit provider IPTelecom terminated service to Bitcanal (graphic on right). While Bitcanal appears to remain connected (for the time being) at ESPANIX, with the loss of IPTelecom transit, Bitcanal is effectively cutoff from the global internet.

Bitcanal’s IPv6 route (2a00:4c80::/29) was also withdrawn at 16:04 UTC today. According to Spamhaus, it was also the source of large amounts of spam email and is listed on their IPv6 Drop list.

A Long Running Reputation

Longtime followers of this blog may recognize the name Bitcanal (retail name Ebony Horizon) as we have documented their numerous flagrant BGP hijacks in the past including the hijack of IP address space belonging to the State Attorney General of Texas (206.218.64.0/22) back in 2014. They warranted their own section (“Case 2”) in my 2015 blog post, The Vast World of Fraudulent Routing.

We’re not the only ones to have noticed something suspicious with Bitcanal: Spamhaus lists all of their ASNs (AS197426, AS3266, AS200775, and AS42229) on their ASN Droplist due to a history of originating massive amounts of spam email.

Lessons for IXPs

There are lessons to be learned from the past couple of weeks, specifically lessons for IXPs.

Bad actors like Bitcanal take advantage of IXPs to form myriad peering relationships for the purpose of injecting fraudulent routes. These routes can be used to send spam and other malicious traffic. These bad actors presume people don’t generally monitor the routes they receive from peers and by hijacking the IP space of others, they attempt to evade IP blacklists.

Based on the discussions with IXPs regarding this particular case, the following points are worthy of consideration.

1) Even if abuse didn’t take place across your exchange, you can still consider disconnection to mitigate future risk. If it had been widely known that DECIX kicked out Bitcanal last year, might other IXes have disconnected them? Or at least started scrutinizing their activity at the exchange?

2) IXPs are not just a neutral transport bus anymore. They facilitate a unique service that malicious actors can leverage. Like it or not, this makes IXPs responsible too.

3) Ensure that you have monitoring and analysis capabilities in place. Multiple IXPs contacted did not have MRT files of their route servers, or PCAP collection to verify any claim. If an IXP has a policy of requiring evidence of bad behavior, it must also be collecting that evidence and, most importantly, a process to review that evidence when a reasonable inquiry is made.

The removal of this bad actor was accomplished with the work of a number of people in the internet community. I would especially like to thank Job Snijders of NTT for his assistance on this blog post.