This past Saturday and Sunday (March 5th, and 6th 2011), I spent my weekend on the Red Team for the At-large National Collegiate Cyber Defense Competition (CCDC). I served as a Red Team member last year, and you can read my write-up of last years (test bed) competition for this event here. This year (instead of 4 teams like last year) there were eight teams. A couple teams were from Alaska, two from Hawaii, and four from scattered states around the contiguous US. The only three universities that I identified (as participants) from chatting with the white team were University of Manoa (Hawaii), University of Alaska Fairbanks, and the United States Air Force Academy Colorado Springs. The goal of CCDC is to have the white team give the blue team business injects and have the red team attack the blue team while they have to work on setting up a corporate style environment.
Comments about the competition in general:
I was kind of disappointed this year. This year we were supposed to have VPN access to the network (as opposed to using VM Sphere over WAN to get to our machines). During the setup process, administrators had what is known as a disaster in the technical world, and to recover we had to use VM Sphere over WAN again this year. The problem with this setup is the delay on every keystroke was about a second long so it was very hard to use the machines. Needless to say the competition started about three hours late. Last year, the network was setup a day before so we could do our reconnaissance phase early. This year, we started recon at the same time the blue team got their machines. A major problem we experienced with the competition is that the one to one NAT the administrators setup between the outside (red team) and inside (blue team) used state tables to maintain records of open in closed ports. When we tried to use tools like hping, nmap, fping, etc to scan the network, the state table buffer would overflow and give us inconsistent results every single time. Even when we figured out how to translate the private IP addresses of the machines that were up (from our insider in the network which ping swept the local IP range) to public ones we could see, we couldn’t nmap them for open ports because the state table buffer would go haywire. Needless to say, you can’t run exploits against hosts with no operating system finger prints or service versions.
Comments about the machine setups:
Another thing that made the competition tough this year is the software the computers were running. Last year the Windows machines were running Windows XP service pack 2. This made it easy for us to find exploits to root the machines. This year the machines were running Windows XP service pack 3. The linux ubuntu machines were on 9.04. We got this information from the white team on day two. There really is just not a good amount of exploits out there that can be performed for these operating system versions, and the ones that are required significant modification. I mean, we can’t just write 0-day exploits, and if we did we certainly wouldn’t use them for these competitions. We’d be selling them to tipping point or somebody for $10k.
We tried running autopwn (a metasploit module) against machines we identified (through our insider) to be windows machines, but of course it failed because it couldn’t nmap the machines correctly. Thus instead of focusing on rooting the machines, we targeted the web applications we could find. There were five web applications we found: A record maintaining website, a social networking site, an IIS server blank page, some other content management system (CMS), and one other (I think) which I do not recall what it was. On the record maintaining site we noticed in the comments on the main page that there was a login username and password so we used that to get access to a page of usernames and personal information (social security numbers etc). We were able to do this for most teams and only one of them successfully changed the password to it towards the end of the competition. I ran nikto (a web vulnerability scanner) against all the websites we could find and I noticed on the social networking site there was a /upgrade.php file. When I browsed to that web page I broke the social networking site which made it a blank page. This is pretty much all we were able to do for day one.
At the end of day one, the white team told us that they would help us do client-side attacks (like open things in email attachments) to simulate dumb users on a network. I went home that night and brushed up on my Social Engineering Toolkit skills (a software included in Backtrack 4). I was able to get internet explorer exploits working (like the google aurora attack) on my test VMs at home (running XP SP2), but when I tried them the next morning on the VMs for the competition (that were running XP SP3) I couldn’t get them to work. Instead I used social engineering toolkit to generate a PDF that had a malicious executable inside it. The white team chatted with me over skype on the blue teams target machines, I sent them the malicious file, they opened it and it spawned a reverse meterpreter shell back to our backtrack VMs. The next problem we had was the rootkit we intended to use for this competition (Dark Comet) did not want to communicate back to us. We chose Dark Comet (and tested it) because it is not detected by rootkit scanners like RootkitRevealer or Sophos Anti-Rootkit tool. Somehow last year teams were able to find our Poision Ivy rootkit, so we wanted to surprise them this year. In light of Dark Comet not working, we just went back to using Poision Ivy. The only teams we got connections back from were Team 1 and Team 3. Team 3 went offline so we were not able to install our home brewed malware (The Charlie Sheen Project) on their machines, but we were able to install it on Team 1′s machine. Here is a cool picture of that in action (us #WINNING):
As you can see, we had a little fun in the last hour of the competition spawning notepad on some of the teams machines and talking to them. The particular image you see above is us beating on the Air Force Academy (Team 1). I did manage to kill a spybot process on Team 5′s machine through a meterpreter shell that was still open from the PDF exploit and tried to spawn a notepad on their machine to let them know we were there. The white team said they saw Team 1 trying to drag windows spyware removal tool around the picture of charlie sheen to install it. It brought me much laughter and joy to see my home brewed malware working in action. Other than that, on day two Wesley McGrew wrote a script which downloaded the information on the record management website and deleted all the user records in it. He manged to execute it against a team, and he was thwarted by another team who noticed the network traffic. These were about all the attacks we were able to do on our end due to network/software version issues.
Remarks for the teams:
I can bet the teams were experiencing difficulties with the network just like us. I know a lot of the teams had their internal networks down for long periods of time. In our debrief Wesley said the only thing you can quote him on is that “You all did horrible”. I wanted to elaborate on that. Wesley was being a bit jocular when he said that, but also he was serious in a way. What we as the Red Team were concerned with is that only one team managed to fix the password on their record management site. People get in really big trouble when they leak information like social security numbers onto the web. They can get fined and the incidence response is costly. The fact that all the teams were notified about this on day one, and only one fixed it near the end of day two is terrible. If I was grading this competition I would have failed all teams solely on this and sent no one to nationals. It was a simple tweak to a .htaccess file to fix. It is too bad CCDC is about doing business injects and making pretty reports rather than an actual competition about information security. That is why our Mississippi State University team stopped blue teaming, and why we concentrate on offensive security. I would like to say something positive to the teams, but due to the network connectivity issues I can’t judge how secure machines actual were. You were giving fairly secure operating systems in the first place, which was really lame. The only metric we have to measure you by is your web application security, and by that you all failed. The winner had better put their game face on for nationals, because unlike this competition (where there were network issues and about 5 of us to attack 8 teams) at nationals there are about 40 Red Team members (5 to attack your team alone). And I guarantee you will be given more vulnerable machines.
I’d say this competition was a disaster. Do not get me wrong, I do appreciate the administrators and all the work they did to set things up. I want to thank all of you as having us as your Red Team. I still enjoyed myself and learned new skills. With that said though, I think next year the admins just need to #planbetter so that we all come out feeling like we are #WINNING . As always, if you have comments please leave them below or feel free to email me.
We are Red Team Sheen. We sometimes forgive. We occasionally forget. Expect us to be #WINNING.