PHP eval (gzinflate (base64_decode (..))) hack - como impedir que ocorra novamente?

Question

Recentemente, tivemos um site hackeado, no qual um código PHP foi injetado no arquivo index.php que se parecia com:

eval (gzinflate (base64_decode ('s127ezsS / ... bA236UA1')))

O código estava fazendo com que outro arquivo php (cnfg.php) fosse incluído, o que fazia com que alguns spams relacionados a produtos farmacêuticos fossem exibidos (mas visíveis apenas para o googlebot et al). Isso parece o pharma hack para wordpress, exceto que não estamos executando o software. O código foi removido, mas eu gostaria de evitar que tais ocorrências aconteçam no futuro.

Eu percebo que este é um problema bem amplo e que poderia haver uma miríade de falhas de segurança que poderiam ser responsáveis, mas pensei em colocar isso lá para o caso de alguém ter tido experiência com um problema como esse no passado.

Quais são os possíveis problemas de segurança que permitiriam o upload desses arquivos php? E o que posso fazer para evitar que isso aconteça no futuro?

Felicidades

    

Answer 1

Você precisa descobrir como isso chegou.

• O invasor teve acesso ao sistema de arquivos por meio do sftp / scp?
  • Se isso aconteceu, você precisa bloquear seus métodos de acesso remoto
• O invasor usou algum script de upload ou algum bug em um script existente que permitiu modificar arquivos?
  • Corrija o script, altere as permissões em seus scripts e conteúdo da Web para que o processo do servidor da Web não possa alterá-los. O servidor web deve ser limitado a modificar arquivos em um diretório de dados em algum lugar. Seus scripts e arquivos geralmente não devem pertencer ou ser graváveis pelo servidor da web.
• O script veio como parte de algum software malicioso que você escolheu?
  • Eu vi coisas assim incluídas como parte dos modelos do wordpress. Um usuário desavisado baixou modelos de algum site aleatório. Esses modelos incluíam a função para executar o código de um servidor da web externo. Isso combinado com configurações de permissão ruins permitiu que o invasor modificasse outras coisas.

Answer 2

Apenas um aviso.

Se você estiver usando o FileZilla como seu cliente de FTP, há um malware por aí que irá capturar suas credenciais de FTP do Filezilla PLAIN TEXT FILE (sim!) e usar essas informações para inserir esse código de malware (indicado pelo # b58b6f # tipo de código em torno de um comando "gzinflate (base64_decode)". É assim que seus arquivos serão atacados / comprometidos.

Procure na pasta% APPDATA% / Roaming / Filezilla. Um dos arquivos XML contém toda a credencial do seu site FTP (usuário / senha / etc) em PLAIN TEXT! E as pessoas do FileZilla se recusam a consertar essa falha óbvia de segurança.

Minha recomendação: exclua o FileZilla do seu computador (e você terá que excluir manualmente a pasta na sua pasta APPDATA).

Se você precisar de um cliente FTP seguro, use WinSCP (www .winscp .net), onde poderá definir uma senha mestra e todas as credenciais do seu site serão criptografadas.

Apenas um aviso ... Rick ... J

    

Answer 3

Existe um enorme campo de possibilidades de como isso poderia ter acontecido. Uma informação que ajuda a limitar isso é o tipo de hospedagem que você tem (compartilhado, dedicado, virtual) e quem é seu host. Alguns possíveis pontos de entrada são

• Compromisso da conta de administrador
• Compromisso de sua conta ftp / ssh / web console / etc com seu provedor. Se você enviar sua senha por meio de um protocolo não criptografado (como o FTP), pare de fazer isso.
• Comprometimento da sua máquina de desenvolvimento local
• Vulnerabilidade é qualquer software do servidor no servidor, como o Apache ou qualquer um dos seus módulos.

• Vulnerabilidade no nível do aplicativo em o PHP no seu site:

  • Você está usando software de terceiros e, em caso afirmativo, está tudo atualizado?
  • Você escreveu uma quantidade significativa de sua própria programação no local? Se assim for, há um milhão de maneiras você poderia ter escrito um buraco. Verifica qualquer método que toque dados proveniente da entrada do usuário (PEDIDO / OBTER / POST / COOKIES / ARQUIVOS). Se você permitir uploads de arquivos, você salva esses arquivos não filtrados em um diretório visualizável na web? Se assim for, alguém poderia fazer o upload de um script .php e, em seguida, apenas visualizá-lo. instruções include / require são destinos especialmente interessantes se você usar uma solução de templates como:

  <?php include $_GET['page'] . '.php'; ?>

Como evitar que se repitam?

• Certifique-se de confiar totalmente na segurança do seu host. Chame-os e grelhe-os em suas políticas de segurança, com que rapidez eles corrigem seus serviços quando surgem vulnerabilidades, etc.
• Ignore a hospedagem compartilhada e pague por dedicado ou dedicado virtualmente. Menos pessoas usando o servidor significa menos vetores para atacar
• Mantenha seus próprios aplicativos / bibliotecas de terceiros atualizados. Entre em sua lista de e-mails, feeds RSS ou qualquer coisa para se manter atualizado com seus lançamentos.
• Audite seu próprio código. Se você não tem experiência suficiente para isso, encontre alguém que pague por isso.
• Mantenha seu site no controle de versão, como git ou subversion. Mantenha o seu diretório de produção como uma cópia de trabalho para que você possa detectar facilmente as alterações da sua base de código (mas certifique-se de bloquear o acesso a metadados como diretórios .git e .svn).

Answer 4

Você precisará encontrar a vulnerabilidade que permitiu o upload desse código.

Eu experimentei um hack semelhante e ele foi identificado como sendo enviado por uma extensão Joomla de terceiros que permite uploads de FTP.

No meu caso, eu removi a extensão do Joomla e disse ao desenvolvedor da Web para não instalá-lo novamente.

Dependendo de suas circunstâncias, você pode querer desativar eval, base64_decode e gzinflate.

Você pode fazer isso no php.ini procurando pela linha

disable_functions = 

e defina-o como

disable_functions = eval, base64_decode, gzinflate

Você precisará reiniciar o servidor da web para que as alterações entrem em vigor.

Também vale a pena mencionar que, quando eu examinei o arquivo infectado com o clamscan, ele foi identificado como malware. Estou executando o ClamAV versão 0.96.1

Eu não tenho minhas anotações agora, então não posso dizer o resultado exato.

Se for prático fazer isso, você pode agendar um trabalho para executar o clamscan em seu código em intervalos regulares (talvez por hora) para procurar futuras infecções.

    

Answer 5

Você pode tentar o link que, entre outras coisas, pode ter desativado o eval (). Se o cnfg.php fosse hospedado remotamente, poderia ter impedido que ele também fosse incluído.

Se possível, não conceda ao usuário que o servidor da Web esteja sendo executado como acesso de gravação aos arquivos php.

    

Answer 6

Aqui está um guia de seis etapas sobre como limpar o php eval (base64_decode ()) de um site WordPress e como evitar que isso ocorra novamente ?, que encontrei recentemente, e anotaram algumas coisas bem escritas que você pode querer para dar uma olhada. link

(pontos-chave do artigo sendo)

What is eval base64 decode?
What does eval base64 decode code do?
How does php eval(base64_decode works?
How to identify & get rid of eval-base64_decode like PHP virus? [Various tools to decode base64 string]
Tips for Staying Safe in the Future

Além disso, eles também mostraram um exemplo de decodificação de como um código malicioso como o eval funcionaria em um site infectado