Possible BGP hijack | Hacker News Reader

Possible BGP hijack

bgpstream.com

318 pointscaaqil70 comments

Prefix 31.148.149.0/24 is normally announced by AS212463 HE shows belongs to https://dataline.ua/en/ which is a Ukrainian company. https://bgp.he.net/AS35297

Is now being announced by AS35004 which HE shows is Ukrainian hosting provider https://netgroup.ua/

But the "Country of origin" of the AS is listed as Russian, which is perhaps where the confusion comes from. https://bgp.he.net/AS35004

About 95% of new AS35004's traffic goes through this peer: (which is Ukrainian) https://bgp.he.net/AS13249

And this peer: (which is Ukrainian) https://bgp.he.net/AS3326

Both of which Peer with Cogent.

What is interesting is that Cogent today decided to cut service to Russia. https://www.reuters.com/technology/us-firm-cogent-cutting-in...

If I was an ISP had networks from UA and RU and my Cogent peering was removed from Russia, I might move some of my traffic through my partner in Ukraine, who does have a peering arrangement with Cogent. I haven't confirmed that is what happened, but you would see this kind of shift I think if they did that.

I'm a security guy and not a CCIE so perhaps a Cisco engineer here can weigh in.

10 year CCIE and ex-Cisco engineer here: I think you nailed it.

What's interesting (to me, at least) is that there's an (signed) ROA for 31.148.149/24 and AS212463 is listed (IRR) as a valid origin AS -- AS35004 isn't.

All things considered, though, I'd find an explanation of "yeah, didn't have time to update the route objects yet" to be completely acceptable.

Same situation with 95.47.59/24, by the way.

(I let my Cisco certs lapse a decade or so ago, although I've certainly originated a prefix or two over the years.)

In simple terms you are saying this is probably not a hijack?

If I've understood it correctly it's not a hijack but rather a circumvention of Cogents RU peering block.

I didn't understand a thing of what you said. Any recommended readings to know a bit more about this topic?

I highly recommend Kurose/Ross' Computer Networking book for a place to start. As the title suggests, it's a "top down approach" starting at the application layer, so if you're familiar with application network programming (and especially HTTP) you can probably skip the early parts of the book. It then details routing protocols, of which there are 2 major kinds: interior routing protocols (RIP, OSPF, EIGRP, iBGP, et al) and exterior routing protocols (eBGP). The former is for routing within your "autonomous system", the latter is for routing between autonomous systems.

This is known as the BGP book: https://www.amazon.com/Internet-Routing-Architectures-2nd-Ha...

It goes into detail. If you're just starting out, get a Network+, Security+ or any other systems administration, security or networking certification that covers the basics of networking and internetworking.

ELI5 "in Paw Patrol terms" from Stamos: https://twitter.com/alexstamos/status/1499873636500475904

It might be a false positive: https://twitter.com/mdhardeman/status/1499877247167209480

Wtf is mayor goodway? And why is he in this confusing analogy?

Mayor Goodway is the mayor of fake-San-Francisco ("Adventure Bay") in the kids' show "Paw Patrol". Also, she is a woman, so I'm not sure why Mayor Goodway is referred to as "he"

They probably meant Mayor Humdinger instead.

Are you assuming Mayor Gooday's gender? /s

It's a joke; somebody asked for a Paw Patrol analogy. It's not actually an explainer, and wasn't intended to be taken as such.

"Paw Patrol Explainers Considered Harmful"

In this thread, I will deconstruct... (1/49)

OH MAH GAWD PATRICK

(I know youre not patrick, I made that joke almost a decade ago!)

I just haven't seen you 'round these parts recently....

May you please provide a link to your analysis of WTF might happen in recent-future times?

I was predicting a major infra/cyber war...

It seems that actions of the world have curbed that enthusiasm...

However; the spectre lingers from an info/dev/ETC/sec position ; here me out:

---

Aside from what we are seeing in the global political frame ; which means nothing to political aspirations on the personal level :

We are seeing a MASSIVE shift on the authoritarian control to global HUMAN mobility in all : Mindshare, Finance, Tech, Social-Acceptability, etc.

The RESET. is in changing the mindshare around such topics.

Lets take into your realm: Cyber-Sec...

---

Extrapolate 10 years. If you have not done so already,

What will cyber-sec look like in 10 years?

What will ID look like?

What will currency access look like?

What will financial channels for individuals look like?

What will access to "goods and services" by those who wish to not deal with "the system" look like?

What will social-mobility look like?

If you are not evaluating and thinking about this, I do not trust you

Pretty sure this is paw patrol but agreed, from the outside, it's incomprehensible. (I'm on the outside with you)

I think I have a Voltron analogy somewhere that can explain the Paw Patrol one...

