Walkthrough Acid server

Mission : Get the root flag on `Acid` which is a deliberately vulnerable virtual machine hosted at https://www.vulnhub.com/. The virtual machine can be downloaded at https://www.vulnhub.com/entry/acid-server,125/. I quickly loaded up the virtual machine into my VMWare Player and i was good to go !

Detailed Steps for getting root:

A nmap scan of the box reveals only one service running on a non default port. It seems that there is only this http service running on the box.



Upon accessing the http service on the port 33447 we are presented with a "Welcome to the world of acid" webpage. 

Acid Page

Our first instinct it to always view the source code of the page to see if there is anything interesting and sure enough we are lucky as in this case we find a hidden comment - "643239334c6d70775a773d3d". It seems that its in hex . We convert hex to ascii to get "d293LmpwZw==" . The == sign at the end tells us that its base64 encoded. We are quickly able to decode the string as wow.jpg. ! Lets see if we can use this image later.

We also see that the page title is "/Challenge" which tells us that such a folder may exist on the webserver. When we visit the /Challenge folder on the webserver we see a login page prompting for an email address and password. We cant do much now so we use dirbuster against the webserver. Our dirbuster tells us there are some interesting files and folders on the webserver. 

Dirbusting /Challenge directory

We also interact with the login page via the burp suite to understand better the way the form interacts with the backend webserver. We can see that the form converts the password into a hash using a api from the includes javascript files namely sha512.js and forms.js. We try to look into these files and see that these files are infact part of a php login system called "phpSecureLogin" https://github.com/peredurabefrog/phpSecureLogin. It seems that the project has been abandoned but we find that the github page (https://github.com/peredurabefrog/phpSecureLogin) lists default credentials (email : test@example.com Password: 6ZaxN2Vzm9NUJT2y ) built into the login system. We use it  and we are successfully able to bypass the login screen ! 

Login form showing the includes javascript files

Once we login we have a look at all the files that are listed by the dirbuster. When we view the cake.php we see that the page title changes to /Magic_Box hinting that there may be something with that name on the webserver. 

It seems that we dont have the permission to view the  /Challenge/Magic_Box directory but we run a dirbuster against it to see if it reveals anything. 

Dirbusting /Magic_Box directory

We are able to find a bunch on interesting files such as low.php, tails.php , command.php etc. It seems that command.php is a console that allows us to ping another IP. We suspect a command injection vulnerability here and hence besides providing a IP address we provide another command such as "id" with the assumption that the backend code will not sanitize the input and not limit execution to a single IP address command.

Command injection

Sure enough we can see that our code is being executed.

Once we can execute code on the server we attempt to get a reverse shell. We reference the reverse shell cheat sheet http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet and select the perl reverse shell after checking that nc though installed does not support the -e option. To be able to use the perl reverse shell we must url enocde it and also since the length of the IP address field is set to max 200 we need to intercept the request in burp before forwarding it to the webserver. 

Burp intercept

Sure enough we get our low priv shell !


Privilege Escalation : 
Escalating privileges on the box takes quite a long time. Once we have a low shell we peep into all the file present in the Challenge and Magic box directories. We see that the box is running a MySQL service and the file psl-config.php contains the database password. 



In the database we check the secure_login database to find a few users and their password hashes and password salts. We are able to crack the hashes ( saman & Vivek) but since the passwords are salted we wont be able to crack it. At this point we give up on the database. We slowly follow the priv escalation guide https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/ till we finally see an interesting file on the box via enumerating all the files for the user acid and user Vivek on the box. 



The pcap file is interesting and we download it and open it in wireshark. We guess that we should look into the TCP communication captured on the network interface and hence set the wireshark filter to the same. Then we follow the TCP stream to see the data exchanged in the session. And sure enough we get our next clue.

Looking at the message we guess the user saman password. Also always check if the user is in the sudoers list. This gives us root !

Walkthrough Vulnix

Mission : Get the root flag on `Pipe` which is a deliberately vulnerable virtual machine hosted at https://www.vulnhub.com/. The virtual machine can be downloaded at https://www.vulnhub.com/entry/hacklab-vulnix,48/. I quickly loaded up the virtual machine into my VMWare Player and i was good to go !

Detailed Steps for getting root:

A nmap scan of the box reveals a number of services running on the box such as ssh, smtp, finger, pop3, imap , rlogin , rexec, rshell and nfs. 


Our attention is drawn to a number of services which we would typically not see exposed such as finger, rlogin services and nfs.NFS protocol allows a user on a client system to access a folder on the network as if it were present locally. Poorly configured NFS services are known be exploitable.[ If we remember there is a exercise in Metaspoitable that deals excursively on attacking the NFS protocol for getting root]. Hence we go for this service and enumerate if we can mount a share locally. 

