Attack Phase

w01ct2_attackpresentation.mp4

Attack Phase

Week 1: Wed Oct 26 – Sun Oct 30

On October 26, our group was given the information for our target of the final phase of our project, the attack. Some of our team began scanning the target server with our tools immediately as we wanted to get a head start. We were expecting things to take time, unsure if we would even be successful. However, before we got too far into scans, we decided to check the basics first as you never know when something simple could be overlooked.

When our servers were assigned to us, we were given default usernames and passwords. Upon accessing the server for the first time, we immediately changed them. Unfortunately for the target of our attack, they did not. Less than 30 minutes after we got their IP, we had successfully logged into their root via Putty.

We thought about deleting everything then and there and calling it a day, but we decided to go a little bit further. Root’s password hadn’t been changed, but what about WordPress? The other team had hidden their login page using a security plugin, but with SSH access, we deleted all plugins and were able to access the login for the administration console. The original username and password worked. In addition, the other team had uploaded their Milestone 1 project documents to their media library.

From this point on we began changing the different passwords on the server, including root, administrator, and ksuitg5 (WordPress). We also created SSH keys to allow us to access the server as a backup in case the other team managed to get back in and change passwords. We translated and changed all the text on the website to pig Latin and created a post with a Rick Astley “Rick Roll”.gif. While we were about to delete the website and shut the server down anyway, we wanted to take screenshots and video as proof that we got in (and to have a little fun with it). By eight o’clock the other team’s website was offline.

Our target’s website remained offline for the duration of the first week of the attack phase. We continued to actively monitor both servers, and never noticed any downtime or issues with our own.

Day 1 Timeline (October 26, 2022)

  • 2:06PM – We were given the target IP of the opposing team: 10.96.33.169.

  • 2:11PM – We discovered the WordPress administrator name was not changed nor obscured on target’s website. KSUITG5 was listed as the author of recent posts.

  • 2:13PM – We discovered the opposing team hid the WordPress administrator login page.

  • 2:17PM – We scanned the target with WPScan.

  • 2:29PM – We verified SSH was open by trying to connect to the IP via Putty.

  • 2:30PM – We successfully logged in to SSH with default username/password via Putty:

      • o Username: root

      • o Password: cyberadmin01

  • 2:52PM – We downloaded important files off the target server, such as the contents of the /home, /www, /etc and /log directories.

  • 3:00PM – A SSH key pair was created and added to target server to allow our team to SSH to their server from ours, in case we lost access (“Ellingwood & Boucheron – How to configure SSH key-based authentication on a linux server”, 2021).

  • 4:30PM – We changed passwords for root and administrator.

  • 4:49PM – We scanned the target with Legion.

  • 5:06PM – We activated and logged into their CockPit web console and found evidence that the other team never used it (“Red Hat Customer Portal – Getting started using the RHEL web console red hat enterprise linux 8,” n.d).

      • o Last login: August 31, 2022.

      • o Not registered with RHEL.

      • o Server uptime: 2 months. The server had never been restarted.

  • 5:19PM – We scanned the target with SkipFish and SQLmap.

  • 6:05PM – We began to focus on WordPress, checking out installed plugins:

      • o All In One WP Security and Firewall

      • o Really Simple SSL

      • o UpdraftPlus

      • o WordFence

      • o WPS Hide Login

  • 7:10PM – We deleted the WordPress /plugins/ folder to deactivate their plugins (most importantly WPS Hide Login and WordFence) (“WPBeginner -- How to deactivate all plugins when not able to access WP-admin,” 2020).

  • 7:13PM – We logged into the WordPress administration console the with default username and password:

      • o Username: KSUITG5

      • o Password: Kennsaw123!

  • 7:14PM – We changed the WordPress administrator password.

  • 7:23PM – We discovered the target team had uploaded their Milestone 1 documents to the WordPress Media Library (such as their Project Plan, Milestone 1 Report, Gantt Chart, and Weekly Log).

  • 7:35PM – We scanned the target with OWASP ZAP.

  • 7:45PM – We defaced the target’s website for fun (changed all text to pig Latin and added a “Rick roll” post).

  • 7:50PM – We performed an attack using goldeneye to test the limits of their server against a DOS tool.

  • 8:10PM – We deleted the target’s /home/ folder.

  • 8:10PM – Target offline.

Week 2: Oct 31 – Nov 6

