Assignment 5‐1 Availability and Redundancy Security Reflection - jacobwilliams100/sec-440 GitHub Wiki
Problem 1: MariaDB Remote User Wildcard
Web01 and Web02 both use the MariaDB user 'remote'@'%' to access the MediaWiki database. The '%' indicates wildcard host, meaning it can connect from any host, meaning that if someone on a host outside the LAN subnet can open a MariaDB client connection to u1, 2, or 3, and could obtain the password (either by social engineering or brute forcing it, MariaDB does not support lockout after failed attempts) then they could use 'remote'@'%' to steal, change or delete Wiki data.
Solution 1: Dedicated Users for web01 and web02
Instead of web01 and web01 sharing the 'remote'@'%' MariaDB account to access the MediaWiki database, Create two new MariaDB users, 'remote1'@'10.0.5.100' and 'remote2'@'10.0.5.101' for web01 and web02 to use respectively, and delete the 'remote'@'%' user. You can change web01/02's MediaWiki database credentials by editing /var/www/html/mediawiki/LocalSettings.php. This change would make the remote accounts only permitted to connect from 10.0.5.100/101 (web01 and web02) limiting database access to the legitimate clients.
https://virtual-dba.com/blog/mysql-user-wildcard-and-localhost-hosts/
Problem 2: Vulnerability to VIP Spoofing
An adversary on the WAN network could configure a device to claim the same address as the WAN VRRP virtual IP in order to intercept traffic intended for the legitimate VRRP virtual IP. Not only would this disrupt legitimate VIP traffic, but the adversary could also analyze the traffic to gain sensitive information such as MediaWiki passwords.
Solution 2: Enforcing SSL/TLS to secure traffic
Using a self-signed certificate (since this is not a public-facing environment), you could enforce the point-to-point encryption of web traffic between WAN users and the web01 and web02 webservers. The underlying Apache configurations would need to be modified to enforce HTTPS traffic only, the firewall rule would need to allow port 443 too. The VYOS WAN-to-LAN NAT rules would need to be changed from port 80 (HTTP) to port 443 (HTTPS). And lastly, the HAProxy configuration would need to bind to port 443 instead of port 80. However, once set up, it would require all clients to connect using SSL/TLS encryption, preventing VIP spoofers from intercepting sensitive information such as passwords.
https://nordvpn.com/blog/ip-spoofing/
Problem 3: Security vulnerabilities with MediaWiki 1.34 (Old Version)
During setup, I had a very difficult time upgrading my web servers PHP version past 7.2, which was required for the newest version of MediaWiki (1.42). I spent so long on this task that I eventually gave up and chose a workaround, which was choosing an older MediaWiki version that runs on PHP 7.2. While this version functions, it has several glaring vulnerabilities that "allow an attacker to leak page contents from private wikis and bypass edit permissions" (Medawiki 2021-12 security release/FAQ)
-
CVE-2021-44858 involves exploiting the 'undo', 'mcrundo', or 'mcrestore' function, allowing an attacker to view page revision information without permission, even on private wikis.
-
CVE-2021-45038 involves exploiting the 'rollback' function to view the contents of any page without permission.
-
CVE-2021-44857 involves exploiting the 'mcrundo' or 'mcrrestore' function to copy the content of any revision and save it to any other page, overwriting its content, all without permission.
Solution 3: Replace web01&02 with newer Rocky VM (With New Versions of PHP and MediaWiki) or Use Recommended Workaround
The best way to deal with this vulnerability is to simply update MediaWiki to the newest version (1.42) which has long since patched these vulnerabilities out. However, this goes back to my original problem of being unable to upgrade the PHP version on the deprecated CentOS 7, so I think the best solution would be to rebuild web01 and web02 with MediaWiki 1.42 on Rocky Linux 9.4 instead, which includes the required PHP 8.2 in its default repositories. The database content would not even have to be migrated because u1-3 are already running the compatible MariaDB server version 10.6.
A more expedient option would be implementing MediaWiki's recommended workaround of editing LocalSettings.php to disable the 'mcrundo' and 'mcrrestore' completely, on both web01/web02. This would be much faster, but could potentially leave MediaWiki open to other security exploits.