The Broken Shield: Measuring Revocation Effectiveness in the Windows Code-Signing PKI

Recent measurement studies have highlighted security threats against the code-signing public key infrastructure (PKI), such as certificates that had been compromised or issued directly to the malware authors. The primary mechanism for mitigating these threats is to revoke the abusive certificates. However, the distributed yet closed nature of the code signing PKI makes it difficult to evaluate the effectiveness of revocations in this ecosystem. In consequence, the magnitude of signed malware threat is not fully understood. In this paper, we collect seven datasets, including the largest corpus of code-signing certificates, and we combine them to analyze the revocation process from end to end. Effective revocations rely on three roles: (1) discovering the abusive certificates, (2) revoking the certificates effectively, and (3) disseminating the revocation information for clients. We assess the challenge for discovering compromised certificates and the subsequent revocation delays. We show that erroneously setting revocation dates causes signed malware to remain valid even after the certificate has been revoked. We also report failures in disseminating the revocations, leading clients to continue trusting the revoked certificates. Role Finding Implication Discovery of Potentially Compromised Certificates The mark-recapture estimation for the number of compromised certificates suggests that even a large AV vendor can only see about 36.5% of the population. There might be malware with compromised certificates that remain a threat for a long time without being detected. CAs took on average 171.4 days to revoke the compromised certificates after the malware signed with the certificates appeared in the wild. Compromised certificates are not discovered and revoked for a long time. Setting Revocation Date CAs erroneously set effective revocation dates for 62 certificates, causing 402 signed malware to remain valid. Wrong effective revocation date setting results in the survival of signed malware although its certificates is revoked. Dissemination of Revocation Information 788 certificates contain neither CRLs nor OCSP points. Clients have no way to check the revocation status of the certificates. 13 CRLs and 15 OCSP servers had reachability issues. OCSP servers responded with unknown or unauthorized messages. 19 certificates have inconsistent responses from CRLs and OCSP; they are valid from OCSP but are revoked in CRLs. CAs improperly maintain their CRLs and OCSP servers. 278 revoked certificates were added and then later removed from 18 CRLs. Errors in the revocation process are made, and later retracted. CAs misunderstood the code signing PKI and removed expired certificates from CRLs.