The major issues mentioned in the post are resolved after I notified e-Tugra of them.
It is important to note that I did not perform an extensive amount of testing of e-Tugra’s systems, given I do not speak Turkish and I found enough issues as it is. Until e-Tugra undertakes a comprehensive security test of their systems, I would assume there are still other vulnerabilities present somewhere else. On Thu, Nov 17, 2022 at 2:42 PM Kurt Seifried <[email protected]> wrote: > > > 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] > -- Thanks, Ian Carroll -- 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/CAEU%3DvGEK94knrHq4kruzbp%3DnVtHfmTVaoYqy%2BK-VdRO7%2Bb__Bg%40mail.gmail.com.
