Weak Keys Remain Widespread in Network Devices
Total Page：16
File Type：pdf, Size：1020Kb
Weak Keys Remain Widespread in Network Devices Marcella Hastings Joshua Fried Nadia Heninger University of Pennsylvania University of Pennsylvania University of Pennsylvania [email protected] [email protected] [email protected] ABSTRACT Wustrow, and Halderman [21] announced that they had In 2012, two academic groups reported having com- factored tens of thousands of public RSA keys from TLS puted the RSA private keys for 0.5% of HTTPS hosts on certificates. The latter group traced the vulnerability the internet, and traced the underlying issue to widespread to widespread failures in random number generators on random number generation failures on networked de- headless, embedded, and low-resource network devices. vices. The vulnerability was reported to dozens of ven- While this vulnerability revealed the private keys for dors, several of whom responded with security advi- 0.5% of HTTPS hosts on the internet at the time, the sories, and the Linux kernel was patched to fix a boot- immediate security impact on those particular hosts time entropy hole that contributed to the failures. was likely limited by the fact that the vast majority of In this paper, we measure the actions taken by ven- compromised TLS certificates were not browser trusted, dors and end users over time in response to the origi- and were automatically-generated certificates protect- nal disclosure. We analyzed public internet-wide TLS ing web login interfaces on consumer and small-business scans performed between July 2010 and May 2016 and grade routers and firewalls, remote server administra- extracted 81 million distinct RSA keys. We then com- tion interfaces, and embedded device such as cooling puted the pairwise common divisors for the entire set systems, building monitors, cameras, projectors, and in order to factor over 313,000 keys vulnerable to the printers. Rather, the presence of weak keys was an ex- flaw, and fingerprinted implementations to study patch- ternally visible signal that the random number genera- ing behavior over time across vendors. We find that tion subsystems on entire classes of devices and across many vendors appear to have never produced a patch, multiple implementations had failed, likely impacting and observed little to no patching behavior by end users these systems and many other hosts in a variety of ways. of affected devices. The number of vulnerable hosts in- In this paper, we study the disclosure process under- creased in the years after notification and public dis- taken by the authors of [21] and the aftermath of this closure, and several newly vulnerable implementations family of random number generation failures. We ag- have appeared since 2012. Vendor notification, positive gregated publicly available internet-wide TLS scan data vendor responses, and even vendor-produced public se- dating back almost six years, including monthly scans curity advisories appear to have little correlation with during the past four years from multiple sources. We end-user security. give more details on our data sources in Section 3.1. In order to measure the incidence of vulnerable keys, we Keywords extracted the 81 million distinct RSA moduli found in these scans and ran a batch GCD algorithm to factor Security vulnerabilities; networked devices improperly generated RSA keys. We were able to factor over 313,000 moduli. (See Table 1.) To carry out such 1. INTRODUCTION a large computation efficiently for such a large number In February of 2012, Lenstra, Hughes, Augier, Bos, of keys, we modified the algorithm to run in parallel Kleinjung, and Wachter [26] and Heninger, Durumeric, across a distributed cluster. We describe our computa- Permission to make digital or hard copies of all or part of this work for personal tion in detail in Section 3.2. We then manually finger- or classroom use is granted without fee provided that copies are not made or printed vulnerable implementations based on available distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work metadata, including certificate subjects, certificate sub- owned by others than the author(s) must be honored. Abstracting with credit is ject alternative names, port scans, and known private permitted. To copy otherwise, or republish, to post on servers or to redistribute to key behavior, as described in Section 3.3, and examine lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. vulnerability rates over time for user populations asso- IMC ’16, November 14–16, Santa Monica, CA, USA. ciated with identified vendors in Section 4. c 2016 Copyright held by the owner/author(s). Publication rights licensed to Previous studies of vulnerability patching have fo- ACM. ISBN 978-1-4503-4526-2/16/11. $15.00 cused on patching behavior from system administra- DOI: http://dx:doi:org/10:1145/2987443:2987486 tors in response to highly publicized vulnerabilities in HTTPS host records 1,526,222,329 OpenSSL [39, 15] or in response to targeted vulnera- Distinct HTTPS certificates 65,285,795 bility notifications [27, 33]. In contrast, the vulnerabil- Distinct HTTPS moduli 50,677,278 ity disclosures undertaken by the authors of [21] were targeted mainly at vendors of embedded and headless Total distinct RSA moduli 81,228,736 devices, which are rarely updated by end users. Vulnerable RSA moduli 313,330 The widespread nature of the flaw provides us with Vulnerable HTTPS host records 2,964,447 an accidental historical experiment allowing us to study Vulnerable HTTPS certificates 1,441,437 the industry's response to disclosure by comparing re- sponses across many vendors. We describe in detail for Table 1: We analyzed six years of internet-wide HTTPS the first time the results from the industry-wide dis- scans in order to study server behavior over time. Each closure process undertaken by the authors of [21]. In host record represents a HTTPS handshake on a given particular, fewer than half of the organizations con- date with a server at some IP address. We augmented tacted about the vulnerabilities responded at all to a our batch GCD computation with RSA public keys ex- best-effort attempt at vulnerability notification. tracted from IMAPS, POP3S, SMTPS, and SSH scans, We also give data on the post-notification internet- but excluded these other protocols from further study. wide vulnerability rates for different vendors in response to the same vulnerability. Many vendors apparently continued to ship vulnerable products for years after client and server negotiate a cipher suite that includes receiving notification of and even acknowledging the se- RSA key exchange, the client uses the server's public curity vulnerability, and in some cases after putting out key to encrypt session key information; when they ne- security advisories for their products. Since the targets gotiate a Diffie-Hellman or elliptic-curve Diffie-Hellman of our study are primarily devices, rather than software cipher suite, the server uses its RSA public key to sign packages, end users must rely on vendors to distribute its key exchange message to prove authenticity. RSA updates in order to patch their own devices. We ob- digital signatures are used to authenticate TLS certifi- serve that for this vulnerability, end-user patching did cates; a certificate may be signed by a trusted certificate not appear to occur at all. authority's public key or by a certificate chaining up to The single largest drop in the number of vulnera- a trusted root key, or self-signed by its own public key. ble keys occurred shortly after the disclosure of the A compromised public key from a TLS certificate Heartbleed vulnerability in April 2014. The decrease could be used to passively decrypt TLS sessions that in vulnerable keys is confined to a handful of devices, had negotiated RSA key exchange. An active attacker for which there was an even larger concurrent drop in could use a compromised certificate key to impersonate the total population of fingerprinted devices, suggest- a trusted server whose certificate used that key, or to ing that while in some cases the publicity may have perform a man-in-the-middle attack to decrypt or mod- prompted device users to regenerate certificates or ap- ify traffic using Diffie-Hellman or RSA cipher suites. ply a patch that also fixed the weak key vulnerability, 74% of the 61,240 vulnerable devices present in our most many device HTTPS interfaces may instead have simply recent scan data from April 2016 only support RSA key been taken offline. In the case of at least one device fam- exchange, making them vulnerable to passive decryp- ily, Heartbleed vulnerability scans were reported to ren- tion by an attacker who is able to observe network traf- der the device non-responsive. This suggests that end- fic. In order for an attacker to intercept network traffic, user device security can improve when vendors patch they would need to be on the network path between the vulnerabilities and end users are encouraged to apply victim client and the true server, or use a network at- patches or change configuration by widespread media tack like DNS or BGP hijacking [8] to force the victim attention and targeted vulnerability notifications, but to connect to the server via the client. that this process did not occur in response to the vul- Among the vulnerable devices that we examined, HTTPS nerabilities we study in this paper. is used primarily to serve remote management inter- faces. Many of the vulnerable firewalls also use TLS to encrypt SSL VPN connections. An attacker who is 2. BACKGROUND able to decrypt connections to one of these devices may obtain administrative credentials for the device or view 2.1 TLS security remote user traffic to internal network resources.