Shutting down the BGP Hijack Factory

By on 12 Jul 2018

Category: Tech matters

Tags: , , ,

Blog home

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, which 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 do Bitcanal’s transit providers continue to carry its BGP hijacked routes on to the global Internet?

This email began a discussion that led to a concerted effort to kick this bad actor, which 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 teleco BICS before being disconnected once BICS were informed of their new customer’s reputation.

Figure 1 — The graph on the left illustrates a BGP hijack by Bitcanal via Cogent before Cogent disconnected them. The graph on the right shows another prefix being initially transited by GTT (AS3257) and then briefly via BICS before those companies terminated service to Bitcanal.

Bitcanal’s announcement of 101.124.128.0/18 was a more specific hijack of 101.124.0.0/16, which is normally announced by AS131486 (Beijing Jingdong 360 Degree E-commerce).

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.

185.251.248.0/22 Anna Dragun-Damian PL
185.251.44.0/22 Anna Dragun-Damian PL
185.254.16.0/22 Xantho Ltd LT

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.

Figure 2 — The graph on the left shows a prefix moving briefly to Meerfarbig after Bitcanal was cut off by major transit providers. The graph on the right 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 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 behaviour, it took behind-the-scenes coordination in recent days to get Bitcanal booted from LINX and AMS-IX, the major IXPs in London and Amsterdam, respectively.

Latest disconnections

Earlier this week, there were two additional significant disconnections which greatly limited Bitcanal’s ability to announce its hijacks.

At 16:46 UTC on 9 July 2018, Hurricane Electric (AS6939) de-peered Bitcanal (AS197426) (Figure 3, left). On 10 July at 11:40 UTC, Portuguese transit provider IP Telecom terminated services to Bitcanal (Figure 3, right). While Bitcanal appears to remain connected (for the time being) at ESPANIX, with the loss of IP Telecom transit, Bitcanal is effectively cut off from the global Internet.

Figure 3 — The graph on the left shows Hurricane Electric de-peered Bitcanal on 9 July 2018. The graph on the right shows Portuguese transit provider IP Telecom terminating services to Bitcanal on 10 July 2018.

Bitcanal’s IPv6 route (2a00:4c80::/29) was also withdrawn at 16:04 UTC [on 10 July]. 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

Readers may recognize the name Bitcanal (retail name Ebony Horizon) as Oracle Dyn has 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.

Oracle Dyn is not the only one 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 IXPs 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 behaviour, 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.

Adapted from original post that appeared on Dyn.com Blog

Doug Madory is a Director of Internet Analysis of Oracle’s Internet Intelligence Team where he works on Internet infrastructure analysis projects.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *

Please answer the math question * Time limit is exhausted. Please reload CAPTCHA.

Top