My previous post was intended to demonstrate that malicious software could also be affected by security vulnerabilities. The example considered a remote code execution in a PHP page used in a phishing attack. However, the debate is still open concerning the possibility that the security issue had been intentionally introduced as a back door. I want to now focus my attention on another piece of malicious code used to control and coordinate the systems belonging to a particular botnet. A botnet is a group of infected zombie machines under a common control infrastructure; usually, a Web application is employed to remotely instruct the systems in order to pursue a variety of illicit purposes. An authentication bypass vulnerability was found to be affecting the command and control Web interface used in this particular botnet, thereby allowing users to bypass the authentication mechanism and take the control of the botnet and its zombies. The code responsible for authenticating the credentials supplied by the users is shown below: The application allows the user to enter the administrative interface only if the “logged” variable evaluates to true (line 29). Let’s have a deeper look at the “else” branch, starting on line 18. The “logged” variable is used to temporarily store the value of the authentication cookie, which is supposed to contain the password whose validity is going to be checked on line 20. But, consider the situation of passing a cookie named “logged” that contains an arbitrary value to the page—it will fail this check (so the variable will not be set to true), but the evaluation on line 29 will be true since the value of “logged” is still set to the arbitrary value passed along within the cookie. This would allow access to the Web application without the need to know the valid credentials.
In some cases, a botnet is like any other software; for example, it is regularly developed and new versions are periodically released. Let’s have a look at the authentication routine implemented in a new version, which was released sometime after the vulnerable one I have just discussed:
Even if a more sophisticated method of managing user sessions is implemented, the application still suffers from an authentication bypass issue. The key is on line 4, which instructs the browser of an unauthenticated user to jump on the “login.php” page; however, the script does not terminate its execution, thus returning to the command and control administrative interface due to a missing “exit” instruction. The fact that two different versions of the application are affected by the same vulnerability, even if the authentication routine has been completely rewritten, is really quite bizarre. It is again hard to say if we are facing poor coders who lack basic security development principles, or very smart people who are adding back doors to their programs in order to ensure they can regain possession of the software at any time.