At the start of week two, our team remained on alert, ready to act should the status of either site change. If the other team regained access to their server, how they did so (and how quickly we reacted) would determine our next steps:

  • If they got it back without reverting to a backup or a complete reinstallation (unlikely), our team would use our saved SSH keys to log back into the server and attempt to take it back.

  • If they got it back through a backup or reinstall (likely), we hoped with our active monitoring of their server that we would be able to login, change passwords, and reinstall SSH keys before they even knew the server was back online.

  • Another quick option would be to delete the aios-bootstrap.php file in their /www/html/home directory. This file was generated with one of their WordPress security plugins (All-In-One Security), and it warns not to delete it because it “will cause PHP to throw a fatal error and render your site unusable.” They would likely be stumped as to why their website was down, as it is not a standard WordPress file. If done first, this could also act as a distraction while our team resecures the server.

  • If they got it back and changed passwords before we had a chance to react, we would resume our original plan as laid out in Milestone 2:

a. Scan for vulnerabilities with our tools

b. Perform network attacks (such as Denial of Service)

c. Perform database attacks (such as SQL injections, cross-site scripting)

d. Attempt to crack passwords (with brute force, dictionary attacks)

Had that been unsuccessful, we would launch a social engineering attack using the contact information we found uploaded to their WordPress Media Library. We would attempt to gain access to their method of communication, and hopefully get the credentials we would require to access their server.

Our website remained online for the entirety of week two, while our target remained offline. Wordfence blocked multiple cross-site scripting attack attempts on Sunday, November 6th, but otherwise detected no other attacks.

Week 3: Nov 7 – Nov 14

Our website remained online for the entirety of week three. Unfortunately, our competitors never got theirs back up. To be honest, we are unsure why as they should have had a backup plan in place. If they had thought to ask for one, KSU’s IT department could have reverted their server to a backup. If not, their WordPress backup plugin (Updraft Plus) stored full site backups on the cloud. While it would have taken significantly more work, they could have had the server completely reinstalled, reinstated previous security fixes, and restored their website through Updraft Plus (“Owens – UpdraftPlus backup/restore with WordPress”, n.d).

Wordfence Logs

During the two and a half weeks of the attack phase, Wordfence blocked six cross-site scripting attack attempts. The IP address of the attacker (172.27.17.103) was immediately blocked from accessing the website for 12 hours. No other attacks were detected via Wordfence. We were surprised at this, as we expected many more web-based attacks. We can only speculate possible reasons:

1. Wordfence was not accurately logging – which is possible, but given the popularity of the plugin, we have full confidence that the plugin was working accurately.

2. There may have been some limited functionality due to the private server – We have had multiple issues with other tools not working as intended because the application could not interface with the private IP. However, Wordfence had previously blocked over 600 requests during our own testing during the first two milestones.

3. This was the only attack attempt made to our website – Unlikely, but not impossible. We made significant efforts during the first two milestones to harden the WordPress installation and fix any vulnerabilities. With removing comments, using Wordfence, and enabling 2FA, we are confident that our site was well protected.

4. The opposing team was also using Wordfence and knew its capabilities. It is likely they saw the plugin installed and did not attempt attacks they knew would fail.

Post-Attack

Due to our server’s consistent uptime, as well as the opposing team’s quick dispatchment, we planned on attempting to attack our own server when the attacking period concluded. We wanted to see if there was anything that the other team missed, as well as get a chance to perform some red team testing on a well defended server.

During this period, we attempted to avoid interacting directly with the Akwaaba site. We knew that Wordfence was active and figured that trying to mess with the site directly was meaningless. The site’s version of WordPress is also up to date, and with 3 supported plugins, we did not have many possibilities when it came to exploiting vulnerabilities. With the limited time we had while we could still investigate the server, we also wanted to avoid the 12-hour block period.

We attempted to attack the server directly, seeing if there were any vulnerabilities with what we set up. We first tried to see if we could somehow exploit the PHP version using PHP CGI Argument Injection, where the tool Metasploit was used to assist us. In practice, Argument Injection allows attackers to enter the server by sending through values and/or text without sanitization checks (“Argument injection and getting past shellwords.escape”, n.d). However, this vulnerability only exists for PHP versions 5.3.12 to 5.4.2, so it did not work for our current version.

We then wanted to see if we could exploit port 80 into giving away information about the server, mainly seeing if we could access the /etc/ directory. When including “/cgi-bin/” in the url to our site, we do see a forbidden access message, letting us know that it does exists. However, when using the curl command to include “/cgi-bin/.%2e/.%2e/etc/passwd” on our site, we get a connection refused message, meaning that we were not able to view the desired content.

Our target was now the Apache version itself, as there are CVEs available that can exploit version 2.4.37. We used Metasploit again, seeing if the tool can call the CVE to exploit Apache. However, the tool that we were using only had 2 CVEs available for a later version of Apache, meaning that this attempt was also unsuccessful.

