"I'm Not Crying, You're Crying," a CTF Project Build
Published: 2023-08-14 04:12:35

Hi there!
My name is JD and last year I decided to make a huge career change and jumped head long into attending a Cybersecurity Bootcamp program through the University of Irvine, California. Why did I do that, you might ask? Well, to be completely honest… I have no idea. Okay, that’s not entirely true. I’ve always been a little interested in cybersecurity but just never pursued that interest. Until now. So, what made me change my mind and start investing in it? Well, it wasn’t anything as interesting as doomsday prepping or alien invasion prepping or rise of the machines prepping (wow lots of prepping). No, really, it’s because I needed a career change. It’s the same old tried and true story of being in a job that doesn’t pay enough and doesn’t fill me with a sense of satisfaction. 
So, wide eyed and bushy tailed, I enrolled myself in a Cybersecurity boot camp. And you know what? I really enjoyed it. I especially liked the Capture the Flag (CTF) sections. So, for my final class project I decided to try and build my own. It was something I thought would be challenging and also help me dive deeper into the pandoras box I’d opened up. And boy was I right. It was not easy. And there was so much once I started digging. SO SO MUCH. But I kept at it and managed to complete about 75/80% of the project. I took notes throughout the whole thing and I’m sure if you’re reading this, you might read over them and think “wow, what a newb” and you know what? That’s 100% true. But I’m trying. And I’m having fun while learning and isn’t that the point? 
So *knuckles cracking* let’s get into it shall we?
First things first, I made a list of what tools I would need and what flags I wanted to do. 
Items needed for Project 4:
	PowerPoint for Class Presentation
CTF Questionnaire Sheet (Excel)
	GitHub Repository
		Contains:
	First clue 
	Access to CTF Sheet
 
     Kali Linux (host box for attacking) (create using Oracle)
     Ubuntu (target) (create using AWS)
	Flags:
	Create flag for user
	Create flag for root
	Create ftp flag
	Create apache flag
	Create docker flag
	Create Caesar cipher flag												
     Windows (target) (create using AWS)
	Flags:
	X Create Apache tomcat flag
	X Create smb flag	
				
     Splunk 
	Flags:
	Log packet flag

I bet you saw those x’s under the Windows machine, huh? Oh, don’t worry, we’ll get into it. It’s probably the reason why any hair I had left is now just dust in the wind. 
Anyway, after I got my list together, I started researching online to see if anyone else had ideas on how to start building a CTF. I found a few great resources that really helped me out:

Building a CTF
https://infosecwriteups.com/how-to-make-our-own-ctf-challenge-with-ease-6b15f76865b5
Hacking Windows Machines
https://medium.com/hacker-toolbelt/metasploitable-2-iv-port-80-5b90a0a22cb6
https://nudesystems.com/how-to-setup-a-virtual-hacking-lab-virtual-box/
Building a Docker Image
https://devopscube.com/build-docker-image/

