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 responses 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 interfaces. 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. In this paper, we focus on RSA as used in the Trans- port Layer Security (TLS) protocol, which is used for 2.2 RSA and factoring HTTPS. Several studies have examined the HTTPS [16], RSA [31] is the most commonly used public-key cryp- email [14], and other TLS application infrastructures [22]. tosystem on the internet. RSA keys can be used both In the TLS protocol, a server’s RSA public keys are in- for encryption and digital signatures. An RSA pub- cluded in a server’s certificate, which is transmitted to lic key consists of a modulus N, which is the product the client in response to a client hello message. When of two large primes p and q, and a public exponent e. Public Advisory Private Response Auto-Response No Response IBM Cisco Pogoplug Brocade ZyXEL Emerson McAfee Innominate Sentry HP NTI TP-Link Fortinet Dell Intel Technicolor Hillstone Networks Haivision 2-Wire Sinetica D-Link Juniper AudioCodes Motorola Xerox SkyStream Pronto Tropos Ruckus Kronos Kyocera BelAir Simton Linksys AVM JDSU MRV

Table 2: 37 vendors were notiﬁed via email in February and March 2012 about weak TLS or SSH RSA key generation in their products. Only ﬁve released a public security advisory. About half of the vendors acknowledged receipt.

The corresponding RSA private key is a private expo- 2.4 The random number generation flaw nent d = e−1 mod (p 1)(q 1), which is efficient to − − The implementation flaws resulting in these weak keys compute if the prime factorization of N is known. If appear to have arisen independently in many different the prime factorization of N is not known, the most implementations, but [21] points to a common pattern: efficient method known in general to compute an RSA on many headless, embedded, or low-resource devices, private key is to factor the modulus N into its prime the operating system random number generator may factors and use the factors to calculate d. not have incorporated any external sources of entropy The most efficient general-purpose factoring algorithm when it is used by an application to generate a crypto- is the number field sieve, which has asymptotic com- graphic key. If the key-generation process incorporates 1/3 2/3 plexity exp((1.923 + o(1))(log N) (log log N) ) [25]. additional low-entropy sources of randomness during Factoring a 512-bit RSA key using the number field key generation—for example the current time or arriv- sieve is within the range of attackers of even modest ing network packets—applications running on different resources today [37]; the current public factorization systems may have identical states during the generation record is a 768-bit RSA modulus factored by an aca- of the first prime factor of the RSA modulus, and di- demic team over several years, announced in 2009 [24], verge during the generation of the second prime factor, and 1024-bit factorization is believed to be within the resulting in the exact situation described above. range of governments. The authors of [21] discovered a boot-time “entropy 2.3 Factoring weak RSA keys hole” vulnerability in the Linux random number generator, where the output of /dev/urandom could be de- Implementation flaws can allow an attacker to break terministic on boot in real usage, and noted that in this RSA much more efficiently. The family of implementa- situation OpenSSL’s key generation behavior could re- tion flaws we study in this paper results in the genera- sult in factorable keys. This combination was visible on tion of RSA moduli that share a single common prime many but not all of the affected product families. factor. In that case, one might have two RSA moduli The vulnerable factored keys were almost exclusively N1 = pq1 and N2 = pq2 that share the prime factor p confined to network devices, rather than general pur- but have different second factors q1 and q2. The two pose web servers. Only a handful of the vulnerable moduli will appear distinct, but an attacker who can HTTPS certificates were signed by a browser-trusted find such a pair can easily factor both of them by com- CA. While most of the vulnerable hosts were likely low- puting p = gcd(N1,N2) and dividing to discover q1 and value targets, their weak keys are an externally visible q2. These two operations can be performed in less than sign of the underlying flaw in the operating system, with one second on a standard modern laptop. broader security implications for any service on the sys- The authors of [26] and [21] discovered such flaws tem requiring randomness. This type of flaw is difficult were widespread by collecting several million RSA pub- to detect in a standard unit test framework, making it lic keys from publicly available datasets, including HTTPS difficult for vendors to discover and mitigate in normal certificate scans, PGP key servers, and SSH host scans, software development practices. and computing the pairwise common divisors of every pair of RSA moduli in the datasets. (See Section 3.2.) 2.5 Responsible disclosure Since these original publications, the same technique has been used to find further vulnerable implementa- The authors of [21] notified 61 vendors of the vul- tions: Bernstein et al. [6] found a random number gen- nerability between February and June 2012. Of these, eration flaw in the Taiwanese national smart card infras- 37 concerned vulnerable RSA keys, and the remainder tructure, and Albrecht, Papini, Paterson, and Villanueva- produced vulnerable DSA signatures only. Since our Polanco [3] found a large number of weak keys among main dataset consists only of RSA keys, we exclude the export-grade RSA keys for TLS. DSA vulnerabilities from further analysis. Among the RSA vulnerabilities, 28 vendor devices produced vulnerable TLS certificates, and the rest produced vulnerable 7/2010 (EFF) 4/2016 (Censys) EFF P&Q Ecosystem Rapid7Censys 40M TLS Handshakes 11,261,212 38,014,832 Distinct Certificates 5,479,537 10,670,210 30M Distinct RSA Keys 5,333,832 10,457,597 20M 10M Table 3: Our dataset includes nearly six years of scans; Total Hosts we summarize the earliest and latest above. 0M 80K 60K RSA SSH host keys. A complete list of affected vendors 40K was never published. The authors first attempted to 20K contact each vendor individually via email. They were Vulnerable able to find a security contact, either an email address 0K or web form, for 13 vendors by searching company web sites, and in two cases via personal connections. For the 07/201012/201010/201106/2012 02/2014 07/201505/2016 rest, they attempted to email [email protected] and [email protected]. Later, CERT/CC and ICS- Figure 1: We aggregated HTTPS scan data from several CERT aided in contacting and coordination between sources. The total number of hosts in each scan is shown companies. Table 2 lists the vendors who were notified above, and the number of hosts serving keys we were about weak RSA keys and their responses. able to factor below. In addition, the authors of [21] notified the main- tainers for the Linux kernel, who published a patch in July 2012 including several mitigations against the failures [35]. In July 2014, Linux introduced the getran- the HTTPS ecosystem [16] in June 2012 and contin- dom() system call, which outputs nonblocking data only ued through January 2014; we refer to this dataset as after it has been properly seeded. This is the desirable “Ecosystem”. These scans used the much faster Zmap functionality for cryptographically secure random num- [17] port scanner and a custom certificate fetcher, and ber generation. [36] the authors report that a single scan took 18 hours on average to complete. The scans vary in frequency from one to over 20 scans per month. Beginning in 3. METHODOLOGY October 2013, Rapid7’s Project Sonar [30] took weekly In order to examine vulnerability rates over time, scans over IPv4 space, also using the Zmap port scanner we collected historical HTTPS scan data, extracted the with their own custom client implementation to collect RSA public keys from server certificates, and performed HTTPS certificates. We use their HTTPS data through a massive batch GCD computation across all of the dis- May 2015. Finally, Durumeric, Adrian, Mirian, Bailey, tinct RSA keys ever seen in our scans. We fingerprinted and Halderman [13] have performed daily scans from certificates to identify the server implementation. July 2015 through April 2016, made available through the Censys search engine, using Zmap and an integrated 3.1 Data sources toolchain to collect TLS handshake data on port 443. While weak keys have been found across many public- The Censys team also performs regular scans of IMAPS, key infrastructures, we chose to focus on HTTPS data, POP3S, and SMTPS using TLS and SSLv2; we ex- as previous and ongoing measurement studies have pro- tracted the RSA moduli for these datasets for use in our vided a historical record to draw from. batch GCD calculation, but did not include the certifi- The earliest internet-wide HTTPS scans we are aware cates or host records in the rest of our results. We also of are the EFF SSL Observatory [18], collected by Burns included Censys SSH host key data. and Eckersley in July 2010 and December 2010. These In total, our dataset includes 1.5 billion host records, two scans were performed over the course of two to three representing an IP address and certificate pair on a months each, using Nmap [28] to scan for hosts with given date, and 131 million unique certificates. There port 443 open and a custom Python client to send a are 81.2 million RSA moduli, of which 313,330, or 0.37% client hello and collect a server’s certificate. We refer were factored using the methods described in the follow- to this dataset as “EFF”. ing section. The data is hosted in a MySQL database on Heninger, Durumeric, Wustrow, and Halderman [21] a machine with a fast 6TB SSD cache layer and 28TB performed an internet-wide HTTPS scan over five days of RAIDed HDDs for backup storage of the scan data. in October 2011, first using Nmap to scan hosts with Figure 1 illustrates the number of hosts seen over open TCP port 443, and using a custom Python client time on port 443 and the number of hosts on port 443 to collect certificates over the course of several days. whose public keys we were able to factor. Artifacts from We refer to this dataset as “P&Q”. Durumeric, Kasten, the different scan methodologies used by each team are Bailey, and Halderman began taking regular scans of clearly visible. Although most of these sources provided N N N N plications.) Then it uses a remainder tree to compute 1 2 3 4 2 zi = P mod Ni for every Ni. Finally, for each Ni, it N1N2 N3N4 outputs gcd(Ni, zi/Ni). If this value is not 1, then Ni shares some common factor with at least one other mod- N1N2N3N4 ulus in the database. Scaling this calculation to the 81 million moduli posed 2 2 mod(N1N2) mod(N3N4) some computational challenges. First, the code as written was limited to running on a single shared-memory 2 2 2 2 mod(N1) mod(N2) mod(N3) mod(N4) system, and used threads to run arithmetic operations in parallel at each level of the tree. Second, the imple- /N1 /N2 /N3 /N4 mentation uses GMP [20] for bignum arithmetic operations, which are single threaded. This resulted in a gcd( ,N ) gcd( ,N ) gcd( ,N ) gcd( ,N ) · 1 · 2 · 3 · 4 bottleneck at the central node in the middle of the tree, the product of all 81 million RSA moduli. Figure 2: To parallelize the batch GCD computation To solve both of these problems, we made several over a cluster, we divide the input into k subsets and adaptations to the batch GCD algorithm that raise the compute a product only over each subset. For each asymptotic complexity of the calculation but allow a subset, we compute the remainder tree with respect to speedup in practice. The modified algorithm works Q all subset products. The total amount of computation is as follows. Instead of computing the product Ni of higher, but we achieve a speedup in practice by avoiding N1...Nn moduli, we divide the moduli into k subsets the bottleneck of computing with respect to the very and compute the product P1,...,Pk for each subset. { } large products in the center of the tree. We then compute a remainder tree for each product with respect to each subset. Since we pair every product with every subset, we are guaranteed to have cov- more frequent scans, we chose one representative scan erage of all possible pairs of moduli. This part of the per month over the time period we examined. In all computation scales quadratically in the number of sub- figures, each point represents a single scan. sets k. For each modulus Ni, this yields k expressions 2 2 2 We also found that the Rapid7 data included sets P1 mod Ni ,P2 mod Ni ,...,Pk mod Ni . The algo- of intermediate certificates without explicitly chaining {rithm then completes the final step as before,} reporting them, while the other scan data either excluded the is- a modulus Ni as vulnerable if any of the subproducts suer certificates or explicitly chained them. In order to returned nontrivial common divisors. better correlate our results across datasets, we excluded This modification allowed us to parallelize the compu- these intermediate certificates from our analysis by re- tation across a cluster. We ran the computation across a constructing the chains using common names among all cluster of six machines with dual 18-core 2.30GHz Intel certificates associated with each IP address and includ- Xeon E5-2699 v3 processors and 128GB of RAM each, ing only the lowest certificate in the chain. eight machines with dual 22-core 2.20GHz Intel Xeon E5-2699 v4 processors and 512GB of RAM each, and 3.2 Batch GCD eight machines with dual 12-core 2.50GHz Intel Xeon In order to compute pairwise GCDs across all col- E5-2680 v3 processors and 512GB of RAM each. We lected moduli, we adapted the batch GCD implemen- were additionally able to speed up the computation by tation described in [21] 1. This code was originally re- storing the entirety of the product and remainder trees ported to perform the batch GCD computation on a in RAM, where the original hardware used for the com- set of 11.1 million RSA moduli in 1.6 hours on a 16- putation had limited memory, requiring that the trees core Amazon cloud cluster compute instance with 60.5 be written to disk. GB of RAM. The batch GCD algorithm is fundamen- For the 81 million RSA keys in our database, we chose tal to the feasibility of our study: it runs in quasilinear k = 16. The entire computation took 86 minutes of time over the number of input moduli, while a naive wall-clock time to finish on our cluster, representing implementation that simply computes the GCD of all 1089 CPU hours. The product and remainder trees re- pairs of moduli runs in quadratic time in the number of quired between 70 and 100 GB of storage on each node. moduli. The computation time required by the latter is In contrast, running the original algorithm without not feasible for the dataset sizes used in this paper. modifications entirely in memory on a machine with The algorithm, which is adapted from an algorithm quad 6-core 3.40GHz Intel Xeon E7-8893 processors with described by Bernstein [5], has two main phases. First, 3 TB RAM took 500 minutes and required over 500 GB it uses a product tree to compute the product of all of memory to store the product and remainder trees. Q input moduli P = Ni. (A product tree computes 3.3 Fingerprinting Implementations the product of its inputs using a binary tree of multi- Once we had identified the weak RSA keys in our 1Available publicly on https://factorable.net. database, we linked them to the set of certificates con- HTTPS SSH POP3S IMAPS SMTPS Date scanned 04/11/2016 10/29/2015 04/25/2016 04/25/2016 04/25/2016 Total hosts with public keys 38,014,832 10,730,527 4,533,094 4,544,158 3,292,031 Hosts with RSA keys 37,931,417 6,257,106 4,533,094 4,544,158 3,292,031 Vulnerable hosts 59,628 723 0 0 0

Table 4: We included datasets of RSA public keys on different protocols into our batch GCD computation, but found that the majority of vulnerable keys were associated with HTTPS. We excluded these other protocols from further analysis. The scan data above is from the Censys project. taining these moduli and attempted to identify the un- stances which we discuss below, this heuristic uniquely derlying implementations using available information. labeled certificates. In a special case, a bug in the prime-generation code 3.3.1 Certificate subject fingerprints of certain IBM Remote Server Administration cards and For many implementations, the certificate subjects BladeServer Management Modules led to only nine pos- clearly identified a device manufacturer and model. We sible primes being generated. Every public key associ- identified the majority of host records using certificate ated with these devices was the product of two of these subjects. We observed that for vulnerable implementa- primes. [21]. Most of these certificates did not contain tions end users typically did not alter the default certifi- information identifying IBM. We identified 3,229 certificate values provided by the device, so it was straight- cates using an IBM prime, and labeled them all IBM. forward to map from distinguished name to vendor. In examining the IBM data, we found an overlap For example, the Hewlett-Packard, Xerox, TP-LINK, between a modulus in the vulnerable IBM clique and and Conel s.r.o. devices generating weak keys in our devices identified as Siemens Building Automation, an dataset all generate certificates containing “O=vendor” interface for building-wide operations such as alarms, in the distinguished name. We also used the distin- time schedules, and HVAC systems. The Siemens-identified guished name to directly identify models. Cisco certifi- modulus began appearing in February 2013 and con- cates in particular used the organizational unit section tinued to appear in scans throughout the study. This of the distinguished name to refer to the model of the affected 2,441 certificates. There were 18 vulnerable device. There were 5,274,287 certificates that identified certificates identified as Siemens that did not use an a vendor in this fashion. IBM modulus. There were about 15,000 total Siemens In other cases, sets of certificates had consistent dis- certificates, which we identified using certificate subject tinguished or common names, but did not name a ven- information. dor. In some cases, the content being served via HTTPS We used extrapolation via shared prime factors to la- for a host of interest was a login or informational page bel certificates associated with Fritz!Box DSL modems. identifying the vendor and model of the device. For ex- Many Fritz!Box certificates had a common name with ample, McAfee’s SnapGear 300 certificate distinguished some subdomain of myfritz.net. Others filled in the name had fields“CN=Default Common Name, O=Default alternative name with identifiable domain names: Organization, OU=Default Unit. . . ”, etc. The content DNS:fritz.fonwlan.box, DNS:fritz.box, served over HTTPS for these hosts was the home page DNS:www.fritz.box, DNS:myfritz.box, for a SnapGear Management Console. Similarly, ev- DNS:www.myfritz.box. These were easy to identify. ery Juniper certificate contained the field “CN=system However, there were tens of thousands of certificates generated”. We labeled 26,272,330 certificates from 18 whose certificate subject identified only an IP address vendors using this heuristic. in octets. We labeled these as Fritz!Box if they shared a common prime factor with certificates fingerprinted via 3.3.2 Fingerprinting prime behavior certificate data or Nmap host identification. We were able to label 20,717 certificates as Fritz!Box using these We found that in the vast majority of cases, devices heuristics. sharing prime factors were identified as the same ven- We also found an overlap in shared primes between dor. We used this information to extrapolate vendors Xerox and Dell certificates. On closer examination, we for some certificates we could not otherwise identify. found that a set of machines with a certificate subject We used a heuristic to identify shared prime factors. containing “OU=Dell Imaging Group” all shared primes For a vendor with clearly identifiable certificates, we with Xerox devices. In 2004, Dell announced a partner- created a pool of all prime factors generated by the ven- ship with Fuji Xerox, which specializes in imaging tech- dor. We then examined our set of moduli and set aside nologies [23]. Later, reviews of Dell printers claim they all moduli produced using a prime from the pool. Any are manufactured by Xerox [11]. This overlap affected certificate containing one of these moduli, we labeled 416 certificates. as the original vendor. Excepting a few special circum- 3.3.3 Internet Rimon Man-in-the-Middle Satisfy OpenSSL fingerprint Do not satisfy In attempting to identify shared implementations via 2Wire IBM DrayTek shared cryptographic keys, we discovered that an Is- AdTran Innominate Fortinet raeli ISP, Internet Rimon, was substituting its own RSA Allegro Linksys Huawei modulus into the self-signed certificates being served by BridgeWave McAfee Juniper the internet-facing services on devices belonging to its Cisco MitraStar Kronos customers. Only the public key and the signature (as Conel s.r.o. Netgear Siemens well as the choice of hash function used in the signa- D-Link NTI Xerox ture) were changed; the rest of the certificate remained Dell Sangfor ZyXEL unchanged. Internet Rimon offers an opt-in content fil- Fritz!Box Schmid Telecom tering service for its customers via installation of a root HP ServerTech certificate on the customer’s machine, but this is the TP-LINK SkyStream Networks first case we have seen of an ISP man-in-the-middling Thomson inbound encrypted connections to its customers’ devices by substituting their public keys for a fixed key of its Table 5: OpenSSL uses a distinctive prime generation own. We saw 922 distinct IP addresses with this key, process that allows us to use the primes in a private appearing in scans throughout the entire study period. RSA key to distinguish vendors who are likely using We did not factor the 1024-bit RSA modulus used by OpenSSL to generate keys from those that are not. We Internet Rimon. classified device vendors from our TLS scan data. 3.3.4 Fingerprinting OpenSSL primes Mironov [29] observes that OpenSSL uses a distinc- database are not the product of two equal-sized primes, tive method of prime generation that eliminates primes that is, they are not well-formed RSA moduli. These p such that p 1 is divisible by any of the first 2048 corresponded to 113 certificates in our database. In primes. He estimates− that the probability that a ran- many cases, this appeared to be due to bit errors. For domly chosen 512-bit prime satisfies this property is example, we found 11 different “certificate authority” about 7.5%. This property would also be satisfied if an certificates in our database with non-well-formed RSA implementation only generated “safe” primes (a prime keys that were at least one bit error from a nearly iden- p where (p 1)/2 is also prime). We found that none tical valid certificate. (In the case of the certificates of our labeled− vulnerable vendors produced exclusively with errors, the signatures of course will fail to verify.) safe primes, although they do arise in the dataset by One or more bit flips in a valid RSA modulus would chance. We did not find any vulnerable implementa- be expected to produce a random integer; this integer tions producing exclusively safe primes, suggesting that would be divisible by some prime qi with probability the property is a true OpenSSL fingerprint. 1/qi. Thus such bit errors are likely to show up in the re- We can use this property to identify implementations sults of our batch GCD computations with divisors that as likely OpenSSL and definitely not OpenSSL by exam- are the product of many small prime factors. Anecdo- ining the fraction of prime factors of weak keys that sat- tally, such errors have been observed to appear in other isfy this property. If an implementation uses OpenSSL large key corpuses such as the PGP keyservers. [7] We set these cases aside and did not treat them as to generate primes, every prime factor pi for every modulus associated with this implementation should satisfy indicators of a flawed implementation, since they could have resulted from memory errors on the host, errors pi = 1 mod qi for each of the 2048 primes checked by OpenSSL.6 If an implementation is not OpenSSL, we on the wire, or errors during storage or download of would expect that only a small fraction of the prime the datasets. A small portion of these certificates were factors associated with this implementation would sat- presented multiple times by the same hosts across scans. isfy this property. Most, however, were seen exactly once, indicating some We found that 71,417 of the certificates with weak error with the transmission or storage of the key. keys were not OpenSSL, about 5% of all certificates with broken moduli. Table 5 categorizes vendors according 4. RESULTS to this OpenSSL fingerprint. Because the fingerprint In this section, we examine the behavior of vendor requires the private key, it only covers models gener- devices based on the company response to the vulnera- ating vulnerable keys. For vendors like Juniper where bility disclosures by the authors of [21]. we cannot distinguish different product models, we can only state that there exists a non-OpenSSL implemen- 4.1 Vendors that released a public disclo- tation generating weak keys. sure Five companies released public security advisories for 3.3.5 Bit errors TLS vulnerabilities2. 107 (0.03%) of the 313,330 vulnerable moduli in our 2https://factorable.net/advisories.html EFF P&Q Ecosystem Rapid7 Censys EFF P&Q Ecosystem Rapid7 Censys 600 80K Total 60K 400 Heartbleed Total Hosts Hosts 40K Vulnerable 200 20K Vulnerable 0K 0

07-201012-201010-201106-2012 02-2014 07-201505-2016 07-201012-201010-201106-2012 02-2014 07-201505-2016

Figure 3: The number of vulnerable Juniper hosts con- Figure 4: The number of broken Innominate mGuard tinued to rise for years after Juniper’s published security hosts increased from the original 2012 notification and advisories and public disclosure. The single largest drop has stayed mostly consistent during the four years since in the number of both vulnerable and total number of the public security advisory. fingerprinted hosts occurred during April 2014, which correlates with the disclosure of Heartbleed, marked with a vertical line. “Heartbleed” issue on April 23, 2014 [1]. The security advisory states that the SRX branch devices identified as generating vulnerable keys were not vulnerable to Juniper, whose products represented the majority of Heartbleed. factored keys in 2012 and the second highest number During the aftermath of Heartbleed, nearly 30,000 over all scans, released a public Security Bulletin in Juniper-fingerprinted hosts went offline entirely, includ- April 2012 and an Out-of-Cycle Security Notice in July ing over 9,000 vulnerable devices. This suggests that de- 2012 announcing that the weak key vulnerability had vice owners disabled TLS on port 443, blocked external been internally discovered and fixed. The exact de- scans, or took devices offline in response to Heartbleed. vice model is not apparent from the certificate data Anecdotal reports suggest that Juniper NetScreen fire- or the HTTPS login page, but Juniper has identified walls crashed when scanned for Heartbleed [38]. the vulnerable models as SRX branch security devices. Innominate, now Phoenix Contact Cyber Security, Juniper certificates do not identify device models, and manufactures security appliances for industry settings. the default certificate matching our fingerprint can be In June 2012, they released a security advisory about generated by different Juniper models. We generated a weak keys in mGuard network security devices. Since certificate on a Juniper SSG5 security platform running the notification and advisory, the number of vulnera- ScreenOS that has the same fingerprint as the Juniper ble mGuard hosts has remained roughly fixed. Out of certificates in our scan. 561 IP addresses that ever served vulnerable Innomi- Our data shows that that the number of vulnera- nate certificates, two hosts served non-vulnerable In- ble hosts continued to increase for two years follow- nominate certificates and transitioned to a vulnerable ing disclosure, and end-user patching was minimal at public key in subsequent scans, three served vulnera- best. (Figure 3.) In order to better understand patch- ble certificates and transitioned to non-vulnerable cer- ing behavior, we examined the vulnerability status of tificates in subsequent scans, and one host transitioned fingerprinted Juniper hosts in more detail. Over the from non-vulnerable to vulnerable and back again. Over entire course of our scan data, we observed 169,000 IP the time period covered by our scan data, the total num- addresses serving a fingerprinted Juniper certificate, of ber of Innominate-fingerprinted devices has risen (Fig- which 34,000 hosts served vulnerable keys. Of these, ure 4), suggesting that the vulnerability has been fixed 1,100 hosts transitioned from a certificate containing a in newer devices, but the population of originally vul- vulnerable key to a certificate containing a non-vulnerable nerable devices continue to serve vulnerable certificates. key, 1,200 transitioned from a certificate containing a IBM BladeCenter Management Module and Remote non-vulnerable key to a certificate containing a vulner- Supervisor Adapter II cards generated only 36 possible able key, and 250 transitioned between vulnerable and public keys from 9 possible prime factors, as described non-vulnerable certificates multiple times. in Section 3.3. 99.5% of the certificates we were able to There is an abrupt decrease in the number of finger- identify as one of these IBM products contained these printed Juniper hosts, both total and those generating moduli. IBM published a security advisory (CVE-2012- weak keys, between April 2014 and May 2014. Juniper 2187) in September 2012. Nearly all certificates con- released four security advisories in April 2014 for vari- tained non-fingerprintable identifying information from ous vulnerabilities, including a patch for the OpenSSL the organizations themselves, although we found 51 cer- EFF P&Q Ecosystem Rapid7 Censys EFF P&Q Ecosystem Rapid7 Censys 200K 600 400 100K Hosts 200 Heartbleed Total Hosts 0K 10K 0 8K 6K 4K 07-201012-201010-201106-2012 02-2014 07-201505-2016 2K Vulnerable 0K Figure 5: We fingerprinted IBM Remote Supervisor Adapter II and BladeCenter Management Modules us- 07/201012/201010/201106/2012 02/2014 07/201505/2016 ing the 36 possible public keys that could be generated by these implementations. The vulnerable population Figure 6: The number of broken Cisco hosts (bottom) appears to have been decreasing already by 2012, and increased steadily through 2014, although it has begun shows a marked decrease at the time of the Heartbleed to decrease in the past year. vulnerability in April 2014.

curity advisory and do not appear to have patched the tificates labeled as Remote Supervisor Adaptors. For vulnerability for several years, as the number of vulner- this reason, we do not have an estimate of the total able hosts continued to increase for the next three years. population for these devices. Figure 5 shows the num- (Figure 6.) ber of vulnerable hosts over time; the vulnerable pop- The detailed model information in Cisco certificates ulation appears to have already been decreasing at the allows us to study the effect of end-of-life announce- time of disclosure in 2012, and drops sharply in April ments on device populations in the wild. Of the 14 2014, corresponding to the Heartbleed disclsosure. vulnerable models we labeled, 10 have released an end- Examining certificate lifetimes and replacement on of-life announcement with a final sale date before May each host suggests that the vulnerable population of 6, 2016. We found that the end-of-life announcements IBM devices was decreasing because devices (or their marked the beginning of a slow decrease in the total publicly accessible web interfaces) were taken offline al- number of devices online. We also note that the end- together, and not because users patched the vulnerabil- of-life announcement typically preceded the end-of-sale ity and renewed their HTTPS certificates on the same date by several months. (Figure 7.) device with a non-vulnerable public key. Among the HP’s Integrated Lights Out out-of-band management 1,728 IP addresses that ever served a certificate con- cards generated weak keys. The number of vulnerable taining one of the vulnerable IBM primes in any of hosts appears to have peaked in 2012, and has been our scans, 350 served a certificate during any of the decreasing steadily since, as shown in Figure 8. There is scans that did not contain a vulnerable public key. The a notable drop in the number of vulnerable hosts as well varying subjects of these new certificates indicated that as the total number of HP hosts in the months after the these new certificates were due to IP churn. Heartbleed disclosure in April 2014. HP iLO cards were Intel and Tropos released public vulnerability disclo- reported to crash when scanned for Heartbleed [38]. sures in the aftermath of [21], but these vulnerabili- The population of other vendors’ devices in this cat- ties concerned vulnerable SSH host keys on port 22, for egory was too small to draw conclusions from. which we do not have comprehensive data. Moxa also 4.3 Vendors that never responded released a public disclosure for a vulnerability in DSA signatures, which we do not address in this study. Figure 9 illustrates the fingerprinted populations and number of vulnerable hosts for ten vendors who did 4.2 Vendors that responded privately not respond to the vulnerability notification. In most cases, the population of vulnerable hosts is declining Several companies responded substantively to the vul- gradually, outside of apparent differences due to differ- nerability notification but did not release a public an- ent scanning methodology across our datasets. Four of nouncement. these vendors (Thomson, Linksys, ZyXEL, and McAfee) Multiple lines of Cisco small business products gen- show a decline in the vulnerable population that closely erated weak keys. As mentioned in Section 3.3, most tracks the decline in the overall number of hosts with Cisco certificates clearly identified full model names in that device fingerprint. Fritz!Box shows a marked in- the certificate distinguished name, so we were able to la- crease in the vulnerable population before an eventual bel 81% of certificates (and 91.5% of broken certificates) decline, suggesting that the vulnerability may have been with a model. Although Cisco responded in private to fixed for new devices at some point in 2014. the vulnerability notice, they never released a public se- End of Life Date EFF P&Q Ecosystem Rapid7 Censys

RV082 100K 50K Heartbleed

RV120W Total Hosts 0K

RV220W 30 20 10

RV180/180W Vulnerable 0

SA520/540 07/201012/201010/201106/2012 02/2014 07/201505/2016

Figure 8: HP iLO out-of-band management cards re- Figure 7: We found that Cisco’s end-of-life announce- portedly crashed when scanned for the Heartbleed vul- ments for their most popular small business routers gen- nerability. There is a noticeable decrease in the total erally mark the start of a gradual decline in the de- population of HP products in the months following the vice population. We identified vulnerable hosts associ- Heartbleed disclosure. ated with all the device models in this figure except the RV082. ceive a response to our notification. Schmid Telecom is a multinational company, but all their vulnerable cer- 4.4 Newly vulnerable products since 2012 tificates identify an Indian subsidiary. Several companies had no or very few vulnerable devices in 2012, but appear to have since released prod- 5. DISCUSSION ucts with the random number generation vulnerability. Our data, viewed as a collection of individual anec- These newly vulnerable hosts are responsible for the ris- dotes on vendor responses to a security vulnerability, ing number of vulnerable hosts visible over the past year illustrate the challenges faced by all parties in the vul- in Figure 1. nerability disclosure and mitigation process. From the The first vulnerable Huawei hosts appeared April 2015, perspective of the reporting party, the disclosure re- and the population has increased dramatically (Figure ceived no substantive response and no acknowledgement 10). An examination of their certificates did not reveal of a deployed fix for years for most vendors who were a specific model. However, the certificates all identify contacted. While the decline of the vulnerable popula- a business unit in India, while 84% of the total pop- tion for many of these vendors suggests that their newer ulation of Huawei certificates matching our fingerprint product versions are no longer naively vulnerable, this identify India. We contacted Huawei via their vulnera- decline took years to become visible in the data. From bility reporting web page in May 2016. They responded the vendor side, the recent introduction of several newly to our notification and released a security advisory and vulnerable products illustrates how difficult it can be to software update in August 2016. keep old bugs out of new products. D-Link was contacted about HTTPS RSA vulnerability in 2012 and did not respond to the original noti- 5.1 Vendor notification processes fication. In 2012, the population of vulnerable devices There is considerable debate in the security research was small, but has since increased dramatically. We community as well as among policymakers about the contacted D-Link in May 2016 via their vulnerability ethics of public disclosure of security vulnerabilities. reporting web form and have not received a response. The norm in the academic research community is gen- ADTRAN was notified in 2012 about DSA vulnera- erally “responsible disclosure” [2, 12] in which the re- bilities in SSH and responded at the time. The vulner- searcher notifies the vendor before going public. How- ability for HTTPS RSA keys seems to have been newly ever, the attempted notification of several dozen ven- introduced in 2015. We contacted ADTRAN using the dors studied in this paper shows how this process can customer support form in May 2016. They responded fail at multiple stages. Most of the vendors did not have substantively to our new notification, but have not yet security contact information publicly available. We found, released a public advisory or informed us of a software between our disclosure process and in [21], 16 out of 42 update. vendors had a discoverable point of contact for reporting We attempted to contact Sangfor using the customer vulnerabilities (see Sections 2.5 and 4.4 for details). The support web form, but the request was closed. majority of vendors who were contacted in [21] never re- The only contact we could find for Schmid Telecom sponded to the notification at all. The majority of those was an Information Request web form; we did not re- vendors who did respond in some way never released a Thomson Fritz!Box EFF P&Q Ecosystem Rapid7Censys EFF P&Q Ecosystem Rapid7Censys 5 2 10 5 · 5 6 10 1.5 10 · 5 1 · 105 4 10 Total 50·,000 Total 2 · 105 · 2000 0 150 20,000 100 10,000 50

Vulnerable 0 Vulnerable 0 06-2010 10-2011 02-2013 07-2014 11-2015 06-2010 10-2011 02-2013 07-2014 11-2015 Linksys Fortinet 1.5 105 2 105 · 5 · 1 10 5 Total Total · 1 10 50,000 · 1,5000 300 1,000 20 500 10 Vulnerable 0 Vulnerable 0 06-2010 10-2011 02-2013 07-2014 11-2015 06-2010 10-2011 02-2013 07-2014 11-2015 ZyXEL Dell , 80,000 40 000 60,000 20,000 40,000 Total Total 20,000 0 0 8,000 150 6,000 4,000 100 2,000 50 Vulnerable Vulnerable 0 0 06-2010 10-2011 02-2013 07-2014 11-2015 06-2010 10-2011 02-2013 07-2014 11-2015 Kronos Xerox 8,000 8,000 6,000 6,000 4,000 4,000 Total Total 2,000 2,000 0 0 600 600 400 400 200 200 Vulnerable 0 Vulnerable 0 06-2010 10-2011 02-2013 07-2014 11-2015 06-2010 10-2011 02-2013 07-2014 11-2015 McAfee TPLink 6,000 6,000 4,000 4,000 Total 2,000 Total 2,000 0 0 400 6,000 4,000 200 2,000 Vulnerable 0 Vulnerable 0 06-2010 10-2011 02-2013 07-2014 11-2015 06-2010 10-2011 02-2013 07-2014 11-2015

Figure 9: Many companies never responded to the vulnerability disclosure at all. In the above cases, the population of vulnerable hosts seems to be declining over the past several years. public security advisory. These ﬁgures were repeated on a smaller scale four years later in the more limited ADTRAN security disclosure process we undertook for this paper. 80,000 Reporting vulnerabilities through an organization such 60,000 40,000 as CERT/CC is a potential alternative to directly con- Total 20,000 tacting vendors. Arora et al. [4] found that response 0 time from vendors decreases when reporting through 200 such an organization. However, Li et al. [27] found that some CERT organizations did not follow up on the end- 100 point vulnerability disclosure information they shared, Vulnerable 0 and concluded that reporting vulnerabilities through 06-2010 10-2011 02-2013 07-2014 11-2015 CERT organizations appeared to be of limited utility. D-Link Despite the lack of organized vendor response, the 2 105 eventual declining vulnerability rates for most vendors · 5 1.5 10 suggest that ultimately the underlying vulnerabilities 1 · 105 Total 50·,000 were ﬁxed for most new devices after several years. We hypothesize that this is likely due to newer products 20,0000 15,000 using updated versions of the Linux kernel that incor- 10,000 porate the software mitigations introduced by the main- 5,000 tainers in 2012. It remains an open problem to design

Vulnerable 0 an experiment to test this hypothesis. 06-2010 10-2011 02-2013 07-2014 11-2015 Huawei Recommendations. 60,000 Software and hardware vendors should provide a ded- 40,000 icated means of contact for security vulnerability noti- Total 20,000 ﬁcations, and when possible, an explicit statement of 0 3,000 procedures concerning security vulnerabilities. Such a 2,000 process should include a default timeline for public dis- 1,000 closure, acknowledgments, and a bug bounty policy for

Vulnerable 0 certain classes of ﬂaws [19]. Alternatively, researchers 06-2010 10-2011 02-2013 07-2014 11-2015 can take advantage of the well-deﬁned public disclosure Sangfor process and vendor coordination provided by organiza- 40,000 tions like CERT/CC. In addition to providing a dedi- 30,000 cated contact point, CERT/CC vulnerability disclosure 20,000 policy includes a default 45-day deadline for public dis- Total 10,000 closure. In the case of the process we studied, coordina- 0 tion via CERT resulted in at least two additional public 20 security advisories. 10 We leave it as an open problem to design mechanisms to incentivize vendors to use the most up-to-date ver-

Vulnerable 0 06-2010 10-2011 02-2013 07-2014 11-2015 sions of operating systems and libraries in their products, in order to avoid old vulnerabilities reappearing in Schmid Telecom new products, as we observed in Section 4.4. 1,500 1,000 5.2 Scoring and predicting vendor responses Total 500 Our data does not appear to show any correlation 8000 between company size or customer population and re- 600 sponse to vulnerability notification, nor between vendor 400 response and end-user vulnerability rates. 200 Future work might study in more detail the variables Vulnerable 0 06-2010 10-2011 02-2013 07-2014 11-2015 leading to different vendor responses, and design regulatory, economic, or commercial incentives to promote more effective security policies among vendors. Figure 10: Some vendors had few or no vulnerable hosts in 2012, but appear to have released a vulnerable prod- 5.3 End-user patching behavior uct version since then. In principle, our dataset should allow us to study end- user patching behavior, but this requires software and hardware vendors to make patches available. Only three vendors with HTTPS RSA vulnerabilities (Juniper, In- act with regularly: Thomas et al. [34] found that half nominate, and IBM) released a public security advisory of all Android devices were updated within 30 days of and patch for the vulnerability in 2012, so our visibility a patch becoming available via Android’s over-the-air into end-user patching behavior is limited. push mechanism, and 95% within a year. However, Nevertheless, our data suggests that end user patch- many internet-of-things devices will likely lack a good ing rates were low to nonexistent, and that decreases in interface for users to manage such updates, so designing the vulnerable populations were due to devices or their a usable update mechanism remains an open problem. web interfaces being taken offline altogether. This does In the case of devices aimed at small or medium busi- not seem to be due to devices being entirely unmain- ness consumers, we recommend that vendors encourage tained, as we see clear evidence of a drop in the vul- customer IT staff to adopt a “Patch Tuesday”-type pol- nerable populations around the time of the Heartbleed icy for device updates as well as software products. This disclosure, suggesting that publicity campaigns around requires vendors to remain on top of upstream software vulnerabilities are both effective at changing user be- updates for the software stacks used in their products, havior, as observed previously [15], and that such cam- and push or make available updated software versions paigns can have unintended consequences. Since we do in a standardized manner to customers. The positive not see such significant events elsewhere in the dataset, responses by system administrators to active notifica- nor even a declining trend in the vulnerable populations tion of software vulnerabilities [27, 33] and the effects for Juniper or Innominate devices, it appears that most of end-of-life policies on vulnerable device populations users do not have a regular patching process in place, discussed in Section 4.2 suggests that they may be re- and that widespread patching or mitigation for security ceptive to active update notifications from vendors. flaws in these types of devices is a rare event. The process of applying software updates to indus- We hypothesize that a major contributing factor to trial control systems and critical infrastructure can be the lack of observed patching is that this vulnerability complicated by operational, regulatory, and legal con- largely affected web interfaces for devices rather than siderations. It remains an open problem to design an web services. The low patch rates have distressing im- effective software update mechanism that balances secu- plications for the security of the “internet of things”. rity and reliability of critical systems in this framework. Yu et al. [40] survey a number of critical vulnerabilities that remain unpatched across hundreds of thousands of 5.4 Ethics and responsible disclosure devices in the wild. Detailed information on the random number gener- Previous work on end-user patching rates [39, 15] for ation vulnerabilities studied in this paper, the efficient TLS vulnerabilities and vulnerability notifications [27, batch GCD implementation, and the data sets used in 33] have focused on system administrator behavior for this paper have all been publicly available for years. web sites. In contrast, the families of devices affected The majority of the vendors discussed in this paper by the random number generation vulnerabilities in our were directly notified of the vulnerability in 2012. In the study fall into three broad classes: industrial control course of this research, we discovered five vendors who systems and critical infrastructure, router and firewall appeared to have introduced newly vulnerable products products aimed largely at the small business market, since 2012. We attempted to notify these vendors of the and cable and DSL modems and WiFi routers largely new vulnerability in May 2016. Only two companies aimed at individual consumers. have acknowledged receipt of our disclosure. Huawei released a public security advisory and software update Recommendations. in August 2016. The vulnerability was assigned CVE- Our results show that public disclosure and patching 2016-6670. We give more details in Section 4.4. of security vulnerabilities does not suffice to ensure end- user security. Additional processes will be necessary 6. ACKNOWLEDGEMENTS to ensure patches are deployed to consumers. The de- We thank Joshua Pearlstein for his contributions to sign of appropriate and effective software update mech- the early stages of the project, and the anonymous re- anisms and incentives will likely depend heavily on the viewers for their extremely helpful and detailed feed- end users of the device. back on our submission. This material is based upon For consumer-grade products, multiple studies have work supported by the National Science Foundation un- shown that individual users are unable to effectively der grants CNS-1513671, CNS-1408734, and a gift from evaluate security concerns (e.g. [9, 32]), and will tend Cisco. We are grateful to Cisco for donating the UCS not discover or apply patches. For these cases, actively servers we used for our computations. pushing updates to devices is likely the most effective security update policy. Such a policy has significant drawbacks, however: software updates may produce un- 7. REFERENCES intended side effects or even brick devices [10]. There [1] Junos Pulse/IC (UAC): Details on fixes for is evidence that most users will eventually apply op- OpenSSL “Heartbleed” issue tional patches that are pushed to devices they inter- (CVE-2014-0160)/JSA10623. https://kb.juniper.net/InfoCenter/index?page= Communication Technology Research. Technical content&id=KB29007&pmv=print&actp=LIST, report, U.S. Department of Homeland Security, April 2014. August 2012. [2] Submitting papers: Human subjects and ethical [13] Zakir Durumeric, David Adrian, Ariana Mirian, considerations. https://www.usenix.org/ Michael Bailey, and J. Alex Halderman. A search conference/usenixsecurity16/submitting-papers, engine backed by Internet-wide scanning. In 2016. Accessed: 2016-09-01. Proceedings of the 22nd ACM Conference on [3] Martin R. Albrecht, Davide Papini, Kenneth G. Computer and Communications Security, October Paterson, and Ricardo Villanueva-Polanco. 2015. Factoring 512-bit RSA moduli for fun (and a [14] Zakir Durumeric, David Adrian, Ariana Mirian, profit of $9,000). James Kasten, Elie Bursztein, Nicolas Lidzborski, https://martinralbrecht.files.wordpress.com/2015/ Kurt Thomas, Vijay Eranti, Michael Bailey, and 03/freak-scan1.pdf, 2015. J. Alex Halderman. Neither snow nor rain nor [4] Ashish Arora, Ramayya Krishnan, Rahul Telang, MITM...: An empirical analysis of email delivery and Yubao Yang. An empirical analysis of security. In Proceedings of the 2015 ACM software vendors’ patch release behavior: Impact Conference on Internet Measurement Conference, of vulnerability disclosure. Info. Sys. Research, IMC ’15, pages 27–39, New York, NY, USA, 2015. 21(1):115–132, March 2010. ACM. [5] D. J. Bernstein. How to find smooth parts of [15] Zakir Durumeric, James Kasten, David Adrian, integers. J. Alex Halderman, Michael Bailey, Frank Li, http://cr.yp.to/papers.html#smoothparts. Nicolas Weaver, Johanna Amann, Jethro [6] Daniel J. Bernstein, Yun-An Chang, Chen-Mou Beekman, Mathias Payer, and Vern Paxson. The Cheng, Li-Ping Chou, Nadia Heninger, Tanja matter of Heartbleed. In Proceedings of the 2014 Lange, and Nicko van Someren. Advances in Conference on Internet Measurement Conference, Cryptology - ASIACRYPT 2013: 19th IMC ’14, pages 475–488, New York, NY, USA, International Conference on the Theory and 2014. ACM. Application of Cryptology and Information [16] Zakir Durumeric, James Kasten, Michael Bailey, Security, Bengaluru, India, December 1-5, 2013, and J. Alex Halderman. Analysis of the HTTPS Proceedings, Part II, chapter Factoring RSA Keys certificate ecosystem. In Proceedings of the 13th from Certified Smart Cards: Coppersmith in the Internet Measurement Conference, October 2013. Wild, pages 341–360. Springer Berlin Heidelberg, [17] Zakir Durumeric, Eric Wustrow, and J. Alex Berlin, Heidelberg, 2013. Halderman. ZMap: Fast Internet-wide scanning [7] Hanno Bock. About the supposed factoring of a and its security applications. In Proceedings of the 4096 bit RSA key. 22nd USENIX Security Symposium, August 2013. https://blog.hboeck.de/archives/872-About-the- [18] Peter Eckersley and Jesse Burns. An observatory supposed-factoring-of-a-4096-bit-RSA-key.html. for the SSLiverse. [8] Kevin Butler, Toni R. Farley, Patrick McDaniel, https://www.eff.org/files/DefconSSLiverse.pdf, and Jennifer Rexford. A survey of BGP security 2010. issues and solutions. In Proceedings of the IEEE, [19] Chris Evans, Eric Grosse, Neel Mehta, Matt volume 98, October 2013. Moore, Tavis Ormandy, Julien Tinnes, Michal [9] Hong Chan and Sameera Mubarak. Article: Zalewski, and Google Security Team. Rebooting Significance of information security awareness in responsible disclosure: a focus on protecting end the higher education sector. International Journal users. https://security.googleblog.com/2010/07/ of Computer Applications, 60(10):23–31, rebooting-responsible-disclosure-focus.html, July December 2012. 2010. Accessed: 2016-09-01. [10] Amit Chowdhry. Apple confirms existence of the [20] Torbjörn Granlund and the GMP development ‘Error 56’ iOS 9.3.2 bug. team. GNU MP: The GNU Multiple Precision http://www.forbes.com/sites/amitchowdhry/ Arithmetic Library, 5.0.5 edition, 2012. 2016/05/18/apple-ios-9-3-2-bug, 2016. Accessed: [21] Nadia Heninger, Zakir Durumeric, Eric Wustrow, 2016-09-01. and J. Alex Halderman. Mining your Ps and Qs: [11] Edward J. Correia. Review: Dell C3765dnf Detection of widespread weak keys in network workgroup color printer. devices. In Proceedings of the 21st USENIX http://www.crn.com/reviews/components- Security Symposium, August 2012. peripherals/240154599/review-dell-c3765dnf- [22] Ralph Holz, Johanna Amann, Olivier Mehani, workgroup-color-printer.htm, 2013. Matthias Wachs, and Mohamed Ali Kaafar. TLS [12] D. Dittrich and E. Kenneally. The Menlo Report: in the wild: an Internet-wide analysis of Ethical Principles Guiding Information and TLS-based protocols for electronic communication. Proceedings of NDSS 2016, [32] Jeffrey M. Stanton, Kathryn R. Stam, Paul February 2016. Mastrangelo, and Jeffrey Jolton. Analysis of end [23] Cynthia B. Johnston and Darlene Caldarelli. user security behaviors. Comput. Secur., Xerox Corp.: Xerox International Partners and 24(2):124–133, March 2005. Fuji Xerox align with Dell to expand imaging and [33] Ben Stock, Giancarlo Pellegrino, Christian printing marketplace. Rossow, Martin Johns, and Michael Backes. Hey, http://www.businesswire.com/news/home/ you have a problem: On the feasibility of 20040108005690/en/Xerox-Corp.-Xerox- large-scale web vulnerability notification. In 25th International-Partners-Fuji-Xerox, 2004. USENIX Security Symposium (USENIX Security [24] Thorsten Kleinjung, Kazumaro Aoki, Jens 16), pages 1015–1032, Austin, TX, August 2016. Franke, Arjen K Lenstra, Emmanuel Thomé, USENIX Association. Joppe W Bos, Pierrick Gaudry, Alexander [34] Daniel R. Thomas, Alastair R. Beresford, and Kruppa, Peter L Montgomery, Dag Arne Osvik, Andrew Rice. Security metrics for the Android et al. Factorization of a 768-bit RSA modulus. In ecosystem. In Proceedings of the 5th Annual ACM Advances in Cryptology, CRYPTO ’10, pages CCS Workshop on Security and Privacy in 333–350. Springer, 2010. Smartphones and Mobile Devices, SPSM ’15, [25] A. K. Lenstra and H. W. Lenstra, Jr., editors. pages 87–98, New York, NY, USA, 2015. ACM. The Development of the Number Field Sieve. [35] Theodore Ts’o. /dev/random fixups. Springer, 1993. https://lkml.org/lkml/2012/7/5/414. [26] Arjen K. Lenstra, James P. Hughes, Maxime [36] Theodore Ts’o. random: introduce getrandom(2) Augier, Joppe W. Bos, Thorsten Kleinjung, and system call. https://lwn.net/Articles/605828/, Christophe Wachter. Ron was wrong, Whit is 2014. right. In 32nd International Cryptology [37] Luke Valenta, Shaanan Cohney, Alex Liao, Joshua Conference, CRYPTO ’12, August 2012. Fried, Satya Bodduluri, and Nadia Heninger. http://eprint.iacr.org/2012/064. Factoring as a service. In Financial Cryptography. [27] Frank Li, Zakir Durumeric, Jakub Czyz, Springer, 2016. Mohammad Karami, Michael Bailey, Damon [38] Rob VandenBrink. Be careful what you scan for! McCoy, Stefan Savage, and Vern Paxson. You’ve https://isc.sans.edu/forums/diary/Be+Careful+ got vulnerability: Exploring effective vulnerability what+you+Scan+for/18017/. notifications. In 25th USENIX Security [39] Scott Yilek, Eric Rescorla, Hovav Shacham, Symposium (USENIX Security 16), pages Brandon Enright, and Stefan Savage. When 1033–1050, Austin, TX, August 2016. USENIX private keys are public: Results from the 2008 Association. Debian OpenSSL vulnerability. In Anja Feldmann [28] Gordon Fyodor Lyon. Nmap network scanning: and Laurent Mathy, editors, Proceedings of IMC The official Nmap project guide to network 2009, pages 15–27. ACM Press, November 2009. discovery and security scanning. Insecure, 2009. [40] Tianlong Yu, Vyas Sekar, Srinivasan Seshan, [29] Ilya Mironov. Factoring RSA moduli. part ii. Yuvraj Agarwal, and Chenren Xu. Handling a https://windowsontheory.org/2012/05/17/ trillion (unfixable) flaws on a billion devices: factoring-rsa-moduli-part-ii/, May 2012. Rethinking network security for the [30] Rapid7. Project Sonar SSL Certificates. Internet-of-things. In Proceedings of the 14th https://scans.io/study/sonar.ssl, April 2016. ACM Workshop on Hot Topics in Networks, [31] Ronald L Rivest, Adi Shamir, and Len Adleman. HotNets-XIV, pages 5:1–5:7, New York, NY, A method for obtaining digital signatures and USA, 2015. ACM. public-key cryptosystems. Communications of the ACM, 21(2):120–126, 1978.