Segurança adicional para o WHMCS e outros scripts

[MyWay Hosting]

<p>&lt;p&gt;Ol&amp;aacute;.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Sou novo neste f&amp;oacute;rum e tenho muita experi&amp;ecirc;ncia em administra&amp;ccedil;&amp;atilde;o de servidores cPanel e seguran&amp;ccedil;a. Costumo desenvolver ferramentas pr&amp;oacute;prias para seguran&amp;ccedil;a para minha empresa.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Esta ser&amp;aacute; minha primeira contribui&amp;ccedil;&amp;atilde;o aqui no Portal do Host.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Eu gostaria de deixar uma sugest&amp;atilde;o de seguran&amp;ccedil;a, em rela&amp;ccedil;&amp;atilde;o ao WHMCS que tamb&amp;eacute;m servir&amp;aacute; para qualquer script em contas hospedadas em servidores compartilhados ou n&amp;atilde;o compartilhados. Mesmo que voc&amp;ecirc; tenha um VPS, Cloud, dedicado, seja l&amp;aacute; qual for o servi&amp;ccedil;o que voc&amp;ecirc; usa e onde tenha diversas contas hospedadas, &amp;nbsp;deve ler com aten&amp;ccedil;&amp;atilde;o o que estou escrevendo aqui e usar essa t&amp;aacute;tica de seguran&amp;ccedil;a.&amp;nbsp;&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Existe uma falha grave de seguran&amp;ccedil;a no Apache. Para o Apache, existem alguns remendos e solu&amp;ccedil;&amp;otilde;es mas nem todas empresas aplicam a corre&amp;ccedil;&amp;atilde;o, seja por n&amp;atilde;o conhecer ou seja por preferir outros meios de seguran&amp;ccedil;a que mantenha a falha mas que seja detect&amp;aacute;vel com auto suspens&amp;atilde;o da conta hackeada que dar&amp;aacute; a brecha para o hack.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Esta falha permite, mesmo que um site esteja em um servidor seguro que funcione sob SUPHP, tenha uma conta hackeada a partir de uma outra conta hackeada no mesmo servidor. N&amp;atilde;o irei entrar em detalhes de como funciona a seguran&amp;ccedil;a do SUPHP mas isso n&amp;atilde;o significa total isolamento de uma conta hospedada como muitos acreditam.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Como funciona a falha? Mesmo em servidores com SUPHP.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Por padr&amp;atilde;o o arquivo configuration.php, config.php, conexao.php ou qualquer outro arquivo de conex&amp;atilde;o a base de dados fica com permiss&amp;atilde;o 644 quando o mesmo &amp;eacute; enviado ao ftp. &amp;Eacute; justamente ai que mora o perigo somada a falha do APACHE.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;No caso do WHMCS o arquivo de configura&amp;ccedil;&amp;atilde;o &amp;eacute; configuration.php. Muito bem. Tomaremos isso como exemplo.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Digamos que em um servidor tenhamos 2 sites hospedados. Ent&amp;atilde;o a estrutura na home ser&amp;aacute; assim&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;/home/USER1/public_html/&lt;/p&gt;

&lt;p&gt;/home/USER2/public_html/&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;O user1 est&amp;aacute; usando o WORDPRESS e o user2 est&amp;aacute; usando o WHMCS ou qualquer outro script com conex&amp;atilde;o a base de dados.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;O user1 est&amp;aacute; usando script desatualizado que permite o hack da conta. Quando pensamos que o SUPHP ir&amp;aacute; fazer uma prote&amp;ccedil;&amp;atilde;o total para o user2 ai que entra um macete do hack.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Como funciona ?&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;1) O hacker usando um script, coleta o username de todas contas do servidor.&amp;nbsp;&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Ent&amp;atilde;o ele saber&amp;aacute; o username de todos sites hospedados no servidor. Sendo assim o primeiro passo est&amp;aacute; dado. Agora ele sabe que existe uma outra conta que neste nosso exemplo chama-se USER2&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;2) Agora dentro do site que ele hackeou, ele imagina que exista diversos scripts comuns hospedados no USER2.&amp;nbsp;&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Ent&amp;atilde;o ele cria links para dentro do USER2 com os mais variados nomes de arquivos.&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Entenda que estes links &amp;eacute; como um link criado na sua &amp;aacute;rea de trabalho para um arquivo em seu HD.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Ent&amp;atilde;o ele ir&amp;aacute; criar links dentro do USER1 para dentro do USER2 como os exemplos abaixo citados.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;&amp;gt;&amp;gt;&amp;nbsp;/home/USER2/public_html/configuration.php&lt;/p&gt;

&lt;div&gt;

&lt;p&gt;&amp;gt;&amp;gt;&amp;nbsp;/home/USER2/public_html/db.php&lt;/p&gt;

&lt;div&gt;

&lt;p&gt;&amp;gt;&amp;gt;&amp;nbsp;/home/USER2/public_html/conexao.php&lt;/p&gt;

&lt;div&gt;

&lt;p&gt;&amp;gt;&amp;gt;&amp;nbsp;/home/USER2/public_html/config.php&lt;/p&gt;