Those were some of the main ones I used but there were lots more articles I skimmed though and I even occasionally used ChatGPT (yes, the evil AI overlord – who’s actually pretty cool, you just have to treat it well and always do a quick fact check on any info it gives you). I mostly stuck to that first link to guide me through a majority of what I was doing when it came to the Ubuntu machine. Maybe ttweeking it here and there to make it work for the flags I wanted. 
After I had created my Github repository and my CTF excel sheet (both of which would be the easiest part of this entire thing), I then started with my Kali Linux creation. I went to the Kali Linux website for the file download (https://www.kali.org) and then booted up my Oracle VirtualBox and clicked on “New” to create the machine. I named it KaliLinux (original, I know) and chose Linux and the following configurations: 

- 64bit version
- 2 GB of RAM and 2 CPU (recommended)
- I didn’t select the downloaded kali ISO version YET
- Create a virtual hard disk

Once the machine was ready I clicked on “Settings”, navigated to the "Storage" tab and clicked on the empty CD/DVD drive. In the "Attributes" section, I clicked on the CD/DVD icon and chose the Kali Linux ISO file. When I started the machine, it proceeded with the Install for Kali. The install came to a screeching halt when it asked me about “partitioning disks” and even though we had just researched that in class during our first Forensics module, I still had no clue what it meant so I researched it. I found out that partitioning is dividing a hard drive into separate sections to keep things organized, protecting the data and enabling different operating systems to coexist on the same computer 
Most people recommended “guided partitioning” for new users, so I chose that and then proceeded with the preset options. And voila, at the end I had a perfectly functioning Kali Linux machine – SCORE!
Next up, I decided to create the Ubuntu target machine. In class we mostly focused on Azure for hosting VM’s but our professor also showed us how to use AWS so we could expand our skills, so I decided to use AWS to host both my Ubuntu and Window machines. Still following the guide, I selected the 20.04 Ubuntu Image and made sure to allow for SSH, HTTP and HTTPs on my security group settings. Once the machine was operational (and I can assure you that this space station is “quite operational”) and I set up my initial user ID and password I then went on to granting root access to myself by using sudo -I passwd root and creating a new password that only I would know. After that I created the root flag, placed it in a file called ‘sensitive_info.txt’. I changed the permissions to make sure that only the root user could access it and double checked my work by logging back in as my original user and attempting to read the file only to be DENIED (which is a good thing in this case). 
I then created the user flag that would be viewable at a user level, but I didn’t want it to be quite that easy, so I also hashed it using a md5sum hash. We had covered things like hashcat and john the ripper in class, so I wanted those to come into play when trying to uncover the flag. 
Continuing along with the guide, it said to enable an Uncomplicated Firewall (also known as a UFW or also known as a pain in the @ss as I would come to find out shortly). We wanted to do this to allow permissions for things like FTP, Apache, open ssh, etc. I first installed the UFW using apt install UFW command but what I should’ve realized – and spoiler alert, didn’t – was that I needed to edit the rules to enable SSH and FTP ports BEFORE activating the firewall. Which I didn’t. And I was immediately locked out of my instance. I tried every troubleshooting technique I could and was unable to find a way back in, so in the end I just created a new instance and redid the following work from the first part. The second time, I made sure to enable the appropriate rules, and everything went smoothly. That was until I started working with FTP. 
According to the instructions, I needed to install the FTP service because that would be our point of entry from the Kali machine to Ubuntu machine. I did so and after that, I had to change the following things: 1) allow for anonymous login to ftp, 2) define a directory for the ftp and 3) disable the login password for anonymous users. Navigating to the /var directory, I created another directory name ‘ftp’, then changed ownership of that directory to nobody:nogroup using the chown command. In Linux, the "nobody" group refers to a special system group that is used to represent unprivileged or anonymous users. It is typically used for running processes or services with minimal privileges and restricted access rights. We then created a file named ‘ftp_secure_info.txt’ and put a flag in it and also changed the ownership of that to the nobody:nogroup as well. 
It was at this moment that I hit my first real HEADACHE. I thought I had made sure to enable ports 20,21 and 22 for ssh and because ftp uses 2 ports (21 for control connections – sending commands and receiving responses between client and server and 20 for transferring actual data between the client and server) but when I tested the FTP connection on the kali machine, it didn’t work. I double checked the inbound rule settings and saw port 21 wasn’t open for connections so I fixed it and tried again. This time it worked but I started receiving a 500 Illegal PORT command error when trying to use basic commands (like ls -la) while in FTP. I researched … and researched … and researched… then raged a little – okay maybe A LOT -  because every work around people suggested just didn’t work. Every attempt, every rule change, everything failed. EVERY TIME. In the end, the only thing I could do was disable the UFW. Only after that could I get the FTP to connect and work correctly. 
After that nightmare inducing 24 hours, I moved on to downloading Apache. That process was a breeze in comparison, and I was able to easily install it. I then went into the Index.html file and edited it to plant the flag inside the header of the Apache landing page. I also changed the listening port to 8080 because my Docker container was going to run nginx (I’ll talk about that later) and I didn’t want them to have port issues. 
I decided to take a crack at creating my first Docker container (you know, just a little DevOps going on, nothing to see here). I followed the instructions from the website I linked above. First I created a nginx-image dir, and a hidden file .dockerignore inside of it, then I created a files dir inside the image dir. From inside the files dir I used VI to create a basic HTML file – index.html. and pasted the flag in there. Next I used the dockerfile provided on the website I was reading along with for creation. The only thing I did was change the maintainer label since it isn’t really required. I then went to build the docker image but realized I didn’t even have Docker installed (YES, I can hear the resounding “NEWB” from here).  Soooo I installed it and then proceeded with the image build. After all my work, I went to run the docker image but DUN DUN DUN, received a weird hashing response and no webpage. When I checked to see if the image was running, there was nothing there. Going through more troubleshooting with ChatGPT and different forums, I couldn’t make heads or tails of what was going on. I ended up uninstalling docker and nginx and trying again. This time the container seemed to be running but when I went to the webpage there was nothing. Yet again, more troubleshooting. It turned out I needed to be running the command: docker run -d -p 9090:80 nginx, to start a new container from the nginx image in detached mode (-d) and map the port to 9090 of the host to port 80 of the container. I did that and success! I got a webpage and a flag!
I went back to the Ubuntu machine to start doing some finishing touches on things. I added directories under the users to make it look like these were working computers. I also needed to remove sudo access from one of my users and this ended up being another pain. I did the usual deluser ubuntu sudo and removed them from the group but they were still able to use sudo. After much digging, it turns out they had a passwordless rule for sudo hidden in the sudoers.d/90-cloud-init-users and on top of that they also had a rule that anyone part of the adm (admin) group could still use sudo so I had to remove the user from that too. 
I also created a scripting flag because I had a lot of fun doing scripts in class. I created a hidden directory using mkdir .scripts and then did a simple script that would ask the user the following question: “Which layer of the OSI model is responsible for establishing, maintaining and terminating connections between network devices?” I coded the script so that if they answered correctly, it would generate the flag. 
The final flag I worked on was the Caesar cipher flag. This one was the easiest compared to the rest. I created a directory named “Et Tu Brute” to give the user the hint that the message inside would need to be decoded with a Caesar cipher. Inside I wrote: “xli jpek reqi mw 'geiwevjpek'” which, when using the correct cipher … well, I’ll let you figure out what it says (bruhahaha).
At this point I was happy with the Ubuntu machine and needed to move on to creating my Windows machine. In class, we had exploited a couple of different vulnerabilities that I decided I wanted to recreate. The first was SMB. SMB essentially signs each packet with a digital signature so the client and server can confirm where they originated from as well as the authenticity of the call. In an SMB relay attack, the attacker tricks the client into connecting to the attacker's machine, which then relays the connection to the actual server. The attacker can then gain unauthorized access to the server using the client's credentials. This seemed to be the best way to infiltrate using Metasploit and based on recommendations I found online.
 When I built the machine it looked like SMB was already configured so I didn’t need to worry about that. I popped up my Kali and did an nmap scan in order to check what ports were open (even though I knew I had already opened 3389 on my AWS security groups – and YES, I know now this isn’t the port to use but hang on, I’m getting there) to test my Metasploit attack. Bingo, sure enough there was 3389 in an open state, so I brought up Metasploit and proceeded to use the eternalblue exploit. I plugged in all the necessary info and BAM, executed the attack. 