We see the the /home/vulnix directory  can be mounted and we mount it on our attacking box. However we are unable to see the contents of the directory as we keep getting a permission error. We get this error because we are root on our attacking machine and we are trying to access a non root owned directory on the target system. We guess that this is because the NFS /etc/exports file (https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-nfs-server-config-exports.html)  may have the root_squash permission turned on which squashes the permissions of the root client to the lowest user to prevent unauthorized alteration by a client on the nfs shared directory. In order to view the contents in the mounted directory we need to acess the nfs drive as a user with the same uid and guid as the vulnix user on the target box. Since we dont know the uid and guid of the vulnix user we do some further enumeration on the box. 

We see that the smtp service is running of the box. There exisits a metasploit auxilliary module that helps us enumerate all the valid users accounts on the smtp server. We use this module as follows 



The module has identified a number of user accounts on the box. The `user` account catches our attention. We guess that accounts maye be reused and use the finger service to determine if its possible to login to this box via the `user` account. 



Clearly an account called `user` can be used to login to the box. With no other information available we attempt to bruteforce the ssh service with this user account. After a few minutes we are able to bruteforce successfully ! ! The credentials for this account are user:letmein . Now we can login to the box as `user`. 

Once we login we see another user called vulnix. We take note of the uid and giud of this user (2008 in both case). We shall attempt to create a user with the same uid and guid on our client box. Hopefully this will solve out permissions problem and we will be able to elevate our priv to vulnix . 



Now on the attacking box we create a testuser with the same uid and guid .


Now after we mount the /home/vulnix directory we no  longer see the permission problem !

Walkthrough SecOS: 1

Mission : Get the root flag on `Pipe` which is a deliberately vulnerable virtual machine hosted at https://www.vulnhub.com/. The virtual machine can be downloaded at https://www.vulnhub.com/entry/secos-1,88/. I quickly loaded up the virtual machine into my VMWare Player and i was good to go !

Detailed Steps for getting root:

I ran a quick nmap scan to identify the Ip address of the Pipe VM. I use `host-only` networking for both my Pipe Vm and Kali box.


We identify the IP address of the new VM as 192.168.28.138. 

A nmap scan of the box shows that the box is running a http service on port 8081 and a ssh service on 22.



We run nikto againts the webserver but dont find anything of much interest. We then dirbust the webserver which reveals a bunch of interesting directories that we should look into.

It seems that the vulnerable application allows us to create a user account and have a look at the various pages on the website. We see that among other things there seems to be 3 users on the box one of whom is the administrator. Also there is a way to send messages to the admin. 

We also see an About page that tells us that the site has been developed using Node.js and MangoDB. At this point we try the an authentication bypass seen in Node.js and MangoDB systems. A good discussion of it is here  : Hacking Node.js and MangoDB http://blog.websecurify.com/2014/08/hacking-nodejs-and-mongodb.html: . It seems that the box is not vulnerable to this bypass. We begin to observer the webapp more closely and find that the login page source code has comment which is a hint. 

We have a look at the /hint page and its source code which reveals that we should launch a CSRF kinda attack on the administrator. 

The hint page tells us that the administrator will visit any site running on 127.0.0.1 if he is asked to do so. The hint is clear that we should feed a URL to the administrator to see. This can be done via the messaging feature of the webapp which allows us the send messages to the administrator. Relooking at the webapp we see that there is a feature to change the password. We decicde to trick the admin into changing his password to our specified one. For this we create a HTML page with hidden inputs and POST the data to the /change-password . 



We know ask the admin to view this page by sending him a message . 

We hope that when the admin visits this page his password will get reset and we can login. Well after a few minutes we try logging in as admin and we see that our little trick has worked ! 

We login to the admins message board and see that he has a message from a user 'pirate` who claims to have cracked his password.

We try ssh'ing into the box with these credentials and we are immediately logged in  ! 

Once we login we see that there a bunch of interesting files in the users home directory. 



If we do a quick directory listing 2 things stand out. i) There is an internalServer running as root on the box ii) there is a additional ping.ejs file which is not normally visible via the public facing web interface. 

We look at the contents of both the internerlServer and ping.ejs files.


It seems that besides the public facing webapp there is an additonal server running on the box on port 9000. This server provides a Ping capability for the admin to maybe ping other systems. When we look at the code for the ping service we see that the exec api is called with the user provided IP address without any input checks. We can inject code here as the application does not sanitize the input data. 

We can launch the command injection both via the web browser or the command line. Let see both approaches . 

a) Command line : We can use wget or curl to post data to the internal server and inject our code in the post request. 



Here we send a post request with a ip address =1 and inject our 'id' command along with the request .

Similarly we can use curl to post data as well 



b) Web browser : In order to be able to see the internal webapp on our attacking machine we use a ssh reverse port forwarding technique using the ssh -L parameter. Via this method we make the port 9000 of our victim machine available on our kali machine at port 4545. 



Now we can access the port 9000 of the inernal web application