Further BGP hijacks of high value authoritative DNS servers' IP space.
Noted by the Oracle/Dyn team at: https://blogs.oracle.com/internetintelligence/bgp-dns-hijacks-target-payment-systems July 2018 saw multiple attacks on authoritative DNS infrastructure of both dedicated DNS service providers and of certain high value internally administered DNS services which answer authoritatively for multiple of the major (primarily US based) credit card processing networks. While the scope of the advertisements was somewhat contained, they still managed to get 30% of peers of some of the BGP listening points at which Dyn has visibility to accept these more specific routes. In the case of First Data, the specific networks which answer authoritatively for First Data's Datawire network were among the particular (and obviously intentionally) selected targets. While the Dyn article does not mention this, the casual outsider might recognize First Data as a major player in the credit card payments space, but Datawire and the datawire.net domain (which are First Data services for transmission of payment batch settlement data and secure file exchange for things like the BIN Master File, etc.) is not well know. This suggests that one or more parties quite familiar with the payment networks and the crucial infrastructure of the payment networks (and so, in turn, would be well familiar with the fact that these mostly rely upon TLS encryption) is attempting to subvert the authoritative DNS for some cause. I believe it's not a great leap to suggest that they may likely seek certificate issuance. Just thought I'd ping the list for thoughts... Matt Hardeman ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Telia CA - problem in E validation
Thank you for supplying this incident report. For reference, this is in response to https://bugzilla.mozilla.org/show_bug.cgi?id=1475115 On Fri, Aug 3, 2018 at 1:55 AM pekka.lahtiharju--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Incident report: > > PROBLEM IN SUBJECT E (email) VALUE VALIDATION (deviation 5) > Telia got a preliminary CA audit report on 25th June 2018. One of its BR > deviations was a statement that "Telia did not have controls to adequately > verify the email address information (of SSL certificates)". Telia has > always verified E values only visually and Registration officer (or > certificate inspector in some cases) has to manually accept each value but > only clearly incorrect values or syntactically incorrect values have been > thus far rejected. Note! Subject E value has only informative meaning and > often includes support email address related to the server and it can't be > used for SMIME purposes. > > Timeline of actions: > 10-Jul-2018 Telia decided to completely stop inserting E values to OV > certificates because of this deviation because Telia won't know how they > could be reasonably verified otherwise. Plan is to implement this removal > in September 2018. But before that Telia would like to get community > opinion how E values are verified by other CAs and how they are supposed to > be verified when BR text is like this "All other optional attributes, when > present within the subject field, MUST contain information that has been > verified by the CA." Before this discussion Telia plan is not to revoke > previously enrolled OV certificates with visually verified E values. > > It is rare for a CA to include subject:emailAddress in a serverAuth certificate. I suspect that sending a random value to the email address and receiving a response (BR 3.2.2.4.2) is the most common way that CAs verify email addresses. Summary and details of problematic certificates: > Lots of existing Telia OV certificates have E value because Openssl which > is one of the most common CSR generators automatically adds it to the CSR > and old Telia process has accepted the values unless they are incorrect in > visual verification or syntactically incorrect. Actual count and list of > problematic E values will be generated in August 2018. > > Explanation about how and why the mistakes were made or bugs introduced, > and how they avoided detection until now: > Telia hasn't understand that E values should be verified using some other > method than using visual check. Before this year it hasn't been on audit > comments even though Telia E verification process has been same always. > > Steps to fix: > 1. listing of problematic certificates; Telia plan to do this in August > 2018 > 2. community discussion how other CAs verify E and how they are supposed > to be verified; planned to happen starting in August 2018 based on this bug > 3. possible revocation or revalidation if community states that existing E > values cause a security problem; will be done after public discussion > > Crt.sh lists over 3,400 Telia certificates containing a Subject:emailAddress. BR 4.9.1.1(9) requires revocation within 24 hours. Failure to revoke is a BR violation, even if this issues does not "cause a security problem". ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Telia CA - problem in E validation
Incident report: PROBLEM IN SUBJECT E (email) VALUE VALIDATION (deviation 5) Telia got a preliminary CA audit report on 25th June 2018. One of its BR deviations was a statement that "Telia did not have controls to adequately verify the email address information (of SSL certificates)". Telia has always verified E values only visually and Registration officer (or certificate inspector in some cases) has to manually accept each value but only clearly incorrect values or syntactically incorrect values have been thus far rejected. Note! Subject E value has only informative meaning and often includes support email address related to the server and it can't be used for SMIME purposes. Timeline of actions: 10-Jul-2018 Telia decided to completely stop inserting E values to OV certificates because of this deviation because Telia won't know how they could be reasonably verified otherwise. Plan is to implement this removal in September 2018. But before that Telia would like to get community opinion how E values are verified by other CAs and how they are supposed to be verified when BR text is like this "All other optional attributes, when present within the subject field, MUST contain information that has been verified by the CA." Before this discussion Telia plan is not to revoke previously enrolled OV certificates with visually verified E values. Summary and details of problematic certificates: Lots of existing Telia OV certificates have E value because Openssl which is one of the most common CSR generators automatically adds it to the CSR and old Telia process has accepted the values unless they are incorrect in visual verification or syntactically incorrect. Actual count and list of problematic E values will be generated in August 2018. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now: Telia hasn't understand that E values should be verified using some other method than using visual check. Before this year it hasn't been on audit comments even though Telia E verification process has been same always. Steps to fix: 1. listing of problematic certificates; Telia plan to do this in August 2018 2. community discussion how other CAs verify E and how they are supposed to be verified; planned to happen starting in August 2018 based on this bug 3. possible revocation or revalidation if community states that existing E values cause a security problem; will be done after public discussion ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
