strip_tags remove predefinidas parametros función funciones ejemplos ejemplo cuál php security grep

remove - Funciones PHP aprovechables



strip_tags php ejemplo (23)

Estoy tratando de construir una lista de funciones que se pueden usar para la ejecución de código arbitrario. El propósito no es enumerar las funciones que deben estar en la lista negra o deshabilitadas. Más bien, me gustaría tener a mano una lista de palabras clave de bandera roja con capacidad de grep al buscar puertas traseras en un servidor comprometido.

La idea es que si desea crear un script PHP malicioso de uso múltiple, como un script "web shell" como c99 o r57, tendrá que usar una o más de un conjunto relativamente pequeño de funciones. en algún lugar del archivo para permitir que el usuario ejecute código arbitrario. La búsqueda de esas funciones lo ayuda a reducir más rápidamente un pajar de decenas de miles de archivos PHP a un conjunto relativamente pequeño de scripts que requieren un examen más detenido.

Claramente, por ejemplo, cualquiera de los siguientes se consideraría malicioso (o codificación terrible):

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

Etcétera.

Al buscar en un sitio web comprometido el otro día, no noté una pieza de código malicioso porque no me di cuenta de que preg_replace podría ser peligroso por el uso de la bandera /e (¿ cuál, en serio? ¿Por qué incluso eso está ahí ?) . ¿Hay otros que me perdí?

Aquí está mi lista hasta ahora:

Shell Ejecutar

  • system
  • exec
  • popen
  • backtick operator
  • pcntl_exec

Ejecutar PHP

  • eval
  • preg_replace (con /e modificador)
  • create_function
  • include [ _once ] / require [ _once ] ( vea la respuesta de mario para detalles de explotación)

También podría ser útil tener una lista de funciones que puedan modificar archivos, pero imagino que el 99% del tiempo en el código de explotación contendrá al menos una de las funciones anteriores. Pero si tiene una lista de todas las funciones capaces de editar o generar archivos, publíquela y la incluiré aquí. (Y no estoy contando mysql_execute , ya que es parte de otra clase de exploit).

¿Qué pasa con los elementos sintácticos peligrosos?

La " variable variable " ( $$var ) encontrará una variable en el alcance actual con el nombre de $ var. Si se usa mal, el usuario remoto puede modificar o leer cualquier variable en el alcance actual. Básicamente una eval más débil.

Ej: escribes algo de código $$uservar = 1; , entonces el usuario remoto establece $uservar en "admin", lo que hace que $admin se establezca en 1 en el alcance actual.

Aparte de la construcción del lenguaje eval , existe otra función que permite la ejecución de código arbitrario: assert

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

Aquí hay una lista de funciones que mi proveedor deshabilita por motivos de seguridad:

  • exec
  • dl
  • show_source
  • apache_note
  • apache_setenv
  • closelog
  • debugger_off
  • debugger_on
  • define_syslog_variables
  • escapeshellarg
  • escapeshellcmd
  • ini_restore
  • registro abierto
  • pasar a través de
  • pclose
  • pcntl_exec
  • popen
  • proc_close
  • proc_get_status
  • procedimiento
  • proc_open
  • proc_terminate
  • shell_exec
  • syslog
  • sistema
  • url_exec

Específicos de plataforma, pero también vectores ejecutivos teóricos:

  • dotnet_load ()
  • nuevo COM ("WScript.Shell")
  • nuevo Java ("java.lang.Runtime")
  • event_new () - muy eventualmente

Y hay muchos más métodos que disfrazan:

  • proc_open es un alias para popen
  • call_user_func_array ("exE" .chr (99), array ("/ usr / bin / damage", "--all"));
  • file_put_contents ("/ cgi-bin / nextinvocation.cgi") && chmod (...)
  • PharData :: setDefaultStub - algunos trabajos más para examinar el código en archivos .phar
  • runkit_function_rename ("exec", "innocent_name") o APD rename_function

Esta no es una respuesta per se, pero aquí hay algo interesante:

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

Con el mismo espíritu, call_user_func_array() se puede utilizar para ejecutar funciones ofuscadas.

Estas funciones también pueden tener algunos efectos desagradables.

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

Los dos primeros pueden agotar toda la memoria disponible y los últimos mantienen el agotamiento ...

