1. nmap scan for the ip address. Once discovered, do a full scan for the available ports.
2. We have several ports open on the server. Looks like we have HTTP, SSH, NFS being presented. Well checking the port services with amap, I decided to look at port 80 to see what kind of web app was presented.
3. Possible users for the web app. This could be useful if I have to bruteforce for authentication.
4. Time for some directory enumeration.
5. Looks like there is a admin page and a /lib/ dir I should look at.
6. I captured the authentication POST process of the web app using burp suite so I could later use it for sqlmap (sqlmap -r "file". However, it did not get me very far. Then, I used cewl to possible get a dictionary file to bruteforce the login page. Nope. Nothing. I used some info I got from the NFS share but more on that later.
7. Now, let's look at what is available on the nfs share. It worth trying to see if there is an available NFS share if you see port 2049 open and port 111.
8. Ok. Now this was interesting. I connected to the share. I saw that it had a .ssh file. I was hoping to possible get keys from it but I did not have permission. I had to do some research and you could possible trick the server by using version 3 of NFS which had less security. You could do this creating an identical user with the same ID. However, I already had that ID in use on my box. Well, that is what my Kali Linux VM is for. I just mounted it there and added the user/ID.
9. Now, I am able to access the SSH keys. I copied them on both my main box and the Kali linux VM.
10. I also decoded the flag on https://www.asciitohex.com/.
11. Ok. Now it is time to try to connect using the keys. Of course, password protected. Well, we have a bruteforce for that. I usually just use PD (phrasen|drescher).
12. Looks like the password is sheep. Dang, karrrrllllllll.
13. Anyway, we are able to connect to ssh but we are put into a restricted shell. Well we already know we can try to get out of that.
However, the usual bash --noprofile does not work. Luckily, using the /bin/sh option does work.
14. Looked around to see the usual stuff. The kernel was at a pretty good level. I went to check for sticky bits and saw /bin/cp.
15. NOW, this is where I took a detour. I started to look at the web files. I found the hardcoded credentials from the source code of the main page.
16. This looks like I could use LFI to read files on the server from the browser if I were able to login and browse to cms.php
17. Ok. The credentials work for heather. I am able to login.
18. Ahh. I am able to read /etc/passwd by browsing to:
20. As the Rock would say, FOCUS! I see the sticky bit on 'cp' so it can be executed as if a user was root. I looked up possible techniques on:
21. I just have to create a salted hash to a passwd file and copy it to the machines /etc/passwd. I used the same kali box for this trick.
22. The file is created. I just have to transfer it to the machine. I just used wget to copy it over. Then, I just did a quick double check to make sure the changes were there.
23. Go time. Use the cp command and boom. I AM
24. Got the flag and used the ascii site again to find out it was "hackergod".