Web Admin Blog Real Web Admins. Real World Experience.


Completing the BSides Austin 2016 Mini-CTF

The BSides Austin 2016 Mini-CTF began with the back of the badge.  There was a large QR code which took a very long time for me to scan with my phone, and when I finally got it, it was just the numbers “07263584”.  Not very useful.  Below that, however, there was  a string of letters and numbers as follows:


The string very obviously looked like BASE64 so I decoded it to get the following URL:


On that page it reads:

That start was easy! You have shown that you are curious and that is the key. As your reward, you may have this:flag 1: BSides{D3c0d3s_R_3Z}Do you want to play some more? If so, read on...

1. Turn in flags by sending an email to bsidesaustin@gmail.com. The email must contain your name, email address, and the flag you are turning in

2. There are three flags total, each should be submitted via email.

3. Do not scan this server with automated tools. They are not necessary and could cause performance issues. If you scan this server, you could be disqualified.

4. Send in flag 1 then click here to continue...

I submitted the flag and moved on to the next page at:


On that page there was a file named coms.pcap.  With the “pcap” extension, I went ahead and loaded up into Wireshark.  It was a 1113 line packet capture file with encrypted Google traffic, YouTube rick rolls, and more.  Only a handful of the requests were for, the IP address belonging to ctf.bsidesaustin.org.  When I followed the TCP stream, it was for a request to http://ctf.bsidesaustin.org:31337/level3/index.html.  When I went to that URL, however, it was as if nothing was listening.  Eventually, I filtered the pcap by that IP as the destination and found a sequence of requests to that IP at odd ports…1025…2300…1337…1337.  This smelled suspiciously of port knocking so I wrote a quick bash script using nmap to test it out:

for x in 1025 2300 1337; do nmap -Pn --host_timeout 201 --max-retries 0 -p $x; done

Finally, I hit the page on port 31337:


Sure enough, now I get a response that says:

Congratulations, you have completed the second challenge!The second flag is: BSidesAustin{C4rV1NG_UP_PC4Ps}

Click here to continue to the final challenge!

I submitted the flag and moved on to the next page at:


On this page we see a network interface test where you can specify an IP as a ping destination, and when you hit “Enter”, it gives you the results of the ping:

PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=0.026 ms--- ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 0.026/0.026/0.026/0.000 ms

Entering some non-IP address information, I got a message like:

Error running ping -c 1

So, there is some filtering on it, but it also looks like some data is making it through.  I figured out that I could specify the destination as a GET instead of the POST with by adding “?dest=” to the URL and that worked.  I tried a bunch of different combinations of “;”, “&&”, and other OS command functions that would piggyback on the existing function with no luck.  Eventually, I figured out that “%0A”, the ASCII line feed control character, was not filtered and I could use that to run more commands.  For example:


Returned a listing of “index.cgi” and “the” in that directory.  Then:


Showed that “the” actually expanded to “/the/roof/the/roof/the/roof/is/on/fire/flag.txt”.  Sweet!  I found the flag!  Now to open it.


That returned:

PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=64 time=0.026 ms--- ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.026/0.026/0.026/0.000 ms
Great job! The third and final flag is:BSidesAustin{F1lt3rs_R_Fun}

Congratulations, you have completed the challenge!

Final flag submitted.  Game over!

Lessons Learned from Participating in my First CTF

Yesterday I finished competing in my first ever Capture The Flag (CTF) tournament.  It was called Kommand and Kontroll Revenge of the Carders and was run by Rod Soto of Prolexic.  I'm going to caveat this post by saying that this was my first ever CTF competition so I have absolutely no baseline of comparison.  It was also pretty thin on competition (only one other team actively pursuing flags for any period of length).  That said, it is what it is and in the end my team ended up with the win which I'm quite proud of.  We got system level privileges on 15 different systems to come away with both the most points as well as accomplishing the primary objective which I'll describe more about below.

