Ubuntu 1.0 Write Up
I will make new posts in the future that cover the changes made to this image from version to version. This post will have three main sections: the scoring system, an explanation of what I’ve done to it and how to fix it, and future plans for this image.
You can download a pre-built version of this virtual machine here (this version was built for Virtualbox and should have those guest tools installed. To get a version built for VMware, either build from the Packer template or contact me at email@example.com): https://files.gingertechnology.net/packersystems/BUILDS/CyberPatriot/
It is the one called UbuntuWeb-1.0.zip. The source code to build this image with Packer, as well as some brief instructions on how to do so, can be found here:
To see the README files for this image, go to http://localhost within the VM, and then open the post that says README.
The scoring system is the largest change from version 0.1.0 to version 1.0. It is now built in Golang, rather than being a plaintext shell script. There are also now more checks, it runs as a Systemd service, and the first time the virtual machine is started up it will randomly pick two forensic questions that will be placed in /home/administrator/Desktop. Currently the system only picks from a pool of three questions, so any suggestions would be greatly appreciated.
The scoring system can also be easily packaged into a .deb file, which is how I install it during the build process. So theoretically I’ll be able to do some cool stuff with it in the future. But for now it has to be built from the Golang source into an executable binary, and then put into the .deb package folder, and then built into the final .deb which is installed during the virtual machine’s build process.
The scoring system also is not modular in the slightest, but I think I’m going to leave it that way. I do have some plans for a more modular system for the CCDC scoring engine though.
Guide for Version 1.0 of Ubuntu
Starting Out and Taking Inventory
The account that a user will be using to solve this image is the “administrator” account with the password “UberPassword”. Upon logging in, I recommend doing a quick check of the system, for example seeing which services are running by using a command such as
ps -e and checking which ports are being used with a command such as
netstat -tulpn | grep LISTEN. After making note of that, I recommend then moving on to checking users, my preferred method for this is
cat /etc/passwd | grep sh, which will list out all accounts on the system that have a login shell containing the characters “sh”, which will include shells such as bash, csh, zsh, and dash. Any user that has one of those shells will be able to log in. One could do a similar check of
/etc/shadow to see which users have passwords, and I recommend doing both, but if I were to have to pick one, I would go with checking
passwd, since that will tell me which login shell the user has.
Update Mirror and Shellshock
After taking a quick inventory of the system, let’s get into fixing it. The most urgent matter in terms of much trouble it will cause in the future is that the version of bash that is currently installed is vulnerable to an exploit called Shellshock. This is being used to reboot the system every hour. To fix that, one can simply do
sudo apt upgrade bash… except that will fail, with an error saying that apt can’t reach the update mirror. So let’s fix that and then attempt the update again. The file that apt uses to determine which mirror to use is:
/etc/apt/sources.list. If we look in that file, it will reveal that the system is attempting to update from http://mirror.gingertechnology.net/ubuntu, which doesn’t exist. Changing that to a valid mirror, such as http://us.archive.ubuntu.com will allow us to update bash and fix the Shellshock vulnerability.
With the most breaking issue patched, let’s move on to adjusting user permissions. As stated in the README, the only users that should have sudo privileges are:
If any other user has sudo access, they should be removed from the sudo group. And if one of these users does not have sudo access, then it should be granted. To check who currently has access, we can use the command
cat /etc/group | grep sudo. The usernames that get listed currently have sudo privileges. To fix this, you can use the Ubuntu user manager, modify the file directly, or use the usermod tool. However you prefer, do that and fix the incorrect privileges.
Checking Installed Services
Next up, it is stated in the README that the only ways to access the server should be web, SSH, and FTP. The README also explicitly lists VNC as not being allowed, since the admin won’t need a GUI when connecting. To see if we have any VNC installed via the package manager, let’s try doing
apt list --installed | grep vnc. To check if any others remain, such as a VNC client or server that was installed from source files, one can modify the command used above to be
find / | grep -i vnc, with the “-i” making the search non-case sensitive. The downside to this is that:
- The search will through every file and folder in the system.
- It is possible that there will be cache files with “vnc” in the name
- The match does not have to be perfect. For example, let’s say that you use the exact command above, and in some part of the filesystem there is a folder that ends in “vn” and there’s another folder in that folder that starts with “c”. This will give a positive match, and will show up because it is technically “vn/c”. grep will ignore the “/”.
In the case of this challenge, only the
apt list command is needed, since I only installed a VNC server using apt, but it would be good to note the other method in case it might be needed in the future. With remote connection options limited to only authorized ones, on to securing them.
Securing Installed Services
SSH is a secure way of connecting to a remote Linux or BSD machine and is the primary method of accessing both. As such, it is important to make sure that its settings are set to be as secure as possible. You can open the file with nano, vi, vim, kate, etc. by doing
sudo (editor) /etc/ssh/sshd_config. The first change that should be made is switching from
Protocol 1 to
Protocol 2. 2 is a more recently made and secure connection protocol and is therefore preferred. Next up, since administrative commands are being given to this system via sudo rather than directly by the root user, we can set
PermitRootLogin to “no”. And you should set
PermitEmptyPasswords to “no”. While circumstances probably exist that would make it necessary to allow empty passwords, none exist on this system.
Now, let’s do some basic FTP configuration. Open
/etc/vsftpd.conf in your editor of choice, using the command
sudo (editor) /etc/vsftpd.conf. Near the top, disallow anonymous connections by setting
anonymous_enable to “NO”. One should also enable logging by setting
xferlog_enable to “YES”. Since only authorized company employees should be able to upload to and change files in on the webserver, disable anon_upload_enable. And finally, in the future the company will want secure FTP, so set
ssl_enable to “YES”.
If you haven’t already, try visiting a search engine such as Google, duckduckgo, startpage, or Bing. Notice anything odd? Depending on which one of those you picked, you’ll either have been routed to localhost or never made a connection. This is because of what we are about to fix. In the hosts file (
/etc/hosts) you should at the bottom of the file something like this:
The way a hosts file works is that it sets the domain names on the right to be routed to the IP address on the left, with 0.0.0.0 meaning localhost, and 126.96.36.199 being a random IP address that won’t connect you to anything. To fix these issues and regain the use of search engines, you can just remove these lines and either reboot the virtual machine or restart the networking service.
New in version 1.0 of this image are checks to see if WordPress has been at least partially secured. These checks require that WordPress be update and Wordfence be enabled. To do this, go to http://localhost/wp-admin and log in with the same credentials used to access the administrator user account. First let’s update WordPress, which should an option that is available through the Dashboard tab. All that should be required is clicking that button and the rest is handled automatically.
To enable Wordfence, go to the Plugins tab, checkmark Wordfence, and then have WordPress enable the plugin.
Future Plans for This Image
Going forward with this image, I plan to get more in-depth with my checks and have more of them. For example, right now I do not check the MySQL or user passwords to make sure they have been made more secure, but I have plans to look for both. I’ve decided that I will probably leave the CyberPatriot scoring engine non-modular.
Thank you for reading and I hope you make good use of this image! If you have any feedback, feel free to comment and I’ll make sure to reply so that we can discuss any problems or ideas that you have.
Have a lovely day!