1451235 - Distrust the WebTrust Audit of Deloitte Anjin South Korea

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[KimMinsu]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce:

N/A


Actual results:

Deloitte Anjin did the WebTrust audit for South Korea GPKI(Government Public Key Infrastructure).

they audited two organization "Ministry of the Interior" and "Ministry of the Education"
buy they did not follow CA/B Forum BR..

they issued certificate without domain validaion. ex) www.testssl.com
they issued certificate to TLD domain(public suffix). ex) *.ac.kr which is public suffix list.

audit report of Deloitte Anjin say's "everythins is OK" for 2 years (2016, 2017)

https://bugs.chromium.org/p/chromium/issues/detail?id=823665


GPKI(MOI)

2017
https://cert.webtrust.org/ViewSeal?id=2183
https://cert.webtrust.org/ViewSeal?id=2184

EPKI(MOE)

2017
https://cert.webtrust.org/ViewSeal?id=2260
https://cert.webtrust.org/ViewSeal?id=2259


Expected results:

Distrust the WebTrust Audit of Deloitte Anjin Korea

Comment 1

[KimMinsu]

https://bugzilla.mozilla.org/show_bug.cgi?id=1377389

Comment 2

[KimMinsu]

https://cert.webtrust.org/ViewSeal?id=1622

Comment 3

[KimMinsu]

Like Webtrust audit of StartCom and WoSign case, they did not audited properly

Comment 4

[KimMinsu]

GPKI(MOI) 2016
https://cert.webtrust.org/ViewSeal?id=1923
https://cert.webtrust.org/ViewSeal?id=1924

Comment 5

[Shinjo Park]

This bug contains important information affecting some applications of South Korean CAs, and they are scattered through multiple comments.

