Hacker News Reader

Comment by highace | Hacker News Reader

What does this mean for those unfamiliar?

It’s like someone posting a “Turn left for Highway 123” road sign right next to a legitimate “Turn right for Highway 123” sign. Traffic snarls result, since most drivers don’t check the DOT security sticker on the back of both signs and find it missing from the fake Left one.

In other words, some entity that is not cloudflare claimed to have the best route to (some of?) cloudflare's IP ranges, including 1.1.1.1.

If malicious, this could be someone trying to redirect 1.1.1.1 traffic elsewhere.

There have also been a lot of historical examples of misconfiguring BGP (the way big internet networks talk to each other and discuss where to send packets), such as a florida ISP accidentally claiming the best route to some major internet service and getting flooded with everyone's traffic until it died.

BGP is also really insecure (back in 2008 pakistan effectively brought down youtube for instance through BGP -- which doesnt require any authentication to claim you have the best route to X).

Significantly simplified:

BGP4, which is one of the fundamental building blocks of the global Internet, relies on trust between BGP peers. ISP A says to ISP B, their peer, "hey I'm responsible for this chunk of publicly routable IP space, please send all traffic to ASN number N for this particular block".

This works as long as everyone configures their IP space announcements and prefix-list filters correctly.

A lot of less clueful ISPs in the world do not verify the IP space announced to them by their peers (BCP38 is your friend!). This results in things like the time that a telecom in Pakistan hijacked the IP space for most of Youtube about ten years ago and successfully DDoSed themselves, while also causing a major youtube outage.

https://www.google.com/search?q=pakistan+bgp+hijack+youtube&...

This will keep happening until various ISP peers properly implement prefix-list filtering, ACLs on their edge BGP connections, and verifying peer announcements via things like various route registries.

1.1.1.1 is the primary IP for CloudFlare’s new DNS service. A BGP Hijack is when the destination route for that IP changes from it’s legit target to somewhere else. Often times it’s accidental but could be part of a wider attack.

In the case of DNS it’s particularly nasty as the attacker would control address resolution (say redirecting traffic for your bank to a phishing site) for everyone using 1.1.1.1 without more specific mitigations. Combined with long DNS cache times this could be a problem for a while.

personally im not super familiar but i found this recent article from cloudfare that gives some background information https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/

Cloudflare operates a public DNS server on 1.1.1.1 that has gotten a lot of attention since it was launched a few months ago. If a bad actor hijacks it, they can answer DNS queries with malicious answers, similar to the Amazon Route53 hijack that was used to redirect an Etherium wallet site to a fake server: https://www.internetsociety.org/blog/2018/04/amazons-route-5...

They could also simply log all the information and have made the server appeared to continue to operate as normal, since most fooling with the DNS packets would yield certificate errors for many sites (Google, YouTube, etc.) Most of the time someone comes out and says the BGP hijacking was an accident.

A bit of a Hanlon's razor situation.

1.1.1.1 is a DNS resolver that does not track activity. A BGP compromise means that someone could have compromised it and redirect/intercept traffic of those trusting it to be Cloudflare.

A BGP attack does not compromise the destination host. It reroutes (some) traffic destined for the host. Any traffic using TLS to establish destination authenticity (e.g DNS TLS, DNS over HTTP) or content authenticity (e.g. DNSSEC) would detect the attack, while other types of traffic (traditional DNS) could be exploited.

Isn't the point that the attacker could compromise that promise of non-tracking? They could track whatever is routed through them and then forward them on to the legitimate destination.

This could be a first step to compromise TLS traffic as well: https://www.princeton.edu/~pmittal/publications/bgp-tls-hotp...

DNSSEC does not in fact mitigate BGP attacks, because to the extent it works at all, DNSSEC protects only the mapping between IP addresses and names. A BGP attacker controls the semantics of the addresses themselves, and can simply leave DNS pointing where it's supposed to, but hijack the underlying address.

TLS, on the other hand, does address this attack, because controlling all the traffic to a TLS-protected site still doesn't give you a private key that produces a valid signature on a certificate for that site.

"Any traffic using TLS to establish destination authenticity (e.g DNS TLS, DNS over HTTP)"

Well, unless you can also fool Let's Encrypt from all their locations around the world. Then you can get a Let's Encrypt certificate.

Traffic meant to go to 1.1.1.1 (cloudflare DNS) could be routed elsewhere. Since this is a common DNS server, this could be used to alter domain resolution for people that use it.

I'm assuming this would/could be done by a malicious party in order to substitute different IP addresses for some sites in an attempt to direct traffic for nefarious purposes.

If my host is configured to use DNSSEC would that prevent sites from resolving?

If DNSSEC is not employed and a connection is directed to a malicious site (using https) wouldn't that prevent the connection?

(I'm afraid I'm out of my depth on the implications of this aspect of networking and wondering about the security implications for me since I'm using Cloudflare DNS servers.)

For DNSSEC: it depends, I don’t think many clients hardfail yet. For HTTPS: if you can BGP attack, theoretically you could get a TLS certificate issued.

There’s a lot of ifs on both those roads, though.

Probably a good use case to pin the certificates for your upstream DNS resolvers if you're using DNS over TLS/HTTPS.

Yeah. As of right now there’s no absolutely fool proof way to ensure all clients aren’t possibly going to slip through some crack, and I’m not sure if we’ll ever get there.

Somebody other than Cloudflare (the current holders) of the IP is receiving some of the traffic meant for it. Usuall hijack reasons are to point users to fake sites (I point yourbank.com to my own server) and phish.

could be a problem for wifi captive portals that redirect to 1.1.1.1, but most of them would never route to begin with. However, I believe the real issue is that it is a free DNS server, so someone could redirect all domains that do not use ssl pinning.

If true it means that Cloudflare's DNS server can't be trusted.

Do you mean it can't ever be trusted? Or just right now? BGP hijacking isn't that difficult to pull off.

I hope you're not trusting 8.8.8.8 either: https://twitter.com/bgpmon/status/445266642616868864

That's not correct, anyone could 'accidentally' do this to every other provider. It's not a special weakness of cloudflare.

I'm sorry, I went for brevity because someone was asking for possible impacts. If I were using 1.1.1.1 as a DNS server and saw this news story, I would change to a different DNS server until the problem was resolved.

My goal was to provide actionable information quickly.

I never said it was specific to Cloudflare. :) It is specifically a mistake which would break an assumption - that putting 1.1.1.1 into your resolver results in an answer from Cloudflare. DNS doesn't necessarily have any protections (not current, so maybe they were added?), so the only level of protection is that the IP address routes UDP traffic where we expect it to.

It also isn't a long-term problem, it only remains for the length of time the route is wrong.

It could also be argued that we're already trusting every router between the device and 1.1.1.1 anyways, so there's not much difference. Except that there's already a trust relationship between those groups, and the new route subverts them.

It's the same level of risk if someone had done a BGP hijack of any backbone router.

Okay, thanks for your polite explanation.

If you use your providers resolvers you would be very unlikely to have this problem (it's not likely someone will re-route the traffic on the network of the provider themselves).

Reply on news.ycombinator.com