Fonctions PHP exploitables

j'essaye de construire une liste de fonctions qui peuvent être utilisées pour l'exécution de code arbitraire. Le but n'est pas d'énumérer les fonctions qui devraient être mises sur liste noire ou autrement rejetées. J'aimerais plutôt avoir une liste de mots-clés grep de " Red-flag à 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 construire un script PHP malveillant Multi-usage -- comme un script "Web shell" comme c99 ou r57-vous allez avoir à utiliser un ou plus d'un petit ensemble de fonctions quelque part dans le fichier afin de permettre à l'utilisateur d'exécuter du code arbitraire. La recherche de ces fonctions vous aide à réduire 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.

en cherchant sur un site compromis l'autre jour, je n'ai pas remarqué un morceau de code malveillant car je ne savais pas que preg_replace pouvait être rendu dangereux par l'utilisation du drapeau /e ( qui, sérieusement? Pourquoi y a-t-il ?). Existe-il des autres que j'ai raté?

Voici ma liste:

Shell Execute

  • system
  • exec
  • popen
  • backtick operator
  • pcntl_exec

PHP Execute

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

il pourrait également être utile d'avoir une liste de fonctions qui sont 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 de modifier ou d'exporter des fichiers, post et je vais l'inclure ici. (Et je compte pas mysql_execute , puisque c'est une partie d'une autre classe d'exploiter.)

277
demandé sur tylerl 2010-06-25 08:34:35
la source

23 ответов

pour établir cette liste, j'ai utilisé 2 sources. A Study In Scarlet and RATS . J'ai aussi ajouté un peu de mon propre à la composition et les gens sur ce fil ont aidé.

Edit: après avoir posté cette liste j'ai contacté le fondateur de RIPS et à partir de Maintenant cet outil recherche le code PHP pour l'utilisation de chaque fonction dans cette liste.

la plupart des ces appels de fonctions sont classés comme des éviers. Lorsqu'une variable viciée (comme $_REQUEST) est passée à une fonction sink, alors vous avez une vulnérabilité. Des programmes comme RATS et RIPS utilisent la fonctionnalité grep comme pour identifier tous les éviers dans une application. Cela signifie que les programmeurs doivent prendre des précautions supplémentaires lors de l'utilisation de ces fonctions, mais s'ils sont tous bannis, alors vous ne seriez pas en mesure d'obtenir beaucoup fait.

avec un grand pouvoir vient une grande responsabilité.

-- Stan Lee

Exécution De La 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 eval il y a d'autres façons d'exécuter le code PHP: include / require peut être utilisé pour l'exécution de code à distance sous la forme de fichier local incluant et Le fichier distant inclut des vulnérabilités .

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 qui acceptent les rappels

ces fonctions acceptent un paramètre string qui peut être utilisé pour appeler une fonction du choix de l'attaquant. Selon la fonction, l'attaquant peut ou non avoir la capacité de passer un paramètre. Dans ce cas, une fonction Information Disclosure 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,

de l'Information La divulgation

la plupart de ces appels de fonction ne sont pas des éviers. Mais c'est peut-être une vulnérabilité si l'une des données retournées est visible pour un attaquant. Si un attaquant peut voir phpinfo() il 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

autres

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 tous fonctions du système de fichiers en php sont méchants. Certains de ces ne semblent pas très utiles à l'attaquant. D'autres sont plus utile que vous ne le pensez. Par exemple si allow_url_fopen=On alors une url peut être utilisée comme chemin de fichier, donc un appel à copy($_GET['s'], $_GET['d']); peut être utilisé pour télécharger un script PHP n'importe où sur le système. En outre, si un site est vulnérable à une requête envoyer via GET chacune de ces fonctions du système de fichiers peut être abusé pour canaliser et attaquer à un autre hôte par le biais de 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
205
répondu Rook 2012-03-22 08:12:07
la source

vous devez rechercher include($tmp) et require(HTTP_REFERER) ainsi que *_once. Si un script d'exploitation peut écrire dans un fichier temporaire, il peut juste inclure cela plus tard. Essentiellement une évaluation en deux étapes.

et il est même possible de cacher le code à distance avec des solutions du genre:

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

en outre, si votre serveur web a déjà été compromis, vous ne verrez pas toujours le mal sans encombre. Souvent, le shell d'exploit est encodé par gzip. Pensez include("zlib:script2.png.gz"); No eval ici, toujours le même effet.

59
répondu mario 2010-06-25 21:24:25
la source

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 d'obfuscation.

48
répondu Aillyn 2010-09-17 16:11:46
la source

je suis surpris que personne n'ait mentionné echo et print comme points d'exploitation de la sécurité.

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

20
répondu Bill Karwin 2010-09-27 21:01:25
la source

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

pour d'autres informations sur les fonctions de dodgy php/l'utilisation regarder autour du Hardened PHP Project et de ses avis. Aussi le récent mois de la sécurité PHP et 2007 mois des bogues PHP projets

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

