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.
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.
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
