Some years back, Russia hijacked a BGP belonging to a major transit provider. For a few hours, international traffic was rerouted thru Russian networks where it could be cloned (like the NSA does in the states) and examined.
They could have been after something specific in the traffic but my unqualified guess is that it was a test or they were showing off.
Surely OpenNet/ClassNet/NIPRNet/SIPRNet/GWAN/JWICS aren't accepting BGP updates, where they even touch public network infrastructure.
If i understand, the article is not so much a typical bgp hijack but the attacker gaining control of their account that controls routing. Seems like private networks would be just as vulnerable to that.
As they stated, European gov networks (plus military and universities OFC) had and still have their private backbone. In Spain, RedIris was for scientific research, universities and such. IDK about the rest, but for sure they'd have a similar approach.
Generally yes, but there is a slight mitigating factor that certificate transparency makes it very public who you are attacking.
In theory, if it was just your site ip that was attacked and not your dns provider, CAA record can protect you. Probably one of the few cases where dns-sec is actually useful. All that though is an edge case that probably doesn't apply 99% of the time.
Hijacking the IP would indeed allow you to respond to ACME HTTP-01 validations. That can be protected against by using RFC 8657: Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding (https://datatracker.ietf.org/doc/html/rfc8657). RFC 8657 extends the CAA record to say "Only this specific CA account may request certs for this domain" and/or "Only this specific validation method may be used when requesting certs for this domain".
Well, the new certificate shows up, but so what? CT logs aren't like "Barry Shitpeas got a certificate for hugecorp.example" they just tell you what was issued, not why, not who in any useful sense was issued it, and they take up to 24 hours to do that.
What is the overlap between the set of people who think "pass1234" is a good password and the set of people who have great oversight of their cert issuance and would flag unexpected issuances ? I'd expect it to be approximately empty.
… they just tell you what was issued, not why, not who in any useful sense was issued it …
They give you the certificate, which contains the issuer's CPS. If it's an issuer that you (the domain owner) don't recognize, you have at least a starting point for reaching out.
… and they take up to 24 hours to do that.
Indeed, the Maximum Merge Delay is 24 hours. But in practice, by monitoring multiple CT logs, it takes just a minute from successful issuance to having the certificate show up in at least one CT log (see https://utcc.utoronto.ca/~cks/space/blog/web/WebProbeSpeedNe...).
Comments
What evil could one do with this?
Some years back, Russia hijacked a BGP belonging to a major transit provider. For a few hours, international traffic was rerouted thru Russian networks where it could be cloned (like the NSA does in the states) and examined.
They could have been after something specific in the traffic but my unqualified guess is that it was a test or they were showing off.
Curious to speculate about.
If you could temporarily redirect BGP at an arbitrary time, at diplomatic risk, what would be the best use of that?
Surely OpenNet/ClassNet/NIPRNet/SIPRNet/GWAN/JWICS aren't accepting BGP updates, where they even touch public network infrastructure.
And I can't think of anything outside those huge spheres that would be worth burning a capability like that on a lark.
Maybe bulk sensitive data transfer? I.e. some site-to-site backup?
Or you're just looking at the metadata of where-to-where, with the goal of finding future targets.
I went back and looked up the event. Rostelecom has been behind a few of these. I might be conflating two of them.
In 2017, Rostelecom grabbed financial & other network data for a few minutes. https://www.thousandeyes.com/blog/rostelecom-route-leak-targ...
In 2020 Rostelecom announced lots of networks they didn't own and got that traffic for an hour. Early analysis felt it was accidental. Not sure about later analysis. https://www.zdnet.com/article/russian-telco-hijacks-internet... https://news.ycombinator.com/item?id=22789754
But 2 months ago, Rostelecom grabbed a chunk of Apple's network (which I missed) https://cybernews.com/apple-network-traffic-went-through-rus...
If i understand, the article is not so much a typical bgp hijack but the attacker gaining control of their account that controls routing. Seems like private networks would be just as vulnerable to that.
In the case of the article / Orange, possibly.
Though I'd hope that Orange doesn't provide network management services for the Spanish military! Some things are better kept in-house.
Less familiar with how European sensitive networks are architected.
As they stated, European gov networks (plus military and universities OFC) had and still have their private backbone. In Spain, RedIris was for scientific research, universities and such. IDK about the rest, but for sure they'd have a similar approach.
Some governments have physical tunnel networks to move people who matter around. Computer networks follow pretty much without a loss of generality.
Indeed, RedIris in Spain, since late 80's or maybe early 90's, can't remember.
Encryption on higher level protocols (https) can do a lot to reduce potential impact.
Big impacts that come to mind (depending on what is being hijacked):
- dos attack
- pasive eavesdropping (not of encrypted contents, but who is connecting to who)
- hijacking plain http
- hijacking things like ssh where nobody pays attention to the mitm warnings
- potentially creating a new tls certificate to further do a later attack
Hijack the ip or dns entry and you break https as it’s trivial to get a new certificate and prove ownership of the DNS address adult the time.
Generally yes, but there is a slight mitigating factor that certificate transparency makes it very public who you are attacking.
In theory, if it was just your site ip that was attacked and not your dns provider, CAA record can protect you. Probably one of the few cases where dns-sec is actually useful. All that though is an edge case that probably doesn't apply 99% of the time.
The same could be said for many necessary security measures.
Hijacking the IP would indeed allow you to respond to ACME HTTP-01 validations. That can be protected against by using RFC 8657: Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding (https://datatracker.ietf.org/doc/html/rfc8657). RFC 8657 extends the CAA record to say "Only this specific CA account may request certs for this domain" and/or "Only this specific validation method may be used when requesting certs for this domain".
Let's Encrypt has supported RFC 8657 for over a year now: https://community.letsencrypt.org/t/enabling-acme-caa-accoun...
But then you show up on certificate transparency logs pretty quickly, no?
Well, the new certificate shows up, but so what? CT logs aren't like "Barry Shitpeas got a certificate for hugecorp.example" they just tell you what was issued, not why, not who in any useful sense was issued it, and they take up to 24 hours to do that.
What is the overlap between the set of people who think "pass1234" is a good password and the set of people who have great oversight of their cert issuance and would flag unexpected issuances ? I'd expect it to be approximately empty.
They give you the certificate, which contains the issuer's CPS. If it's an issuer that you (the domain owner) don't recognize, you have at least a starting point for reaching out.
Indeed, the Maximum Merge Delay is 24 hours. But in practice, by monitoring multiple CT logs, it takes just a minute from successful issuance to having the certificate show up in at least one CT log (see https://utcc.utoronto.ca/~cks/space/blog/web/WebProbeSpeedNe...).
I imagine letsencrypt is checking if any certs were issued from the hijacked IP-range during the outage, and is moving to revoke those certs?
Presumably the site owner would be the one monitoring CT. If they see there's a rogue certificate, they can take steps to get it revoked.