Funzioni PHP sfruttabili

Sto cercando di creare un elenco di funzioni che possono essere utilizzate per l'esecuzione di codice arbitrario. Lo scopo non è elencare le funzioni che dovrebbero essere nella lista nera o altrimenti vietate. Piuttosto, vorrei avere a grepportata di mano un elenco di parole chiave con bandiera rossa quando si cercano back-door in un server compromesso.

L'idea è che se vuoi creare uno script PHP dannoso multiuso - come uno script "web shell" come c99 o r57 - dovrai usare una o più di una serie relativamente piccola di funzioni da qualche parte nel file per consentire all'utente di eseguire codice arbitrario. La ricerca di queste funzioni ti aiuta a restringere più rapidamente un pagliaio di decine di migliaia di file PHP in un set relativamente piccolo di script che richiedono un esame più attento.

Chiaramente, per esempio, uno qualsiasi dei seguenti sarebbe considerato dannoso (o codifica terribile):

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

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

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

e così via.

Cercando su un sito Web compromesso l'altro giorno, non ho notato un pezzo di codice dannoso perché non mi rendevo conto che preg_replacepotesse essere reso pericoloso dall'uso della /ebandiera ( che, sul serio? Perché è anche lì ?). Ce ne sono altri che mi sono perso?

Ecco la mia lista finora:

Shell Execute

• system
• exec
• popen
• backtick operator
• pcntl_exec

PHP Execute

• eval
• preg_replace(con /emodificatore)
• create_function
• include[ _once] / require[ _once] ( vedi la risposta di mario per i dettagli sugli exploit)

