Ottawa Bsides Recap

With 2.5 Hours to go!

Last Month our CTF team “SomeRandomName” hosted the CTF at BSides Ottawa for over a hundred competitors. It was our third year running the event and largest one yet, both in terms of number of attendees and challenges.   
​
Scoreboard
The CTF had used the mellivora scoreboard the last few years and while incredibly reliable and easy to use, we were looking to provide something new to the players this year.

​Eventually we settled on the Facebook CTF scoreboard.
​ 
The Stats 
Number of Challenges: 43
Number of Correct Flags submitted:  ~2600
Number of Incorrect Flags: ~28000  ( ahhh trivia)
Challenges solved by at-least one team:  40 (3 challenges were not solved)
Challenges not released: 2
 
The first part of this post provides a look into the inner workings of the CTF from our perspective. The second are write-ups for a number of the challenges.  

Behind the Curtain

Network
We moved to a more segregated topology this year, with a player network, network track, infrastructure and management network. Our long-term plan is to move to team containers which would contain separate instances of the game.  A high-level diagram can be found below:

---

Challenges
We aim for a CTF of average difficulty with a wide variety of intro to mid-level difficulty problems. The goal is to have something for everyone, with plenty for new players to work on - especially the CTF101 / Trivia categories, where someone can jump in and work away between talks - but with a good number of harder problems to challenge the more experienced CTFers.. Our categories included Network, Forensics, Web, CTF101, RE and Crypto.

We also had several “guest” challenges contributed. These were all excellent and rounded out the higher end of the difficulty spectrum.

Red Alert! Shields up!
After the doors opened, the 100 plus players began to connect and to explore the game, initially everything seemed fine….

It soon became apparent that there were issues with the game network. Challenges would appear to be randomly unavailable, and tools like nmap would simply die half way through a scan. Once a session was established it seemed to be fine but that initial connection would randomly never complete. This was puzzling as the network latency looked normal.

Meanwhile it became apparent that the scoreboard wasn’t holding up either, gradually becoming completely unresponsive.

ZeroCool never had to put up with this.
Looking at the scoreboard box we saw that async-mysql process (a hhvm plugin) was pinning a full CPU and a there were thousands of connections in the timewait state. We gave the box additional resources and rebooted. This alleviated the problems for a short time, but the scoreboard eventually began to slowly grind to a halt again.

The puzzling thing was that after assigning more resources, the scoreboard CPU, was only at 10-20%, memory wasn’t in swap and the network traffic was minimal as well (with little to no errors).  Chasing the excess timewaits, we adjusted the mysql configuration to close timewaits within seconds rather than minutes. This appeared to help a little but nothing like rebooting the box, which would give a solid 15-30 minutes of good performance before it slowed to a crawl again.

In the end we isolated the problem to hhvm (the facebook developed JIT php environment) and its  async-mysql plugin, we noticed a number of issues had been raised in the Facebook CTF git to improve performance in this area. We started going down the code rabbit hole to determine the full root cause, but with a room full of increasingly restless CTFers there wasn’t time to debug in depth. We eventually settled on a highly effective but rather inelegant solution: A cron job which restarted the hhvm service every 15 minutes. #Solved.

I get static route, you get a static route, everybody gets a static route!
Going back to the problem of the challenges randomly not responding, we found asymmetric routing between the players and some of the challenges. Packets from the infrastructure network (where the challenges were) would first go to the venue gateway before bouncing back to the player network, which caused problems with packets traversing the state tables on the routers. Of course during our tests with only a handful of users the night before this problem did not manifest itself.

Again, some front line maintenance was used to correct the issue. A default static route to the player network was pushed to each of the challenge boxes.

route add -net 10.20.128.0/21 gw 10.20.1.11 dev <ent> 

Both issues are great cases of problems that only become apparent when the system is under load.
 
Alls Well that Ends Well
By about 1300, we had the problems with the routing, wireless and scoreboard under control and by 1400 the experience was back to what we wanted to see. To give teams a bit more time, we extended the game by an hour the first day. 

Bsides Ottawa Challenges Write ups
The following are brief writeups for some of the challenges.  

Ctfinder
(category: CTF101/Web)

After building the most awesome CTF team, one had was presented with Nedry from Jurassic Park informing you, that did not say the magic word. 
https://www.youtube.com/watch?v=RfiQYRn7fBg

