Introduction
In this report I will be detailing the process of Penetration Testing the St John’s Secondary School web server. This will include the Information Gathering, Vulnerability Analysis and Penetration Testing stages. Furthermore, at the end, I will include recommendations for Mr Chalk to improve the security of this server.
This will be done on a closed local network between two virtual machines running Linux Debian using various pre-installed tools to my advantage.
Information Gathering
The first step that I took was to open up Links, a text and graphics web browser, and connect to 192.168.1.2 (http://school). This displayed the web page for St Johns School. From there, I wanted to see the underlying script that controls the page to search for any weaknesses.
I then proceeded to run Nmap, a tool used for exploring networks and checking security which uses packets of data to determine information about the network. [1]
By running the command “Nmap -v -A. 192.168.1.2”, I was able view all of the open ports running on 192.168.1.2. These ports were 21 (FTP), 22 (SSH), 23 (Telnet) and 80 (HTTP).
My next step was to use Netcat, a networking utility that is used for reading from and writing to network connections, to attempt to connect to each port. [2] I began with port 21 but it required a username and password that I did not have at that stage. Secondly, I connected to port 22 which revealed details about the SSH software that was running on the machine: “SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze5”. The next connection was to port 23, which unfortunately did not return anything.
Finally, I connected to port 80. I then executed the command ‘GET /’ which revealed the html source code for the page and highlighted the shell file that was controlling the page. From there I reconnected and ran the command ‘GET /cgi-bin/marks.sh’ which was interesting as it returned the shell script for the page, containing the sql query that is run by the web page to access the marks database.
In the screenshot to the right, you can see the source code for the webpage and that it runs the marks.sh script.
In the next screenshot, you can see the contents of the marks.sh file and the SQL query that it executes.
It also gives the name of the database that holds the student’s marks.
Vulnerability Analysis
The first area that I thought would be vulnerable to attack, was the SQL query running within the marks.sh script. This is because it has no input cleansing or verification and therefore any input will be accepted. This means that the query can be bypassed and the entire contents of the database can be returned.
As you can see in the screenshot above, the query has no protection from SQL injection.
The next vulnerability that I found was that the server is running an old version of Linux (Debian 6.0) which was released in 2014 and has had several new releases since. This operating system is typically susceptible to the Shellshock bug (CVE-2014-6271) [3] unless it has been patched correctly. For these purposes, I assumed that Mr Chalk would not have patched this and treated it as a vulnerability.
However, when it came to penetration testing, I had already obtained the root login from another method and was able to test the vulnerability of the school server with the command “env x=’() { :;}; echo vulnerable’ bash -c ‘echo hello’” which returned the desired statements, proving that it was vulnerable. [4]
The final area that seemed unnecessarily vulnerable was the fact that there are 4 open ports. Obviously, port 80 (HTTP) is required to host the web server, but the others allow unnecessary access and therefore this can be exploited. For example, once a login has been gained, files can be transferred over ftp and the server can be controlled remotely via SSH. Furthermore, when the ports are left open, their logins can be tested with Ncrack.
Penetration Testing
My first attack was SQL injection, one of the most common web hacking techniques, whereby code is injected via web input. [5] For this attack, I took the query: SELECT child, mark FROM marks WHERE child = ‘ ‘ AND password = ‘ ‘; and looked to see how I could exploit that and cause it to trip up and return all of the contents of the marks table.
The first thing I tried was to insert a condition that was always true such as 1=1. I then realised that I needed certain apostrophes so that the statement was all correct and found that the correct input would be ‘ or ‘1=1’; which would make the query “SELECT child, mark FROM marks WHERE child = ‘ ‘ or ‘1=1’; ‘ AND password = ‘ ‘;” and would get to the child condition, return true and therefore bypass the password condition, returning all of the data.
However, I could possibly have inputted a “SELECT * FROM marks;” statement in the password field and obtained the passwords as well.
This attack was successful and allowed an unauthorised user to read the data. However, due to the permissions of the web page, data cannot be altered or inserted from this method.
My second attack was possibly the simplest attack, where I utilised a tool called Ncrack. Ncrack is a high-speed network authentication cracker that can be used across various different protocols such as ftp and ssh. It tests networks for poor passwords by repeatedly trying common passwords until it finds a successful login. [6]
For my attack, I ran Ncrack on port 22 (SSH) and used the optional command –user root.
This completed in between 5 to 10 minutes and therefore gave me access to the root account. I could however have given it the guest username as well, but I felt that root privileges were more important.
The login it gave me was Username: root and Password: donkey.
Following this, I logged in via SSH afterwards and changed both the root and the guest passwords to “hello” and therefore this meant that I also had the guest login.
This attack was successful and allowed an unauthorised user to read the data as they can view the database but also to modify data as they have access to the database and the .csv file. Furthermore, this attack was powerful as it allows access to both the administrator account and the guest account.
For my third attack, I took a login that I already had and attempted to access the contents of the shadow file. To do so, I used the FTP tool and connected to the School server with the Guest login. From there, I changed directory to /etc/ where both the passwd and shadow files are kept. I was then able to download the shadow file by using the command “get shadow”.
I then exited the FTP connection and ran John, a fast password cracker that can decrypt hashed passwords, on the shadow file. John takes a list of common words and hashes them and then compares those to the hashed passwords until it has a match. [7]
This completed instantly, which was surprising, meaning that with the command “/usr/sbin/john -show shadow” I was able to view all of the usernames and passwords stored on the system.
This attack was successful and allows an already authorised user to gain root privileges as once they have gained the root login, they can give themselves root privileges. Furthermore, it allows access to other user accounts. Finally, it allows that unauthorised user to be able to view modify data that they previously would not have been able to.
The final penetration method that I chose was an exploitation of the Shellshock bug. The Shellshock bug affects most Linux and Unix systems as it affects the Bash shell that is commonly found in these operating systems. The way this works is that malicious commands can be hidden within variables and when the shell gets to the specific string of characters: “() { :;};”, it causes the shell to trip up and executes the commands that follow it.
The way I have exploited this bug is by setting a custom HTTP header that the CGI script on the webpage receives as an environment variable. This allows me to perform any command with the permissions of the webpage.
As you can see in the screenshot, I have used the command: wget -U “() { test;};echo \”Content-type: text/plain\”; echo; echo; /bin/cat /etc/shadow” http://192.168.1.2/cgi-bin/marks.sh to set a custom HTTP header for the web page which downloads the contents of the shadow file. [8]
In this screenshot you can see the contents of the marks.sh and that it is the shadow file instead of the shell script that controls the webpage.
From there, the file can be cracked by John.
In this screenshot you can see that by running the commands “/usr/sbin/john marks.sh” and then “/usr/sbin/john –show marks.sh”, you can obtain the passwords for the system.
This attack was successful and allows an unauthorised user to access to both standard and administrator accounts by obtaining their credentials. Furthermore, it allows the ability to read or modify data due to the privileges gained from the credentials.
Following any of the three previous attacks, it is possible to modify the data on the web server and therefore alter what the user sees.
To do so, I created a new .csv file with new entries for the database. I then logged into the school server as “chalk” via ftp and uploaded this file to the /home/chalk folder.
The next step was to log in as root via ssh. I quickly checked that file was in the desired folder and then ran sqlite3, a command-line database management system, and used the command “.import” to load the new .csv file into the database. [9] As you can see in the screenshot, there are extra entries beyond what was originally in the database.
Recommendations
To improve his system, I would suggest a number of improvements to Mr Chalk. The first being the issue of the open ports. If these were closed and only the necessary ports were open, it would prevent Ncrack attacks, unless they are possible on port 80. Furthermore, if the penetrator was able to gain a login to the machine, they would have to have physical access to manipulate the machine as there would be no FTP or SSH access.
Secondly, it is always a good idea to use secure passwords when protecting sensitive data such as information about school children. In this situation, the passwords used were very simple, often single words and are therefore easy to crack with various dictionary based tools. My suggestion is to implement certain requirements in a password, such as it has to include a number, a capital letter and a special character to make it harder to crack.
My third recommendation is to prevent anybody other than root being able to read secure files such as /etc/passwd and /etc/shadow which are easy to crack with a tool such as John and therefore leave the system very vulnerable to an internal attack.
Finally, Mr Chalk needs to patch the system against the shellshock bug as this is a crucial security vulnerability. To do so, he will need to update bash to its latest version.
After these areas have been patched, this system will be much more secure. There may still be some slight vulnerabilities, but for the purposes of a school marks system, the security will be adequate.
Conclusion
To conclude, the security of this web server is fairly weak with open ports and simple passwords. With a few simple fixes, this could become fairly secure and therefore inaccessible to the average user.
Whilst completing this testing of the server, I have gained a huge amount of knowledge about the Linux Operating System, how to traverse the file system and some of the common commands. Furthermore, I have learnt about penetrating a system and therefore how to protect a system from such attacks.
Finally, if I were to complete this task again, I would look into some more complex vulnerabilities, such as the directory traversal vulnerability surrounding thttpd 2.25b 29dec2003 to ensure that the system is almost bulletproof. [10]
References
[1] Nmap: the Network Mapper – Free Security Scanner: 2019. https://nmap.org/. Accessed: 2019- 02- 15.
[2] Netcat: 2019. https://en.wikipedia.org/wiki/Netcat. Accessed: 2019- 02- 15.
[3] ShellShock: All you need to know about the Bash Bug vulnerability: 2019. https://www.symantec.com/connect/blogs/shellshock-all-you-need-know-about-bash-bug-vulnerability. Accessed: 2019- 02- 15.
[4] Bash vulnerability CVE-2014-6271 (Shellshock) fix on Debian 6.0 (Squeeze): 2019. https://unix.stackexchange.com/questions/157805/bash-vulnerability-cve-2014-6271-shellshock-fix-on-debian-6-0-squeeze/157808. Accessed: 2019- 02- 15.
[5] SQL Injection: 2019. https://www.w3schools.com/sql/sql_injection.asp. Accessed: 2019- 02- 15.
[6] Ncrack – High-speed network authentication cracker: 2019. https://nmap.org/ncrack/. Accessed: 2019- 02- 15.
[7] Getting Started Cracking Password Hashes with John the Ripper – TunnelsUP: 2019. https://www.tunnelsup.com/getting-started-cracking-password-hashes/. Accessed: 2019- 02- 15.
[8] What is a specific example of how the Shellshock Bash bug could be exploited?: 2019. https://security.stackexchange.com/questions/68122/what-is-a-specific-example-of-how-the-shellshock-bash-bug-could-be-exploited. Accessed: 2019- 02- 15.
[9] sqlite3 – Unix, Linux Command: 2019. http://www.tutorialspoint.com/unix_commands/sqlite3.htm. Accessed: 2019- 02- 15.
[10] Thttpd 2.25b Directory Traversal Vulnerability – CXSecurity.com: 2019. https://cxsecurity.com/issue/WLB-2013050155. Accessed: 2019- 02- 15.