Exploitable PHP functions

PHP, a widely used server-side scripting language, powers a significant portion of the web. While offering flexibility and power, certain PHP functions, if misused or improperly implemented, can introduce security vulnerabilities. Understanding these exploitable PHP functions is crucial for developers to build secure and robust web applications. Neglecting these potential pitfalls can expose websites to various attacks, compromising sensitive data and user privacy. This article delves into some of the most commonly exploited PHP functions, explaining the risks they pose and providing best practices for secure coding.

eval()

eval() is a powerful function that executes a string as PHP code. While convenient for dynamic code generation, it’s also highly dangerous. If user-supplied input finds its way into the eval() function, attackers can inject malicious code, potentially granting them control over the server.

For example, imagine a script that uses eval() to process user input for a simple calculator: eval("$user_input;");. If a malicious user submits system(‘rm -rf /’);, the server could execute this command, potentially deleting critical files. Avoid using eval() whenever possible. Consider safer alternatives like call_user_func() or dedicated libraries for specific tasks.

A safer approach involves strictly sanitizing and validating user input before using it in any dynamic code execution context. Employing parameterized queries or prepared statements further mitigates the risk of SQL injection vulnerabilities when interacting with databases.

exec(), shell_exec(), and system()

These functions allow PHP scripts to execute shell commands. Similar to eval(), if user input is not properly sanitized, these functions can be exploited to execute arbitrary commands on the server.

For instance, if a web application uses system() to process user-supplied filenames, an attacker could inject commands like ; rm -rf / to cause significant damage. Always sanitize user input and use escaping mechanisms to prevent command injection vulnerabilities. Consider using safer alternatives or restricting the allowed commands.

Employing input validation and filtering effectively restricts the characters and patterns allowed in user-supplied data. This proactive measure prevents the execution of malicious commands by limiting the potential for exploitation. Regular expression patterns designed to match and block dangerous characters enhance the security posture by filtering out potential threats.

include() and require()

These functions are used to include external files in PHP scripts. However, if the file path is dynamically generated based on user input without proper validation, attackers can potentially include malicious files. This can lead to remote code execution or disclosure of sensitive information.

Imagine a script that includes a file based on a URL parameter: include($_GET[‘file’]);. An attacker could manipulate the URL to include a file from a malicious external server, potentially compromising the website. Always validate and sanitize user input before using it in include() or require() statements. Consider using absolute paths whenever possible.

Implementing rigorous access controls on included files safeguards against unauthorized access and manipulation. Regularly auditing included files for security vulnerabilities enhances the overall security posture by addressing potential weaknesses before they can be exploited.

unserialize()

The unserialize() function converts a serialized string back into a PHP object. However, if an attacker can manipulate the serialized string, they can potentially inject malicious objects, leading to object injection vulnerabilities. These vulnerabilities can be exploited to manipulate application logic, bypass authentication, or even execute arbitrary code.

Protecting against object injection involves carefully validating and sanitizing user input before passing it to the unserialize() function. Employing secure coding practices and using parameterized queries or prepared statements mitigates SQL injection vulnerabilities and other potential risks.

A secure coding approach includes whitelisting allowed classes during deserialization, and using strong type hinting to further restrict the types of objects that can be unserialized. Additionally, implementing robust exception handling mechanisms prevents errors from revealing sensitive information to potential attackers.

Protecting Against Exploitable PHP Functions

• Sanitize and Validate Input: Always sanitize and validate user input before using it in any context, especially with functions like eval(), exec(), and include(). Use appropriate filtering techniques like regular expressions and escaping mechanisms.
• Principle of Least Privilege: Run PHP scripts with the lowest possible privileges. This limits the potential damage if a vulnerability is exploited.

1. Identify potentially exploitable functions in your code.
2. Review how user input is handled and ensure proper sanitization and validation.
3. Implement appropriate security measures, such as input filtering, escaping, and access controls.
4. Regularly audit your code and update PHP to patch known vulnerabilities.

According to OWASP (Open Web Application Security Project), injection flaws, including those related to exploitable PHP functions, are among the most critical web application security risks. These vulnerabilities can have severe consequences, including data breaches, system compromise, and denial of service attacks.

Infographic Placeholder: [Insert infographic illustrating common PHP vulnerabilities and best practices.]

Learn more about web application security best practices. External Resources:

• OWASP
• PHP Security
• CWE

FAQ

Q: How can I prevent command injection vulnerabilities?

A: Sanitize user input, use escaping mechanisms, and consider using safer alternatives to functions like exec() and system(). Restrict the allowed commands and implement strong access controls.

By understanding the risks associated with these functions and following secure coding practices, developers can significantly enhance the security of their PHP applications. Regular code audits, vulnerability scanning, and staying updated with the latest security best practices are crucial for mitigating potential threats and protecting user data. While PHP offers powerful tools for web development, responsible and secure coding is paramount to prevent exploitation and maintain a secure online environment. Exploring topics like secure coding guidelines, penetration testing, and vulnerability management can further strengthen your security knowledge and protect your web applications from evolving threats.

Question & Answer :

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

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.

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

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.

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), 'sqlite_create_aggregate' => array(2, 3), 'sqlite_create_function' => 2, 

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.

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

// open filesystem handler fopen tmpfile bzopen gzopen SplFileObject->__construct // write to filesystem (partially in combination with reading) chgrp chmod chown copy file_put_contents lchgrp lchown link mkdir move_uploaded_file rename rmdir symlink tempnam touch unlink imagepng - 2nd parameter is a path. imagewbmp - 2nd parameter is a path. image2wbmp - 2nd parameter is a path. imagejpeg - 2nd parameter is a path. imagexbm - 2nd parameter is a path. imagegif - 2nd parameter is a path. imagegd - 2nd parameter is a path. imagegd2 - 2nd parameter is a path. iptcembed ftp_get ftp_nb_get // read from filesystem file_exists file_get_contents file fileatime filectime filegroup fileinode filemtime fileowner fileperms filesize filetype glob is_dir is_executable is_file is_link is_readable is_uploaded_file is_writable is_writeable linkinfo lstat parse_ini_file pathinfo readfile readlink realpath stat gzfile readgzfile getimagesize imagecreatefromgif imagecreatefromjpeg imagecreatefrompng imagecreatefromwbmp imagecreatefromxbm imagecreatefromxpm ftp_put ftp_nb_put exif_read_data read_exif_data exif_thumbnail exif_imagetype hash_file hash_hmac_file hash_update_file md5_file sha1_file highlight_file show_source php_strip_whitespace get_meta_tags