Funções PHP exploráveis

277

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.)

tylerl
fonte
43
Como nota, eu gostaria de ver que a lista publicada no futuro próximo, se possível :)
Yoda
16
@yoda: publicado onde? Manterei a lista atualizada aqui, pois SO é a fonte de todo conhecimento.
tylerl
3
O que o /emodificador faz?
Billy ONeal
6
@ Billy: o emodificador faz com que a string de substituição seja avaliada como código PHP.
Nikc.org
1
É preciso dizer: executar o código no regex é algo que Perl e possivelmente Python também, não algo exclusivo do PHP. Eu não sei os detalhes, no entanto.
Adriano Varoli Piazza

Respostas:

205

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
torre
fonte
37
@whatnick Na verdade, não vejo uma diferença significativa entre o PHP e outras linguagens de aplicativos da web. No final do dia, os programadores precisam eval()codificar, executar comandos do sistema, acessar um banco de dados e ler / gravar em arquivos. Esse código pode ser influenciado por um invasor, e isso é uma vulnerabilidade.
rook
8
Tantas funções banidas! Você é o anfitrião do meu site por acaso?
Randy the Dev
2
@ Andrew Dunn haha, não. Se você baniu todas essas funções, nenhum aplicativo PHP funcionaria. Especialmente include (), require () e as funções do sistema de arquivos.
rook
2
@ Torre: meus pensamentos exatamente, mas estes são para problemas em potencial, não definitivos. Se usado corretamente, nenhum deles representa uma ameaça imediata; mas se eles podem ser evitados, deveriam ser.
Geekster
3
Imho preg_matchcom enão é mal. O manual diz "Apenas preg_replace () usa esse modificador; é ignorado por outras funções do PCRE".
NikiC 05/11
59

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.

mario
fonte
1
Dependendo de como o PHP estiver configurado, o include pode incluir código de URLs arbitrárias. Algo como incluir " example.com/code.phps "; Eu vi um site comprometido que foi quebrado usando uma combinação desse recurso e register_globals.
BlackAura
@BlackAura como o regiser_globals se encaixou no ataque? É algo que poderia ter sido realizado com a mesma facilidade usando $_GET[xyz]ao invés de $xyz? Ou havia algo mais profundo nisso?
tylerl
Não sei ao certo por que isso foi feito dessa maneira, mas o site continuou fazendo coisas assim: include ($ prefix. '/Filename.php'); Acho que a ideia era que você pudesse mover o código principal para fora da raiz da web, definindo a variável $ prefix no arquivo de configuração. Se o invasor definir esse valor para algo como " example.com/code.phps ?", O PHP incluirá esse arquivo remoto. Quase como eu posso dizer, um 'bot realmente conseguiu invadir usando uma exploração genérica. Aparentemente, muitos códigos PHP antigos cometeram esse erro. Basicamente, NUNCA deixe nenhum valor enviado pelo usuário nem perto de uma instrução de inclusão.
BlackAura
Eu acho que você pode generalizar isso para as inclusões que contêm um ":" no nome do arquivo ... exceto que o nome do arquivo pode ser uma variável, dificultando o grepuso. PHP - que desastre.
tylerl
2
includenão requer parênteses; include "…"é suficiente.
Gumbo
48

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.

