From Patches to Honey-Patches: Lightweight Attacker Misdirection, Deception, and Disinformation∗ Frederico Araujo Kevin W. Hamlen Sebastian Biedermann Stefan Katzenbeisser The University of Texas at Dallas Technische Universität Darmstadt {frederico.araujo, hamlen}@utdallas.edu {biedermann, katzenbeisser}@seceng.informatik.tu-darmstadt.de ABSTRACT alone released over 100 security bulletins spanning 330 sepa- Traditional software security patches often have the unfortu- rate vulnerabilities in its products during 2013 [33]. However, nate side-effect of quickly alerting attackers that their attempts despite the increasingly prompt availability of security patches, to exploit patched vulnerabilities have failed. Attackers greatly a majority of attacks in the wild continue to exploit vulnera- benefit from this information; it expedites their search for bilities that are known and for which a patch exists [5, 9, 23]. unpatched vulnerabilities, it allows them to reserve their ulti- This is in part because patch adoption is not immediate, mate attack payloads for successful attacks, and it increases and may be slowed by various considerations, such as patch attacker confidence in stolen secrets or expected sabotage compatibility testing, in some sectors. resulting from attacks. As a result, even determined, resourceful attackers often To overcome this disadvantage, a methodology is pro- probe and exploit unpatched, patchable vulnerabilities in their posed for reformulating a broad class of security patches into victims. For example, a 2013 security audit of the U.S. De- honey-patches|patches that offer equivalent security but partment of Energy revealed that 60% of DoE desktops lacked that frustrate attackers' ability to determine whether their critical patch updates, leading to a compromise and exfiltra- attacks have succeeded or failed. When an exploit attempt tion of private information on over 100,000 individuals [22]. is detected, the honey-patch transparently and efficiently The prevalence of unpatched systems has led to tools and redirects the attacker to an unpatched decoy, where the at- technologies via which attackers can quickly derive unique, tack is allowed to succeed. The decoy may host aggressive previously unseen exploits from patches [12], allowing them to software monitors that collect important attack information, infiltrate vulnerable systems. and deceptive files that disinform attackers. An implementa- The obvious solution is, of course, to obey the golden rule tion for three production-level web servers, including Apache of \patch early, patch often." However, once applied, typical HTTP, demonstrates that honey-patching can be realized for security patches have a significant drawback|they advertise large-scale, performance-critical software applications with that the system is patched. For example, a request that minimal overheads. yields garbage output from an unpatched server, but yields an error message from a patched server, readily divulges Categories and Subject Descriptors: D.2.7 [Software whether the server is vulnerable. Attackers can quickly and Engineering]: Distribution, Maintenance, and Enhancement; efficiently probe such servers for known vulnerabilities to D.4.6 [Operating Systems]: Security and Protection; K.6.5 discover patching lapses and prepare potent attacks. [Management of Computing and Information Systems]: Secu- To misdirect such attackers, we propose patching vulnera- rity and Protection|Unauthorized access bilities in such a way that failed exploits appear to succeed. Keywords: Intrusion detection and prevention; Honeypots This frustrates attackers' ability to discern which apparent vulnerabilities will actually divulge secrets or do damage 1. INTRODUCTION once fully exploited. We refer to such a patch as a honey- patch. Honey-patches offer equivalent security to conventional Patching continues to be perhaps the most ubiquitous and patches, but respond to attempted exploits by transparently widely accepted means for addressing newly discovered security redirecting the attacker's connection to a carefully isolated vulnerabilities in commodity software products. Microsoft decoy environment. The decoy is unpatched, allowing the attack to succeed, but gathers information about the threat ∗This research was supported by ONR grant N00014-14-1-0030, AFOSR grant FA9550-14-1-0173, NSF grant 1054629, CASED (e.g., collecting and analyzing previously unseen malware), and EC-SPRIDE Darmstadt, and BMBF grant 01C12S01V. and feeds disinformation to the attacker in the form of falsified data (cf., [11, 48, 62]). As an illustration of where honey-patching could be useful, Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed consider the digital infrastructure mandated by the U.S. Pa- for profit or commercial advantage and that copies bear this notice and the full cita- tient Protection and Affordable Care (\Obamacare") Act [52]. tion on the first page. Copyrights for components of this work owned by others than The act entails the deployment of federal- and state-level web ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re- servers that sell health care plans. These servers have been publish, to post on servers or to redistribute to lists, requires prior specific permission identified as inviting targets of directed cyber-attacks, since and/or a fee. Request permissions from [email protected]. they receive a wealth of personally identifying information that CCS’14, November 3–7, 2014, Scottsdale, Arizona, USA. Copyright 2014 ACM 978-1-4503-2957-6/14/11 ...$15.00. could be abused for identity theft and fraud [21]. Patching http://dx.doi.org/10.1145/2660267.2660329. these servers in the conventional way protects against known Listing 1: Abbreviated patch for Heartbleed Listing 2: Honey-patch for Heartbleed 1 + if (1 + 2 + payload + 16 > s->s3->rrec.length) 1 if (1 + 2 + payload + 16 > s->s3->rrec.length) 2 + return 0; // silently discard 2 + f 3 + hp fork(); 4 - return 0; // silently discard exploits, but facilitates an attacker's probing efforts until an 5 + hp skip(return 0); // silently discard unpatched vulnerability is found. Network-level filters redirect 6 + g known malware to honey-servers, but may not catch custom malware payloads whose exploitive behavior is only detected disclosures in recent history, affecting a majority of then- at execution. deployed web servers, including Apache. The patch introduces However, honey-patching the servers and stocking the a conditional that validates SSL/TLS heartbeat packets, decoy environments with false information that has been declining malformed requests. Prior to being patched, attackers red-flagged in identity theft databases greatly increase risk for could exploit this bug to acquire sensitive information from attackers who manage to bypass other safeguards to reach many web servers. the decoy. Apparently successful attacks may then yield This patch exemplifies a common vulnerability mitigation: tainted information that could lead to an arrest when used. dangerous inputs or program states are detected via a boolean Even if the deception is eventually uncovered, defenders gain test, with positive detection eliciting a corrective action. valuable threat information by aggressively monitoring the most dangerous attacks, and attacker reconnaissance efforts The corrective action is typically readily distinguishable by are impeded. attackers|in this case, the attacker request is silently declined. While the concept of honey-patching is straightforward, As a result, the patched and unpatched programs differ only realizing it in practice is not. To demonstrate and evaluate on attack inputs, making the patched system susceptible to its feasibility, we present an implementation for three high- probing. Our goal in this work is to introduce a strategy performance web servers: Apache HTTP, Lighttpd, and Nginx. whereby administrators of products such as Apache can Our implementation, RedHerring, Redirects Exploits to easily transform such patches into honey-patches, whose Deceptive Honeypot Environments for counteRReconnaissance corrective actions impede attackers and offer strategic benefits and INformation Gathering. We chose Apache as our flag- to defenders. ship case-study due to its complexity (2.2M SLOC) and its Toward this end, Listing 2 presents an alternative, honey- use in many security-sensitive contexts. For example, most patched implementation of the same patch. In response Obamacare web sites presently use it. to a malformed input, the honey-patched application forks Our work includes the following contributions: itself onto a confined, ephemeral, decoy environment, and behaves henceforth as an unpatched, vulnerable version of • We outline a strategy for easily reformulating many the software. Specifically, line 3 forks the user session to vendor-supplied, source-level patches into equally secure a decoy container, and macro hp_skip in line 5 elides the honey-patches that raise attacker risk and uncertainty. rejection in the decoy container so that the attack appears • We introduce a light-weight, resource-efficient, and to have succeeded. Meanwhile, the attacker session in the fine-grained approach to transparently fork attacker original container is safely terminated (having been forked to connections to a sandboxed decoy devoid of secrets. the decoy), and legitimate, concurrent connections continue • Our decoy generation