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 Details

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
      /etc/ctf.key.
    * The game masters will *not* disclose any details of what the
      required services are, and they do occasionally expand the set of
      required services.
    * 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
      continuously.
    * 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.

Strategy:

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
Immunix server.

Game Analysis:

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
the game.

Security Analysis:

As stated in the summary, the Immunix server was never captured: enemy
flags were never placed on the Immunix server. However, several caveats
do apply:

    * 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
            resumed serving.
          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
following people:

    * 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

-- 
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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]