Source: https://www.vulnhub.com/entry/kioptrix-level-13-4,25/
4th in the series now of Kioptrix (1 to go!). I’ll be concluding the reading/video portion of OSCP studying soon and will be doing a lot of practice in the online labs so this may be my last vulnhub VM in a while. These have been a great learning experience and I’m looking forward to doing the next one soon!
To get this started, we’ll do the usual nmap host discovery scan.
nmap 192.168.111.0/24 -sP
And then an OS/service scan of the victim.
nmap 192.168.111.100 -O -sV
In addition to OpenSSH + Apache like in the last challenge this one now has 2 ports for the Samba service running.
Let’s navigate to the HTTP server in a web browser to take a look.
I view the source and that doesn’t really give me any information other than that there is an /images/ folder and login authentications go through “checklogin.php”. I try a variety of different combinations of admin, loneferret, test, administrator, etc. but nothing comes back successful. Like in previous Kioptrix VMs there is no feedback on whether or not the ID is valid so unless the combination is relatively simple this makes it much more difficult to bruteforce.
I’ll run a quick nikto scan to see if it can give any more information about the server.
There is likely a separate admin page for PHP, but let’s try seeing what’s available via Samba first.
We get the name of the server as well as the specific Samba version (3.0.28a) with an anonymous login. No folder shares displayed this way, however. Doing a quick check on exploitDB there seem to be a handful of exploits around this version number so that’s something to note for later.
I’ll run dirbuster to see if I can find more directories on the webserver or possibly other php sites I’ve overlooked.
I don’t have to run it very long before I see a few new directories that nikto missed. /john/ seems to just redirect to the main log in page, navigating to /index/ gives us another login page with broken image link:
And /robert/ has a robert.php page which again just redirects back to index.php. I view the source just in case but it’s identical to the normal login site.
BUT what we do have is two very probably login IDs of “robert” and “john”.
These failed on the last Kioptrix boxes, but let’s try some SQLi tests on the main login screen: “admin” and “‘” for the password:
Fantastic, this could be vulnerable to attack.
Tried: Robert and…
‘ OR 1=1–
‘ OR 1=1#
And the second was a success. No need to do further complicated injection on the route to the password…it’s displayed there right away.
Let’s try the same thing for “john”.
That’s some good left-handed button mashing right there, robert. Let’s go ahead and try the login for both and see what comes up. Nevermind, all it does is display their password. So let’s try them in SSH instead?
Robert works but we’re stuck in what appears to be a very limited shell. I’ll try john just in case he is setup with different permissions.
Well at this point they appear identical. What can we do to try to escalate privileges from here? I try to go exploring but then…
There were hidden files in the current directory but without cat I couldn’t display them. No vi, nano, etc. either. There must be something I can do with the echo command, though. “echo cd ..” just gets me kicked off SSH and I have to sign in again…but there must be a way for me to bypass the limitations using it somehow.
Well, some googling for “limited shell echo” and we find this post by SANS: https://pen-testing.sans.org/blog/2012/06/06/escaping-restricted-linux-shells
The first option using python worked like a charm! I tried changing directories to /root/ fully expecting it not to work, but it did!
