Thursday August 18, 2005
Wednesday August 10, 2005
After three straight days of attacks, counterattacks, and constant caffeine
consumption, Shellphish triumphed among a worthy
field of eight teams to take first place at the 2005 DEFCON CTF! Kenshoto, the organizers who were tasked with following
the footsteps of the ghettohackers and
succeeded beyond all expectations, have posted the final scores on their site.
Slashdot has a story on the CTF, along
with SecurityFocus (which includes
Crispin Cowan's take on the setup), but for the blow-by-blow, read on.
There was much mystery and speculation swirling around the setup of this year's competition, as Kenshoto purposefully held back information on the physical setup of the network, how much access to the machines teams would have, what operating system would need to be defended, etc. When the day came and the setup was revealed, not everyone was happy, as Crispin's comments to SecurityFocus made clear. Incidentally, this makes two years in a row that LSM or SELinux-like systems have been undeployable (last year's team images were Windows-based). In particular, this year was a departure from previous setups as the images to be defended were jails on a single FreeBSD 5.4-RELEASE server hosted by kenshoto. Thus, no physical access, firewalls, kernel modifications, etc. were allowed. Nevertheless, I would have to dispute Crispin's claim that no defensive measures were possible on the part of the competing teams. Most services were easily patchable, a network tap provided by kenshoto allowed teams to sniff traffic to and from their jails, and more advanced defenses like syscall interposition were still possible.
As for the vulnerabilities themselves, these were mainly a smattering of web-based services, python scripts, and C-based network daemons. The web-related services were generally easy to deal with, as they could be instrumented and audited rather easily. The binary-only daemons, on the other hand, presented another problem altogether.
There was much mystery and speculation swirling around the setup of this year's competition, as Kenshoto purposefully held back information on the physical setup of the network, how much access to the machines teams would have, what operating system would need to be defended, etc. When the day came and the setup was revealed, not everyone was happy, as Crispin's comments to SecurityFocus made clear. Incidentally, this makes two years in a row that LSM or SELinux-like systems have been undeployable (last year's team images were Windows-based). In particular, this year was a departure from previous setups as the images to be defended were jails on a single FreeBSD 5.4-RELEASE server hosted by kenshoto. Thus, no physical access, firewalls, kernel modifications, etc. were allowed. Nevertheless, I would have to dispute Crispin's claim that no defensive measures were possible on the part of the competing teams. Most services were easily patchable, a network tap provided by kenshoto allowed teams to sniff traffic to and from their jails, and more advanced defenses like syscall interposition were still possible.
As for the vulnerabilities themselves, these were mainly a smattering of web-based services, python scripts, and C-based network daemons. The web-related services were generally easy to deal with, as they could be instrumented and audited rather easily. The binary-only daemons, on the other hand, presented another problem altogether.
To be continued...
Monday June 13, 2005
Last Friday, the RSL ran another edition of the UCSB
iCTF, with the Tower of Hanoi from the
Politecnico di Milano taking top honors in a hard fought contest with Old Eur0pe of Aachen and the Wizards of DoS from
TU Darmstadt. Slashdot has a story on the
contest, and some teams have put up pictures.
Finally, congratulations are deserved by Vika and Greg for making the entire event run smoothly!
Finally, congratulations are deserved by Vika and Greg for making the entire event run smoothly!
Wednesday June 08, 2005
Tuesday June 07, 2005
The next version of dlmalloc (v2.8) is slated to
include a variant of the heap protection patch as a compile-time option. As a
result, the versions hosted here are now deprecated in favor of the officially
supported version in glibc.
This past weekend, UCSB (a.k.a. Shellphish)
qualified for the 2005 DEFCON CTF. Look for the RSL++ to be in the thick
of things this July in Las Vegas!
Tuesday August 31, 2004
Better late than never: UCSB (a.k.a. Enemy Combatants) take 2nd place at the
2004 DEFCON CTF.
First was so close we could taste it, but at the end of 30-plus grueling hours the Naval Postgraduate School, competing as the Skewl of Root, was able to hang on to a 3 point margin of victory at 38 points, with the Enemy Combatants at 35 points, and Immunix coming in third with 8 points. Given that this was our first year competing, second is a great result, and I think we gave a foreshadowing of the hammer that will be brought down next year with our attack performance this time around.
Here were this year's team members, in alphabetical order:
The competition itself started off on a rocky note. We knew that we would be given several VMware images with services to deploy and defend on our own network and to attack on the other teams' networks, but we were definitely not prepared to face two Windows images, a first in DEFCON history! Being proper UNIX hackers, some time was lost exploring the images and attempting to lock down access to the host and its services, but one could take comfort in the fact that the other teams were almost certainly in the same boat. (Incidentally, the choice of Windows as a host image was a significant blow to Immunix's strategy, which has traditionally been to port the services to their security-enhanced platform and dial in access control specifications for each of them.) The two images turned out to be the frontend and backend servers for a simple web-based banking application, with deployed services including a wiki, forum, MUD, and credit card transaction processing system, among others.
The probes began almost immediately, but some time passed before a team scored the first offensive point. Initially, the wiki and MUD services proved the most fertile ground for stealing tokens, and the hunt for the lead was fierce as teams vied for offensive points. At this early stage in the competition, teams like Immunix and Anomaly were trading shots for first, and we were hanging around fourth or fifth place. Our defense at this point was rated fairly highly, but our attacking lagged as we struggled to discover vulnerabilities to exploit. Nevertheless, we kept the leaders in sight as we automated our initial attacks and analyzed the more complex services deployed.
As the competition entered its 12th hour, Immunix had emerged as the top-rated team. Many of the teams at this point decided to retire significant numbers of members in order to stay fresh for the final push tomorrow, including us. However, during the night, several members of our team refined our existing attack scripts and continued analyzing services, and as a result we, along with a few other teams, were able to creep up the standings until Immunix had been displaced from the top three.
By the morning, when most of the teams returned to the competition, NPS had already staked out first place due to their solid defense. We were in third or fourth place, but were soon to change that situation dramatically. A hole was discovered in the credit card processing server, and that exploit, along with further refinements of existing attacks and repulsing attacks against our network, allowed us to launch a major offensive against the other teams. Over the next few hours, we steadily climbed the scoreboard until we had come within 10 points of NPS, who had refused to budge from first place.
From here on in, it was a desperate race to overtake NPS. Exploit after exploit was developed for variations of the existing vulnerabilities, and new defensive patches were applied as the other teams adjusted their attacks. Unfortunately, with time running out and other teams (aka point sources) dropping out of the race, we simply hit the time limit in our bid to overtake NPS. It was a valiant effort, but second would have to do.
In the final analysis, we definitely made an impression. Our attacking points far exceeded everyone else's scores, but our defensive token retention left something to be desired. NPS, on the other hand, had managed to implement an excellent defense by taking advantage of a feature of the incoming traffic, and thus went home with all the prizes, even if it was unsexily done. ;-)
In any case, thanks again to the ghettohackers for organizing the event, and we will definitely see you next year!
First was so close we could taste it, but at the end of 30-plus grueling hours the Naval Postgraduate School, competing as the Skewl of Root, was able to hang on to a 3 point margin of victory at 38 points, with the Enemy Combatants at 35 points, and Immunix coming in third with 8 points. Given that this was our first year competing, second is a great result, and I think we gave a foreshadowing of the hammer that will be brought down next year with our attack performance this time around.
Here were this year's team members, in alphabetical order:
- Davide Balzarotti
- Wilson Chen
- Paul Haas
- Oddbjoern Heimdal
- Christopher Kruegel
- Darren Mutz
- Dan Nurmi
- William Robertson
- Fredrik Valeur
- Giovanni Vigna
The competition itself started off on a rocky note. We knew that we would be given several VMware images with services to deploy and defend on our own network and to attack on the other teams' networks, but we were definitely not prepared to face two Windows images, a first in DEFCON history! Being proper UNIX hackers, some time was lost exploring the images and attempting to lock down access to the host and its services, but one could take comfort in the fact that the other teams were almost certainly in the same boat. (Incidentally, the choice of Windows as a host image was a significant blow to Immunix's strategy, which has traditionally been to port the services to their security-enhanced platform and dial in access control specifications for each of them.) The two images turned out to be the frontend and backend servers for a simple web-based banking application, with deployed services including a wiki, forum, MUD, and credit card transaction processing system, among others.
The probes began almost immediately, but some time passed before a team scored the first offensive point. Initially, the wiki and MUD services proved the most fertile ground for stealing tokens, and the hunt for the lead was fierce as teams vied for offensive points. At this early stage in the competition, teams like Immunix and Anomaly were trading shots for first, and we were hanging around fourth or fifth place. Our defense at this point was rated fairly highly, but our attacking lagged as we struggled to discover vulnerabilities to exploit. Nevertheless, we kept the leaders in sight as we automated our initial attacks and analyzed the more complex services deployed.
As the competition entered its 12th hour, Immunix had emerged as the top-rated team. Many of the teams at this point decided to retire significant numbers of members in order to stay fresh for the final push tomorrow, including us. However, during the night, several members of our team refined our existing attack scripts and continued analyzing services, and as a result we, along with a few other teams, were able to creep up the standings until Immunix had been displaced from the top three.
By the morning, when most of the teams returned to the competition, NPS had already staked out first place due to their solid defense. We were in third or fourth place, but were soon to change that situation dramatically. A hole was discovered in the credit card processing server, and that exploit, along with further refinements of existing attacks and repulsing attacks against our network, allowed us to launch a major offensive against the other teams. Over the next few hours, we steadily climbed the scoreboard until we had come within 10 points of NPS, who had refused to budge from first place.
From here on in, it was a desperate race to overtake NPS. Exploit after exploit was developed for variations of the existing vulnerabilities, and new defensive patches were applied as the other teams adjusted their attacks. Unfortunately, with time running out and other teams (aka point sources) dropping out of the race, we simply hit the time limit in our bid to overtake NPS. It was a valiant effort, but second would have to do.
In the final analysis, we definitely made an impression. Our attacking points far exceeded everyone else's scores, but our defensive token retention left something to be desired. NPS, on the other hand, had managed to implement an excellent defense by taking advantage of a feature of the incoming traffic, and thus went home with all the prizes, even if it was unsexily done. ;-)
In any case, thanks again to the ghettohackers for organizing the event, and we will definitely see you next year!
Friday July 02, 2004
Snort alert verification v0.9.6 has been released for snort v2.1.3.
The patch can be downloaded from the project download page.
Thursday July 01, 2004
The ghettohackers have put up their analysis of the CTF qualifiers as well as the solutions which makes for interesting reading if you're into that kind of thing.
Seems like they used our solution for stage8; nice work, Chris. :-)
Tuesday June 29, 2004
Each year, DEFCON hosts a Capture the Flag (CTF)
challenge, inviting hacking groups from all over the world to participate in a
competition to determine who can simultaneously compromise the most machines
while successfully defending their own. I'm happy to report that the Enemy
Combatants, a team comprising current and former hackers from the RSG, has successfully passed the qualifying round held
last weekend, and has thus won a slot in the CTF to occur at DEFCON 0xc!
The format of the qualifier was a little different than last year's, which was web-based and could be completed for the most part within a few hours. This time around, the competition was hosted on a highly-modified Debian machine with the grsecurity kernel patch applied. Teams were given shell access to a set of "stage" directories, each of which contained a setuid program to be exploited and a SECRETCODE file containing a MD5 hash. The idea was to exploit each stage one-by-one and thus elevate privileges in order to read the secret code, which was sent to the organizers, and access the next stage. There were twelve stages in all, and though no team actually exploited all twelve, Immunix was able to make it past stage 9. We were working on 9, and had an exploit working locally, but unfortunately ran out of time. :-( In any case, it was enough to place fourth overall and second among the teams that didn't take advantage of the "secret," which was revealed after the contest had ended on the qualifier IRC channel. Two teams were able to pass all twelve stages by simply sending in the codes for each stage, since it turned out that the MD5 hash for each stage was simply the hash of the name of the stage. So, passing a stage was as simple as the following:
I plan on putting up some analysis of the stages, including the vulnerabilities and how we exploited them, some time in the near future. In the meanwhile, many thanks to the GhettoHackers for organizing and running the CTF, and we'll see you in Vegas this summer!
The format of the qualifier was a little different than last year's, which was web-based and could be completed for the most part within a few hours. This time around, the competition was hosted on a highly-modified Debian machine with the grsecurity kernel patch applied. Teams were given shell access to a set of "stage" directories, each of which contained a setuid program to be exploited and a SECRETCODE file containing a MD5 hash. The idea was to exploit each stage one-by-one and thus elevate privileges in order to read the secret code, which was sent to the organizers, and access the next stage. There were twelve stages in all, and though no team actually exploited all twelve, Immunix was able to make it past stage 9. We were working on 9, and had an exploit working locally, but unfortunately ran out of time. :-( In any case, it was enough to place fourth overall and second among the teams that didn't take advantage of the "secret," which was revealed after the contest had ended on the qualifier IRC channel. Two teams were able to pass all twelve stages by simply sending in the codes for each stage, since it turned out that the MD5 hash for each stage was simply the hash of the name of the stage. So, passing a stage was as simple as the following:
$ echo "stage1" | md5sum
Nevertheless, I prefer our way. :-PI plan on putting up some analysis of the stages, including the vulnerabilities and how we exploited them, some time in the near future. In the meanwhile, many thanks to the GhettoHackers for organizing and running the CTF, and we'll see you in Vegas this summer!