Como os websites são realmente comprometidos, e como não ser o alvo fácil.
Em segurança, a causa presumida é normalmente «não há nada de errado». Eis como os websites são realmente comprometidos, porque o topo dessa lista é evitável, e como se prova de fora que uma correção fechou a porta.
Neste artigo 4 secções
- Em segurança, a causa presumida é «não há nada de errado». A maioria das pessoas não sabe que foi comprometida.
- A nossa monitorização e os feeds de threat intelligence estão ligados de forma a abrir o ticket, pelo que a primeira mensagem é normalmente nossa. Apanhá-lo primeiro é o trabalho.
- Os websites são comprometidos de formas aborrecidas. Software desatualizado e coisas deixadas abertas sem querer lideram a lista, e ambas são exatamente o que uma auditoria antes do go-live e o patching contínuo apanham.
- Encontrar a intrusão é só metade. Quando fechamos uma, provamos que a porta está fechada voltando a atacar a partir de um endereço em que não confiamos. Se ainda lá conseguimos chegar, não está corrigido.
Há um sinal em todas as chamadas de segurança. A causa presumida pelo cliente é normalmente a pior que existe: não há nada de errado. Não ligaram porque algo parecia estranho. Ligaram porque nós lhes dissemos. Quando uma intrusão se torna visível para a pessoa que é dona do website, normalmente já aconteceu.
Em segurança, a causa presumida é «não há nada de errado»
“quote: Em segurança, a causa presumida pelo cliente é normalmente «não há nada de errado». Não sabiam que tinham sido comprometidos. attribution: EUROVPS SECURITY”
Essa é toda a diferença. Não que as intrusões não aconteçam. Acontecem, em todas as plataformas, a todo o tipo de websites. A diferença é quem as vê primeiro: uma camada de deteção atenta às assinaturas de um comprometimento, ou um feed de threat intelligence a assinalar tráfego que não devia existir, enquanto o painel do próprio website continua a mostrar verde. A nossa monitorização e esses feeds estão ligados de forma a abrir o ticket, e é por isso que a primeira mensagem é normalmente nossa.
Como os websites são realmente comprometidos
Retire a versão de cinema e as formas como os websites são realmente comprometidos são aborrecidas, e repetem-se. Eis a classificação, da mais comum para a menos. Nada no topo desta lista é inteligente.
Software desatualizado ou em fim de vida
A forma de entrada mais comum, por larga margem. Uma aplicação com uma vulnerabilidade publicamente conhecida, exposta à internet, anos atrasada nos patches. Exposta à internet e anos atrasada nos patches é tudo o que é preciso. O exploit está pronto na prateleira. Não é precisa inteligência.
Algo deixado aberto sem querer
Não é preciso exploit. A porta estava simplesmente aberta. Uma base de dados ligada a todas as interfaces de rede sem autenticação. Um ficheiro de configuração ou de debug legível por todos. Um CMS a deixar fugir os seus nomes de utilizador por uma API aberta. Um subdomínio de staging esquecido que ainda responde. Ninguém arrombou. Entraram a pé.
O origin alcançável por trás do CDN
O website está atrás de um CDN, mas o servidor real continua a responder diretamente se alguém o conseguir encontrar, e o seu endereço está muitas vezes no DNS de correio do próprio domínio. A porta da frente está guardada enquanto a porta das traseiras está escorada aberta.
Brute force de credenciais sem defesa de Layer 7
Uma página de login sem nada à frente na camada de aplicação, martelada até algo ceder. Uma firewall de Layer 3/4 deixa isto passar sem olhar: para um filtro de portas, parece tráfego normal para uma porta que tem de ficar aberta.
Credenciais fracas, reutilizadas ou expostas sem MFA
Uma palavra-passe que fugiu noutro lado, reutilizada aqui, sem um segundo fator que a torne inútil. A fechadura estava boa. A chave já tinha sido copiada.
Spam de saída a partir de uma conta já comprometida
Muitas vezes o primeiro sinal exterior de uma intrusão que já aconteceu. A conta não é o alvo. É a rampa de lançamento, e o spam é o fumo, não o fogo.
Phishing e engenharia social
A camada humana. Nenhum bug de software envolvido. Alguém foi simplesmente convencido a entregar as chaves.
Olhe para os dois primeiros. Software desatualizado e coisas deixadas abertas sem querer. Nenhum dos dois é um ataque inteligente. Ambos são exatamente o que uma auditoria disciplinada antes do go-live e o patching contínuo apanham antes de alguém experimentar o puxador. Esse é todo o argumento a favor da managed security. A maioria dos arrombamentos não é arrombamento. É entrada a pé. E a entrada a pé é evitável.
Apanhá-lo primeiro é o trabalho. Provar que está fechado é a diferença.
Encontrar a intrusão é metade do trabalho. A metade que quase ninguém faz é provar que a correção realmente se manteve. Quando fechamos um comprometimento, não aceitamos a palavra do painel de que a porta está fechada. Voltamos a atacar o origin como um atacante o faria: a partir de uma máquina noutro dos nossos datacenters, num egress em que a firewall nunca foi mandada confiar. Se o nosso próprio scanner ainda lá consegue chegar, não está corrigido. Só quando a porta está fechada vista de fora, a partir de um endereço em que não confiamos, é que a declaramos fechada.
“quote: O trabalho não é só corrigir a intrusão. É apanhá-la primeiro, e depois provar de fora que a porta está fechada. attribution: EUROVPS SECURITY”
Esse método, voltar a atacar o próprio origin a partir de um ponto não confiável e confirmar o que um atacante veria de facto, é uma disciplina própria e tem artigo próprio. Provamos de fora que está fechado percorre o playbook completo.
Sete formas de não ser o alvo fácil
Nada no topo daquela classificação precisa de um atacante genial. O que significa que a maior parte é evitável por não se ser o alvo fácil. Sete hábitos, pela ordem em que compensam.
Corrigir ou retirar
Se está exposto à internet e sem manutenção, é uma responsabilidade. Atualize-o ou tire-o do ar. Não há uma terceira opção que acabe bem.
Assuma que o origin vai ser encontrado
Tranque-o aos intervalos de IP do CDN para que só o CDN o consiga alcançar, e pare de deixar fugir o seu endereço no DNS de correio. Um origin escondido não está escondido se o seu próprio DNS o anuncia.
Uma firewall L3/4 não é uma WAF
A filtragem de portas não lê pedidos. Brute force, injection e abuso na camada de aplicação passam todos por portas que tem de deixar abertas. Precisa de uma defesa que inspecione o Layer 7.
Audite antes de declarar terminado
«Funciona» não é «está fechado». Verifique o que está exposto, o que é legível por todos, o que ainda está ligado à internet pública, antes do go-live, não depois de chegar o aviso.
Assuma que as credenciais fogem. Torne-as inúteis fora da whitelist.
MFA em todo o lado, e amarre os caminhos sensíveis a endereços conhecidos. Uma palavra-passe roubada não deve abrir nada por si só.
Vigie o vigilante
Monitorização que fica cega e continua a reportar verde é pior do que nenhuma monitorização, porque compra uma falsa calma. Confirme que o detetor consegue realmente ver.
Prove a correção de fora
O único teste que conta é a perspetiva do atacante. Volte a atacar a partir de um endereço em que não confia e confirme que a porta está fechada.
Respostas diretas
Como é que os websites são realmente atacados em managed hosting?+
Sobretudo de duas formas aborrecidas. Software desatualizado ou em fim de vida com uma vulnerabilidade publicamente conhecida, exposto à internet, e coisas deixadas abertas sem querer: uma base de dados sem autenticação, um ficheiro de configuração legível por todos, um subdomínio de staging esquecido. Os exploits inteligentes estão muito mais abaixo na lista. A maioria dos arrombamentos é entrada a pé.
Como é que eu saberia sequer se o meu website foi comprometido?+
Muitas vezes não saberia, e é esse o ponto. A nossa monitorização e os feeds de threat intelligence estão ligados de forma a abrir o ticket, pelo que a primeira mensagem sobre um comprometimento é normalmente nossa. A causa presumida do lado do cliente é normalmente «não há nada de errado». Spam de saída ou um aviso de terceiros é frequentemente o primeiro sinal exterior, e nessa altura já aconteceu.
O meu servidor está seguro se tiver uma firewall?+
Uma firewall de Layer 3/4 filtra portas. Não lê pedidos. Brute force de credenciais, injection e abuso na camada de aplicação viajam todos por portas que tem de deixar abertas, pelo que para ela parecem tráfego normal. Uma firewall não é uma WAF. Travar isso exige uma defesa que inspecione o Layer 7.
Os atacantes conseguem encontrar o meu servidor origin se estiver atrás de um CDN?+
Frequentemente, sim. O CDN só ajuda se o origin não puder ser alcançado diretamente, e o endereço real do origin foge muitas vezes no DNS de correio do próprio domínio. Tranque o origin aos intervalos de IP do CDN e pare de o anunciar no DNS, ou a porta da frente guardada tem a porta das traseiras escorada aberta.
Em managed hosting, quem é responsável pelo patching das minhas aplicações?+
A plataforma e a aplicação são trabalhos diferentes, e o intervalo entre elas é onde os websites são comprometidos. Nós mantemos a plataforma reforçada e auditamos antes do go-live. Mas uma aplicação em fim de vida com uma vulnerabilidade conhecida é um risco partilhado. O valor do managed é que uma auditoria disciplinada antes do go-live e o patching contínuo apanham a maior parte antes de alguém experimentar o puxador.
Não tem a certeza do que está exposto? Pergunte antes que outra pessoa descubra.
Traga-o a um engenheiro, não a uma fila de tickets. Verificamos o que é alcançável de fora, dizemos-lhe com clareza o que fechar, e depois provamos que está fechado.
Fale com um engenheiroChegou ao fim.
Ponha a leitura em prática
O que executa?
Fale-nos da carga de trabalho, do tráfego e dos requisitos de recuperação. Comece pelo configurador de servidores ou discuta os detalhes com um engenheiro.
Escrito pelos engenheiros que constroem e operam a infraestrutura que descreve.Fale com um engenheiro