Using burp, you can add magicword to the parameters in the post request to which the application would responder "get closer"
.
Taking that one step farther adding magicword=please will get the flag.

Internet of Poop
(category: CTF101/RE)

An internet connected toilet. Ahh it’s nice to live in the future.

There was a small misdirection to look like a sqli challenge but it was a infact a basic firmware reversing challenge. The “admin credentials” to the toilet were in the emergency firmware reset image.  Simply binwalking the image and extracting the zipfile within, yielded the creds in base64 format.


Security by Obscurity – Big Data Edition
(category: CTF101/Network) 

The version is a little old so we moved it to a port no one could possibly find it. Since we passed our compliance test, we know we’re secure. Groovy…

A vulnerable version (CVE-2015-1427) of elasticsearch (1.4.2) was running on the host, the only "hardening" was the REST API port remapped to a high port.

After locating the service, here’s the metasploit module to use.
https://www.rapid7.com/db/modules/exploit/multi/elasticsearch/search_groovy_script

Then read the flag in \flag.txt

Off By One
(category: CTF101/Crypto)
(attached)
 
I think someone broke a bit. 
 
In taking a closer look at the key, the key had one bit flipped. The solution was to write a small script which iterated through the key flipping each bit. This quickly yield the solution.  
Flag: B1tFl1pp1nAllDayEv3yD4y

Mo Data Mo Problems
(category: CTF101/Network)

If you haven big data problems I’m sure it’s no fun I got 99 problems but authentication ain’t one

This problem featured an elasticsearch node, with the REST API remapped and behind nginx on port 8080.

Ironically the real effort behind this challenge was not the initial creation but armoring it so players couldn’t delete or modify the flag.  

Here’s the solution:

curl -X GET 'http://10.20.16.31:8080/_search?q=*:*'
 
Result
{"took":2,"timed_out":false,"_shards":{"total":5,"successful":5,"failed":0},"hits":{"total":1,"max_score":1.0,"hits":[{"_index":"flagstorage","_type":"flag","_id":"1","_score":1.0,"_source":{"user" : "flagowner", "flag" : "COnnECt_ME_To_THe_InterNet_WhAt_CoUlD_Go_Wr0ng"}}]}}
  
The flag: COnnECt_ME_To_THe_InterNet_WhAt_CoUlD_Go_Wr0ng

Remote Desktop compromise by weak creds
(Category: Old School Trivia)
​
The augments should have changed the code from this value

If you search augments in google depending your search history it may go to “Enterprise” augments references, which is definitely not old skool enough. “Augments” refers of course to our favorite augment “Kahn” from Star Trek 2 and TOS:Space Speed,  Once you find the video the flag you’re looking for is the prefix code which allows one to remote into a ships console.

The flag can be found in this video clip. Enjoy!:
https://www.youtube.com/watch?v=WCpYqWAIwFA
 
And if that’s not enough, here’s a reddit thread debating the merits of 5 digit code to control star ships... 
https://www.reddit.com/r/DaystromInstitute/comments/2yl22y/are_prefix_codes_a_fatal_security_flaw_of/
 
What’s inside
(Category: Old School Trivia)
I thought the title of the challenge would give it away. But apparently, some teams spent hours on this problem. I know how it is on CTFs, sometimes it’s very hard to put a problem down.

The challenge featured an ascii art of the HEMAN logo.  The title was a clue or it could be compared to the original. It was ASCII Stego. A quick search of google for “Ascii art stego” reveals the online decoder here:
http://pictureworthsthousandwords.appspot.com/

The Flag IS: YoU_Will_NEvEr_FinD_TH1S​

Off the Rails

We released this challenge with about 2 hours or so to go. It consisted of a vulnerable ruby on rails install running a web console. The web console of course allowed you to run ruby code. 

The easiest path to a shell, which no one did, would have been to run the metasploit module for this particular version of ruby on rails webconsole. Alternatively using the command injections you could have seen that you were running as the user cyber (the title of the app was cybercybercyber as well.). At that point if you had tried to ssh to the box with the account/password cyber/cyber you would have a shell. Instead many many many people tried to get a reverse shell with netcat, over and over and over again.

Unfortunately  the version of netcat on the box did not have the -e option. #sorrynotsorry. - Check out https://pen-testing.sans.org/blog/2013/05/06/netcat-without-e-no-problem 

 Unfortunately the flag was readable only by root. Fortunately there were a number of priv escs on the box, the simplest was sudo  as cyber was in the sudo group.