With more time, it is possible that we could have been able to break into our server. In preparation for the attack phase, we’ve put in a lot of time and research into having our application withstand as much as possible. Luckily, our main attackers were not able to take down our system, but that doesn’t mean that our server is completely unbreakable until the end of time. Technology grows day by day, as well as the skill level of attackers, it is highly probable that with enough time and dedication, an attacker can either completely bypass Wordfence or find the right tool to break our Apache, PHP and/or MariaDB versions. If this server was something that we had to defend for a longer period, it would be wise to grow our skill levels as well and monitor and update our systems to be as secure as can be.

SSL Update

During the first two phases of the project, our team attempted to install an SSL certificate on the server but was not successful. However, after speaking with Professor Privitera after our final presentation, we decided to give it one more shot. After some more research, we successfully installed a self-signed SSL certificate on our website. Unfortunately, the website still warns of being unsecure even though HTTPs is active as the certificate is not technically valid. While we did not get this installed in time for the attack phase, we wanted to say we did everything we could (“Boucheron – How to create a self-signed SSL Certificate for apache on centos 8,” 2020).

Recommendations

Over the course of this project, we have implemented many updates and security fixes to the server and the WordPress installation. We may have missed some things, but we know our website uptime speaks for itself. During the two and a half weeks of the attack phase, our server never went down. While we believe everything we did contributed to the strength of our server, here are what we found to be the most important:

1. Use strong and unique passwords - It should be no surprise that the first recommendation is to change the default passwords and to enforce a proper password policy. Passwords should use a long random string of letters, numbers, and special characters. In addition, no password should be reused, and they should be changed often (every six months minimum).

2. Enable Two-Factor Authorization – 2FA can come in many different forms, such as asking to enter a verification code from SMS or email upon login, an app-based notification asking the user if they intend to login, or a physical key. Each method comes with its own pros and cons, but it is better to use one of them than none. We successfully enabled 2FA for our WordPress administration console, and had we kept SSH enabled during the attack phase, we would have added it to root as well.

3. Update everything – Anything that can be updated, should be updated. Apache, PHP, WordPress, etc. Not updating can open the door for hackers to gain access through vulnerabilities.

4. Utilize backups – Both server and WordPress backups. Should your site go down, you should have backups and a plan in place to bring it back up as quickly as possible.

5. Use WordFence (or another trusted security plugin) and a Firewall – WordFence is the most recommended WordPress security plugin. It protects against many different types of attacks as well as IP blocks for different scenarios.

6. Enable HTTPS – Unfortunately, we could not enable HTTPs on a private server. However, it is recommended for a live website as it adds a layer of encryption which increases your website’s security (and puts visitors at ease).

7. Test for vulnerabilities – Like updates, your website and server should be regularly checked for vulnerabilities. Nothing is truly impenetrable forever, new technology and methodologies are being developed every day to exploit even the most secure systems, it’s best to continuously test and patch up weaknesses.

8. Monitor – Whether you monitor the site yourself or through an application, the server should be monitored regularly for downtime, unauthorized changes, irregularities, and access.

9. Have a plan – Have a plan in place if something goes wrong so you’re not fumbling if/when it happens. Having a risk management plan to cover if something goes wrong, what are the chances of it going wrong, and how to recover from it ultimately saves a lot of time and stress when developing any project.

10. Don’t publicize usernames – Hackers need both a username and password to log into accounts. By making usernames public, you have already done half the work for them. Instead, utilize nicknames or aliases on publicly facing websites.

11. Train users – Users should be properly trained on important security topics, such as proper passwords, identifying and avoiding social engineering, and phishing. As users are the ones that commonly use these systems, and are the weakest link in security, it is best to minimize the chances of a user doing something that will allow something malicious into the system.

Gantt Chart

This is the final Gantt chart for our group that shows the progress of our project. This helped us keep up with the most important aspects of the project. Our team’s communication was one of the best parts of the group. We understood the assignment and wanted to show on the Gantt chart the main parts of the project.

Conclusion

While we made many changes to our server during the first two milestones, we believe we can attribute our success to our fixing of vulnerabilities, the use of Wordfence and the enabling of two-factor authorization. Wordfence detected and blocked a few attacks, but our competitor was not successful in breaching our defenses or taking down our server.

Our competitor spent a lot of time working toward securing their server, including installing multiple WordPress plugins to add security, hiding the administrator login page, and creating backups. However, by gaining root access to their server through their own accounts, our team bypassed all their security. Had they changed passwords, we would have had a difficult time breaching their server, and it is likely that we may not have gotten in at all. This just goes to show that humans really are the weakest link in cybersecurity.