Mirai Vulnerability Disclosed, But Exploits May Constitute Hacking Back

A buffer overflow found in the Mirai botnet could eliminate its ability to carry out HTTP flood attacks. But exploiting that vulnerability puts defenders in a gray area with regard to hacking back.

The Mirai botnet apparently has a weakness that could shut down its ability to flood targets with HTTP requests. But exploiting that vulnerability puts defenders in a gray area with regard to hacking back.

Researchers at Invincea Labs discovered three vulnerabilities in Mirai, one of which is the most critical and applicable to putting a halt to one of the botnet’s DDoS capabilities. A stack buffer overflow was found after a close look at the source code that was publicly dumped three weeks ago. The flaw is in the segment of code that carries out HTTP flood attacks and if exploited would crash one of two forked subprocesses used in the attack; one process carries out the attack, while the other sleeps for a specified time before killing the parent process and exiting.

Invincea said its exploit causes a segmentation fault in a bot carrying out an HTTP flood attack, crashing the attack process, but leaving the compromised intact and running. Researchers said this technique would not have helped in last Friday’s DNS-based DDoS attack against provider Dyn, but would shut down Layer 7 attack capabilities present in the publicly available Mirai code.

Scott Tenaglia, research director at Invincea Labs, said the buffer overflow vulnerability lies in the way Mirai parses responses from HTTP packets, and can be used to stop an attack from a compromised device.

In a lab setting, Invincea said it set up three virtual machines: a debug instance of the Mirai bot; a Mirai command and control server; and a victim. The proof-of-concept exploit it has developed is 100 percent effective, he said.

“It’s very simple modification to the response the webserver sends,” Tenaglia said. “It’s not malformed in the sense of the HTTP protocol, but malformed in what the client expects to receive in terms of an HTTP response.”

Tenaglia said the nuance in the Invincea exploit is that the bot would still be connected.

“When we exploit the vulnerability in the attacking code, it exploits only the vulnerability in the child process,” Tenaglia said. “The bot itself is still running; we haven’t cleaned the bot infection, just stopped the attack.”

As Tenaglia points out, there’s nothing preventing the attacker from re-starting the attack, or from ultimately patching it. In the meantime, DDoS protection services, delivery networks and/or network managers would have to make the decision in concert with legal counsel as to the legality of this type of action.

“As a general matter, you cannot send code to another computer that is unauthorized in nature,” said Ed McAndrew, an attorney with Ballard Spahr in Washington, D.C., and a former federal cybercrime prosecutor. “If you think about the [Computer Fraud and Abuse Act] CFAA, you are really talking about authorized access to a protected computer. The question is, if the code is on the bot, you are modifying code that resides on these devices. I think it constitutes access, and you would have a potential problem with the CFAA.”

While there have been numerous court-ordered botnet takedowns in the past, McAndrew points out that the disruptive activity against the botnets occurred outside the infected bots, and any eradication was done with either a court order, or the owner’s consent, eliminating any concerns with violating the CFAA. McAndrew said that the owners of Mirai-compromised devices may similarly be willing to work with defenders to remove the malware from their devices. Invincea, for its part, is clear in its report that it is not advocating a counterattack.

“It’s in the gray space of active defense,” Tenaglia conceded. “In the defense world, this is a hotly contested issue. Say if your IoT is already compromised and bad code is already running, if I do something to the bad guy’s code, am I breaking law?”

Hacking back is illegal under the Computer Fraud and Abuse Act, which prohibits intentional damage to a protected computer, the trafficking of passwords, intentionally damaging data on a computer, unauthorized access to government computers and data, and more.

“I would never comment on the legality of this,” Tenaglia said. “I think this gives us another point to discuss with regard to active defense. Is this something we think is ok? I don’t think it would hurt the system; it might help it. If a bot is degrading performance of the Internet connection because of the packets it’s sending out, and if this attack kills the process and the connection gets better, have we helped you? That’s why this is a gray area.”

Suggested articles

Discussion

  • Ken on

    Nice to notify the bad guys that they have a vulnerability they need to fix while the good guys try to figure out the ethics of war.
  • Bryan on

    The silliness of CFAA. It's illegal to stop an attack? Can't wait until ignorance and apathy take over the world and make it illegal to respond to a kinetic attack as well.
  • Horacio on

    This article makes no sense. There's nothing illegal in sending a modified header in an HTTP response.
  • Anonymous on

    The issue is that the counterattack is on a system which is still someone else's system, not the hacker's system. I can see it getting into the grey zone as a system works for the owner but some of the system(s) are compromised. Think about this scenario: One of the computers on Amazon's network starts sending out DDoS attacks. You can't reach the actual machine. So do you take Amazon down?
    • Horacio on

      But the exploit is to modify the response on the attacked party, which thanks to the discovered bug just happens to end the attack from a compromised system . As a victim, you are not taking anyone's system down nor illegally entering or modifying nobody's code but yours.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.