Potrebbe anche essere utile avere un elenco di funzioni in grado di modificare i file, ma immagino che il 99% delle volte il codice exploit conterrà almeno una delle funzioni sopra. Ma se hai un elenco di tutte le funzioni in grado di modificare o produrre file, pubblicalo e lo includerò qui. (E non sto contando mysql_execute, dal momento che fa parte di un'altra classe di exploit.)

Per creare questo elenco ho usato 2 fonti. Uno studio in rosso e RATS . Ho anche aggiunto alcuni dei miei al mix e le persone su questo thread mi hanno aiutato.

Modifica: dopo aver pubblicato questo elenco ho contattato il fondatore di RIPS e sin da ora questo strumento cerca nel codice PHP l'uso di tutte le funzioni in questo elenco.

La maggior parte di queste chiamate di funzione sono classificate come lavandini. Quando una variabile contaminata (come $ _REQUEST) viene passata a una funzione sink, si ha una vulnerabilità. Programmi come RATS e RIPS utilizzano la funzionalità grep like per identificare tutti i sink in un'applicazione. Ciò significa che i programmatori dovrebbero prestare particolare attenzione quando utilizzano queste funzioni, ma se fossero tutti vietati, non si sarebbe in grado di fare molto.

" Da un grande potere derivano grandi responsabilità " .

- Stan Lee

Esecuzione del comando

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

Esecuzione del codice PHP

A parte evalci sono altri modi per eseguire il codice PHP: include/ requirepuò essere utilizzato per l'esecuzione di codice in modalità remota sotto forma di vulnerabilità di inclusione di file locale e inclusione di file remoto .

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

Elenco di funzioni che accettano i callback

Queste funzioni accettano un parametro stringa che potrebbe essere utilizzato per chiamare una funzione a scelta dell'attaccante. A seconda della funzione l'attaccante può o meno avere la capacità di passare un parametro. In tal caso Information Disclosure, è phpinfo()possibile utilizzare una funzione simile .

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,

Rivelazione di un 'informazione

La maggior parte di queste chiamate di funzione non sono sink. Ma piuttosto potrebbe essere una vulnerabilità se uno dei dati restituiti è visualizzabile da un utente malintenzionato. Se un attaccante può vedere phpinfo()che è sicuramente una vulnerabilità.

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

Altro

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

Funzioni del filesystem

Secondo RATS tutte le funzioni del filesystem in php sono cattive. Alcuni di questi non sembrano molto utili all'attaccante. Altri sono più utili di quanto si possa pensare. Ad esempio, se allow_url_fopen=Onun URL può essere utilizzato come percorso di file, è copy($_GET['s'], $_GET['d']);possibile utilizzare una chiamata per caricare uno script PHP in qualsiasi punto del sistema. Inoltre, se un sito è vulnerabile a una richiesta di invio tramite GET, è possibile abusare di tutte queste funzioni del file system per incanalare e attaccare un altro host attraverso il proprio 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

Dovresti cercare include ($ tmp) e richiedere (HTTP_REFERER) e * _once. Se uno script di exploit può scrivere su un file temporaneo, potrebbe includerlo in un secondo momento. Fondamentalmente una valutazione in due fasi.

Ed è anche possibile nascondere il codice remoto con soluzioni alternative come:

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

Inoltre, se il tuo server web è già stato compromesso, non vedrai sempre il male non codificato. Spesso la shell exploit è codificata con gzip. Pensa a include("zlib:script2.png.gz");No eval qui, sempre allo stesso effetto.

Questa non è una risposta in sé, ma ecco qualcosa di interessante:

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

Con lo stesso spirito, call_user_func_array()può essere utilizzato per eseguire funzioni offuscate.

Sono sorpreso che nessuno abbia menzionato echoe printcome punti di sfruttamento della sicurezza.

Cross-Site Scripting (XSS) è un grave exploit di sicurezza, perché è ancora più comune degli exploit di esecuzione di codice sul lato server.

in particolare vorrei aggiungere unserialize () a questo elenco. Ha una lunga storia di varie vulnerabilità tra cui l'esecuzione di codice arbitrario, denial of service e perdita di informazioni sulla memoria. Non dovrebbe mai essere chiamato su dati forniti dall'utente. Molti di questi vuls sono stati corretti nelle versioni negli ultimi anni di rugiada, ma conserva ancora un paio di cattivi vuls al momento attuale della scrittura.

Per ulteriori informazioni sulle funzioni / sull'utilizzo di php non ottimali, consultare il progetto PHP temprato e le relative consulenze. Anche la recente mese di PHP Security e il 2007 del mese di bug PHP progetti

Si noti inoltre che, in base alla progettazione, la mancata serializzazione di un oggetto comporterà l'esecuzione delle funzioni di costruzione e distruzione; un altro motivo per non chiamarlo sui dati forniti dall'utente.

Il mio VPS è impostato per disabilitare le seguenti funzioni:

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 ha abbastanza funzioni potenzialmente distruttibili per cui la tua lista potrebbe essere troppo grande per essere approvata. Ad esempio, PHP ha chmod e chown, che potrebbero essere usati per disattivare semplicemente un sito web.

EDIT: Forse potresti voler creare uno script bash che cerchi un file per una serie di funzioni raggruppate per pericolo (funzioni che sono cattive, funzioni che sono peggio, funzioni che non dovrebbero mai essere usate), e quindi calcolare la relatività del pericolo che il file impone in percentuale. Quindi output questo su un albero della directory con le percentuali contrassegnate accanto a ciascun file, se maggiore di una soglia di dire, pericolo del 30%.

Siate anche consapevoli della classe di "vulnerabilità di interruzione" che consentono di leggere e scrivere posizioni di memoria arbitrarie!

Queste influiscono su funzioni come trim (), rtrim (), ltrim (), explode (), strchr (), strstr (), substr (), chunk_split (), strtok (), addcslashes (), str_repeat () e altro . Ciò è in gran parte, ma non esclusivamente, dovuto alla funzione pass-by-reference della lingua della chiamata che è stata deprecata per 10 anni ma non disabilitata.

Per maggiori informazioni, vedi il discorso di Stefan Esser sulle vulnerabilità di interruzione e altri problemi di PHP di livello inferiore al BlackHat USA 2009 Slides Paper

Questo documento / presentazione mostra anche come dl () può essere utilizzato per eseguire codice di sistema arbitrario.

Vettori esecutivi specifici per la piattaforma, ma anche teorici:

• dotnet_load ()
• nuovo COM ("WScript.Shell")
• nuovo Java ("java.lang.Runtime")
• event_new () - molto alla fine

E ci sono molti altri metodi di mascheramento:

• proc_open è un alias per popen
• call_user_func_array ("exE" .chr (99), array ("/ usr / bin / damage", "--all"));
• file_put_contents ("/ cgi-bin / nextinvocation.cgi") && chmod (...)
• PharData :: setDefaultStub - altro lavoro per esaminare il codice nei file .phar
• runkit_function_rename ("exec", "innocent_name") o APD rename_function

Oltre al evalcostrutto del linguaggio esiste un'altra funzione che consente l'esecuzione di codice arbitrario:assert

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

Una fonte di exploit interessanti non è stata menzionata. PHP consente alle stringhe di contenere 0x00byte. Le funzioni sottostanti (libc) considerano questo come la fine di una stringa.

Ciò consente situazioni in cui il controllo della sanità mentale (mal implementato) in PHP può essere ingannato, ad esempio in una situazione come:

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

Ciò potrebbe includere qualsiasi file, non solo quelli che terminano .php, chiamandoscript.php?file=somefile%00.php

Quindi qualsiasi funzione che non obbedirà alla lunghezza della stringa di PHP può portare a qualche vulnerabilità.

Che dire di pericolosi elementi sintattici?

La " variabile variabile " ( $$var) troverà una variabile nell'ambito corrente con il nome di $ var. Se utilizzato in modo errato, l'utente remoto può modificare o leggere qualsiasi variabile nell'ambito corrente. Fondamentalmente un debole eval.

Es: si scrive un po 'di codice $$uservar = 1;, quindi l'utente remoto imposta $uservarsu "admin", causando $admindi essere impostato 1nell'ambito corrente.

Immagino che non sarai in grado di trovare davvero tutti gli exploit possibili analizzando i tuoi file sorgente.

• anche se ci sono elenchi davvero fantastici forniti qui, puoi perdere una funzione che può essere sfruttata

• potrebbe esserci ancora un codice malvagio "nascosto" come questo

$ myEvilRegex = base64_decode ('Ly4qL2U =');

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

• ora potresti dire che estendo semplicemente il mio copione per adattarlo anche a questo

• ma poi avrai quel "codice malefico" che forse non è nel suo contesto

• quindi per essere (pseudo-) sicuro, dovresti davvero scrivere un buon codice e leggere tu stesso tutto il codice esistente

Backtick Operator Backtick sul manuale php

So che move_uploaded_fileè stato menzionato, ma il caricamento di file in generale è molto pericoloso. Solo la presenza di $_FILESdovrebbe sollevare qualche preoccupazione.

È del tutto possibile incorporare il codice PHP in qualsiasi tipo di file. Le immagini possono essere particolarmente vulnerabili con commenti di testo. Il problema è particolarmente problematico se il codice accetta l'estensione trovata all'interno dei $_FILESdati così com'è.

Ad esempio, un utente può caricare un file PNG valido con codice PHP incorporato come "foo.php". Se lo script è particolarmente ingenuo, potrebbe effettivamente copiare il file come "/uploads/foo.php". Se il server è configurato per consentire l'esecuzione di script nelle directory di caricamento degli utenti (spesso il caso e una terribile supervisione), puoi immediatamente eseguire qualsiasi codice PHP arbitrario. (Anche se l'immagine viene salvata come .png, potrebbe essere possibile ottenere il codice da eseguire tramite altri difetti di sicurezza.)

