Analysis Process
Project Objective
This project followed the scenario described below:
A company specializing in retailing bicycles, snowboards, and other outdoor active gear has a new e-commerce website. The name of the ompany is "Bikes, Boards, and Beyond." They need to ensure that the website and webserver are secure against multiple attacks to ensure that their business is secure. Their website includes a Retrieve Order page and Message Board page.
Network Topology
This is my proposed network topology for Bikes, Boards, and Beyond.
The webserver should be publicly available, so it is connected to the internet with only one router behind a firewall. The firewall is necessary since some ports (such as SSH) should probably not be enabled.
The customer data server should not be directly connected to the internet, it should be behind the webserver. However, the customer data server must be connected to the webserver as shipping and account information must be stored automatically from the website. However, this sensitive data should not be stored on the webserver, as the webserver has ports such as HTTPS and FTP open and is thus more vulnerable to attack. The data should be secured on the internal Bikes, Boards, and Beyond customer data server.
Access computers are needed for accessing the databases on the individual server systems. These access computers are needed to modify information from Bikes, Boards, and Beyond. They must be internal as they have direct access to the internal servers with only a firewall in between.
I believe that the employee data should be stored offline, as this data does not need high availability. Employee data should not be accessible online, which makes it much more difficult to access. For Bikes, Boards, and Beyond, employees are likely not working online and systems do not need access to their data from outside the Bikes, Boards, and Beyond internal network.
Each server has a backup server (represented by the two servers with arrows between them). In case one server fails, the other server can take the network load.
Additionally, customers do not connect directly to the Bikes, Boards, and Beyond servers. They should connect their personal computers from a home network through a firewall and a router, and then connect to a DNS (Domain Name Server) server. This DNS server then gives the customer's personal computer the IP address of the Bikes, Boards, and Beyond webserver, which can then be accessed over the internet through a Bikes, Boards, and Beyond router and firewall for safety.
Plan of Action
- Determine the IP address of the webserver
- Use the netstat command in PowerShell using the server's IP address to determine the services running on the webserver. These may include SMTP or FTP which may be vulnerable.
- Login to the Bikes, Boards, and Beyond website using the provided credentials (admin/password)
- Explore the website and attempt forceful directory browsing
- Attempt to find logfiles which may contain sensitive data
- If FTP is enabled, attempt to use FTP with found credentials
- Perform cross-site scripting (XSS) on all forms
- Perform SQL injection on all forms
- Attempt a ping flood attack on the webserver
- Attempt remote code execution on all forms
- Secure the webserver by disabling unnecessary features, enabling the firewall, and choosing more secure settings. I will use the IIS (Internet Information Services) Manager on the webserver for this.
Determine Running Services
I ran netstat –an 172.30.0.15 on the webserver, I was able to determine which ports were open. Port 21 (FTP) was open, but port 25 (SMTP) was closed (not in the list). This means that FTP is running but SMTP is not running. FTP stands for the File Transfer Protocol, and is used for transferring files. SMTP is a vulnerable mail service (Simple Mail Transfer Protocol).
No Vulnerability: SMTP
Since port 25 is closed, SMTP is not being used. Thus, SMTP is not a vulnerability.
Vulnerability: Forceful Directory Browsing
I attempted forceful directory browsing, and succeeded at browsing directories. Forceful directory browsing is when an attacker accesses an unlisted URL of a website, in this case the root URL of the webserver.
Preventing the Vulnerability
Directory browsing was enabled in the IIS Manager, so I disabled it.
Vulnerability: Visible Logfiles
Logfiles were visible and could be downloaded through forceful directory browsing. One logfile contained a username and password for FTP (anonymous/test).
Preventing the Vulnerability
To prevent this vulnerability, the directory browsing needed to be disabled, and the logfile location needed to be changed. The default storage location for logfiles on the IIS server is in C:\inetpub\logs\LogFiles, which is easy for an attacker to guess. The logfile location should be changed to outside the inetpub folder in a hard-to-guess location so it cannot be accessed with directory browsing.
Vulnerability: Anonymous FTP
Using FileZilla, I was able to use anonymous FTP with credentials "anonymous" and "test" found in the logfile. Sensitive files were visible on the webserver using FTP. Files could also be uploaded and downloaded from the webserver.
Preventing the Vulnerability
The webserver does not need FTP enabled, so it would be significantly more secure to disable FTP. To disable FTP, I used the Windows Server Manager's Remove Roles and Features Wizard, where I unchecked "FTP Server."
Vulnerability: XSS (Cross-Site Scripting)
Cross-site scripting (XSS) is when an attacker uses Javascript code as input into a form. If not configured properly, the input will indeed be interpreted as Javascript, and will run on the client's web browser. In this scenario, I used Javascript code that showed a heading confirming a successful XSS attempt.
Preventing the Vulnerability
I was able to detect the XSS attempt using Wireshark, a software for analyzing network traffic. The Javascript code was directly interpreted as input, and was thus run. To prevent this vulnerability, treating input as plaintext and filtering out <script> tags is necessary.
Vulnerability: SQL Injection
SQL is a the Structured Query Language, and is used for managing relational databases. The SQL injection attack uses SQL code as input into a database, which is then interpreted and can be used to gain sensitive information. In this case, 1' is the regular input. The apostrophe exists the input string, so that SQL commands can be added. OR is a logical operator using in SQL. 1=1 will always evaluate to TRUE. So this input will query the first element of the database, and then will loop through all of the other elements and return all of their values. Thus, it returns the entire database.
Preventing the Vulnerability
The process of preventing SQL injection is similar to that of XSS. By not allowing symbols in the input, such as apostrophes, SQL injection can be avoided. I was also able to detect the SQL injection attempt in Wireshark.
Vulnerability: Inactive Firewall
I checked the firewall on the webserver, and found that it was disabled. This meant that all ports could be used by services, which could present numerous vulnerabilities.
Preventing the Vulnerability
Turning the firewall on was simple, I just selected "On" in the Windows Firewall settings.
Vulnerability: Ping Replies (Ping Flood Attack)
During a ping flood, multiple computers send numerous "ping" requests to a server. The idea is to make the server "reply" to this ping request, which requires processing power. With enough ping requests, the server will be overwhelmed and will fail, causing a Denial of Service (DoS).
Wireshark can be used to detect a ping flood attack. If pings are sent in rapid succession and the webserver sends a reply, a ping flood attack is occurring and may be successful. In the Wireshark screenshot above, one can see the ping requests and ping replies.
Preventing the Vulnerability
Once the firewall was enabled, I could block "File and Printer Sharing (Echo Request)." By blocking this, the webserver would not reply to pings and ping floods would not be an issue.
No Vulnerability: Loose-Lipped Error Messages
"Loose-lipped" HTTP error messages are error pages that show sensitive system details. These details could include software running on the webserver, versions, and system diagnostics. However, this webserver was secured to not show detailed error messages. Thus, a generic 404 error was shown in the example above.
No Vulnerability: Remote Code Execution
I attempted remote code execution on both the Retrieve Order and the Message Board webpages, but was unsuccessful. Remote code execution is when an attacker inputs malicious code into a form that runs directly on the server. This makes remote code execution an extremely dangerous vulnerability, as any command can be run as a non-root user. In this scenario, I attempted to use the ; operator to chain another command to be executed in PowerShell. However, there was no output, so remote code execution is not a vulnerability on this server.
To secure a server against remote code execution, programs should never take direct input from a form and use it in a command. Input should be searched for special characters which may be used to execute additional commands.
Reflection
Why should a security analyst be able to read and analyze software programs written in Javascript?
Knowledge of Javascript is absolutely necessary when performing penetration testing on a webserver.
To identify XSS, SQL injection, or remote code execution vulnerabilities, the security analyst must ensure that
input is treated as plaintext and that user input will not be processed if it contains special characters used in exploits.
Why is it important to plan and then document all the steps you take in a pen test?
Creating a plan of action is imperative when performing penetration testing.
Planning out actions saves time later when the exploits are performed, as potential issues can be brainstormed and identified easily.
It also helps to generate a plan beforehand as necessary actions can be forgotten during a pen test.
Documentation is necessary to communicate the system audit and findings of the pen test to the administrators responsible for the system.
This helps them to solve issues quickly to keep systems secure and maximise uptime.