Posts Tagged ‘ctf’

IRISS Conference 2009

Sunday, November 22nd, 2009

I had the joy to attend the first annual IRISS Conference 2009 which is a for free conference held by IRISS, the Irish CERT.

It was about cybercrime in general and there were speaker from e.g. SANS, IRISS -the local cert- or Team Cymru which I already enjoyed at DNF CERT Conf at the beginning of the year.

One talk I attended was by a local polices cybercrime investigation team. He basically talked about the goodness of creating movement profiles with GSM data and ISP keeping IP to customer data to catch criminals…

Then we participated in HackEire, a Capture the Flag style contest. We ran second. Not too bad for our sucky preparation and the fact that we spent more than an hour to make a Mac share its 3G uplink with two Linux Notebooks over (encrypted -didn’t work-) WiFi. The game network was 10.0.1.0/23 and the Mac automatically and not changable was 10.0.2.0/24. Although the networks overlapped by one bit I expected it to work for the majority of the packets being sent. But we failed. Hard. So hard, that the Mac couldn’t take part in the game anymore… I need to polish either my understanding of networking or my passion for hating Apple.

This CtF, however, was a bit different since there was one virtual network for everyone. I.e. no team had an own server or an own virtual network. There were four machines which were supposed to be owned in a given order. That wasn’t immediately clear and there were many tarpits to waste a lot of time. I.e. a Kernel in a supposed-to-be vulnerable version which is not exploitable, or a separate PHP user for the Webserver with a locked down home directory, tempting you to mess around with PHP scripts to investigate.

And the end of the day, the contest was about collecting secret keys to decrypt a file afterwards. The secret keys were more or less obviously lying around once the machine has been pwned. Passphrases to that secret keys were either user passwords or otherwise easily guessable strings.

The Machines were:

  1. Linux Webserver. To be 0wned with a password being served on a page from the webserver. A bit obfuscated though, so that one had to use the source. Once SSHed to that host, secrings were lying around in ~/gnupg/. Also, weird processes were running that connected to a strange host outside the network (4) to send a password over the wire.
  2. BIND on windows (sic!). To be pwned via the conficker exploit. Also, one should crack a users password using THCs Hydra.
  3. Linux Mailserver. With SSH Server only visible when coming from (1). Log in with password from (2). Machine was running an old kernel, thus sooner or later you g0t root. Then search for keyring in home directories. Also, crack the shadow using a John that’s capable of cracking SHA256 (i.e. not the most recent version shipped with Ubuntu).
  4. “hidden” DB server on Windows, only connectable from (1). You could find that machine by looking at the network interfaces of (1). You’d see that it has a second interface with a different IP thus inviting you to scan the new subnet. Luckily, there was an smbclient on (1) and with credentials from (1), one could enumerate all users (smbclient -L). Then, with the other credentials found on (1), connect and get keyring as well as final encrypted file.

That final file could be decrypted using keys and passphrases obtained earlier. Out came an ELF binary that looked, smelled and quacked like “ls”. However, it contained a steganographically hidden text file. Using a standard stego tool shipped with Backtrack, it’s possible to obtain the very final CSV file.

I not only liked the fact that they posted hints on the wall every now and then, but also that they actively walked around, talking to the teams and helped them actually achieving stuff. In fact, I wouldn’t even have thought about transferring zones from that BIND instance using AXFR or checking the machines whether they have an smbclient installed.

While we were playing, I bricked my sudo by trying to add a line without knowing the syntax. I couldn’t do sudo nano /etc/sudoers afterwards as it couldn’t parse the file, effectively leaving me without root access. I think I’ll better use visudo now…