Tag Archives: Information Security

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

How I “Kinda” Won The BsidesIndy CTF

Posted on by

I’d first like to thank everyone who worked hard to make BsidesIndy so awesome. It was the first time I have every gone and from my understanding, the first time it has every occurred. Needless to say it was a stunning success in my book.

When I go to conferences I like to always make time to visit the capture the flag events. Sometimes I do really well, sometimes I do rather poorly, and sometimes I just meets some cool new people, but I always send time at there. Simply put, there is just a lot of learn from spending an hour or several competing against others within the same industry. As such, Bsides Indy was no exception. I showed up to the BsidesIndy CTF table ready to learn some new tricks and got all set up.

In the BsidesIndy CTF, competitors could register as either the blue (defensive) or red (offensive) team. So while I was waiting for my login credentials to be generated, I looked over the score board and noticed that there was not anyone on the red team. So I choose to register as the red team, and quickly noticed that many, if not all, of the individuals at the CTF table on either side of me were on the blue team. So I started by doing some nmap scans on the /24 network that was given to me to test, but I quickly noticed that many of the blue team members were just yelling up and down the table, with information about each of the boxes. So I listened in for a while and was able to learn the IP addresses and services of many of the boxes. I then noticed that the gentlemen beside me was having some issues getting his web services up on a box he was working on. So I deiced to help him out and what do you know, a few config files, iptables rules, and service restarts brings to web services back up. However when I was working with him, I noticed that he kept referencing a web pages for IP addresses, usernames, and passwords. So, after helping him repair the services on the second box, I simply asked for the URL of the web page he was using and he was more then happy to give it to me. I then spent the rest of the competition, gaining access to different Linux boxes, establishing persistence, and hunting for flag. By the end of the game, I had active beacons on 5 different systems (Unfortunately not displayed at the end of the competition, when the screen shot was taken) and possession of several of the flags. I’m honestly not even sure, if my original nmap scan even finished.

Screen Shot 2015-02-21 at 5.41.22 PM

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