Milestone #2

Milestone 2 Report

Milestone 2 Assessment

The objectives for Milestone 2 as laid out in our project plan were to:

1. Take the information gained by milestone 1 and implement our policies and procedures into the system.

2. Have meetings to discuss new developments, accomplishments, roadblocks, etc.

3. Update server applications in the stack - Apache, PHP, MySQL, JavaScript

4. Enable and setup HTTPS for Linux and web server.

We successfully completed all but one of our Milestone 2 objectives. Over the course of the last month, we completed the remaining server and WordPress updates. Unfortunately, we were unable to get HTTPs working due to private server limitations.

Server vulnerabilities and solutions

Our team already configured and registered the server in Milestone 1, which allowed us to be able to receive the updates from the Red Hat servers. These updates get sent to our team lead’s email and we push out the updates to the server when required, fixing all the vulnerabilities and bugs that are on the server per the Red Hat team. (“Linux man page – Subscription-manager(8)”, n.d.).

Updating PHP on the server was a crucial step for our team as older versions of PHP are more likely to have vulnerabilities in them. Our team investigated the best way to update PHP for our server with little downtime and going the route of least changes. We did not want to have to change many things on the server while updating as we think our server is hardened already from the changes we have made. Finding the best solution from articles online guided us to be able to update the application on our server (“LeoGuides -- How to upgrade PHP 7.2 to php 7.4 on centos 8 or Rhel 8,” 2022).

We had to first update the server with the yum command to make sure all other repositories had been updated on the server. Once we knew that the server was running the latest repository updates, turning off https service was necessary as the application would still be running in the background. After, we removed the older version of PHP from the server (version 7.4). Running the command allowed us to remove the outdated version of the application and its cache. If we did not do this, the older files could create conflicts within the latest version.

After removing the older version and files, we ran the command sudo yum install php php-curl php-cli php-mysql php-gd php-common –y to find and download the latest PHP for our server that is running 8.2(“LeoGuides -- How to upgrade PHP 7.2 to php 7.4 on centos 8 or Rhel 8,” 2022). Running through the update, new files for PHP were installed onto the server along with all other required repositories. After finishing the update, we turned back on the PHP service and ran the yum, php –v, and httpd -v commands to verify that everything was up to date and then checked the website to make sure it was still running properly.

The version our server is running right now is Apache version 2.4.37. This is an older version of Apache, and we are looking into the vulnerabilities of this version. We are researching to see what we can and cannot do with this version in case the other team is using it. Once we have finished research and testing, we will update Apache if we can safely do so without uninstalling the application from the server (“Ubiq -- How to upgrade Apache version in centos, Redhat Linux,” 2022). If we can find a way to run the update and allow the services and other repositories needed to run Apache to stay on the server and update alongside the main client, then we will go that route. If we must uninstall the application to install the latest version, we will not be going that route as we are not allowed to uninstall any application from the server that is part of the application stack.

The version of MariaDB we are running on the server is 10.6.18, with the latest version (10.9.3) released in September of 2022. When updating the version of MariaDB, it is suggested that you uninstall the version and all the services for the application. We ended up not updating MariaDB as in our VM (Virtual Machine) setup, it specifically says to not uninstall any application that is already on the server. Our team made sure we pushed all server updates with yum updates and tried to just update the database version to the latest without uninstalling the application. We were not successful in doing so and do not want to uninstall the database and cause any issues.

With the application not being able to update to the latest version, we made sure the user accounts that go with MariaDB were secure. Making sure that the root and admin passwords are changed and as well as locking down tables and databases to only be read only. This way if anything happens and the other team gets into the database, our databases are locked so they wouldn’t be able to create or remove any data. In addition, we have the database backed up on the server.

