Case Studies and Lessons Learned from SSL/TLS Certificate Verification Vulnerabilities (JavaOne2015 Edition)

1. Case Studies and Lessons Learned from SSL/TLS Certificate Verification Vulnerabilities JPCERT/CC Information Coordination Group Yozo TODA (yozo.toda@jpcert.or.jp) 1 JavaOne2015 version

2. Copyright©2015 JPCERT/CC Allrights reserved. Activities of JPCERT/CC 2 Incident response Network monitoring Watch and warning Vulnerability handling Vulnerability analysis Secure coding Developers Oversea CSIRTs

3. Copyright©2015 JPCERT/CC Allrights reserved. The speaker introduction http://www.tomo.gr.jp/root/e9706.html Yozo Toda JPCERT/CC Vulnerability analysis team •vulnerability analysis/handling •secure coding •co-op. with secure coding initiative of SEI, CMU 3

4. Copyright©2015 JPCERT/CC Allrights reserved. Agenda ü Introduction ü Basics: SSL/TLS and Certificate Verification ü Vulnerabilities in the Real World ü Lessons Learned from Vulnerabilities ü References 4

6. Copyright©2015 JPCERT/CC Allrights reserved. SSL/TLS 6 SSL/TLS technology becomes popular today, and is essential for privacy protection and data encryption. • E-commerce and online banking sites support HTTPS connection. • Most browsers support HTTP/2 on TLS only But… number of vulnerabilities are found on software supporting SSL/TLS.

7. Copyright©2015 JPCERT/CC Allrights reserved. From security vendors’ reports… 7 “40% of the audited apps did not validate the authenticity of SSL certificates presented. This makes them susceptible to Man in The Middle (MiTM) attacks.” IOActive Research Blog (Jan. 8, 2014) “cryptography issues are highly prevalent across all applications and may be used to allow an attacker to retrieve poorly protected data or hijack communication with an application.” VERACODE, State of Software Security Volume6 (June 2015)

8. Copyright©2015 JPCERT/CC Allrights reserved. Vulnerability reports on JVN.JP 8 JVN#27388160: SumaHo forAndroid fails to verify SSL/TLS server certificates JVN#48270605: Yahoo! Japan Box for Android issue where it fails to verify SSL server certificates JVN#04560253: Yuko YukoApp for Android fails to verify SSL server certificates JVN#17637243: Kindle App for Android fails to verify SSL server certificates JVN#27702217: Ameba forAndroid contains an issue where it fails to verify SSL server certificates JVN#72950786: Outlook.com forAndroid contains an issue where it fails to verify SSL server certificates JVN#10603428: JR East JapanApp for Android. contains an issue where it fails to verify SSL server certificates JVN#16263849: Demaecan forAndroid. contains an issue where it fails to verify SSL server certificates JVN#48810179: Denny's App for Android. contains an issue where it fails to verify SSL server certificates JVN#97810280: KDrive Personal for Windows contains an issue where it fails to verify SSL server certificates JVN#75084836: Yahoo! Japan Shopping for Android contains an issue where it fails to verify SSL server certificates JVN#68156832: Yafuoku! Contains an issue where it fails to verify SSL server certificates JVN#39218538: Pizza Hut Japan Official OrderApp forAndroid. contains an issue where it fails to verify SSL server certificates JVN#85812843: FileMaker Pro fails to verify SSL server certificates JVN#39707339: Opera fails to verify SSL server certificates JVN#82029095: sp mode mail issue in the verification of SSL certificates “improper certificate verification” issues in jvn.jp (2013,2014) Many Reports on various Android apps

10. Copyright©2015 JPCERT/CC Allrights reserved. Why Certificate Verification Failure Concerns? 10 client The failure allows Man-in-the-middleattack server Information leakage Message modification Man-in-the-middle attack https://en.wikipedia.org/wiki/Man-in-the-middle_attack

12. Copyright©2015 JPCERT/CC Allrights reserved. What is SSL/TLS? 12 Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communications security over a computer network. https://en.wikipedia.org/wiki/Transport_Layer_Security They use X.509 certificates and hence asymmetric cryptography to authenticate the counterparty with whom they are communicating, and to negotiate a symmetric session key. This session key is then used to encrypt data flowing between the parties. https://nl.wikipedia.org/wiki/Secure_Sockets_Layer

