Funções PHP exploráveis

Estou tentando criar uma lista de funções que podem ser usadas para execução arbitrária de código. O objetivo não é listar as funções que devem estar na lista negra ou não permitidas. Em vez disso, eu gostaria de ter uma greplista habilitada de palavras - chave com bandeira vermelha ao procurar um servidor comprometido por back-doors.

A idéia é que, se você deseja criar um script PHP mal-intencionado multiuso - como um script de "shell da web" como c99 ou r57 - precisará usar um ou mais de um conjunto relativamente pequeno de funções em algum lugar do arquivo para permitir que o usuário execute código arbitrário. A busca por essas funções ajuda a reduzir mais rapidamente um palheiro de dezenas de milhares de arquivos PHP para um conjunto relativamente pequeno de scripts que requerem um exame mais detalhado.

Claramente, por exemplo, qualquer um dos seguintes itens seria considerado malicioso (ou terrível de codificação):

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

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

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

e assim por diante.

Pesquisando em um site comprometido no outro dia, não notei um código malicioso porque não sabia que preg_replacepoderia ser perigoso pelo uso da /ebandeira (o que, sério? Por que isso acontece ?). Há outros que eu perdi?

Aqui está minha lista até agora:

Shell Execute

• system
• exec
• popen
• backtick operator
• pcntl_exec

Execução do PHP

• eval
• preg_replace(com /emodificador)
• create_function
• include[ _once] / require[ _once] ( consulte a resposta de mario para obter detalhes da exploração)

Também pode ser útil ter uma lista de funções capazes de modificar arquivos, mas imagino que 99% do código de exploração do tempo conterá pelo menos uma das funções acima. Mas se você tiver uma lista de todas as funções capazes de editar ou gerar arquivos, poste-a e incluirei aqui. (E não estou contando mysql_execute, já que isso faz parte de outra classe de exploração.)

Para construir esta lista, usei 2 fontes. Um estudo sobre Scarlet e RATS . Eu também adicionei alguns dos meus à mistura e as pessoas neste segmento ajudaram.

Edit: Depois de postar esta lista, entrei em contato com o fundador do RIPS e, a partir de agora, essas ferramentas pesquisam o código PHP para o uso de todas as funções nesta lista.

A maioria dessas chamadas de função é classificada como Pias. Quando uma variável contaminada (como $ _REQUEST) é passada para uma função de coletor, você tem uma vulnerabilidade. Programas como RATS e RIPS usam a funcionalidade grep para identificar todos os coletores em um aplicativo. Isso significa que os programadores devem ter cuidado extra ao usar essas funções, mas se elas banirem todas, você não poderá fazer muito.

" Com grande poder vem grande responsabilidade. "

--Stan Lee

Execução de 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

Execução de código PHP

Além de evaloutras maneiras de executar o código PHP: include/ requirepode ser usado para execução remota de código na forma das vulnerabilidades de inclusão local de arquivo e inclusão remota de arquivo .

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 funções que aceitam retornos de chamada

Essas funções aceitam um parâmetro de string que pode ser usado para chamar uma função de escolha do atacante. Dependendo da função, o invasor pode ou não ter a capacidade de passar um parâmetro. Nesse caso, uma Information Disclosurefunção como phpinfo()poderia ser usada.

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,

Divulgação de informação

A maioria dessas chamadas de função não são sumidouros. Mas, talvez, seja uma vulnerabilidade se algum dos dados retornados estiver visível para um invasor. Se um invasor pode ver phpinfo(), é definitivamente uma vulnerabilidade.

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

De outros

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

Funções do sistema de arquivos

De acordo com o RATS, todas as funções do sistema de arquivos no php são desagradáveis. Alguns deles não parecem muito úteis para o atacante. Outros são mais úteis do que você imagina. Por exemplo, se allow_url_fopen=Onum URL pode ser usado como um caminho de arquivo, uma chamada para copy($_GET['s'], $_GET['d']);pode ser usada para carregar um script PHP em qualquer lugar do sistema. Além disso, se um site estiver vulnerável a uma solicitação de envio via GET, todas essas funções do sistema de arquivos podem ser abusadas para canalizar e atacar outro host por meio do 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

