foi hackeado. Quer entender como

Question

Alguém, pela segunda vez, adicionou um pedaço de javascript em um site que eu ajudo a executar. Este javascript intercepta o Google adsense, inserindo seu próprio número de conta e exibindo todos os anúncios.

O código é sempre anexado, sempre em um diretório específico (um usado por um programa de anúncios de terceiros), afeta vários arquivos em vários diretórios dentro desse diretório de um anúncio (20 ou mais) e é inserido a aproximadamente o mesmo tempo durante a noite. A conta do adsense pertence a um site chinês (localizado em uma cidade que não fica a uma hora de onde eu estarei na China no próximo mês. Talvez eu deva ir à procura de cabeças ... brincando, mais ou menos), aqui está a informação sobre o site: link

Então, como eles poderiam acrescentar texto a esses arquivos? Está relacionado às permissões definidas nos arquivos (variando de 755 a 644)? Para o usuário do servidor web (está no MediaTemple, então deve ser seguro, sim?)? Quero dizer, se você tem um arquivo que tem permissões definidas para 777 eu ainda não posso simplesmente adicionar código a ele à vontade ... como eles podem estar fazendo isso?

Aqui está uma amostra do código real para o seu prazer de visualização (e como você pode ver ... não muito para ele. O verdadeiro truque é como eles conseguiram chegar lá):

<script type="text/javascript"><!--
google_ad_client = "pub-5465156513898836";
/* 728x90_as */
google_ad_slot = "4840387765";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>

