This walk through assumes you worked through the previous post on the Billu_b0x. Some items will not be explained that were explained in the Billu_b0x post.
Vulnhub Link: https://www.vulnhub.com/entry/seattle-v03,145/
Tools Used:
VMware Workstation 12 Player
PuTTY or SSH client on host computer
Seattle 0.0.3 VM
Kali Linux Distro VM (Downloaded the VM edition from kali.org)
1 - nc - netcat
2 - dirbuster - Directory Buster
3 - OWASP Zap
4 - Firefox Web Browser
1. nc or netcat is considered to be the TCP/IP swiss army knife. nc can be used to also scan for open ports. The below command was used to scan for ports 76-80 to identify if they are open or closed. There are different versions of netcat. The one I am using is on the latest version of Kali.
Command: nc -vz -n -w 1 172.16.216.131 76-80
2. I am going to use nc now to pull the header that the web server returns. To do this we are going run the following command. Then the web server is waiting for the request to be issued, so we type and hit enter at the end of the string "GET / HTTP/1.0". If the web server supports the header it will return the home page. You should disable HTTP/1.0 on a production server.
Command: nc 172.16.216.131 80
String: GET / HTTP/1.0
3. Below I am going to use nc to send another request but using HTTP/1.1. The HTTP/1.1 protocol only requires the request to have a method and a host parameter. Being able to see the headers returned by the web server you can see the version of the web server that is running and other information that could be utilized to learn about the vulnerabilities that a server can have. Notice a cookie is returned.
Command: nc 172.16.216.131 80
String: GET / HTTP/1.1
String: Host: test.local.anything
4. From the headers above you can see the web server version is Apache 2.4.16, running Fedora (probably), has the OpenSSL 1.0.2d-fips libraries loaded, and PHP 5.6.14 running. Use Google to find any related exploits or vulnerabilities.
5. I am going to use a directory buster to find pages but instead of using dirb I am going to use a similar tool called OWASP DirBuster. With this tool you can specify the URL, how many threads to spend on the task, the character set, and the min and max length if you brute-force, and then additional options. The URL Fuzz is an interesting option.
6.After you click start you will see the results that are returned and the pages that are found. If you go into the options of this tool you can add additional extensions to scan, change the agent that is used, send the requests through a proxy and more... With the list of pages you can start visiting them to see the content.
7. I am going to look closer at the login.php page. If I have permission to test the login page I will normally try as a username and password a variety of common combinations like, admin:admin, admin:password, administrator:password, etc. After trying a few combinations and making the username look like an email address it comes back and states, "Invalid username". This is not good practice cause a miscreant can harvest usernames from your site.
9. After going back to the My Account page let's try and use that email address. After testing the email address the message now states "Invalid Password" so we know the email address is an account associated with a password in the database. A login page should state something like you entered an invalid username and/or password instead of the way it is.
10. Now that we know the email address of a user we can proceed to brute-force the password of the site. A simple login page should have a method to slow down or block a brute-force attack. Often times to slow down such an attack a catcha may be utilized.
11. We are going to use another proxy called OWASP Zed Attack Proxy or ZAP. I am using ssh x11 forwarding and launching ZAP.
Command: owasp-zap
12. Then I am using firefox to go through the proxy as I access the site. Then I browsed to the login page and inserted the email address and an incorrect password. Below is what you should see.
13. If you have selected "History" in the bottom left and find the line that is for the POST request. You can see in the right top screen shows the POST request sent to the web server. It has the headers showing the User Agent, this identifies the OS, browser version and other items associated with the browser. This can assist in identifying vulnerabilities. If a miscreant has control of this information, they can customize the page to exploit vulnerabilities associated with the OS, browser or plugins.
14. The other important item to point out. A POST request will have the parameters passed to the web server in the body of the request. A GET request will have the parameters in the URL. If logging is enabled the URL and what was passed by a GET request will be in the logs. By default, POST requests will not be logged in the apache2 access logs. Search and identify how you could log POST requests.
15. One item you can do with a web proxy is fuzz a parameter. I am interested in fuzzing the password for the user account. Fuzzing is a method to insert random information, patterns, hex, unicode, or any character necessary to see if we can identify a state change (crash or behavior), different response code, change in size of the response or time it takes to execute. To fuzz the password parameter highlight the password that was a guess in the password field, right-click on it and then select "Fuzz". (This also can be done in Burp Suite, a tool used in the previous post.)
16. The Fuzzer window comes up. Notice you can select multiple fuzz locations, color code them and select different payloads for each respective ones. In this example, the color code is green, I then select Payloads..., then I click on Add, select File, and then I selected the rockyou wordlist that can be found in /usr/share/wordlists/rockyou.txt after you gunzip it. (You may receive an error due to trying to use that large or a wordlist.)
Command: gunzip /usr/share/wordlists/rockyou.txt.gz
17. After the payload is selected and you click out of the windows to keep the selections you will see a selection to start fuzzer. I customized the rockyou wordlist to only be a list of about 1,500 words with the correct password in the middle.
Notice as a payload is inserted and sent as a web request you receive the meta-data collected from the responses. The code 302, the round trip time (RTT), size of the response header and then the size of the body.
18. After clicking on the size of the response header you can see a variation. The largest one is 356 bytes where the rest are 298 bytes. Something changed with the payload of Assassin1 as the password. This probably means that this is the password for the email that we have. Sure enough, it works!
19. After a successful login you should see the ability to create a post or update an account.
20. With being able to post to the blog you can insert a title and content. The information that you put in is not validated that it only contains characters that are necessary. Due to allowing the following characters to be posted: < > ( ) /, you can cause stored cross site scripting or XSS. Stored XSS is where the value is being stored in a database to then be returned to a page that is requested by a user. To initially test the XSS I inserted the following into a post.
22. Stored XSS can be utilized to gather cookies from a site and send them to a miscreant. The cookies could allow the miscreant to login as a victim without needing a username and password. As shown in the video below an attacker sent a phishing email to a victim. After the victim clicks on the link in the phishing email the attacker receives the cookies from the browser due to XSS. Then the attacker was able to login.
XSS is thwarted when user input is validated, scrubbed and/or encoded appropriately. Remember also to validate, scrub and/or decode appropriately for information that is output. OWASP has released libraries that can be implemented to assist with input validation and output validation.
Challenge: I would challenge you to use the VM and your own lab and recreate what you see in the video with the stealing the sessionID and then utilizing it to login from a separate browser.
2nd Challenge: Find XSS in another page on this VM.
This VM has many vulnerabilities. Can you get root? On the vulnhub page for this VM you can follow other walk through's that will take you to getting root on the box.
No comments:
Post a Comment