Last month I started working on something that feels extremely counter-intuitive. Building targets for a hacking ‘Capture The Flag‘ event. The normal behaviour of a security specialist is to secure everything. This time, I had to create a system that is insecure on purpose. At the same time, it should not be so obvious that it is simple. In other words, finding the right balance between security holes and security measures. Besides insecure software itself, security misconfiguration is one of the main reasons systems are vulnerable. Therefore I chose a debian platform which is fairly secure. On top of that, I installed wordpress, which of course is known for its many insecure plugins.

Secure platform

By choosing debian as a foundation, a secure operating system was at the core of the target. This created numerous challenges in itself. For debian it appeared to be difficult to find vulnerable packages such as mysql, openssh-server or apache. Debian has a pretty stable testing/patching policy and as soon as a vulnerability is discovered, it appears that many developers are working on patches. I installed the apache webserver and a mysql database on top as preparation for a wordpress blog. In addition, I installed phpmyadmin. For security by obscurity reasons, I ‘moved’ the installation to /mysqladmin as a directory. I also  created a minimal admin panel in the /sysadmin directory on the webserver.

Insecure configuration

This is where the insecure configuration started. Of course, security by obscurity is a bad idea to begin with. The /sysadmin directory could easily be found using tools such as nikto, dirb or dirbuster. There was some ‘protection’  in place using a .htaccess restriction. Using a tool such as Nikto, this was easily breached. Other mistakes also allowed the .htaccess file to be directly accessed. This enabled you to find the file containing usernames and passwords for the /sysadmin portal.

These passwords were either with md5 or sha1 hashed. This was an easy job for john the ripper to crack. Another well-known issue of password-reuse was hidden. One of the administrators re-used his password as an ssh-login. Once inside, a hint was given that all system administrators have their own TODO.txt file.

Mistakes – making things too insecure

When the CTF was running was the moment where I learned that, even if you plan things well, things go wrong. A script I created to be used, appeared to be able to do much more than planned. Using the script, it was easy to find the flag hidden in the /root directory and also the wp.sql file hidden there.

A second mistake was that the /etc/wordpress/ configuration files were world-readable. Leaving the wordpress SQL passwords readable for anyone who is interested. So no need to access the /root directory at all for that.  As a last mistake, it appeared that the password for the wordpress user was also picked out by Nikto during its scan. This was not intended as it made the challenge much easier to win.

All in all it was a nice experience to make things insecure on purpose!