Milestone #1

Milestone 1 Report

Milestone Assessment

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

1. Examine the existing system and develop policies and general improvements to better secure it

2. Have meetings to discuss our findings and planning what could be implemented in the final project

These objectives were created before we had a chance to access the server and before we truly understood the scope of our project. Once we were given access to the virtual machine and the web server, our objectives changed. Our priority was to get the server running and updated so our team could begin scanning for vulnerabilities. While objective one is in progress, we did regularly meet to discuss our findings and consider objective two complete.

Server vulnerabilities and solutions

Most of the vulnerabilities for the server were due to the server not being up to date and not getting updates. While looking into the issue, we found the server had to be registered with Red Hat. Once registered, the server would be able to receive the proper updates.

Unfortunately, the server was flagged as registered when it was not. To fix the issue, we unregistered the server, cleaned the registration data off the server, and re-registered. Afterward, we ran the command subscription-manager register –force, which allowed us to register the server with the account we created (“Red Hat – How to register and subscribe a RHEL system to the Red Hat Customer Portal using Red Hat Subscription-Manager? - Red Hat Customer Portal,” 2022).

We gave the update some time to complete, and afterward the server said it had 727 updates and 152 security updates. We ran all the updates. As the server updates had been holding the team back, we were finally able to begin working on finding WordPress and website vulnerabilities.

After the server was updated, we were also able to run insight-client on the server to send information to Red Hat for updates. This is a big part of the server as it will help with monitoring and supporting security features and solutions for the server. Helping us along the way as our own team is working on the security features and vulnerabilities (“Red Hat – Red Hat Insights,” n.d.).

WordPress vulnerabilities and solutions

Outdated theme/plugins

The theme installed on the website (Dyad) required the use of a security plugin (Jetpack), which would not work on a private server. In addition, there were other inactive themes and plugins installed which were a vulnerability issue if left installed. As outdated or unsupported themes and plugins can cause vulnerability issues, we opted to remove Jetpack and the Dyad theme. All inactive themes and plugins were also removed (“Jetpack – Dyad 2,” 2022).

Lack of a security plugin with the removal of Jetpack

With the removal of Jetpack, WordPress was lacking in security. While a plugin may not be necessary for more experienced system administrators, for inexperienced users we suggest Wordfence as a replacement for Jetpack. Wordfence is the most recommended WordPress security plugin as it includes brute force, XMLRPC, and malware protection, as well as two-factor authorization and additional firewalls (“Wordfence – Wordpress Security plugin,” 2018).

In addition to the above, the following features have been enabled in Wordfence:

• Email alerts: The administrator will be emailed if Wordfence is deactivated, firewalls turned off, an IP address is blocked or a user is locked out, a user requests a lost password, an administrator logs in, or if attacks are detected.

• Limit login failures and forgotten password attempts – If an IP fails to log in, on the 5^th attempt their IP will be blocked for 12 hours.

• ANY attempts to log in with the usernames ‘admin,’ ‘administrator,’ or ‘ksuitg5’ (the original admin account which no longer exists), will result in an immediate IP block.

• Failed login attempts will now result in a generic error message (“something went wrong”) instead of displaying whether a username is valid.

• Prevention of username discovery through author pages, oEmbed API, REST API, and XML Sitemaps.

Poor password

The initial administrator password was Kennesaw123!. While this password does follow some basic password standards (such as the use of uppercase, lowercase, numbers, and symbols) it is still considered a poor password due to its length and use of a single word. We changed this password to a 20-character password with a random mix of uppercase, lowercase, numbers, and symbols.

Publicly displayed username

While the administrator login wasn’t admin or administrator, it still had a security issue as its username was publicly visible as the author on news posts uploaded to the website. Hackers can use this information to attempt brute force logins on the website. A nickname was added and enabled for the admin account within user settings. This name will appear on all blog posts instead of the admin username. In addition, Wordfence has additional protections in place to obscure author information.

Active directory listings

Many directories without index files were explorable and showed their contents when the URL was viewed. This was a huge vulnerability issue, as hackers could get information from files within directories to aid them in hacking the website. The httpd.conf file located in etc/httpd/conf was edited to disable directory listings. Viewing directories now shows a 403 error (“you don’t have permission to access this resource”).

Outdated PHP

WordPress had the following warning upon logging into the admin console: “Your site is running an insecure version of PHP (7.2.24), which should be updated.” As of August 2022, the recent version of PHP is 8.0.22. The original version on our server (7.2.24) was released in October 2019. As older versions of PHP are no longer receiving updates, using them is a huge problem as any vulnerabilities could be exploited. PHP was updated to the most recent version (“PHP – PHP: Releases,” n.d.).

No HTTPS

Our website is not currently using HTTPS, a more secure and encrypted version of HTTP. HTTPs not only protects your business, but your customers. It gives website visitors peace of mind by seeing your website is secure. In addition, many browsers will refuse to load websites that are not using HTTPs. This issue will be addressed in Milestone 2 (“Cloudflare – Why use HTTPS?,” n.d.).