The competition consisted of somewhere around 30 virtual machines running as servers and workstations on a completely isolated network.  Each system played a role in the scenario that Rod created around a carding ring that got pwn3d by one of its members using a Zeus botnet.  The primary objective for the CTF was to take over command and control of the botnet.  The secondary objective was to capture flags of various levels of difficulty (and points) in order to score more points than the competing teams.  It took the better part of two days to do it, but once we finally got system privileges on the CnC server, it was only a matter of time before we figured out a way to take ownership of it and win the game.  What follows are some lessons (in no particular order) that I learned throughout the competition that will hopefully serve to better myself and others as they compete in future competitions.

  1. Participate with a team: These CTF competitions are most definitely a team sport.  It's a series of challenges, different types of systems, and different applications.  There's no way that any one person can be an expert in all of them.  Working with one or more partners means that you have a fresh perspective when you need it.  It also helps when there are situations where time is of the essence.  For example, at one point I had system level privileges on a box and found the flag, but needed a way to get it onto my system.  We had a running FTP server to make the transfer, but this risks the other team seeing the file.  With the help of a partner, we had the file on the server, downloaded, and removed in under 5 seconds.
  2. Keep important files on removable media: I constantly found myself transferring files between different environments.  Some were flags, some were exploit code, others were just files with notes on them.  At one point I had my attack VM lock up on me and die to the point where I had to restore it from a snapshot.  Had I not been keeping my important files on removable media, it would have cost us several flags and many points.  Thank goodness for being prepared.
  3. Don't submit all of your flags at once: Believe it or not, there's quite a bit of strategy involved in how you present your team.  Show too little points and people will think you're a chump.  It'll encourage others to join the game because they feel they can make up those points quickly.  Show too many points and now the competition feels the need to work harder and faster to catch up.  My partner and I decided that it was best to start off with a low number of points.  We posted a few flags just to show some progress, but kept a large number in our back pocket for later.  At the end of day one I posted some more, but not all of the remaining flags.  In hindsight, this was a bad move on my part as it seemed to get the other team moving faster.  At the beginning of day 1 they posted enough points to overtake us on the scoreboard, but we still had enough flags in waiting at that point to more than make up the difference.  We decided to hold them until the end to make the other team think they had it in the bag.  I think this proved to be a far smarter strategy.
  4. Have a variety of different environments available: Since the CTF machines were running a wide variety of host operating systems, we ran into a number of challenges where we needed to be able to mimic a similar environment.  Fortunately, I had a fairly diverse system that I was running which had OSX, Windows, and Linux.  I found myself constantly switching between them during the game.  I know that other players were definitely hindered by their lack of diverse environments.
  5. Take snapshots of your environments: As I mentioned in #2 above, at one point I had my attack VM lock up on me.  I tried restarting, but no matter what I did, I couldn't get back into the GUI interface to resume my attacking.  This would have killed my game.  Snapshots to the rescue.  Fortunately, before I started, I took a snapshot of my VMs and was able to quickly and easily roll back to a known good state.
  6. Have Internet access available: Maybe it's via your phone or via another computer attached to a different network, but there were a number of times where we had to query things on the Internet.  Sometimes it was for scripts (like a PHP C99 shell) and sometimes it was for knowledge, but without Internet access, things would have been far more difficult.
  7. Know how to query an exploit database: Assuming that you found a way to get Internet access, you should know how to use an exploit database like the one at http://www.exploit-db.com.  After you do your discovery, you have a list of running applications, sometimes even version numbers, and need to know if they are affected by any vulnerabilities with known exploits.  That's where these guys come in.
  8. Update in advance: In several cases, the needed exploit was provided in the latest version of Metasploit.  Unfortunately, my partner had a version that was a bit outdated.  As in the case of this CTF, Internet access was not available in the game environment.  He ended up taking his system onto the conference wireless network to do the update, but it sidetracked him for a fairly significant amount of time.  It's far easier to update your tools before you walk into the CTF environment so you can spend your time actually hacking all the things.
  9. Be well versed in exploitation tools: The time I spent listening to my friend Raphael Mudge talk about penetration testing with Armitage paid off dividends here as did the many months our study group went through David Kennedy's Metasploit book.  I went into it feeling like I had a pretty good grasp on the concepts with no practical application of the skills.  Now, I feel like the CTF gave me the practical application and then some.  If you don't have at least some knowledge of a tool like Metasploit or Armitage, you're going to struggle.
  10. Explore the system: The system that I mentioned earlier that we used to take over the botnet command and control was one that I had rooted several hours earlier.  I browsed the system, got the flag, and moved on.  It wasn't until I established a VNC connection to the system that I found the CnC console staring right back at me.  It had been there all along and because I didn't give the system enough attention, I moved right on past what could have won us the game far sooner.  Remember, there are many different ways to view the data on the system.  Be somewhat thorough while at the same time remembering that time is of the essence.
  11. Know how to use a directory brute forcer: I think that many of the people who came in, played for an hour, and then left got stuck here.  They ran their scan, found some HTTP servers, and connected to them but saw nothing but a "Hello world!" message.  They knew that something was running, but couldn't figure out what.  Fortunately, I'm familiar with the OWASP ZAP tool and was able to tell it to brute force common directories on the web server.  We found a number of different applications this way that there was really no other way to find.  Your Metasploit exploits will never work if you can't tell it the proper URI to target.

So, there you have it.  My list of lessons learned from participating in (and winning) my first Capture the Flag (CTF) challenge.  Big thanks to my partners Alek and Nate for pwning systems alongside me.  As I said in #1 above, CTF is a team sport and I couldn't have won it without you guys.