Live data from Hacker News

Possible BGP hijack of 1.1.1.1

bgpstream.com

91–100 of 158 posts

Re: Possible BGP hijack of 1.1.1.1

#91
post #86

Earlier quoted context omitted.

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/i…

[deleted]

Re: Possible BGP hijack of 1.1.1.1

#92

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? :-/

In fact, they usually use 172.10.x.x on their PtP address...

That isn't a reserved/private network either.

Re: Possible BGP hijack of 1.1.1.1

#93

Does anyone else find it sort of beautiful watching replays of events like this? It's amazing to watch how the routers organise themselves, making and breaking connections when needed.

yes, what JS library does that graph drawing and animation? Or a similar one?

Re: Possible BGP hijack of 1.1.1.1

#94
post #31

Earlier quoted context omitted.

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 w…

1) would take about 20 seconds, thanks to Let's Encrypt, but probably only marginally more time for some other CA with an API.

2) Who exactly is staring at CT logs and going "oh, I don't remember this domain using this CA, maybe I should investigate this" ? Sure there's a record of it. Doesn't really matter during an attack, because public attacks like this aren't intended to last long.

All you need is a half hour or less to steal a couple hundred million from a bank, or cryptocurrency wallet, using this attack. That's more than enough incentive for most unscrupulous 3rd world hackers.

If you're an authoritarian government, you could require CAs in your country to selectively quiet CT logs by certain users, and just issue certs willy-nilly for your private government org for MITM purposes. Google Chrome would detect them for Google-owned properties, but smaller sites would never know. And spy agencies can use this at their leisure and basically never be held accountable, because world politics.

Let's face it. The CA system is a joke and BGP is the butt of it.

Re: Possible BGP hijack of 1.1.1.1

#96

Earlier quoted context omitted.

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 resolve…

[deleted]

Re: Possible BGP hijack of 1.1.1.1

#98

Earlier quoted context omitted.

In fact, they usually use 172.10.x.x on their PtP address...

That isn't a reserved/private network either.

I shake my head in bewilderment when I see stuff like this - just why would people make things harder for themselves. I very highly doubt that they are so large that they ran out of IP space in the enormity of 172.16/12 to encompass all of their OSPF/BGP router-id /32s and individual /30 OSPF router-to-router links.

Re: Possible BGP hijack of 1.1.1.1

#99

Earlier quoted context omitted.

Better now?

Just tested - loaded. Site seems to be working, have wandered about a bit. What was the problem?

One of BT's routers was rebooted as a result of this report and that seems to have cleared up the problem.

Thank you for all your assistance in this - and also everybody else that helped to pinpoint the problem.

Re: Possible BGP hijack of 1.1.1.1

#100
post #32

Earlier quoted context omitted.

Hey, what software are you using to collect the data and display that graph? I wouldn't mind running something on my server that could notify or log if 1.1.1.1 (and other services I rely on) are slow or down.

That looks like smokeping

more specifically looks like smokeping, rra file storage and rrdtool to draw the graph. Compared to modern things like influxdb+grafana it is a very oldschool setup but still works perfectly fine.
Post reply on HN