This challenge was appropriately named as it leaked much more than most people would suspect.
The basic premise was that the password file was chosen from a GET parameter. In the same directory as the file, there was a default password file that the user could request via the webserver.
If one were to set the auth file to be the publicly visible one, and login with the username and password specified on the first line the challenge would provide the answer.
There is a basic security flaw in this challenge in that any file on the server can be included. From this I was able to determine (with reasonable certainty):
- What files were present on the system
- The contest host was Ubuntu 8.04.1
- The kernel version was 2.6.24-19.36-server
The first point is relatively simple. The script will fail if it tries to open a non-existant file, and thus can be used to verify the presence of files on the system.
The second and third points are related. The system essentially verifies the first two space-delimited words from the "auth file". If the file to open is set to /etc/issue, the username will be "Ubuntu," and the password will be "8.04.1." Thus if the script is fed these parameters and the file /etc/issue, it will return success if the system is Ubuntu 8.04.1. A similar technique for the file /proc/version_signature will return the kernel version.
These two techniques can be used for a variety of things:
- It is possible to verify which packages has been downloaded into the cache by APT.
- .htaccess and .htpasswd files can be probed for in the web accessible directories.
- It is possible to exhaust the memory of the server, and possibly force the system to swap to disk.
Admittedly the utility of the above points varies when looked at from an attack perspective. The presence of an .htaccess or .htpasswd file is of limited utility as it does not provide much information to an attacker.
The attack can be used to examine the apt cache for presence of security upgrades. An attacker simply has to crawl /var/cache/apt/archives on Debian-based systems to make reasonable guesses about the state of the system.
The final attack vector is exhausting the memory on the system by setting the file /dev/random as the auth file. This will cause excess memory consumption and can be used as part of a denial of service attack.
From a defensive perspective, all of the above attacks are less than desirable. The system leaks unnecessary information to an attacker, and in cases of an inadequately patched or improperly configured server, can quickly become a thorn in any system administrator’s side.
The easiest way to thwart the attacks is to setup the webserver in a chroot’ed environment, or perform proper sanitation of the input for the auth file. While some may shrug off the holes I presented above, from an overall security perspective any hole is too big.