SELinux blocking server emails

SELinux (a security module within Linux) is giving the following error when attempting to use email capabilities within WordPress: “SELinux is preventing /usr/sbin/sendmail.postfix from 'read, write' accesses on the file /var/www/html/home/wp-content/wflogs/ips.php.” This must be fixed as server email is necessary for Wordfence alerts and 2FA. This issue will be addressed in Milestone 2.

Additional website vulnerabilities found

Other vulnerabilities were found using the multitude of available scanners using Kali Linux. This was done to show how to strengthen our website to defend ourselves from future attacks. After discovering the numerous weaknesses on the website, we will continue to improve the site to get it in as secure a state as possible, as well as continue scanning for future vulnerabilities that may appear.

One scanner, called Nitko (“Nitko,” n.d.), was able to show us some of the undefined headers, and potential open database IDs. More specifically, this includes undefined X-XXS Protection, X-Frame-Option, and X-Content-Type headers, which leaves the current website open for XSS attacks and MIME sniffing. In combination with the already open Trace method, the website is also subject to a Cross-Site Tracing attack, if used in conjunction with the undefined headers previously mentioned. We have also discovered possibly open database IDs, which can be used for other injection attacks.

Another scanner, named Skipfish (“Skipfish - Penetration Testing Tool in Kali Linux,” 2022) was able to detect some HTML forms without XSRF protection and embedded external content. Putting XSRF protection in place can prevent normal users from being subject to mistaken actions while on the website. Embedded content can become subject to malicious scripts, that affect the content itself and the website hosting that content.

We also used Uniscan (Uniscan – Web Application Penetration Testing Tool,” 2021) .to look over possible vulnerabilities on the website. While the scan picked up some email addresses, we determined that they may be tied to the Uniscan service itself.

Wapiti (“Wapiti -- Automated Vulnerability Scanner,” 2021) was used as well to find a couple more weaknesses on the website. It was able to detect that there were some issues with the HTTP secure header and the Content Security Policy.

While we attempted to use WPScan (“WPSCAN Intro: How to Scan for WordPress Vulnerabilities,” 2021) to look over the website, we unfortunately faced some difficulties when trying to set up the scan. By design, it is supposed to look for vulnerabilities in WordPress specific sites, but it was not able to detect WordPress. We will continue to further investigate, to either get the scanner to work as intended, or find potential alternatives.

Penetration Testing

Before we begin penetration testing, we first needed to identify the most common attacks that could be the most compromising to our website. Since our final grade is based on the uptime, and integrity of the website against attacks, it is important that we protect ourselves from any type of external penetration from the other team. Penetration testing is the best way to prevent this, because in a way we are acting as intruders and protecting ourselves from them in the process.

DOS/DDOS attack

A denial of service, or distributed denial of service attack is where a web server is flooded with traffic, which can prevent real users from accessing a website. In some cases, an attack like this can cause a web server to shut down completely. We want our website to be active and accessible, so protecting our website from a DOS/DDOS attack is particularly important. It is also extremely easy to execute a DOS/DDOS attack, which is why it will be one of the first attacks we will use against our site during pen testing (“Paloaltonetworks -- What is a denial-of-service attack?,” n.d.).

Port Scanning/Port Attack

Port scanning is where an intruder or hacker scans open ports to search for vulnerabilities on a web server. Many of Kali Linux's pre-installed tools can easily find open ports and tell you specific vulnerabilities that can be taken advantage of in those open ports. Scanning the ports is simple, but finding vulnerabilities, and then taking advantage of them to gain access to the website takes research and planning depending on the complexity of the vulnerability. We do not currently know the skill level of the opposing team, but we will assume that that are highly skilled, and knowledgeable about port vulnerabilities, and we will perform our penetration testing with that assumption in mind (“ExtraHop - Port scanning attack - definition, examples, & detection,” n.d.).

Brute Force Attacks (passwords)

We predict a brute force attack on our login Information will happen soon after our IP is released, because if we have improper password protection on our webserver, it will be the easiest way for an intruder to gain access and do what they please to our website. For example, Kali Linux has built in tools to commit SSH brute force attacks, so after we create complex usernames/passwords, we will test these attacks on our website to reveal if our passwords are utterly secure or not (“Pentestit -- Brute-force attacks using Kali Linux,” 2020).

SQL Injection

Our webserver uses MySQL for the database, meaning that we are susceptible to SQL injection attacks. SQL Injection needs ample knowledge of the SQL language, and knowledge of database structure. Though it is one of the more challenging attacks to commit, it can also be one of the most damaging, because if an intruder has access to our web database, they can add, drop, or change information within the database which could be catastrophic. We plan on heavily researching and protecting our webserver database before pen testing SQL Injection (“W3Schools -- SQL Injection,” n.d.).

Challenges

Learning new tools