&lt;div&gt;&amp;nbsp;&lt;/div&gt;

&lt;/div&gt;

&lt;/div&gt;

&lt;/div&gt;

&lt;p&gt;3) O pr&amp;oacute;ximo passo do hacker &amp;eacute; acessar os links. Claro que no caso acima, ele ter&amp;aacute; uma mensagem de erro para os arquivos db.php, conexao.php, config.php porque estes arquivos n&amp;atilde;o existem no USER2 mas poder&amp;aacute; ler o arquivo configuration.php&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;A partir de agora o hacker tem a senha da base de dados + o user da conta + nome da base de dados&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Usando estes dados ele pode ent&amp;atilde;o hackear sua conta, destruir seus dados, destruir a base de dados e etc. Seja qual a inten&amp;ccedil;&amp;atilde;o do hacker, ele tem tudo para isso.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Como resolver isso ?&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;O segredo &amp;eacute; muito simples. Coloque permiss&amp;atilde;o 640 para o arquivo configuration.php ou para qualquer outro arquivo de conex&amp;atilde;o da base de dados. Cada script define o nome do arquivo de conex&amp;atilde;o. Se voc&amp;ecirc; desenvolveu um script e o arquivo &amp;eacute; chamado de conecta.php ent&amp;atilde;o coloque a permiss&amp;atilde;o 640.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Essa permiss&amp;atilde;o ir&amp;aacute; retirar do hacker a possibilidade de ele enxergar o conte&amp;uacute;do do arquivo.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Eu j&amp;aacute; havia comentado sobre isso com o Edvan no site dele e ele ficou de contactar a WHMCS para saber sobre isso mas n&amp;atilde;o houve mais respostas na p&amp;aacute;gina de seguran&amp;ccedil;a. Inclusive o checklist criado para verificar a seguran&amp;ccedil;a continua informando que o arquivo com 644 de permiss&amp;atilde;o est&amp;aacute; seguro. Eu acredito que o checklist deva ser modificado e instruido para que o arquivo tenha permiss&amp;atilde;o 640.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;J&amp;aacute; comentei isso em uma p&amp;aacute;gina no facebook para usu&amp;aacute;rios de WHMCS afim de alertar sobre o grande perigo que os mesmos est&amp;atilde;o passando.&amp;nbsp;&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Minha inten&amp;ccedil;&amp;atilde;o &amp;eacute; orientar os usu&amp;aacute;rios que alugam servidores compartilhados, dedicados, seja qual for e que hospede diversas contas ou n&amp;atilde;o, sobre como aumentar sua seguran&amp;ccedil;a.&amp;nbsp;&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Inclusive em nossos servidores que administramos, temos scripts preparados para mudar permiss&amp;atilde;o automaticamente em todas contas hospedadas visto que &amp;eacute; imposs&amp;iacute;vel fazer com que 100% dos clientes tomem a atitude correta na hora de colocar a devida permiss&amp;atilde;o no arquivo de configura&amp;ccedil;&amp;atilde;o que conecta a base de dados.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Considera&amp;ccedil;&amp;otilde;es finais:&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Apesar de um servidor estar rodando com compila&amp;ccedil;&amp;atilde;o SUPHP, ele poder&amp;aacute; ver o conte&amp;uacute;do do arquivo mas n&amp;atilde;o poder&amp;aacute; alterar o mesmo a partir do site hackeado.&amp;nbsp;&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&lt;p&gt;Em caso de d&amp;uacute;vidas, responda esse t&amp;oacute;pico que posso ajudar a entender melhor caso ainda tenha ficado d&amp;uacute;vidas.&lt;/p&gt;

&lt;p&gt;&amp;nbsp;&lt;/p&gt;

&nbsp;</p>

[Guest]

Isso é symlink, não? Se sim, já tem uma solução.

[MyWay Hosting]

Olá Erick

sim, isso é ataque via simlink. Tem solução mas não necessariamente ela está aplicada no servidor que está sua conta.

Vamos lá:

Caso 1)

Digamos que você tenha um dedicado,ou VPS. Você tem acesso SSH e o serviço é totalmente configurado por você. Então, neste caso você é que tem que fazer a correção. Inclusive a melhor opção é paga e requer bastante conhecimento para ser feita.

Não pense que irá receber o servidor já com a correção visto que é um adicional feito pelo admin do servidor posteriormente a instalação do serviço. Não é uma solução default ou disponibilizada pelo fabricante do Apache webserver.

Se você comprar hoje um VPS ou dedicado, virá o Linux instalado + painel, sem nenhuma correção !

Caso 2)

Quando está usando servidores compartilhados, as famosas revendas normais ou hospedagem normal, como saber se o admin implantou a segurança ? Difícil saber.

Então em ambos casos, permissão 640 no arquivo de conexão a base de dados !

Abraços!

[RobertSP]

Galera se vocês mantém o WHM/cPanel atualizados, apache compilado 'adequadamente' via EasyApache, não há risco!

 

Sem pânico, isso é velho, antigamente utilizavamos "SymLinksIfOwnerMatch" como prevenção global, mas atualmente nem há mais a necessidade!