Our team decided to turn off port 22 for SSH to better harden our server. With SSH turned off, we understand as a team that we will not be able to use the port to SSH into the server to make changes. To do so, we would have to login to the CockPit application and use the terminal to make changes. Deciding to turn off port 22 was a team decision and gave us a clear mind going into the next phase of the project when the other team will be attacking us. Taking away a vantage point for them is a plus for our team and the server (“IBM -- Securing your SSH Server,” (n.d.).

WordPress vulnerabilities and solutions

Most of the WordPress vulnerabilities were fixed during Milestone 1. However, at the end of the milestone, there were a few issues with WordPress that had yet to be addressed: HTTPs was not active and SELinux was blocking server emails. After researching, we concluded that HTTPs would not be possible on our server as LetsEncrypt cannot assign an SSL certificate to a private server (Spencer, 2022). Additionally, KSU’s IT support informed us that email capabilities were disabled as students sending emails from KSU servers is a security concern. We had planned to use email for two-factor authorization but were able to enable it via a mobile application instead. Unfortunately, without email we will not get email alerts from WordFence, but it is something we can live without. In a live setting, email would be enabled and Wordfence would email the site administrator whenever attacks were detected.

During Milestone 2 our team continued to scan the website with different tools to check for vulnerabilities other tools may have missed. The Open Web Application Security Project’s (OWASP) ZAP tool informed us that our website did not have security headers or a content security policy in place. We installed the Redirection plugin and used its HTTP Headers options to add both. The following headers were added: X-Frame-Options (protects against clickjacking), X-XSS-Protection, and X-Content-Type-Options (protects against content sniffing). In addition, a content security policy (CSP) and referrer policy were added as well. The main role of a CSP is to block untrusted content besides the host and/or any defined sources. Further scans with OWASP ZAP still flag missing security headers, but we believe this to be a false positive (Morris, 2021). WordFence protects against many of the same attacks, so we are confident we are protected in this regard.

A few other small tweaks were made to further harden its security:

1. The original Dyad theme was removed, and a theme rebuild was completed with a combination of the GeneratePress theme with the GenerateBlocks plugin. Both are easily customizable, widely recommended, updated regularly, and well supported ("GenerateBlocks – Build better WordPress sites, n.d.).

2. As mentioned previously, two-factor authorization was successfully enabled.

3. All forms on the website were removed, such as the ability to comment on posts. Comment forms are popular with bots and forms could be used to attempt a cross-site-scripting (XSS) attack (though Wordfence should protect against it as well) (“Malcare -- WordPress XSS Vulnerability: How to prevent it,” 2022).

4. File permissions were changed, 755 for directories, and 644 for files, as recommended by WordPress.

5. Edited the WordPress configuration file (wp-config.php) to disable file editing within the WordPress admin panel. Should someone successfully log in, they will be unable to edit themes, plugins, or files through the web interface (“WordPress.org -- Hardening WordPress”, 2021).

Additional website vulnerabilities found

After scanning for vulnerabilities in preparation for Milestone 1, we were able to analyze each scanner’s results and make possible fixes to prevent the existing weaknesses from being exploited. Additional scans using some of the same tools were done in preparation for Milestone 2 to see where we started and the progress we have made since then, as well as if any other vulnerabilities still existed.

One scanner sqlmap (“sqlmap,” n.d.), was used to find if our website was susceptible to SQL injection. The tool, however, said that the page IDs were not injectable and that Wordfence is active. To confirm the results, we also did some manual testing on the page IDs to see if we were able to get any undesirable results but were not able to find anything out of the ordinary.

Skipfish, (“Skipfish - Penetration Testing Tool in Kali Linux,” 2022) which was used in the previous milestone to find HTML forms that lacked XSRF protection, was used again to scan the current website. Like sqlmap, skipfish did not find any vulnerabilities dealing with SQL injection. However, it did still find some XSRF related issues, albeit we got less flags this time than the first initial scan. As we do have X-content-type http headers active, we believe that these may be false flags.

Our active X-content-type headers were shown to be visible using a scan from Whatweb (“Whatweb -- Tool to Discover Security Vulnerabilities with Your Web Application,” 2018) which also showed the Apache version and WordPress version that the server and website is running on.

OWASP Zap (“ZAP -- Most Used Web Vulnerability Scanner”, 2021) is another scanner that also flagged the lack of headers, even though we can view the flags ourselves through Whatweb and the WordPress website settings themselves.

Unfortunately, like Milestone 1, we are still having difficulties when trying to scan with WPScan (“WPSCAN Intro: How to Scan for WordPress Vulnerabilities,” 2021). The scanner still does not detect WordPress content on the website. We are satisfied with the information that we found using other vulnerability scanners, so we have chosen to continue without WPScan.

The tools we’ve used for Milestone 1 and 2 have been a great part in recognizing and addressing the weaknesses in our website. As such, we will also use these tools to find vulnerabilities during the attack phase on the other team’s website. Even though it is likely that they have also been using vulnerability scanners to patch up their website as well, it will still be good to know what defenses were put up by the other team just so that we have an idea of how they built their website against attacks, and if there is anything that they missed.

Penetration Testing

Using Nmap, and Confirmed on Legion, a vulnerability was discovered involving the version of Apache we currently have which could allow an attacker to remotely perform a DOS attack against our web server (“Rapid7 -- Apache httpd…,” n.d.) We attempted to locate the package, but we were unsuccessful during Milestone 2. This vulnerability will be one of our main focuses, because from the start, one of the biggest risks to our web server is denial of service because our final grade is based off server uptime and accessibility.

Since the WPScan has not been working, we also are unable to locate specific WordPress vulnerabilities. Though, we can assume because it does not work for us, it most likely also does not work for the opposing team.

A brute force pen testing attack would have occurred, but we instead decided to disable SSH since it gives our attackers an easy way to access our server. We do not necessarily need to access the website via SSH when we can directly connect through Red Hat.

Since we have not been able to find an easily available vulnerability to exploit on our own web server, most of our penetration testing was continuing to run regular scans on the web server to see if any of our security has changed.

Challenges

During Milestone 1, we used tools to be able to find the vulnerabilities presented in our website/VM. We had various tools at our disposal that have been working well in helping us with our goals of finding and securing vulnerabilities. We decided to take things a step further by finding and using other open-source tools that could potentially help us find missed vulnerabilities and that could help us during Milestone 3/Attack Phase. We originally ran into various issues with trying out new tools during Milestone 1 that were mentioned in the Milestone 1 report. Now, as we prepare for the attack phase during Milestone 2, there have been a few new and reoccurring issues that have been presented with certain tools.

Beginning with WPScan (as mentioned above), WPScan has been giving us issues in the sense of not being able to discover WordPress installed on our website, despite our website having WordPress installed. We’ve tried various commands with various parameters and have even run the different commands from different Kali Linux VMs, but usually ended up with a failed result of not being able to discover WordPress on the website. Seeing as how we are unable to work around this issue when running several different commands with several different parameters, it was best to abandon WP scan as a tool during this Milestone.

Another tool that has presented an issue has been Legion. Legion is a penetration testing tool that can scan for and attack vulnerabilities in a website. The main issue that we have been running into with Legion is constant crashes when running. We were only able to successfully perform one scan with legion which only confirmed the data we had already gathered from a SYN scan using Nmap. While there are no issues regarding the installation and startup of the tool, the execution of the tool remains an issue. We’ve tried running Legion on different Kali Linux VMs, but it persists in crashes when attempting deep scans. We’ll continue trying to use this tool for testing our own website and during our attack phase, but it could be possible that if we cannot get the crashes to subside, then this tool could be abandoned before or during Milestone 3/Attack Phase like WPScan.

When gathering tools for the attack phase, it’s possible that some tools could be used, but certain tools have a challenge regarding their potential use. In this case, it could be that social engineering would be needed which would be likely to fail immediately. It’s commonly known that humans are usually one of, if not, the weakest link when it comes to attacks due to social engineering. One of the most common attacks are phishing attacks, and some tools, to work in an attacking sense, would need the victim (in our case: the other team) to fall for a phishing link that could give us access or information desirable to reach our goal in taking down their website. This here lies the issue with this tool’s potential use, since it’s highly likely that the other team is smart enough to not fall for any social engineering tricks in real life, let alone tricks during the attacking phase. Any tools that could have been a huge asset during the attacking phase whether they were to be used in recon/scans or actual attacks are now likely to have to be abandoned as well since they would immediately fail due to social engineering prerequisite.

Overall, new challenges were presented with tools during this phase. We will have to either find solutions for these challenges or gather new tools that could present less-to-no issues for us, conducive to our goal of taking down the other team’s website.

Risks

In addition to the risks in Milestone 1, our team discovered a few more during this milestone.

Older PHP/Apache/MariaDB object dependencies

While updating PHP, Apache and MariaDB on the server was done to combat the vulnerabilities that existed in the older versions. There comes the chance that objects that relied on functionalities that existed in older versions may not work as intended in newer versions. To prevent such errors from occurring, we have been analyzing what changes each update will bring, as well as preparing server backups in the case that an update causes an object to break.

False positives from scans that are actual vulnerabilities

As stated in the above sections, we believe that some of the X-content-header flags were false flags. It is not too farfetched to believe that positives from scans, or harmless flags, can be exploited that the vulnerability scanner did not detect. This can be combatted by manual penetration testing, in which if we are able to bypass something that a scanner said was harmless, we will know of the vulnerabilities existence and how to address them. As a positive, assuming that we can break through a false positive, and if our attacker’s website is built similarly to our own, then we can use the newfound information to our advantage.

Unlocked MariaDB Databases

Our databases in MariaDB are not locked, meaning that if a user were to gain access to MariaDB, they would be able to read and change the data inside. To nullify the chance of this being exploited, we have changed the password to both the root and admin accounts, which creates users in the database. We have also looked for any weaknesses that could lead to SQL injection through scanning using sqlmap and performing manual testing to see if we were able to view the MySQL data inside.

Lessons Learned

When the time comes for the attack phase, it’s possible that our prior experience in securing our website will come in handy.

Assuming that all websites/VMs were identical (meaning that had all the same vulnerabilities), our group can use the current knowledge that we have from all the vulnerabilities that we have found and fixed, as a starting point in spearheading our attack on the other group. Whatever we fixed, we can check to see if the other group has found and fixed that same vulnerability; and if we are fortunate, the other team has not, and we can exploit it. Seeing as how we found and fixed multiple issues throughout Milestone 1 and 2, we have many we can look for right off the bat and hopefully can exploit them to give us a good start for the attack phase.

Our knowledge of what vulnerabilities are possibly present is not the only transferrable skill for the attack phase. We also have our experience when it comes to the multiple tools that we have been using during Milestone 1 and 2. When first starting in Milestone 1, we faced the learning curve of having to learn how to navigate the GUI and command lines of the tools we used, along with having to learn what commands/actions we needed to execute to get the results that we desired. We can use our experience in working with these tools to help us get the results we want when attempting to attack our target. Whether it’s scanning/reconnaissance or exploiting found vulnerabilities, we won’t struggle as much during the attack phase since we will be accustomed to our tools and will be more comfortable navigating and working them.

Gantt Chart

This chart shows what we think are the most important parts of the project for this milestone. We had to make sure that all vulnerabilities that we found were patched and applications were up to date. Our team will continue to scan for vulnerabilities and run penetration tests as finding vulnerabilities in our own server will help us with the attack phase.

Conclusion

Our team is incredibly proud of the progress we have made during the first two milestones of our capstone. We updated the server and WordPress, fixed vulnerabilities, and successfully implemented all but two planned fixes to our server (HTTPs and server email). Over these two months we have learned a lot that will help us during the attack phase, including which tools to use, vulnerabilities to look for, and how to exploit them. We are confident that we are ready to begin the attack phase and look forward to wrapping things up next month.