Cristian Augusto Postado Dezembro 8, 2011 Compartilhar Postado Dezembro 8, 2011 Acabei de receber um "ataque" exatamente igual ao que reporta este tópico, e estive fazendo alguns testes apartir deste script.. Na verdade, ele cria um arquivo chamado "b0x.php" na pasta lang. Dentro deste arquivo, possui um script para realizar upload de arquivos para esta pasta lang. Após por exemplo, "upar" um arquivo php que faça com que leia o arquivo "configuration.php", eu consigo por exemplo, todos os dados do banco de dados.. A solução que encontrei, foi restringir a criação de tickets apenas para clientes registrados, o que ameniza um pouco a situação.. Me desculpem se esta "solução", ou fato, já foi apresentado aqui neste tópico, mas por falta de tempo, acabei não lendo todo o tópico.. É isso pessoal Abraço! Link para o comentário Compartilhar em outros sites More sharing options...
edvan Postado Dezembro 8, 2011 Compartilhar Postado Dezembro 8, 2011 Acabei de receber um "ataque" exatamente igual ao que reporta este tópico, e estive fazendo alguns testes apartir deste script.. Na verdade, ele cria um arquivo chamado "b0x.php" na pasta lang. Dentro deste arquivo, possui um script para realizar upload de arquivos para esta pasta lang. Após por exemplo, "upar" um arquivo php que faça com que leia o arquivo "configuration.php", eu consigo por exemplo, todos os dados do banco de dados.. A solução que encontrei, foi restringir a criação de tickets apenas para clientes registrados, o que ameniza um pouco a situação.. Me desculpem se esta "solução", ou fato, já foi apresentado aqui neste tópico, mas por falta de tempo, acabei não lendo todo o tópico.. É isso pessoal Abraço! Dá uma lida em http://www.whmcs.blog.br/principal/atualizacao-de-seguranca-2/ Link para o comentário Compartilhar em outros sites More sharing options...
avonni Postado Dezembro 8, 2011 Compartilhar Postado Dezembro 8, 2011 (editado) Se alguém enviou a correção divulgada pela WHMCS.com e mesmo assim o problema persistiu certamente o arquivo estava na pasta /templates_c/ ou /lang/ e daí o cracker procedeu a invasão! Pensei em fazer um incremento de segurança utilizando o .htaccess Já que este tipo de ataque precisa upar/criar um .PHP e em seguida rodar o script, se limitarmos o acesso aos arquivos essenciais do WHMCS, creio que a probabilidade de ter problemas diminuiria bastante. Vou dar um exemplo: Na pasta /lang/ só temos os arquivos de linguagem que são .txt, logo poderíamos simplesmente desabilitar o acesso a qualquer outra extensão de arquivo nesta pasta. E é bem simples de ser feito: Options +FollowSymlinks RewriteEngine On RewriteCond %{REQUEST_FILENAME} !^(.+)\.txt$ RewriteRule ^(.+)$ "http\:\/\/www\.seusite\.com\.br\/central\/" [NC] Este código vai permitir acesso somente aos arquivos .txt e negar acesso a qualquer outra possível extensão (o que incluiria um possível .PHP malicioso, mesmo que já tivesse sido upado) e vai redirecionar quem tentar acessar os demais arquivos à página principal de seu WHMCS, neste exemplo: http://www.seusite.com.br/central/ (que obviamente você pode substituir pelo endereço do seu). Isto poderia ser feito para todas as pastas, permitindo somente os arquivos legítimos do WHMCS. Além das extensões necessárias, você pode configurar as permissões de acesso individualmente por arquivo. Exemplo: Options +FollowSymlinks RewriteEngine On RewriteCond %{REQUEST_FILENAME} !^(.+)\.txt$ RewriteCond %{REQUEST_FILENAME} !teste.php$ RewriteRule ^(.+)$ "http\:\/\/www\.seusite\.com\.br\/central\/" [NC] Neste caso, além de permitir acesso aos .txt, nós permitimos acesso ao arquivo teste.php. Assim é possível liberar acesso somente aos .PHP do WHMCS, listando cada um deles aqui. Assim demais arquivos .PHP que possam ser inseridos indevidamente em seu WHMCS não poderão ser acessados/executados via navegador pelo atacante. Sendo assim, ataque FAIL ;) Editado Dezembro 8, 2011 por Ysaac Link para o comentário Compartilhar em outros sites More sharing options...
Visitante Postado Dezembro 8, 2011 Compartilhar Postado Dezembro 8, 2011 Muito bom Ysaac.. favoritei aqui. Link para o comentário Compartilhar em outros sites More sharing options...
edvan Postado Dezembro 8, 2011 Compartilhar Postado Dezembro 8, 2011 Pensei em fazer um incremento de segurança utilizando o .htaccess Já que este tipo de ataque precisa upar/criar um .PHP e em seguida rodar o script, se limitarmos o acesso aos arquivos essenciais do WHMCS, creio que a probabilidade de ter problemas diminuiria bastante. Vou dar um exemplo: Na pasta /lang/ só temos os arquivos de linguagem que são .txt, logo poderíamos simplesmente desabilitar o acesso a qualquer outra extensão de arquivo nesta pasta. E é bem simples de ser feito: Options +FollowSymlinks RewriteEngine On RewriteCond %{REQUEST_FILENAME} !^(.+)\.txt$ RewriteRule ^(.+)$ "http\:\/\/www\.seusite\.com\.br\/central\/" [NC] Este código vai permitir acesso somente aos arquivos .txt e negar acesso a qualquer outra possível extensão (o que incluiria um possível .PHP malicioso, mesmo que já tivesse sido upado) e vai redirecionar quem tentar acessar os demais arquivos à página principal de seu WHMCS, neste exemplo: http://www.seusite.com.br/central/ (que obviamente você pode substituir pelo endereço do seu). Isto poderia ser feito para todas as pastas, permitindo somente os arquivos legítimos do WHMCS. Além das extensões necessárias, você pode configurar as permissões de acesso individualmente por arquivo. Exemplo: Options +FollowSymlinks RewriteEngine On RewriteCond %{REQUEST_FILENAME} !^(.+)\.txt$ RewriteCond %{REQUEST_FILENAME} !teste.php$ RewriteRule ^(.+)$ "http\:\/\/www\.seusite\.com\.br\/central\/" [NC] Neste caso, além de permitir acesso aos .txt, nós permitimos acesso ao arquivo teste.php. Assim é possível liberar acesso somente aos .PHP do WHMCS, listando cada um deles aqui. Assim demais arquivos .PHP que possam ser inseridos indevidamente em seu WHMCS não poderão ser acessados/executados via navegador pelo atacante. Sendo assim, ataque FAIL ;) Essa dica não deve ser aplicada para o WHMCS 5.0.2 pois os arquivos de linguagem /lang/ agora são em .php e não mais em .txt Link para o comentário Compartilhar em outros sites More sharing options...
avonni Postado Dezembro 8, 2011 Compartilhar Postado Dezembro 8, 2011 Essa dica não deve ser aplicada para o WHMCS 5.0.2 pois os arquivos de linguagem /lang/ agora são em .php e não mais em .txt Como eu mostrei no 2º exemplo, você pode habilitar individualmente os arquivos desejados. No caso da /lang/ do 5.0.2, é só listar/habilitar no .htaccess os arquivos de linguagem que agora são .PHP mas que já estão presentes no WHMCS, restringindo o acesso aos demais arquivos que possam vir a ser adicionados à pasta (de forma maliciosa). :o Link para o comentário Compartilhar em outros sites More sharing options...
avonni Postado Dezembro 8, 2011 Compartilhar Postado Dezembro 8, 2011 (editado) Baixei a nova versão do WHMCS só pra conferir como estão os arquivos. Então segue um exemplo de como proteger a pasta /lang/ na versão 5.0.2: Se você só utiliza/permite a utilização da linguagem "portuguese-br", é só criar um arquivo .htaccess na /lang/ com o seguinte código: Options +FollowSymlinks RewriteEngine On RewriteCond %{REQUEST_FILENAME} !portuguese-br.php$ RewriteRule ^(.+)$ "http\:\/\/www\.seusite\.com\.br\/central\/" [NC] O funcionamento é como informei antes: Só vai ser possível acessar/utilizar este arquivo na pasta /lang/ Quem tentar acessar qualquer outro arquivo nesta pasta, será redirecionado para o endereço principal do WHMCS, que neste exemplo é: http://www.seusite.com.br/central/ Logo, mesmo que alguém consiga upar um arquivo malicioso para esta pasta, ele não conseguirá acessá-lo e executá-lo. :) Se você permite que seus clientes utilizem os demais idiomas disponíveis, basta ir habilitando os arquivos como foi feito com o "portuguese-br". Você pode incluir o italian.php, english.php, e todos os arquivos que deseja permitir acesso. Este procedimento pode ser feito para cada pasta do WHMCS, bastando personalizar as permissões conforme as necessidades de cada pasta. ;) Editado Dezembro 8, 2011 por Ysaac Link para o comentário Compartilhar em outros sites More sharing options...
Cristian Augusto Postado Dezembro 8, 2011 Compartilhar Postado Dezembro 8, 2011 Estava pensando aqui... E se for executado um script para alterar, ou subscrever algum arquivo permitido? Link para o comentário Compartilhar em outros sites More sharing options...
Visitante Postado Dezembro 8, 2011 Compartilhar Postado Dezembro 8, 2011 Estava pensando aqui... E se for executado um script para alterar, ou subscrever algum arquivo permitido? Aí as permissões da sua instalação estão erradas. Link para o comentário Compartilhar em outros sites More sharing options...
Cristian Augusto Postado Dezembro 8, 2011 Compartilhar Postado Dezembro 8, 2011 Mas não é possível alterar arquivos a partir de um script PHP, assim como é possível criar os mesmos? Link para o comentário Compartilhar em outros sites More sharing options...
Posts Recomendados