Hay un montón de vulnerabilidades de PHP que se pueden desactivar mediante la configuración en el archivo PHP.ini. Un ejemplo obvio es register_globals, pero dependiendo de la configuración, también puede ser posible incluir o abrir archivos desde máquinas remotas a través de HTTP, que pueden explotarse si un programa utiliza nombres de archivo variables para cualquiera de sus funciones de manejo de archivos include () o.

PHP también permite la función de función variable al agregar () al final de un nombre de variable, por ejemplo, $myvariable(); Llamará al nombre de la función especificado por la variable. Esto es explotable; por ejemplo, si un atacante puede hacer que la variable contenga la palabra ''eval'' y pueda controlar el parámetro, entonces puede hacer lo que quiera, aunque el programa no contenga la función eval ().

Hubo una discusión sobre esto en security.stackexchange.com recientemente.

Funciones que pueden ser utilizadas para la ejecución de código arbitrario.

Bueno, eso reduce un poco el alcance, pero dado que ''imprimir'' puede usarse para inyectar javascript (y, por lo tanto, robar sesiones, etc.) todavía es algo arbitrario.

no es para enumerar funciones que deben ser incluidas en la lista negra o deshabilitadas de otra manera. Más bien, me gustaría tener una lista capaz de grep

Ese es un enfoque sensato.

Sin embargo, considere la posibilidad de escribir su propio analizador; muy pronto encontrará un enfoque basado en grep fuera de control (awk sería un poco mejor). ¡Muy pronto también comenzarás a desear que hayas implementado una lista blanca también!

Además de los obvios, recomiendo marcar cualquier cosa que incluya un argumento que no sea un literal de cadena. Cuidado con __autoload () también.

La mayoría de los ataques en el código utilizan múltiples fuentes de acceso, o múltiples pasos para ejecutarse. Buscaría no solo un código o método con código malicioso, sino todos los métodos, funciones que se ejecutan o llaman. La mejor seguridad también incluiría la codificación y validación de los datos del formulario a medida que entran y salen.

Observe también la definición de las variables del sistema, luego se pueden llamar desde cualquier función o método en el código.

Me sorprende que nadie haya mencionado el echo y la print como puntos de explotación de seguridad.

Las secuencias de comandos entre sitios (XSS) son un grave problema de seguridad, ya que son incluso más comunes que los ataques de ejecución de código del lado del servidor.

Mi VPS está configurado para deshabilitar las siguientes funciones:

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 tiene suficientes funciones potencialmente destructibles que su lista puede ser demasiado grande para grep. Por ejemplo, PHP tiene chmod y chown, que podrían usarse para simplemente desactivar un sitio web.

EDITAR: Quizás desee crear un script de bash que busque un archivo para una serie de funciones agrupadas por peligro (funciones que son malas, funciones que son peores, funciones que nunca deberían usarse) y luego calcule la relatividad del peligro. que el archivo impone en un porcentaje. Luego, envíe esto a un árbol del directorio con los porcentajes etiquetados al lado de cada archivo, si es mayor que un umbral de, por ejemplo, un 30% de peligro.

Para construir esta lista utilicé 2 fuentes. Un estudio en escarlata y RATS . También agregué algunos de los míos a la mezcla y la gente en este hilo me ayudó.

Edición: después de publicar esta lista, me puse en contacto con el fundador de RIPS y, a partir de ahora, esta herramienta busca el código PHP para el uso de todas las funciones de esta lista.

La mayoría de estas llamadas de función se clasifican como sumideros. Cuando una variable contaminada (como $ _REQUEST) se pasa a una función de sumidero, tiene una vulnerabilidad. Los programas como RATS y RIPS utilizan una funcionalidad similar a grep para identificar todos los sumideros de una aplicación. Esto significa que los programadores deben tener mucho cuidado al usar estas funciones, pero si estuvieran prohibidos, no podría hacer mucho.

" Con gran poder viene una gran responsabilidad " .

--Stan Lee

Comando de Ejecución

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

Ejecución de código PHP

Además de eval hay otras formas de ejecutar el código PHP: include / require se puede usar para la ejecución remota de código en la forma de inclusión de archivos locales y vulnerabilidades de archivos remotos .

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());

Lista de funciones que aceptan devoluciones de llamada

Estas funciones aceptan un parámetro de cadena que podría usarse para llamar a una función de la elección del atacante. Dependiendo de la función, el atacante puede o no tener la capacidad de pasar un parámetro. En ese caso, se podría utilizar una función de Information Disclosure como phpinfo() .

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,