13. Copyright©2015 JPCERT/CC Allrights reserved. SSL/TLS versions 13 Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communications security over a computer network. https://en.wikipedia.org/wiki/Transport_Layer_Security They use X.509 certificates and hence asymmetric cryptography to authenticate the counterparty with whom they are communicating, and to negotiate a symmetric session key. This session key is then used to encrypt data flowing between the parties. https://nl.wikipedia.org/wiki/Secure_Sockets_Layer SSL 3.0 - RFC6101 TLS 1.0 - RFC2246 TLS 1.1 - RFC4346 TLS 1.2 - RFC5246 ………. The protocol is still evolving; incorporating new cipher suites and countermeasures to known attack vectors…

14. Copyright©2015 JPCERT/CC Allrights reserved. SSL/TLS Transaction 14 client server Client hello Server Hello Certificate Server Hello Done ClientKeyExchange ChangeCipherSpec Finished ChangeCipherspec Finished applicationData This diagram is inspired from http://www.secureworks.com/cyber-threat-intelligence/threats/transitive-trust/

15. Copyright©2015 JPCERT/CC Allrights reserved. SSL/TLS Transaction 15 client server Client hello Server Hello Certificate Server Hello Done ClientKeyExchange ChangeCipherSpec Finished ChangeCipherspec Finished applicationData handshake phase Negotiating keys and parameters This diagram is inspired from http://www.secureworks.com/cyber-threat-intelligence/threats/transitive-trust/

16. Copyright©2015 JPCERT/CC Allrights reserved. SSL/TLS Transaction 16 client server Client hello Server Hello Certificate Server Hello Done ClientKeyExchange ChangeCipherSpec Finished ChangeCipherspec Finished applicationData Encrypted communication This diagram is inspired from http://www.secureworks.com/cyber-threat-intelligence/threats/transitive-trust/

17. Copyright©2015 JPCERT/CC Allrights reserved. NetCat: sample client program with URLConnection class 17 public class NetCat { public static void main(String[] argv) throws Exception { URI uri = new URI(argv[0]); URLConnection conn = uri.toURL().openConnection(); BufferedReader reader = new BufferedReader (new InputStreamReader (conn.getInputStream(), “UTF-8”)); String buffer = reader.readLine(); System.out.println(); while (null != buffer) { System.out.println(buffer); buffer = reader.readLine(); } } }

18. Copyright©2015 JPCERT/CC Allrights reserved. Sample session (1) 18 $ java NetCat http://www.jpcert.or.jp/ <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 …… ……………… $ java NetCat https://www.jpcert.or.jp/ <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 …… ……………… URLConnection supports both “http” and “https” protocol schemes.

19. Copyright©2015 JPCERT/CC Allrights reserved. Sample session (2) 19 $ java NetCat https://www.php.net/ Exception in thread “main” javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at sun.security.ssl.SSLSocketImpl.fatal (SSLSocketImpl.java:1937) ………… This server certificate is self-signed, hence certificate path validation failed. In case of HTTPS, URLConnection verifies the server certificate.

20. Copyright©2015 JPCERT/CC Allrights reserved.20 client server Client hello Server Hello Certificate Server Hello Done ClientKeyExchange ChangeCipherSpec Finished ChangeCipherspec Finished applicationData Client verifies server certificate SSL/TLS Transaction This diagram is inspired from http://www.secureworks.com/cyber-threat-intelligence/threats/transitive-trust/

21. Copyright©2015 JPCERT/CC Allrights reserved.21 client server Client hello Server Hello Certificate Server Hello Done ClientKeyExchange ChangeCipherSpec Finished ChangeCipherspec Finished applicationData Client verifies server certificate In this talk, We concentrate on this part. SSL/TLS Transaction This diagram is inspired from http://www.secureworks.com/cyber-threat-intelligence/threats/transitive-trust/

22. Copyright©2015 JPCERT/CC Allrights reserved.22 Server Certificates •A server certificate contains the public key and the domain name of the server (when it is used in HTTPS) •Some CA (Certificate Authority) guarantees the correspondence between the two •ITU-T standard X.509 •RFC5280, RFC6818 •Web browsers have a set of trusted CA certificates