Desdequeumnúmerodepessoasmencionou,aquiestáoqueeuverifiquei(eporchecagem,euolheiotempoemqueosarquivosforammodificadosparaqualquerestranhezaeeuuseiosarquivosparainstruçõesPOSTetravessiasdediretórios:

• access_log(nadaaoredordotempo,excetotráfegomsnbotnormal(ouseja,excessivo))
• error_log(nadaalémdoarquivousualnãoexisteerrosparaarquivosdeaparênciainócua)
• ssl_log(nadaalémdousual)
• messages_log(semacessoaoFTPaqui,excetoparamim)

*UPDATE:**OK,resolvido.HackersdaChinafisicamentecolocaramumarquivoemnossositequepermitequeelesfaçamtodotipodecoisasadministrativas(acessoaobancodedados,exclusãoecriaçãodearquivosediretórios,onomedele,elestinhamacesso).Nóstivemossortequeelesnãofizeramalgomaisdestrutivo.Nãohavianadanosarquivosnormaisdelogdoapache,masencontreiumconjuntodiferentedearquivosdelogemumanalisadordelogdoservidordaWebeaevidênciaestavalá.Elesestavamacessandoessearquivocomseupróprionomedeusuárioesenhadeadministradore,emseguida,editandooquequerqueprecisassemalimesmonoservidor.Seuarquivotem"apache" definido como o usuário, enquanto todos os outros arquivos em nosso site têm um nome de usuário diferente. Agora preciso descobrir como eles fisicamente colocaram esse arquivo em nosso sistema. Eu suspeito culpa por isso acabará por descansar com o nosso host (Media Temple), a menos que eles realmente tinham o nosso login FTP ... não sei como vou determinar isso, no entanto, como este arquivo provavelmente já esteve lá por um tempo.

    

Answer 1

Primeiro de tudo chmod 744 NÃO é o que você quer. O objetivo do chmod é revogar o acesso a outras contas no sistema. Chmod 700 é muito mais seguro que chmod 744 . No entanto, o Apache só precisa do bit de execução para executar seu aplicativo php.

chmod 500 -R /your/webroot/

chown www-data:www-data -R /your/webroot/

www-data é comumente usado como a conta do Apache que é usada para executar o php. Você também pode executar este comando para ver a conta do usuário:

'<?php
print system("whoami");
?>'

O FTP é horrivelmente inseguro e é muito provável que você tenha sido hackeado por esse método. Usando o FTP, você pode tornar os arquivos graváveis e, em seguida, infectá-los novamente. Certifique-se de executar um antivírus em todas as máquinas com acesso FTP. Há vírus que detectam o tráfego local para nomes de usuário e senhas de FTP e, em seguida, fazem login e infectam os arquivos. Se você se preocupa com segurança, você usa o SFTP, que criptografa tudo. Enviar código-fonte e senhas pelo fio em texto não criptografado é uma loucura total.

Outra possibilidade é que você esteja usando uma biblioteca ou aplicativo antigo. Visite o site do fornecedor de software e verifique se você está executando a versão mais recente.

    

Answer 2

Minhas contas do Temple Grid Server de mídia foram "hackeadas" assim várias vezes. A segurança deles é muito ruim ... começou com TEXTO SIMPLES PASSWORDS no ano passado e continua até hoje (você pode ligar para o suporte técnico e eles dizem "qual é a sua senha?"). Eu sei porque recebo e-mails mensais sobre como eles mudaram todas as senhas da minha conta e eles realmente entram e trocam senhas de banco de dados toda vez que são hackeados. Essa empresa parece brilhante como o inferno na superfície, mas o servidor de rede está uma bagunça. Eu recomendo trocar imediatamente .

Por favor, veja este post do ano passado sobre o fiasco original (aviso, vai te chatear). Desceu a partir daí. Eu passei agradecimento no ano passado longe da minha família e removi links pornôs dos meus sites. Linda.

Acompanhe a diversão em sua página de status : ela informará tudo sobre a explorações mais recentes (e, sim, de fato, há uma "possível exploração" no momento).

    

Answer 3

Com base na falta de atividade nos logs de acesso, etc., e o fato de que isso está ocorrendo aproximadamente ao mesmo tempo, parece que eles comprometeram o servidor e possuem algum tipo de script de shell para executar o anexo.

Você verificou crontab para algo estranho?

Você tentou renomear o diretório e as referências a ele (isso pode quebrar o script de shell)?

    

Answer 4

Sim, definitivamente pode estar relacionado às permissões de arquivo. Com arquivos que podem ser gravados pelo processo da web, você está aberto a qualquer vulnerabilidade de segurança nos aplicativos da web que estiver executando. Bloqueie tudo para que o processo da Web não possa ler ou escrever nada mais do que o necessário.

O outro componente está rastreando exatamente como eles estão modificando seus arquivos. Verificar os registros de acesso do servidor da web é um bom lugar para começar. Verifique os últimos tempos de login para vários usuários. Você também pode configurar um script que monitore os arquivos para modificação e notifica você para que você possa tentar capturar os criminosos em flagrante!

    

Answer 5

Isso soa muito familiar para os hacks Wordpress que atingiram uma enorme quantidade de redes Sites de soluções recentemente. Como você está no Media Temple, é possível que você tenha deixado alguns arquivos visíveis para outros usuários que compartilham sua máquina. Isso explicaria a falta de traços de log do POST ou do eery Apache. Se for esse o caso, seria extremamente simples injetar código na linha de comando.

    

Answer 6

The code is always appended, always in one specific directory

Is it related to the permissions set on the files (ranging from 755 to 644)? To the webserver user

Você está em um servidor compartilhado? Em caso afirmativo (ou até mesmo se não), alguém pode ter forçado brute uma senha de FTP e fez o upload de um script que anexou todos os arquivos em que ele pudesse colocar suas mãos.

one used by a third party ad program

Ou talvez este programa tenha uma exploração.

    

Answer 7

Se você tiver acesso apropriado (e suporte ao kernel), pode tentar ativar um daemon de monitoramento baseado em inotify ou dnotify para observar as alterações em seus arquivos e, em seguida, (rapidamente) use "lsof" para ver qual processo tem o arquivo aberto com acesso de gravação. Você também pode usar strace para monitoramento. Isso deve fornecer uma pista sobre qual executável está sendo explorado.

    

Answer 8

Os registros de inspeção de FTP são o primeiro lugar para começar. O log deve conter a maioria das atividades, se não todas, juntamente com os registros de data e hora, portanto, se você souber a que horas seus arquivos foram modificados, poderá determinar se sua conta FTP está comprometida ou não.

Em seguida, pode ser um script em seu servidor da web que está injetando esse código. Em um cenário de hospedagem compartilhada, acho que é possível fazer um cat /web/malicious.com/script.js >> /web/innocent.com/index.php . Isso pode funcionar sob certas condições, como o comando que está sendo executado pelo usuário httpd e o arquivo index.php também é de propriedade / gravável por esse usuário. Nesse caso, você deve ter seu provedor de hospedagem para rastrear a conta que está sendo usada para injetar os scripts.

    

Answer 9

A maioria dos arquivos de sites precisa ser lida pelo servidor da web. Em um site somente leitura, somente os registros precisam ser graváveis pelo servidor da web. defina o proprietário para alguém que não seja o usado pelo servidor da web. Definir proteção 640 em todos os arquivos, exceto scripts. Definir scripts e diretórios 750. Para arquivos ou diretórios que precisam ser gravados pelo websever, você pode alterar o proprietário para o servidor da web ou definir o chmod g + 2 para os arquivos ou diretórios relevantes.

    

Answer 10

Há um zilhão de maneiras possíveis de invadir um site. Eles poderiam ter usado uma vulnerabilidade em seu script, roubado sua senha, usado uma vulnerabilidade de um site co-hospedado (se você estiver em um host barato), usado uma vulnerabilidade de algum serviço não relacionado à web na máquina do servidor. .

Como primeiro passo, verifique a data de modificação do arquivo e verifique os registros de acesso, erro e FTP para qualquer atividade suspeita naquele momento.

    

Answer 11

A mesma coisa aconteceu comigo há um tempo atrás. O Wordpress foi o único software que teria causado algo assim até onde eu sei.