=== Grace Period

OS was Linux Gentoo 2006.1 (kernel 2.6.17-gentoo-r8)

There kernel was probably vulnerable to vmsplice local root + numerous DOSes.
Most notable vulnerable userspace stuff:
GLSA 200610-11 (and others) / openssl (get_shared_ciphers potential remote hole) - afaik not really used much by apps
GLSA 200803-24 (and others) / libpcre - anything using regular expressions via libpcre has a potential hole
GLSA 200707-14 / tcpdump - remote root if we run tcpdump with at least '-s0 -v'.
+ DOS/XSS in apache and holes in software we didn't have but considered installing (like lighttpd or tshark).

== System Upgrade:

# eselect profile set 2008.0/server
# emerge - -sync
# emerge - -nodeps portage
# emerge -uD system
# dispatch-conf
# emerge -uD world
# dispatch-conf
# emerge hardened-source # linux-2.6.23-hardened-r12 with grsec chroot restrictions - in anticipation of potential vulnerable services we may be asked to run

Changed profile to 2008.0/server

So we have shiny Apache2 (2.2.8) and SSH (4.7p1) to latest version. We installed also the 3rd service: OpenNTPd. We selected these services because they are used widely and thus unlikely to have 0days floating around or at least unlikely people would consider wasting them on the wargame.

All services are running on standard ports.

== Securing

We created user accounts, changed root pass, disabled root ssh login. We fixed both ssh and IP gw MAC addresses (no arp). Also turn off accept_redirects.

We also disabled the sendmail from startup scripts.

So the remaining attack surface for our team was pretty much:
# SSH, apache and ntpd - unlikley to be broken
# lesbos admin tasks, updating packages etc - we found out gentoo signes their package files: as long as we don't do a new "emerge - -sync" we can't be fed tampered packages via 'emerge'.
# lesbos login - we had limited the possibility of a MITM (just in case) and knew the ssh host key, user accounts either had nonbruteforcable or disabled passwords (and key auth).
# gateway box - we had good passwords, so as long as we refrained from doing anything dangerous, we were good there as well. also knew ssh host key.

from that point on, we pretty much concentrated on attacking.

=== Open season

== The gateway box

There was a bunch of hassling with setuid/setgid binaries on the gw. A number of people run these binaries without properly analyzing them and lost their accounts because of it.

There was a particular binary in /dev/shm (and in /tmp too, probably) that was planted by beist and contained some odd-looking strings in "strings" output. binary analysis suggested they are xored by 0x05 and 0x09, which revealed them to be essentially "cp /bin/bash /home/beist/hh/$$" and "chmod 6777 /home/beist/hh/$$".

We hardlinked the contents of that directory (at least all the different suid shells) to our home which turned out to be good idea as beist later removed that directory (at least made it invisible). From there we got livinded's (absolut) and aksnowman's (gothicus) accounts.

There were also 2 accounts with the default "changeme" password still in place - z3x and chickenman. someone planted statically linked 6777 backdoors in their homes .../fun (also for plasmatonic, not sure how they got his account). We reversed the backdoor (setregid/setreuid(argv[1])+system(argv[2])) and wrote one that was similar except installed our ssh key to their authorized_keys as well. We then run an interesting command as plasmatonic ("ssh -i .ssh/id_rsa_absolut absolut") and waited for interested parties to use the .../fun and check the ssh key out. Not sure if it was the ssh key, but some time later we found that our ssh key worked on vooduhal's (absolut) and eps's (gothicus) accounts.

We developed a ptrace-based session snooper that attached to a process and logged their stdin/stdout/stderr. as we had the handy setuid binaries for others' accounts, the snooper was also made setuid and juggled its saved/effective/real uids to look like our process in ps output but still able to claim the victims privileges for the moment it needed to do a PTRACE_ATTACH.

We claimed we have absolut box on #roothack and vooduhal was kind enough to check if a file called "SUPRISE" had been planted to their /root/.ssh/. We traced his "-bash" process and got his login credentials and su credentials.

The next day (when they were offline) we owned their box, disabled their accounts and closed down all services except for ssh to avoid an own-back. We also quickly checked the kernel source for modifications (with a simple find for recently modified source files) but were unable to find anything. vooduhal later confirmed they didn't have any backdoors in place.

We also had a really short trace of aksnowman's actions and login to his box (with ssh on a different port and a different username from .ssh/config). But that login got us something weird called "LatteraShell~#" and we decided to wait fro either eps or aksnowman to log further into their machine to understand what was happening there. Then, however, ocyrus ended the wargame.

We also had a cronjob doing netstat+ps aux so that we could lookup a database of what people are doing from times we could not be logged in (we are from Europe, so we were on on the exact opposite times than most people).

== Traffic Monitoring

Because of the topology of the network we were able to keep trace of the whole network traffic by simply sniffing it.

This provided lots of information about O.S. and configuration of the others servers. By monitoring day-by-day traffic we discovered the following:

* Loki was running Slackware and probably using swaret for managment. [It wasn't running Mobotix as nmap suggested :D]
* Loki was sometimes downloading stuff from ftp/http.
* Gothicus was running Ubuntu Hardy
* Gothicus SSH port was 18966
* Gothicus was probably using nessus.
* Absolut changed its ssh server to another ip and another port (10.0.1.200:8022)

== Handling of attacks

There was no major attack that we know against us. There were only portscans.

== Absolut

They used 3 IPs .192, .199 and .200. We compiled an ssh client with custom protocol header to connect to Absolut ssh and thus avoided using their (potentially backdoored) binary. The BBS itself was vulnerable (as Lattera kept saying) but pretty useless. The BBS was running with sqlite 3.5.6 and was prone to sql-injection. Unfortunatly this version of sqlite didn't had any known vulnerability so it was a dead end. We later owned it via snooped credentials.

== Captainmorgan

The MUD they were hosting was well written. We spent a bit of time going through the source code trying to identify some vulnerability. Unfortunatly we didn't find anything useful.

== Gothicus

Was down (or seemed down) from time to time. We had some snooped credentials for their box but were waiting for better information when the game ended.

== Loki

Some of their accounts were owned (marshallmellow maybe by his password "r0b3r7", which he later changed) and wild complained that his team had gone missing in action.