It is a false positive. Both the originating and "hijacking" AS are the same Ukrainian ISP (Netgroup).

The advertising ASN does not share any upstream peers. So it might not be a hijack, but it is an interesting event and could be related to the conflict.

Untangling ISPs that have operated in both countries or with subsidiaries is going to get messy while infrastructure is also getting destroyed.

It’s VERY likely a false positive. It’s the same ISP

It is quite plausible that Russia would try to take down parts of Ukraine internet given everything going on.

Alternatively, could simply be someone fat-fingering things, given the insane numbers of blocks that RosKomNadzon has been putting in today (Facebook, Twitter, etc)

I read an article (in Russian, will link later) outlining a plan to copy current BGP tables, update them so that the Russian internal internet space is encircled with government-controlled ASes, and filter or block any outside access, while making the BGP inside Russia look synchronized with the rest of the world. Of course this applies to all BGP announcements from outside the perimeter.

Not exactly a great firewall with packet inspection, but still something to prevent any possibility to access any resources except whitelisted ones, or to run a VPN to the outside.

Update: the article in question, Google-translated: https://whatisyournameinsider-com.translate.goog/politika/24...

If Russia is preparing to up its information warfare game does this give them better defenses against inbound attacks? While letting FSB selectively allow outbound attacks?

Gentle reminder: You can still generate valid TLS certificates for arbitrary domains with BGP hijack. Hide yo logins, hide yo passwords, and hide yo persistent sessions too, they hijackin' errrbudy up in here

I assume the mechanism here is to hijack the DNS servers? Does DNSSEC protect against this?

E-mail, DNS, and HTTP validation are all vulnerable (so, all the methods besides ACME). As for DNS validation, DNSSEC is opt-in; if one of the 350 different Certificate Authorities doesn't do mandatory stub validation, then the hijack still works on them.

There's actually multiple attacks using BGP. You can either hijack the DNS or E-mail server's IP and spoof records, or you can hijack the IP of the target host and spoof an HTTP response. Or you could try all 3 to maximize your chances.

There are non dns mechanisms as well - you can directly hijack the websites ip address instead of their dns server.

In theory i think https://en.m.wikipedia.org/wiki/Resource_Public_Key_Infrastr... is the thing that's meant to stop this attack if everyone adopted it.

Chrome doesn't support DNSSEC sadly. https://bugs.chromium.org/p/chromium/issues/detail?id=50874

Doesn't seem to matter: https://twitter.com/colmmacc/status/1494047770428149761

That's like saying the lock on the front door did not prevent intrusion because the burglar went in through the window.

As tptacek will tell you, there's never any situation where DNSSEC would help. For instance, it doesn't mean your own DNS lookups to 1.1.1.1 are secure, but it does mean Libya is a CA for bit.ly.

Although trying to turn it on did take Slack and HBO down in the past, so someone out there cares.

Never helps. Causes outages. Route all your DNS through 1.1.1.1 or 8.8.8.8 instead. Sheesh. In Ancient Rome, weren't dictators expected to vacate office once their task had been accomplished and decentralized solutions were ready to once again take hold? Why is it that I always feel the heat whenever I voice words of support for DNSSEC?

Because DNSSEC is a bad protocol that nobody serious uses, with an inexplicably committed cheering section.

DNSSEC worked mostly fine for Slack, except that their DNS provider, Route 53, initially had a bug where wildcard records on DNSSEC would not get correctly signed. It was when Slack panicked and tried to turn off DNSSEC when they completely bungled it and borked their whole setup.

This is the funniest apology for DNSSEC I've ever read. It's fine, as long as you never try to turn it off! Or use Route53! Don't do that, or your whole site will fall off the Internet for a day. Got it!

As a well-known person on HN, that amount of snark is unbecoming of you. FWIW, you can bork your own system just as much, if not even more so, with HSTS headers. And also with DNS in general; how many people have mucked up a DNS setting and then have no recourse but to wait it out? The issue was not DNSSEC, but Slack who panicked and pulled the plug on themselves.

It's not snark if you're mocking the person you're talking to. That's just disrespect. Maybe he's had bad experiences in the past with DNSSEC that are causing him to forget himself. I feel like he's been talking down to me too.

DNSSEC is continuing to have a bad experience with tptacek, really. The Rorschach of DNSSEC, if you will.

Read it again. I'm not "mocking the person I'm talking to". I don't even know the person I'm talking to. I'm mocking the statement they made, that DNSSEC is fine, and when it blows your whole site off the Internet because you dared turn it off after it immediately caused problems the moment it was turned on, well, you were just holding it wrong. It really is funny! Read their comment again, too!

I suppose I could be less snarky, but my snark here is substantive, and I'm comfortable with what it says about my seriousness. You're going to have to do better than trying to work the refs here.

