Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Possible BGP hijack of 1.1.1.1

bgpstream.com

Post reply on HN
Print view View original

81–90 of 158 posts

Re: Possible BGP hijack of 1.1.1.1

#81

Post by padiyar83 »

sdfgdfhjdgj wrote: post #66
akw28888 wrote: post #41

I'm using AnchNet's services. And We've asked AnchNet when I recieved a e-mail from our BGPMon. They said their staff was configured a wrong config on router. Also they don't know 1.1.1.0/24 is used by CloudFlare&APNIC. So they used this prefix to test.

Why let people access BGP that don't even know that 1.0.0.0/8 or 1.1.1.0/24 are part of the public internet or that decide they can use random prefixes to "test" things? :-/

Usually upstream ISP providing transit accepts only a valid set of prefixes that they have agreed to advertise on the public internet from an ISP customer, they enforce a policy on the ingress to make this happen. Idea being, if the customer ISP ends up advertising an incorrect prefix, then the impact is only localised to his ISP and not to the whole world. But some ISPs don't follow this and implicitly trust the customer ISPs and of course there is no cover if the tier1 ISP itself typo's a prefix. There are tools such as BGP RPKI available, but its not widely deployed.

Re: Possible BGP hijack of 1.1.1.1

#82

Post by jpollock »

Latteland wrote: post #29
jpollock wrote: post #3

Earlier quoted context omitted.

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

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.

Re: Possible BGP hijack of 1.1.1.1

#83

Post by dogecoinbase »

sdfgdfhjdgj wrote: post #66
akw28888 wrote: post #41

I'm using AnchNet's services. And We've asked AnchNet when I recieved a e-mail from our BGPMon. They said their staff was configured a wrong config on router. Also they don't know 1.1.1.0/24 is used by CloudFlare&APNIC. So they used this prefix to test.

Why let people access BGP that don't even know that 1.0.0.0/8 or 1.1.1.0/24 are part of the public internet or that decide they can use random prefixes to "test" things? :-/

I'm not sure when modern tech got this idea that if everyone has been using something "wrong" for decades, it's still wrong. That space has never been previously announced, it's assigned to APNIC for _research_, it's in dozens of makes and models of router as admin interfaces, blackholed or otherwise.

I get the impulse to say "you used it wrong, now it's broken", but we didn't get to a functioning worldwide internet with that attitude. We got here by observing what people were actually doing and coming to a consensus view on what to break and what to carefully tread around (you know, UX). This is an obvious example of the latter and the fact that APNIC let CF use this space for a production platform in the name of breaking shit is frankly disqualifying (in terms of their overall trustworthiness as curators of essential IN infrastructure).

Re: Possible BGP hijack of 1.1.1.1

#84

Post by tialaramex »

moviuro wrote: post #31
amaccuish wrote: post #20

And that is why I'm using dns over tls :)

Not enough. You have to check the certificate's fingerprint, along with its validity. TLS is not a silver bullet. If an attacker controls the host behind what everyone believes to be 1.1.1.1, nothing is to prevent them from applying for a legit certificate.

Nothing prevents them from applying but...

* They need to do that, and get the resulting certificate, and install it, during the attack. The weirder the product (and certificates for IP addresses are relatively weird) the more humans end up involved in your order, and humans are slow.

* This leaves a smoking gun in the Certificate Transparency logs. So we all get to know (in maximum 24 hours but usually the reality will be minutes) about this extra certificate.

Re: Possible BGP hijack of 1.1.1.1

#85

Post by jacquesm »

ColinWright wrote: post #55
jacquesm wrote: post #45

Earlier quoted context omitted.

I wonder if it is a resolution issue or an access issue. What happens when you go to: http://62.129.133.242/ ? That should come up with a 'domain for sale' page, that's the same server.

Not loading for me. UK : 79.69.113.214 : Tue May 29 16:06:38 BST 2018

Better now?

Re: Possible BGP hijack of 1.1.1.1

#86

Post by dice »

padiyar83 wrote: post #81
sdfgdfhjdgj wrote: post #66

Earlier quoted context omitted.

Why let people access BGP that don't even know that 1.0.0.0/8 or 1.1.1.0/24 are part of the public internet or that decide they can use random prefixes to "test" things? :-/

Usually upstream ISP providing transit accepts only a valid set of prefixes that they have agreed to advertise on the public internet from an ISP customer, they enforce a policy on the ingress to make this happen. Idea being, if the customer ISP ends up advertising an incorrect prefix, then the impact is only localised to his ISP and not to the whole world. But some ISPs don't follow this and implicitly trust the cus…