Você precisaria procurar por include ($ tmp) e exigir (HTTP_REFERER) e * _once também. Se um script de exploração puder gravar em um arquivo temporário, ele poderá ser incluído posteriormente mais tarde. Basicamente, uma avaliação em duas etapas.

E é ainda possível ocultar o código remoto com soluções alternativas, como:

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

Além disso, se o seu servidor da web já tiver sido comprometido, você nem sempre verá o mal não codificado. Geralmente, o shell de exploração é codificado em gzip. Pense em include("zlib:script2.png.gz");Sem avaliação aqui, ainda o mesmo efeito.

Esta não é uma resposta em si, mas aqui está algo interessante:

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

No mesmo espírito, call_user_func_array()pode ser usado para executar funções ofuscadas.

Estou surpreso que ninguém tenha mencionado echoe printcomo pontos de exploração de segurança.

Script entre sites (XSS) é uma exploração de segurança séria, porque é ainda mais comum que as explorações de execução de código no servidor.

Eu gostaria particularmente de adicionar unserialize () a esta lista. Ele tem um longo histórico de várias vulnerabilidades, incluindo execução arbitrária de códigos, negação de serviço e vazamento de informações de memória. Nunca deve ser chamado em dados fornecidos pelo usuário. Muitos desses vuls foram corrigidos em lançamentos nos últimos anos de orvalho, mas ainda retêm alguns vuls desagradáveis ​​no momento atual da escrita.

Para outras informações sobre funções / uso desonesto do php, consulte o Hardened PHP Project e seus conselhos. Também o recente mês de segurança do PHP e os de 2007 projetos Month of PHP Bugs de

Observe também que, por design, a desserialização de um objeto fará com que as funções construtor e destruidor sejam executadas; outro motivo para não chamar dados fornecidos pelo usuário.

Meu VPS está definido para desativar as seguintes funções:

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

O PHP possui funções potencialmente destrutíveis suficientes para a sua lista ser grande demais para a qual grep. Por exemplo, o PHP possui chmod e chown, que podem ser usados ​​para simplesmente desativar um site.

EDIT: Talvez você queira criar um script bash que procure um arquivo por uma matriz de funções agrupadas por perigo (funções ruins, funções piores, funções que nunca devem ser usadas) e depois calcule a relatividade do perigo que o arquivo impõe em uma porcentagem. Em seguida, imprima isso em uma árvore do diretório com as porcentagens marcadas ao lado de cada arquivo, se maior que um limite de, digamos, 30% de perigo.

Também esteja ciente da classe de "vulnerabilidades de interrupção" que permite que locais arbitrários de memória sejam lidos e gravados!

Isso afeta funções como trim (), rtrim (), ltrim (), explode (), strchr (), strstr (), substr (), chunk_split (), strtok (), addcslashes (), str_repeat () e mais . Isso ocorre em grande parte, mas não exclusivamente, devido ao recurso de passagem por referência do tempo de chamada do idioma que foi descontinuado por 10 anos, mas não desativado.

Para obter mais informações, consulte a palestra de Stefan Esser sobre vulnerabilidades de interrupção e outros problemas de PHP de nível inferior no BlackHat USA 2009 Slides Paper

Este artigo / apresentação também mostra como dl () pode ser usado para executar código arbitrário do sistema.

Vetores exec específicos da plataforma, mas também teóricos:

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

E existem muitos outros métodos de disfarce:

• proc_open é um alias para popen
• call_user_func_array ("exE" .chr (99), matriz ("/ usr / bin / damage", "--all"));
• file_put_contents ("/ cgi-bin / nextinvocation.cgi") && chmod (...)
• PharData :: setDefaultStub - mais trabalho para examinar o código em arquivos .phar
• runkit_function_rename ("exec", "innocent_name") ou APD rename_function

Além da evalconstrução da linguagem, há outra função que permite a execução arbitrária de código:assert

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

Uma fonte de explorações interessantes não foi mencionada. O PHP permite que as strings tenham 0x00bytes. As funções subjacentes (libc) tratam isso como o fim de uma string.

