AWS Route 53 BGP Hijack: What Kentik Saw
Summary
News broke last week that attackers attempted to steal cryptocurrencies from users of MyEtherWallet.com by using a BGP route hijack attack. Numerous Kentik Detect customers saw changes in their traffic patterns, allowing them to detect this attack. In this post, we look at how the attack worked and the visibility that Kentik Detect provided our customers.
Using Kentik Detect to analyze and respond to BGP issues
Last week, news broke that attackers attempted to steal cryptocurrencies from users of MyEtherWallet.com by using a BGP route hijack attack. Numerous Kentik Detect® customers saw changes in their traffic patterns which would allow them to detect this attack. Let’s take a look at how this works.
What is BGP Route Hijacking?
In simple terms, Border Gateway Protocol (BGP) is the protocol that routes traffic on the Internet. Each BGP speaking organization is assigned an Autonomous System Number (ASN) that identifies them on the Internet. They can then announce the routes (groups of IP addresses) that they own from their ASN. During a BGP route hijack, an attacker advertises IP prefixes from an ASN that is not the normal originator. This causes legitimate traffic to those IPs to be redirected to the attacker. During last week’s attack, the attacker was redirecting traffic that belonged to Amazon’s Route 53 DNS servers. Below is a diagram of how this attack worked:
Once the attackers have the DNS requests coming to them, they can respond with the IP address of a server they control. In this case, requests for MyEtherWallet.com were answered with the IP address of a fake server in Russia. Unsuspecting MyEtherWallet.com users then entered their usernames and passwords on the fake site and the attackers used them to access those accounts on the real MyEtherWallet.com website. This type of attack is often referred to as a Man-in-the-Middle (MITM) attack.
What Kentik Saw
According to the Cloudflare blog, the BGP hijack was taking place from 11:05 UTC to 12:55 UTC so we will focus on that time range. First, we filtered traffic just to the hijacked subnets:
And then we looked at the packets per second (PPS) by destination AS number:
We can see that there is a major spike to eNet, Inc. (AS10297) who is a small ISP in Ohio the attackers used to propagate this attack. There is definitely a dip in traffic to the legitimate destination on Amazon (AS16509) but the traffic did not completely go away. This is likely caused by the fact that not all regions accepted the hijacked routes from AS10297. Drilling down further we can take a look at just the traffic that has been hijacked. This makes it very easy to see the timeframe for the hijack as well as the distribution of traffic across the various hijacked IP prefixes.
To get an even better idea of the distribution of the traffic across the various hijacked prefixes, let’s take a look at a Sankey diagram. Here we have the DNS clients sending their DNS queries to the hijacked blocks advertised by AS10297. We can see that most of the traffic is UDP port 53 DNS traffic but there is a little bit that is TCP port 53. By looking at the thickness of the bands, you can see how much traffic is taking each path.
For more information on Sankey diagrams, check out our blog: Insights Delivered: The Power of Sankey Diagrams.
Summary
Although not always as high profile as this event, BGP hijacking attacks happen regularly. In this case, the attackers stole crypto-currencies. In other cases, damages to digital enterprise have been devastating. To see how you can get this type of visibility in your own network, schedule a demo or sign up today for a free trial.
