When an organization’s computer systems come under attack, it usually wants to minimize the damage as quickly as possible. For some types of attacks, like SQL injection or cross-site script injection, the clear path forward is to identify and close the vulnerability that allowed the attack in the first place, then clean up the other problems the attacker may have caused (backdoors, etc.). But this process does not work well for some other types of attacks.

For example, in a distributed denial-of-service (DDoS) attack, a large number of systems make (mostly) ordinary requests, for example asking for the main page of a website, that would not be troublesome individually. But since there are so many, they overwhelm the system’s ability to respond to legitimate requests, leaving real visitors unable to access the site or its services. The computers making the attack requests might be owned by the attackers, but they might not: they could be compromised themselves (black-market services rent “botnets” of virus infected machines to participate in these sorts of things), connecting to another innocent-but-compromised system to receive commands, and the actual attacker may be virtually untraceable.

In September a series of high-profile DDoS attacks were carried out against several banks, and in December a division of the U.S. Treasury Department issued a warning indicating that the attacks had multiple motives, including distracting bank personnel from monitoring fraudulent transactions and making it difficult or impossible for customers to report fraudulent transactions over using the bank’s website. Planning can help when responding to a DDoS incident, but there is usually no single hole or vulnerability to address, since the problem is simply one of finite available resources. The best protection against a DDoS attack is the ability to scale services up rapidly and handle all of the requests normally, but this only gives the attacker a reason to launch an even bigger attack next time. In many ways DDoS is an arms race between high-availability websites and their attackers.

So, what are the banks (and others in similar situations) to do? One possible answer is to swap defense for offense. This is sometimes called “hacking back,” “active defense,” “self-defense,” depending on your point of view (and on the scope of the activity). The idea is that if the organization under attack can cripple the attacker’s ability to launch and maintain a DDoS offensive, it can render the attack ineffective. But what can it legally do to achieve that goal? Gather information from its own logs, or from publicly available sources? Definitely yes. Reconfigure its systems to make DDoS more difficult? Certainly. Can it identify a vulnerability in the many systems carrying out the DDoS attack and configure its servers to send a special response to crash those systems? That’s much less certain. Remember, these might be malicious systems, but they also might be innocent systems infected with malware. Can it launch its own outbound attacks against the systems participating in the DDoS attack? Maybe, but probably not: that action likely constitutes a violation of anti-hacking laws in its own right. What about attacking the command-and-control servers DDoS attackers typically use to coordinate their activity? If the victim can identify the C&C, can they insert “good” malware to gain partial control, and monitor the malicious activity of the C&C? Can the “good” malware disable the program running the C&C service? (What if the “C&C” actually piggybacks on a legitimate service, like a website–or a blog?) Can it disable the host completely by corrupting its operating system? Traditional views of anti-hacking law again say none of this is allowed. But is that true? And is it socially desirable? Should the law of trespass or necessity apply here, granting a limited “right” to repel attackers? Should operators of critical infrastructure like hospitals and power plants have a broader right to engage in active defense? What happens if a critical-infrastructure system is one of the innocents caught in the crossfire–would they have a broader right than you I to sue “active defenders?”

In short, traditional defense is not always enough. When you are under attack, what rights do you have today, and what rights should you have tomorrow, to fight back in a such a way that may (or may not) affect possibly-innocent, infected, bystanders? Although there are not yet any cases that address the issue, it may only be a matter of time. There are start-ups already focused on (legal) active defense, and companies like the banks that experienced daylong outages last year may be more willing to engage in a new, untested tactic. A group of information security analysts and lawyers also recently formed a discussion group to address these questions (disclosure: I help manage the email list). Another group of law professors and practitioners recently had a lengthy discussion on the popular legal blog Volokh Conspiracy, analyzed at length (and all in one place) here. They debate the CFAA, with the traditional view broadly prohibiting active defense, and several different understandings that would permit some active defense based on the text of the CFAA, policy, common-law trespass, and common-law tort. Other cyberlawinformation security, and technology bloggers have analyzed the issues as well. Where should we go from here? What, if any, active defense–or was it hacking back?–should be allowed? And is that what is allowed today?

–Brad Edmondson

Image Source

Tagged with:

3 Responses to Illegal “Hacking Back” or Necessary “Active Defense”?

  1. Bradlee Edmondson says:

    Thanks for the comments; I hope to keep developing these concepts at JETLaw and in general.

    @Zach: Are you saying they should be subject to tort liability (restitution for third parties harmed by the defensive act), thus implying the law of necessity? Or are you saying that criminal liability (CFAA/unauthorized access) should be conditioned on whether a third-party innocent is harmed?

    @Jacob: True, cloud computing can help the defenders in a number of ways. You mention the sheer bandwidth, but you could also mention that good endpoint (laptop/desktop/phone/table) management is also easier when they primarily access the cloud instead of locally run applications. Still, we should bear in mind that active defense, (or active response, or hacking back,) might apply to targeted data-theft attacks in addition to DDoS. For instance, the attacker could compromise a third-party email account and use that to send custom malware to a corporation’s financial officer, then use a compromised third-party webserver as the command-and-control server to which that malware looks for instructions. In that scenario, the fact that the data is on a corporate cloud with (let’s stipulate) effectively infinite bandwidth does not mean the risk shrinks. If the CFO’s machine is compromised, the corporation is still at risk, and it might still have an incentive to “actively respond.” It might want to reach out to the compromised webserver to disable the attacker’s command-and-control capabilities, to check whether any of its other machines are infected (and reporting back to the webserver), or to try to identify the attacker.

    On this understanding, I think at least some incentive arises to take a more active response role whenever an attack might have a significant effect on an organization’s goals or bottom line, and it is possible that compromised third-party assets are being to carry out the attack.

  2. Zachary Loney says:

    I think liability would have to attach on the part of the defender. From the defender’s position, they are only worried about stopping the attack as quickly as possible to limit their damage. Adding liability to the cost-benefit analysis would encourage the defender to use less destructive measures. There remains the question of whether these lesser defenses would be as efficient or if the attacker could easily thwart or route around these attempts.

    Perhaps a more innovative (and in my mind a more effective) approach is to encourage a more subtle offense—infiltration of the intermediary, investigation, and finally a planned strike against an identified original attacker. If the defender can strike back, it should also notify the owner of the system that a) their system is compromised, and 2) that the defender intends to infiltrate their system for investigative purposes. The following investigation would help ensure that the appropriate computers are targeted. And finally, a well-organized and orchestrated counterstrike is far more likely to be effective in destroying the root of the problem.

    There are definite issues with privacy and 3rd party security but I believe that the best response to targeted hacking attacks is with an equally well-planned response.

    You’re absolutely right that cloud computing can help in a lot of situations, but I think it also could provide wonderful tools for hackers. In a recent situation the hackers compromised high bandwidth webservers for e-commerce sites and were able to launch large scale attacks on a number of banks. They used the same infrastructure that was designed to allow for high bandwidth traffic.

  3. Jacob Schumer says:

    Great post, Brad.

    I personally think that counter-offensives of that type should be legal. It seems unfair that hackers can use human shields (the zombie computers), and thus prevent sites from defending themselves in a very useful manner. It would also incentivize users to secure their computers, since being part of a botnet could severely cripple their internet connection.

    However, I hope that such defenses will eventually be obsoleted by the growth of cloud computing. Sites on large cloud services are resilient against DDoS attacks because spikes in traffic are absorbed by the huge network of servers and distributed evenly. As cloud networks get larger, DDoS attacks will become like shooting bullets at T-1000 in Terminator 2. Such defenses then could be reserved for sites that for security reasons can’t utilize cloud computing.