Tag Archives: CCDC

CCDC Tips and Tricks

Posted on by

So as many people probably already know, I’ve competed in the Collegiate Cyber Defense Competition (CCDC) for the last several years.  I’m now employed as a penetration tester, and hope to join the CCDC red team one of these days; to reek havoc.

So I hope to provide some level of assistance to those preparing compete in CCDC as well. Much of this will be guide will be Linux based. This is because many of the scored services (sometimes upwards of 70%) are Linux based and that’s also my background.

So to start off with, here are some general CCDC tips and tricks.

1. Any web service is still just a web server

Don’t freak out if you are asked to manage, configure, or setup a web service/product that is new to you. Just remember the fundamentals, there is a web server (such as apache or tomcat), some data storage (such as a file, mysql, or etc), and pages that are being served (html). Protect access to these three points of entry by limiting file/folder permissions and change passwords.

2. Setup core services from scratch

Before you enter the competition room, setup all the services you think might be scored and compile/configure them by hand.  This will give you a better understanding of how the service is configured, some of the changes you can make, and also how to enhance the overall security. Once you have everything setup, print the configuration files out. This can be a life saver, because worst case you can just reconfigure the entire service to your known good configuration, by hand.

3. Setup an IN+OUT Firewall

The reason why I even mention this one is simple. In CCDC you have little to no choice on weather to run some rather vulnerable services. Limiting the amount of ports that are/can listen on your server is a great idea. But as am attacker, i’m here to tell you that it doesn’t matter much. You see most people use a connection new or established statement in their iptables. This means that if your service gets popped by an exploit, the call back will be an established connection. So make sure you have detailed out rules instead of that established statement, that way attackers can’t form a connect outside the scope of the service port.

4. Don’t eat that DoS/DDoS attack

Even though its specify prohibited in the CCDC team packet, I’m here to tell you those “wild stallions are hard to keep down” and they will do it anyway (David Durkee). So protect yourself, configure your services too only allow X number of connections per IP address, and on Linux systems enable syn cookies.

5. Report everything

I can’t even fathom how many points we have gotten back over the years by just calling them out on their errors or by reporting things that just seemed amiss. If you are attacked or think you were attacked. Report it. If you think their is an error with how a service is being scored. Report it. If you think their inject conflicts with previous information, the topology, or doesn’t make good business sense. Report it. Generating reports can be time consuming, but it can really only help you out.

6. Figure out what is “Really” being scored

Now again, this is one of those things that is prohibited in the team packet; aka doing forensic activities on the scoring engine. However, I encourage you to heavily log and/or monitor every interaction with your score services to passively identify what requests are really being made to your servers. With verbose enough logging you might find that AD/DNS is being scored based on an old SRV record that is no longer in use, or that web email is being scored based on the existence of an index file outside the scope of the Roundcube web application. Crazy things happen, review all of the logs.

7. Interact with your services regularly

This is one for more of a regional and nation level of competition, but none the less; interact with all of your score services. Make yourself an account and make sure things operate the way you would expect. If you start getting error or worse everything is being sold for negative moneys on your eCommerce site, investigate and report that activity. The service doesn’t have be spewing out errors or unreachable to impact the bottom line.

8. Backup all of the things

I’m not sure why this one even needs to be mentioned in this day and age, but back up all of the things. Every time you need to change a configuration file just go ahead and back it up. You never know when you might need to revert changes or reinstall a known good configuration. In fact at higher levels of competition, notably nations, you have physical equipment, so if your box gets popped, your the one rebuilding it.

9. Hide important files and backups

Sometimes there is little to no choice one weather to backup to the same local disk or to write that important file to local disk. However, try your best to obfuscate what the files really are by placing them in a different directory or giving them an obscure file name. The red team is somewhat lazy in this regard and are not going to start opening every file on the system to find your logs or backup configs. However, it you just add .old or .bak to the end of that configuration file, don’t be surprised if its gone the next time you have to restore it because of an attack.

