Seattle VM Walkthrough

We hosted the VM in virtual box and opened the system's IP from our browser, and we found a web application running on it.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

This web application is running on a virtual machine; it's designed to simulate a simple E-Commerce style website which is purposely vulnerable to some well know security issues commonly seen in web applications. Currently, this web app is vulnerable to the following vulnerabilities:

• SQL Injection (Error-based)
• SQL Injection (Blind)
• Reflected Cross-Site Scripting
• Stored Cross-Site Scripting
• Username Enumeration
• Path Traversal
• Exposed phpinfo()
• Exposed Administrative Interface
• Weak Admin Credentials
• Insecure Direct-Object Reference

We will look for more issues apart from the listed ones.

SQL Injection(Error-based): For looking SQL injection we start from very basic discovery by adding single quotes in every parameter. We noticed that in the login page if we are adding a single quote in username parameter it throws a SQL error message which was a very obvious sign of error based SQL injection.

We took this post request and sent it to SQLmap for dumping the database by using the following command: Sqlmap.py –r r.txt –dbs –dbms=Mysql

As can be seen above SQLmap has identified 4 databases.

After running SQLmap, we successfully dumped the tblMembers table from seattle database.

As can be seen above the Admin password is not hashed, and we were able to login into the application by using this password.

SQL Injection (Blind): The blind SQL injection was actually time-based injection. We found this vulnerability on the same login post request where we found the error based injection. The password parameter was not throwing any SQL error messages in the response, but it was reacting when we were sending SLEEP queries to the server. By crafting a SLEEP based payload, we were able to bypass the login screen which means it was vulnerable to SQL injection.

We ran SQLmap by using the following command: sqlmap.py -r r.txt --dbs --dbms=Mysql --level=5 --user-agent="random"

As can be seen above SQLmap was able to detect the time-based SQL injection.

Reflected Cross-SiteScripting: For looking XSS issues, we have first to find out the areas in the application where it takes inputs values or parameter values which reflect in the HTML response. After logging into the application we found a blog page where it was showing all blog posts published by Admin user in the URL there was an author parameter which holds an integer value of 1 that id value is associated with Admin username we just simply added an XSS script in the author parameter and it executed in the browser.

Thus the script is not getting saved in the database so it will execute only once.

Stored Cross-SiteScripting: For looking stored XSS the concept is same as reflected XSS we have to look for areas where application is accepting user input values, and then it's showing the values in response, but in the stored XSS it could happen that application asks for user input in different page and the saved results are showing on different pages. In this application in the blog area, there is an option of the blog post so we added our same JavaScript in the blog post area and submitted the form.

When we submitted the blog post, the script doesn't get executed on the same page because the blog post was published on a different page, so when we visited the post area our submitted script executed on that page.

User Enumeration: The use of user enumeration is to find out the correct usernames from the application database by analyzing the correct and incorrect error messages on the login page.

As can be seen in below image when we supplied a wrong username and password the application throws a message that "invalid username."

The error message is too obvious that it's indicating clearly that this username is wrong and it doesn't exist in the database. While browsing the application in blog area, we found the admin username.

We tried login by using the admin username now this time the application throws a different message that "invalid password" it means this username is valid and it exists in the database.

Path Traversal: A path traversal vulnerability allows an attacker to access files on your web server to which they should not have access. They do this by tricking either the web server or the web application running on it into returning files that exist outside of the web root folder. The application has a functionality of downloading pdf brochure from the site.

By sending the ../ characters in item parameter has caused include() to traverse to the root directory, and then include the Unix password file /etc/passwd.

Exposed phpinfo: The official PHP documentation makes a recommendation to create a file that calls the phpinfo() function to test that the PHP installation was successful; it is a common mistake to forget to remove this file. The information leaked by the phpinfo() function includes physical paths, environment variables, and the full PHP configuration settings. For finding this file we Dirbuster tool which is a directory bruteforcer.

We found a file called info.php we opened the file, and we found the PHPinfo page.

Exposed Administrative Interface: In some application, we found that admin section is accessible without login or by using a normal user session. In this application also we found the admin directory from the dirbuster tool but when we tried to access admin.phpfile it was redirecting to login page.

We logged into the application and then tried to open the admin.php file, and we were able to view the admin functionalities on that page.

Weak Admin Credentials: We have already found the admin credential by exploiting the SQL injection the password Assassin1 which is a dictionary based password, and it can be brute forced.

Insecure Direct Object References: Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability, attackers can bypass authorization and access resources in the system directly, for example, database records or files. In this application, the impact of this vulnerability is not severe because it's leaking only usernames. In the blog post are when we are fuzzing the author parameter it will reveal all usernames which exist in the database since there is only one user Admin is available on the application so it's showing only admin's username.

Apart from the listed vulnerability there are some other medium, and low-risk vulnerabilities are there such as user login credential is transmitted in plain text over HTTP request which will result to MITM attack, user session cookie is static which can lead to account hijack, CAPTCHA or rate limiting is not implemented on login page which will results in Bruteforce attack, Admin directory is browsable, session cookie is not protected from HttpOnly flag.

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

Reference: https://www.gracefulsecurity.com/vulnvm/