Un elenco (non esaustivo) di cose da controllare sui caricamenti:

• Assicurati di analizzare i contenuti per assicurarti che il caricamento sia del tipo che afferma di essere
• Salvare il file con un'estensione di file sicura e nota che non verrà mai eseguita
• Assicurati che PHP (e qualsiasi altra esecuzione di codice) sia disabilitato nelle directory di caricamento degli utenti

Aggiungiamo pcntl_signale pcntl_alarmalla lista.

Con l'aiuto di queste funzioni puoi aggirare qualsiasi restrizione set_time_limit creata nel php.ini o nello script.

Questo script, ad esempio, verrà eseguito per 10 secondi nonostante set_time_limit(1);

(Il merito va al tweet e alla sintesi di 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";
}

Ci sono un sacco di exploit PHP che possono essere disabilitati dalle impostazioni nel file PHP.ini. Un esempio evidente è register_globals, ma a seconda delle impostazioni potrebbe anche essere possibile includere o aprire file da macchine remote tramite HTTP, che possono essere sfruttati se un programma utilizza nomi di file variabili per una delle sue funzioni include () o di gestione dei file.

PHP consente anche la chiamata di funzioni variabili aggiungendo () alla fine di un nome di variabile, ad esempio $myvariable();chiamerà il nome della funzione specificato dalla variabile. Questo è sfruttabile; ad esempio, se un utente malintenzionato può ottenere la variabile per contenere la parola "eval" e può controllare il parametro, allora può fare tutto ciò che vuole, anche se il programma in realtà non contiene la funzione eval ().

Queste funzioni possono anche avere alcuni effetti negativi.

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

I primi due possono esaurire tutta la memoria disponibile e questi ultimi fanno andare avanti l'esaurimento ...

