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/CABqVa39hkLhnVH9Tw-Ec5F4jdSyuYkhpJ-wjWq%3DgQ%2BJmy8YRjg%40mail.gmail.com.
