É Inseguro Rodar Scripts Como Nobody

[Jaime Silva]

Como é rotineiro, estava trabalhando em sistemas de backup e acabei descobrindo algo preocupante:

Com o PHP rodando como DSO ou (CGI sem o SuExec) é possível acessar arquivos de outras contas facilmente.

Não precisa ter o open_basedir habilitado, pois pode-se executar comando do shell e ver o conteúdo de arquivos importantes.

Consegui com facilidade acessar o arquivo configuration.php do Joomla e vi a senha do banco de dados.

Isso acontece por a pasta public_html, em servidor com Apache, ter acesso de leitura pelo usuário nobody. Os diretórios por padrão tem permissão 755 e arquivos 644, que é suficiente pra lê-los.

O problema não é com o PHP, pois scripts em Perl, por exemplo, rodando via CGI também dão acesso a arquivos de outras contas.

Além disso, o fato do arquivo passwd poder ser lido, permite que alguém possa obter todos os UIDs dos usuário do servidor e seus homedirs. A partir daí, pode-se procurar arquivos importantes, como os arquivos de configuração, com senhas e etc.

Fica a dica: ative o SuExec e SuPHP (ou quem sabe ModRuid, se tiver algum problemas com esses) e dê permissão de leitura apenas pelo próprio usuário em arquivos de configuração.

[joaopaulo]

Estranho, estive testando essa vulnerabilidade num servidor aqui (cPanel) e não deu certo o acesso de outras contas via PHP ou usando a função exec(). Teria como fornecer o script que você usou?

Mas faz sentido o que você falou. Será que deu sorte grande por aqui?

[Angel Junior]

Realmente o que o Jaime falou, tem muita relação e sentido.

No entanto como o joão, eu testei algumas coisas, e não consegui. (as vezes sou muito burro). Mais creio que se tiver tudo bem configurado, é mais complicado.

[JMonteiro]

Mas essas configurações não são as recomendadas para servidores compartilhados.

O mais indicado é SuPHP + SuEXEC, repetindo, em hospedagem compartilhada.

Assim os processos vão ser executados pelo id do usuário acabando com esses problemas, correto? (amisto de afirmação e duvida...)

[Jaime Silva]

Estranho, estive testando essa vulnerabilidade num servidor aqui (cPanel) e não deu certo o acesso de outras contas via PHP ou usando a função exec(). Teria como fornecer o script que você usou?

Mas faz sentido o que você falou. Será que deu sorte grande por aqui?

Jõao, o cPanel por si só é inseguro.

Você nem deve saber, mas, por exemplo, é possível ter acesso total ao sistema apenas editando um certo arquivo do fullbackup do cPanel.

Em PHP e Perl o procedimento é o mesmo.

Por algum motivo, não é possível ler os arquivos com o file hander do PHP nem Perl, mas pode-se fazer isso com o comando tail.

# Funcionou !!!

system ('cd /home/<USUARIO>/public_html/site; ls'); # Listar arquivos

system ('tail -n 20 /home/<USUARIO>/public_html/site/configuration.php'); # Ler o arquivo

print file_get_contents('/home/<USUARIO>/public_html/site/configuration.php'); # Não funciona

# Não funciona

open( FILE, '/home/<USUARIO>/public_html/site/configuration.php') or print('Não foi possível abrir o arquivo!');

while (<FILE>) {

print $_;

}

close(FILE);

[Jaime Silva]

Mas essas configurações não são as recomendadas para servidores compartilhados.

O mais indicado é SuPHP + SuEXEC, repetindo, em hospedagem compartilhada.

Assim os processos vão ser executados pelo id do usuário acabando com esses problemas, correto? (amisto de afirmação e duvida...)

Sim, isso mesmo!

Complementando, as permissões do homedir das contas testadas eram 0711, public_html 0750, as demais tem permissão 0755

O que acho inseguro também é poder ler o arquivo /etc/passwd e obter a UID dos usuários (tanto pelo arquivo, quanto usando outros métodos) tanto via PHP quando CGI.

[joaopaulo]

Todos os servidores que tenho com cPanel, não são para hosting. É algum cliente que assina um de nossos serviços, gosta bastante da empresa e quer trazer blogs, portais ou outros emprendimentos para nossa estrutura. Aí como não é um ambiente "compartilhado", eu abro mão do suPHP e suExec para colocar o Eaccelerator, pois tenho plena convicção que ele não vai hackear a si mesmo.

@Jaime, eu tentei usar um scrip parecido com:

#php

echo 'buscando /home<br/>';

print_r(scandir('/home'));

echo '<br/><br/>.indo diretamente a um usuario /home/fulano/<br/>';

print_r(scandir('/home/fulano'));

#php+shell

echo 'buscando /home<br/>';

print_r(shell_exec("ls /home/"));

echo 'buscando /home<br/>';

print_r(shell_exec("ls /home/fulano/"));

Esses códigos escrevi agora, mas foram os que usei. Escrevi um com o exec() também. O 2o não funcionou pois bloqueio o acesso shell no cpanel e a exec() está entre as funções desativadas, juntamente com a shell_exe().

O Fullb ackup do cPanel é uma trincheira de códigos, da para pegar de tudo por lá: senhas do Mysql, email, trocar o proprietário da conta (aí acho que era aqui que você se referia, seria no .addons), enfim, já me aventurei estudando aqueles full backups.

[Jaime Silva]

ls /home/ -> Não funciona de modo algum. Não é possível ler a raíz do diretório home

A diretiva de funções desativadas pode ser ignorada com um php.ini, exceto em FastCGI

Com o PHP seria mais fácil listar os usuários do servidor e obter seus homedirs lendo o arquivo passwd.

Além disso pode-se rodar qualquer script em qualquer linguagem, inclusive em C, através de CGI, suportado nativamente pelo Apache.

Sobre o fullbackup, não lembro qual arquivo, mas é que tem informações sobre o revendedor.

Funciona apenas com fullbackup de conta de revendedor, mas você pode modificar os arquivos e dar privilégio de revenda à conta e dar acesso total à ela. Sim, ela terá acesso administrativo completo. Embora apenas dentro do cPanel, isso é suficiente pra muita coisa e também pra mudar a senha de root.