27. Copyright©2015 JPCERT/CC Allrights reserved. Example: www.jpcert.or.jp. 27 • Issuer: •C=US •O=Symantec Corporation •OU=Symantec Trust Network •CN=Symantec Class 3 EV SSL CA - G3 •Subject: •serialNumber=0100-05-006504 •C=JP •postalCode=101-0054 •ST=Tokyo •L=Chiyoda-ku •streetAddress=“Hirose Bldg. 11F, 3-17 Kanda-nishikicho” •O=“Japan Computer Emergency Response Team Coordination Center” •OU=“System Administration Group” •CN=www.jpcert.or.jp • X509v3 extensions: •X509v3 Subject Alternative Name: •DNS:www.jpcert.or.jp •X509v3 Basic Constraints: •CA:FALSE CA Information Server Information

28. Copyright©2015 JPCERT/CC Allrights reserved. Example: www.google.com. 28 • Issuer: •C=US •O=Google Inc •CN=Google Internet Authority G2 •Subject: •C=US •ST=California •L=Mountain View •O=Google Inc •CN=google.com • X509v3 extensions: •X509v3 Subject Alternative Name: •DNS:google.com, DNS:*.2mdn.net, DNS:*.android.com, •DNS:*.appengine.google.com, DNS:*.au.doubleclick.net, •DNS:*.cc-dt.com, DNS:*.cloud.google.com, DNS:*.de.doubleclick.net, •DNS:*.doubleclick.com, DNS:*.doubleclick.net, •DNS:*.fls.doubleclick.net, DNS:*.fr.doubleclick.net, •DNS:*.google-analytics.com, DNS:*.google.ac, DNS:*.google.ad, •…….. (omitted) …….. •X509v3 Basic Constraints: •CA:FALSE

29. Copyright©2015 JPCERT/CC Allrights reserved.29 “Certificate Verification” contains 3 processes •Verifies that the received server certificate is properly created •⇒certificate verification (in a narrow sense) •Verifies that there is a proper certificate path •⇒certificate path validation •Verifies that the server name contained in the certificate matches the server name to contact •⇒host name verification

30. Copyright©2015 JPCERT/CC Allrights reserved. Certificate Verification (in a narrow sense) 30 lIs this certificate valid? • Correct ASN.1 data structure? • Properly signed by some trusted CA? • Not expired? • Not revoked?

31. Copyright©2015 JPCERT/CC Allrights reserved. Certificate Path Validation 31 Certification path validation algorithm https://en.wikipedia.org/wiki/Certification_path_validation_algorithm lAre there any certificate path(chain) starting from the certificate up to some trusted CA certificate? lIs this certificate path valid? RFC5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile 6. Certification Path Validation https://tools.ietf.org/html/rfc5280#section-6

32. Copyright©2015 JPCERT/CC Allrights reserved. Certificate Path Validation 32 https://security.stackexchange.com/questions/56389/ssl-certificate- framework-101-how-does-the-browser-actually-verify-the-validity Builds the chain between the server certificate and the trusted CA certificate … and verifies that each certificate is signed properly. Root CA

33. Copyright©2015 JPCERT/CC Allrights reserved. Hostname Verification 33 RFC2818: HTTP Over TLS 3.1. Server Identity https://tools.ietf.org/html/rfc2818#section-3.1 RFC5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile 7. Processing Rules for Internationalized Names https://tools.ietf.org/html/rfc5280#section-7 lConfirm the two identities match: the server name (domain name) to access and the server name stored in the certificate lsubjectAltName extension MUST be used if exists lMatching algorithm is the same as the algorithm used in certificate path validation

36. Copyright©2015 JPCERT/CC Allrights reserved. Vulnerability reports on JVN.JP 36 JVN#27388160: SumaHo forAndroid fails to verify SSL/TLS server certificates JVN#48270605: Yahoo! Japan Box for Android issue where it fails to verify SSL server certificates JVN#04560253: Yuko YukoApp for Android fails to verify SSL server certificates JVN#17637243: Kindle App for Android fails to verify SSL server certificates JVN#27702217: Ameba forAndroid contains an issue where it fails to verify SSL server certificates JVN#72950786: Outlook.com forAndroid contains an issue where it fails to verify SSL server certificates JVN#10603428: JR East JapanApp for Android. contains an issue where it fails to verify SSL server certificates JVN#16263849: Demaecan forAndroid. contains an issue where it fails to verify SSL server certificates JVN#48810179: Denny's App for Android. contains an issue where it fails to verify SSL server certificates JVN#97810280: KDrive Personal for Windows contains an issue where it fails to verify SSL server certificates JVN#75084836: Yahoo! Japan Shopping for Android contains an issue where it fails to verify SSL server certificates JVN#68156832: Yafuoku! Contains an issue where it fails to verify SSL server certificates JVN#39218538: Pizza Hut Japan Official OrderApp forAndroid. contains an issue where it fails to verify SSL server certificates JVN#85812843: FileMaker Pro fails to verify SSL server certificates JVN#39707339: Opera fails to verify SSL server certificates JVN#82029095: sp mode mail issue in the verification of SSL certificates “improper certificate verification” issues in jvn.jp (2013,2014) Many Reports on various Android apps

