Normally I would say e-Tugra needs to reissue all their certificates or like in this case; it would appear they need to reestablish that the certificates were issued properly, which means having all their customers re-create them, establish domain validation, etc.
But in this case, I think it's so severe that they should be removed and be made to re-apply to ensure all their security controls/processes are up to standard because they clearly are not. This isn't a little mistake. this shows a massive failure at all levels, technically and business-wise (not removing default passwords, seriously... that's literally the most basic of the basic, what else did they get wrong?). Additionally, did an attacker possibly get a whole set of new certificates over the summer for their domain names (just a few days ago, etugra renewed everything using their own CA, but they also did a lot of them in July/August of this year). https://crt.sh/?q=e-tugra https://crt.sh/?q=etugratest.com Also, should this discussion be moved to https://groups.google.com/a/ccadb.org/g/public ? Added [email protected]. On Thu, Nov 17, 2022 at 10:26 AM Ian Carroll <[email protected]> wrote: > Hi there, > > Today I published a blog post at https://ian.sh/etugra, describing > several serious security issues I discovered in the e-Tugra certificate > authority. I was able to obtain access to two e-Tugra administrative > systems using default passwords, which disclosed numerous amounts of > subscriber PII and verification details, and appeared to impact e-Tugra's > domain control validation processes. > > I am concerned that it is possible for these trivial vulnerabilities to be > present in a publicly-trusted certificate authority. In light of the recent > Symantec news > <https://symantec-enterprise-blogs.security.com/blogs/threat-intelligence/espionage-asia-governments-cert-authority>, > certificate authorities are clearly being targeted by nation states, but > these vulnerabilities could have been discovered by any amateur security > researcher. From what I have seen, I firmly believe that additional > security issues likely exist in e-Tugra's infrastructure, and they may > already be known to adversaries. > > The Network and Certificate System Security Requirements require an annual > penetration test, or whenever the CA believes there are material changes. > Based on this issue, I am concerned that this control is not sufficient to > protect certificate authorities against application security issues, and I > am concerned that e-Tugra is not following this control. I am also > concerned with the lack of vulnerability disclosure programs and bug bounty > programs that are operated by CAs in general; indeed no certificate > authority at all appears to run a bug bounty program at the moment. > > I would suggest that e-Tugra be compelled to take remedial actions such as > performing a comprehensive penetration test on their external > infrastructure, and building processes to ensure that future applications > that they deploy are secure. I also believe e-Tugra should ensure that > these issues did not have the ability to compromise domain-control > validation for any certificates still valid today. > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/37cff300-b57a-4b38-82e0-a514b4557b07n%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/37cff300-b57a-4b38-82e0-a514b4557b07n%40mozilla.org?utm_medium=email&utm_source=footer> > . > -- Kurt Seifried (He/Him) [email protected] -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CABqVa39zXqxqHZqyFzuaLb5mFC1S-Cb9WwnWJMhoLmRHdtkPZQ%40mail.gmail.com.
