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
Veterans Find New Roles in Enterprise Cybersecurity
Kelly Sheridan, Staff Editor, Dark Reading,  11/12/2018
Empathy: The Next Killer App for Cybersecurity?
Shay Colson, CISSP, Senior Manager, CyberClarity360,  11/13/2018
Understanding Evil Twin AP Attacks and How to Prevent Them
Ryan Orsi, Director of Product Management for Wi-Fi at WatchGuard Technologies,  11/14/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
Online Malware and Threats: A Profile of Today's Security Posture
Online Malware and Threats: A Profile of Today's Security Posture
This report offers insight on how security professionals plan to invest in cybersecurity, and how they are prioritizing their resources. Find out what your peers have planned today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-15769
PUBLISHED: 2018-11-16
RSA BSAFE Micro Edition Suite versions prior to 4.0.11 (in 4.0.x series) and versions prior to 4.1.6.2 (in 4.1.x series) contain a key management error issue. A malicious TLS server could potentially cause a Denial Of Service (DoS) on TLS clients during the handshake when a very large prime value is...
CVE-2018-18955
PUBLISHED: 2018-11-16
In the Linux kernel 4.15.x through 4.19.x before 4.19.2, map_write() in kernel/user_namespace.c allows privilege escalation because it mishandles nested user namespaces with more than 5 UID or GID ranges. A user who has CAP_SYS_ADMIN in an affected user namespace can bypass access controls on resour...
CVE-2018-19311
PUBLISHED: 2018-11-16
Centreon 3.4.x allows XSS via the Service field to the main.php?p=20201 URI, as demonstrated by the "Monitoring > Status Details > Services" screen.
CVE-2018-19312
PUBLISHED: 2018-11-16
Centreon 3.4.x allows SQL Injection via the searchVM parameter to the main.php?p=20408 URI.
CVE-2018-19318
PUBLISHED: 2018-11-16
SRCMS 3.0.0 allows CSRF via admin.php?m=Admin&c=manager&a=update to change the username and password of the super administrator account.