DNSSEC is, unsurprisingly, designed to secure DNS only. It only tells you that the answer you received is authentic. DNSSEC would prevent a DNS server being hijacked via BGP being evil in that it couldn't give bad answers.

It however doesn't typically help in a BGP hijack. The DNS answer is authentic, but the server at the answer given isn't.

DNSSEC could be used to protect against it, if TLS cert issuing policies were tightened by folks who mandate the minimum verification requirements for CAs, but this is not currently done. (eg Let's Encrypt supports DNS verification as one mechanism currently, but it also supports plaintext HTTP which is vulnerable to BGP hijack)

Check the CT logs for bandits!

How exactly would one do that? CT logs don't have traceroutes. They don't even have IP addresses. https://crt.sh/?q=ycombinator.com

check CT logs vs your own issuance records, and look for discrepancies. Look for issuance during the hijack period. Etc

wait how? CA workflows should still work and be able to break this?

If you can hijack the traffic you can respond to http challenges from CAs and they will give you a valid certificate. In theory the certificate owner should spot this via CT, but it’s not automatic.

aren't root CAs installed inside browsers and OSes so that they can't be hijacked without physical access to the target victim device?

The attack (I think) would work like this:

- You own the domain trust.org pointing to IP address 2.3.4.5.

- Someone performs a BGP hijack on 2.3.4.5 and now hosts their own server on 2.3.4.5.

- They then ask Letsencrypt for a certificate to prove they are trust.org. Letsencrypt provides them a token to host on their website to prove they control it.

- Letsencrypt does a DNS lookup, sees trust.org resolves to 2.3.4.5, and performs a http request to that website to check for a token which the hijacker has duly placed on their server at 2.3.4.5.

- Letsencrypt issues a certificate for trust.org, which is now valid and controlled by the hijacker.

None of this requires access to CAs installed on anyones machine, because Letsencrypt is widely trusted and they are the ones issuing the cert.

When the CA is giving you, supposedly the owner of someguy.example, a new certificate, how do they verify that you're you first?

One common way is they tell you a magic, unique string and you serve it under someguy.example/.well-known/whatever and they connect to you and verify it's there and matches. But if BGP is being hijacked, when they connect to you, they could really be connecting to some scammer. How would they know? So now some scammer has proved they're you and they'll be given a valid cert for someguy.example.

The other common verification methods have similar holes.

CAs currently run on the assumption that the underlying internet is....somewhat fine.

FWIW let's encrypt does multi perspective validation, but it is not a requirement currently.

The best thing to do as a site owner is to regularly check CT logs or use a service that does that for you.

I'm not sure CT logs would help in practice. Assuming a site owner religiously monitors CT logs (who actually does that?), notices a cert they didn't mean to issue, and then issues a CRL or OCSP change (do most people even know how to do that?), the client application has to download the lists and respect it, and many (most?) clients do not.

The site owner may know about the compromised cert, but the users/clients will be blissfully ignorant and unable to do anything about it.

There are initiatives to make certificate revocation better.

As of now, the world's most popular browser does not support OCSP. So revoking a cert kinda has no impact on chrome.

As we go forward, crlite is going to be required by Apple around October of this year. It's probably our current best option for browsers to use.

But yeah, you're not wrong. At the very least it would give you an idea that you were targeted and give you an idea that you need to plan for DR.

CA's verify the person that the domain is pointing to. If the domain is pointing to a malicious server (due to bgp making IP addresses belong to an evil person), then the CA will verify the malicious server instead.

love the hide yo kids, hide yo wife, and hide yo husband reference!

This says the prefix being announced by two ASNs is only a /24, which is kind of narrow for a hijack? Considering the countries involved, reporting this as a hijack will inevitably lead to people assuming it is related to the current conflict.

AS212463 only announces 2 /24 prefixes in total so it being only 1 isn't a big sway one way or the other. The company being the same just across the 2 countries makes it less likely to be something militarily malicious but doesn't necessarily mean it's unrelated to the current conflict.

A /24 wouldn't propagate much farther than the nearest IX and immediate peers, as presumably peers have learned to aggregate and filter in the last 20 years. At face value, it really seems like a shift to backup routes. Also, state level attacker view, hijacking a route from another ASN is a bit 3rd world, as if you were a superpower, you'd have already hacked the routers in question and would just loop traffic through and MPLS tunnel to your analysis centre.

> A /24 wouldn't propagate much farther than the nearest IX and immediate peers, as presumably peers have learned to aggregate and filter in the last 20 years.

... and yet the global BGP table is absolutely full of /24s.

Is Raleigh Mann not still the canon state of truth on BGP?

I noticed reddit and other big websites were somewhat slower at one point those couples of days... I live in Europe and I wonder...

Did you do a traceroute?

me too, Russian sites don't load at all

Reply on news.ycombinator.com