While Kali Linux has various tools that can help us with conducting scans in finding vulnerabilities on the website and server, it would be unwise to take what we find with just these tools and believe they are the only vulnerabilities possible. We decided to try and find different tools that are not already installed on Kali Linux as there is a chance that the pre-installed tools could miss certain vulnerabilities. This is where the challenge comes in regarding these new, unfamiliar tools.

When discovering a new tool that can potentially be an asset to our project we can run into various issues when attempting to use said tool. A few issues that we have currently run into are installation, executing, command line, and obsoletion errors.

In terms of installation errors, there have been applications that we have tried installing on to our Kali Linux machine and during installation we would receive an error about a missing file, directory, or import. These installation errors cause the application to be dead on arrival and no longer an asset for the group. When it comes to executing errors, applications will install successfully but throw errors upon opening and crash.

Now assuming neither installation nor execution errors have occurred, there is a final hurdle that can make or break the ability for a tool to be used, which is command line errors. There have been a few instances where an application will install and run correctly, but errors will occur within the tool itself.

Lastly, there is the dreaded obsoletion error. There are various open-source tools that have a great reputation but are no longer being maintained and updated. For example, Telnet is available, but due to being insecure, it was replaced by SSH and is now obsolete.

When conducting research for potential applications/tools that can be an asset to our project, there have been several open-source tools that would have been perfect to help in scanning and finding vulnerabilities. However, they now require a purchase, thus leading to having to find an alternative tool that can be just as effective while still being free to use.

Registering server

The challenges we ran into when registering on the server consisted of knowing we needed to create a Red Hat account, while the server said it was already registered. We had to .SSH into the terminal for the server and force an un-registration to the server. Once complete, we then created the account for our team on the Red Hat website. Once the account was created, we went back to the server and registered it to our account.

We ran the command subscription-manager register –force. Once entered, it asked for the account username and password for the Red Hat account created. We entered the information and got a successful message, and we could see the server was registered. It took a while to propagate in the Linux CockPit application, but the next day it showed up that the server was registered, and updates were available (“Linux man page – Subscription-manager(8)”, n.d.).

Working together as a team

One of the biggest challenges for any group project is working together as a team. Each team member has different strengths, weaknesses, perspectives, schedules, and expectations. In addition, our team faces a tougher challenge as we are working remotely, never actually meeting face-to-face. For the most part, our group has worked very well together. However, our biggest challenge has been with the delegation of tasks and balancing contributions among team members.

Time management

In addition to the above challenges of working as a team, time management has been a big challenge. Most in our group are working adults who are juggling both school and work. As we all are taking other courses as well, we must find a good balance of time spent on each of our courses while devoting adequate time to our capstone.

Communication with KSU to back up our server

To back up our virtual machine, we must contact someone at KSU to do it for us. Unfortunately, these backups can take up to a week or more to process, so we consider this a big challenge. Should the server go down during phase three and require a back-up to be used, we are unsure whether it could be restored quickly. Hopefully we never have to worry about reverting to a back-up.

Risks

Chance of breaking the website with an update

Every update or change has the potential to break the server or website if done incorrectly, especially while working with the terminal and root access. Using sudo commands can be tricky, especially for someone inexperienced in system administration. This whole process has been a big learning experience for all of us, and luckily, we never had the server break or had the need to roll-back to a previous version (knock on wood).

Potentially missing a vulnerability that can be exploited

Missing a vulnerability is a huge gamble towards the integrity of our website. Though we are not entirely aware of how much our opposing team knows about the vulnerabilities on the website, we must expect they know all of them. We will have to search as much as we possibly can for any and every vulnerability in case the opposing team knows of one that we were not aware of before our IP is released to them.

Misuse and/or not understanding our tools

If we are not able to fully understand the workings of our tools, it could be possible that we can have issues:

1. Tools not executing correctly

2. Not returning our desired results

3. Wrong commands attack/break our website unintentionally.

Leaving ports and SSH open

We are leaving the ports open for now, so the team can SSH into the server remotely from our computers. This way we can’t make the necessary changes to the server through a terminal and Putty. Once we’ve completed all we can with patching up the server and website, our team will talk about leaving the ports open or closing them. We would like to close the ports for security purposes, though we have always discussed the best decisions as a team during our meetings.

Gantt Chart

Based off the chart, one can see that the group has been holding and attending meetings and keeping constant communication, along with putting in the hard work to reach our goal of securing the website/server. Everyone is given specific roles that suit their strengths for the project. When we bring together the work we’ve done, we’ve been able to make an ample amount of progress regarding the project.

Conclusion

Our team made significant progress in identifying and fixing server and website vulnerabilities during Milestone 1. The main server updates yet to be completed are PHP, Maria DB, and Apache. In addition, we are still researching how to enable HTTPs and email on the server. With a month to go before the end of Milestone 2, we hope to have all server fixes completed within the next few weeks to allow plenty of time for penetration testing and research before Milestone 3 begins.