Fonctions PHP exploitables

J'essaie de construire une liste de fonctions qui peuvent être utilisées pour l'exécution de code arbitraire. Le but n'est pas de répertorier les fonctions qui devraient être mises sur liste noire ou autrement interdites. Au lieu de cela, j'aimerais avoir une grepliste des mots clés à drapeau rouge à portée de main lors de la recherche de portes dérobées sur un serveur compromis.

L'idée est que si vous voulez créer un script PHP malveillant polyvalent - comme un script "web shell" comme c99 ou r57 - vous allez devoir utiliser une ou plusieurs fonctions relativement petites quelque part dans le fichier afin de permettre à l'utilisateur d'exécuter du code arbitraire. La recherche de ces fonctions vous aide à affiner plus rapidement une meule de foin de dizaines de milliers de fichiers PHP à un ensemble relativement petit de scripts qui nécessitent un examen plus approfondi.

De toute évidence, par exemple, l'un des éléments suivants serait considéré comme malveillant (ou terrible codage):

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

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

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

et ainsi de suite.

La recherche sur un site Web compromis l'autre jour, je n'ai pas remarqué un morceau de code malveillant parce que je ne savais pas que cela preg_replacepourrait être rendu dangereux par l'utilisation du /edrapeau ( ce qui, sérieusement? Pourquoi est-ce encore là ?). Y en a-t-il d'autres que j'ai ratés?

Voici ma liste jusqu'à présent:

Shell Execute

• system
• exec
• popen
• backtick operator
• pcntl_exec

PHP Execute