37. Copyright©2015 JPCERT/CC Allrights reserved. Vulnerable Code 37 public static HttpClient getNewHttpClient() { DefaultHttpClient v6; try { KeyStore v5 = KeyStore.getInstance(KeyStore.getDefaultType()); v5.load(null, null); MySSLSocketFactory mySSLSocket = new MySSLSocketFactory(v5); if(ApplicationDefineRelease.sAllowAllSSL) { ((SSLSocketFactory)mySSLScoket).setHostnameVerifier (SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER); } BasicHttpParams v2 = new BasicHttpParams(); HttpConnectionParams.setConnectionTimeout(((HttpParams)v2), 30000); ... } catch(Exception v1) { v6 = new DefaultHttpClient(); } return ((HttpClient)v6); }

38. Copyright©2015 JPCERT/CC Allrights reserved. Vulnerable Code 38 public static HttpClient getNewHttpClient() { DefaultHttpClient v6; try { KeyStore v5 = KeyStore.getInstance(KeyStore.getDefaultType()); v5.load(null, null); MySSLSocketFactory mySSLSocket = new MySSLSocketFactory(v5); if(ApplicationDefineRelease.sAllowAllSSL) { ((SSLSocketFactory)mySSLScoket).setHostnameVerifier (SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER); } BasicHttpParams v2 = new BasicHttpParams(); HttpConnectionParams.setConnectionTimeout(((HttpParams)v2), 30000); ... } catch(Exception v1) { v6 = new DefaultHttpClient(); } return ((HttpClient)v6); } ((SSLSocketFactory)mySSLScoket).setHostnameVerifier (SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER); Hostname verification is disabled!!

39. Copyright©2015 JPCERT/CC Allrights reserved. Vulnerable Code 39 public static HttpClient getNewHttpClient() { DefaultHttpClient v6; try { KeyStore v5 = KeyStore.getInstance(KeyStore.getDefaultType()); v5.load(null, null); MySSLSocketFactory mySSLSocket = new MySSLSocketFactory(v5); if(ApplicationDefineRelease.sAllowAllSSL) { ((SSLSocketFactory)mySSLScoket).setHostnameVerifier (SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER); } BasicHttpParams v2 = new BasicHttpParams(); HttpConnectionParams.setConnectionTimeout(((HttpParams)v2), 30000); ... } catch(Exception v1) { v6 = new DefaultHttpClient(); } return ((HttpClient)v6); } ((SSLSocketFactory)mySSLScoket).setHostnameVerifier (SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER); Hostname verification is disabled!!

