Found via Twitter that others had already tried changing DNS servers, and then did a tracepath and found that I couldn't reach the resolved IP's. Thought it would have been a misconfiguration of Orange. Then on Twitter (accessed via Orange mobile, which funnily worked fine -- probably a different network?) I found a thread of the people in Spain complaining about it, where someone later replied with links to the RIPE account take-over tweet.
Took about 2-4 hours for the service to be fixed. Haven't fixed any other issues so far. One of the articles pointed that it could have been due to someone that was not using 2FA, but there were no sources in that article.
EDIT: the article mentioned above https://bandaancha.eu/articulos/secuestran-cuenta-ripe-orang...
RIPE is the European equivalent of ARIN (the North American regional authority of ISP addressing matters). They are sort of like the postal/zoning agents of the internet in that they oversee the distribution and management of IP address blocks. ISPs like Orange Spain have a RIPE account that they use manage their IP allocations, which is what was compromised.
The RIRs are delegated the numbers from IANA, and they in turn delegate numbers to LIRs, Local Internet Registries, such as an ISP or a maybe a large organisation which has vertically incorporated that functionality.
The RIRs represent, and are paid for by, the LIRs in their region and so to some extent they reflect local consensus, local culture, etc. This means in some sense RIPE's security policies reflect what European ISPs and similar wanted, for good or ill.
Traditional routing has always been very, very open. Like a club where anyone is welcome and if new folks mess stuff up it just gets fixed.
Several IRRs used to allow RPSL changes by email to their systems with only maintainer auth and no verification of route ownership (e.g. you register with the IRR, then publish Google routes).
It’s all getting hardened nowadays with things like no more email, layers of verification, RPKI, etc.
It’s not necessarily what folks want but how this stuff had traditionally been handled. Thankfully it’s all changing because of events like this.
if it's a thing at Orange Spain and they're reusing that excellent scheme for several services (the excellent scheme being adding "admin" after the name), they're in for a world of hurt...
I’ve always liked the professional level of collusion that makes the Internet work. One day it will all go wrong and we’ll have to set up something democratic, but until then the technocracy works well.
Until our CIO went to the bathroom and came back saying "Hey, these websites aren't working from our WIFI network but they're working fine from mobile data? Could it be a navigation problem from Orange?"
Then we realized it.
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.
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.
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
The problem here appears to be that the victim didn't do even a halfway decent job of protecting their RIPE account.
RIPE offers TOTP. TOTP is hardly the best possible security, because it can be phished, but assuming the people using it are competent (and why are your networking team incompetent?) that ought to be adequate. It seems as though Orange didn't bother to enable TOTP and indeed didn't even set a decent password.
In principle key pinning would be the counter measure, but that was so problematic it was removed from browsers. I think chrome still does static key pinning for their own domain, and many mobile apps do key pinning, so its not entirely dead, just mostly.
nocerts.example.com CAA 0 issue ";"
… telling CAs that they shouldn't issue certs for `nocerts.example.com` at all.
That being said, it would make things difficult when it's time to do a cert renewal: You'd have to update the CAA record, wait for it to propagate, do the renewal, and then set it back. And that's a window that could be exploited.
What could work is CAA, along with 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".
But the second problem is it doesn't really solve the problem. Eventually you have to renew the cert, and when that happens, an attacker can spoof the IP of the validating source and have a valid cert issued. CA validation itself is flawed by design.
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.
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.
Some governments have physical tunnel networks to move people who matter around. Computer networks follow pretty much without a loss of generality.
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.
Let's Encrypt has supported RFC 8657 for over a year now: https://community.letsencrypt.org/t/enabling-acme-caa-accoun...
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.
> … 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...).