pki related incidents in 2013-2014
TRANSCRIPT
PKI related incidents in 2013/2014
Andrej Šimko
13.07.2014
1 Abstract The Public Key Infrastructure is probably the most used security measure on the internet. All major
sites and services are entrusting their security and the security of their customers and services to the
PKI by establishing a bond between the public keys and the entities in form of the certificates. End-to-
end encryption, domain validation, chains of trust set up by Certificate Authorities (CAs) ,
authentication of users to applications by smart cards, SSL/TLS protocols and many other systems rely
on the proper PKI infrastructure – by checking if certificate is valid, and only then establishing secure
server-client connection. Although these systems have been here for decades, because of their wide
usage all over the internet, there are constantly being exploited in various ways. Breaking any part of
system based on PKI would result in security failure of the system. This paper is trying to list and
explain major incidents since 2013.
2 Introduction There are many different attack scenarios on multitude of levels, each of which can potentially break
the security of the connection. In recent years, the human factor has been exploited/misused many
times, which allowed creating fraudulent certificates by compromised CAs, or signing certificates for
different domains (mostly Google ones). With a valid certificate signed by trusted CA and man-in-the-
middle attack, communication on the internet can be eavesdropped or modified. Attacks on PKI are on
the rise and gaining popularity [7].
If the secure connection (e.g. HTTPS) seems to be ok because the browser doesn’t see anything wrong
with the certificate, and if this certificate is somehow corrupted, the attacker can redirect user without
his knowledge to a malicious server and have secure connection only between malicious server and
user. This however means that the attacker can read everything user thinks is secured and confidential;
and also redirect everything to the legitimate server (for example if attacker spoofs Gmail, user would
receive his emails but attacker as the middle man would see everything) without user’s knowledge.
Apart from Man-In-The-Middle (MITM) attacks, also website spoofing or server impersonation is
possible.
3 Potential incidents There are many known vulnerabilities which I didn’t find any real world example of exploitation of.
This however doesn’t mean attacks are not happening regularly. If anything, these vulnerabilities give
attacker huge chance for mounting an attack.
3.1 Signed Android applications
For any application to be put on Google Play, it must first be digitally signed by a private key. The
problem is that this is also possible with home-made, self-signed certificates, since Android doesn’t
require applications to be signed by someone trustworthy [1]. Android itself doesn’t have any
information window that would say who signed the application, or if the source is trustworthy.
Another example of bad handling of Android with certificates is not checking properly for the
expiration date. For example, the popular game Angry Birds can be installed without giving away any
problems, although the certificate validity is set to be between 19.08.2010-26.07.2010 [1]. The main
thing to notice is that it actually expires before it is valid, and also it was valid 4 years ago and user
doesn’t know about any of these certificate issues. Other flaw is that certificates are checked only
while the installation process, but not during the running time – the attacker with root access can
modify any files in the phone without requiring any digital signatures. “The certificate does not need
to be signed by a certificate authority: it is perfectly allowable, and typical, for Android applications to
use self-signed certificates” [2]. Anyone can thus make a malicious application, sign it by any
certificate, and user won’t notice anything suspicious.
3.2 Smartphone applications that use SSL/TLS
Dozens of self signed certificates for impersonating banking, social networks and e-commerce have
been found on the web [16]. Since browsers are rather good in handling certificates (when they are not
signed by trusted CA), they don’t pose any real thread there – the main concern are however mobile
apps, since many of them are doing inadequate checks of SSL certificate validities. Self-signed
certificates were issued to domains of Facebook, Google, Apple, Russian bank and Russian payment
service provider [16]. Along with ARP spoofing, compromising router or changing DNS victim’s
settings; the attacker can mount MITM attack without user knowing about it. There have been three
[17, 18, 19] interesting researches in this area – first two of Android applications on Google Play, third
one of iOS applications. Results are self-explaining – at the beginning of 2014, “40% of the audited
apps did not validate the authenticity of SSL certificates presented” [19]. This can have huge impact
on security of banking applications, as well as any others that require secure connection and
communication only with legitimate server.
3.3 Heartbleed
Probably the most known bug in TLS implementation of OpenSSL library can also be used to leak
private keys [10]. Thanks to the missing boundary check, millions of web servers leaked all sorts of
sensitive information from their memory. Most people were concerned about leakage of login
credentials, passwords or authentication cookies, but there is also a way of getting the private keys
itselves. This would enable decryption of all previously observed secured communications (if the
perfect forward secrecy was not negotiated at the time); and it would also enable mounting of MITM
attack to all future TLS sessions. It’s a well known fact that the security of RSA system depends on
not being able to factorize the product of 2 large prime numbers. The problem is that server needs to
store these 2 numbers inside its memory to be able to sign TLS handshakes. Using heartbleed packets,
the only problem is to identify returned data. Let’s say we have 2048-bit number N. This means that
both p and q are 1024-bit long (128 bytes). By exploiting the well-known fact that OpenSSL library
represents big numbers in little-endian in the memory, this problem can be broken down to treating
128 consecutive bytes in the packet as little-endian numbers and testing if it divides N. Of course this
could be interpreted as a cold boot attack and thus Coppersmith method [9] can be employed here – N
can be efficiently factorized if either the button or top half (in our case 64 bytes) of p is known. This
results in finding the private key in a matter of days or less [10].
4 Existing incidents Apart from the “possible” threads that I didn’t find any case of exploitation of; there are plenty of
incidents in PKI world that are occurring regularly and are publically known.
4.1 Issuing valid certificates to non-existing companies
At the beginning of 2013, the company Malwarebytes has identified a banking malware that was
signed by a valid certificate issued by DigiCert [12]. Signing was done to bypass security solutions,
and for the malware to look more legitimate. This malware was engineered to target Brazilians and
after detection, it was revoked within 2 days.
4.2 Issuing intermediate certificates to untrusted users
Every CA is responsible for verifying customer’s claim on a particular domain, as well as a
background checking if the person/company is who he claims to be. This demand is of course natural
– we don’t want “John Doe” to be assigned certificate for “*.google.com” domain. Since every
browser has over a hundred build-in certificates (Mozilla Firefox currently - 07.07.2013 has 170
certificates [8]), there are many different CAs to approach with claim for any domain. Intermediate
certificates in particular are used to enable the certification for any domains, along with inherited trust
level of their issuing CA. This allows owner to sign and create trusted SSL certificates for any domain.
4.2.1 Example: Turktrust
Because of an undetected certificate profile migration error between the company’s testing and
production system [15], the company Turktrust mistakenly issued 2 intermediate certificates to
companies, who requested regular certificates [14]. One of them was revoked by the customer who
received it, but the other one (issued to EGO – public transport authority in Ankara, Turkey) was not.
Since Turktrust was in root certificates of probably every browser, company EGO had the ability to
sign SSL certificates to any domain of their choosing. This would probably go unnoticed, if EGO
hasn’t decided to analyze HTTPS connection of its employees by creating proxy server which
examined content of HTTPS connection and then re-encrypted data while communicating with
legitimate servers. This can be seen as keybridging or MITM attack. Users are usually notified about
the fact that secure connection can’t be established since it ends up on the proxy server ; but not if
proxy server uses intermediate certificate signed by globally trusted root certificate. Employees who
used Chrome received an error message thanks to Google’s technology certificate pinning and thus
Google managed to discover abuse of certificate for “*.google.com”.
4.3 Issuing rouge certificates by trusted (intermediate) CA
At the end of 2013, French government CA signed certificates for multiple Google domains [21] to
inspect packets in their private network. More recently, Indian government CA issued rouge
certificates for Google domains [20]. This particular incident affected only Windows products, since
this CA was in root CA list of Microsoft; however users of Google products were safe thanks to their
certification pinning. Of course, all certificates have been revoked almost immediately after their
discovery.
4.4 Code-signing certificate leakage
To know if installed software comes from legitimate company, PKI is used to sign that software by
using code-signing certificates. Before installing, these certificates are automatically checked and if
system believes they are legitimate, user rarely sees it. If any code-signing certificate is leaked, it can
be used to sign any malware, which will result its installation to come from a valid source. Such
incidents are happening more and more often, for example the Adobe leakage in September 2012 [5].
Malware can then be used for privilege escalation, or lateral movement within an environment
following an initial machine compromises.
4.4.1 Opera Software
Although this discovered breach is said to have only a limited impact [4], attackers who stole code-
signing certificate from Opera Software were able to sign and install malware. To do so, the attackers
were able to steal at least one expired code signing certificate. This lead to the distribution of malware
that appeared to be from genuine Opera Software and it has potentially been automatically received
and installed on thousands of Windows browsers [4].
4.4.2 Bogus antivirus
With the help of code-signing certificates, malware can be misused for all sorts of things. For example
the fake antivirus application “Antivirus Security Pro” that was first detected in 2009 and so far has 30
different names (along with “Win32/Winwebsec” as Microsoft calls it) is such an example. An
interesting thing is that the certificates this particular malware uses were issued in 6 countries and by
well established CAs such as VeriSign, Comodo, Thawte and DigiCert [6].
4.5 Obtaining PKI certificate with password
According to RSA Conference in 2013 [7], the criminals are recently growing “more successful in
obtaining unauthorized digital certificates or misusing cryptographic keys”. This is true also for
Edward Snowden – according to the memo from 10.02.2014 by NSA [3], Edward Snowden was able
to obtain access to the classified information on NSANet by compromising their PKI. He did so thanks
to a human error, when another employee of the NSA used his PKI certificate and typed in password
on Snowden’s computer. This event lead to even greater compromisation of classified information.
After the civilian confessed this fact to the FBI, his certificate was revoked.
5 Build-in certificate statistics Since Mozilla keeps up-to-date list of all built-in certificates in their browser on their website [8],
many statistics can be observed. There is still 1 certificate with MD2 and 1024-bit modulus present
valid until 2028 (although now with flag “legacy”). Moreover, there are eight MD5 certificates valid
until at least 2018, from which all but one have only 1024-bit modulus. You can see the exact numbers
in Table 1. List of Mozilla built-in certificates.
Signature algorithm Modulus Number of certificates
MD2 1024 1
MD5 1024 7
2048 1
SHA1
1024 12
2048 91
4096 22
SHA-256 2048 16
4096 14
SHA-384 4096 1
ECC - 5
Table 1. List of Mozilla built -in certificates
As we can see, most of the certificates that are currently used have at least 2048-bit modulus, although
there are some legacy certificates which use insecure MD5 or not recommended modulus length of
1024-bit. If attacker would factorize any of shorter keys, they could create certificates and sign them
with particular private keys. MD5 support should also be dropped because there are known attacks
[22] which exploit collisions and can be used to create rogue CA certificates that seem to be signed by
root CA that browsers trust.
6 Countermeasures Many countermeasures either already exist but are not widely implemented yet, or require more
supervision to avoid human errors. Few examples follow:
Accountability of CA – when CA makes a mistake, usually their clients are the ones who are
harmed by this fact. However, they can lose their place in root certificate lists in browsers and
go bankrupt.
Disabling low security systems on the server side, and their support in browsers
Enabling perfect forward secrecy – even with leakage of private keys, previously observed
communication would remain confidential.
Certificate pinning helps against MITM attacks by validating certificate against trusted
validation data – for example Google Chrome include validation data for “*.google.com”
certificate which already helped detecting fraudulent certificates released by DigiNotar [11].
This solution works, but is not scalable.
Use Online Certification Status Protocol (OCSP) to confirm the current validity of certificates .
Prompt revocation of misused/bogus certificates.
Detection of certificate spoofing – the easiest way is to use software/add-ons that already have
legitimate certificates stored – if different one than expected is detected, user is notified. In
this simple scheme, the problem occurs when certificates are changed or compromised. Better
way would be to use SRP (Secure Remote Password) or DH-EKE (Diffie-Hellman Encrypted
Key Exchange) protocols. Since both protocols offer mutual authentication and strong
encryption key negotiation, if they would be modified to send the client the value of the real
certificate encrypted with negotiated strong encryption key, after client decrypts it and finds
out a mismatch, MITM would be detected [13]. If also client sent copy of received certificate
to the server, it could be warned that MITM happened and could take some proactive action.
TACK (Trusted Assertions for Certificate Keys) – is a proposal for TLS Extension for public
key pinning framework, that is backward compatible with existing CA certificates and
provides a layer of indirection away from CAs. It uses “TACK signing key” (TCK), which is
used for signing server’s TLS keys. Trust in CA is not required and TSK keys can be revoked
if TLS private keys are compromised.
DNSSEC-TLS – usage of DNSSEC to perform the domain validation prevents CAs from
misusing certificates, since such certificates would not match in content of DANE/CAA
record [23]. This holds, because during TLS handshake the chain of DNSSEC records must be
send along with the server certificate.
Implement TLSv1.1 and TLSv1.2 on more servers since they use newer crypto.
Use add-ons in browsers – for example Calomel SSL Validation [24] is able to either allow
TLSv1.1 and TLSv1.2; or only allow strong ciphers (e.g. “128 bit PFS and stronger”).
7 Conclusions As we can see, over the recent years the attacks on PKI has grown on popularity. Attackers are trying
to obtain certificates or means of creating and signing certificates in a way it would be undetectable by
software using it (browsers, mobile apps…). We can see decrease of attacks that would target
weaknesses like MD5 or short RSA keys (mainly because these are becoming deprecated and are not
recommended to use). Powerful adversary can mount MITM attack without users’ knowledge, but he
should not do it for Google domains as Chrome and other Google products support certificate pinning
which enables them to immediately discover bogus certificate.
There are many possible countermeasures of how to secure PKI; the most important ones are doing
more checking of CAs before signing any certificate. Most of the incidents I found were targeting
Google, which resulted in their immediate detection. New protocol extensions (DNSSEC-TLS,
TACK…) should be implemented in browsers and at servers. TLSv1.1 and TLSv1.2 should be
implemented on more servers as new browsers already have support for them. Certificates with short
keys or MD5 should be dropped from default certificate lists in browsers. Users can turn on OSCP,
and turn off weak ciphers or install add-ons that support only safer crypto to protect themselves.
8 Resources [1] MCNAMEE, Kevin. How to Build a SpyPhone: A Demonstration of an Android Spyphone
Trojan. [online]. 28.07.2013 [cit. 2014-07-12]. Available from: https://www.blackhat.com/us-
13/archives.html#McNamee
[2] Signing Your Applications. ANDROID. [online]. [cit. 2014-07-12]. Available from:
https://developer.android.com/tools/publishing/app-signing.html
[3] NATIONAL SECURITY AGENCY. Memorandum: Congressional Notification - Resignation
of NSA Employee [online]. 10.02.2014 [cit. 2014-07-12]. Available from:
http://msnbcmedia.msn.com/i/msnbc/sections/news/NSA_Snowden_Memo.pdf
[4] NARAINE, Ryan. Opera Software Hit by 'Infrastructure Attack': Malware Signed with Stolen
Cert. [online]. 26.06.2013 [cit. 2014-07-12]. Available from: http://www.securityweek.com/opera-software-hit-infrastructure-attack-malware-signed-stolen-cert
[5] ARKIN, Brad. Inappropriate Use of Adobe Code Signing Certificate. [online]. 27.09.2012 [cit.
2014-07-12]. Available from: https://blogs.adobe.com/security/2012/09/inappropriate-use-of-adobe-
code-signing-certificate.html
[6] KIRK, Jeremy. Bogus AV program uses 12 stolen digital certificates to make the malware look legit. [online]. 16.12.2013 [cit. 2014-07-12]. Available from:
http://www.pcworld.com/article/2080620/bogus-antivirus-program-uses-a-dozen-stolen-signing-
certificates.html
[7] BOCEK, Kevin. Consensus at RSA Conference 2013: PKI is Under Attack. [online].
04.03.2013 [cit. 2014-07-12]. Available from: http://www.venafi.com/blog/post/consensus-at-rsa-
conference-2013-pki-is-under-attack/
[8] Mozilla Included CA Certificate List. MOZILLA. [online]. [cit. 2014-07-12]. Available from:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/included/
[9] COPPERSMITH, Don. Small Solutions to Polynomial Equations, and Low Exponent RSA
Vulnerabilities. [online]. 11.08.1996 [cit. 2014-07-12]. Available from:
http://link.springer.com/article/10.1007%2Fs001459900030#page-1
[10] XU, Rubin. Heartbleed and RSA private keys. [online]. 25.04.2014 [cit. 2014-07-12].
Available from: https://www.lightbluetouchpaper.org/2014/04/25/heartbleed-and-rsa-private-keys/
[11] Certificate and Public Key Pinning. [online]. 26.06.2014 [cit. 2014-07-12]. Available from:
https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
[12] KOVACS, Eduard. Brazilian Banking Malware Signed with Valid DigiCert Digital Certificate. [online]. 06.02.2013 [cit. 2014-07-12]. Available from:
http://news.softpedia.com/news/Brazilian-Banking-Malware-Signed-With-Valid-DigiCert-Digital-
Certificate-327180.shtml
[13] HUITEMA, Christian. The Comodo Hacker, PKI and Internet Standards. [online]. 23.01.2012
[cit. 2014-07-12]. Available from: https://huitema.wordpress.com/2012/01/23/the-comodo-hacker-pki-and-internet-standards/
[14] DUCKLIN, Paul. The TURKTRUST SSL certificate fiasco - what really happened, and what
happens next?. [online]. 08.01.2013 [cit. 2014-07-12]. Available from:
http://nakedsecurity.sophos.com/2013/01/08/the-turktrust-ssl-certificate-fiasco-what-happened-and-
what-happens-next/
[15] CONSTANTIN, Lucian. Rogue Google SSL certificate not used for dishonest purposes, Turktrust says. [online]. 04.01.2013 [cit. 2014-07-12]. Available from:
http://www.computerworld.com/s/article/9235260/Rogue_Google_SSL_certificate_not_used_for_d
ishonest_purposes_Turktrust_says
[16] CONSTANTINE, Lucian. Dozens of rogue self-signed SSL certificates used to impersonate high-profile sites. [online]. 13.02.2014 [cit. 2014-07-12]. Available from:
http://www.pcworld.com/article/2097781/dozens-of-rogue-selfsigned-ssl-certificates-used-to-
impersonate-highprofile-sites.html
[17] GEORGIEV, Martin and Subodh IYENGAR. The Most Dangerous Code in the World:
Validating SSL Certificates in Non-Browser Software. [online]. 16.10.2012 [cit. 2014-07-12]. Available from: http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
[18] FAHL, Sascha and Lars BAUMGÄRTNER. Why Eve and Mallory Love Android: An
Analysis of Android SSL (In)Security. [online]. 16.10.2012 [cit. 2014-07-12]. Available from:
http://www2.dcsec.uni-hannover.de/files/android/p50-fahl.pdf
[19] SANCHEZ, Ariel. Personal banking apps leak info through phone. [online]. 08.01.2014 [cit. 2014-07-12]. Available from: http://blog.ioactive.com/2014/01/personal-banking-apps-leak-info-
through.html
[20] HIGGINS, Kelly Jackson. Fake Google Digital Certificates Found & Confiscated. In: [online].
07.09.2014 [cit. 2014-07-12]. Available from:
http://www.darkreading.com/endpoint/authentication/fake-google-digital-certificates-found-and-
confiscated/d/d-id/1297165?piddl_msgid=232822#msg_232822
[21] TUNG, Liam. French Treasury accidentally signs SSL certificate for Google.com domains.
[online]. 10.12.2013 [cit. 2014-07-12]. Available from:
http://www.cso.com.au/article/533843/french_treasury_accidentally_signs_ssl_certificate_google_c
om_domains/
[22] SOTIROV, Lexander and Marc STEVENS. MD5 considered harmful today: Creating a rogue CA certificate. [online]. 16.06.2011 [cit. 2014-07-12]. Available from:
http://www.win.tue.nl/hashclash/rogue-ca/
[23] Security/DNSSEC-TLS-details. In: [online]. [cit. 2014-07-13]. Available from:
https://wiki.mozilla.org/Security/DNSSEC-TLS-details
[24] Calomel SSL Validation: a Firefox Add-on extension grading SSL strength. In: Calomel.org [online]. 10.05.2014 [cit. 2014-07-13]. Available from:
https://calomel.org/firefox_ssl_validation.html