>Usually

If only...

BCP 38[0] is nowhere near usual. Lots of networks, including some very problematic big ones (cough Hurricane Electric cough), do not implement it as a matter of course. The AWS Route53 hijack last month which resulted in downtime for a number of sites plus a six figure coin theft[1] could have been prevented by adequate filtering.

0: https://tools.ietf.org/html/bcp38

1: https://arstechnica.com/information-technology/2018/04/suspi...

Re: Possible BGP hijack of 1.1.1.1

#87

Post by walrus01 »

dogecoinbase wrote: post #83
sdfgdfhjdgj wrote: post #66

Earlier quoted context omitted.

Why let people access BGP that don't even know that 1.0.0.0/8 or 1.1.1.0/24 are part of the public internet or that decide they can use random prefixes to "test" things? :-/

I'm not sure when modern tech got this idea that if everyone has been using something "wrong" for decades, it's still wrong. That space has never been previously announced, it's assigned to APNIC for _research_, it's in dozens of makes and models of router as admin interfaces, blackholed or otherwise. I get the impulse to say "you used it wrong, now it's broken", but we didn't get to a functioning worldwide internet…

I don't disagree with you that things have coalesced by consensus over a period of the past 25 years, for what IP space people should and can use, and what IP space you shouldn't use (eg: I have no doubt that a bunch of enterprise end users are using some of the US military/DoD assigned /8s internally, because those never show up on the global internet. It's wrong, but they do it anyways).

However, the RFC1918 IP ranges have existed for a very, very long time, as have the standard documentation/example IP ranges which Cisco, Juniper and others have been using in their training and example publications since 1995 or so. People have had more than twenty years to number their internal networks into the ranges that, also by consensus, the global internet community has decided to make non-globally-routable (192.168, 10.x, 172.16, etc). RFC1918 was published 22 years ago so there is really no excuse.

If you are using 1/8 in the year 2018 for your own internal production traffic, you are wrong and should feel bad. IANA and APNIC (and APNIC's contracted partner, Cloudflare) should be able to begin using ranges as granular as an individual /24 within this /8 on the public Internet without worrying that people who have misconfigured their shit will have a broken experience. It will take time for people to move their misconfigured erroneous configurations into normal RFC1918 IP space, but it will happen eventually. Or maybe not, if v6 adoption speeds up this becomes irrelevant.

Re: Possible BGP hijack of 1.1.1.1

#88

Post by charonn0 »

sdfgdfhjdgj wrote: post #66
akw28888 wrote: post #41

I'm using AnchNet's services. And We've asked AnchNet when I recieved a e-mail from our BGPMon. They said their staff was configured a wrong config on router. Also they don't know 1.1.1.0/24 is used by CloudFlare&APNIC. So they used this prefix to test.

Why let people access BGP that don't even know that 1.0.0.0/8 or 1.1.1.0/24 are part of the public internet or that decide they can use random prefixes to "test" things? :-/

To be fair 1.1.1.1 had been unassigned/non-routable up until April.

Re: Possible BGP hijack of 1.1.1.1

#89

Post by Diederich »

carbocation wrote: post #49
jacquesm wrote: post #45

Earlier quoted context omitted.

I wonder if it is a resolution issue or an access issue. What happens when you go to: http://62.129.133.242/ ? That should come up with a 'domain for sale' page, that's the same server.

Not loading for me from MA, USA. $ httpstat http://62.129.133.242/ 2018/05/29 10:54:04 unable to connect to host 62.129.133.242:80: dial tcp 62.129.133.242:80: connect: connection timed out

+1 for httpstat; I'd not seen this utility before, quite nice!

Re: Possible BGP hijack of 1.1.1.1

#90

Post by otterlicious »

floatingatoll wrote: post #61
moviuro wrote: post #27

Earlier quoted context omitted.

Well, if you control the host behind the IP, you could have any CA issue a challenge, and successfully pass it (e.g. if Let's encrypt uses the erroneous routes). So no. The only thing protecting you would be to have the expected hash of the certificate you expect to see (TOFU - Trust on First use, though you're screwed if you didn't contact 1.1.1.1 before the incident!).

Is there a CAA equivalent for ARIN assignments?

Not yet. :-(

https://tools.ietf.org/html/draft-shoemaker-caa-ip-01

Post reply on HN