*Hi,We really appreciate the efforts of the reporter in identifying some
security issues. At the same time, we are also glad that our customer
facing SSL ecosystem is secure and hence not vulnerable to security
threats.It is our internal ecosystem, deploying some other applications
than our CA /SSL certificate life cycle system. Right after receiving the
email, we made an immediate action to resolve the default password problem.
Both SSL and other products have their own separate ecosystems and
processes which do not conflict with each other. The logs and email access
you got was related to resellers, customers and application processes but
not for CA SSL certificate issuance. As claimed in the blog, he was unable
to access the DV SSL validation email because a separate CA email
validation component is in operation and not accessible to any
system. eTugra CA/SSL ecosystem is pen-tested annually and all the
infrastructure changes ensuring the CA/B Network Security Guidelines are in
place. We once again want to appreciate you attempting to point out any
possible threats as such reports always help reassess our system and come
back with extra feel of security.@Kurt Seifried, on your point (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 yearWe were in the process of inclusion
of new Root CAs. We generated both test sub-CAs and test SSL certificates.
You can find more details from this
link:https://bugzilla.mozilla.org/show_bug.cgi?id=1628720#c31
<https://bugzilla.mozilla.org/show_bug.cgi?id=1628720#c31>An incident
report is also published on this
link:https://bugzilla.mozilla.org/show_bug.cgi?id=1801345
<https://bugzilla.mozilla.org/show_bug.cgi?id=1801345>*
Regards,
Ahmed
On Friday, 18 November 2022 at 03:51:29 UTC+5 [email protected] wrote:
> 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/9c9cde14-a221-4db8-8bf2-c6c7a7c121d2n%40mozilla.org.
