Tag Archives: Cyber Defense

NCL Summer 2015 Skyline Thoughts and Challenges Walk through

Posted on by

NCL recently ran a pilot to introduce there new skyline platform. Although this will likely be the NCL Summer 2015 competition i’ll be able to compete in, I wanted to give my honest opinion on the platform and walk through some of the challenges that I thought were well done.

Review:

First of all I find that this new Skyline platform had far better performance then old NCL scoring engine. This is likely due to the lower number of players in this summer round, but I hope the stability remains. Additionally, I thought the step by step approach with hints available will make challenges far more approachable to player who are new to the infosec competition space. My only real criticism would be the web app challenge, having it embedded into the skyline interface made it much harder to work with. In the further maybe still host web app challenges in AWS.

Challenges:

QR Code Images

There were really two very similar QR image challenges. These were among my favorite present, in this NCL round. Since some of the guided questions were very similar I will just cover them once. Now the latter image is given to you in 4 pieces and you are meant to use your forensic skills to reassemble the image based on some hex headers, footers, and commonalities. However, I just wrote a quick script to cat each of the files together in each of the possible permutations; then just opened the one that showed a valid thumbnail of the image.

What is the md5 hash of the image? In both chases the following command on that trust kali box will get you the

iptables for Cyber Defense

Posted on by

Linux operating systems are very popular within the Cyber Security competition space for several reason, the foremost likely being that its free. Nonetheless, this abundance often calls for competitors to have at least a basic understanding of how to defend Linux systems. Arguable the first step in defending a Linux system is strong passwords, but a strong firewall is defiantly the second.

First of all, make a bash script for your firewall configuration, run it often (I like rc.local, cron, and init), and hide it well (I like a places I would frequent as a defender, but not as an attacker, like /etc/apache2/sites-available). This iptables script should at the very least include an IN and OUT filter for ssh and the port(s) core service(s). A basic script might look like the following.

#!/bin/bash
iptables -F #clear the table
#iptables tricks
iptables -A INPUT -i lo -j ACCEPT #accept connections on our loop back
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP #drop bull packets
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP #drop syn floods (couple with syn.cookies)
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP #drop xmas packets cause this isn't the 90s
iptables -A INPUT -p tcp --dport 80,443 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT #limit incoming connections
#IN Chain
iptables -A INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT #open ssh
iptables -A INPUT -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT #open http
iptables -A INPUT -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT #open https
#OUT Chain
iptables -A OUTPUT -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT #allow ssh out
iptables -A OUTPUT -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT #allow http out
iptables -A OUTPUT -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT #allow https out
iptables -P OUTPUT DROP #drop other out
iptables -P INPUT DROP #drop other in

Allow this is likely not all the rules one might require throughout a competition, I’ve found its a good place to start. I hope to add more examples and useful rules as I learn of them in my career. If anyone has any questions feel free to hit me up.

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