[HN Gopher] Possible BGP hijack
___________________________________________________________________
Possible BGP hijack
Author : caaqil
Score : 312 points
Date : 2022-03-04 22:34 UTC (1 days ago)
(HTM) web link (bgpstream.com)
(TXT) w3m dump (bgpstream.com)
| cjbprime wrote:
| 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
| randomhodler84 wrote:
| Wtf is mayor goodway? And why is he in this confusing analogy?
| umvi wrote:
| 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"
| pelasaco wrote:
| Are you assuming Mayor Gooday's gender? /s
| fintler wrote:
| They probably meant Mayor Humdinger instead.
| tptacek wrote:
| 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.
| secalex wrote:
| "Paw Patrol Explainers Considered Harmful"
|
| In this thread, I will deconstruct... (1/49)
| randomhodler84 wrote:
| gerdesj wrote:
| It may surprise you that I have a different view on the
| world despite speaking the same language as you and
| hanging out in the same place as you.
|
| I have no idea what a paw patrol is (actually I do,
| because I take the trouble to look to things from other
| people's perspective and engage).
|
| Broaden your mind please. Or fuck off. Your choice.
| randomhodler84 wrote:
| ineedasername wrote:
| The issue isn't the particular show or analogy. It's the
| implication of your comment that everyone should,
| unrealistically, try to be an expert in everything and
| thereby never seek a more concise "intuition" when a few
| hundred hours of research and self-study could be had.
| astrange wrote:
| If you don't know what Paw Patrol is then a Paw Patrol
| explanation can't be lowest-common-denominator.
| ehPReth wrote:
| You were new at one point too.
| serf wrote:
| I see validity on both sides of the table.
|
| Yeah, someone new and experienced should have all the
| effort possible put into them by others trying to catch
| them up..
|
| on the other hand the whole 'ELI5' phenomenon really has
| no place in niches that really have no point to be
| generalized for the average population.
|
| 'ELI5' breaks down when comprehension of multiple topics
| is required for elucidation; i.e.: a layman's explanation
| of quantum chromodynamics requires many other base level
| comprehensions before it can be tidily explained.
|
| The 'ELI5' thing is cute, and it has a place -- but it
| shouldn't be generalized to all education across the
| board.
| Cottages wrote:
| I feel this way whenever I have to explain that, no, sex
| is not a binary related to XX or XY, there's lots of
| genetic variations (many of which don't fall neatly into
| male or female).
|
| There's lots of stuff like that across a wide range of
| disciplines -- computer science, biology, sociology,
| physics, economics, etc.
| randomhodler84 wrote:
| For sure. Life is beautiful and nuanced. Anything
| significant is complex, and quantizing a spectrum, or at
| worst, making it monochromatic, takes something from its
| beauty.
| lbotos wrote:
| Pretty sure this is paw patrol but agreed, from the outside,
| it's incomprehensible. (I'm on the outside with you)
| ineedasername wrote:
| I think I have a Voltron analogy somewhere that can explain
| the Paw Patrol one...
| [deleted]
| jsizzle wrote:
| It's VERY likely a false positive. It's the same ISP
| dsl wrote:
| It is a false positive. Both the originating and "hijacking" AS
| are the same Ukrainian ISP (Netgroup).
| secalex wrote:
| 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.
| [deleted]
| drglitch wrote:
| 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)
| nine_k wrote:
| 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...
| stadium wrote:
| 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?
| thamer wrote:
| 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.
| motohagiography wrote:
| 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.
| jlgaddis wrote:
| > _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.
| zamadatix wrote:
| 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.
| mmaunder wrote:
| 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.
| jlgaddis wrote:
| 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.)
| lmarcos wrote:
| I didn't understand a thing of what you said. Any recommended
| readings to know a bit more about this topic?
| 0x0000000 wrote:
| 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.
| mmaunder wrote:
| 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.
| theginger wrote:
| In simple terms you are saying this is probably not a hijack?
| corford wrote:
| If I've understood it correctly it's not a hijack but rather
| a circumvention of Cogents RU peering block.
| 0x0000000 wrote:
| 10 year CCIE and ex-Cisco engineer here: I think you nailed it.
| throwaway984393 wrote:
| 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
| randomhodler84 wrote:
| Check the CT logs for bandits!
| jart wrote:
| 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
| randomhodler84 wrote:
| check CT logs vs your own issuance records, and look for
| discrepancies. Look for issuance during the hijack period.
| Etc
| trooop wrote:
| wait how? CA workflows should still work and be able to break
| this?
| midasuni wrote:
| 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.
| obert wrote:
| aren't root CAs installed inside browsers and OSes so that
| they can't be hijacked without physical access to the
| target victim device?
| mindwok wrote:
| 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.
| kadoban wrote:
| 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.
| aaomidi wrote:
| 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.
| throwaway984393 wrote:
| 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.
| aaomidi wrote:
| 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.
| bawolff wrote:
| 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.
| ushakov wrote:
| love the hide yo kids, hide yo wife, and hide yo husband
| reference!
| advisedwang wrote:
| I assume the mechanism here is to hijack the DNS servers? Does
| DNSSEC protect against this?
| throwaway984393 wrote:
| 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.
| fulafel wrote:
| 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)
| bawolff wrote:
| 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_Pu
| blic_Key_Infrastr... is the thing that's meant to stop this
| attack if everyone adopted it.
| jart wrote:
| Chrome doesn't support DNSSEC sadly.
| https://bugs.chromium.org/p/chromium/issues/detail?id=50874
| astrange wrote:
| Doesn't seem to matter:
| https://twitter.com/colmmacc/status/1494047770428149761
| silisili wrote:
| 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.
| jart wrote:
| That's like saying the lock on the front door did not
| prevent intrusion because the burglar went in through the
| window.
| astrange wrote:
| 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.
| teddyh wrote:
| 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.
| tptacek wrote:
| 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!
| teddyh wrote:
| 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.
| jart wrote:
| 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.
| tptacek wrote:
| 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.
| pvg wrote:
| DNSSEC is continuing to have a bad experience with
| tptacek, really. The Rorschach of DNSSEC, if you will.
| jart wrote:
| 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?
| tptacek wrote:
| Because DNSSEC is a bad protocol that nobody serious
| uses, with an inexplicably committed cheering section.
| samstave wrote:
| Is Raleigh Mann not still the canon state of truth on BGP?
| [deleted]
| jokoon wrote:
| I noticed reddit and other big websites were somewhat slower at
| one point those couples of days... I live in Europe and I
| wonder...
| midasuni wrote:
| Did you do a traceroute?
| ushakov wrote:
| me too, Russian sites don't load at all
___________________________________________________________________
(page generated 2022-03-05 23:02 UTC)