Menu
close
The NorthSec Challenge 2021 ran from May 21-23, 2021. According to the event page, the challenge is a ‘Capture the Flag’ style event in which the flags are typically secret messages hidden in different challenges. Teams compete to have the most points on the leaderboard.
Similar to the NorthSec Challenge 2021, Software Secured offers private, instructor-led corporate security training to software development teams. Part of the instruction is getting the software teams to compete in a capture the flag game. Learn more about our training offering here.
Robert Babaev from the Reshift Security team participated in the NorthSec Challenge 2021 and shared his write-up online after the event. He has granted permission for Software Secured to share the write up below, as an example of what a Capture the Flag game might look like for a corporate security training.
This write up by Robert Babaev was first published on May 27th, 2021.
This challenge put the hackers up against a set of three boxes, each with an ssh port open and interlinked by an apache server. This challenge was an interesting look into how to turn a defender’s own defenses (and hubris) against them. Flags one and two were snagged by Robert, and Forest had a hand in the third one.
NorthSec 2021 was themed after medieval fantasy, with hackers being elite mages. The “king” had requested we poke around his siege defense system and see if we could break it. We had three targets: central-dovecote.ctf, eastern-trebuchet.ctf, and southern-ballista.ctf.
Step one of any hack was knowing what you were looking at, and luckily we were given a good bit of info going into this. The homepage of the Dovecote box had a set of configuration packages available for download, one for each box. Additionally, it had an alert box which would print out various alerts when prompted by the system, likely to log logins or page requests. Useful.
Additionally, an nmap scan of each box didn’t reveal much beyond the obvious: three HTTP ports, three SSH ports. Nothing more, nothing less. It was clear the bulk of this operation would be contained in those configuration packages.
I spent a good while poking around the configuration files and structure of each box, fiddling around a bit. I eventually landed on this file, write-file.sh, inside the Trebuchet box:
Looked promising. I spent about 20 minutes trying to URI encode what I thought was the URL, eastern-trebuchet.ctf/[email protected] Then I looked up what the sed command did, and realized that the URL was actually eastern-trebuchet.ctf/getflag. Okay, cool, handy search and replace function, I put that in my back pocket. The URL got me to a plaintext environment with “FLAG-” written in it. Now, how exactly did I get this script to trigger?
That was the work of another file. Under the Dovecote box’s configuration, specifically the rules folder, I found web_rules.xml:
Combine that with ossec.conf under the etc folder, and I could get a pretty good picture of what I had to do (file snipped):
In summary, if you requested the /getflag URL 3 times in under 10 seconds, rule id 102 would trigger and an alert would display in Central Dovecote. Rule id 102 would then trigger the write-file command, which conveniently activated write-file.sh. Request /getflag one more time, and you had your output. Flag one done and dusted!
After playing around with non-standard remote code execution methods, you really start to appreciate having a shell in your hands. Without spoiling too much, this was one of the former, and I was so happy to have a shell after it.
Poking around Southern Ballista’s config file, I found a few things. Under the main server rules, an unauthorized SSH access would trigger a log of the username that tried to access the box. Sounded normal, until I actually took a closer look at the script that was doing the logging.
Oh. Oh boy. Oh boy. This is an RCE waiting to happen. So naturally, the only thing to do was test it. Since this would execute as BASH, I used the following username after a few test attempts:
user\;\ echo\ pwned
This led to:
That confirmed my theory. After some messing around trying to get certain commands to work (note that forward slashes are not permitted in SSH logins, escaped or not), I finally managed to get the second flag in the /opt folder of the Ballista box. It took a lot of separate cd commands and SSH logins to work.
I also noticed that writing up custom, escaped payloads for this RCE was rather troublesome, so I went ahead and cooked up a script to launch the payload:
I also made a specific one for covering my tracks until a teammate told me all NorthSec challenges have team-specific endpoints. In short, the only people I was covering my tracks from were my own teammates. Whoops.
This one was a bit trickier than the last two. I still had to use the esoteric RCE method from flag 2 to navigate the box, which was painful in and of itself. There was also no way of easily exfiltrating files, besides base64 conversion, as the system had a firewall in place to prevent Simple HTTP Servers being spawned.
There were two accounts on the system: sysadmin and ubuntu. The RCE was being executed as a user known as logger, which didn’t have any special permissions. However, we could poke around the sysadmin folder with no trouble. In it was a compressed tarball and a folder called “notepad.” We grabbed the tarball, and the notepad folder had 20 or so encrypted files, a public key, and a note from the sysadmin. Additionally, there were encryption and decryption scripts as well.
The encryption script had several comments, including that the user couldn’t decrypt files of more than 20 bytes, and that “No one’s going to get the private key from the public key!”
Uh huh.
By this point Forest had joined the fray, and he managed to grab the N and E values from the public key. The files were encrypted using RSA, and feel free to read more about that here and here.
The funny part? Forest literally plugged N into Google and got the factors. That’s a yikes for our sysadmin.
The next hour or so was spent trying to convert our numbers into a usable private key. Forest tried a number of different tools before landing on one that worked, linked here. However, we kept running into errors that we couldn’t decrypt the encrypted files. So Forest tried to figure out what was going on while I tried to tackle some other challenges. Eventually, he realized that the public key exponent was in hex, so he had to convert it to decimal. That gave us a working private key, which we used to decrypt the files, concatenating them all into this:
Well, they aren’t wrong, but they don’t exactly have a high bar. The ssh key was in the tarball we extracted, and we logged into Central Dovecote to grab Flag Three. Boom!
Logging into Eastern Trebuchet via SSH (same key) also gave us a flag, which I happily submitted for an extra point.
Unfortunately, that was as far as we got with this challenge. It was a lot of fun, and got us exploring a number of different aspects of security, but I failed to escalate priviliges to a root user, which I knew had to be the final challenge. Apache didn’t have any vulns, and none of the binaries on the system looked vulnerable either. So that was the end of that box. If anyone ever did manage to get the final flag on this box, shoot me an email, I’d love to read your writeup!
301 Moodie Dr. Unit 108
Ottawa ON K2H 9C4
