Servidor Potencialmente Comprometido - c99madshell [duplicado]

Question

Então, eis que um site legado que hospedamos para um cliente tinha uma versão do FCKEditor que permitia que alguém enviasse o temido exploit c99madshell em nosso host.

Eu não sou um grande fã de segurança - francamente eu sou apenas um colaborador atualmente responsável pelos deveres de S / A devido a uma perda de pessoal. Consequentemente, eu adoraria qualquer ajuda que os servidores defeituosos pudessem fornecer ao avaliar o dano do exploit.

Para lhe dar um pouco de informação:

O arquivo foi enviado para um diretório dentro da webroot, "/ _img / fck_uploads / File /". O usuário e o grupo do Apache são restritos, de forma que não podem fazer login e não têm permissões fora do diretório do qual servimos sites.

Todos os arquivos tinham 770 permissões (rwx de usuário, rwx de grupo, nenhum outro) - algo que eu queria consertar, mas foi dito para adiar, já que não era "prioridade alta" (espero que isso mude isso). Então parece que os hackers poderiam facilmente ter executado o script.

Agora eu não consegui localizar o c99madshell.php em si - apenas um monte de outros arquivos HTML contendo texto russo e alguns arquivos .xl e .html com PHP embutido que eram interpretações do hack madshell. Ao fazer um pouco de pesquisa, porém, parece que o hack se destrói depois da execução - ótimo.

De qualquer forma, minha avaliação inicial seria:

• Não é necessário reconstruir todo o host, pois, dado o isolamento do usuário / grupo do apache, eles não deveriam ter sido capazes de obter senhas no nível do sistema.

• É necessário corrigir essa vulnerabilidade, restringindo o upload para não ter a permissão de execução, atualizando a versão do FCKEditor para corrigir o alvo de exploração original e adicionando configuração no nível do servidor que nega a execução do script PHP no diretório de uploads .

• Eu deveria alterar as senhas do banco de dados para o aplicativo - dado que o arquivo de configuração para a conexão com o banco de dados está dentro da raiz da web, o hacker provavelmente o pegou e com ele a senha do banco de dados.

De qualquer forma, por favor, forneça qualquer informação que você tenha sobre o que eu 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 o que vai acontecer.

Eu realmente aprecio sua ajuda pessoal. Também não hesite em pedir mais informações (eu ficaria feliz em executar comandos / trabalhar com vocês para avaliar o dano). Malditos hackers: (.

    

Answer 1

Obviamente, como outros já disseram, 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 o sistema rpm, 'rpm -Va | grep 5' verificará todos os binários instalados em rpm e reportará um "5" se a soma MD5 tiver mudado. Recompilação necessária se você encontrar alguma inconsistência não explicada por um binário personalizado.
• Procure no / tmp por algo suspeito.
• Verifique 'ps fax' para qualquer processo anormal. Se 'ps' for comprometido ou por meio de outras técnicas, você ainda pode ter processos ocultos em execução.
• Se você encontrou QUALQUER arquivo em sua pesquisa que tinha 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:

• Desativar uploads pelo FCKeditor, se possível
• Certifique-se de que seus diretórios temporários sejam feitos NOEXEC para impedir que programas sejam executados fora deles
• Qualquer script php deve estar atualizado
• Se você quiser instalar o fancy mod_security para procurar exploits durante o tempo de execução dos scripts php

Há uma tonelada de 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 estar certo em verificar as opções acima. / p>     

Answer 2

Você precisa reconstruir o host. Você não sabe que tipo de ataque de escalonamento de privilégios eles usaram contra o host, nem pode ter absoluta certeza de que não há trojans, keyloggers ou rootkits instalados.

Depois de ficar comprometido, não há outra opção além de uma reconstrução a partir do zero.

    

Answer 3

Resumindo - eu reconstruiria o servidor.

Se eles tiverem acesso a um usuário local (agora eles tinham acesso como usuário do apache), eles podem executar explorações locais. Então você deve considerar que todo o servidor está comprometido. Você deve verificar outros servidores também.

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 o rpm -V para verificar os pacotes.

    

Answer 4

Primeiro de tudo. NUNCA CONFIE EM UM SERVIDOR COMPROMETIDO.

Mesmo que você pense que você protegeu a máquina, os script kiddies não são estúpidos, as chances são de que em algum lugar haja um backdoor instalado. Usuário / Grupo faz pouca diferença depois que você ganhou shell.

Faça backup de seus arquivos, implemente uma alteração de TODAS as senhas.

    

Answer 5

Sei que não é o que você prefere ouvir, mas eu realmente recomendo fazer o backup dos dados, reconstruir o servidor e reimportar todos os dados.

Não se esqueça de verificar através de outros sites para garantir que este não é o único afetado pelo hack. Se todos os scripts do seu servidor estiverem executando como um usuário do Apache ( nodoby / www_data / what-ever-your-distro-uses), qualquer coisa que possa gravar em um site pode quase certamente também ser escrita para o resto.

Além de alterar todas as senhas, certifique-se de que quaisquer 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 excluir apenas a chave privada) e que quaisquer outros sistemas você pode ter digitado uma senha para (ou armazenou uma senha em um arquivo) no / por esse servidor com as senhas alteradas.