Shell Exploit Cuidado

[filipidev]

Olá! Amigos Do portaldohost! Primeiramente Gostaria de Alertar A todos Sobre Um novo Exploit Baseado em php Capaz de Danificar seu servidor, um cliente meu possui um servidor virtual Cpanel, ele me comunicou que o servidor estava fora do ar Openvz, fui verificar loguei pelo Dedicado é entrei no servidor virtual pois estava sem acesso Pelo SSH, dei comando service cpanel restart estava falando que o cpanel Não existe, fui verificar no top os processos tinha um processo com nome de um usuario que ele tinha Na conta cpanel executando Um Arquivo perl que danificou o servidor do cliente todo, infelizmente a programação foi complicada apagou tudo até mesmo /home Alem de danificar o cpanel perca total de contas

eu na hora se toquei que se trata de um exploit, perguntei se ele sabia algo ele disse que vendeu uma hospedagem cpanel para um cara que comprou poucas horas antes de acontecer isso, ele me passou usuario dele que foi criado no whmcs no caso era brevol mesmo usuario com o processo que verifiquei no top,executando um arquivo perl, o meu cliente disse que verificou arquivos dele antes de acontecer isso tinha o arquivo injection.pl injection.php php.ini

perguntei se ele Havia visto o codigo fonte ele me informou que o codigo fonte estava criptografado Com Ioncube. o arquivo perl ele verificou mais não entende nada dessa programação achou que faz parte de algum funcionamento do site, no arquivo php.ini ele me disse que estava safemode dentro, me falou apenas isso eu acredito que seja safe_mode = Off

pois, o safemode estava ativo por padrao no php.

intão, como o servidor dele é gerenciado basico coloquei CSF,Proteção total em diretorios, Mod_security,ClamAv rodando scanner em todos usuarios funçoes desativadas como shell_exec,passthru,exec,system,proc_ open entre outros perigosos.

mais como o safemode estava desativado pelo usuario tenho certeza que ele foi vitima de um exploit não comum como c99shell. Acredito que o exploit Funciona da seguinte Forma o php executa o perl por Algum comando que estava desativado No Safemode é o perl faz as funçoes total de danificar o servidor.

não vejo solução se for o que estou pensando, pois safemode ativado se ele colocar o php.ini consegue totalmente rodar comandos perigosos. venho alertar A todos caso notar arquivos parecidos Ou usuario, se algum leitor souber uma solução com base em que falei talvez desativar a modificaçao no php.ini seria uma solução, ou a outra seria não permitir o usuario Rodar .pl no servidor Não sei se e possivel, desculpe o texto Enorme "biblia" Mais achei que deveria Alertar A todos, pois trata-se de um Assunto serio, e peço se alguem souber como desativar o php.ini no diretorio ou desativar .pl para rodar sem ser usuario root Compartilhe conosco!

Muito Obrigado A todos! Fiquem Com Deus

[Visitante]

Era só desativar o ini_set (no disable_functions) que ele podia fazer o que quiser que não iria danificar o servidor, só se estiver muito mal configurado.

[filipidev]

Era só desativar o ini_set (no disable_functions) que ele podia fazer o que quiser que não iria danificar o servidor, só se estiver muito mal configurado.

Já estava desativado, o que acontece que ele desativou o safemode no php.ini dentro do diretorio principal dele.

[Visitante]

Já estava desativado, o que acontece que ele desativou o safemode no php.ini dentro do diretorio principal dele.

Não, se estivesse ativado ele não teria conseguido utilizar um php.ini pŕoprio.

[little_oak]

NÃO preocupe-se tanto com php, existe uma coisa chamada CGI/PERL que é MUITO aberta (em nível geral).

Já vi escalation a nível de root com arquivos .pl que baixavam séries de ferramentas (DEUS ME LIVRE!).

Minha humilde dica (na verdade 2):

1 - NUNCA LIBERE SHELL,

2 - NUNCA LIBERE CGI.

Se o cara quer formail pega um pronto na internet junto com o phpmailer e vai dar show, não mecha com cgi-perl, se não tiver um modsec bombado facilmente vai rolar exploitation.

Ps: NUNCA LIBERE urlwrapper no php de maneira que o cara busque coisas fora, manda usar CURL, fopen para abrir sites remotos é punk para invasão.

No mais, aquela chave ssh bem gordinha para evitar besteiras e por fim combater burrices como register globals, falta de php como cgi, suexec off e etc... chance de dano é mínima.