Divulgación de información

La mayoría de estas llamadas a funciones no son sumideros. Pero más bien puede ser una vulnerabilidad si alguno de los datos devueltos es visible para un atacante. Si un atacante puede ver phpinfo() es definitivamente una vulnerabilidad.

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

Otro

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

Funciones del sistema de archivos

Según RATS, todas las funciones del sistema de archivos en php son desagradables. Algunos de estos no parecen ser muy útiles para el atacante. Otros son más útiles de lo que piensas. Por ejemplo, si allow_url_fopen=On entonces se puede usar una url como ruta de archivo, por lo que se puede copy($_GET[''s''], $_GET[''d'']); se puede utilizar para cargar un script PHP en cualquier parte del sistema. Además, si un sitio es vulnerable a una solicitud de envío a través de GET, todas las funciones del sistema de archivos pueden utilizarse para canalizar y atacar a otro host a través de su servidor.

// 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

Particularmente quisiera agregar unserialize () a esta lista. Ha tenido una larga historia de varias vulnerabilidades, incluida la ejecución de código arbitrario, la denegación de servicio y la pérdida de información en la memoria. Nunca debe llamarse a los datos proporcionados por el usuario. Muchos de estos vuls han sido arreglados en lanzamientos durante los últimos años de rocío, pero aún conserva un par de vuls desagradables en el momento actual de la escritura.

Para obtener más información acerca de las funciones / uso de php dudosos, consulte el Proyecto Hardened PHP y sus avisos. También los proyectos recientes Mes de seguridad PHP y Mes de errores de PHP 2007.

También tenga en cuenta que, por diseño, la deserialización de un objeto hará que se ejecuten las funciones del constructor y del destructor; otra razón para no llamarlo en los datos proporcionados por el usuario.

Puede encontrar una lista continuamente actualizada de receptores sensibles (funciones php explotables) y sus parámetros en RIPS /config/sinks.php, un analizador de código fuente estático para vulnerabilidades en aplicaciones PHP que también detecta puertas traseras PHP.

Sé que se ha mencionado move_uploaded_file , pero la carga de archivos en general es muy peligrosa. Sólo la presencia de $_FILES debería plantear alguna preocupación.

Es bastante posible incrustar código PHP en cualquier tipo de archivo. Las imágenes pueden ser especialmente vulnerables con comentarios de texto. El problema es particularmente problemático si el código acepta la extensión que se encuentra dentro de los datos $_FILES tal cual.

Por ejemplo, un usuario podría cargar un archivo PNG válido con código PHP incorporado como "foo.php". Si el script es particularmente ingenuo, puede copiar el archivo como "/uploads/foo.php". Si el servidor está configurado para permitir la ejecución de secuencias de comandos en los directorios de carga de usuarios (a menudo el caso, y una terrible supervisión), entonces puede ejecutar instantáneamente cualquier código PHP arbitrario. (Incluso si la imagen se guarda como .png, es posible que el código se ejecute a través de otras fallas de seguridad).

Una lista (no exhaustiva) de cosas para verificar en las subidas:

  • Asegúrese de analizar los contenidos para asegurarse de que la carga sea del tipo que dice ser
  • Guarde el archivo con una extensión de archivo conocida y segura que nunca se ejecutará
  • Asegúrese de que PHP (y cualquier otra ejecución de código) esté deshabilitado en los directorios de carga de usuarios

Se descubrieron varios desbordamientos de búfer utilizando funciones de caracteres de 4 bits que interpretan el texto. htmlentities () htmlspecialchars ()

en la parte superior, una buena defensa es usar mb_convert_encoding () para convertir a una sola codificación antes de la interpretación.

Supongo que no podrá realmente encontrar todas las posibles vulnerabilidades al analizar los archivos de origen.

  • Además, si aquí se proporcionan listas realmente geniales, puede perderse una función que puede ser explotada.

  • Todavía podría haber código malvado "oculto" como este

$ myEvilRegex = base64_decode (''Ly4qL2U ='');

preg_replace ($ myEvilRegex, $ _POST [''código'']);

  • ahora puedes decir, simplemente extiendo mi script para que coincida con esto

  • pero luego tendrás ese "código posiblemente malvado" que además está fuera de su contexto

  • así que para estar (pseudo) seguro, deberías escribir un buen código y leer tú mismo todo el código existente

