Hackit Contest

Ok, the contest is ready. I’ll start off with the information everybody has been waiting for:

IP: 80.190.250.213

There is a webserver running with a brief description of the target and rules of the contest http://80.190.250.213/ The webserver is actually part of the contest since people are supposed to deface this page. To make it a bit more interresting, the ssh sessions are recorded with script and saved here for everyone to see (e.g. “less -r filename”).

Rules and Target of the contest:
As stated above, deface this page. To achieve this goal, everything is allowed. Do what you need/want to achieve the goal.
Unfortunatly we will still need a short list of actions that are not allowed:

  • (D)DoS against this box, or via this box against other hosts are
    of course not allowed
  • Brute Force attacks against accounts are not prohibited … but trust me, you really don’t want to waste your time with that
  • Be nice, don’t try to make the accounts or box unusable for others
  • If you are doing something that isn’t aimed at solving the contest, than it probably isn’t allowed

A few details to the box and the system:

  • It is a vmware box (so I can reset it and/or access the console without any problems)
  • Linux debian testing is installed
  • some basic hardening done with normal linux tools and grsecurity
  • Don’t worry, I left enough room for you all to poke around, I didn’t make it “too secure to have fun”
  • This time no holes were intentionally added to the system. On the other hand there will also be no updates of software packages or changes to the RBAC system, no matter what security flaws arise (or I may have overseen)
  • On a scale of 1 to 10: I’d say the security is around 7

Have fun 😉

btw. I’m also posting this in the buha forums for anyone who prefers a German description.

HackIt server nearly ready

I spent the last few days fine tuning the HackIt server I mentioned last week. After lots of thought on how I was going to punch holes into the security, I decided on a different approach. Since in the past contests I always found it fustrating to see people with high skills trying out stuff I would never have dreamed of, and in the end to get beaten by people who by sheer luck tried out the right thing at the right time … I decided to minimize the “luck” factor of the contest by not putting any holes in the server on purpose.

What I am going to do is not update any of the packages any more from now on. I’m doing an update right now as I post this, and from here on no more updates. There will also be no updates or changes to the RBAC system. The only changes I will be making to the box from now on, are if it breaks and needs to be fixed.
-> The box will be shamelessly neglected, waiting to be owned.

If nothing strange pops up tonight, I will be posting information about the contest tomorrow in the buha forum, here and a few other places …

[Work in progress] HackIt Server

The last HackIt I set up was a few years ago, so I decided to have a go at it again. As before it will be a Linux server. And I will also have some fun with grsecurity kernel patches (including the additional Role-Based Access Control system). So nothing new up to here. I’m also going to be using most of the features I used back then too (like “trusted path execution” and no outgoing/server sockets for users, …)
Last time it was separate hardware on my little DSL line (meaning back then all users had to share a 128kbit upstream). This time it will be a vmware box on a 100Mbit Internet connection and it’s own IP, so no more worry about laggy ssh sessions.

I’ll post more details as soon as this gets more “ready-for-release”. Right now I’m still hardening the box, I still haven’t decided on which holes I’m going to build into it to make it a “HackIt”.

rkhunter and linux kernel 2.6.26-3

The combination of rkhunter and the latest stable Linux kernel has been giving me problems the last few days. Considering that I couldn’t find anything about this on the Internet, I guess it must be something special about my box. rkhunter makes my server hang when it gets to the part where it checks for hidden processes if I use the 2.6.26-3 kernel. If I use the same .config and make myself a 2.6.25-16 (the latest stable 2.6.25) rkhunter runs without problems.

While it is nice that I found the problem, it was a pain narrowing down the culprit. The last few days I had noticed that my server was dead in the water every morning and had at first suspected vmware, since I had installed that a few days ago on the server (and had to make a new kernel to get it running). Well, everything is fine now. Next time I have to update my kernel, I’ll remember to do a test run of /etc/cron.daily

Hartknäckige Scriptkiddies

Seit gestern Abend versucht irgendein Scriptkiddie mein SSH zu Bruteforce’n. Das an sich ist eigentlich nichts erwähnenswertes da es zum täglichen Müll gehört (wie die Spammer die offene Mail Relays suchen) und eigentlich zum allgemein “Rauschen” im Internet gehört. Nach ein paar Fehlversuche landet bei mir die IP automatisch für eine gewisse Zeit auf eine Blackliste und wird per iptables gesperrt.

Was das ganze hier jedoch interssant macht ist die Hartknäckigkeit derjenigen. Die meisten Kiddies merken “ach mist, meine IP wird geblockt” und versuchen es vielleicht noch von eine 2. IP bevor sie aufgeben. Der hier jedoch hat wohl eine ganze menge an Zombie Rechner zur Verfügung weil er seit ein paar Stunden es schafft nach jeden IP Ban von einen neuen Host seinen Brute Force Attacke erneut zu starten. Jepp, ihr habt richtig gelesen, er führt sie nicht weiter, wo er aufgehört hat, sondern fängt jedesmal wieder von vorne an.

Ich gib ihn 8/10 Punkte für Ressourcen, 9/10 für Hartknäckigkeit und 2/10 Punkte für die Durchführung.