BGP routing security flaw caused Amazon Route 53 incident

BGP routing security flaw caused Amazon Route 53 incident

A well-known weakness in Border Gateway Protocol routing was exploited this week, as Amazon Web Services' DNS traffic was hijacked for two hours, enab

Android ransomware and more preinstalled on devices
AT&T Faces $224M Legal Challenge Over SIM-Jacking Rings
Some HTTPS inspection tools might weaken security

A well-known weakness in Border Gateway Protocol routing was exploited this week, as Amazon Web Services’ DNS traffic was hijacked for two hours, enabling the attacker to steal about $150,000 in cryptocurrency from users of a cryptocurrency wallet.

The attack, which rerouted traffic for five Class C networks registered to Amazon Web Services from 11 a.m. until 1 p.m. (UTC), could have affected as many as 1,280 IP addresses. During the incident, some traffic to the cryptocurrency website MyEtherWallet was redirected to a server in Russia, where the cryptocurrency was stolen from unwitting customers, according to Kevin Beaumont, a U.K.-based security researcher.

The attack used the weakness in Border Gateway Protocol routing security to advertise the spoofed network routes from an exploited BGP server. “The attackers used BGP – a key protocol used for routing internet traffic around the world – to reroute traffic to Amazon’s Route 53 service, the largest commercial cloud provider who count[s] major websites such as Twitter.com as customers,” Beaumont wrote in a blog post. “They re-routed DNS [domain name system] traffic using a man in the middle attack using a server” hosted on customer equipment in a Chicago facility provided by colocation provider Equinix.

The spoofed routes were apparently inserted into the BGP infrastructure by a server at the Columbus, Ohio-based internet service provider eNET Inc., which participates as autonomous system (AS) 10297. In this case, it appears that eNET BGP servers had received advertisements of the spoofed routes and forwarded them to other BGP servers. The BGP routing security flaw was exploited to redirect network traffic to the phishing site, without the need to successfully attack the MyEtherWallet server or the AWS Route 53 DNS servers.

ENET was unavailable for comment on the incident.

In a statement to media outlets, Amazon officials said the incident did not involve any hack or compromise of systems at either AWS or Amazon Route 53; rather, it was the result of a malicious actor announcing BGP routes for Route 53 addresses that were then improperly used to direct traffic intended for one customer’s domain to a malicious version of the domain.

MyEtherWallet officials also responded to the incident on Reddit, stating they became aware of the hijack of two DNS registration servers at 12 p.m. UTC, which redirected their users to a phishing site. “This redirecting of DNS servers is a decade-old hacking technique that aims to undermine the internet’s routing system. It can happen to any organization, including large banks. This is not due to a lack of security on the @myetherwallet platform. It is due to hackers finding vulnerabilities in public facing DNS servers.”

Minding MANRS for better BGP routing security

The incident occurred just a day after the Internet Society announced its Mutually Agreed Norms for Routing Security (MANRS) initiative for internet exchange points, an effort to improve BGP routing security by specifying best practices to eliminate BGP route hijacking, route leaks and forwarding of traffic with spoofed IP addresses.

MANRS “calls for four simple, but concrete actions all network operators should take to reduce the most common routing threats,” Aftab Siddiqui, Internet Society technical engagement manager, told SearchSecurity. “The first 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 Ethereum BGP hijack would not have propagated across the internet like it did. For example, eNET also peers with Level3 (AS3356) and NTT (AS2914), but those operators didn’t forward the wrong information, because they are MANRS-compliant.”

Go to Source

COMMENTS