Dear Kurt Seifried,
Thank you for bringing this to our attention. We would like to clarify that our both personal and corporate email accounts are subscribed. The comments were initially posted using the Google Groups web interface and at that time, Google Chrome was logged in and synchronized with my personal email. Moving forward, I will ensure to use my corporate email for all official communications. I understand the importance of maintaining professional correspondence and have already been communicating with root stores using my corporate email. If you have any further questions or concerns, please feel free to let us know. Thanks. On Thursday, 8 June 2023 at 02:26:26 UTC+5 Kurt Seifried wrote: > Can we get some proof that you represent E-Tugra? I mean... can you not > afford a domain name to email from? > > On Tue, Jun 6, 2023 at 8:54 AM Israr Ahmed <[email protected]> wrote: > >> Dear Mozilla community members, >> >> E-Tugra treated this incident with utmost seriousness upon its report, >> taking immediate actions as acknowledged by Ian Carroll on November 18, 2022 >> >> https://groups.google.com/a/ccadb.org/g/public/c/SXAeHT04TFc/m/AJ8S0XuXAwAJ?utm_medium=email&utm_source=footer >> >> It is important to note that the exploited application did not have any >> impact on the certificate life cycle process. Specifically, the validation >> of DV certificates is directly handled by SSL.com, without involving >> E-Tugra. >> >> In response to the incident, we conducted comprehensive investigations to >> identify any potential presence of attackers and took the necessary steps >> to safeguard the integrity of our infrastructure and protect our users' >> data. Further details regarding the actions taken can be found: >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1801345#c18 >> >> We acknowledge that there were administrative weaknesses in our >> responsiveness to the community and forums, as well as the completion of >> the pen testing exercise leading to frustration. However, we want to >> emphasize that the information provided was fully transparent, and nothing >> was concealed from the community. We have already shared this information >> with both Chrome and Mozilla Root programs . While we are willing to share >> the requested information with the root store, we maintain our stance that >> there was no exploitation in the certificate life cycle process. Therefore, >> we kindly request that root stores consider our request to remain listed. >> >> We can confirm that [email protected] and [email protected] represent >> E-Tugra as [email protected] and [email protected]. The >> duplicate comment was a result of a technical issue where the page did not >> immediately reflect the posted comment, and it was subsequently posted by >> another representative, leading to its duplication. >> >> We strongly believe in collaborative work with root stores and community >> members. We are open to highlighting any information or details that can >> benefit the community, and we are fully prepared to provide it. We have the >> necessary evidence, which will be presented to auditors during the upcoming >> audit (end of July). The audit report will address this incident and >> related security issues. >> On Monday, 5 June 2023 at 23:40:30 UTC+5 Kurt Seifried wrote: >> >>> My observations: >>> >>> If you look at this thread: >>> https://groups.google.com/a/ccadb.org/g/public/c/SXAeHT04TFc/m/69LVodC-HgAJ >>> >>> It's not clear that E-Tugra replied, "<[email protected]>" did, but >>> there's exactly one hit in Google on that email address. Ditto for " >>> [email protected]". Can we get a confirmation that these 2 unknown Gmail >>> addresses actually represent E-Tugra? >>> >>> E-Tugra also intentionally lied about the scope and impact of the >>> incident. >>> >>> E-Tugra then states (in Bugzilla): >>> >>> ========= >>> For the sake of transparency and community interest, we can share the >>> following issues: >>> >>> Web Server / Application Server information disclosure >>> Outdated versions of certain third-party applications >>> Cross-Origin Resource Sharing configuration issues >>> File uploading vulnerability on the support portal >>> Usage of default error messages >>> ========== >>> >>> These again are all extremely simple issues that any competent >>> information security team should catch before deployment to production. >>> There is also a lack of transparency/information in the above list. E-Tugra >>> has made no substantial statement about the default passwords other than >>> "Right after receiving the email, we made an immediate action to resolve >>> the default password problem." >>> >>> Can we assume that E-Tugra changed the passwords but has not taken any >>> corrective action to ensure it doesn't happen again? Also what, if any, >>> forensic action was taken to restore or rebuild the systems to a known good >>> state, since it is possible an attacker was present (and not nice enough to >>> report the vulnerabilities). >>> >>> There is no real mention of an information security program being >>> present, created, or updated in light of these disclosures. Again my >>> question stands: >>> >>> If E-Tugra has an information security program, how did such simple, >>> fundamental errors occur (deployment of production systems with default >>> administrative credentials, something that literally every information >>> security program covers, and is even being banned in some jurisdictions >>> (e.g. TS 103 645)? >>> >>> >>> >>> >>> On Mon, Jun 5, 2023 at 11:36 AM Ben Wilson <[email protected]> wrote: >>> >>>> Dear Mozilla Community, >>>> >>>> This email relates to the e-Tugra breach that was described in a blog >>>> post by Ian Carroll <https://ian.sh/etugra> and subsequent discussions >>>> here >>>> <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/yqALPG5PC4s/m/sIkv6eLAAAAJ> >>>> >>>> and in CCADB Public >>>> <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/yqALPG5PC4s/m/sIkv6eLAAAAJ> >>>> >>>> and Bugzilla <https://bugzilla.mozilla.org/show_bug.cgi?id=1801345>. >>>> We are grateful for the involvement of various individuals and >>>> organizations, particularly Ian Carroll and Google Chrome, who have >>>> contributed their expertise and resources while investigating this breach. >>>> >>>> We are now opening this discussion to help determine whether the >>>> e-Tugra root certificates should be removed from Mozilla’s Root Store. We >>>> will greatly appreciate your thoughtful and constructive feedback on this. >>>> >>>> Below are some questions for us to consider in this discussion. >>>> >>>> What were the main concerns raised by the community during the >>>> discussions that took place in Bugzilla Bug #1801345 >>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1801345>? (this is not a >>>> complete list; details may be found in the bug) >>>> >>>> - >>>> >>>> Mr. Carroll indicated that he was able to log in and conduct >>>> reconnaissance on e-Tugra’s email and document storage systems, gaining >>>> access to customer PII. >>>> - >>>> >>>> There were security holes in e-Tugra’s internal systems that >>>> existed because access to internal resources was not adequately >>>> secured, >>>> namely, default passwords on some administrative tools had not been >>>> changed, and internal applications were left exposed without >>>> appropriate >>>> access control mechanisms. >>>> - >>>> >>>> Statements by e-Tugra about the lack of impact were refuted by >>>> the fact that the contents of 568,647 emails and 251,230 documents >>>> were >>>> accessible, including access to password resets and confirmation >>>> codes. >>>> - >>>> >>>> e-Tugra indicated in their incident report that they would conduct >>>> additional vulnerability scanning and penetration testing before the >>>> end of >>>> 2022. They also said that they were preparing a detailed report of the >>>> problem and would provide more information. >>>> - >>>> >>>> None of this information was provided until April 2023. >>>> - >>>> >>>> The explanations in subsequent reports and executive summaries >>>> of penetration testing did not fully answer the questions that had >>>> been >>>> asked. >>>> - >>>> >>>> A detailed analysis was not provided, no root cause analysis was >>>> ever provided, and the output of the penetration test (i.e., reports) >>>> did >>>> not offer any detail addressing concerns raised in the incident report. >>>> (The penetration test reports only provided brief statements and >>>> insufficient information to evaluate the security posture of e-Tugra.) >>>> >>>> Does the benefit of having e-Tugra root certificates in Mozilla’s Root >>>> Store outweigh the risk? >>>> >>>> - >>>> >>>> The breach that was found by Mr. Carroll may indicate that the CA >>>> operators may not have the level of expertise necessary to securely >>>> operate >>>> a publicly trusted CA. >>>> - >>>> >>>> The slow response by e-Tugra may also be an indication that they >>>> may not be prepared to respond to concerns and incidents in the >>>> required >>>> timely manner. >>>> >>>> How would the distrust of e-Tugra affect our users? >>>> >>>> - >>>> >>>> Since the e-Tugra root certificates are not currently being used, >>>> there would not be any impact to our users. >>>> - >>>> >>>> e-Tugra is not currently issuing TLS certificates within their own >>>> CA hierarchy. Instead, e-Tugra has been acting as a reseller for the >>>> SSL.com CA, which means that all domain validation and certificate >>>> issuance >>>> is being performed by systems operated by the SSL.com CA, so SSL.com is >>>> the >>>> party currently responsible for issuance/security procedures. >>>> >>>> If distrusted, could e-Tugra continue to be a reseller for a publicly >>>> trusted CA? >>>> >>>> - >>>> >>>> Yes, as long as the publicly trusted CA ensures correct >>>> systems/procedures/processes in relation to reselling certificates >>>> within >>>> their CA hierarchy. >>>> >>>> If distrusted, could e-Tugra re-apply to have their root certificates >>>> included in Mozilla’s Root Store? >>>> >>>> - >>>> >>>> If we decide to remove the current e-Tugra roots, then in order for >>>> e-Tugra to apply to have their root certificates included in Mozilla’s >>>> Root >>>> Store again, they would need to: >>>> - >>>> >>>> Implement an infrastructure that is properly secure and tested, >>>> with sufficiently detailed artifacts to show that the systems are >>>> properly >>>> configured. >>>> - >>>> >>>> Then create new root certificates within the properly secured >>>> infrastructure. >>>> - >>>> >>>> Then re-apply for inclusion in Mozilla’s root store. >>>> - >>>> >>>> As always, the onus is on the CA operator to demonstrate their >>>> ability to operate a publicly trusted CA hierarchy. >>>> >>>> How are other root stores addressing this issue? >>>> >>>> - >>>> >>>> Google Chrome announced >>>> >>>> <https://groups.google.com/a/ccadb.org/g/public/c/SXAeHT04TFc/m/TIh1ANmHAwAJ> >>>> >>>> that they will remove the “E-Tugra Global Root CA ECC v3” and “E-Tugra >>>> Global Root CA RSA v3” roots from the Chrome Root Store. >>>> - >>>> >>>> Apple stated >>>> >>>> <https://groups.google.com/a/ccadb.org/g/public/c/SXAeHT04TFc/m/B_snEIWZAwAJ> >>>> >>>> that the e-Tugra roots are not in the Apple Root Store. >>>> >>>> Given that SSL.com has been the operator of the issuing CA, e-Tugra’s >>>> breach has not necessitated that we take any urgent safeguarding actions. >>>> However, e-Tugra’s problems give us reason to question whether the e-Tugra >>>> CA should continue to be in our root store, based on the level of >>>> expertise >>>> required to securely operate a publicly trusted CA infrastructure. >>>> Additionally, e-Tugra’s inadequate responses to the problem and resulting >>>> requests for information, give us reason to question e-Tugra’s commitment >>>> to the important role that CAs have in ensuring security on the web. >>>> >>>> We appreciate your engagement and dedication, and we kindly request >>>> that all participants adhere to our Community Participation Guidelines >>>> <https://www.mozilla.org/en-US/about/governance/policies/participation/>, >>>> fostering a respectful and constructive environment for dialogue. >>>> >>>> Thanks, >>>> >>>> Ben and Kathleen >>>> >>>> PS: For your reference, below are excerpts from >>>> https://wiki.mozilla.org/CA/Maintenance_and_Enforcement >>>> >>>> CA behavior >>>> >>>> - >>>> >>>> Did the CA notice the error and take appropriate action in a timely >>>> manner? >>>> - >>>> >>>> Was the threat or error properly contained? >>>> - >>>> >>>> Did the CA notice the hacker intrusion and take appropriate action >>>> in a timely manner? >>>> - >>>> >>>> Were the CA's defense mechanisms current and sufficient? >>>> - >>>> >>>> Was the intrusion appropriately contained? >>>> - >>>> >>>> Was the CA's behavior reckless? >>>> - >>>> >>>> Did the CA try to cover up the mistake/threat rather than follow >>>> Mozilla's Security Policy? >>>> >>>> In incident response, Mozilla is looking for the following factors: >>>> >>>> - >>>> >>>> A CA takes responsibility for their own actions. >>>> - >>>> >>>> Incidents are taken with an appropriate level of seriousness. >>>> - >>>> >>>> Incidents are handled with urgency. >>>> - >>>> >>>> Root cause analysis is performed. >>>> - >>>> >>>> Any questions posed, by anyone, are answered quickly and in detail. >>>> - >>>> >>>> A reasonably-detailed incident report >>>> <https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report> >>>> is made public on what happened, why, and how things have changed to >>>> make >>>> sure it won’t happen again >>>> >>>> >>>> -- >>>> 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/CA%2B1gtaaUPBb1DG4Uc4Cs40K4v56c2hzkdYO-JS8sNN9K%2BzzfYw%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaaUPBb1DG4Uc4Cs40K4v56c2hzkdYO-JS8sNN9K%2BzzfYw%40mail.gmail.com?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/99f361b5-709c-46ce-8945-9c9bbf2463d3n%40mozilla.org.
