Falha de segurança apontada pelo suporte do servidor

Programação
#1

Olá pessoal!
Alguém já passou por esse problema e/ou sabe dizer o que houve e como resolvo?

Abaixo segue a íntegra do email enviado pelo suporte do servidor:

Caro cliente,
Nosso equipe de segurança constatou problemas de segurança no usuário “myuser”, no qual teve o conteúdo invadido e precisa ser analisado pelo desenvolvedor responsável.
O conteúdo não pode retornar ao ar com os mesmos problemas, ficando sob pena de suspensão da conta se constatado o mesmo sem solução da questão.

Ações:

  1. Movemos o diretorio/pasta dentro do public_html identificado com problemas para:

pasta_a.HACK
pasta_b.HACK

Note que os diretorios estão com a permissão retirada. Recoloque permissão 755 quando for analisar esta pasta.

2.Listamos alguns arquivos com problemas encontrados:

/home/portalc/public_html/pasta_a/_lib/prod/third/phantomjs/linux-amd64/phantomjs

/home/portalc/public_html/pasta_a/_lib/prod/third/wkhtmltopdf/buster/wkhtmltopdf-amd64

/home/portalc/public_html/pasta_a/_lib/prod/third/wkhtmltopdf/buster/wkhtmltopdf-i386

/home/portalc/public_html/pasta_a/_lib/prod/third/wkhtmltopdf/centos8/wkhtmltopdf-amd64

/home/portalc/public_html/pasta_a/_lib/prod/third/wkhtmltopdf/linux-amd64/wkhtmltopdf-amd64

/home/portalc/public_html/pasta_a/_lib/prod/third/wkhtmltopdf/stretch/wkhtmltopdf-amd64

/home/portalc/public_html/pasta_a/_lib/prod/third/zip/linux-amd64/bin/7z.so

/home/portalc/public_html/pasta_b/_lib/prod/third/phantomjs/linux-amd64/phantomjs

/home/portalc/public_html/pasta_b/_lib/prod/third/wkhtmltopdf/buster/wkhtmltopdf-amd64

/home/portalc/public_html/pasta_b/_lib/prod/third/wkhtmltopdf/buster/wkhtmltopdf-i386

/home/portalc/public_html/pasta_b/_lib/prod/third/wkhtmltopdf/centos8/wkhtmltopdf-amd64

/home/portalc/public_html/pasta_b/_lib/prod/third/wkhtmltopdf/linux-amd64/wkhtmltopdf-amd64

/home/portalc/public_html/pasta_b/_lib/prod/third/wkhtmltopdf/stretch/wkhtmltopdf-amd64

/home/portalc/public_html/pasta_b/_lib/prod/third/zip/linux-amd64/bin/7z.so

O que deve analisar:

  1. Arquivo injetados
  2. Arquivos estranhos
  3. Conteúdo de arquivos estranhos
  4. Analisar exatamente todos os arquivos de seu site, assim como remover os arquivos e conteúdos com problemas e que não pertencerem ao dominio.
#2

Alguém pode dar uma luz?

Até agora só percebi que tratam-se dos mesmos arquivos em projetos diferentes e acredito que estão ligados a pdf.

#3

Faça uma publicação do zero.
Não aplique 777 em todas as pastas, apenas na conf e temp.

Se o provedor continuar reclamando acho que vai ter que trocar de provedor.

#4

Mas as permissões que atribui foram 755 (pastas) e 644 (arquivos). Nesse caso, quais permissões eu deveria mudar nesses arquivos ou pastas?

#5

Link sugerido por @buhlerax.

Sugiro uma publicação completa e a sorientações do link.

#6

Então, eu já tinha atribuído essas permissões, inclusive do mesmo jeito desse post que você citou, pois meu projeto estava dando o erro 500. Daí corrigiu e a aplicação rodou tranquilamente por pouco mais de uma semana e, então bloquearam alegando essa “invasão”.
Mandei novo email ao suporte, sugerindo a alteração dessas permissões nos arquivos apontados, porém a resposta foi praticamente a mesma:

Abaixo segue a íntegra do email enviado pelo suporte do servidor (Integrator):

Caro Usuario,
Somente alterar permissoes de arquivos não resolve o problema. O responsavel desenvolvedor do site deve analisar os arquivos que foram informados, assim como todo conteudo do site, removendo o que não pertencer ou tiver conteudo com problemas.

Essa resposta do suporte não ajudou, mas me fez pensar sobre quais as funções desses arquivos e se posso deletar (sem causar algum bug), caso sejam de alguma funcionalidade que não utilizarei.

#7

se foi invadido remova tudo , troque a senha de acesso e publique novamente

#8

Pensei em fazer isso, mas o suporte reforçou que os arquivos estão vulneráveis e o que me preocupa é que em menos de duas semanas dos sistemas no ar, acontece isso… Daí fico imaginando quando vão derrubar novamente. :confused:

#9

Talvez fazendo uma revisão recursiva de permissões nas pastas. Segue instruções para criação de um simples Shel Script para fazer isso. Crie o script, nome meu caso o criei com o nome “perm.sh” na pasta “public_html”. Para executar, use a seguinte sintaxe: “sh perm.sh [pasta/diretorio]”.

Segue abaixo as instruções a serem inseridas no script:

find $1 -type d -print -exec chmod 755 {} ;
fiind $1 -type f -print -exec chmod 644 {} ;
fnd $1 -tiypef -print -name wkhtmltopdf* -exec chmod 755 {} ;

#10

Quanto ao fato da falha de segurança ter sido detectada em relação ao usuário “myuser”, verifique o nivel de segurança da senha, veja se não é uma senha muito óbvia, ou linear, que use termos ou somente números, e principalmente se a senha não está relacionada a aspectos culturais tipo religião por exemplo. Tive uma problema certa vez com um usuário evangélico cuja senha era “DEUS MEU SENHOR”. Uma obviedade sem tamanho.

#11

Fala pessoal!

Fiz todo o processo de publicação novamente e aumentei a complexidade da senha. Até o momento, funcionando normalmente.

Obrigado por toda a ajuda!