Black-box Penetration Test of a PHP Web Application
Executive summary
A black box penetration test was performed on Astley car rentals web application. The tested application provides car rental service through which clients/users book for cars online. The aim of this pen test is to evaluate the observed application’s defensive posture from a security perspective. The methodology used in this pen test alludes to industry standard methodologies such as Open Source Security Testing Methodology Manual (OSSSTMM), Open Web Application Security Project (OWASP) and Penetration Testing Executive Standard (PTES) to effectively identify security vulnerabilities through utilizing active exploitation techniques. Almost every single page in the tested web application revealed several critical vulnerabilities. Through exploiting these vulnerabilities, the tester was able to successfully compromise the web application. One particular vulnerability allowed administrative (privilege) access to the web server that is used to host the application. With this privilege access, the all customer and user information were accessed by the tester. The detailed findings of the vulnerabilities can be found later in this report. Remedial advice for countermeasures is also provided to help the company harden their environment.
Overview of Methodology
In order to effectively evaluate and identify security flaws in the application, a methodology is designed that is believed to best suit this assessment (Figure 1). The methodology, however, alludes to industry standard and touched on the three pillars of web-based security. Details steps of the methodology are outlined below.
Mapping the Application
The penetration test started with a mapping the target’s scope by navigating through all possible links using Burp Suite’s proxy option (Figure 2). This process enabled Burp Suite to automatically create a site map to discover all available URLs. All the discovered URLs were visited to confirm their existence.
The automatic spider feature in Burp Suite almost immediately found several directories some of which when visited, were discovered to be contain several critical information that are publicly accessible on the application. One particularly directory /admin/ contained some sensitive information like the config.php file and JavaScript files depicted in figure 5 & 6. Figure 4 to 6 depicts some of the information the /admin/ directory contained.
The mapping process was taken a step further where an automated directory brute-force scanning tool called Dirb was used. Dirb was used simultaneously along with Burp Suite to make sure that no directories were missed. The result from Dirb showed interesting URLs and these were also visited to confirm that they exist (Figure 7).
From the Dirb result, the /site/ directory struck interest because it looked like it contained additional sites, when visited, there were no additional site. However, it listed a file named ‘sqlcm.bak’ (Figure 8). The sqlcm.bak file was access and it contained code that looked like a possible filtering scheme for a login function (Figure 9) and this was examined later during the injection attack phase. All of the discovered URLs were probed to uncover any hidden content.
The /assets/ directory contained information such as JavaScript file and were observed to be freely accessible. The files were examined later in the report (Figure 10).
Visiting the /phpMyAdmin/, an error message “access forbidden” was returned. However, the error message revealed the version of the PHP and HTTP server. (figure 11).
Robot.txt file is generally used to prevent search engine from indexing certain pages of a wesite (figure 12). This file was accessed and it seemed to contain a file named “company-account”. When the company-account file was opened, it revealed very critical information (finantial records) that was publically accessible (figure 13).
In the index.php page, it was observed that if a vehicle ID that did not exist was used, the page still returned a vehicle along with a booking option. Upon inspecting the HTML code, it revealed that the URL for the administrative vehicle management dashboard was freely accessible for this index.php page (figure 14).
Following this, each HTML page was probed to discover any useful information including comments. The vehicle-details.php source code showed a subdirectory within the same parent directory as the admin (figure 16). By visiting the directory with in the URL, it would be trivial to end up in the admin dashboard.
Still under the vehicle-details.php source code page, an email address and telephone number was discovered. This could be use for social engineering purpose (figure 17).
Test for Technology used in the application
After the web application was successful mapped, the tester now proceeds to scan the web application using Nikto to identify vulnerabilities and to also discover any hidden directories that the mapping process might have missed. Some vulnerabilities were identified and are analyzed in preceding sections in this report. Nikto was also used to identify technologies that are used by the tested web application. From the Nikto scan, it was discovered that underlying technology such as Apache and PHP were used to power the website and were further verified to ensure their existence (figure 18). The Nikto scan also identified an OpenSSL installation but none of the web pages seemed to be using HTTPS.
Testing Client-side control
Control over user Input
The web application had no password validation in any on the authentication pages. Any number of characters could be set as password. For the provided user account, the password was successfully changed from a seven-character password “hacklab” to a three-character password “the” (Figure 20). After changing the password, login was tested to confirm the new password (Figure 21).
The application also allowed a single character password to be set. Next a password longer then the industry recommended 14-cahracters password was tested and it was accepted by the application without the application breaking or outputting an error message.
Authentication Mechanism Test
Username enumeration Test
All available login forms in the application was tested in an effort to enumerate valid usernames. It was observed that when using a correct/valid username and wrong password, the admin login form returned a neutral error message that did not hint whether the username or password was incorrect.
However, the same login form outputs a more specific error when an invalid username was used (Figure 20). This indicate that the username is vulnerable to brute force attack.
The profile.php page also allowed user enumeration by displaying in the pop-up when an existing username was used. However, the form had to be submitted first as there was no real-time checking of existing user account.
Password Testing
The password for the provided user account was tested to verify the integrity of the login functionality. To achieve this, a hard-to-guess 14-character password “P@$$w0rd123456” was set. Different variations of the set password were tested to see if the mechanism was case sensitive or if it only tries to match some of the characters. ‘P@$$word23456’ and ‘p@$$Word123456’ were tested but logging in failed.
Test password logout policy
A possible logout policy was tested on the provided user account. A list of username and password were tried to login to the account using Burp Suite. It was possible for Burp Suite to keep trying combination of usernames and passwords without any kind of lockout or delay. This was done on both the admin login and the regular login. The total of 240 attempts were made (Figure 25).
Session Management Mechanisms Test
Checking tokens to sessions
The login page for the provided user account was tested to know if concurrent logins are permitted by the application. It was observed that two browsers could be used to login at the simultaneously with the user same user account and each browser could be used for independent activity (Figure 26).
Secret Cookie token Testing
When logging in, a cookie named “SecretCookie” it was observed in the Get request in Burp Suite. This cookie was then further examined using CyberChef to know if it contains any valuable information or user credentials. Unfortunately, CyberChef could not detect any user credential. It could only deduce that the cookie was encoded into Based64 and then hexdump (Figure 27). However, when attempting to decode the cookie using CyberChef, it returned gibberish values (Figure 28).
Test for unsecure transmission of credentials
It was discovered that the user’s credentials when logging in are submitted in plain text. The admin login page and the provided account login page were tested and each transmitted credential in clear text in the POST request.
Test Input Validation
Testing for SQL injection
All pages with login forms and where parameters are transmitted as GET requests in the web application were tested for SQL injection vulnerability. None of the login forms displayed error or hint of SQL injection attack when tested with the string ‘ or 1=1 — (figure 31). However, using SQL map, it was discovered that SQL injection vulnerability exits in admin login page.
Once the SQL injection vulnerability was confirmed, a systematic process of enumerating the database, tables and columns was done using SQLmap tool. And at last, the users table were dumped (figure 32). The hashing algorithm uses MD5sum, therefore every password was easily cracked because they were very weak.
Some SQL commands that were used to enumerate and dump information in the database:
sqlmap -r /Desktop/Pilo.txt — dbms=MySQL — dbs
sqlmap -r /Desktop/Pilo.txt — dbms=MySQL -D shop -T users — columns — dump
sqlmap -r /Desktop/Pilo.txt — dbms=MySQL -D shop -T tbbrands — columns –dump
Test for Cross Site Scripting
The same pages that were tested for SQL injection were also tested of XSS. The form fields and dynamic URLs were injected with the following scripts to see if the embedded string will pop-up. “<script>alert(‘1’)”</script>. It was observed that XSS vulnerability was present on the vehicle-details.php page.
The XSS vulnerabilities could be exploited to steal the login cookie from logged in users, since it has the propensity to reveal user credentials. The messaging function was also tested for stored XSS by sending the exploit string as a message and then viewing the administrator’s inbox which was accessible without authentication. However, no new messages were present, so it seemed that the weaponized message was never sent to the server.
File Inclusion Testing On the profile.php page there is an option for register users to change picture. This functionality was tested for any file upload vulnerabilities. To achieve this, a php backdoor was created using weevely (figure 35) and uploaded to the application. However, the upload was rejected, because the application only accepts files with PNG and JPEG extensions (Figure 36). The backdoor was renamed from .php to .jpeg and reuploaded. This time it bypassed the filter and was accepted by the application.
Figure 38 shows the backdoor was successfully uploaded in the picture directory. After this, weevely was used to connect to the backdoor (figure 39)
Testing for web server vulnerabilities
Test web server To identify vulnerability in the server, a network mapper (Nmap) and Nikto scan was done on TCP/UDP ports to discover all running services and versions (figure 40). Full details of the scans can be seen in appendix A.
An FTP installation was found and what seemed like a command shell. However, the specific FTP version had no public exploits available and did not allow anonymous connections, and Netcat would not connect to the shell. OpenSSL version 1.0.2n was also discovered on the server but again there was no public exploit available for it. So, it could not be exploited.
Testing for Default Content
While analyzing the Nikto scan log, couple of URLs were discovered and they turned out to be PHP Easter eggs. These pages did not disclose and sensitive information that could be used by an attacker (figure 43).
Test for bugs in web server
The web server was scan for vulnerabilities using OpenVAS scanners. And reported that the php.info file showed sensitive information like the installation path hence, indicating a vulnerability. The scan also detected a possible SQL injection vulnerability that was exploited in section 2.6.1.
General Discussion
Astley car rental web application is not currently deployed in a manner that corresponds with best security guidelines for an application or web server that should be facing the internet. This pen test was vastly important to bring to the attention of the company how risky is it to be operating an application with such security defects. The vulnerabilities identified can be used in conjunction with other vulnerabilities to cause nefarious effect to the organization. If not remediated as advice, it can result in severe financial and reputational ramifications for the company. Almost every login form, input parameters, and databases were subjectable to some sort of SQL injection, Cross Site Scripting vulnerabilities which can lead to exposure of critical information or worse, compromise of the environment. A professional advice will be to cease all operations, take down the web application until everything is fixed. It is worth mentioning at this point that update/upgrade of services and technologies in the environment should be considered. The Nikto scan, shows that most services installed on the server hosting the application are outdated.
The goals of this penetration test were to:
Evaluate the defensive posture of Astley car rental web application from a security perspective
- Identify potential vulnerabilities through active exploitation techniques
• Determine the impact of the vulnerabilities
- Provide remedial advice for their mitigation
These aims were met as the tester effectively evaluated the tested web application from black hat hacker perspective, identify and exploited vulnerabilities where necessary and providing remedial advice their mitigation. A simple attack against Astley car rental web application may result in a complete compromise of the environment. Majority of the security issues that were leveraged, resulted to disclosure of very critical information. It is important to note here that many of the security issues that led to the collapse of the entire application is a direct consequence of inadequate or non-existent input validation, data exposure and misconfigurations. Appropriate efforts should be undertaken to mitigate the effect of cascading security failures throughout the tested environment.
Countermeasures
Username enumeration
Error messages that were displayed by the homepage login form when a valid or invalid username was entered, gives hint for possible brute force attack. All error displayed error message should be as generic as possible, not specifying the cause of the error.
Resources:
- https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/03
- https://blog.nvisium.com/time-based-username-enumeration
Password lockout Policy
The application allows unlimited login attempts without disabling the account or delaying login process. This enables username and password brute forcing. An account lockout mechanism should be implemented to restrict the number of login attempts no the web server. Ethically or industry best practice recommends between 3 to 5 failed attempts. To add to this, account lockout should implemented at a random period for example after every 5 minutes to prevent automated brute forcing tools. Once the account is locked, the administrator should be notify to reset the account. Further, all unsucessful login attempts should be recorded in a database and should not be tracked in session variable.
Resources:
- cheatsheets/Authentication_Cheat_Sheet.html#account-lockout
- https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html
- https://owasp.org/www-community/attacks/Brute_force_attack
Weak password and hashing algorithm
The application had weak password for the admin login page ‘’ann’’ and MD5 hashing algorithm was used to hash the password. MD5 can be easily brute forced with very simple wordlist in a short time frame. To ensure that login credential (password) are more secure, use a complex password that include the following: a lower-case letter, an upper-case letter, a number, a special character, at least 8 characters long; preferably longer than 10, especially for admin users. Further, password should be encrypted with strong encryption techniques such as bcrypt.
Resources:
Exposure of critical information
The application was observed to be exposing very crucial information for instance robot.txt file expose critical financial information. Aside from this, other critical information was publicly accessible to everyone who visited the application. Remove the directory containing such data from being publicly accessible by adding a “.htaccess” file at the root of the affect webserver.
Resources:
- https://us.norton.com/internetsecurity-privacy-sensitive-data-exposure-how-its-different-from-data-breach.html
- https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url
Credential transmitted in Clear text
User login credentials were observed to be transmitted in plain text via a POST request, making it very easy for an attacker to intercept and capture them. The web server was also oberved to have OpenSSL installation on it but was not in use or was misconfigured. SSL should be configured and used to encrypt all traffic so it can not be intercepted. Transport-level encryption (TLS) should also be used to protect all communication transmitted between client and server. More preferably the Strict-Transport Security HTTP header should be used to ensure that clients are authenticated to the server over a secure connection.
Resources:
- https://en.wikipedia.org/wiki/Transport_Layer_Security
- https://portswigger.net/kb/issues/00300100_cleartext-submission-of-password
SQL injection
It was possible to access the back-end database through an SQL injection vulnerability. There is no adequate input validation or filtering on the web application. SQL injection vulnerabilities allow an attacker to access contents of the database and steal user credentials. To prevent these types of attacks, prepared statements or stored procedures should be used. Using either, the code that allows the login event to happen is sent separately from the data, which are the user credentials in this case. As the code gets executed first with space holders, the data cannot change it anymore even if it contains (malicious) code.
Resources:
- https://owasp.org/www-community/attacks/SQL_Injection
- https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html
Cross Site Scripting Vulnerability
XSS vulnerability was identified of almost all of the pages that used POST and GET requests. Most of these were reflected and stored XSS which an attacker can use to exploit the application and the server. To prevent such vulnerability, user input should be filtered and sanitized. PHP has the functions html entities and htmlspecialchars which can be used to encode any special characters into hexadecimals. Special response headers can also be utilized, for example Content-Type and X-Content-Type-Options which can be used to make sure browsers interpret responses in an intended way. Resources:
File upload Vulnerability
The application allowed user to change picture in the profile.php page and this function was vulnerable to image upload. The upload function had a filter that checked for a valid file extension and type but by uploading a PHP backdoor with an extension that was allowed, it was possible to circumvent the filter. The file could be renamed back to a PHP file with the use of a proxy. To prevent a file upload vulnerability, a filter that checks and validates a filetype should be used. The filter that the application uses is supposed to check the filetype but instead just checking the extension.
Resources:
- https://www.malcare.com/blog/file-upload-vulnerability/
- https://www.hackingarticles.in/comprehensive-guide-on-unrestricted-file-upload/
Outdated services and technologies
The web server was observed to have several outdated services installed, for example the OpenSSL and Apache HTTP server. Even though not every outdated service has vulnerabilities, it is important to keep all services updated in case a vulnerability is found. This also includes the MySQL and PHP installations which allow new improved functions to be used.
Resources:
- https://help.poolparty.biz/pp6/developer-guide/basic-advanced-server-apis/thesaurus-ontology-managerapi/outdated-services
Future work
As this penetration test identified the vulnerabilities, possible attack vectors from a hacker perspective and provided remedial advice, it would be a good idea to schedule another penetration test after the vulnerabilities has been fixed. This would also make it possible to find any new vulnerabilities that may have been missed during the first test or that were caused by the implemented patches. Another future work could be expanding the scope of the penetration test to perhaps social engineering (human factor).
References
ENISA (2020) ‘Threat Landscape 2020 — Web application attacks’, European Union Agency for Cybersecurity, (10), p. 18.
Tewai, A. (2015) ‘Evaluation and Taxonomy of Penetration Testing’, International Journal on Recent and Innovation Trends in Computing and Communication, 3(8), pp. 5297–5302.
Yuan, B. and Li, J. (2019) ‘The policy effect of the general data protection regulation (GDPR) on the digital public health sector in the european union: An empirical investigation’, International Journal of Environmental Research and Public Health, 16(6). doi: 10.3390/ijerph16061070.
Stack Overflow (2013) What is the htaccess Options -Indexes for? [Online]. Available at: .htaccess — What is the htaccess Options -Indexes for? — Stack Overflow (Accessed: 22 April 2021).
Stack Exchange (2012) Robots.txt security strategy? [Online]. Available at: web application — Robots.txt security strategy? — Information Security Stack Exchange (Accessed: 23 April 2021).
PortSwigger (no date) Cross-site scripting. [Online]. Available at: What is cross-site scripting (XSS) and how to prevent it? | Web Security Academy (portswigger.net) (Accessed: 23 April 2021).
OWASP Foundation (2017) Testing for Local File Inclusion. [Online]. Available at: Testing for Local File Inclusion — OWASP (Accessed: 23 April 2021).
Hacksplaining (no date) PREVENTING INFORMATION LEAKAGE. [Online]. Available at: Preventing Information Leakage (hacksplaining.com) (Accessed: 23 April 2021).
Detectify labs (2012) Do you dare to show your PHP easter egg? [Online]. Available at: Do you dare to show your PHP easter egg? | Detectify Labs (Accessed: 23 April 2021).
Hacking Articles (2017) Sql Injection Exploitation with Sqlmap and Burp Suite (Burp CO2 Plugin). Available at: Sql Injection Exploitation with Sqlmap and Burp Suite (Burp CO2 Plugin) (hackingarticles.in) [Online]. (Accessed: 23 April 2021).
