This document discusses public key infrastructure (PKI) and digital certificates. It covers how certificates enable authentication, confidentiality, integrity and non-repudiation. It also discusses certificate authorities, self-signed certificates, common uses of certificates including TLS and code signing, and risks associated with certificates like compromised certificate authorities and vulnerable algorithms. The document provides recommendations around treating certificates as assets, establishing policies, being aware of issues for embedded systems, and monitoring for malware that targets certificates.

1. PKI
Do You Know your Exposure?
Kent King
Information Security Manager

2. Public Key Infrastructure
Authentication
Confidentiality
Integrity
Nonrepudiation Gawker.com

3. Certificates Enable
 Secure data transfers
 TLS, SSL, https, VPN, sFTP, ssh
 Code signing
 Origination
 Validation
 Non-Repudiation

5. Certificate Authorities
 Trust in the certificate itself
 Validate owner of certificate
 Auditability
 Revocation & Renewal
 Intermediate CAs
 Self-Signed Certificates

6. Certificates Are Internet Glue
 Digital certificates are everywhere
 TLS
 Wireless
 Mobile devices
 IoT/Embedded devices
 Code signing
 Trusted root certificates – because you
can’t always internet
 Browsers and OS use different root stores
 Do you know what is in your root store?

7. What’s in Your Root Store?
http://www.zdnet.com/article/google-banishes-chinas-main-digital-certificate-authority-cnnic/

8. Self-Signed Certificates
 Who is the owner?
 Did the issuer have the permission of the domain owner?
 What is the status?
 How recently was it issued? How long is it valid?
 Contain both public and private key data
 Vendor failure: Superfish
http://blog.erratasec.com/2015/02/extracting-superfish-certificate.html#.VuXin-IrLct

9. Self-Signed Browser Warning

10. Certificates – The Bad
 Certificate Authorities
Compromised
 2011 – Diginotar, Comodo
 2014 - NIC of India -intermediate CA
 Root Certificate pain
 Google revoked 20 year Verisign Cert
 Implementation errors
 Heartbleed, DROWN
http://www.darkreading.com/attacks-breaches/digital-certificate-authority-hacked-dozens-of-phony-digital-certificates-issued/d/d-id/1136244

11. • Vulnerable algorithms: MD5 and
SHA-1
• Malware steals legitimate and
installs malicious certificates
• Process errors
• A test or self-signed certificate
gets into production
• Letting your certificates expire
• 2013 - Azure
More bad…
http://arstechnica.com/security/2015/10/sha1-crypto-algorithm-securing-internet-could-break-by-years-end/

12. Real attacks
 Stuxnet – Certificate Theft
 Signed code
 Operation Emmental – Fake Certificates
 Malware places certificate and no warning
is seen at phishing web sites
 POODLE – Protocol attacks
 Goodbye SSL v3
 Man In The Middle
 The story of Bob, Alice and Mallory
http://www.computerweekly.com/news/4500242932/Google-warns-of-fake-digital-certificates

13. Pidgin, Dsniff, Fiddler2, Subterfuge

14. Threat Review
 Certificate Compromise
 CA failures
 Malware
 Certificate Insertion
 Vulnerable Algorithms
 Implementation Issues
 Process Errors
 Ensuring validation and revocation status

15. If You Ever See a Revoked Certificate

16. Mitigation

17. Attack surface
 Study of routers, modems, IP
cameras, VoIP phones and other
devices showed that over 3M
devices used one of 150 TLS
private keys.
 The same study saw just less than
1M SSH private keys using 80
private keys.
 230 keys to control our planet?
https://nakedsecurity.sophos.com/2015/11/30/millions-of-internet-things-are-secured-by-the-same-private-keys/

18. How Many Certificates Do You Have?
 Purchased?
 Self-Signed?
 Wildcard?
 Functions?
If your company name is on the certificate, it’s an asset worth tracking!

19. Certificates As Assets
 Track as an asset category or use a vendor product
 Monitor expiration and renewal dates
 Know certificate function
 How are you handling revoked certificates?
 Choose a reliable CA
 Self-signed
 Policies for generation and use
 Clear process that is auditable

20. Certificates on the Web
 All public pages present a verifiable EV
certificate from a reputable CA
 Use secure cookie flag
 Don’t mix secure/non-secure content
 Avoid redirect from http to https
 Use wildcard certificates carefully
 Review your web server TLS protocols
 Consider using HSTS
 Pin it?

21. Wildcard Certificates
 Wildcards enable sub-domains (*.yourorg.com)
 support.yourorg.com and purchasing.yourorg.com
 Trust extends over many systems
 Avoid using wildcards for
 Login/validation pages
 Entering sensitive personal data
 Ecommerce purchase/checkout
 Certificate compromise means numerous pages are affected
http://news.softpedia.com/news/PayPal-Phishing-Page-Hosted-on-Secure-Website-of-Malaysian-Police-Portal-359166.shtml

22. http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html

23. HSTS – HTTPS Strict Transport Security
 Helps mitigate SSL stripping
 Reduces TLS downgrade attacks
 Makes MITM harder
 Protects cookie-based web login credentials
 First connection can be leveraged
https://tools.ietf.org/html/rfc6797

24. Certificate Pinning
 Using a set of info (often a hash), to double
check certificate validity
 Protects against CA compromise
 Can be used to limit browser warnings
 Can be used to find nation/state MITM
activity
 Helps with users who will just click on
“Proceed” no matter what.
 Administrative PITA
https://www.owasp.org/index.php/Pinning_Cheat_Sheet

25. Certificates Beyond the Browser
http://researchcenter.paloaltonetworks.com/2015/08/keyraider-ios-malware-steals-over-225000-apple-accounts-to-create-free-app-utopia/

26. If You Sign Code
 Policy Awareness
 Don’t share or reuse private keys
 Customize firmware keys and use once
 Time stamping
 Library code
 Signed code attests
 Where the code came from
 That it has not been altered

27. Embedded devices
 Reset default passwords
 Limit remote administration
 Regenerate crypto keys if possible
 Limits poor quality “default” keys
 Know the exposure
 Scan your network
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150625-ironport
http://www.theregister.co.uk/2015/08/24/smart_fridge_security_fubar/

28. Monitor for Malware that Steals Certificates
 Backdoor.Beasty, Infostealer.Snifula
 Downloader.Parshell, Trojan.Spyeye, W32.Cridex, W32.Qakbot,
Infostealer.Shiz, Trojan.Carberp, Trojan.Zbot

29. Mitigation Review
 Treat certificates as assets
 Review certificate stores in deployed systems (CNNIC)
 Establish clear web policies and standards for PKI management
 Establish clear code-signing policies and standards
 Be aware of certificate issues in embedded systems
 Track certificate-related events – internal and external
 Have a plan for certificate loss or root revocation
 Monitor for malware known to steal certificates
 It’s not all about key lengths and algorithms – many process issues

30. After Today’s Talk
 Government in the Middle
 http://www.slate.com/blogs/future_tense/2015/12/14/kazakhstan_wants_citizens_to_download_a_mandatory_nat
ional_security_certificate.html
 Perspectives from C-M
 http://perspectives-project.org/
 Sovereign Keys from EFF
 https://www.eff.org/deeplinks/2011/11/sovereign-keys-proposal-make-https-and-email-more-secure
 DNSSEC in conjunction with SSL - HSTS