19
répondu Cheekysoft 2010-06-28 17:13:14
la source

mon VPS est réglé pour désactiver les fonctions suivantes:

[email protected] [~]# 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 assez de fonctions potentiellement destructibles pour que votre liste soit trop grande à grep. Par exemple, PHP a chmod et chown, qui pourrait être utilisé pour simplement désactiver un site web.

EDIT: peut-être voulez-vous construire un script bash qui recherche un fichier pour un ensemble de fonctions regroupées par danger (fonctions qui sont mauvaises, fonctions qui sont pires, fonctions qui ne devrait jamais être utilisé), puis de calculer la relativité du danger que le fichier impose en pourcentage. Ensuite, afficher ceci dans un arbre du répertoire avec les pourcentages marqués à côté de chaque fichier, si plus grand qu'un seuil de par exemple, 30% de danger.

17
répondu Josh 2010-06-25 21:10:00
la source

soyez également conscient de la classe de" vulnérabilités d'interruption " qui permettent de lire et d'écrire des emplacements de mémoire arbitraires!

ils 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, en raison de la fonction pass-by-reference de la langue qui est dépréciée depuis 10 ans mais non désactivée.

pour plus d'informations, voir l'exposé de Stefan Esser sur les vulnérabilités d'interruption et autres problèmes de PHP de niveau inférieur à BlackHat USA 2009 Slides Paper

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

15
répondu Cheekysoft 2010-08-11 13:06:37
la source

vecteurs spécifiques à la plateforme, mais aussi vecteurs théoriques:

  • dotnet_load ()
  • new COM ("WScript.Shell")
  • Java("java.lang.Runtime")
  • event_new() - finalement

et il y a beaucoup plus de méthodes de déguisement:

  • proc_open est un alias pour popen
  • call_user_func_array ("exE".chr(99), array("/usr/bin/dommage", "tout"));
  • file_put_contents ("/cgi-bin / nextinvocation.cgi") & chmod(...)
  • PharData::setDefaultStub - un peu plus de travail pour examiner le code de .fichiers phar
  • runkit_function_rename("exec", "innocent_name") ou de la DGPA rename_function
14
répondu mario 2010-06-25 20:40:52
la source

en dehors de la construction de langue eval il y a une autre fonction qui permet l'exécution de code arbitraire: assert

assert('ex' . 'ec("kill --bill")');
13
répondu NikiC 2010-09-17 21:04:24
la source

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

cela permet des situations où (mal mis en œuvre) le contrôle de bon sens en PHP peut être dupé, 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 appelant script.php?file=somefile%00.php

donc toute fonction qui n'obéit pas à la longueur de la chaîne de caractères de PHP peut conduire à une certaine vulnérabilité.

10
répondu mvds 2011-03-26 15:41:33
la source

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

la" variable variable " ( $$var ) trouvera une variable dans la portée actuelle par le nom de $var. S'il est mal utilisé, l'utilisateur distant peut modifier ou lire n'importe quelle variable de la portée actuelle. Fondamentalement un plus faible eval .

Ex: vous écrivez un code $$uservar = 1; , puis l'utilisateur distant met $uservar à "admin", faisant que $admin soit mis à 1 dans le champ d'application actuel.

9
la source

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

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

  • il pourrait encore y avoir un code mal" 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 aussi à ce

  • mais alors vous aurez ce mayn "peut-être mauvais code" qui est en outre hors de son contexte

  • donc pour être (pseudo-)sûr, vous devriez vraiment écrire le bon code et lire tous les codes existants vous-même

6
répondu Andreas Linden 2010-09-23 23:52:23
la source

Backtick Opérateur Backtick sur le manuel php

5
répondu opHASnoNAME 2010-06-25 08:38:34
la source

je sais move_uploaded_file a été évoquée, mais le téléchargement de fichiers, en général, est très dangereux. La présence de $_FILES devrait soulever quelques inquiétudes.

il est tout à fait possible d'intégrer du code PHP dans n'importe quel type de fichier. Les Images peuvent être particulièrement vulnérables avec les commentaires de texte. Le problème est particulièrement gênant si le code accepte l'extension trouvée dans les données $_FILES telles quelles.

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

(non-exhaustive) liste de choses à vérifier sur uploads:

  • assurez-vous d'analyser le contenu pour vous assurer que le téléchargement est le type qu'il prétend être
  • Enregistrer le fichier avec l'connu, coffre-fort extension de fichier qui ne sera pas 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 d'utilisateur""
5
répondu Matthew 2010-09-15 12:35:12
la source

ajoutons pcntl_signal et 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 s'exécute par exemple pendant 10 Secondes malgré set_time_limit(1);

(crédit à Sebastian Bergmanns) tweet et 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";
}
5
répondu edorian 2011-03-13 23:31:45
la source

il y a des charges D'exploits PHP qui peuvent être désactivés par des paramètres dans le PHP.fichier 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, qui peut être exploité si un programme utilise des noms de fichiers variables pour l'une de ses fonctions include() ou file handling.