Aillyn
fonte
1
E não há como encontrá-lo sem executar o código :( A análise estática não ajudará aqui.
NikiC
15
@tylerl: ... ou qualquer outro idioma?
dr Hannibal Lecter
@dr Hannibal Lector: mesmo idiomas compilados?
Ponkadoodle 30/10/10
3
@ Wallacoloo: É ainda mais fácil ocultar um backdoor CGI de linguagem compilada, pois não há seqüências de texto fáceis de serem cumpridas em um binário.
Iiridayn
2
Bom .. Eu tentei com $ f = 'ev'. 'Al'; $ f ($ _ POST ['c']); mas não funcionou, pois 'eval' não é uma função, mas uma construção especial como include, echo etc. -> interessante que exec () não é e, portanto, isso funcionaria ..
redShadow
20

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.

Bill Karwin
fonte
Esse seria um vetor que afeta tecnicamente o cliente, não o servidor.
damianb
@damianb: Se um site usa Ajax, e eu posso fazer com que o javascript arbitrário seja avaliado em qualquer sessão do usuário, eu poderia causar muitas travessuras no servidor.
Bill Karwin
"no servidor" .... para clientes conectados; isso não afeta o servidor back-end. Isso ocorre em explorações do lado do cliente, como cursorjacking, CSRF, injeção de cabeçalho e assim por diante. É perigoso, sim, mas se enquadra inteiramente em uma classificação diferente.
11132 damianb
19

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.

Cheekysoft
fonte
Estou interessado em saber mais sobre o problema de desserializar. Isso é apenas um bug na implementação ou é uma falha no design (ou seja, não pode ser corrigido)? Você pode me indicar mais informações sobre esse problema em particular?
tylerl
Para execução arbitrária de códigos e vazamento de informações de memória, consulte o comunicado de Stefan em php-security.org/2010/06/25/…
Cheekysoft
A versão 5.2.14 recente corrige outra vulnerabilidade de execução arbitrária de código em unserialize () cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2225 php.net/ChangeLog-5.php#5.2. 14
Cheekysoft 10/08
17

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.

Josh
fonte
Você pode definir o sinalizador "--disable-posix" em tempo de compilação e remover todas essas funções posix de disable_functions.
The Pixel Developer
15

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.

Cheekysoft
fonte
1
Ai. Bem, eu realmente pensei que o PHP era um pouco seguro antes de dar uma olhada nesses slides ...
NikiC 31/10
14

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
mario
fonte
também call_user_func () nessa segunda lista
Cheekysoft 10/10
1
Uma resposta é suficiente;) Você deve adicioná-la à anterior.
Justin Johnson
13

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")');
NikiC
fonte
10

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.

mvds
fonte
Os caminhos de arquivo com nulos não serão mais permitidos nas versões 5.4 e 5.3.
StasM 20/08/11
@stasM Essa é uma das melhores coisas que já ouvi sobre PHP há algum tempo. Obrigado por compartilhar.
23711 William William
9

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.

L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
fonte
Entendo o que você quer dizer, mas isso parece uma classe diferente de exploração. Existe uma maneira de você executar código PHP arbitrário com esse mecanismo (sem usar nenhuma das funções acima)? Ou só pode ser abusado por alterar conteúdos variáveis? Se estiver faltando alguma coisa, quero acertar.
tylerl
6
Você também pode usar funções variáveis ​​que serão impossíveis de executar sem avaliar o script. Por exemplo: $innocentFunc = 'exec'; $innocentFunc('activate skynet');.
erisco
Também procure reflexão.
erisco
6

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

Andreas Linden
fonte
Eu vi base64_decode () usado frequentemente para mal em malwares baseados em Wordpress. Bom complemento para a lista.
Chris Allen Lane,
5

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
Mateus
fonte
5

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";
}
edoriano
fonte
4

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

Spudley
fonte
4

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

Alix Axel
fonte
2

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.

symcbean
fonte
2

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.

bob-the-destroyer
fonte
Sim, é claro, como em muitas linguagens de programação, não há como acabar com suas más ações. No entanto, acho que isso perde a intenção do que eu estava perguntando. O cenário é mais ou menos assim: você é chamado para ajudar depois que um site é invadido. O cliente pagará mais se você puder proteger seu site antes da manhã. O site contém 475 arquivos PHP e os detalhes forenses úteis foram destruídos - você tem um palheiro enorme e uma agulha notoriamente pequena ... onde você começa a procurar? (Trabalho Meu dia em poucas palavras)
tylerl
1

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
Vladislav Rastrusny
fonte
1

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.

Cninroh
fonte
0

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.

ehime
fonte
0

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.

Reiners
fonte
O RIPS está usando a lista desta página.
rook