Hacking root EPP servers to take control of zones(hackcompute.com)
hackcompute.com
Hacking root EPP servers to take control of zones
https://hackcompute.com/hacking-epp-servers/
28 comments
Firewalling is a good practice and hopefully provide some traceability if servers at a registrar would start to attack the epp servers. It should however not the be only defense as that would make the system vulnerable to the least secure registrar that is approved by the registry. Becoming a registrar is also in many cases not that hard.
I helped the authors with a little bit of background info on EPP.
Some registries are leaving their management systems open to the internet.
Some registries are leaving their management systems open to the internet.
As a security consultant this boggles my mind. I push companies with much less sensitive systems to use better security practices. It's crazy that these foundational systems lack such controls, but I guess that's due to race to the bottom economic factors?
Most of these are small ccTLDs with minimal management. For most countries they just kind of got assigned a TLD and some random person in the telecommunications department of the government, the postal office, or a university has been keeping it going for years.
I recently tried reporting a security issue to a ccTLD. As a registrar thankfully I was able to reach out to ICANN for assistance, but even then the person who operated the TLD had just retired and there was no replacement.
I recently tried reporting a security issue to a ccTLD. As a registrar thankfully I was able to reach out to ICANN for assistance, but even then the person who operated the TLD had just retired and there was no replacement.
Wait until you find out where CA certificates come from. The answer is: E-Mail and a public salesforce instance.
You're talking about issuing certificates via email? That's a widely documented process, I've used it. SharePoint... I'm not familiar with. I'd love a reference.
Certificate issuance doesn't need to be perfect. We have Certificate Transparency, for example to catch missisuance and CAA records to restrict the process.
Certificate issuance doesn't need to be perfect. We have Certificate Transparency, for example to catch missisuance and CAA records to restrict the process.
I talk about the CCADB:
[1] https://www.ccadb.org/
[2] https://www.ccadb.org/resources
[1] https://www.ccadb.org/
[2] https://www.ccadb.org/resources
Ah, you're not talking about issuance. I think you're implying that the browsers blindly copy their trust roots from the linked Salesforce site, and you don't think Salesforce provides suitable tampering protection.
I'm not shocked? The website discusses audit responsibilities quite a bit, which seems like it mitigates tampering concerns. Sure I'd prefer something other than Salesforce too, but I'm not seeing a glaring issue here.
I'm not shocked? The website discusses audit responsibilities quite a bit, which seems like it mitigates tampering concerns. Sure I'd prefer something other than Salesforce too, but I'm not seeing a glaring issue here.
[deleted]
can you elaborate on that?
Certificates are usually public anyway, but the matching private keys aren't. CAs usually have them on hsm-devices only.
if you mean private keys are shared via email: keys from the CA-Certs, or just from the Certificates the CA signed?
for instance, getting a CA publicly into a browser is expensive and requires audits, so your experience makes me curious
This is probably the "No one cares about security unless something breaks (and then security team gets blamed)" mindset especially in public areas.
Note that the command they use, poll, requires to login first, which means they also had some valid credentials somehow.
In addition, they seemed to have access to the source code, whereas the opensource version hasn't been updated in more than 8 years.
Maybe this is the result of a whitebox security audit?
In addition, they seemed to have access to the source code, whereas the opensource version hasn't been updated in more than 8 years.
Maybe this is the result of a whitebox security audit?
Login is itself an XML command so in theory that could also be hacked.
Like @silisili said most of the registry operators require client certs and ips to go with the usernames but it is very possible that they are only checking that after getting a login.
CoCCA run by the tiny zones with no budgets. They are likely to be VERY vulnerable to this.
Like @silisili said most of the registry operators require client certs and ips to go with the usernames but it is very possible that they are only checking that after getting a login.
CoCCA run by the tiny zones with no budgets. They are likely to be VERY vulnerable to this.
This feels like it should be submitted to https://www.hackerone.com/internet-bug-bounty.
This is interesting, however the vast majority of registries require connecting from a known ip, using a specific cert chain and in some instances their own ca. Turns out when you don’t follow industry practices in one way you don’t do much else right either
This is huge! You could control entire ccTLDs?
Yes, as we were able to download the database for CoCCA's web application (from the box.com backups) for any of the ccTLDs managed by CoCCA, we could decrypt the admin hash and then login to the CoCCA administration panel and modify/transfer any domain inside a ccTLD's zone.
> We spent a significant amount of time on Google's registry software and discovered an endpoint that we believe are not supposed to be accessed without authentication
Can you send me info on this to [email protected] ? Thanks.
Can you send me info on this to [email protected] ? Thanks.
Out of curiosity, at what point is this considered hacking? Aren't you afraid of getting into trouble with the law by accessing servers like this, downloading data, etc?
The scale of possibilities with this hack are enormous. You could easily redirect entire domains, generate valid SSL certs for those domains, then capture all the data including all login credentials for all users on those domains.
With exploitation of the right domains you would probably be able to extend this hack using stolen authentication information to take over basically the entire Internet.
Funny hack of my own once: a major web hosting company had a forum which failed to check uploaded profile pics were images, so I used it to upload a script so I could browse their entire filesystem. I eventually came across their root password stored in plaintext in a configuration file. The password? "internet" - all lowercase, just like that.
With exploitation of the right domains you would probably be able to extend this hack using stolen authentication information to take over basically the entire Internet.
Funny hack of my own once: a major web hosting company had a forum which failed to check uploaded profile pics were images, so I used it to upload a script so I could browse their entire filesystem. I eventually came across their root password stored in plaintext in a configuration file. The password? "internet" - all lowercase, just like that.
I kinda think these vulnerabilities were long exploited but no one made the move to actually make any harm is because 1) not profitable for private parties 2) state actors are waiting for a proper time to execute
This was a fun writeup and I liked the continued references to the theme of the brittle internet. In particular, I found this amusing:
> We discovered that one of the maintainers of the .AI registry is a person named Vince.
I wonder if Vince lives in Nebraska: https://xkcd.com/2347/
> We discovered that one of the maintainers of the .AI registry is a person named Vince.
I wonder if Vince lives in Nebraska: https://xkcd.com/2347/
Vince lives in Anguilla: https://en.wikipedia.org/wiki/Vince_Cate
I've read through this article several times, and I am failing to see how this could possibly be used to form an attack.
Sure - taking the provider down is bad - but that happens due to unscheduled downtime every other day?
Sure - taking the provider down is bad - but that happens due to unscheduled downtime every other day?
From the article:
>> Speaking with Vince (the administrator of the .ai zone) over WhatsApp, we confirmed that compromising this server would give us full control over any .ai domain:
>> Once administrative access is gained to the CoCCA application, it is possible to control the nameservers for every domain for that ccTLD.
The point is to control domains in a ccTLD. Arbitrary domain hijacking is bad...
>> Speaking with Vince (the administrator of the .ai zone) over WhatsApp, we confirmed that compromising this server would give us full control over any .ai domain:
>> Once administrative access is gained to the CoCCA application, it is possible to control the nameservers for every domain for that ccTLD.
The point is to control domains in a ccTLD. Arbitrary domain hijacking is bad...
The screenshot of the WhatsApp conversation says they'd need admin on the web application. I agree it wasn't clear if they'd gotten that.
Looks like it was via the backup files:
https://news.ycombinator.com/item?id=36305699
Looks like it was via the backup files:
https://news.ycombinator.com/item?id=36305699
Apologies if I missed it, but were they testing from a trusted source, or are some registries that wide open?