[MyWay Hosting]

Galera se vocês mantém o WHM/cPanel atualizados, apache compilado 'adequadamente' via EasyApache, não há risco!

 

Sem pânico, isso é velho, antigamente utilizavamos "SymLinksIfOwnerMatch" como prevenção global, mas atualmente nem há mais a necessidade!

 

 

Olá RobertSP

 

Os usuários do WHMCS ou qualquer outro script devem levar a minha sugestão ao pé da letra e não confiar no servidor que estão hospedados.

 

Há claro indício para executar a troca de permissão do arquivo. O pânico começa quando você pode ter todos seus dados destruídos e um backup atualizado por cima disso.

 

A palavra pânico neste caso não é que eu escreveria e sim aplicação imediata da troca da permissão. 

 

Sou novo no fórum e estou observando muitos usuários usando servidores virtuais e não dedicados. Portanto a sua sugestão é válida apenas para quem tem controle total sobre o equipamento com acesso root !

 

Apenas atualizar o WHM e CPANEL não resolve o problema. Alem de atualizar o WHM e CPANEL tem que fazer a compilação necessária do servidor WEB.

 

A solução apresentada pelo fabricante do CPANEL tem aspectos ruins que podem obrigar ao admin do servidor a não fazer a compilação para evitar o problema e tomar outras soluções no lugar. 

 

Não vou entrar em detalhes dos motivos do patch não ser aplicado. Isso é caso para ser discutido no forum da CPANEL ou com o próprio fabricante. 

 

O fato é que a falha existe e não necessariamente o usuário está em um servidor com o PATCH aplicado.

 

Você escreveu de uma forma como se TODOS servidores já tivessem aplicado a correção ou como se TODOS administradores tenham optado pela correção e como se TODOS administradores de servidores, mesmo que capacitados tenham feito as correções.

 

Alem disso você esqueceu dos usuários que usam servidores virtuais sem acesso root !

 

Abraços.

[Alexandre Duran]

Sem dúvida a melhor forma de se prevenir é aplicando o 640 no arquivo de config. Isso é válido não apenas para o WHMCS quanto tb para praticamente todos os scripts existentes.

 

Mas tem uma dica: para os que usam o CloudLinux, instale o CAGEFS e seja feliz.

[MyWay Hosting]

Sem dúvida a melhor forma de se prevenir é aplicando o 640 no arquivo de config. Isso é válido não apenas para o WHMCS quanto tb para praticamente todos os scripts existentes.

 

Mas tem uma dica: para os que usam o CloudLinux, instale o CAGEFS e seja feliz.

 

Olá Duran,

 

sim, existe essa possibilidade. Tendo acesso root e fizer a configuração funciona bem.

 

Mas isso se o usuário tiver root para poder instalar isso ou aplicar outro patch. 

 

Eu escrevi esse tópico visando todos usuários, incluindo quem não tem acesso root, quem tem mas não aplicou a correção até mesmo por desconhecer e ainda usuários de hospedagem comum que usam o WHMCS para outras funções a não ser hosting. Sim, isso é aplicável para qualquer script. Não é uma falha do WHMCS e sim do servidor WEB.

 

Abraços.

[Guest]

Sem dúvida a melhor forma de se prevenir é aplicando o 640 no arquivo de config. Isso é válido não apenas para o WHMCS quanto tb para praticamente todos os scripts existentes.

Mas tem uma dica: para os que usam o CloudLinux, instale o CAGEFS e seja feliz.

É uma boa utilizar CageFS, mas vale ressaltar que ele não vai salvar ninguém de um belo Privilege Escalation...

O que eu recomendo utilizar é também as regras do ModSec do OWASP.

--

Também existe outras formas de aplicar este path, que pode ser mesmo até via modsecurity.

http://docs.cpanel.net/twiki/bin/view/EasyApache/Apache/SymlinkPatch

http://www.sysadmindiaries.com/2013/07/how-to-prevent-cpanel-apache-symlink.html

[Alexandre Duran]

É uma boa utilizar CageFS, mas vale ressaltar que ele não vai salvar ninguém de um belo Privilege Escalation...

O que eu recomendo utilizar é também as regras do ModSec do OWASP.

--

Também existe outras formas de aplicar este path, que pode ser mesmo até via modsecurity.

http://docs.cpanel.net/twiki/bin/view/EasyApache/Apache/SymlinkPatch

http://www.sysadmindiaries.com/2013/07/how-to-prevent-cpanel-apache-symlink.html

 

Eu testei o uso do OWASP mas não tive sucesso na instalação.

[edvan]

A WHMCS.com modificou as instruções nas permissões http://docs.whmcs.com/Installing_WHMCS#Installing_WHMCS

 

 

Required file & folders permissions

 

/configuration.php CHMOD 400 Readable

/attachments CHMOD 777 Writeable

/downloads CHMOD 777 Writeable

/templates_c CHMOD 777 Writeable

 

The above applies unless your php is suPHP or PHPSuExec. If using DSO as your php handler, you must use 644 permissions.