PENETRATION TEST REPORT – Pentest.id
Name: Fauzan Athallah Arief & Naman Vohra
Binusian ID : 2201798326 & 2201798420
Class: L4BC-LEC
Course Name: Ethical Hacking and Penetration Testing
Course Code: COMP6210
Lecturer: Andreas Kurniawan
Video Links :
Overview
This penetration testing is mainly conducted using tools in Kali Linux and other techniques that are taught by the lecturer in the ethical hacking class. Gaining as much information as possible is one of the objectives from the final project, but accessing the admin and or the server is the main goal for this penetration testing. We conducted the penetration testing of the target website and documented the findings and actions from the test.
Summary Of Findings:
In performing a detailed application penetration study against https://pentest.id/ Web application, we as Binus Students are assigned to identify the site’s vulnerabilities but overall found the application to be built around a solid security model.
Throughout this report, we provided brief descriptions of the various types of vulnerabilities found while conducting penetration testing.
3.1 Potential SQL Injection
SQL Injection is an attack in which malicious SQL queries are inserted into an application through the client’s input data. If successful, the attacker can perform harmful database operations such as retrieving sensitive information from the database, manipulating its data, etc.
One of the vulnerabilities is “$wpdb->prepare() potential SQL Injection”. It means that SQL injection may happen through plugins and themes.
3.2 Cross-site Scripting (XSS)
This website has a list of XSS vulnerabilities. Before discussing each type of the XSS vulnerabilities listed in the above screenshot, let’s first understand what XSS is. XSS is an injection attack that occurs from the client-side. This vulnerability allows the attacker to inject harmful code in a Web application. Next, the attacker needs to wait for the user, who is the victim, to visit the website so that the execution of the malicious injected script takes place in the victim’s browser. Usually, the script used is JavaScript as it is essential for Web development. We will now look at some of the possible negative impacts which XSS can lay on the users. Using this script, the attacker can access the user’s cookies which contain session tokens. The session token can then be used by the attacker to perform unauthorized actions. Moreover, JavaScript can utilize HTML5 APIs which can access a user’s microphone, files, and even expose the victim’s geolocation.
Now, let’s take a look at the above vulnerabilities. The first one is “Authenticated Cross-site Scripting in Customizer”. This vulnerability indicates that the navigation section of Customizer makes the website prone to executions of malicious JavaScript codes. As the name of the vulnerability implies, this vulnerability can be exploited by authenticated users to harm other users. The second one is “Cross-Site Scripting in wp-object-cache”. It implies that the cache key was not validated or encoded by WordPress’ object cache, which caches data from the database. It leaves an opportunity for the attacker to inject his own malicious key, which if exposed in a third-party plugin, could lead to XSS. Thirdly, there is “Authenticated Cross-Site Scripting In File Uploads” which means that authenticated users can upload files consisting of utf8 characters to execute JavaScript.
3.3 Retrieved the MX Record
Using a tool called “CloudFail”, one could obtain the IP addresses of a website’s subdomains. Moreover, the network on which a website is running on is exposed. In this case, the server is Cloudflare.
In the first screenshot, we can see the MX record which specifies the server handling mail activities for the domain. By knowing the mail server’s IP and utilizing WhoIs tool, sensitive information such as name, address, and telephone number of the concerned (?) person or organization can be retrieved.
3.4 National Vulnerability Database
The National Vulnerability Database (NVD) is the U.S. government repository of standards-based vulnerability management data represented using the Security Content Automation Protocol. This data enables the automation of vulnerability management, security measurement, and compliance. This vulnerability has been acknowledged worldwide and the problem is due to the version of the software that is used in the web application.
3.5 Robot.txt Found
Source: https://www.theregister.co.uk/2015/05/19/robotstxt/
(Robots.txt tells hackers the places you don’t want them to look, When you say ‘move along, nothing to see here’, the bad guys get interested). That was the headline regarding an article about robot.txt and why hackers get excited when they find it.
Based on what we found on the robot.txt is the path which directs us into the main admin server.
3.6 Server software and technology found
We have found all technology that is used in the Web Application and suffice to say that most of the vulnerability comes from this technology.
3.7 Insecure HTTP cookies
This vulnerability was found using https://pentest-tools.com/home, a web that deals with penetration testing through online methods. Pentest-Tools.com allows you to quickly discover and report vulnerabilities in websites and network infrastructures. We provide a set of powerful and tightly integrated penetration testing tools that enable you to perform easier, faster, and more effective pentest engagements.
3.8 List Of User(s) Found with Wpscan
With the help of WPScan and by typing ‘wpscan –url pentest.id –enumerate u’ in the Kali Linux’s terminal, we were able to find some information that is believed to be real users for the WordPress website which is pentest.id. Down below are the screenshot of the users found by WPScan.
3.9 Brute Force Attempt
We used the WPScan in Kali Linux to brute force, with an aim to find a matched password to the admin page using the command ‘wpscan –url https://pentest.id/ -U @apietz –P list2.txt’. Another password list utilized by our group is called rockyou.txt. It is an inbuilt password list which contains 14 million passwords.
After trying the first 10000 passwords, our group stopped the process as most of the passwords are weak and the possibility of gaining admin access is low. So, unfortunately, we could not get any password which matches the admin’s credentials.
Conclusion
Overall, we found the application under review to be relatively well designed and to be utilizing several solid security practices. As seen in the image below, the communication is secure as the website implements the HTTPs. One of the security protocols which may be utilized by HTTPs is SSL. When a client visits a website, its browser will request the web server to identify itself. The website responds by providing an SSL certificate which is used as a means to authenticate the identity of a web server. Next, the certificate will be “checked” by the client’s browser. If approved, the client will start sending its data to the server and most importantly, the information passed would be encrypted by the HTTPs. Thus, even if an attacker manages to “listen” to the communication between the client and the web server, he/she will receive encrypted data that can’t be understood by humans.
List of things that are Secure in the Website
Next, our group attempted to penetrate the website by implementing the brute force method. But, as seen in section 3.9, we failed to do so. This implies that a simple method like brute force cannot be used to gain user/admin access.