From Patches to Honey-Patches: Lightweight Attacker Misdirection

Download From Patches to Honey-Patches: Lightweight Attacker Misdirection

Post on 30-Dec-2016




2 download

Embed Size (px)


  • From Patches to Honey-Patches: LightweightAttacker Misdirection, Deception, and Disinformation

    Frederico Araujo Kevin W. HamlenThe University of Texas at Dallas

    {frederico.araujo, hamlen}

    Sebastian Biedermann Stefan KatzenbeisserTechnische Universitt Darmstadt

    {biedermann, katzenbeisser}

    ABSTRACTTraditional software security patches often have the unfortu-nate side-effect of quickly alerting attackers that their attemptsto exploit patched vulnerabilities have failed. Attackers greatlybenefit from this information; it expedites their search forunpatched vulnerabilities, it allows them to reserve their ulti-mate attack payloads for successful attacks, and it increasesattacker confidence in stolen secrets or expected sabotageresulting from attacks.

    To overcome this disadvantage, a methodology is pro-posed for reformulating a broad class of security patches intohoney-patchespatches that offer equivalent security butthat frustrate attackers ability to determine whether theirattacks have succeeded or failed. When an exploit attemptis detected, the honey-patch transparently and efficientlyredirects the attacker to an unpatched decoy, where the at-tack is allowed to succeed. The decoy may host aggressivesoftware monitors that collect important attack information,and deceptive files that disinform attackers. An implementa-tion for three production-level web servers, including ApacheHTTP, demonstrates that honey-patching can be realized forlarge-scale, performance-critical software applications withminimal overheads.

    Categories and Subject Descriptors: D.2.7 [SoftwareEngineering]: Distribution, Maintenance, and Enhancement;D.4.6 [Operating Systems]: Security and Protection; K.6.5[Management of Computing and Information Systems]: Secu-rity and ProtectionUnauthorized access

    Keywords: Intrusion detection and prevention; Honeypots

    1. INTRODUCTIONPatching continues to be perhaps the most ubiquitous and

    widely accepted means for addressing newly discovered securityvulnerabilities in commodity software products. Microsoft

    This research was supported by ONR grant N00014-14-1-0030,AFOSR grant FA9550-14-1-0173, NSF grant 1054629, CASEDand EC-SPRIDE Darmstadt, and BMBF grant 01C12S01V.

    Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full cita-tion on the first page. Copyrights for components of this work owned by others thanACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re-publish, to post on servers or to redistribute to lists, requires prior specific permissionand/or a fee. Request permissions from, November 37, 2014, Scottsdale, Arizona, USA.Copyright 2014 ACM 978-1-4503-2957-6/14/11 ...$15.00.

    alone released over 100 security bulletins spanning 330 sepa-rate vulnerabilities in its products during 2013 [33]. However,despite the increasingly prompt availability of security patches,a majority of attacks in the wild continue to exploit vulnera-bilities that are known and for which a patch exists [5, 9, 23].This is in part because patch adoption is not immediate,and may be slowed by various considerations, such as patchcompatibility testing, in some sectors.

    As a result, even determined, resourceful attackers oftenprobe and exploit unpatched, patchable vulnerabilities in theirvictims. For example, a 2013 security audit of the U.S. De-partment of Energy revealed that 60% of DoE desktops lackedcritical patch updates, leading to a compromise and exfiltra-tion of private information on over 100,000 individuals [22].The prevalence of unpatched systems has led to tools andtechnologies via which attackers can quickly derive unique,previously unseen exploits from patches [12], allowing them toinfiltrate vulnerable systems.

    The obvious solution is, of course, to obey the golden ruleof patch early, patch often. However, once applied, typicalsecurity patches have a significant drawbackthey advertisethat the system is patched. For example, a request thatyields garbage output from an unpatched server, but yieldsan error message from a patched server, readily divulgeswhether the server is vulnerable. Attackers can quickly andefficiently probe such servers for known vulnerabilities todiscover patching lapses and prepare potent attacks.

    To misdirect such attackers, we propose patching vulnera-bilities in such a way that failed exploits appear to succeed.This frustrates attackers ability to discern which apparentvulnerabilities will actually divulge secrets or do damageonce fully exploited. We refer to such a patch as a honey-patch. Honey-patches offer equivalent security to conventionalpatches, but respond to attempted exploits by transparentlyredirecting the attackers connection to a carefully isolateddecoy environment. The decoy is unpatched, allowing theattack to succeed, but gathers information about the threat(e.g., collecting and analyzing previously unseen malware),and feeds disinformation to the attacker in the form of falsifieddata (cf., [11, 48,62]).

    As an illustration of where honey-patching could be useful,consider the digital infrastructure mandated by the U.S. Pa-tient Protection and Affordable Care (Obamacare) Act [52].The act entails the deployment of federal- and state-level webservers that sell health care plans. These servers have beenidentified as inviting targets of directed cyber-attacks, sincethey receive a wealth of personally identifying information thatcould be abused for identity theft and fraud [21]. Patchingthese servers in the conventional way protects against known

  • Listing 1: Abbreviated patch for Heartbleed1 + if (1 + 2 + payload + 16 > s->s3->rrec.length)2 + return 0; //silently discard

    exploits, but facilitates an attackers probing efforts until anunpatched vulnerability is found. Network-level filters redirectknown malware to honey-servers, but may not catch custommalware payloads whose exploitive behavior is only detectedat execution.

    However, honey-patching the servers and stocking thedecoy environments with false information that has beenred-flagged in identity theft databases greatly increase risk forattackers who manage to bypass other safeguards to reachthe decoy. Apparently successful attacks may then yieldtainted information that could lead to an arrest when used.Even if the deception is eventually uncovered, defenders gainvaluable threat information by aggressively monitoring themost dangerous attacks, and attacker reconnaissance effortsare impeded.

    While the concept of honey-patching is straightforward,realizing it in practice is not. To demonstrate and evaluateits feasibility, we present an implementation for three high-performance web servers: Apache HTTP, Lighttpd, and Nginx.Our implementation, RedHerring, Redirects Exploits toDeceptive Honeypot Environments for counteRReconnaissanceand INformation Gathering. We chose Apache as our flag-ship case-study due to its complexity (2.2M SLOC) and itsuse in many security-sensitive contexts. For example, mostObamacare web sites presently use it.

    Our work includes the following contributions:

    We outline a strategy for easily reformulating manyvendor-supplied, source-level patches into equally securehoney-patches that raise attacker risk and uncertainty.

    We introduce a light-weight, resource-efficient, andfine-grained approach to transparently fork attackerconnections to a sandboxed decoy devoid of secrets.

    Our decoy generation incorporates a novel techniquefor efficient in-memory redaction of secrets that couldotherwise be abused by attackers.

    Implementations and evaluations for three productionweb servers demonstrate that the approach is feasible forlarge-scale, performance-critical software with minimaloverheads for legitimate users.

    Section 2 first outlines the honey-patching process andpresents our system design. Section 3 describes the architecturein greater detail, and Section 4 explores the central challengeof efficient, live redirection of attacker sessions to decoys. Ourimplementation is summarized in Section 5 and evaluatedin Section 6. Discussion and related work are presented inSections 7 and 8, respectively, and Section 9 concludes with asummary of outcomes and future directions.

    2. SYSTEM OVERVIEWWe first outline the concept of a honey-patch, and then de-

    scribe primary challenges and corresponding high-level designdecisions for honey-patching. Finally, we summarize importanttechnologies that undergird our implementation approach.

    2.1 From Patches to Honey-PatchesListing 1 shows an abbreviated patch in diff style for the

    Heartbleed OpenSSL buffer over-read vulnerability (CVE-2014-0160) [14]one of the most significant vulnerability

    Listing 2: Honey-patch for Heartbleed1 if (1 + 2 + payload + 16 > s->s3->rrec.length)2 + {3 + hp fork();4 - return 0; //silently discard5 + hp skip(return 0); //silently discard6 + }

    disclosures in recent history, affecting a majority of then-deployed web servers, including Apache. The patch introducesa conditional that validates SSL/TLS heartbeat packets,declining malformed requests. Prior to being patched, attackerscould exploit this bug to acquire sensitive information frommany web servers.

    This patch exemplifies a common vulnerability mitigation:dangerous inputs or program states are detected via a booleantest, with positive detection eliciting a corrective action.The corrective action is typically readily distinguishable byattackersin this case, the attacker request is silently declined.As a result, the patched and unpatched program