Isso permite situações em que a verificação de sanidade (mal implementada) no PHP pode ser enganada, por exemplo, em uma situação como:

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

Isso pode incluir qualquer arquivo - não apenas aqueles que terminam em .php- chamandoscript.php?file=somefile%00.php

Portanto, qualquer função que não obedeça ao comprimento da string do PHP pode levar a alguma vulnerabilidade.

E quanto aos elementos sintáticos perigosos?

A " variável variável " ( $$var) encontrará uma variável no escopo atual com o nome de $ var. Se usado incorretamente, o usuário remoto pode modificar ou ler qualquer variável no escopo atual. Basicamente, um mais fraco eval.

Ex: você escreve algum código $$uservar = 1;e o usuário remoto define $uservarcomo "admin", fazendo $admincom que seja definido 1no escopo atual.

Acho que você não conseguirá realmente encontrar todas as explorações possíveis analisando seus arquivos de origem.

• Além disso, se houver realmente ótimas listas fornecidas aqui, você poderá perder uma função que pode ser explorada

• ainda pode haver código maligno "oculto" como este

$ myEvilRegex = base64_decode ('Ly4qL2U =');

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

• você poderia dizer agora, eu simplesmente estendo meu script para combinar com isso

• mas você terá esse "código possivelmente maligno" que, além disso, está fora de seu contexto

• de modo a ser (pseudo-) garantir, você deve realmente escrever código bom e ler todos os códigos existentes se

Operador de Backtick Backtick no manual php

Eu sei move_uploaded_fileque foi mencionado, mas o upload de arquivos em geral é muito perigoso. Apenas a presença de $_FILESdeve suscitar alguma preocupação.

É bem possível incorporar código PHP em qualquer tipo de arquivo. As imagens podem ser especialmente vulneráveis ​​aos comentários de texto. O problema é particularmente problemático se o código aceitar a extensão encontrada nos $_FILESdados como está.

Por exemplo, um usuário pode fazer upload de um arquivo PNG válido com código PHP incorporado como "foo.php". Se o script for particularmente ingênuo, ele poderá copiar o arquivo como "/uploads/foo.php". Se o servidor estiver configurado para permitir a execução de scripts nos diretórios de upload do usuário (geralmente o caso e uma supervisão terrível), você poderá executar instantaneamente qualquer código PHP arbitrário. (Mesmo que a imagem seja salva como .png, pode ser possível executar o código por outras falhas de segurança.)

Uma lista (não exaustiva) de itens a serem verificados nos envios:

• Analise o conteúdo para garantir que o upload seja do tipo que afirma ser
• Salve o arquivo com uma extensão de arquivo segura e conhecida que nunca será executada
• Verifique se o PHP (e qualquer outra execução de código) está desativado nos diretórios de upload do usuário

Vamos adicionar pcntl_signale pcntl_alarmà lista.

Com a ajuda dessas funções, você pode contornar qualquer restrição set_time_limit criada no php.ini ou no script.

Este script, por exemplo, será executado por 10 segundos, apesar de set_time_limit(1);

