Então, vejam só, um site legado que hospedamos para um cliente tinha uma versão do FCKEditor que permitia que alguém carregasse o temido exploit c99madshell em nosso host.
Não sou um grande fã de segurança - francamente, sou apenas um desenvolvedor atualmente responsável pelas tarefas de S/A devido a perda de pessoal. Conseqüentemente, eu adoraria qualquer ajuda que vocês que falharam no servidor pudessem fornecer para avaliar os danos causados pela exploração.
Para lhe dar um pouco de informação:
O arquivo foi carregado em um diretório dentro do webroot, "/_img/fck_uploads/File/". O usuário e o grupo Apache são restritos de forma que não podem fazer login e não têm permissões fora do diretório a partir do qual atendemos os sites.
Todos os arquivos tinham 770 permissões (usuário rwx, grupo rwx, outro nenhum) - algo que eu queria consertar, mas fui instruído a esperar, pois não era "alta prioridade" (espero que isso mude isso). Parece que os hackers poderiam facilmente ter executado o script.
Agora não consegui localizar o próprio c99madshell.php - apenas um monte de outros arquivos HTML contendo texto em russo e alguns arquivos .xl e .html com PHP embutido que eram versões do hack madshell. Porém, ao fazer um pouco de pesquisa, parece que o hack se destrói após a execução – ótimo.
De qualquer forma, minha avaliação inicial seria esta:
Não é necessário reconstruir todo o host, pois devido ao isolamento do usuário/grupo do Apache, eles não deveriam ter conseguido obter senhas no nível do sistema.
É necessário corrigir esta vulnerabilidade restringindo uploads para não terem permissão de execução, atualizando a versão do FCKEditor para corrigir o alvo de exploração original e adicionando configuração em nível de servidor que nega a execução de script PHP dentro do diretório de uploads.
Eu deveria alterar as senhas do banco de dados do aplicativo - dado que o arquivo de configuração da conexão do banco de dados está na raiz da web, o hacker provavelmente poderia tê-lo capturado e com ele a senha do banco de dados.
De qualquer forma, por favor, forneçam qualquer opinião que vocês tenham sobre o que devo dizer ao chefe. Obviamente, seria ideal evitar a reconstrução de todo o host - mas se isso é o que precisamos fazer para garantir que não estamos executando uma máquina hackeada, então é isso que será necessário.
Eu realmente aprecio a ajuda de vocês. Também não hesite em pedir mais informações (ficarei feliz em executar comandos/trabalhar com vocês para avaliar os danos). Malditos hackers :(.
Responder1
Obviamente, como já foi dito, a resposta oficial "segura" seria reconstruir a máquina.
A realidade da situação pode impedir isso. Você pode executar algumas coisas para verificar se há comprometimentos:
- Chkrootkit- testes para sinais comuns de comprometimento do servidor
- Se for um sistema rpm, 'rpm -Va|grep 5' verificará todos os binários rpm instalados e reportará um "5" se a soma MD5 tiver sido alterada. A reconstrução é necessária se você encontrou alguma inconsistência não explicada no binário customizado.
- Procure em /tmp por algo suspeito.
- Verifique 'ps fax' para quaisquer processos anormais. Se o 'ps' estiver comprometido ou por meio de outras técnicas, você ainda poderá ter processos ocultos em execução.
- Se você encontrou QUALQUER arquivo em sua pesquisa que tivesse propriedade diferente do Apache, suas contas do sistema foram definitivamente comprometidas e você precisa de uma reconstrução.
Correções a serem feitas na configuração do seu sistema:
- Desative uploads pelo FCKeditor, se possível
- Certifique-se de que seus diretórios temporários sejam NOEXEC para evitar que programas sejam executados a partir deles
- Qualquer script php deve estar atualizado
- Se você quiser uma instalação sofisticada do mod_security para procurar explorações durante o tempo de execução dos scripts php
Há muitas coisas que estou perdendo, mas esses seriam os primeiros passos que eu daria. Dependendo do que você está executando no servidor e da importância da segurança dele (você lida com transações CC?), uma reconstrução pode ser necessária, mas se for um servidor de 'baixa segurança', você pode verificar o acima.
Responder2
Você precisa reconstruir o host. Você não sabe que tipo de ataques de escalonamento de privilégios eles usaram contra o host, nem pode ter certeza absoluta de que não há trojans, keyloggers ou rootkits instalados.
Uma vez comprometido, não há outra opção além de reconstruir a partir do zero.
Responder3
Resumindo - eu reconstruiria o servidor.
Se eles tiverem acesso a um usuário local (agora eles tinham acesso como usuário Apache), eles poderão executar explorações locais. Portanto, você deve considerar que todo o servidor está comprometido. Você também deve verificar outros servidores.
Qual distribuição você está executando? Se for baseado em rpm você pode verificar as assinaturas dos arquivos. Inicialize o CD de instalação e execute rpm -V para verificar os pacotes.
Responder4
Sei que não é o que você gostaria de ouvir, mas eu realmente recomendaria fazer backup dos dados, reconstruir o servidor e reimportar todos os dados.
Certifique-se também de verificar outros sites para garantir que este não seja o único afetado pelo hack. Se todos os scripts do seu servidor estiverem sendo executados como um usuário Apache ( nodoby/ www_data/o que quer que sua distribuição use), qualquer coisa que possa gravar em um site quase certamente também poderá gravar no restante.
Além de alterar todas as senhas, certifique-se de que todas as chaves SSH no servidor sejam invalidadas em todos os outros servidores (ou seja, revogue as chaves públicas onde quer que estejam armazenadas, em vez de apenas excluir a chave privada) e que quaisquer outros sistemas que você possa ter inseriu uma senha (ou armazenou uma senha em um arquivo) naquele servidor e por meio desse servidor e as senhas foram alteradas.