40. Copyright©2015 JPCERT/CC Allrights reserved. Other Vulnerable Code Patterns 40 HostnameVerifier hv = new HostnameVerifier() { @Override public boolean verify(String hostname, SSLSession session) { // always return true, any hostnames are accepted return true; } }; empty HostnameVerifier

41. Copyright©2015 JPCERT/CC Allrights reserved. Other Vulnerable Code Patterns 41 TrustManager tm = new X509TrustManager() { @Override public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException { // do nothing, any certificates are accepted } @Override public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException { // do nothing, any certificates are accepted } @Override public X509Certificate[] getAcceptedIssuers() { return null; } }; empty TrustManager

42. Copyright©2015 JPCERT/CC Allrights reserved. SSL/TLS vulnerability as a research topic ACM CCS2012 Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html 42 ACM CCS2013 Rethinking SSL Development in an Appified World http://android-ssl.org/files/p49.pdf

43. Copyright©2015 JPCERT/CC Allrights reserved.43 SSL/TLS vulnerability as a research topic Many application mis-use SSL/TLS libraries!! - disable certificate verification - disable hostname verification -…… the cause(s) of SSL/TLS related vulnerabilities - Developer’s lack of understanding SSL/TLS - Releasing with the temporary configuration for internal testing - Requirement from the customer

45. Copyright©2015 JPCERT/CC Allrights reserved.45 https://bluebox.com/technical/android-fake-id-vulnerability/ Android Fake ID Vulnerability Lets Malware Impersonate Trusted Applications, Puts All Android Users Since January 2010 At Risk Presented at BlackHat 2014 USA ANDROID FAKEID VULNERABILITY WALKTHROUGH https://www.blackhat.com/us-14/archives.html#android-fakeid-vulnerability-walkthrough Improper Certificate Path Validation: Fake ID This vulnerability is related to application- signing in Android OS…

46. Copyright©2015 JPCERT/CC Allrights reserved.46 “there is a conspicuous absence of cryptographic verification of any issuer cert claims, instead defaulting to simple subjectDN to issuerDN string matching.” Improper Certificate Path Validation: Fake ID lEvery Android application is digitally signed lAndroid OS verifies the signature as a part of installation process lEquivalent to certificate verification in SSL/TLS lVerification code comes from Apache Harmony lThis code has a problem on certificate path validation

48. Copyright©2015 JPCERT/CC Allrights reserved. JarUtils::findCert (vulnerable) 48 private static X509Certificate findCert(Principal issuer, X509Certificate[] candidates) { for (int i = 0; i < candidates.length; i++) { if (issuer.equals(candidates[i].getSubjectDN())) { return candidates[i]; } } Picks up a certificate just matching the subjectDN. The signature is not validated. JarUtils.java

50. Copyright©2015 JPCERT/CC Allrights reserved.50 private static X509Certificate findCert(Principal issuer, X509Certificate[] candidates, X509Certificate subjectCert, boolean chainCheck) { for (int i = 0; i < candidates.length; i++) { if (issuer.equals(candidates[i].getSubjectDN())) { if (chainCheck) { try { subjectCert.verify( candidates[i].getPublicKey()); } catch (Exception e) { continue; } } return candidates[i]; } } JarUtils::findCert (fixed) The signature is verified JarUtils.java

51. Copyright©2015 JPCERT/CC Allrights reserved. Improper certificate path validation: Apple iOS 51 TWSL2011-007: iOS SSL Implementation Does Not Validate Certificate Chain http://blog.spiderlabs.com/2011/07/twsl2011-007-ios-ssl-implementation- does-not-validate-certificate-chain.html https://www3.trustwave.com/spiderlabs/advisories/TWSL2011-007.txt “iOS's SSL certificate parsing contains a flaw where it fails to check the basicConstraints parameter of certificates in the chain.” What is ‘basicConstraints’?

52. Copyright©2015 JPCERT/CC Allrights reserved. Example: www.jpcert.or.jp. 52 • Issuer: •C=US •O=Symantec Corporation •OU=Symantec Trust Network •CN=Symantec Class 3 EV SSL CA - G3 •Subject: •serialNumber=0100-05-006504 •C=JP •postalCode=101-0054 •ST=Tokyo •L=Chiyoda-ku •streetAddress=“Hirose Bldg. 11F, 3-17 Kanda-nishikicho” •O=“Japan Computer Emergency Response Team Coordination Center” •OU=“System Administration Group” •CN=www.jpcert.or.jp • X509v3 extensions: •X509v3 Subject Alternative Name: •DNS:www.jpcert.or.jp •X509v3 Basic Constraints: •CA:FALSE Basic Constraints is specified in RFC5280.

53. Copyright©2015 JPCERT/CC Allrights reserved. What does basicConstraints indicate? 53 [from RFC5280 section 4.2.1.9] (basicConstraints) indicates whether the certified public key may be used to verify certificate signatures. If (basicConstraints is not present or the value is false), then the certified public key MUST NOT be used to verify certificate signatures. CA certificates must have basicConstraints as TRUE, any other (nonCA) certificates must have basicConstraints as FALSE.

54. Copyright©2015 JPCERT/CC Allrights reserved. basicConstraints and Certificate Path Validation 54 basicConstraints must be TRUE basicConstraints must be TRUE The issuer vouches that the certificate is CA or not CA.

55. Copyright©2015 JPCERT/CC Allrights reserved. basicConstraints and Certificate Path Validation 55 basicConstraints must be TRUE basicConstraints must be TRUE The issuer vouches that the certificate is CA or not CA. iOS failed to confirm that any root CA and intermediate CA certificates have basicConstraints as TRUE. Malicious user may use an end- entity certificate to sign another certificate, and use it to MITM attack iOS users.

57. Copyright©2015 JPCERT/CC Allrights reserved.57 CVE-2014-3577Apache HttpComponents client: Hostname verification susceptible to MITM attack http://seclists.org/fulldisclosure/2014/Aug/48 Similar issues are reported for Apache Commons HttpClient (CVE-2012-6153,CVE-2012-5783) Apache HttpComponents and Apache Axis “Apache HttpComponents … may be susceptible to a 'Man in the Middle Attack' due to a flaw in the default hostname verification during SSL/TLS when a specially crafted server side certificate is used.”

58. Copyright©2015 JPCERT/CC Allrights reserved. “a (crafted) DN with a O field such as O="foo,CN=www.apache.org” and ...... ordered such that the O appears prior to the CN field would incorrectly match on the <www.apache.org> ..." 58 … a specially crafted server side certificate is used.” Apache HttpComponents and Apache Axis

59. Copyright©2015 JPCERT/CC Allrights reserved.59 [from https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3596] The getCN function in Apache Axis 1.4 and earlier does not properly verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the- middle attackers to spoof SSL servers via a certificate with a subject that specifies a common name in a field that is not the CN field. NOTE: this issue exists because of an incomplete fix for CVE-2012-5784. Axis 1.x Axis 1.x CVE-2012-5784 patch Axis 1.x CVE-2014-3596 patch Does not verify hostnames at all! Verify hostnames, but poor quality… Better quality verification… Apache HttpComponents and Apache Axis

60. Copyright©2015 JPCERT/CC Allrights reserved. CVE-2012-5784 fix 60 private static void verifyHostName(final String host, X509Certificate cert) throws SSLException { String cn = getCN(cert); String[] subjectAlts = getDNSSubjectAlts(cert); verifyHostName(host, cn.toLowerCase(Locale.US), subjectAlts); } private static String getCN(X509Certificate cert) { String subjectPrincipal = cert.getSubjectX500Principal().toString(); return getCN(subjectPrincipal); } private static String getCN(String subjectPrincipal) { StringTokenizer st = new StringTokenizer(subjectPrincipal, ","); while(st.hasMoreTokens()) { String tok = st.nextToken().trim(); if (tok.length() > 3) { if (tok.substring(0, 3).equalsIgnoreCase("CN=")) { return tok.substring(3); } } } return null; } Recognizes the data as a comma-separated string list and searches “CN=“. Hence it detects “CN=“ inside some attribute string.

61. Copyright©2015 JPCERT/CC Allrights reserved. CVE-2014-3596 fix(1) 61 private static void verifyHostName(final String host, X509Certificate cert) throws SSLException { String[] cns = getCNs(cert); String[] subjectAlts = getDNSSubjectAlts(cert); verifyHostName(host, cns, subjectAlts); } private static String[] getCNs(X509Certificate cert) { String subjectPrincipal = cert.getSubjectX500Principal().toString(); return getCNs(subjectPrincipal); } private static String[] getCNs(String subjectPrincipal) { …….. }

62. Copyright©2015 JPCERT/CC Allrights reserved. CVE-2014-3596 fix(2) 62 private static void verifyHostName(final String host, X509Certificate cert) throws SSLException { …….. } private static String[] getCNs(X509Certificate cert) { …….. } private static String[] getCNs(String subjectPrincipal) { if (subjectPrincipal == null) { return null; } final List cns = new ArrayList(); try { final LdapName subjectDN = new LdapName(subjectPrincipal); final List rdns = subjectDN.getRdns(); for (int i = rdns.size() - 1; i >= 0; i--) { final Rdn rds = (Rdn) rdns.get(i); final Attributes attributes = rds.toAttributes(); final Attribute cn = attributes.get("cn"); if (cn != null) { try { final Object value = cn.get(); if (value != null) { cns.add(value.toString()); } } catch (NamingException ignore) {} } } } catch (InvalidNameException ignore) { } return cns.isEmpty() ? null : (String[]) cns.toArray(new String[ cns.size() ]); } This code uses LdapName class to find CN attribute.

63. Copyright©2015 JPCERT/CC Allrights reserved.63 Another Improper hostname verification: CVE-2013-4073 Ruby Hostname check bypassing vulnerability in SSL client (CVE-2013-4073) https://www.ruby-lang.org/en/news/2013/06/27/hostname-check-bypassing-vulnerability-in-openssl-client-cve-2013- 4073/ “Ruby’s SSL client implements hostname identity check but it does not properly handle hostnames in the certificate that contain null bytes.”

65. Copyright©2015 JPCERT/CC Allrights reserved.65 Point1: Do Verify Certificates Certificate Verification is THE mandatory procedure for SSL/TLS communication Be careful if disabling verification for debugging ̶Check the configuration for release builds ̶Your release build behaves properly? For Java/Android applications ̶Donʼt ignore SSLException ̶Donʼt disable TrustManager ̶Donʼt disable HostnameVerifier

66. Copyright©2015 JPCERT/CC Allrights reserved.66 Point2: Verify Certificate Path and Hostname Properly Basic Principle: When using third-party libraries, use them as is, customization should be as smallest as possible When you need to implement the verification procedure by yourself ̶Understand the specification properly ̶Test verification behaviors carefully ̶Include test patterns reflecting the known attack vectors BE CAREFUL! Certificate path validation and hostname verification are complicated tasks.

67. Copyright©2015 JPCERT/CC Allrights reserved. Best Practice for Using Cryptography https://developer.android.com/guide/practices/security.html#Crypto “In general, try using the highest level of pre-existing framework implementation that can support your use case. ……… 67 If you cannot avoid implementing your own protocol, we strongly recommend that you do not implement your own cryptographic algorithms.”

68. Copyright©2015 JPCERT/CC Allrights reserved. Note: Debugging with Proxy Tools 68 Proxy tools are useful for testing verification behavior •Responding with a self-signed certificate or a dynamically generated certificate •Certificates with improper hostnames •Expired certificates •Revoked certificates •Famous / popular proxy tools are Burp proxy, dsniff, Fiddler, mitmproxy, …

70. Copyright©2015 JPCERT/CC Allrights reserved. BOOKS 70 lBulletproof SSL and TLS lhttps://www.feistyduck.com/books/bulletproof-ssl- and-tls/ lマスタリングTCP/IPSSL/TLS編 lhttp://shop.ohmsha.co.jp/shop/shopdetail.html?bra ndcode=000000001666&search=4-274-06542-1 And if you can read Japanese…

71. Copyright©2015 JPCERT/CC Allrights reserved.71 WWW resources Introduction to Public-Key Cryptography — https://developer.mozilla.org/en-US/docs/Introduction_to_Public- Key_Cryptography Exciting Updates to Certificate Verification in Gecko — https://blog.mozilla.org/security/2014/04/24/exciting-updates-to-certificate- verification-in-gecko/ Japan smartphone Security Association (JSSEC), Android Application Secure Design/Secure Coding Guidebook —https://www.jssec.org/dl/android_securecoding_en_20140701.pdf OnionKit by Android Library Project for Multi-Layer Network Connections (Better TLS/SSL and Tor) —https://github.com/guardianproject/OnionKit

72. Copyright©2015 JPCERT/CC Allrights reserved. SSL Vulnerabilities: Who listens when Android applications talk? —http://www.fireeye.com/blog/technical/2014/08/ssl-vulnerabilities- who-listens-when-android-applications-talk.html Defeating SSL Certificate Validation for Android Applications —https://secure.mcafee.com/us/resources/white-papers/wp- defeating-ssl-cert-validation.pdf CERT/CC Vulnerability Note VU#582497: Multiple Android applications fail to properly validate SSL certificates —https://www.kb.cert.org/vuls/id/582497 72 WWW resources

73. Copyright©2015 JPCERT/CC Allrights reserved. OWASP, Certificate and Public Key Pinning — https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning OWASP, Pinning Cheat Sheet —https://www.owasp.org/index.php/Pinning_Cheat_Sheet Java Pinning (Flowdalic / java-pinning) —https://github.com/Flowdalic/java-pinning Android Pinning by Moxie Marlinspike (moxie0 / AndroidPinning) — https://github.com/moxie0/AndroidPinning 73 WWW resources (Certificate and Public Key Pinning)

Case Studies and Lessons Learned from SSL/TLS Certificate Verification Vulnerabilities (JavaOne2015 Edition)

JPCERT Coordination Center

Case Studies and Lessons Learned from SSL/TLS Certificate Verification Vulnerabilities (JavaOne2015 Edition)

A particular slide catching your eye?