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

Backtick Operator Backtick on php manual

Answer 2

You'd have to scan for include($tmp) and require(HTTP_REFERER) and *_once as well. If an exploit script can write to a temporary file, it could just include that later. Basically a two-step eval.

And it's even possible to hide remote code with workarounds like:

 include("data:text/plain;base64,$_GET[code]");

Also, if your webserver has already been compromised you will not always see unencoded evil. Often the exploit shell is gzip-encoded. Think of include("zlib:script2.png.gz"); No eval here, still same effect.

Answer 3

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.

Answer 4

i'd particularly want to add unserialize() to this list. It has had a long history of various vulnerabilities including arbitrary code execution, denial of service and memory information leakage. It should never be called on user-supplied data. Many of these vuls have been fixed in releases over the last dew years, but it still retains a couple of nasty vuls at the current time of writing.

For other information about dodgy php functions/usage look around the Hardened PHP Project and its advisories. Also the recent Month of PHP Security and 2007's Month of PHP Bugs projects

Also note that, by design, unserializing an object will cause the constructor and destructor functions to execute; another reason not to call it on user-supplied data.

Answer 5

Plattform-specific, but also theoretical exec vectors:

• dotnet_load()
• new COM("WScript.Shell")
• new Java("java.lang.Runtime")
• event_new() - very eventually

And there are many more disguising methods:

• proc_open is an alias for popen
• call_user_func_array("exE".chr(99), array("/usr/bin/damage", "--all"));
• file_put_contents("/cgi-bin/nextinvocation.cgi") && chmod(...)
• PharData::setDefaultStub - some more work to examine code in .phar files
• runkit_function_rename("exec", "innocent_name") or APD rename_function

Answer 6

My VPS is set to disable the following functions:

root@vps [~]# grep disable_functions /usr/local/lib/php.ini
disable_functions = dl, exec, shell_exec, system, passthru, popen, pclose, proc_open, proc_nice, proc_terminate, proc_get_status, proc_close, pfsockopen, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid

PHP has enough potentially destructible functions that your list might be too big to grep for. For example, PHP has chmod and chown, which could be used to simply deactivate a website.

EDIT: Perhaps you may want to build a bash script that searches for a file for an array of functions grouped by danger (functions that are bad, functions that are worse, functions that should never be used), and then calculate the relativity of danger that the file imposes into a percentage. Then output this to a tree of the directory with the percentages tagged next to each file, if greater than a threshold of say, 30% danger.

Answer 7

Also be aware of the class of "interruption vulnerabilities" that allow arbitrary memory locations to be read and written!

These affect functions such as trim(), rtrim(), ltrim(), explode(), strchr(), strstr(), substr(), chunk_split(), strtok(), addcslashes(), str_repeat() and more. This is largely, but not exclusively, due to the call-time pass-by-reference feature of the language that has been deprecated for 10 years but not disabled.

Fore more info, see Stefan Esser’s talk about interruption vulnerabilities and other lower-level PHP issues at BlackHat USA 2009 Slides Paper

This paper/presentation also shows how dl() can be used to execute arbitrary system code.

Answer 8

To build this list I used 2 sources. A Study In Scarlet and RATS. I have also added some of my own to the mix and people on this thread have helped out.

Many of these function calls are classified as Sinks. When a tainted variable (like $_REQUEST) is passed to a sink function, then you have a vulnerability. Programs like RATS use a grep like functionality to identify all sinks in an application.

Command Execution

exec() - Executes a specified command and returns the last line of the
programs output
passthru() - Executes a specified command and returns all of the output
directly to the remote browser
`` (backticks) - Executes the specified command and returns all the output
in an array
system() - Much the same as passthru() but does not handle binary data
popen() - Executes a specified command and connects its output or input
stream to a PHP file descriptor
proc_open()
pcntl_exec()
shell_exec()

PHP Code Execution

Apart from eval there are other ways to execute PHP code: include/require can be used for remote code execution in the form of Local File Include and Remote File Include vulnerabilities.

eval()
assert()  - identical to eval()
preg_replace('/.*/e',...) - /e does an eval() on the match
create_function()
include()
include_once()
require()
require_once()
$_GET['func_name']($_GET['argument']);
$func = new ReflectionFunction($_GET['func_name']); $func->invoke(); or $func->invokeArgs(array());

List of functions which accept callbacks

Those can be used to hide execution of malicious functions.