More things to come….I Hope

The CCDC 2014 Experince

Posted on by

Most of the individuals who read by blog are most likely already aware of the Collegiate Cyber Defense Competition (CCDC). For those who don’t know, it’s a defensive competition for college students. The scenario is simple, a team of students (blue team) go into a compromised mock business and secure it. They also try to run the competition in the most realistic fashion possible, so the management side (white team) is constantly giving the blue team tasks to complete while securing the network. While the hackers (red team) are trying to get back into the vulnerable systems. Just so we are all on the same page, there are two other groups of individuals involved in the competition, those who run the competition (gold team) and the technical support staff (green team).

The network we were given for CCDC 2014, was much like it was in the past few years I’ve been involved in the competition. In the DMZ there was a CentOS box running eCommerce and a Ubuntu DNS running Bind9 as well as our MySQL server. On the internal network there was a Debian email server running RoundCube, a Server 2003 running WarFTP, Server 2008 running DFS, and a Sever 2008 R2 running ADDS. There was also a Windows 7 desktop on the ISP’s network, that we also had to manage.

During the competition you get points by maintaining your professionalize through the stress of the competition, keeping business related services up, and completing business related tasks in a timely manner. There is also a small margin of points available if you are able to both block and report red team activities.

This year our team at Indiana Tech did very well. I was on the Linux side of the competition this year as opposed to last year when I managed the Windows desktops. My primary goal was to keep the services on the Debian email box up throughout the competition. However, the credit goes to our entire Linux sub-team as a whole, for keeping our services up. That being said the only real issue we had was with the CentOS box hanging after the initial reboot, forcing us to scrub the box, about an hour into the competition. Other than that, we were able to pull together as a team and had about 80%-85% service up time and completed 40 out of 43 of the business related injects. Our performance over the 8 hour window was said to be one of the schools best and netted us a second place finish. With first place going to Rose-Hulman, who I wish the best on their conquest to the national title.

As always, we learned a few lessons during this year’s competition. First of all, it’s incredibly valuable to figure out exactly how they are scoring services as early as possible. This helps get full points on each of the service categories throughout the entire competition. We too discovered that it’s better to scrub a box early in the competition then fight with it for hours. We also found great value in setting up centralized logging and automated log checking packages like Kiwi and OSSEC.

Now, I would just like to take the time to make a few recommendations about how the competition might be improved. First I would like to recommend better communication between the blue and white team in an effort to help students more effectively improve communication skills. I say this because submitting an inject to the scoring system that I think is well written does not mean it is, and without a score report its hard to justify using builds communication skills as a selling point. The simply addition of having an inject, where an individual or group blue team members have to go present an idea, to someone would be a great place to start. Second consider better defining or allowing question on how services are technically scored. I recommend this because, I personally have seen some truly strange things happen with scoring and the rules clearly state that any interference with scoring is grounds for desertification. That being said, if you state in the team pack that access to web mail via an http site is being scored. It seems hardly fair to additionally score a random chat client as well, when its technically against the rules to investigate as to weather it indeed is being scored. Lastly I would like to simply request that those who compete in the competition receive some sort of acknowledgement, certificate, or web posting that includes placement. This request is simply to provide some tangible proof to an employer or future employer in the event that such a request should be made.

As an added bonus, here are the pictures of the CCDC 2014 commemoration dinner, hosted by Ivy Tech, that were made public the last few years.

http://www.flickr.com/photos/ivytechfortwayne/sets/72157640781466374/

Please note: In 2013 I was a senior on the Ivy Tech team.

http://www.flickr.com/photos/ivytechfortwayne/sets/72157632800411224/

Please note: In 2012 I was a substitute for the Ivy Tech team and did not make it into their limited photo set.

http://www.flickr.com/photos/ivytechfortwayne/sets/72157629404992103/