Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Crispin Cowan (crispin_at_wirex.com)
Date: Tue Aug 06 2002 - 01:05:56 CDT
This weekend, the WireX research team entered an Immunix server into the
DefCon <http://www.defcon.org/> Capture the Flag games, in which each of
the teams try to hack each other's servers, while simultaneously
defending their own server. The executive summary is that we placed 2nd,
coming withing a hare's breadth of winning the contest, and the Immunix
server was never captured.
Here is some very good coverage
<http://news.com.com/2100-1001-948404.html?tag=fd_top> of the event.
The rules <http://www.ghettohackers.net/ctf/> are somewhat complex. This
is a summary:
* There is a score server. It periodically surveys team server
nodes, looking for a complex of services. If it finds all services
functioning to its satisfaction, it awards a point to the owner of
the flag found on that server. The "flag" is just a big file in
* The game masters will *not* disclose any details of what the
required services are, and they do occasionally expand the set of
* If all services are not running, then no point is awarded for that
node. Further, if (say) the Green team's server is not fully
functional, then the Green team cannot score *any* points for
placing a Green flag on any other server.
* If the score server does not get a satisfactory response for any
service, it immediately stops polling that team's node and moves
on to another node.
* Score polling happens at random intervals. Attacking is permitted
* Bandwidth costs points: if a team is sending out a large amount of
data, they will be penalized point in proportion to the traffic.
* All traffic appearing at a teams' network appears to come from the
same source IP address, using a reverse-NAT router configuration.
This is so that teams cannot trivially firewall their node to only
accept traffic from the score server.
* The game masters issue each team a candidate distribution (a
VMWare image of a modified Red Hat 6.2 system) that has been
modified and configured such that:
o It fully satisfies the score server's queries.
o It is horribly vulnerable to all manner of attacks.
* Teams can do whatever they want with the candidate image to
attempt to provide the score server with satisfactory service
while attempting to prevent opposing teams from corrupting the
machine or replacing the flag.
Most teams took the approach of immediately launching the candidate
system, and attempting to ad hoc harden the system's security, and use
massive human intrusion detection to resist attacks, i.e. lots of sys
admins killing off login shells as fast as they can. This allowed them
to gain points quickly early in the game, by offiering services early,
and thus scoring a strong baseline for having their own server up.
The WireX team took the approach of deploying an Immunix server, and
porting the necessary services from the candidate distribution to the
Immunix server. This allowed us to maintain the integrity of the Immunix
server, and score points later in the game when attacks against the
candidate system are well-developed, but do not function against the
Our strategy was designed to test the security of Immunix, and was not
optimized towards winning the game. We lost substantial points early in
the game by failing to offer qualifying services: it took us 12 hours of
work to get a satisfactory set of services operational on Immunix (the
total game play was 26 hours over three days). The delay was *not* due
to any difficulty in offering these services, but rather because the
required set of services was a secret, which we could discover only by
attempting to offer services and watching for requests and failures, and
by deploying a network sniffer and analyzing traffic logs.
While trying to get the Immunix server to a satisfactory set of
services, we evenutally resorted to offering the candidate system as a
server so that we could sniff network traffic for successful score
server transactions. Naturally, the candidate server was penetrated, but
it did score some points for offering intact services, and did provide
critical information on the nature of the required services.
We delayed offering the candidate system in place of the Immunix system
for many hours. While this was in keeping with the fundamental goal of
security analysis for Immunix, it was not an optimal game strategy. We
strongly feel that if we had offered the candidate server in place of
the Immunix server much earlier, that we would have both scored more
points, and learned the required services for the Immunix server more
quickly, and as a result would have easily won the contest.
When we finally did get the Immunix server offering an acceptable set of
services, our score surged from near last to first place in under 1
hour, and we oscillated between first and second place for the rest of
As stated in the summary, the Immunix server was never captured: enemy
flags were never placed on the Immunix server. However, several caveats
* When we offered the candidate server instead of the Immunix
server, it was compromised and enemy flags were placed.
* While the Immunix server was never compromised ("0wned") several
of our services were compromised:
o Telnetd: Yes, it is foolish to *ever* offer telnet service,
which is why telnetd is not an officially supported service
for Immunix. We didn't even bother to provide a security
update for telnetd when it was found to be vulnerable some
months ago. But, telnetd was a service required by the score
server. An attacking team found the vulnerability in
telnetd, was abile to exploit it, and thus was able to
compromise our telnet service. We applied the patch and
o Perl: Another required service was a set of Perl CGI
scripts, which in turn contained numerous exploitable
vulnerabilities. SubDomain successfully confined these
scripts, until an attacker determined that a malloc call
could be passed to the Perl interpreter through these CGI
scripts, effectively consuming all of system memory. Better
resource management is called for.
o Webmin: Late in the game, the score server was changed to
require support for Webmin, a competitor to WireX's SSM web
management interface. Webmin provides too much authority to
web browsers, and is a very large and complex system. We did
deploy SubDomain profiles for Webmin, but we were not able
to develop good profiles for Webmin in the 2 hours we had
available. Attackers were able to exploit this to use Webmin
to force the Immunix server to reboot. The main lesson here
is that it takes more than 2 hours to SubDomain profile an
application of the complexity of Webmin or SSM.
* Intrusion Detection: While the Immunix strategy of intrusion
prevention was highly effective, intrusion detection is also
highly beneficial for game play, for several reasons:
o Protecting Services: SubDomain protects the *rest* of the
system from an attack against a service, but cannot protect
the service. Intrusion detection lets you know that you need
to do something.
o Denial-of-service: Intrusion detection helps you discover
that someone is DoS'ing you.
o Protecting the candidate system: Because of the delay in
porting required services to Immunix, it is necessary to
launch the candidate system that the game masters provide
ASAP. Intrusion detection would help defend when this sysetm
is inevitably rooted.
Future Game Strategy:
* Be proficient with VMWare: Configuring VMWare (especially
networking) is not easy, and is critical for effective CtF gaming.
We should practice with it before going to future contests.
* Put Immunix in VMWare: there is substantial advantage to running
play nodes in VMWare instead of on hard machines, both for the
candidate system and for Immunix. By Sunday, we ended up partially
immunizing the candidate system.
* Have hot spares: Configure VMWare to have several instances of
both the candidate system and the Immunix system, so that they can
be swapped over at a moment's notice when attacks occur.
* Bring an adaptive, inline firewall: The Snort project begot the
Hogwash firewall project, which has folded back into Snort as
in-line Snort. This package allows you to write elaborate blocking
and packet re-writing rules that would be very useful for blocking
various kinds of DoS attacks, and for protecting the candidate system.
Future Technology Strategy:
* Better resource management controls.
* Better intrusion event logging.
Acknowledgements: This could not have been possible without the
* DARPA <http://www.darpa.mil/>, for sponsoring our security research
* Increadible effort by the WireX research team
* Amazing efforts from the group of volunteers who joined the
Immunix team, including and especially Toby Kohlenberg, Jay Beale
<http://www.bastille-linux.org/jay/>, John Viega
<http://www.viega.org/>, and the Shmoo Group <http://www.shmoo.com/>.
-- Crispin Cowan, Ph.D. Chief Scientist, WireX http://wirex.com/~crispin/ Security Hardened Linux Distribution: http://immunix.org Available for purchase: http://wirex.com/Products/Immunix/purchase.html
_______________________________________________ Immunix-users mailing list Immunix-usersmail.wirex.com http://mail.wirex.com/mailman/listinfo/immunix-users