• eval
• preg_replace(avec /emodificateur)
• create_function
• include[ _once] / require[ _once] ( voir la réponse de mario pour les détails de l'exploit)

Il pourrait également être utile d'avoir une liste de fonctions capables de modifier des fichiers, mais j'imagine que 99% du temps, le code d'exploitation contiendra au moins une des fonctions ci-dessus. Mais si vous avez une liste de toutes les fonctions capables d'éditer ou de sortir des fichiers, postez-la et je l'inclurai ici. (Et je ne compte pas mysql_execute, car cela fait partie d'une autre classe d'exploit.)

Pour construire cette liste, j'ai utilisé 2 sources. Une étude dans Scarlet et RATS . J'ai également ajouté quelques-uns des miens au mix et les gens de ce fil ont aidé.

Edit: Après avoir publié cette liste, j'ai contacté le fondateur de RIPS et à partir de maintenant, cet outil recherche dans le code PHP l'utilisation de toutes les fonctions de cette liste.

La plupart de ces appels de fonction sont classés comme récepteurs. Lorsqu'une variable contaminée (comme $ _REQUEST) est passée à une fonction puits, alors vous avez une vulnérabilité. Des programmes comme RATS et RIPS utilisent une fonctionnalité de type grep pour identifier tous les récepteurs dans une application. Cela signifie que les programmeurs doivent faire très attention lors de l'utilisation de ces fonctions, mais s'ils sont tous interdits, vous ne pourrez pas faire grand-chose.

" Une grande puissance s'accompagne d'une grande responsabilité. "

--Stan Lee

Exécution de commande

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

Exécution de code PHP

En dehors de cela, evalil existe d'autres façons d'exécuter du code PHP: include/ requirepeut être utilisé pour l'exécution de code à distance sous la forme de vulnérabilités Local File Include et Remote File Include .

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

Liste des fonctions acceptant les rappels

Ces fonctions acceptent un paramètre de chaîne qui pourrait être utilisé pour appeler une fonction au choix de l'attaquant. Selon la fonction, l'attaquant peut ou non avoir la capacité de passer un paramètre. Dans ce cas, une Information Disclosurefonction comme phpinfo()pourrait être utilisée.

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,

Divulgation d'information

La plupart de ces appels de fonction ne sont pas des puits. Mais il s'agit plutôt d'une vulnérabilité si l'une des données renvoyées est visible pour un attaquant. Si un attaquant peut le voir, phpinfo()c'est certainement une vulnérabilité.

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

Autre

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

Fonctions du système de fichiers

Selon RATS, toutes les fonctions du système de fichiers en php sont désagréables. Certains d'entre eux ne semblent pas très utiles à l'attaquant. D'autres sont plus utiles que vous ne le pensez. Par exemple, si allow_url_fopen=Onune URL peut être utilisée comme chemin de fichier, un appel à copy($_GET['s'], $_GET['d']);peut être utilisé pour télécharger un script PHP n'importe où sur le système. De plus, si un site est vulnérable à une demande envoyée via GET, toutes ces fonctions du système de fichiers peuvent être utilisées de manière abusive pour canaliser et attaquer un autre hôte via votre serveur.

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

Vous devez rechercher include ($ tmp) et exiger également (HTTP_REFERER) et * _once. Si un script d'exploitation peut écrire dans un fichier temporaire, il pourrait simplement l'inclure plus tard. Fondamentalement, une évaluation en deux étapes.

Et il est même possible de masquer le code à distance avec des solutions de contournement comme:

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

De plus, si votre serveur Web a déjà été compromis, vous ne verrez pas toujours le mal non codé. Souvent, le shell d'exploitation est encodé en gzip. Pensez à include("zlib:script2.png.gz");No eval ici, toujours le même effet.

Ce n'est pas une réponse en soi, mais voici quelque chose d'intéressant:

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

Dans le même esprit, call_user_func_array()peut être utilisé pour exécuter des fonctions obscurcies.

Je suis surpris que personne ne l'ait mentionné echoet en printtant que points d'exploitation de la sécurité.

Le Cross-Site Scripting (XSS) est un sérieux exploit de sécurité, car il est encore plus courant que les exploits d'exécution de code côté serveur.

je voudrais en particulier ajouter unserialize () à cette liste. Il a une longue histoire de diverses vulnérabilités, notamment l'exécution de code arbitraire, le déni de service et la fuite d'informations de mémoire. Il ne doit jamais être appelé sur des données fournies par l'utilisateur. Beaucoup de ces vuls ont été corrigés dans les versions au cours des dernières années de rosée, mais il conserve encore quelques vuls désagréables au moment de la rédaction.

Pour d'autres informations sur les fonctions php douteuses / l'utilisation, regardez autour du projet PHP renforcé et ses conseils. Aussi le mois récent de PHP Security et le mois de 2007 des projets PHP Bugs

Notez également que, par conception, la désérialisation d'un objet entraînera l'exécution des fonctions constructeur et destructeur; une autre raison de ne pas l'appeler sur les données fournies par l'utilisateur.

Mon VPS est configuré pour désactiver les fonctions suivantes:

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 a suffisamment de fonctions potentiellement destructibles pour que votre liste soit trop grande pour être utilisée. Par exemple, PHP a chmod et chown, qui pourraient être utilisés pour désactiver simplement un site Web.

EDIT: vous pouvez peut-être créer un script bash qui recherche un fichier pour un tableau de fonctions regroupées par danger (fonctions qui sont mauvaises, fonctions qui sont pires, fonctions qui ne devraient jamais être utilisées), puis calculer la relativité du danger que le fichier impose en pourcentage. Ensuite, affichez-le dans une arborescence du répertoire avec les pourcentages balisés à côté de chaque fichier, s'il est supérieur à un seuil de 30% de danger.

Soyez également conscient de la classe des "vulnérabilités d'interruption" qui permettent la lecture et l'écriture d'emplacements de mémoire arbitraires!

Ceux-ci affectent des fonctions telles que trim (), rtrim (), ltrim (), explode (), strchr (), strstr (), substr (), chunk_split (), strtok (), addcslashes (), str_repeat () et plus encore . Ceci est en grande partie, mais pas exclusivement, dû à la fonction de passage par référence du temps d'appel de la langue qui est déconseillée depuis 10 ans mais non désactivée.

Pour plus d'informations, consultez le discours de Stefan Esser sur les vulnérabilités d'interruption et d'autres problèmes PHP de niveau inférieur lors du BlackHat USA 2009 Slides Paper

Cet article / présentation montre également comment dl () peut être utilisé pour exécuter du code système arbitraire.

Des vecteurs d'exécution spécifiques à la plate-forme, mais aussi théoriques:

• dotnet_load ()
• nouveau COM ("WScript.Shell")
• nouveau Java ("java.lang.Runtime")
• event_new () - très éventuellement

Et il existe de nombreuses autres méthodes de déguisement:

• proc_open est un alias pour popen
• call_user_func_array ("exE" .chr (99), array ("/ usr / bin / damage", "--all"));
• file_put_contents ("/ cgi-bin / nextinvocation.cgi") && chmod (...)
• PharData :: setDefaultStub - un peu plus de travail pour examiner le code dans les fichiers .phar
• runkit_function_rename ("exec", "innocent_name") ou APD rename_function

Outre la evalconstruction du langage, il existe une autre fonction qui permet l'exécution de code arbitraire:assert

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

Une source d'exploits intéressants n'a pas été mentionnée. PHP permet aux chaînes de 0x00contenir des octets. Les fonctions sous-jacentes (libc) traitent cela comme la fin d'une chaîne.

Cela permet des situations où (mal implémenté) la vérification de l'intégrité en PHP peut être dupe, par exemple dans une situation comme:

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

Cela peut inclure n'importe quel fichier - pas seulement ceux se terminant par .php- en appelantscript.php?file=somefile%00.php

Ainsi, toute fonction qui n'obéira pas à la longueur de chaîne de PHP peut entraîner une certaine vulnérabilité.

Qu'en est-il des éléments syntaxiques dangereux?

La " variable variable " ( $$var) trouvera une variable dans la portée actuelle du nom de $ var. En cas d'utilisation incorrecte, l'utilisateur distant peut modifier ou lire n'importe quelle variable dans la portée actuelle. Fondamentalement, un plus faible eval.

Ex: vous écrivez du code $$uservar = 1;, puis l'utilisateur distant se positionne $uservarsur "admin", ce $adminqui entraîne sa définition 1dans la portée actuelle.

Je suppose que vous ne pourrez pas vraiment trouver tous les exploits possibles en analysant vos fichiers source.

• aussi s'il y a de très bonnes listes fournies ici, vous pouvez manquer une fonction qui peut être exploitée

• il pourrait toujours y avoir un code diabolique "caché" comme celui-ci

$ myEvilRegex = base64_decode ('Ly4qL2U =');

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

• vous pouvez maintenant dire, j'étends simplement mon script pour qu'il corresponde

• mais vous aurez alors ce "code peut-être maléfique" qui est en plus hors de son contexte

• donc pour être (pseudo-) sûr, vous devez vraiment écrire du bon code et lire vous-même tout le code existant

Opérateur Backtick Backtick sur le manuel php

Je sais que cela move_uploaded_filea été mentionné, mais le téléchargement de fichiers en général est très dangereux. La seule présence de $_FILESdevrait susciter quelques inquiétudes.

Il est tout à fait possible d'incorporer du code PHP dans n'importe quel type de fichier. Les images peuvent être particulièrement vulnérables aux commentaires de texte. Le problème est particulièrement gênant si le code accepte l'extension trouvée dans les $_FILESdonnées telles quelles.

Par exemple, un utilisateur peut télécharger un fichier PNG valide avec du code PHP incorporé comme "foo.php". Si le script est particulièrement naïf, il peut en fait copier le fichier sous "/uploads/foo.php". Si le serveur est configuré pour permettre l'exécution de scripts dans les répertoires de téléchargement des utilisateurs (souvent le cas et une terrible erreur), alors vous pouvez instantanément exécuter n'importe quel code PHP arbitraire. (Même si l'image est enregistrée au format .png, il pourrait être possible d'exécuter le code via d'autres failles de sécurité.)

Une liste (non exhaustive) de choses à vérifier lors des téléchargements:

• Assurez-vous d'analyser le contenu pour vous assurer que le téléchargement est du type qu'il prétend être
• Enregistrez le fichier avec une extension de fichier connue et sûre qui ne sera jamais exécutée
• Assurez-vous que PHP (et toute autre exécution de code) est désactivé dans les répertoires de téléchargement des utilisateurs

Ajoutons pcntl_signalet pcntl_alarmà la liste.

Avec l'aide de ces fonctions, vous pouvez contourner toute restriction set_time_limit créée dans le php.ini ou dans le script.

Ce script, par exemple, fonctionnera pendant 10 secondes malgré set_time_limit(1);

(Le mérite revient au tweet et à l' essentiel de Sebastian Bergmann :

<?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";
}

Il existe de nombreux exploits PHP qui peuvent être désactivés par les paramètres du fichier PHP.ini. Un exemple évident est register_globals, mais selon les paramètres, il peut également être possible d'inclure ou d'ouvrir des fichiers à partir de machines distantes via HTTP, ce qui peut être exploité si un programme utilise des noms de fichiers variables pour l'une de ses fonctions include () ou de gestion de fichiers.

PHP permet également d'appeler des fonctions variables en ajoutant () à la fin d'un nom de variable - par exemple, $myvariable();il appellera le nom de fonction spécifié par la variable. C'est exploitable; Par exemple, si un attaquant peut obtenir que la variable contienne le mot «eval» et contrôler le paramètre, alors il peut faire tout ce qu'il veut, même si le programme ne contient pas réellement la fonction eval ().

Ces fonctions peuvent également avoir des effets désagréables.

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

Les deux premiers peuvent épuiser toute la mémoire disponible et les derniers continuent d'épuiser ...

Il y a eu quelques discussions à ce sujet sur security.stackexchange.com récemment

fonctions pouvant être utilisées pour l'exécution de code arbitraire

Eh bien, cela réduit un peu la portée - mais comme 'print' peut être utilisé pour injecter du javascript (et donc voler des sessions, etc.), c'est toujours quelque peu arbitraire.

ne consiste pas à répertorier les fonctions qui devraient être mises sur liste noire ou autrement interdites. Plutôt, j'aimerais avoir une liste grep-able

C'est une approche sensée.

Envisagez cependant d'écrire votre propre analyseur - très bientôt, vous allez trouver une approche basée sur grep hors de contrôle (awk serait un peu mieux). Très bientôt, vous allez également commencer à souhaiter que vous ayez également mis en place une liste blanche!

En plus des plus évidents, je recommanderais de signaler tout ce qui fait une inclusion avec un argument autre qu'un littéral de chaîne. Faites également attention à __autoload ().

Je crains que ma réponse soit un peu trop négative, mais ...

À mon humble avis, toutes les fonctions et méthodes peuvent être utilisées à des fins néfastes. Considérez-le comme un effet d'entraînement de la néfaste: une variable est affectée à un utilisateur ou à une entrée distante, la variable est utilisée dans une fonction, la valeur de retour de fonction utilisée dans une propriété de classe, la propriété de classe utilisée dans une fonction de fichier, et ainsi de suite. Rappelez-vous: une adresse IP falsifiée ou une attaque d'homme au milieu peut exploiter l'ensemble de votre site Web.

Votre meilleur pari est de trace du début à la fin tout utilisateur possible ou entrée à distance, en commençant par $_SERVER, $_GET, $_POST, $_FILE, $_COOKIE, include(some remote file)( si allow_url_fopen est), toutes les autres fonctions / classes traitant des fichiers distants, etc. Vous construisez un profil programatically stack-trace de chaque valeur fournie par l'utilisateur ou à distance. Cela peut être fait par programme en obtenant toutes les instances répétées de la variable et des fonctions ou méthodes affectées dans lesquelles il est utilisé, puis en compilant récursivement une liste de toutes les occurrences de ces fonctions / méthodes, etc. Examinez-le pour vous assurer qu'il passe d'abord par les fonctions de filtrage et de validation appropriées par rapport à toutes les autres fonctions qu'il touche. Ceci est bien sûr un examen manuel, sinon vous aurez un nombre total decase commutateurs égal au nombre de fonctions et de méthodes en PHP (y compris défini par l'utilisateur).

Alternativement, pour gérer uniquement les entrées utilisateur, ayez une classe de contrôleur statique initialisée au début de tous les scripts qui 1) valide et stocke toutes les valeurs d'entrée fournies par l'utilisateur par rapport à une liste blanche des fins autorisées; 2) efface cette source d'entrée (ie $_SERVER = null). Vous pouvez voir où cela devient un peu naziesque.

Voici une liste des fonctions que mon fournisseur désactive pour des raisons de sécurité:

• exec
• dl
• show_source
• apache_note
• apache_setenv
• closelog
• debugger_off
• debugger_on
• define_syslog_variables
• échappehellarg
• Escapeshellcmd
• ini_restore
• openlog
• passer à travers
• pclose
• pcntl_exec
• popen
• proc_close
• proc_get_status
• proc_nice
• proc_open
• proc_terminate
• shell_exec
• syslog
• système
• url_exec

La plupart des attaques dans le code utilisent plusieurs sources d'accès ou plusieurs étapes pour s'exécuter. Je rechercherais non seulement un code, ou une méthode contenant du code malveillant, mais toutes les méthodes, fonctions qui l'exécutent ou l'appellent. La meilleure sécurité comprendrait également l'encodage et la validation des données du formulaire à mesure qu'elles entrent et sortent.

Méfiez-vous également de la définition des variables système, elles peuvent ensuite être appelées à partir de n'importe quelle fonction ou méthode du code.

Plusieurs dépassements de tampon ont été découverts à l'aide de fonctions de caractères 4 bits qui interprètent le texte. htmlentities () htmlspecialchars ()

étaient au sommet, une bonne défense consiste à utiliser mb_convert_encoding () pour convertir en codage unique avant l'interprétation.

Vous pouvez trouver une liste constamment mise à jour des récepteurs sensibles (fonctions php exploitables) et de leurs paramètres dans RIPS /config/sinks.php, un analyseur de code source statique pour les vulnérabilités des applications PHP qui détecte également les backdoors PHP.