Security concerns with the e-Tugra certificate authority

Certificate authorities (CAs) are a critical backbone of internet security; when they are compromised, users lose the ability to securely connect to websites without fear of interception. Websites cannot insulate themselves against a fully-compromised CA, even if they normally use other CAs.

In many regards, certificate authorities are audited comprehensively against industry-specific audit standards. Certificate authorities also routinely get hacked. Despite this, not a single certificate authority runs a bug bounty program, and of the major CAs, only GlobalSign and Let’s Encrypt even offer a security.txt to help disclose issues. Only an annual penetration is generally required of CAs.

As a result, I suspected that there was a lot of low-hanging fruit in certificate authorities, which malicious actors may have already discovered. I decided to look into several certificate authorities, in particular looking into the applications they are exposing to the internet.

I ended up taking a deep look into e-Tugra, a Turkey-based certificate authority trusted by Apple, Google, Mozilla, and other clients. I found a number of alarming issues that worry me as to the security practices inside their company, and want to share the details in hope of preventing these issues in the future. While every company suffers from security issues, these appear to be concerning issues in critical infrastructure, and I am disclosing them quickly in order to raise awareness of the potential risks.

e-Tugra appears to use a common framework for many of their internal tools. They have a similar appearance, but also similar conspicuous text on their homepages.

Although it’s written in Turkish, the homepage helpfully offers the default credentials for this application are either admin / admin123% or user / user123%. This is quite alarming to see on a certificate authority’s production website! Nevertheless, these credentials did not work at first, until I stumbled upon another application:

This appeared to be a server storing logs from their other applications, and the default password worked! This allowed logging in and viewing over 14 million log entries, as well as adding other users to the application as an administrator. Notably, there was no other user configured, so the default passwords would have had to be willingly used by e-Tugra staff in order to access this system.

Additionally, there were many log lines referencing EJBCA, which is the software used by many certificate authorities as part of their issuance infrastructure. As a result, this system was likely connected to other systems with the ability to issue certificates. Luckily, the log lines did not appear to have sensitive or secret values in them, albeit many are in Turkish which I do not speak.

I tried the default passwords on another similar e-Tugra application written with the same framework. Luckily, they had been changed and did not work. However, there was an additional button on the login form — to sign up for a new account! I registered an account with the email admin2@admin2.com and was immediately logged into into a massive administrative panel.

This administrative tool contains every email message, text message, and uploaded document sent to and from e-Tugra’s systems. It contains numerous amounts of PII including uploaded Turkish IDs, email addresses, phone numbers, and physical addresses.

This is, undoubtedly, a very serious issue. It is likely also a massive data breach of personal information. However, for certificate authorities, they also have a unique role of validating control of certain things like domain names. One way certificate authorities do this is by sending a unique code to specific email addresses, like admin@yourdomain.com, and having you send them that code as proof of control of the email address.

(Side note: Email validation is the only allowed domain validation method that relies on “secret” values. DNS and HTTP validation methods use public values that are then hosted on the domain, but email validation is the only one to have secrets which must be kept from the user.)

This issue in e-Tugra’s system allowed me to view the contents of any email sent to any e-Tugra user. Here, they are sending me a confirmation code to my own email address, but I could view these for any user:

In this same administrative panel, we can see that it has an email template for proving control of a domain name. We can also edit the template, which is extremely concerning in itself. It appears this template may be presently unused by e-Tugra at the moment, however any domain validation previously completed through this system likely should be considered invalid.

e-Tugra also offers a customer panel for customers to purchase certificates. Using the above issues, we could capture password reset emails and take over any account on this site. Without going into specific details due to them potentially not being resolved, there were numerous additional issues in this customer panel:

Hopefully I can add more details to these issues in the future, but I must stress how trivial they are. I was unable to test the customer panel in detail because it did not accept foreign credit cards, despite my best attempts. However, customer panels for certificate authorities often allow re-issuing existing certificates without further validation. These would be a critical issue for any user of e-Tugra.

Under the CA/B Forum Network Security Guidelines, e-Tugra is required to remediate critical security vulnerabilities within 96 hours. I disclosed all of these issues in detail to e-Tugra, but have decided to publish this post without waiting for approval from e-Tugra due to the potential ecosystem risks.