Function                     => Position of callback arguments
'ob_start'                   =>  0,
'array_diff_uassoc'          => -1,
'array_diff_ukey'            => -1,
'array_filter'               =>  1,
'array_intersect_uassoc'     => -1,
'array_intersect_ukey'       => -1,
'array_map'                  =>  0,
'array_reduce'               =>  1,
'array_udiff_assoc'          => -1,
'array_udiff_uassoc'         => array(-1, -2),
'array_udiff'                => -1,
'array_uintersect_assoc'     => -1,
'array_uintersect_uassoc'    => array(-1, -2),
'array_uintersect'           => -1,
'array_walk_recursive'       =>  1,
'array_walk'                 =>  1,
'assert_options'             =>  1,
'uasort'                     =>  1,
'uksort'                     =>  1,
'usort'                      =>  1,
'preg_replace_callback'      =>  1,
'spl_autoload_register'      =>  0,
'iterator_apply'             =>  1,
'call_user_func'             =>  0,
'call_user_func_array'       =>  0,
'register_shutdown_function' =>  0,
'register_tick_function'     =>  0,
'set_error_handler'          =>  0,
'set_exception_handler'      =>  0,
'session_set_save_handler'   => array(0, 1, 2, 3, 4, 5),

Information Disclosure

phpinfo()
posix_mkfifo()
posix_getlogin()
posix_ttyname()
getenv()
get_current_user()
proc_get_status()
get_cfg_var()
disk_free_space()
disk_total_space()
diskfreespace()
getcwd()
getlastmo()
getmygid() 
getmyinode()
getmypid()
getmyuid() 

Other

extract - Opens the door for register_globals attacks (see study in scarlet).  
putenv
ini_set
mail - has CRLF injection in the 3rd parameter, opens the door for spam. 
header - on old systems CRLF injection could be used for xss or other purposes, now it is still a problem if they do a header("location: ..."); and they do not die();. The script keeps executing after a call to header(), and will still print output normally. This is nasty if you are trying to protect an administrative area. 
proc_nice
proc_terminate
proc_close
pfsockopen
fsockopen
apache_child_terminate
posix_kill
posix_mkfifo,
posix_setpgid
posix_setsid
posix_setuid

Filesystem Functions

According to RATS all filesystem functions in php are nasty. Some of these don't seem very useful to the attacker. Others are more useful than you might think. For instance if allow_url_fopen=On then a url can be used as a file path, so a call to copy($_GET['s'], $_GET['d']); can be used to upload a PHP script anywhere on the system.

chgrp
chmod
chown
copy
delete
file_exists
file_get_contents
file_put_contents
file
fileatime
filectime
filegroup
fileinode
filemtime
fileowner
fileperms
filesize
filetype
fopen
glob
is_dir
is_executable
is_file
is_link
is_readable
is_uploaded_file
is_writable
is_writeable
lchgrp
lchown
link
linkinfo
lstat
mkdir
move_uploaded_file
parse_ini_file
pathinfo
readfile
readlink
rename
rmdir
stat
symlink
tempnam
touch
umask
unlink
bzopen
gzopen
gzfile
imagepng  - 2nd parameter is a path.
imagewbmp - 2nd parameter is a path. 
imagejpeg - 2nd parameter is a path.
imagewbmp - 2nd parameter is a path.
imagexbm  - 2nd parameter is a path.
imagegif  - 2nd parameter is a path.
imagegd   - 2nd parameter is a path.

Answer 9

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 10

There are loads of PHP exploits which can be disabled by settings in the PHP.ini file. Obvious example is register_globals, but depending on settings it may also be possible to include or open files from remote machines via HTTP, which can be exploited if a program uses variable filenames for any of its include() or file handling functions.

PHP also allows variable function calling by adding () to the end of a variable name -- eg $myvariable(); will call the function name specified by the variable. This is exploitable; eg if an attacker can get the variable to contain the word 'eval', and can control the parameter, then he can do anything he wants, even though the program doesn't actually contain the eval() function.

Answer 11

This is not an answer per se, but here's something interesting:

$y = str_replace('z', 'e', 'zxzc');
$y("malicious code");

In the same spirit, call_user_func_array() can be used to execute obfuscated functions.

Answer 12

Apart from the eval language construct there is another function which allows arbitrary code execution: assert

assert('ex' . 'ec("kill --bill")');

Answer 13

These functions can also have some nasty effects.

• str_repeat()
• unserialize()
• register_tick_function()
• register_shutdown_function()

The first two can exhaust all the available memory and the latter keep the exhaustion going...

Answer 14

I guess you won't be able to really find all possible exploits by parsing your source files.

• also if there are really great lists provided in here, you can miss a function which can be exploitet

• there still could be "hidden" evil code like this

$myEvilRegex = base64_decode('Ly4qL2U=');

preg_replace($myEvilRegex, $_POST['code']);

• you could now say, i simply extend my script to also match this

• but then you will have that mayn "possibly evil code" which additionally is out of it's context

• so to be (pseudo-)secure, you should really write good code and read all existing code yourself

Answer 15

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.