Category Archives: Cyber Defense Competitions

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

NCL 2014 Team Challenges

Posted on by

Although I wont cover all of the team challenges that Kernel Panic completed during the NCL 2014 Team Post Season round, several stood out amongst the rest.

I’d also note, some of the challenges from the individual round were covered on the site of my Cyber Defense Team.

Passwords 1:

For this challenge, we were given a password hashing algorithm written in java script. I heard from some other teams, that they had successfully reverse engineered the algorithm; in order to decode the passwords. However, we had s better rate of success just running a word list through the algorithm and doing some string comparison. In the end it turned out, that the passwords were all World of Warcraft towns, and a few Google’s made a winning word list.

Recon 2:

In this challenge we were asked to find the port on a server that was actually running an HTTP 1.0 compatible server and to then to find several flags. After a very confusing start, we discovered that the server was running port spoof. This nifty piece of software, randomly generates one of roughly 400 legitimate service banners, on each of the unused ports. Several of these possible banners being Apache products. However, it turned out that the web server was running nginx, which only really has one service banner. So we were able to use nmap to request the service banner for each port and then grep through the results for nginx. We then found the correct port to be 56565, and the first 5 flags could be found from viewing the pages source.

NCLRecon2

In order to get the last flag, you would have had to guess or know from previous exercise (<- what the heck NCL), that you can just throw a /flag on the end of the site URL. You will then be served a text file with the flag information inside it.

NCLRecon2flag

Web 3:

Using the CHANGELOG.txt file of the site, we were quickly able to identify that the server was vulnerable to a string of Drupal vulnerabilities that had recently surfaced. However, due to the destructive (<- no fun NCL) nature of these SQL based exploits, we were unable to gain a strong foot hold within this box. It should be noted that towards the end of the session a metasploit module (drupal_drupageddon) was even release to exploit this vulnerability, and still very few teams were able to capture the flag.

Exploit 3:

This challenge was all about gaining access to the system and gathering flags. The exploit being the shellshock vulnerability allowing for a special string of characters to be passed into a web function that processes bash commands. In this case, the vulnerability existed in a php-cgi script called dpkglist. This allowed for a specially encoded string to be passed as the user agent of an http request, to the effected web server. This string can also be manipulated to allow for fully qualified commands to be entered and their output to be displayed, if they output only one stream. Bellow is the curl command I engineered during the challenge to run the cat command on the flag files.

curl -H “User-Agent: () { ignored; }; echo Content-Type: text/plain ; echo ; echo ; /bin/cat flag.cgi;” -k https://54.83.28.186/cgi-bin/dpkglist.cgi

 

Special thanks to the other members of my team:

Turner “Shadow_Crux” England

Wade “HelpdeskMan” Schimmoeller

Elliot “CiscoMan”  Stidd

Michael “Seleventyeleven” Contino