Only to get BUPKISS. No session created. 
 This led to another foraging session online and from what I read its because SMB uses … wait for it… yup, port 445. So, I added that to the security group on my ec2 instance and tried again. But still nothing -I simply kept getting the same No session created error code. After hours of trying to get it to work, I finally gave up and looked back into our class modules on Windows hacking. Another vulnerability we exploited during our session was an outdated Apache server. So, I decided I would try going that route. However, as I’m sure you can guess, it wasn’t just as simple as downloading the Apache service. Ohhhh no. 
First, I had to figure out which version of Apache we had been exploiting during our session. In the material it had notated that the version was Apache Struts 2.3.5 – 2.3.31. This confused me a little though because I had remembered tackling a vulnerability with Apache Tomcat too. I didn’t quite understand that Struts and Tomcat were actually two different things and after doing research I found that Tomcat is a web server and servlet container that provides the runtime environment for executing Java web applications, while Struts is a web application framework that helps structure and streamline the development of Java-based web applications. So, in my case, having both downloaded was necessary anyway as Tomcat provided the runtime environment for deploying and running my Struts-based web application and Struts is what we needed to exploit.
But here’s the other caveat – the versions we were exploiting are older ones, which meant I couldn’t just download the most recent files available on the websites.  Nope. After LOTS OF INTERNET SEARCHING, I finally found all the versions I needed and downloaded them. After all that, I once again went through Metasploit and tried the Apache exploit we had used in class. 
And once again, NADA. Another error saying no session created. Another issue was the machine had started to run extremely slow. It was like a washing machine moving through quicksand. At one point it was so bad, I ended up deleting the entire instance, creating a new one and downloaded all those services again. And still, no session was created to show for my work. 
I was really running out of time to get my project completed and ready to demo for our last class so in the end I decided to scrap the Windows machine altogether. The last flag I created was a flag for Splunk and after the terrible tragedy that was the Windows machine, I was relieved that it was relatively easy. I simply found some testing logs that Splunk provides and downloaded one. Inside the file I inserted a flag and the IP address for the Ubuntu machine so that when you performed a search through the log by the IP address, the results would also pull up the flag under that line. 
I managed to complete far more of the project than I was expecting. Especially when you consider the fact that, coming into UCI’s bootcamp, I had no prior computer experience other than the average joes. The entire project wasn’t easy, and there was a point where my wife asked me “Why are you crying?” and she probably didn’t appreciate it when I responded, “I’m not crying, you’re crying,” instead of answering but all in all, it was a lot of fun and very rewarding. My professor really liked my project and I graduated with a pretty good grade (technically it was pass /  fail but you could still see your overall percentage and mine was not too shabby if I can humbly brag for a second).  Another thing the project opened my eyes to is the expansive field that cybersecurity offers. I had gone into class wanting to focus on digital forensics, but I really enjoyed building the Docker flag and now I’m considering looking at DevOps. So, I guess the only thing left to say is, keep going. It doesn’t matter if you know what you’re doing or are a self-proclaimed NEWB, there’s always something new to learn… and make sure you enjoy the ride.