(O crédito vai para o tweet e essência de Sebastian Bergmanns :

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

Existem muitas explorações do PHP que podem ser desabilitadas pelas configurações no arquivo PHP.ini. O exemplo óbvio é register_globals, mas, dependendo das configurações, também pode ser possível incluir ou abrir arquivos de máquinas remotas via HTTP, que podem ser explorados se um programa usar nomes de arquivos variáveis ​​para qualquer uma de suas funções include () ou de manipulação de arquivos.

O PHP também permite a chamada de função variável adicionando () ao final de um nome de variável - por exemplo $myvariable();, chamará o nome da função especificado pela variável. Isso é explorável; por exemplo, se um invasor pode fazer com que a variável contenha a palavra 'eval' e controlar o parâmetro, ele pode fazer o que quiser, mesmo que o programa não contenha a função eval ().

Essas funções também podem ter efeitos desagradáveis.

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

Os dois primeiros podem esgotar toda a memória disponível e os últimos mantêm a exaustão em andamento ...

Houve alguma discussão sobre isso em security.stackexchange.com recentemente

funções que podem ser usadas para execução arbitrária de código

Bem, isso reduz um pouco o escopo - mas como 'print' pode ser usado para injetar javascript (e, portanto, roubar sessões etc.), ainda é um tanto arbitrário.

não é listar as funções que devem estar na lista negra ou não permitidas. Em vez disso, eu gostaria de ter uma lista grep-capaz

Essa é uma abordagem sensata.

No entanto, considere escrever seu próprio analisador - muito em breve você encontrará uma abordagem baseada em grep ficando fora de controle (o awk seria um pouco melhor). Em breve, você começará a desejar também ter implementado uma lista de permissões!

Além dos óbvios, eu recomendaria sinalizar qualquer coisa que inclua com um argumento de qualquer coisa que não seja uma string literal. Cuidado com __autoload () também.

Temo que minha resposta possa ser um pouco negativa demais, mas ...

IMHO, todas as funções e métodos existentes podem ser usados ​​para fins nefastos. Pense nisso como um efeito superficial da nefastidão: uma variável é atribuída a um usuário ou entrada remota, a variável é usada em uma função, o valor de retorno da função usado em uma propriedade de classe, a propriedade de classe usada em uma função de arquivo, e assim por diante. Lembre-se: um endereço IP forjado ou um ataque intermediário pode explorar todo o site.

Sua melhor aposta é a de vestígios do início ao fim qualquer usuário possível ou entrada remota, começando com $_SERVER, $_GET, $_POST, $_FILE, $_COOKIE, include(some remote file)( se interruptores igual ao número de funções e métodos em PHP (incluindo definido pelo usuário).allow_url_fopen estiver ligado), todas as outras funções / classes que lidam com arquivos remotos, etc. Você programaticamente criar um perfil pilha-trace de cada valor fornecido pelo usuário ou remotamente. Isso pode ser feito de forma programática, obtendo todas as instâncias repetidas da variável e funções ou métodos atribuídos em que é usado, compilando recursivamente uma lista de todas as ocorrências dessas funções / métodos e assim por diante. Examine-o para garantir que ele passe primeiro pelas funções de filtragem e validação adequadas em relação a todas as outras funções que toca. É claro que este é um exame manual; caso contrário, você terá um número total decase

Como alternativa, para lidar apenas com a entrada do usuário, tenha uma classe de controlador estático inicializada no início de todos os scripts que 1) valide e armazene todos os valores de entrada fornecidos pelo usuário em uma lista branca de propósitos permitidos; 2) limpa a fonte de entrada (ou seja $_SERVER = null). Você pode ver onde isso fica um pouco nazista.

Aqui está uma lista de funções que meu provedor desabilita por motivos de segurança:

• exec
• dl
• show_source
• apache_note
• apache_setenv
• Closelog
• debugger_off
• debugger_on
• define_syslog_variables
• escapeshellarg
• escapeshellcmd
• ini_restore
• openlog
• passar através
• fechar
• pcntl_exec
• popen
• proc_close
• proc_get_status
• proc_nice
• proc_open
• proc_terminate
• shell_exec
• syslog
• sistema
• url_exec

A maioria dos ataques no código usa várias fontes de acesso ou várias etapas para se executar. Eu pesquisaria não apenas um código ou método com código malicioso, mas todos os métodos, que funcionam executando ou chamando-o. A melhor segurança também incluiria a codificação e validação dos dados do formulário à medida que eles entram e saem.

Cuidado também ao definir as variáveis ​​do sistema, elas podem ser chamadas posteriormente a partir de qualquer função ou método no código.

Vários estouros de buffer foram descobertos usando funções de caracteres de 4 bits que interpretam o texto. htmlentities () htmlspecialchars ()

No topo, uma boa defesa é usar mb_convert_encoding () para converter em codificação única antes da interpretação.

Você pode encontrar uma lista atualizada continuamente de sumidouros sensíveis (funções php exploráveis) e seus parâmetros em RIPS /config/sinks.php, um analisador de código fonte estático para vulnerabilidades em aplicativos PHP que também detectam backdoors PHP.