This walk through assumes you worked through the previous post on the Billu_b0x and Seattle. Some items will not be explained that were explained in the previous posts.
Vulnhub Link: https://www.vulnhub.com/entry/zico2-1,210/
Tools Used:
VMware Workstation 12 Player
PuTTY or SSH client on host computer
Zico2 VM
Kali Linux Distro VM (Downloaded the VM edition from kali.org)
1 - dirbuster - Directory Buster
2 - python 2.7 (You could use 3)
3 - exploitdb
4 - Command Injection
5 - Firefox Web Browser
Lab
1. We are going to build a simple python program to be our port scanner this time. I am demonstrating building the script on the Kali VM. Below is a script that you can create:
To talk through the script. You are going to create a raw socket so you need to import the library of socket. Then an IP Address will be input to be scanned. An endless while loop will begin until you hit Ctrl ^C to exit. It will then ask you the port to check, connect to the port and if is it successful return that it is open.
2. Sometimes during a test you need to create a script to accomplish a task that a tool can not do, or you need to do a specific task to be quite on the wire instead of using a tool that can be very noisy. In the below example I am going to compare nmap with the python script.
3. If I use nmap to scan ports 21,22 and 80 of the zico2 virtual machine and I am going to capture the packets with wireshark listening on vmnet1. Notice the number of tcp packets:
Command: nmap -p 21,22,80 172.16.216.132
4. In the below example, I am going to run the python script that I called, "simple.py". I am going to capture the packets utilizing wireshark. The first command I am going to run is to make the python script executable. The second one is going to execute the python script.
Command: chmod 700 simple.py
Command: ./simple.py
5. You can see that the script functions very similar to nmap. Also, another point I would like to make is you need to know the tools that you use.
- Identify how noisy your tools are or are not.
- Know what you are sending across the wire in the packets.
- What information of your host is sent? Are you being incognito?
6. After recognizing the web page is available through the port scan. View the source code of the home page. A tool called a spider will follow each link that it finds. Notice the URL http://172.16.216.132/view.php?page=tools.html. By reading the URL the view.php page has a parameter called page that calls a file tools.html.
7. Notice that if it calls a page as we did in the Billu Box post, we could probably access any file. To do this we are going to test to see if the web application is vulnerable to directory traversal. Directory traversal is where you can call a file outside of the web servers root directory that is on the server. A test would be to see if /etc/passwd could be accessed.
URL: http://172.16.216.132/view.php?page=../../../../etc/passwd
To talk through this script you are going to import the library urllib2, have a URL input, add characters for directory traversal and then a specified full path to a filename that could be on the file system. If successful it will return the file. Here are a few filenames to try and access:
/etc/passwd (Notice the home directories of the users)
/etc/ssh/sshd_config (Helps you understand how the SSH Server is configured)
/home/zico/.bashrc (Validates the home directory exists)
/etc/crontab (Learn about scheduled jobs if they exist in this file)
Challenge: Build a list of files that could provide you useful information if you find a future directory traversal vulnerability.
Challenge: Use Zap or Burp proxy to fuzz the list of files that you found.
Challenge: Add to the python script the ability to save the files that are collected.
9. With the above gathering of the files, notice that these would be through a GET request. The filename that you are calling through directory traversal would be in an apache2 log file.
10. Next, use a directory buster and identify the pages that are available. Reference previous posts to conduct this.
11. We are going to evaluate the directory of dbadmin because it sounds interesting. After browsing to that directory you find that the browser lists the files in the directory.
12. Listing of the files inside of a directory should not be allowed. You should configure the directories permissions correctly to not display the files, however most of time developers will place an index.php or index.html file that is empty in every directory. This will present a blank page if the directory is called due to the Apache web server calling and looking for an index.php or index.html file. Test this, don't make assumptions that it works.
13. You can click on the file "test_db.php" and it brings up the following image:
14. The first thing I would do is google the tool displayed on the web site, version and then follow it with "exploit". As shown below in the google search.
16. Before we use this exploit that was found, on Kali is an up-to-date copy of this online exploit-db based on the last time you updated Kali. You can navigate to it by going to /usr/share/exploitdb/.
17. Then you can go to that directory and use a tool called searchsploit to search for a keyword related to an exploit. Why would you want an offline cache of these exploits? Sometimes as a penetration tester you do not have internet access to browse the exploits or what you browse will be filtered preventing you from downloading the exploits. You want to try and not create too many logs from the tools that you are using.
Command: ./searchsploit phplite
18. For the first exploit you can browse to /usr/share/exploitdb/platforms/php/webapps/24044.txt and cat it to the screen. After reading about the exploit try and follow and do what it says.
19. First of all we need to get past the password screen, so we can create the database. Try some common passwords that you know and see if you can get in. You should identify the password quickly.
20. With the above access create a new database called, "test_info". If you did it correctly you should see test_info underneath the Change Databases section.
21. Following the published information about the exploit on exploitdb, click on the database of test_info that you created, then select rename database, add the .php extension at the end and then click on rename.
22. Then click on structure and create a table called pages with 1 field.
23. Then I created a field called my, with type TEXT (This is important), and then I inserted a default value of text. Click create. Then click "return" on the next page.
24. Click on pages, under name. This selects the table, and takes you to the next page. Then click on "Click here" to insert rows.
--- Next Page ---
25. Then it asks you for the value that you would like to insert for the first row. For this value type in the following:
Value: <?php system("whoami"); ?>
26. Then click insert. But before we move on let's recap what we have done. We renamed or called the database test_info.php. Created a table called pages. Then we inserted a row with some php code. The php code when executed will run a system command of "whoami". The command will return the user that is running the command.
27. How do we get the web server to execute the value in the table pages, in the database test_info.php, and located at /usr/databases/test_info.php. Earlier we created a directory traversal script that could be used to execute the command by calling the test_info.php file.
28. Let's modify/create a new script to be more specific to the output of that file. I took away the prompts, statically set the url and readFile values. Then I modified the while loop to if I click "y" to refresh it will return the output for me.
29. Below is the output of the script if it was created successfully. I ran the script once before I inserted the row above into the table that had the command of whoami. Then I refreshed the output to see the results of the "whoami" command.
30. Notice above the output of the interpreted php code that is inside the value of the table in the sqllite database displays "www-data". Now we could go back and modify this php code to execute additional commands. You can also chain commands together and separate them with a semi-colon.
31. You now have command execution through a chain of vulnerabilities. The first vulnerability is a directory traversal. Then a second vulnerability is being able to rename the database to have a php extension that can be interpreted by the web server if called, then the ability to input php code into a value in the database.
32. To complete this challenge you need to get root on the box. The walkthrough that is currently posted is posted here. He utilizes the same chain of vulnerabilities, then uses metasploit to get a meterpreter shell. Work through how he does it.
Challenge: Go back through and document how you could prevent these vulnerabilities. Try and conduct the changes. Without the directory traversal are there other vulnerabilities that could be exploited?
Enjoy!
No comments:
Post a Comment