También tenga en cuenta la clase de "vulnerabilidades de interrupción" que permiten leer y escribir ubicaciones de memoria arbitrarias.

Estas funciones afectan funciones como trim (), rtrim (), ltrim (), explode (), strchr (), strstr (), substr (), chunk_split (), strtok (), addcslashes (), str_repeat () y más . Esto se debe en gran parte, pero no exclusivamente, a la función de paso por referencia del tiempo de llamada del idioma que ha estado en desuso por 10 años pero no está deshabilitado.

Para más información, vea la charla de Stefan Esser sobre vulnerabilidades de interrupción y otros problemas de PHP de nivel inferior en BlackHat USA 2009 Slides Paper

Este documento / presentación también muestra cómo se puede usar dl () para ejecutar código de sistema arbitrario.

Temo que mi respuesta sea un poco negativa, pero ...

En mi humilde opinión, todas las funciones y métodos disponibles pueden usarse con propósitos nefarios. Piense en ello como un efecto de goteo de la nefariedad: una variable se asigna a un usuario o entrada remota, la variable se usa en una función, el valor de retorno de función usado en una propiedad de clase, la propiedad de clase usada en una función de archivo, Etcétera. Recuerde: una dirección IP falsificada o un ataque de intermediario puede explotar todo su sitio web.

Su mejor apuesta es rastrear de principio a fin cualquier posible usuario o entrada remota, comenzando con $_SERVER , $_GET , $_POST , $_FILE , $_COOKIE , include(some remote file) ( si allow_url_fopen está allow_url_fopen ), todas las demás funciones / clases que tratan con archivos remotos, etc. Usted crea programáticamente un perfil de seguimiento de pila de cada valor suministrado por el usuario o remoto. Esto se puede hacer programáticamente obteniendo todas las instancias repetidas de la variable asignada y las funciones o métodos en los que se usa, luego compilando de forma recursiva una lista de todas las apariciones de esas funciones / métodos, y así sucesivamente. Examínelo para asegurarse de que primero pasa por las funciones adecuadas de filtrado y validación en relación con todas las demás funciones que toca. Esto es, por supuesto, un examen manual, de lo contrario tendrá un número total de cambios de case igual al número de funciones y métodos en PHP (incluido el definido por el usuario).

Alternativamente, para manejar solo las entradas del usuario, haga que una clase de controlador estático se inicialice al comienzo de todos los scripts, lo que 1) valida y almacena todos los valores de entrada proporcionados por el usuario contra una lista blanca de propósitos permitidos; 2) borra esa fuente de entrada (es decir, $_SERVER = null ). Se puede ver de dónde viene un poco naziesque.

Tendría que buscar para incluir ($ tmp) y requerir (HTTP_REFERER) y * _once también. Si un script de exploit puede escribir en un archivo temporal, podría incluirlo más adelante. Básicamente una evaluación de dos pasos.

E incluso es posible ocultar código remoto con soluciones alternativas como:

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

Además, si su servidor web ya ha sido comprometido, no siempre verá el mal sin codificar. A menudo, el shell de explotación está codificado en gzip. Piense en include("zlib:script2.png.gz"); No hay evaluación aquí, todavía el mismo efecto.

Una fuente de hazañas interesantes no ha sido mencionada. PHP permite que las cadenas tengan 0x00 bytes en ellas. Las funciones subyacentes (libc) tratan esto como el final de una cadena.

Esto permite situaciones en las que se puede engañar al saneamiento en PHP (mal implementado), por ejemplo, en una situación como:

/// note: proof of principle code, don''t use $include = $_GET[''file'']; if ( preg_match("///.php$/",$include) ) include($include);

Esto podría incluir cualquier archivo, no solo los que terminan en .php , llamando a script.php?file=somefile%00.php

Por lo tanto, cualquier función que no obedezca la longitud de la cadena de PHP puede llevar a alguna vulnerabilidad.

pcntl_signal y pcntl_alarm a la lista.

Con la ayuda de esas funciones, puede solucionar cualquier restricción set_time_limit creada en el php.ini o en el script.

Este script, por ejemplo, se ejecutará durante 10 segundos a pesar de set_time_limit(1);

(El crédito va para Sebastian Bergmanns, tweet y 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"; }