Hacked? Como o acréscimo de um nome de arquivo permite o acesso aos dados no site… veja o exemplo

Question

Visitando todos os itens a seguir, você será direcionado para a tela de login:

http://mysite.com/admin/configuration.php
http://mysite.com/admin/login.php

No entanto, se você visitar (note que as duas últimas partes da string url são ambas .php):

http://mysite.com/admin/configuration.php/login.php

Você pode ver a tela de configuração e todos os seus dados!

Além disso, se você adicionar algumas variáveis GET, poderá até obter campos editáveis:

http://mysite.com/admin/configuration.php/login.php?cID=1&action=edit

O que está acontecendo aqui?

Devo notar que isso está no site usando um carrinho de compras absolutamente horrível chamado oscommerce. O código é um pesadelo para lidar, mas estou preso a isso por enquanto.

EDITAR

Uma correção baseada no comentário excelente e preciso do vstm abaixo:

Isso ocorreria logo antes da verificação para ver se $current_page != FILENAME_LOGIN (em torno das linhas 141-143 em /admin/includes/application_top.php). Lembre-se que este é apenas um patch de emergência, já que a solução real é nunca usar o oscommerce, pois é tão seguro quanto um hooker.

//$current_page = basename($PHP_SELF); //this is the default
$current_page = basename($_SERVER['SCRIPT_NAME']); //change that default to this

if ( ($current_page == FILENAME_LOGIN) && !tep_session_is_registered('redirect_origin') ) {
      $current_page = FILENAME_DEFAULT;
      $HTTP_GET_VARS = array();
    }

Se alguém tentar isso, não se esqueça de que a var de redirect_origin session já pode estar definida para que isso pareça não funcionar. Apenas desmarque e tente novamente.

    

Answer 1

Nos includes / application_top, que são incluídos por todos os scripts em /admin , você encontrará esta pequena joia (eu joguei algumas partes desinteressantes):

// redirect to login page if administrator is not yet logged in
if (!tep_session_is_registered('admin')) {
    $redirect = false;

    $current_page = basename($PHP_SELF);

    if ($current_page != FILENAME_LOGIN) {
        // session stuf blabla
        $redirect = true;
    }

    if ($redirect == true) {
        tep_redirect(tep_href_link(FILENAME_LOGIN));
    }

    unset($redirect);
}

Este código só é executado quando você não está logado. O que basicamente faz é verificar se basename de $PHP_SELF é login.php. Se for login.php, ele continuará a renderizar a página, caso contrário, você será redirecionado.

Se você fizer essa solicitação:

http://mysite.com/admin/configuration.php/login.php

Então o PHP_SELF será

/admin/configuration.php/login.php

E basename($PHP_SELF) será, naturalmente, login.php , portanto, a renderização continua e nenhum redirecionamento é executado. Mas é claro que não é login.php , que é processado, mas configuration.php . O resto da URL "/login.php" é "ignorado" e é fornecido apenas para o PHP em $ _SERVER ['PATH_INFO'].

Edit: Eu gostaria de acrescentar que este "bug" afeta apenas o oscommerce ou qualquer outro software que use uma solução como essa para "proteger" o login de administração (acho que não há muitos que sofrem com isso). Não é um bug que afeta todo o software PHP.

    

Answer 2

Isso é simplesmente uma vulnerabilidade no arquivo configuration.php - a coisa do 'diretório falso' com um arquivo php como parte do caminho é um recurso intencional e algo que você verá com frequência - como o material após a barra é manipulado é até o arquivo php no caminho. (mediawiki vem à mente como um bom exemplo)

    

Answer 3

Eu tentei isso em uma caixa do windows, para usar um URL duplo conforme indicado - ele diz que a página não foi encontrada. Mas o servidor está configurado para não permitir transversais de diretórios e o OSCommerce está configurado para verificar o agente do usuário e evitar sessões do spider, bem como usar um diretório de sessões - possivelmente é por isso que é seguro e não permite anexar um URL. Além disso, o servidor trata o /login.php como parte do primeiro nome de arquivo, não permite transversais de driectory e não permite ponto em um nome de arquivo - portanto, ele recusa a URL inteiramente. Portanto, é seguro porque o servidor é seguro, independentemente do que o software de catálogo tente fazer.