PHP permet également l'appel de fonction variable en ajoutant () à la fin d'un nom de variable -- par exemple $myvariable(); appellera le nom de la fonction spécifiée par la variable. Ceci est exploitable; par exemple si un attaquant peut faire en sorte que la variable contienne le mot "eval", et peut 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 ().

4
répondu Spudley 2010-09-15 12:45:23
la source

Ces fonctions peuvent aussi avoir des effets néfastes.

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

les deux premiers peuvent épuiser toute la mémoire disponible et les derniers maintiennent l'épuisement...

4
répondu Alix Axel 2010-09-19 18:54:40
la source

il y a eu une discussion à ce sujet sur security.stackexchange.com recently

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

bien cela réduit un peu la portée - mais puisque 'print' peut être utilisé pour injecter javascript (et donc voler des sessions etc) Son encore quelque peu arbitraire.

n'est pas d'énumérer les fonctions qui devraient être mis sur liste noire ou autrement refusé. Plutôt, je voudrais avoir une liste grep-able

c'est une approche sensée.

ne envisager d'écrire votre propre analyseur si - très bientôt, vous allez trouver une approche basée grep hors de contrôle (awk serait un peu mieux). Très bientôt, vous allez également commencer à souhaiter que vous aviez mis en œuvre une liste blanche trop!

en plus de ceux qui sont évidents, je recommande de signaler tout ce qui fait un include avec un argument autre qu'une chaîne de caractères littérale. Surveillez __autoload ().

2
répondu symcbean 2017-03-17 13:45:55
la source

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

IMHO, chaque fonction et méthode là-bas peuvent être utilisés à des fins néfastes. Pensez - y comme un effet de ruissellement de la négativité: une variable est assigné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 fausse adresse IP ou un homme-dans-l'attaque du milieu peut exploiter l'intégralité de votre site.

votre meilleur pari est de tracer du début à la fin toute entrée possible utilisateur ou à distance, en commençant par $_SERVER , $_GET , $_POST , $_FILE , $_COOKIE , include(some remote file) ( if allow_url_fopen is on), all other functions/classes dealing with remote files, etc. Vous construisez programmatiquement un profil stack-trace de chaque valeur fournie par l'utilisateur ou à distance. Cela peut être fait programmatically en obtenant tout répétez les instances de la variable assignée et les fonctions ou les méthodes dans lesquelles elle est utilisée, puis compilant récursivement une liste de toutes les occurrences de ces fonctions/méthodes, et ainsi de suite. 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. Il s'agit bien sûr d'un examen manuel, sinon vous aurez un nombre total de commutateurs case égal au nombre de fonctions et de méthodes en PHP (y compris défini par l'utilisateur).

alternativement pour la manipulation seulement l'entrée de l'Utilisateur, avoir une classe de contrôleur statique initialisée au début de tous scripts qui 1) valide et stocke toutes les valeurs d'entrée fournies par l'utilisateur par rapport à une liste blanche des buts autorisés; 2) essuie que source d'entrée (ie $_SERVER = null ). Vous pouvez voir d'où vient ce petit Nazi.

2
répondu bob-the-destroyer 2011-03-27 10:11:25
la source

Voici une liste des fonctions que mon fournisseur désactive à des fins de sécurité:

  • exec
  • dl
  • les fonctions show_source
  • apache_note
  • apache_setenv
  • closelog
  • debugger_off
  • debugger_on
  • define_syslog_variables
  • escapeshellarg
  • escapeshellcmd
  • ini_restore
  • openlog
  • passthru
  • pclose
  • pcntl_exec
  • popen
  • proc_close
  • proc_get_status
  • proc_nice
  • proc_open
  • proc_terminate
  • shell_exec
  • syslog
  • système
  • url_exec
1
répondu Vladislav Rastrusny 2011-03-29 12:32:20
la source

la plupart des attaques dans le code utilisent plusieurs sources d'accès, ou plusieurs étapes pour s'exécuter. Je chercherais non seulement un code, ou une méthode ayant du code malveillant, mais toutes les méthodes, fonction l'exécutant ou l'appelant. La meilleure sécurité comprendrait également l'encodage et la validation des données de formulaire, il va et vient.

méfiez-vous aussi de définir des variables de système, elles peuvent ensuite être appelées à partir de n'importe quelle fonction ou méthode dans le code.

1
répondu Cninroh 2011-03-29 14:32:34
la source

plusieurs dépassements de tampon ont été découverts en utilisant 4bit les fonctions de caractères qui interprètent le texte. htmlentités() htmlspecialchars ()

étaient au sommet, une bonne défense est d'utiliser mb_convert_encoding() pour convertir unique encodage avant interprétation.

0
répondu ehime 2011-04-29 02:43:47
la source

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

0
répondu Reiners 2012-01-01 21:21:31
la source

Autres questions sur php security grep