Sunday, September 8, 2013

Scram CTF 2013 lesson learned

We attended this wargame as Apple Corps. It was a quick name I threw together because the team was a last minute decision as it was sure if my Unallocated Space was creating a team. Apple Corps was mostly made of members that aren't part of Unallocated Space, but were interested in doing wargames and jeopardy style contests. So this is how we started, a last minute one-off team that decided to become serious. We are now the Crimson Agents.

This was certainly one of the most creative competitions I've participated in, and also the worst performance I've had. The wargame attempted to model a SCADA environment by having each network host a simulated nuclear power plant. They did this by reverse engineering an old Atari game and redesign it as a network server. These servers had port 80 to provide the javascript interface, and 6 web sockets coded in python. Each team would try to operate the own nuclear power plant, defend it from other teams, while also attack other teams power plants.

While the concept for this wargame was exceptional, the game could have been better explained. When the game began, we were told that the entire 192.168.1.0/24 network was off-limits, and that on the 192.168.15.0/24 network only the game server was off-limits but that there were other systems on that network for extra points. This was a bit misleading as the only address range the wargame operated on was on the 192.168.15.0/24, but we didn't find this out until it was too late.

There are other complaints, but I feel Altamira's recap captured the heart of it.

Log of our Fail


Our team largely consisted of new members who had not been to a wargame before, and so we chose a mostly defensive strategy of one experienced person on offense, one person operating the simulator, one person responsible for patching our systems, and two people auditing our network for unpatched vulnerabilities. Quickly we found a few keys on our server and began with a good start, but the services weren't vulnerable to anything we knew of, and throughout the exercise no team had remote access to our network.

Continuing in our audit we found an additional server on our network with some weird mafia website. This server distracted us for a good bit, because we did get root on the server but it lacked keys. So we then tried to see if the mafia website contained obscure clues or stego. It wasn't until we had accidentally firewalled ourselves out of the system (doh!), and ask the admins to reboot the server, did we find out that this was not part of the wargame and the VM had been started by accident. So, that was waste of time, but because we found it and got root, they did award some points for us.

With full confidence that our network was secure, and no indications of activity from other teams, I began poking into the javascript for our power plant after backing up the entire code to my server (thanks altamira!). I located in a file that had not only our network (192.168.4.0/24), but listed every other teams network, and which team was on that network. We had already been searching for the other teams networks, leaving the 192.168.15.0 for later once we had a few footholds, but this information we began looking even harder.

We found nothing, no hosts, no ports. So I began scanning port 80 on everything but 192.168.1.0/24. Turns out this was a horrible idea as all the team networks were translated behind an address on the 192.168.15.0/24 network. This however does not mean I did not find other hosts...just that those hosts were probably someone else in the hotel (oops!). Again more wastes of time.

Finally, we focused on 192.168.15.0/24 network, but as we were very very late to the party though we were able to find an unused flag. The important hosts to own and pivot from had already been claimed by other teams.

Good points

Our nuclear simulation operator (tarkiz) did a wonderful job of scoring points which helped us be out a team that had their router fail mid-game.

Needs work

I wouldn't call this experience a failure. It could only be a failure if we didn't learn from it. Besides, that's the point of a lessons learned, and this wargame had so many lessons for us. We'll learn, we'll be ready.

In previous wargames, the teams I was on had used Google Drive to collaborate and communicate without being overheard. This time however, the Internet was so inaccessible it might as well not been on. So, one thing we need to work on is bringing our own collaborating system.

Learn Javascript. While Javascript was already on my todo list, this summer I studied Java due to its use in the MDC3 wargrame. Knowing how to reverse engineer Javascript quickly would have been useful, as teams which did this was able to score the maximum power plant points without operating it. I tried looking, but quickly got lost.

The other part I was weak on was fuzzying websockets with ZAP/Burpsuite. If I had Internet at the time, I probably could have figured out something, but as most services use RESTful architecture, I did not expect to encounter websocket.

Related Links:
https://www.altamiracorp.com/ctf/information
https://www.altamiracorp.com/blog/employee-posts/altamira-scram-ctf-recap
https://www.altamiracorp.com/blog/684/files/CMChangelog.txt
http://packetinspection.blogspot.com/2013/08/altamira-ctf-2013-lessons-learned.html

Other teams that were there.
https://ctftime.org/team/1948
https://ctftime.org/team/4955
https://ctftime.org/team/397

No comments:

Post a Comment