As inclusion of GPKIRootCA1 is declined since this is a super CA (bug #1226100), one of its public CA (Ministry of the Interior (MOI) CA) initiated a separate process to be included in the root CA storage (bug #1377389). On the other hand, the other CA mentioned there, Ministry of Education (MOE) CA (MOE CA afterwards, CA134100031), did not initiated inclusion process. The incident happened in MOE CA.

Among the certificates signed by this CA, there are wildcard certificates for *.or.kr [1] and *.co.kr [2], which is a public TLD. Although there are wildcard certificates signed by this CA for other TLDs such as *.go.kr, *.hs.kr, *.ms.kr, *.es.kr, these are restricted TLDs. This should not be tolerated in any cases, as they do not have the control on the public TLDs, and this is a showcase of failing validation of domain's owner. The Chromium bug [3] tracks several additional technical mistakes that this CA had been made.

[1] https://crt.sh/?id=216514419 https://crt.sh/?id=140593669 https://crt.sh/?id=93537384 valid as of writing the article (see also https://crt.sh/?q=*.or.kr )
[2] https://crt.sh/?q=*.co.kr (none of them are valid as of writing the article)
[3] https://bugs.chromium.org/p/chromium/issues/detail?id=823665

This CA got WebTrust seal two times [4, 5]. The audit by Ernst & Young Han Young (EY Han Young) in [4] states the period as 2015-09-01 to 2015-11-30 (currently this seal is revoked). Another audit by Deloitte Anjin LLC in [5] states the period as 2015-12-01 to 2016-12-31. One of the offending certificate was validated during audited period of Deloitte Anjin [6]. Although no offending certificates has validity period starting during EY Han Young's audit period, they have failed to address that certificates in [2]'s validity period includes 2015-09-01 to 2015-11-30.

[4] https://cert.webtrust.org/SealFile?seal=2029&file=pdf https://cert.webtrust.org/SealFile?seal=2030&file=pdf 
[5] https://cert.webtrust.org/SealFile?seal=2259&file=pdf https://cert.webtrust.org/SealFile?seal=2260&file=pdf
[6] https://crt.sh/?id=20687119&opt=ocsp (valid from 2016-05-31)

Therefore, the integrity of both EY Han Young's and Deloitte Anjin's audit report should be questioned.

This affects the Bug #1377389 and Bug #1310580 [7], since they were also audited by the same Deloitte Anjin for WebTrust seal.

[7] https://cert.webtrust.org/SealFile?seal=2242&file=pdf

Comment 6

[Wayne Thayer]

I have added the information reported in this bug to the Government of Korea MOI inclusion request bug #1377389

I have also made a note of this issue in the CCADB audit record for Deloitte Korea (Anjin)

Comment 7

[KimMinsu]

Distrust the WebTrust Audit of EY (HanYoung) South Korea and KPMG (Samjong) South Korea
see also https://bugzilla.mozilla.org/show_bug.cgi?id=1451578

Comment 13

[Dylan Hardison [:dylan] (he/him)]

The content of attachment 8967032 [details] has been deleted for the following reason:

Deleted by request

Comment 19

[Shinjo Park]

(In reply to [redacted] from comment #17)
> (In reply to Shinjo Park from comment #16)
> 
> [1] https://crt.sh/?id=20687119&opt=ocsp
> 
> The certificate you mentioned and others are already revoked. It seems like
> not revoked since the site supports only http crl.
> But all major browsers show it is revoked. 
> DNS: support.ulsanedu.kr

Now I got the situation. These problematic certificates are revoked according to OCSP server at http://ocsp.epki.go.kr:8081, but these problematic certificates lack this very URL of OCSP server. What they only have is CRL, and according to the CRL URL listed in those certificate, they are not revoked. Only Microsoft queried OCSP server (which is NOT included within leaf certificates but only at the root one) and showed that these certificates are revoked. I admit that my assumption was wrong, but I still believe that the revocation status should be synchronized between OCSP and CRL, especially since these certificates are not including OCSP URL.

Comment 20

[Shinjo Park]

Again, I want to reiterate that these problematic certificates are issued during the Deloitte Anjin's audit period, and further revocation of these certificates do not cancel out the mistakes made during the audit.

Comment 21

[Shinjo Park]

(In reply to Shinjo Park from comment #19)
> Only Microsoft queried OCSP server (which is NOT included
> within leaf certificates but only at the root one)

Corrections and additions regarding certificate validity: I checked the "GPKIRootCA1" and "CA134100031" available at EPKI website [1] and they do not list the certificate CRL. As crt.sh do not check LDAP-based CRLs, I manually checked against them for the certificates that I mentioned in comment #16, sorted by time of revocation:

[1]
* https://www.epki.go.kr/sub/info.do?m=0403&s=epki
* https://www.epki.go.kr/boardCnts/fileDown.do?fileSeq=c7ed810e03b729ed68405ed67b521701
* https://www.epki.go.kr/boardCnts/fileDown.do?fileSeq=ddd64aa21b7fd438f61ecf998176fd45

* https://crt.sh/?id=287314507 (Revocation Date: Aug 29 01:48:28 2016 GMT - lies within Deloitte Anjin's audit period)
* https://crt.sh/?id=20687119 (Revocation Date: Feb 14 00:37:21 2017 GMT)
* https://crt.sh/?id=287836356 (Revocation Date: Apr  3 06:29:12 2017 GMT)
* https://crt.sh/?id=287836414 (Revocation Date: Apr  3 06:42:44 2017 GMT)
* https://crt.sh/?id=30277284 (Revocation Date: Apr  5 08:53:25 2018 GMT - near the time when the incident went public)
* https://crt.sh/?id=67799926 (Revocation Date: Apr  6 11:07:54 2018 GMT - after the time of writing comment #5, probably within 24 hour time window)
* https://crt.sh/?id=45248454 (Revocation Date: Apr 12 01:42:19 2018 GMT - after the time of writing comment #17)
* https://crt.sh/?id=19158231 (Revocation Date: Apr 12 07:33:53 2018 GMT)

* https://crt.sh/?id=284348956 (Revocation Date: Apr  6 00:38:20 2016 GMT)
* https://crt.sh/?id=27487545 (Revocation Date: Nov  2 06:42:59 2016 GMT - above two lies within Deloitte Anjin's audit period)
* https://crt.sh/?id=284281655 (Revocation Date: Apr  5 08:58:02 2018 GMT - near the time when the incident went public)
* https://crt.sh/?id=284155050 (Revocation Date: Apr  5 08:59:22 2018 GMT)
* https://crt.sh/?id=284360442 (Revocation Date: Apr  6 05:46:05 2018 GMT - after the time of writing comment #5)
* https://crt.sh/?id=284285387 (Revocation Date: Apr  6 07:53:32 2018 GMT)
* https://crt.sh/?id=52978891 (Revocation Date: Apr  6 07:12:43 2018 GMT)
* https://crt.sh/?id=284281136 (Revocation Date: Apr  6 07:54:15 2018 GMT)
* https://crt.sh/?id=20792511 (Revocation Date: Apr  6 11:04:04 2018 GMT)
* https://crt.sh/?id=284360297 (Revocation Date: Apr  6 11:04:19 2018 GMT)
* https://crt.sh/?id=44332351 (Revocation Date: Apr  6 11:07:17 2018 GMT)
* https://crt.sh/?id=284349160 (Revocation Date: Apr  6 11:07:57 2018 GMT)
* https://crt.sh/?id=19993478 (Revocation Date: Apr  6 11:09:37 2018 GMT)
* https://crt.sh/?id=47658798 (Revocation Date: Apr  6 11:10:17 2018 GMT)

* https://crt.sh/?id=287315384 (Expired)
* https://crt.sh/?id=284294244 (Expired)

I am sorry for not checking LDAP-based CRLs when writing comment #16, but there were still valid certificates among this list when I was writing the original comment #5.

Comment 22

[Ryan Sleevi]

The BRs require HTTP CRLs (7.1.2.3), and clients don't check LDAP URLs, so it's not unreasonable to not have checked LDAP URLs.

Comment 23

[Rob Stradling]

FWIW, I'd be happy to add support for LDAP CRLs to crt.sh, if anyone can point me to some example Go code that can fetch CRLs via LDAP.  I tried to figure out how to do this once before, but gave up.  (See also https://github.com/crtsh/certwatch_db/issues/16).