On Thu, Nov 17, 2022 at 2:59 PM ke ju <[email protected]> wrote: > I agree that something should be done swiftly. If you did this, who else > could have. Also, has the authority been notified, and have they simply > changed the passwords yet? Ie could a threat actor watching this list now > go there and get into the system after the disclosure >
To be clear, I'm not the original reporter. They also posted to the old list which is why I cross-posted it. Their blog entry has a timeline: - Nov 13, 2022 4:10: Initial contact to e-Tugra about administrative systems - Unknown: Administrative systems no longer reachable on the internet - Nov 13, 2022 18:50: Second set of issues reported to e-Tugra, follow-up on initial issues that appeared fixed - Nov 14, 2022 8:35: Initial reply from e-Tugra saying they are working on resolution - Nov 14, 2022 17:18: Asked how to report security issues in the future - Nov 16, 2022 22:52: Notified e-Tugra of impending disclosure - Nov 17, 2022: Disclosed this post > On Thursday, November 17, 2022 at 12:52:37 PM UTC-5 [email protected] > wrote: > >> 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] >> > -- 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/CABqVa39%3DbDEcmhZsB5juSJi-b_7StF65SJF3sHO4Hir2xksXbg%40mail.gmail.com.
