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):

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?

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.)

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

43

as a sidenote, I'd like to see that list published in the near future, if possible :)
–
yodaJun 25 '10 at 4:40

16

@yoda: published where? I'll keep the list updated here, since SO is the Source of All Knowledge.
–
tylerlJun 25 '10 at 8:36

@Billy: the e modifier makes the replacement string to be evaluated as PHP code.
–
nikc.orgSep 13 '10 at 6:20

1

It has to be said: executing the code in the regex is something Perl and possibly Python do too, not something exclusive to PHP. I don't know the details, though.
–
Adriano Varoli PiazzaSep 20 '10 at 18:21

23 Answers
23

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.

Edit: After posting this list I contacted the founder of RIPS and as of now this tools searches PHP code for the use of every function in this list.

Most 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 and RIPS use grep like functionality to identify all sinks in an application. This means that programmers should take extra care when using these functions, but if they where all banned then you wouldn't be able to get much done.

"With great power comes great responsibility."

--Stan Lee

Command Execution

exec - Returns last line of commands output
passthru - Passes commands output directly to the browser
system - Passes commands output directly to the browser and returns last line
shell_exec - Returns commands output
`` (backticks) - Same as shell_exec()
popen - Opens read or write pipe to process of a command
proc_open - Similar to popen() but greater degree of control
pcntl_exec - Executes a program

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.

List of functions which accept callbacks

These functions accept a string parameter which could be used to call a function of the attacker's choice. Depending on the function the attacker may or may not have the ability to pass a parameter. In that case an Information Disclosure function like phpinfo() could be used.

Information Disclosure

Most of these function calls are not sinks. But rather it maybe a vulnerability if any of the data returned is viewable to an attacker. If an attacker can see phpinfo() it is definitely a vulnerability.

Other

extract - Opens the door for register_globals attacks (see study in scarlet).
parse_str - works like extract if only one argument is given.
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.
Also if a site is vulnerable to a request send via GET everyone of those file system functions can be abused to channel and attack to another host through your server.

@whatnick Actually I don't see an appreciable difference between PHP and other web application languages. At the end of the day programmers need the ability to eval() code, to execute system commands, access a database, and read/write to files. This code can be influenced by an attacker, and that is a vulnerability.
–
RookSep 19 '10 at 9:59

8

So many functions banned! Are you the host of my website by any chance?
–
Andrew DunnSep 20 '10 at 18:20

2

@Andrew Dunn haha, no. If you banned all of these functions than no PHP application would work. Especially include(), require(), and the file system functions.
–
RookSep 20 '10 at 18:31

3

Imho preg_match with e is no harm. Manual says "Only preg_replace() uses this modifier; it is ignored by other PCRE functions."
–
NikiCNov 5 '10 at 8:01

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.

Depending on how PHP is configured, include can actually include code from arbitrary URLs. Something like include "example.com/code.phps&quot;; I saw a compromised website that had been broken into using a combination of that feature and register_globals.
–
BlackAuraJun 25 '10 at 17:15

@BlackAura how did regiser_globals fit in to the attack? Is it something that could have been pulled off just as easily by using $_GET[xyz] as opposed to $xyz? Or was there something deeper to it?
–
tylerlJun 25 '10 at 19:29

I'm not quite sure why it was done this way, but the website kept doing things like this: include($prefix . '/filename.php'); I think the idea was that you could move the core code outside the web root, by setting the $prefix variable in the config file. If the attacker sets that value to something like "example.com/code.phps?&quot;, PHP will include that remote file instead. Near as I can tell, a 'bot actually managed to break in using a generic exploit. Apparently, a lot of old PHP code made that mistake. Basically, NEVER let any user-submitted value anywhere near an include statement.
–
BlackAuraJun 26 '10 at 9:08

2

include does not require parentheses; include "…" suffices.
–
GumboSep 15 '10 at 8:40

@Wallacoloo: It's even easier to hide a compiled language CGI backdoor as there are no easy text strings to grep for in a binary.
–
IiridaynNov 5 '10 at 19:24

2

Nice.. I tried with $f = 'ev'.'al'; $f($_POST['c']); but did not work since 'eval' is not a function but a special construct like include, echo, etc. -> interesting that exec() is not and so this would work..
–
redShadowNov 8 '10 at 0:12

