Tentativa de invadir o VPS, como proteger no futuro, o que eles estavam tentando fazer? [duplicado]

Question

UPDATE: Eles ainda estão aqui. Ajude-me a parar ou prendê-los!

Oi SF's,

Acabei de hackear um dos sites dos meus clientes. Eles conseguiram alterar um arquivo para que a página de check-out do site registrasse as informações de pagamento em um arquivo de texto.

Felizmente ou infelizmente, eles tiveram um erro de digitação no código, que quebrou o site, então eu fiquei sabendo imediatamente.

Eu tenho uma ideia de como eles conseguiram fazer isso:

Meu site CMS tem uma área de upload de arquivos onde você pode fazer upload de imagens e arquivos para serem usados no site. Os uploads são limitados a 2 pastas. Eu encontrei dois arquivos suspeitos nessas pastas e ao examinar o conteúdo, parece que esses arquivos permitem que o hacker visualize o sistema de arquivos do servidor e carregue seus próprios arquivos, modifique arquivos e até mesmo altere as chaves do registro!

Eu deletei alguns arquivos e mudei as senhas e estou tentando proteger o CMS e limitar os uploads de arquivos pelas extensões.

Qualquer outra coisa que vocês podem sugerir que eu faça para tentar descobrir mais detalhes sobre como eles entraram e o que mais eu posso fazer para evitar isso no futuro?

    

Answer 1

Se o seu site (do cliente) já tiver sido comprometido, primeiro você deverá colocá-lo off-line. Você não tem como provar facilmente que o hacker não instalou um rootkit. Você deve presumir que todos os dados desse serviço foram comprometidos e potencialmente perdidos. Por sua causa, espero que você não esteja armazenando dados de cartão de crédito ou outros dados de pagamento em um banco de dados SQL não criptografados ou armazenando-os criptografados com a chave em algum lugar no mesmo sistema.

Então você tem que reconstruí-lo a partir de uma boa imagem conhecida e restaurar a partir do último backup válido conhecido. Essa é a única maneira de ter certeza. Nuke de órbita.

Até onde descobrir como eles entraram em seu sistema, dê uma olhada nos logs de eventos para quando as pessoas logadas, e possivelmente os logs de auditoria também, podem dizer se eles executaram algum código da área de upload. Isso servirá como uma boa experiência de aprendizado para você, especialmente quando se trata de permissões executáveis em áreas publicamente acessíveis do site, bem como auditoria e registro em log.

Sua primeira prioridade deve ser reconstruir o site em um servidor bom e protegido e proteger mais o site original.

Você pode encontrar este " Recuperando de um sistema comprometido " uma leitura interessante.

A resposta aclamada de RobertMoir a esta pergunta também pode ajudá-lo.

    

Answer 2

My website CMS has a File upload area where you can upload images and files to be used within the website. The uploads are limited to 2 folders. I found two suspicious files in these folders and on examining the contents it looks like these files allow the hacker to view the server's filesystem and upload their own files, modify files and even change registry keys?!

É por essa razão que as áreas de upload de arquivos são extremamente perigosas. Você precisa dar grandes passos para garantir que o conteúdo carregado não possa ser reutilizado como parte de uma tentativa de invasão. Se você bloquear o conteúdo executável, um script vulnerável ao XSS em algum outro lugar do site poderá chamar esse código e executá-lo em seu próprio contexto , que é executável.

Eles entraram fazendo upload de algo que poderiam executar posteriormente. Talvez o tenham chamado diretamente, caso em que você precisa garantir que apenas conteúdo não executável possa ser carregado nesses diretórios. Talvez tenham sido invocados a partir de algum outro script, descobrindo que isso exigirá que você vasculhe os arquivos de log para ver qual script invocou os arquivos identificados e, em seguida, proteja o script.

Depois de reconstruir seu servidor, examine melhor esses buracos e reavalie a necessidade dos diretórios de upload.

    

Answer 3

Se você estiver executando o asp.net e apenas como você marcou no SO, você só precisará adicionar este web.config no diretório raiz para o qual seus usuários carregam arquivos. Com esse web.config você não permite que ninguém execute páginas aspx nessa árvore de diretórios.

<configuration>
    <system.web>
      <authorization>
        <deny users="*" />
      </authorization>
    </system.web>
</configuration>

    

Answer 4

O mais importante é garantir que, se você tiver alguma área de upload, essas áreas serão impedidas de ter arquivos executáveis dentro delas.

Se a área for acessível pela web e os uploads puderem ser qualquer coisa - tudo o que eles precisam fazer é enviar um script aspx / php / etc para esse local e navegar até ele para ativá-lo.

Evite isso por:

• renomeando arquivos no upload
• verificar o tipo de arquivo por conteúdo antes de movê-lo para o local
• configure seu servidor da Web para não permitir que scripts sejam executados nesse local
• se o local de envio não precisar ser acessível pela web, mova-o para fora

Se eles tiverem acesso no momento, especialmente se tiverem por algum tempo, com um software personalizado que você talvez não encontre com verificadores de vírus, garanta que você tenha uma cópia limpa do código que eles não tiveram acesso em outro lugar; em seguida, reconstrua o servidor. Sim, provavelmente é totalmente desnecessário se eles tivessem acesso limitado, mas se você não sabe, não se arrisque.

Sim, obviamente, mude todas senhas em todos os lugares. Se o seu site tiver contas que tenham um banco de dados de senhas legível, essas duas. Se o seu site hospeda dados pessoais de usuários, você provavelmente precisará informá-los e possivelmente às autoridades, dependendo de sua legislação nacional.

    

Answer 5

No log do IIS, você deve ser capaz de descobrir quando os arquivos foram enviados e de qual endereço IP eles vieram

    

Answer 6

O mais importante é garantir que, se você tiver alguma área de upload, essas áreas serão impedidas de ter arquivos executáveis dentro delas.

Se a área for acessível pela web e os uploads puderem ser qualquer coisa - tudo o que eles precisam fazer é enviar um script aspx / php / etc para esse local e navegar até ele para ativá-lo.

Evite isso por:

• renomeando arquivos no upload
• verificar o tipo de arquivo por conteúdo antes de movê-lo para o local
• configure seu servidor da Web para não permitir que scripts sejam executados nesse local
• se o local de envio não precisar ser acessível pela web, mova-o para fora