It's going to happen sooner or later...sooner probably. You're going to be asked about your company's mobile app or a mobile app your company wants to install across all mobile devices. They'll put the request in the "yet another duty as assigned" (YADAA) category/bucket. You look at the network traffic; it's using TLS so you can't see the content. Cool, right? Maybe, maybe not. Can an attacker get man in the middle position by tricking users, or by attacking the very root of trust (well, one of the 100 or so root CAs) that is used to sign a TLS server cert? It is a complicated situation and requires a thorough understanding of several systems and protocols to address. I want you to be smart on the subject, so when that YADAA comes your way, you can answer the question knowledgeably and authoritatively. So here you go...read on.
The first installment of this two-part blog post will provide some background on TLS (Transport Layer Security) certificates so you can understand why your mobile apps should implement certificate pinning. In the second part, I'll discuss a tool that was released recently, called TrustKit, that makes it easy for iOS developers to implement certificate pinning with no change to the iOS app. (No change presumes the URLs to be protected are requested by TLS already). No analogous project exists for Android yet.
Background
TLS provides transport encryption to protect data while in transit over a network, providing confidentiality and integrity protection against untrusted and unknown network nodes. This is a mainstay in our protection of information in transit. In addition to recent attacks against implementations in TLS/SSL, (iOS/OSX goto fail; Heartbleed; Poodle) there are fundamental trust issues within the implementation of TLS. A trusted Certification Authority (CA) is trusted to issue certificates for any resource.
The TLS handshake involves a client verification of the certificate the server provides, then an optional server validation of client certs. In practice, there is no server validation of client certificates, but the spec allows for it.
Diagram Source here
There are 5 basic items that the client validates during the assessment of the server presented certificate.
- Is this certificate current and still valid based on the expiration date in the cert compared to the current system date?
- Is this certificate intended for the purpose I'm attempting to use it for? This capability is defined in the certificate. In the case of a client connecting over HTTPS to a server, the certificate must include the specification for identifying a server.
- Is this certificate on a revocation list? In practice, we rarely see OCSP (Online Certificate Status Protocol - RFC 6960) a real time query mechanism for certificates, used. The client may have downloaded CRLs stored. The certificate offered may include a query URL.
- Is this certificate issued to the resource I'm requesting? If the browser requested https://www.willhackforsushi.com, but the certificate was issued to a server named www.montance.com, the browser (or mobile app) shouldn't allow the connection to proceed.
- Is this certificate issued by a certification authority I trust? The certification authority (CA) included with the mobile device or web browser is stored in a structure called a certificate store. The list of trustworthy authorities usually numbers in the tens of CAs up to 100 or more CAs. This means that any of these CAs (companies, organizations, or government entities) could issue a certificate for any server name. In practice, the CA is supposed to vet the requester of a certificate. In practice, the CA is only supposed to issue certificates to trustworthy people who actually represent the organization the certificate is assigned to. In practice, the CA has your personal privacy as its primary concern. In reality, we've seen a small number of violations of these practical considerations.
To put this in perspective, iOS 9 trusts 218 CA's:
$ curl -s https://support.apple.com/en-us/HT205205 | grep '</tr><tr><td>' | wc -l 218
Attacks
We've seen some attacks in the past related to certificate manipulation. We've seen scenarios of complete CA compromises that were used to issue unauthorized certs. We've seen CAs tricked into handing out certs. We've seen users fail to protect the CA-issued private keys which resulted in unauthorized certificates being issues. Below I cite two reported instances (India CCA and TURKTRUST Inc) where government organizations have issued certificates for servers in an unauthorized fashion. These two are not really a big deal, just for google.com host certificates. Also, many organizations using HTTP proxies will configure CA certs on the client end points, allowing for the transparent interception of HTTPS communication.
We've seen theoretical and in the wild attacks against TLS and its related certificate authority infrastructure and organizations. Why, there's even an RFC "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)"
Some of my favorite failures are below. I like studying failure; it helps us to improve.
- 2001 : VeriSign issues Microsoft certificates to unauthorized party: https://support.microsoft.com/en-us/kb/293818
- 2008 : MD5 Collision Construction allows rouge CA Certs http://www.zdnet.com/article/ssl-broken-hackers-create-rogue-ca-certificate-using-md5-collisions/
- 2009 : TLS Renegotiation attack http://blog.g-sec.lu/2009/11/tls-sslv3-renegotiation-vulnerability.html
- 2011: Diginotar http://arstechnica.com/security/2011/09/comodo-hacker-i-hacked-diginotar-too-other-cas-breached/
- 2011: Duqu - Code Signing used in malware http://www.symantec.com/connect/blogs/duqu-protect-your-private-keys
- 2013 : TURKTRUST - Unauthorized certs https://technet.microsoft.com/en-us/library/security/2798897.aspx
- 2014 : India CCA - Unauthorized Google certs http://www.entrust.com/google-fraudulent-certificates/
- 2014: Heartbleed http://heartbleed.com/
- 2014 : goto fail; https://support.apple.com/en-us/HT202934
- 2015 : Microsoft revokes certs associated with live.fi https://technet.microsoft.com/en-us/library/security/3046310
In many of the cases listed above, there was some fundamental component of the protocol or the implementation that undermined integrity of the security. Several of the attacks were entirely fraudulent certificates. You can't have endpoint protection when there is a broken implementation on the endpoint (like in the Apple goto fail;) or in the server OS (like in Heartbleed). But, we can address the frequent (2001, 2009, 2011, 2013, 2014, 2015) scenario of fraudulent certificates used in networks by requiring our mobile applications to only trust specific certificates we intend for use.
Certificate Pinning
Certificate pinning is the application-specific requirement that some specific certificate or CA be required for a TLS connection, rather than accommodating any of the CAs the phone trusts. This can also be used to remove the user from the negotiation. Certificate pinning is most effective when the user is unable to override it.
For protecting your data, this is a useful thing. Is it foolproof? Certainly not. For example, there's a tweak available for jailbroken iPhones called SSLKillSwitch (https://github.com/iSECPartners/ios-ssl-kill-switch) which is a "Blackbox tool to disable SSL certificate validation - including certificate pinning - within iOS Apps." Instead of falling victim to the perfect solution fallacy, I recommend developers use certificate pinning to minimize the likelihood of data interception, while acknowledging the reality that a jailbroken or rooted endpoint is not going to provide the same data protection as a non-rooted device.
Cert pinning provides your application with a layer of certificate control that allows you to specify which certificates you'll accept, substantially limiting the likelihood of unauthorized information disclosure or alteration during network transmission. Another scenario where this may be undesirable is if your organization uses a privately issued CA to introduce a man-in-the-middle (MITM) TLS scenario for data loss protection. Google implements one of the largest certificate pinning instances in the world via its Chrome browser. It addresses this nuance by allowing the private trust store CAs to override pinning, while prohibiting the public trust store to violate pinning. Read more here.
Here's a simple example of how certificate pinning could help you to protect your organization's data. A user, alibo, reported to Google Groups that there was a cert error reported by Google Chrome. As it turns out, Google used certificate pinning capability in the Chrome browser to identify unexpected certificates signing certificates for servers in the google.com domain. Read more here.
That is a public example of detecting the DigiNotar compromise.
Stay Tuned?
In my next blog installment I'll discuss the specific implementation of certificate pinning in iOS applications using TrustKit. Let me know if you found this useful on twitter @CCrowMontance.
P.S. If you like this kind of thing, you really should consider joining me for the SANS Security 575 course on mobile device penetration testing and security in New Orleans in January. We call the event SANS Security East, and it's gonna be an awesome event full of great strategies, tactics, techniques, and practical advice on securing your organizations mobile devices! I hope you can make it!