That would be a vector that affects the client, not the server, technically.
–
damianbMar 10 '12 at 14:12

@damianb: If a site uses Ajax, and I can cause arbitrary javascript to be evaluated in any user's session, I could cause a lot of mischief on the server.
–
Bill KarwinMar 10 '12 at 17:56

"on the server" ....to clients connected; it does not affect the server backend. That falls under client-side exploits, such as cursorjacking, CSRF, header injection, and so on. It's dangerous, yes, but it falls under a different classification entirely.
–
damianbMar 11 '12 at 18:17

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.

I'm interested to hear more about the unserialize issue. Is this just a bug in the implementation, or is it a flaw in the design (i.e. can't be fixed)? Can you point me to more information about that issue in particular?
–
tylerlJun 25 '10 at 19:27

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.

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 SlidesPaper

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

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.

I see what you mean, but this looks like a different class of exploit. Is there a way you can execute arbitrary PHP code with this mechanism (without using any of the above functions)? Or can it only be abused for changing variable contents? If I'm missing something, I want to get it right.
–
tylerlJun 25 '10 at 5:50

6

You can also use variable functions which will be impossible to work out without evaluating the script. For example: $innocentFunc = 'exec'; $innocentFunc('activate skynet');.
–
eriscoJun 25 '10 at 6:56

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

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.

Well that reduces the scope a little - but since 'print' can be used to inject javascript (and therefore steal sessions etc) its still somewhat arbitrary.

isn't to list functions that should be blacklisted or otherwise disallowed. Rather, I'd like to have a grep-able list

That's a sensible approach.

Do consider writing your own parser though - very soon you're going to find a grep based approach getting out of control (awk would be a bit better). Pretty soon you're also going to start wishing you'd implemented a whitelist too!

In addition to the obvious ones, I'd recommend flagging up anything which does an include with an argument of anything other than a string literal. Watch out for __autoload() too.

IMHO, every single function and method out there can be used for nefarious purposes. Think of it as a trickle-down effect of nefariousness: a variable gets assigned to a user or remote input, the variable is used in a function, the function return value used in a class property, the class property used in a file function, and so forth. Remember: a forged IP address or a man-in-the-middle attack can exploit your entire website.

Your best bet is to trace from beginning to end any possible user or remote input, starting with $_SERVER, $_GET, $_POST, $_FILE, $_COOKIE, include(some remote file) (ifallow_url_fopen is on), all other functions/classes dealing with remote files, etc. You programatically build a stack-trace profile of each user- or remote-supplied value. This can be done programatically by getting all repeat instances of the assigned variable and functions or methods it's used in, then recursively compiling a list of all occurrences of those functions/methods, and so on. Examine it to ensure it first goes through the proper filtering and validating functions relative to all other functions it touches. This is of course a manual examination, otherwise you'll have a total number of case switches equal to the number of functions and methods in PHP (including user defined).

Alternatively for handling only user input, have a static controller class initialized at the beginning of all scripts which 1) validates and stores all user-supplied input values against a white-list of allowed purposes; 2) wipes that input source (ie $_SERVER = null). You can see where this gets a little Naziesque.

Yes of course, as with many programming languages, there's no end of ways to hide your evil deeds. However I think that misses the intention of what I was asking. The scenario is something like this: You're called to help after a website is hacked. The client will pay extra if you can secure his website before morning. The site contains 475 PHP files, and the useful forensic details have been destroyed -- you've got a huge haystack and a notoriously small needle... where do you start looking? (My day job in a nutshell)
–
tylerlMar 27 '11 at 8:35

Most of attacks in the code use multiple access sources, or multiple steps to execute themselves. I would search not only for a code, or method having malicious code, but all methods, function executing or calling it. The best security would also include encoding and validating form data as it comes in and out.

Watch also out from defining system variables, they can afterwards be called from any function or method in the code.

You can find a continuously updated list of sensitive sinks (exploitable php functions) and their parameters in RIPS /config/sinks.php, a static source code analyser for vulnerabilities in PHP applications that also detects PHP backdoors.