Exploitable PHP functions

Question

I'm trying to build a list of functions that can be used for arbitrary code execution. The purpose isn't to list functions that should be blacklisted or otherwise disallowed. Rather, I'd like to have a grep-able list of red-flag keywords handy when searching a compromised server for back-doors.

The idea is that if you want to build a multi-purpose malicious PHP script -- such as a "web shell" script like c99 or r57 -- you're going to have to use one or more of a relatively small set of functions somewhere in the file in order to allow the user to execute arbitrary code. Searching for those those functions helps you more quickly narrow down a haystack of tens-of-thousands of PHP files to a relatively small set of scripts that require closer examination.

Clearly, for example, any of the following would be considered malicious (or terrible coding):

<? eval($_GET['cmd']); ?>

<? system($_GET['cmd']); ?>

<? preg_replace('/.*/e',$_POST['code']); ?>

and so forth.

Searching through a compromised website the other day, I didn't notice a piece of malicious code because I didn't realize preg_replace could be made dangerous by the use of the /e flag (which, seriously? Why is that even there?). Are there any others that I missed?

Here's my list so far:

Shell Execute

• system
• exec
• popen
• backtick operator
• pcntl_exec

PHP Execute

• eval
• preg_replace (with /e modifier)
• create_function
• include[_once] / require[_once] (see mario's answer for exploit details)

It might also be useful to have a list of functions that are capable of modifying files, but I imagine 99% of the time exploit code will contain at least one of the functions above. But if you have a list of all the functions capable of editing or outputting files, post it and I'll include it here. (And I'm not counting mysql_execute, since that's part of another class of exploit.)

Answer 1

Several buffer overflows were discovered using 4bit characters functions that interpret text. htmlentities() htmlspecialchars()

were at the top, a good defence is to use mb_convert_encoding() to convert to single encoding prior to interpretation.

Answer 2

I'm surprised no one has mentioned echo and print as points of security exploitation.

Cross-Site Scripting (XSS) is a serious security exploit, because it's even more common than server-side code execution exploits.

Answer 3

I know move_uploaded_file has been mentioned, but file uploading in general is very dangerous. Just the presence of $_FILES should raise some concern.

It's quite possible to embed PHP code into any type of file. Images can be especially vulnerable with text comments. The problem is particularly troublesome if the code accepts the extension found within the $_FILES data as-is.

For example, a user could upload a valid PNG file with embedded PHP code as "foo.php". If the script is particularly naive, it may actually copy the file as "/uploads/foo.php". If the server is configured to allow script execution in user upload directories (often the case, and a terrible oversight), then you instantly can run any arbitrary PHP code. (Even if the image is saved as .png, it might be possible to get the code to execute via other security flaws.)

A (non-exhaustive) list of things to check on uploads:

• Make sure to analyze the contents to make sure the upload is the type it claims to be
• Save the file with a known, safe file extension that will not ever be executed
• Make sure PHP (and any other code execution) is disabled in user upload directories

Answer 4

Let's add pcntl_signal and pcntl_alarm to the list.

With the help of those functions you can work around any set_time_limit restriction created int the php.ini or in the script.

This script for example will run for 10 seconds despite of set_time_limit(1);

(Credit goes to Sebastian Bergmanns tweet and gist:

<?php
declare(ticks = 1);

set_time_limit(1);

function foo() {
    for (;;) {}
}

class Invoker_TimeoutException extends RuntimeException {}

class Invoker
{
    public function invoke($callable, $timeout)
    {
        pcntl_signal(SIGALRM, function() { throw new Invoker_TimeoutException; }, TRUE);
        pcntl_alarm($timeout);
        call_user_func($callable);
    }
}

try {
    $invoker = new Invoker;
    $invoker->invoke('foo', 1);
} catch (Exception $e) {
    sleep(10);
    echo "Still running despite of the timelimit";
}

Answer 5

Here is a list of functions my provider disables for security purposes:

• exec
• dl
• show_source
• apache_note
• apache_setenv
• closelog
• debugger_off
• debugger_on
• define_syslog_variables
• escapeshellarg
• escapeshellcmd
• ini_restore
• openlog
• passthru
• pclose
• pcntl_exec
• popen
• proc_close
• proc_get_status
• proc_nice
• proc_open
• proc_terminate
• shell_exec
• syslog
• system
• url_exec

Answer 6

What about dangerous syntactic elements?

The "variable variable" ($$var) will find a variable in the current scope by the name of $var. If used wrong, the remote user can modify or read any variable in the current scope. Basically a weaker eval.

Ex: you write some code $$uservar = 1;, then the remote user sets $uservar to "admin", causing $admin to be set to 1 in the current scope.