Proprietário e permissões em um arquivo invadido versus em um arquivo “legal”

Question

Isso está relacionado a um incidente de hackers com o qual tivemos de lidar. Os hackers inseriram um arquivo php em nosso sistema. O diretório em questão recebe uploads (imagens) do nosso cmsadmin. No entanto, todos os arquivos enviados através do nosso cmsadmin têm o mesmo proprietário e permissões ( owner: theadminsname, permissions: 777 ). O arquivo inserido ilegalmente, por outro lado, possui owner: apache, permissions: 644

Minha pergunta: Essa diferença no proprietário e nas permissões fornece alguma pista de como o arquivo foi inserido? Se eles tivessem feito o upload do arquivo através do nosso cmsadmin, ele não teria o mesmo dono e permissões de outros arquivos enviados? O fato de o proprietário ser o apache indica uma rota diferente ou simplesmente a alterou, porque esse é o nome do proprietário do apache tão comum?

Outra coisa. O arquivo inserido foi colocado em uma seção do nosso cms personalizado. Em seguida, ele forneceu um formulário para os hackers fazerem alterações nos arquivos em um programa de publicidade de terceiros (entre outras coisas). Parece estranho que eles façam upload de um arquivo em nosso cmsadmin personalizado (localizado em uma estrutura de diretórios completamente diferente do sistema de anúncios e sem interoperabilidade entre os dois) e, em seguida, usá-lo para manipular esse programa de anúncios de terceiros. O cmsadmin e o administrador do programa de publicidade estão em diretórios diferentes e não estão conectados, de forma programática, de nenhuma maneira. Isso tudo me faz suspeitar que o ataque foi conduzido não através de uma fraqueza em nosso cmsadmin ou no sistema de anúncios, mas através de uma fraqueza no serviço de hospedagem.

O que vocês acham?

    

Answer 1

Certamente, o arquivo parece ter sido enviado por meio do código em execução no servidor da Web. No entanto, garantir que o conteúdo enviado seja

1) mantido separado do resto do site

2) armazenado em um local que é explicitamente configurado para impedir a execução

é um princípio de segurança muito básico e fundamental: a culpa é sua de ter sido hackeado.

Does the fact that the owner is apache indicate a different route in or did they just change it to that because that is such a common apache owner name?

Provavelmente - qual sistema operacional é esse? Você só pode colocar um arquivo no Unix se você for root - isso implica se eles não o fizeram através do servidor da web, então eles têm acesso root - e se eles têm root por que deixar uma trilha tão bagunçada? / p>

The cmsadmin and advertising program admin are in different directories

Então o que? A menos que eles estejam em servidores diferentes, eles podem interagir (mesmo em servidores separados).

C.

    

Answer 2

É realmente difícil dizer qualquer coisa com as informações que você nos forneceu sem saber a configuração em detalhes. Existem tantas possibilidades, que o melhor que podemos fazer é adivinhar.

A melhor coisa que você pode fazer é tentar entender o que aconteceu. Analise os arquivos de log e veja se há algum rastreio do que aconteceu. Como você mencionou, não parece ser o trabalho de um profissional, mas sim algumas crianças de script aleatórias ou até mesmo alguns verificadores automáticos de vulnerabilidades.

Depois de descobrir o que você quer, o melhor é formatar o disco e reinstalar tudo.

Para o futuro, bem, existem coisas que você pode implementar (mais ou menos facilmente), como sistemas de detecção de intrusão como AIDE / tripwire, syslog remoto, regras de firewall mais rígidas (filtrar entrada e saída), melhor registro / trilha de auditoria e alertar, auditoria manual regular e uma revisão das práticas recomendadas e usar um scanner de vulnerabilidade (como o Nessus). Mas se você é paranóico, há mais, muito mais - testes de penetração, DMZ, redes segregadas, ACLs de rede, tokens de segurança RSA, SELinux / AppArour, ... Você entendeu. Cabe a você onde parar.

Muitas coisas, eu sei. A segurança é difícil.