Code Injection vulnerabilities are often easy to exploit and because they allow attackers to execute arbitrary PHP code using the application’s own privileges, they can result in a lot of damage. They are typically exploited to upload some kind of backdoor to the application server. Once the backdoor has been uploaded, the attacker is likely to try to root the server with privilege escalation exploits. Regardless of whether or not privilege escalation is successful, the attacker has free range to loot whatever databases are accessible to them and possibly attack other computers on any private network(s) the server is connected to. If the server hosts a popular application, the attacker might redirect the users to an exploit pack, which is a malicious page that infects visitors with malware. The attacker might also use the server to send out spam/phishing attack emails or to perform Denial of Service attacks on other servers.
Code Injection vulnerabilities are not elusive, so it should be easy (and important) to find and fix them before the attackers do. The root cause of Code Injection vulnerabilities in PHP is passing attacker's data to the eval() function Finding all possible vulnerable spots is a simple matter of finding all code that uses the eval() function, which includes using the preg_replace() function with the "e" modifier. Code that uses the eval() function should always be rewritten. When the eval() function is no longer necessary for the application, it is recommended to install the Suhosin hardened PHP patch and use it to disable eval() and the "e" modifier for preg_replace(). Doing so yields the added benefit of breaking most obfuscated malicious PHP code.
The first mitigation step is to find all potentially vulnerable code. To do so, search your application code for "eval" and "preg_replace". Use a spreadsheet to keep track of all code that uses eval(). Also keep track of code that uses preg_replace() with the “e” modifier, because it actually calls eval(). Be sure to also note the file that contains the potential vulnerability and the line of code. Once all potentially vulnerable code has been located, it should be rewritten. The exact way to rewrite the code depends on what the code in question does, so there is no general pattern for doing so. Keep in mind that it should be possible to implement most applications without using eval().
After all code that uses eval() has been rewritten, disable eval() and the "e" modifier for preg_replace() by installing the Suhosin hardened PHP patch and configuring it using "suhosin.executor.disable_eval" and "suhosin.executor.disable_emodifier" directives in the php.ini file (I wrote a separate blog on configuring the php.ini file).. This will help purge all eval() from your application and will break virtually all obfuscated malicious PHP code and many common backdoors.
As shown, preventing Code Injection vulnerabilities is not too difficult. When you consider how dangerous they are and the potential impact they might have on your users, it is wise investment to spend some time and energy into preventing them.