Di recente si è discusso di questo su security.stackexchange.com

funzioni che possono essere utilizzate per l'esecuzione di codice arbitrario

Bene, questo riduce leggermente l'ambito - ma poiché 'print' può essere usato per iniettare javascript (e quindi rubare sessioni, ecc.) È ancora un po 'arbitrario.

non è elencare le funzioni che dovrebbero essere nella lista nera o altrimenti vietate. Piuttosto, mi piacerebbe avere un elenco in grado di supportare

Questo è un approccio sensato.

Prendi in considerazione la possibilità di scrivere il tuo parser - molto presto troverai un approccio basato su grep che sfuggirà al controllo (awk sarebbe un po 'meglio). Molto presto inizierai anche a desiderare di aver implementato anche una whitelist!

Oltre a quelli ovvi, consiglierei di contrassegnare qualsiasi cosa includa un argomento con qualcosa di diverso da una stringa letterale. Fai attenzione anche a __autoload ().

Temo che la mia risposta potrebbe essere un po 'troppo negativa, ma ...

IMHO, ogni singola funzione e metodo là fuori può essere utilizzato per scopi nefasti. Pensalo come un effetto a cascata della nefarietà: una variabile viene assegnata a un utente o a un input remoto, la variabile viene utilizzata in una funzione, il valore di ritorno della funzione utilizzato in una proprietà di classe, la proprietà di classe utilizzata in una funzione di file, e così via. Ricorda: un indirizzo IP contraffatto o un attacco man-in-the-middle può sfruttare l'intero sito web.

La cosa migliore è quella di traccia dall'inizio alla fine ogni possibile utente o ingresso remoto, a partire da $_SERVER, $_GET, $_POST, $_FILE, $_COOKIE, include(some remote file)( se allow_url_fopen è su), tutte le altre funzioni / classi che si occupano di file remoti, ecc Si programatically costruire un profilo di stack-trace di ciascun valore fornito dall'utente o da remoto. Questo può essere fatto in modo programmatico ottenendo tutte le istanze ripetute della variabile assegnata e le funzioni o i metodi in cui è utilizzato, quindi compilando ricorsivamente un elenco di tutte le occorrenze di tali funzioni / metodi e così via. Esaminalo per assicurarti che prima passi attraverso le funzioni di filtraggio e convalida appropriate rispetto a tutte le altre funzioni che tocca. Questo è ovviamente un esame manuale, altrimenti avrai un numero totale dicase switch uguale al numero di funzioni e metodi in PHP (incluso definito dall'utente).

In alternativa per gestire solo l'input dell'utente, avere una classe di controller statica inizializzata all'inizio di tutti gli script che 1) convalida e memorizza tutti i valori di input forniti dall'utente in una lista bianca di scopi consentiti; 2) cancella quella sorgente di input (cioè $_SERVER = null). Puoi vedere dove questo diventa un po 'nazista.

Ecco un elenco di funzioni che il mio provider disabilita per motivi di sicurezza:

• exec
• dl
• show_source
• apache_note
• apache_setenv
• closelog
• debugger_off
• debugger_on
• define_syslog_variables
• escapeshellarg
• escapeshellcmd
• ini_restore
• openlog
• passare attraverso
• pclose
• pcntl_exec
• popen
• proc_close
• proc_get_status
• proc_nice
• proc_open
• proc_terminate
• shell_exec
• syslog
• sistema
• url_exec

La maggior parte degli attacchi nel codice utilizza più origini di accesso o più passaggi per eseguirsi. Vorrei cercare non solo un codice o un metodo con codice dannoso, ma tutti i metodi, le funzioni che lo eseguono o lo chiamano. La migliore sicurezza includerebbe anche la codifica e la convalida dei dati dei moduli man mano che entrano e escono.

Fai attenzione anche alla definizione delle variabili di sistema, che in seguito possono essere richiamate da qualsiasi funzione o metodo nel codice.

Numerosi buffer overflow sono stati scoperti utilizzando funzioni di caratteri a 4 bit che interpretano il testo. htmlentities () htmlspecialchars ()

erano in cima, una buona difesa è usare mb_convert_encoding () per convertire in codifica singola prima dell'interpretazione.

Puoi trovare un elenco continuamente aggiornato di sink sensibili (funzioni php sfruttabili) e dei loro parametri in RIPS /config/sinks.php, un analizzatore di codice sorgente statico per vulnerabilità nelle applicazioni PHP che rileva anche backdoor PHP.