Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

4/11/2018
10:30 AM
Connect Directly
LinkedIn
RSS
E-Mail vvv
50%
50%

Hack Back: An Eye for an Eye Could Make You Blind

Attackers have had almost zero consequences or cost for stealing data from innocent victims. But what if we could hack their wallets, not their systems?

As Gandhi once said, "An eye for an eye will only make the whole world blind." The same could be said about using "hack back" technology for vengeful purposes, such as security defenders who respond to attackers with the intent to harm their systems. What would happen if we let corporations take cyber justice into their own hands? Critics fear it will make the Internet less safe and unintended harm will be directed at innocent bystanders. But should we live at the mercy of attackers who have more control over our data than we do? Or is it possible to hack back in an ethical and safe way?

Legislation has been proposed in Congress that would make it legal for folks to defend themselves in an attack by hacking back. Even if the language of the legislation is inherently ambiguous, the intent is clear: change the asymmetric cyberwar to at least provide equal footing to the defenders. Attackers have always had the high ground. It's time to change that.

It is understandable that the concept of hacking back has been met with loud opposition by some academics, security professionals, and policy analysts, claiming that it's the worst idea in cybersecurity ever. (That's certainly debatable; purely signature-based antivirus is perhaps worse.) They believe attribution of the true attacker is just not solvable and could lead to mistaken identities or hacking the wrong person. I disagree with these knee-jerk reactions, but that also depends on the definition of hacking back. When there are many sides to an argument, it's important to make sure we're all talking about the same thing.

How to Define Hacking Back
Hacking back is one of the best-kept secrets by some defenders and clearly runs afoul of the Computer Fraud and Abuse Act (CFAA). It is illegal for a defender to probe a remote source IP implicated in an attack on them and exploit any found vulnerabilities to implant code in the abusive machine, even if the defender seeks to recover or destroy stolen data. The cost to the defender is very high, especially if the target of their revenge turns out to be an innocent bystander. Under CFAA, the penalties can be quite stiff.

For these and other reasons, the Active Cyber Defense Certainty Act (ACDC) seeks to limit or entirely eliminate the liability of the corporation that seeks to defend itself and recover its own lost data by retaliatory strikes against the perpetrator. But being certain of the true source of an attack — true attribution — remains elusive and misdirected revenge could do far more harm, even if it is legal. There must be a safer way to legitimately hack back to recover or destroy stolen data.

Target the Attackers' Knowledge, Not Their Systems
Attackers have had almost zero consequences or costs for stealing data from innocent victims. What if we could hack their wallets, but not their systems? The goal of hacking back should be to confound and confuse them, especially attackers who have the primary goal of data exfiltration for monetary gain. Make them pay a price for stealing data from an innocent victim. Cost should now be part of the game.

But how do we do that without causing damage to an innocent bystander who served merely as a stepping stone for the true attack hiding in the shadows? Unmitigated (and vengeful) hacking back plays directly into the hands of the attacker who executes an old school reflector attack, for example. How might we reach past the stepping stones and serve up their just rewards to the true attacker?

One way is by feeding attackers with unbounded, exfiltrated bogus data. This strategy not only makes them think twice about whether they were snookered, but they now have the expense of figuring out what of their quarry actually has any value to them. Of course, the same may be true of nation-state actors; they, too, should not operate freely any longer, even if their goal is nonmonetary.

Deception in Depth
Deception security is a growing marketplace, and it's an obvious choice for safely hacking back (hackbacking?) with outcomes that favor the defender. But the key to successful deployment of deception security must incorporate strategic placement and replenishment of deceptive data throughout the operational networks of the defended enterprise, making it very hard to tell what is real and what isn't for the attacker. Sophisticated attackers do well to identify the "tells" that can be found in honeynets, especially those that lack realistic data and data flows. And if the deceptive data and decoy document generation is automated and architected well, it will be nearly impossible for the attacker to tell if the data is real or not.

For this to work, deceptive materials must be believable, noninterfering with normal operations, conspicuous to the attacker, and plentiful to keep the attackers well fed and deeply frustrated. These guidelines for successful decoy data deployment within operational networks are achievable and could one day become part of any modern security architecture.

Deception and decoy data is clearly a knowledge attack that seems to me to be the best choice to safely hack back. A data deception strategy may work best to feed the attacker with the false sense of accomplishment, but with the real cost of determining what they stole is real or bogus.

Revenge may best be served cold, but defenders can bask in the warmth of knowing their hack-back method, serving tons of decoys, caused the attacker as much frustration and anger as they experienced in the past when their network was pierced, and their corporate data was stolen as reported in the headlines. A knowledge attack is a safer alternative that no one can complain about from a judicial or legal perspective, and certainly no one will go blind to the fact that the defender now has the high ground.

Related Content:

Interop ITX 2018

Join Dark Reading LIVE for an intensive Security Pro Summit at Interop ITX and learn from the industry’s most knowledgeable IT security experts. Check out the agenda here. Register with Promo Code DR200 and save $200.

Dr. Salvatore Stolfo is the founder and CTO of Allure Security. As a professor of artificial intelligence at Columbia University since 1979, Dr. Stolfo has spent a career figuring out how people think and how to make computers and systems think like people. Dr. Stolfo has ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
I 'Hacked' My Accounts Using My Mobile Number: Here's What I Learned
Nicole Sette, Director in the Cyber Risk practice of Kroll, a division of Duff & Phelps,  11/19/2019
DevSecOps: The Answer to the Cloud Security Skills Gap
Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
Attackers' Costs Increasing as Businesses Focus on Security
Robert Lemos, Contributing Writer,  11/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-13157
PUBLISHED: 2019-11-22
nsGreen.dll in Naver Vaccine 2.1.4 allows remote attackers to overwrite arbitary files via directory traversal sequences in a filename within nsz archive.
CVE-2012-2079
PUBLISHED: 2019-11-22
A cross-site request forgery (CSRF) vulnerability in the Activity module 6.x-1.x for Drupal.
CVE-2019-11325
PUBLISHED: 2019-11-21
An issue was discovered in Symfony before 4.2.12 and 4.3.x before 4.3.8. The VarExport component incorrectly escapes strings, allowing some specially crafted ones to escalate to execution of arbitrary PHP code. This is related to symfony/var-exporter.
CVE-2019-18887
PUBLISHED: 2019-11-21
An issue was discovered in Symfony 2.8.0 through 2.8.50, 3.4.0 through 3.4.34, 4.2.0 through 4.2.11, and 4.3.0 through 4.3.7. The UriSigner was subject to timing attacks. This is related to symfony/http-kernel.
CVE-2019-18888
PUBLISHED: 2019-11-21
An issue was discovered in Symfony 2.8.0 through 2.8.50, 3.4.0 through 3.4.34, 4.2.0 through 4.2.11, and 4.3.0 through 4.3.7. If an application passes unvalidated user input as the file for which MIME type validation should occur, then arbitrary arguments are passed to the underlying file command. T...