Leia sobre dicas e funcionalidades da GoCache CDN para melhorar a seguranca do seu site, loja virtual ou app mobile.

Falsos Positivos em Cyber Security

/em

Imagine que você alertou sua equipe de TI sobre um erro crítico de infraestrutura que prejudica sua rede. Neste momento, você solicita que eles abandonem seu trabalho atual e se concentrem na correção imediata dessa vulnerabilidade detectada. Após uma investigação mais aprofundada, no entanto, descobriu-se que era um falso positivo.

Infelizmente, esses incidentes são comuns e custam tempo e mão de obra valiosos à sua organização. Mais preocupante ainda, eles desviam a atenção de questões legítimas de segurança.

É evidente que esta questão frustrante e crítica deve ser abordada. Neste artigo, exploraremos um pouco mais o que são Falsos Positivos em Cyber Security, abordando pontos importantes que devem ser analisados para que você possa restringir o foco de sua equipe para que eles possam identificar e responder às ameaças mais importantes.

O que é um alerta de falso positivo?

Um falso positivo na segurança cibernética refere-se a um alerta ou vulnerabilidade que foi sinalizado incorretamente, geralmente causado por um comportamento imprevisível desencadeado por um caso de teste. As imprecisões na resposta podem fazer com que as ferramentas de segurança destaquem uma falha onde na realidade, nenhuma está presente. Um exemplo disso seria um servidor web demorando 20ms a mais para responder, e o scanner acreditando que um teste de injeção de SQL baseado em tempo foi executado com sucesso.

Por que os falsos positivos são importantes na segurança cibernética?

Como vimos, os falsos positivos podem ter um impacto significativo na segurança cibernética. Eles podem enganar as equipes de segurança e desperdiçar tempo e recursos que poderiam ser melhor gastos na identificação e resposta a ameaças reais. Um estudo descobriu que 80% dos entrevistados afirmaram gastar muito tempo resolvendo alertas falsos positivos de seus sistemas de segurança. O relatório indicou uma tendência preocupante: 47% dos profissionais de segurança alegaram ter ignorado 50% ou mais desses avisos.

Os falsos positivos são especialmente problemáticos em sistemas de detecção e prevenção de intrusões (IDPS). Os IDPS são projetados para detectar e bloquear atividades maliciosas, mas geralmente geram falsos positivos. Esses diagnósticos errados muitas vezes fazem com que o IDPS seja desativado ou totalmente ignorado, deixando uma organização vulnerável a ataques.

Os falsos positivos devem ser tratados como ameaças potenciais e investigados em conformidade. As equipes de segurança também devem ter processos para identificar e resolver falsos positivos rapidamente.

Como posso reduzir falsos positivos em Cyber Security? 

As organizações estão lutando para encontrar o melhor método para gerenciar o problema da sobrecarga de alertas. Muitos estão contratando mais analistas de segurança ou simplesmente desativando recursos de segurança para lidar com o volume de alertas. No entanto, esta não é a solução que toda a indústria procura.

Você poderia reduzir o número de regras no gerenciamento de eventos e informações de segurança (SIEM), especialmente regras que são explicitamente projetadas apenas para um dispositivo ou sistema de rede específico que você não possui. Se você não tiver mais esse sistema ou dispositivo em sua rede, mas mantiver a regra, isso poderá criar falsos positivos. 

Evite o uso de regras padrão em um SIEM, pois elas são propensas a cometer erros ou são rotuladas incorretamente em alguns produtos. Você deverá executar mais iterações se a regra ainda disparar falsos positivos. As regras devem ser divididas em múltiplas sub-regras de natureza mais específica. Os analistas devem testar continuamente as regras até que parem de gerar falsos positivos.

Priorizar alertas é uma das melhores técnicas que um SOC pode utilizar para reduzir o tempo perdido na investigação de falsos positivos. Os alertas que têm a mais alta confiabilidade e estão vinculados à detecção de ameaças de alto nível devem receber a prioridade máxima. Isso permite que as equipes de segurança analisem ameaças desde a prioridade mais alta até a mais baixa, garantindo que alertas importantes sejam tratados primeiro. Por último, o ajuste, a inclusão na lista de permissões e a filtragem podem ajudar uma regra a funcionar com mais precisão, juntamente com exclusões aceitáveis que não exigem alertas.

Atualmente, também é fundamental investigar se o seu fabricante e fornecedor possui ferramentas de IA que possam te ajudar a reduzir falsos positivos. Hoje, é possível reduzir significativamente o esforço operacional com falsos positivos de forma automática, apenas utilizando recursos de IA que lhe auxiliam com esse desafio. 

Como a GoCache ajuda?

Como fabricante de soluções de cibersegurança, o time de P&D da GoCache está constantemente evoluindo seus produtos para gerarem a menor quantidade de falsos positivos possíveis.

Além disso, a GoCache oferece ferramentas de observabilidade como o Edge Insights, que permite com que o cliente analise os eventos de segurança e identifique rapidamente padrões de falsos positivos. Também oferecemos a opção de integrar os eventos de segurança da GoCache e enviá-los para alguma ferramenta de SIEM (Security Information and Event Management) como Wazuh, QRadar, Splunk, entre outros.

Por último, para clientes com equipes enxutas ou sem especialização em cibersegurança, oferecemos o serviço GoCache Managed Security, onde os especialistas da GoCache irão assumir o gerenciamento da ferramenta e garantir que elas estejam mitigando ataques com o máximo de assertividade, sem bloquear usuários legítimos.

DNSSEC: O que é, e como funciona?

/em

DNSSEC é uma implementação segura do sistema DNS onipresente que garante integridade e confiança ao assinar todos os registros DNS com chaves de segurança para criar assinaturas criptográficas. Essas assinaturas são armazenadas junto com os registros DNS tradicionais (MX, A, AAAA, CNAME, etc.), e ao verificar a assinatura, garante que os registros retornados pelo servidor DNS venham do servidor de nomes autorizado para a zona determinada. 

Os sistemas DNS tradicionais são vulneráveis tanto a ataques man-in-the-middle, onde os registros DNS são alterados no caminho para o usuário, quanto a ataques de envenenamento de DNS, onde o resolvedor DNS local (provavelmente seu computador) recebe uma enxurrada de resoluções DNS ruins. que dizem ao resolvedor local para resolver um determinado domínio para o site do invasor, em vez do legítimo. 

Como um DNS funciona? 

Para entender as Extensões de Segurança do Sistema de Nomes de Domínio (DNSSEC), é útil ter um conhecimento básico do Sistema de Nomes de Domínio (DNS).

O bom funcionamento da Internet depende criticamente do DNS. Cada página da web visitada, cada e-mail enviado, cada imagem recuperada de uma mídia social: todas essas interações usam o DNS para traduzir nomes de domínio amigáveis (como gocache.com.br) para endereços IP (como 198.0.33.7 e 2001: 500:88:300::7) necessários a servidores, roteadores e outros dispositivos de rede para rotear o tráfego pela Internet até o destino adequado.

Usar a Internet em qualquer dispositivo começa com o DNS. Por exemplo, considere quando um usuário digita o nome de um site em um navegador de seu telefone. O navegador usa o resolvedor stub, que faz parte do sistema operacional do dispositivo, para iniciar o processo de tradução do nome de domínio do site em um endereço de protocolo da Internet (IP). Um resolvedor stub é um cliente DNS muito simples que retransmite a solicitação de dados DNS de um aplicativo para um cliente DNS mais complicado chamado resolvedor recursivo. Muitos operadores de rede executam resolvedores recursivos para lidar com solicitações ou consultas de DNS enviadas por dispositivos em sua rede. (Operadores e organizações menores às vezes usam resolvedores recursivos em outras redes, incluindo resolvedores recursivos operados como um serviço para o público, como Google Public DNS, OpenDNS e Quad9.)

O resolvedor recursivo rastreia ou resolve a resposta à consulta DNS enviada pelo resolvedor stub. Este processo de resolução exige que o resolvedor recursivo envie suas próprias consultas DNS, geralmente para vários servidores de nomes autoritativos diferentes. Os dados DNS de cada nome de domínio são armazenados em um servidor de nomes oficial em algum lugar da Internet. Os dados DNS de um domínio são chamados de zona. Algumas organizações operam seus próprios servidores de nomes para publicar suas zonas, mas geralmente as organizações terceirizam essa função para terceiros. Existem diferentes tipos de organizações que hospedam zonas DNS em nome de terceiros, incluindo registradores, registros, empresas de hospedagem na web, provedores de servidores de rede, apenas para citar alguns.

Mas o DNS não por si só não é seguro?

O DNS foi projetado na década de 1980, quando a Internet era muito menor e a segurança não era uma consideração primordial em seu design. Como resultado, quando um resolvedor recursivo envia uma consulta a um servidor de nomes autoritativo, o resolvedor não tem como verificar a autenticidade da resposta. O resolvedor só pode verificar se uma resposta parece vir do mesmo endereço IP para onde o resolvedor enviou a consulta original. Mas confiar no endereço IP de origem de uma resposta não é um mecanismo de autenticação forte, uma vez que o endereço IP de origem de um pacote de resposta DNS pode ser facilmente falsificado ou falsificado. 

Como o DNS foi originalmente projetado, um resolvedor não consegue detectar facilmente uma resposta forjada a uma de suas consultas. Um invasor pode facilmente se disfarçar como o servidor autoritativo que um resolvedor consultou originalmente, falsificando uma resposta que parece vir desse servidor autoritativo. Em outras palavras, um invasor pode redirecionar um usuário para um site potencialmente malicioso sem que o usuário perceba.

Os resolvedores recursivos armazenam em cache os dados DNS que recebem de servidores de nomes autorizados para acelerar o processo de resolução. Se um resolvedor “stub” solicitar dados DNS que o resolvedor recursivo possui em seu cache, o resolvedor recursivo poderá responder imediatamente, sem o atraso introduzido pela primeira consulta a um ou mais servidores autorizados. No entanto, essa dependência do cache tem uma desvantagem: se um invasor enviar uma resposta DNS forjada que seja aceita por um resolvedor recursivo, o invasor envenenará o cache do resolvedor recursivo. O resolvedor irá então retornar os dados DNS fraudulentos para outros dispositivos que os consultam.

Como exemplo da ameaça representada por um ataque de envenenamento de cache, considere o que acontece quando um usuário visita o site do seu banco. O dispositivo do usuário consulta seu servidor de nomes recursivo configurado para obter o endereço IP do site do banco. Mas um invasor poderia ter envenenado o resolvedor com um endereço IP que apontasse não para o site legítimo, mas para um site criado pelo invasor. Este site fraudulento se faz passar pelo site do banco e tem a mesma aparência. O usuário desconhecido digitaria seu nome e senha, como de costume. Infelizmente, o usuário forneceu inadvertidamente suas credenciais bancárias ao invasor, que poderia então fazer login como esse usuário no site legítimo do banco para transferir fundos ou realizar outras ações não autorizadas.

Então usar um sistema de DNSSEC é fundamental? 

Os engenheiros da Internet Engineering Task Force (IETF), a organização responsável pelos padrões do protocolo DNS, perceberam há muito tempo que a falta de uma autenticação mais forte no DNS era um problema. O trabalho em uma solução começou na década de 1990 e o resultado foram as Extensões de Segurança DNSSEC.

DNSSEC fortalece a autenticação no DNS usando assinaturas digitais baseadas em criptografia de chave pública. Com o DNSSEC, não são as consultas e respostas DNS em si que são assinadas criptograficamente, mas sim os próprios dados DNS são assinados pelo proprietário dos dados.

Cada zona DNS possui um par de chaves pública/privada. O proprietário da zona usa a chave privada da zona para assinar dados DNS nesta zona, assim gerando assinaturas digitais sobre esses dados. Como o nome “chave privada” indica, esse material de chave é mantido em segredo pelo proprietário da zona. 

A chave pública da zona, entretanto, é publicada na própria zona para que qualquer pessoa possa recuperá-la. Qualquer resolvedor recursivo que procure dados na zona também recupera a chave pública da zona, que usa para validar a autenticidade dos dados DNS. O resolvedor confirma que a assinatura digital dos dados DNS recuperados é válida. Nesse caso, os dados DNS são legítimos e são devolvidos ao usuário. Se a assinatura não for validada, o resolvedor assume um ataque, descarta os dados e retorna um erro ao usuário.

DNSSEC adiciona dois recursos importantes ao protocolo DNS:

  • A autenticação da origem dos dados permite que um resolvedor verifique criptograficamente se os dados recebidos realmente vieram da zona onde acredita que os dados foram originados.
  • A proteção da integridade dos dados permite que o resolvedor saiba que os dados não foram modificados em trânsito desde que foram originalmente assinados pelo proprietário da zona com a chave privada da zona.

E quais são os principais ataques que o DNSSEC mitiga?

Entre os principais ataques mitigados pelo DNSSEC, podemos destacar: 

DNS Cache Poisoning

O envenenamento do cache DNS (dns poisoning) ocorre quando um agente de ameaça alimenta informações falsas no cache DNS, fazendo com que o navegador do usuário retorne uma resposta incorreta.

Essa resposta geralmente redireciona os usuários para um site diferente daquele que pretendiam visualizar. Quando isso acontecer, um worm, spyware, programa de sequestro de navegador da Web ou outro tipo de malware poderá ser baixado para o computador do usuário a partir de um local não autorizado.

Os resolvedores de DNS não podem verificar os dados armazenados em seus caches, o que significa que as informações incorretas permanecem no cache até que o TTL expire ou até que o problema seja resolvido manualmente. Embora o envenenamento de cache não desconecte o site real de seu endereço IP real, se as informações incorretas permanecerem no cache DNS, os usuários continuarão a ser direcionados ao site não autorizado, o que pode levar a maiores comprometimentos.

DNS Hijacking

O sequestro de servidor de nomes de domínio (DNS) Hijacking, também chamado de redirecionamento de DNS, é um tipo de ataque de DNS no qual as consultas de DNS são resolvidas incorretamente para redirecionar inesperadamente os usuários para sites maliciosos. Para realizar o ataque, os perpetradores instalam malware nos computadores dos usuários, assumem o controle dos roteadores ou interceptam ou hackeiam a comunicação DNS.

O sequestro de DNS pode ser usado para pharming (nesse contexto, os invasores normalmente exibem anúncios indesejados para gerar receita) ou para phishing (exibindo versões falsas de sites acessados pelos usuários e roubando dados ou credenciais).

Muitos provedores de serviços de Internet (ISPs) também usam um tipo de sequestro de DNS para assumir as solicitações de DNS de um usuário, coletar estatísticas e retornar anúncios quando os usuários acessam um domínio desconhecido. Alguns governos usam o sequestro de DNS para censura, redirecionando os usuários para sites autorizados pelo governo.

E como posso usar o recurso de DNSSEC em minhas aplicações web? 

Como vimos neste artigo, quando se trata de implementar o DNSSEC, é fácil subestimar sua complexidade. Ainda mais se pensarmos em uma estrutura DNS centralizada e automatizada. 

No mínimo, a implementação manual requer manutenção de registros e substituição de chaves (atualização periódica das chaves para reduzir as chances de comprometimento).

Na GoCache é possível utilizar os recursos nativos de DNSSEC em nossa plataforma, permitindo que suas aplicações tenham toda a segurança de DDSSEC, sem esforços de implementação e manutenção. 

Para utilizar o DNSSEC em seu domínio na GoCache é necessário fazer a configuração tanto no Painel da GoCache, quanto no registro, onde o seu domínio foi comprado. Trata-se de uma configuração extremamente simples e que é feita em poucas etapas. 

Caso queira saber um pouco mais sobre implementação de DNSSEC na GoCache, leia nossa documentação sobre o tema. 

Floods (Inundação) XML-RPC no WordPress: O que é, e como se proteger

/em

O arquivo xmlrpc.php pode ser encontrado no núcleo do WordPress e geralmente é habilitado por padrão, o que deixa seu site WordPress exposto a todos os tipos de ataques maliciosos.

Neste artigo da GoCache, veremos o que é o arquivo XMLRPC, o que ele faz e, mais importante, como gerenciá-lo e, ao mesmo tempo, aumentar a segurança do seu site.

Mas o que é XMLRPC?

XML-RPC (Extensible Markup Language – Remote Procedure Call) foi criado para oferecer comunicação entre plataformas. Este é um protocolo que utiliza HTTP como transporte e XML como codificador para gerar chamadas de procedimentos, permitindo assim a execução de funções em um computador remoto.

As solicitações HTTP podem ser enviadas pelo cliente (ou seja, navegador ou aplicativo móvel) ao servidor, e o servidor então envia uma resposta HTTP. A solicitação HTTP pode ser usada para invocar funções e essas funções podem então ser usadas para executar ações específicas.

Isso é diferente da API REST, pois usa parâmetros de URL para identificar recursos. Por outro lado, o RPC usa parâmetros de consulta para oferecer argumentos de função.

XMLRPC permite que os usuários interajam com seu site remotamente, como por meio do aplicativo móvel WordPress ou de plugins amplamente conhecidos, como JetPack ou WooCommerce.

Por que muitos especialistas em aplicações em WordPress desabilitam o recurso xmlrpc.php? 

A principal razão pela qual você pode desabilitar o xmlrpc.php em seu site WordPress é porque ele introduz vulnerabilidades de segurança e pode ser alvo de ataques.

Uma vez que o XML-RPC não é mais necessário para comunicação fora do WordPress, não há razão para mantê-lo ativo. É por isso que é aconselhável tornar seu site mais seguro, desativando a extensão. 

Se xmlrpc.php é uma responsabilidade de segurança e não funciona mais, por que não foi totalmente removido do WordPress? A razão para isso é porque um dos principais recursos do WordPress sempre será a compatibilidade com versões anteriores. Se você gerencia bem o seu site, saberá que manter o WordPress atualizado, assim como quaisquer plugins ou temas, é essencial.

Mas sempre haverá proprietários de sites que não desejam ou não podem atualizar sua versão do WordPress. Se eles estiverem executando uma versão anterior à API REST, eles ainda precisarão de acesso ao xmlrpc.php.

E como eu posso desabilitar meu XMP-RPC no WordPress? 

Existem várias opções diferentes que você pode aproveitar para desativar o XML-RPC em seu site WordPress, incluindo modificações em seu arquivo .htaccess, desativá-lo com um filtro ou instalar um plugin. Neste exemplo, vamos mostrar como desativar o XML-RPC via arquivo .htaccess

Se você usa Apache, você pode desativar o XML-RPC editando seu arquivo .htaccess para incluir o seguinte código:

<Files xmlrpc.php>

Order Allow,Deny

Deny from all

</Files>

Certifique-se de criar um backup do arquivo .htaccess original antes de fazer qualquer alteração. Observe que se você usar o servidor web NGINX em vez do Apache, não terá um arquivo .htaccess funcional. Nesse caso, tente um dos outros métodos para desabilitar o XML-RPC.

E quais as vulnerabilidades mais frequentes em XML-RPC do WordPress? 

Vejamos as vulnerabilidades específicas com mais detalhes.

Brute force via xmlrpc.php

Os ataques de força bruta (brute force) envolvem hackers que tentam obter acesso ao back-end de um site, tentando milhares de combinações de nome de usuário e senha até encontrarem as credenciais corretas. Sites com senhas de administrador fracas e sem autenticação multifatorial são particularmente vulneráveis a esses ataques.

Os invasores podem usar ferramentas automatizadas para encontrar e listar todos os nomes de usuário válidos de um site. Assim que obtiverem essas informações, eles poderão explorar o arquivo xmlrpc.php para realizar um ataque de força bruta, enviando solicitações com várias combinações de senhas. Se as medidas de segurança de um site forem inadequadas, os hackers nem precisam ignorar os reCaptchas ou se preocupar com tentativas limitadas de login. Isso poderia permitir que hackers obtivessem acesso não autorizado ao seu site, representando um risco de segurança significativo para o seu ambiente WordPress.

Portanto, se você estiver usando atualmente uma versão do WordPress que aproveita a API REST para se comunicar com sistemas externos, vale a pena desabilitar totalmente o XML-RPC para mitigar o risco.

Quer aprender um pouco mais sobre Brute Force, e como proteger áreas logadas? Então dá uma olhada no vídeo que temos sobre o assunto. 

Ataques DDoS via xmlrpc.php

Os ataques distribuídos de negação de serviço (DDoS) podem incapacitar completamente o seu servidor, enviando milhares de solicitações simultâneas. No WordPress, os hackers costumam usar o recurso pingback em conjunto com o arquivo xmlrpc.php para executar ataques DDoS. Esses ataques podem sobrecarregar seu servidor e deixar seu site offline usando xmlrpc.php para enviar um grande número de pingbacks em um curto espaço de tempo.

Para iniciar o ataque, os hackers primeiro identificam uma página alvo e verificam a presença do arquivo xmlrpc.php enviando uma solicitação específica. Depois de confirmarem sua existência, eles começam a bombardeá-lo com solicitações de pingback de uma rede de sites comprometidos.

Em muitos casos, esse processo pode ser automatizado usando código específico, o que permite que hackers enviem inúmeras solicitações de pingback ao site alvo. Como resultado, desabilitar o xmlrpc.php pode reduzir significativamente o risco de ataques DDoS e ajudar a manter um ambiente seguro para o seu site WordPress.

XML-RPC: Qual o custo benefício de manter?

O XML-RPC já foi um componente vital para a comunicação entre o WordPress e aplicativos externos, mas sua utilidade diminuiu com a introdução da API REST do WordPress, mais segura e versátil. Embora o xmlrpc.php ainda exista nas instalações do WordPress devido à compatibilidade com versões anteriores, é importante reconhecer que mantê-lo ativo pode trazer riscos de segurança, como força bruta e ataques DDoS.

Portanto, reserve um momento para verificar se o XML-RPC está habilitado em seu site WordPress. Se você não precisar mais dele, desative-o para ajudar a mitigar o risco de força bruta e DDoS.

Quero utilizar o XML-RPC, como posso me proteger? 

Caso você precise seguir utilizando os recursos de XML-RPC em seu WordPress, saiba que podemos te ajudar. Na GoCache você pode utilizar nossas soluções de segurança, como WAF, Rate Limit, Bot Mitigation e Firewall, permitindo que você se proteja contra ataques em XML-RPC de forma simples e sem nenhum esforço técnico. 

Mozlila: O user-agent suspeito

/em

Desde os primórdios da internet, existem dois tipos de usuários heavy users que gostam de Cyber Security: aqueles que gostam de provocar incidentes e aqueles que protegem aplicações contra incidentes. 

É claro que, com a evolução dos mecanismos de defesa, aqueles que buscam vulnerabilidades passaram a utilizar recursos cada vez mais tecnológicos, e que podem provocar danos severos. Mas, é fundamental entender que por muitas vezes as ferramentas de ataque podem ser utilizadas incorretamente, e ainda mais, podem ser distribuídas para outros atacantes com erros, gerando bizarrices. 

Ano passado, algumas variações de user-agent contendo “Mozlila” foram identificadas pelo nosso time de cibersegurança. Algo que nos chamou atenção foi a similaridade com o nome “Mozilla”,  amplamente utilizado na internet, constantemente identificado como legítimo por quem administra aplicações web. 

E como descobrimos esse user-agent? 

Um dos analistas de Cyber Security do time da GoCache notou que um cliente específico recebia acessos do user-agent contendo a palavra “Mozlila”, e no início parecia se tratar apenas de um erro pontual de digitação por parte de algum atacante. 

Investigando mais a fundo, notou-se que havia uma quantidade constante de acessos vindo deste user-agent, e boa parte proveniente da Europa e Ásia.

Vamos dar uma olhada nos números? 

Dados da rede da GoCache sobre a requisição do “Mozlila”

Além do volume de requisições, nosso time também buscou entender a origem desse user-agent. Descobrimos que mais de ¼ desses acessos vieram de Singapura. Confira abaixo a distribuição dos acessos por geocalização. 

Dados da rede da GoCache sobre geolocalização do “Mozlila”

Mas afinal, o que é esse tal de “Mozlila” buscava fazer? 

Após análise das URLs de acesso, foi possível identificar que o alvo específico desse user-agent eram aplicações em WordPress. Basicamente, ele tenta encontrar vulnerabilidades no CMS, bem como, oportunidades em backdoors e variáveis de ambiente. 

Atualmente, este caso do “Mozlila” já é amplamente conhecido, e é bloqueado por padrão em sistemas de segurança mais atualizados. 

A Trunc montou um artigo bem interessante sobre o assunto, mostrando passo a passo como eles identificaram a origem dos ataques, e como descobriram que tratava-se na verdade de um suposto erro de digitação banal. Caso queira ler o artigo da Trunc, basta clicar aqui. 

Sim, o user-agent suspeito “Mozlila” que fez nosso time de segurança realizar uma investigação a fundo no ano passado era aparentemente um erro de copiar e colar do script de um atacante, que foi replicado em várias ferramentas e scanners, e o resultado final foi a introdução de um novo agente de usuário no ecossistema de quem lida com segurança web.

O que devo fazer para me proteger?

Para se proteger, você tem algumas soluções à disposição. A primeira seria bloquear esse user-agent em seu servidor web, fazendo com que sempre que esse user-agent for detectado, ele seja interceptado antes de se transformar em uma requisição legítima.

Além disso, é possível adicionar regras no firewall para esse tipo de user-agent, opção mais simples e rápida para aqueles que já têm contratado este recurso.

Como a GoCache ajuda?

Clientes da GoCache têm, via de regra, um firewall de borda que permite que o cliente crie regras para bloquear acessos provenientes de algum user-agents. 

É necessário levar em consideração que diferentes user-agents e bots são criados diariamente, tornando cada vez mais complexo o dia a dia de quem gerencia aplicações web.

Para casos mais avançados,  recomendamos que nossos clientes utilizem o nosso Bot Mitigation , que identifica e bloqueia automaticamente diferentes bots, sem a necessidade de criar regras para cada caso.

Riscos, Evolução e Futuro: Os desafios de lidar com ataques DDoS

/em

O que está em risco em um ataque DDoS em um site ou aplicação web? Certamente, existe um risco financeiro, uma vez que uma possível paralisação da operação online trará prejuízos diretos. Existe o custo da remediação e os clientes afetados podem ter que ser compensados. Existe um risco legal se os dados confidenciais do usuário forem comprometidos. Os prestadores de serviços podem enfrentar consequências financeiras e jurídicas se não cumprirem os seus SLAs. Depois, há os prejuízos intangíveis, como danos à marca ou à reputação de uma empresa, que aparecerão no futuro na forma de perda de negócios e queda nos preços das ações.

A evolução dos ataques DDoS:

Os ataques de negação de serviço distribuídos (DDoS) continuarão a ser uma ameaça significativa em 2024, com uma evolução notável em sua natureza. Antecipa-se um aumento na utilização de técnicas de inteligência artificial e aprendizado de máquina por parte dos atacantes para aprimorar a eficácia dos ataques DDoS. Além disso, a diversificação de vetores de ataque, como amplificação de DNS e ataques de reflexão, exigirá que as organizações fortaleçam suas defesas, adotando soluções de mitigação de DDoS baseadas em inteligência artificial e análise de tráfego em tempo real.

Quanto mais digital, mais vulnerável

Uma frase da moda que ouvimos muito hoje em dia é “transformação digital”. As empresas estão investindo em tecnologias que tornam suas operações mais eficientes por meio de automação, virtualização, nuvem e conectividade. Muitos estão criando novos modelos de negócios alimentados digitalmente que não teriam sido possíveis sem a convergência destas tecnologias. No entanto, as medidas de segurança nem sempre acompanham esta transformação. A Internet das Coisas (IoT), aplicações, redes e dispositivos estão a proliferar mais rapidamente do que os esforços para protegê-los, tornando-os alvos propícios para os atacantes. As próprias tecnologias que tornam a prestação de serviços mais eficiente também tornam as empresas mais vulneráveis a ataques.

Parte da razão pela qual os ataques estão se tornando cada vez mais devastadores é que eles estão crescendo em tamanho e complexidade. Os atores podem empregar uma combinação de metodologias de ataque e atacar diferentes vetores de ataque. As atuais ameaças multicamadas podem combinar um ataque volumétrico em grande escala, que procura sobrecarregar a largura de banda através da força pura, com um ataque furtivo que visa algum aspecto de uma aplicação ou serviço na Camada 7. Esses são os tipos de ataques mais danosos, pois podem ser muito eficazes com apenas uma máquina atacante gerando uma baixa taxa de tráfego (isso torna esses ataques muito difíceis de detectar e mitigar proativamente).

Aumento da conscientização sobre ameaças em nível C

À medida que os riscos DDoS aumentam, também aumenta a consciencialização da gestão. Ataques DDoS de alto perfil levaram a uma melhor compreensão da ameaça no nível executivo. Em 2017, 77% das empresas relataram que o DDoS fazia parte dos seus negócios ou das suas avaliações de risco de TI. Esta é uma tendência positiva e encorajadora. Isto indica que os líderes empresariais estão a reconhecer a proteção DDoS como uma questão de gestão de risco.

As empresas dedicam recursos e conhecimentos substanciais à gestão dos seus riscos e exposição financeiros, regulamentares, comerciais e de mercado. É hora de adotar a mesma postura em relação aos riscos de segurança cibernética, especialmente porque cada vez mais negócios estão online ou dependem de redes conectadas à Internet pública. Você possui controles para garantir a disponibilidade contínua do serviço e mitigar os riscos financeiros, legais e de reputação que um ataque DDoS representa?

Ataques multicamadas exigem uma defesa multicamadas

A proteção eficaz contra DDoS requer contramedidas contra todo e qualquer tipo de ameaça. Uma solução DDoS híbrida totalmente gerenciada, integrando proteção local dedicada com recursos de mitigação baseados em nuvem, é amplamente considerada a melhor prática na defesa contra DDoS. O componente local fornece recursos suficientes de detecção e mitigação contra a grande maioria dos ataques, incluindo ataques de camada de aplicação e de exaustão de estado que têm como alvo firewall, IPS e outras infraestruturas com estado. O componente de nuvem é necessário para fornecer a capacidade de neutralizar grandes ataques volumétricos, que atingem tamanhos de 600 a 800 Gbps. No cenário híbrido, os dois componentes são integrados de forma inteligente para que a mitigação da nuvem seja ativada automaticamente quando um ataque atinge um limite designado.

Os dados WISR deste ano sublinham as consequências crescentes dos ataques DDoS – perda de receitas, perda de clientes e perda de credibilidade. Um investimento em proteção dedicada contra DDoS é uma proteção eficaz contra um dos riscos do seu negócio: a perda de disponibilidade do serviço e as consequências resultantes.


Enfoque na visibilidade e monitoramento de tráfego na camada 7:

Com o aumento da complexidade dos ataques na camada 7, a visibilidade e o monitoramento de tráfego tornam-se elementos críticos da estratégia de segurança. Soluções de análise de tráfego na camada 7 permitirão uma compreensão mais profunda dos padrões de comportamento dos usuários e do tráfego de dados, facilitando a detecção precoce de atividades suspeitas. A implementação de ferramentas avançadas de análise comportamental será essencial para identificar ameaças que se disfarçam de tráfego legítimo.

Foco na educação e conscientização:

A segurança cibernética é uma responsabilidade compartilhada, e a educação contínua dos usuários é essencial. Em 2024, as organizações deverão investir cada vez mais em programas de treinamento de conscientização de segurança para garantir que os usuários estejam cientes dos riscos na camada 7, como phishing e engenharia social, que podem levar a violações de segurança.

O que é NTP Amplification?

/em

O ataque de amplificação NTP é um ataque DDoS baseado em reflexão amplificada que tira vantagem de um servidor Network Time Protocol (NTP) abertamente acessível que é executado em uma porta de tráfego UDP. A porta de tráfego UDP é de vulnerabilidade simples em um dispositivo, pois não vai através do processo de “handshake”, onde um remetente tem que estabelecer uma conexão com o destinatário antes de poder enviar dados, isso permite que os invasores alimentem o dispositivo alvo com quaisquer dados que desejarem, sem o conhecimento prévio do destinatário.

Em um ataque DDoS de amplificação NTP, o invasor canaliza uma quantidade amplificada de tráfego para um dispositivo ou servidor, tornando o computador alvo e suas estruturas envolvidas inacessíveis ao tráfego válido, o único objetivo de um ataque DoS.

Quais são as técnicas mais usadas em ataques de amplificação NTP: 

  • Explorando o comando NTP Monlist: Os invasores utilizam o comando NTP “monlist”, um recurso projetado para fornecer informações sobre clientes NTP recentes. Ao enviar uma solicitação maliciosa a um servidor NTP com um endereço IP de origem falsificado, os invasores enganam o servidor para que envie uma resposta grande ao endereço IP de destino, amplificando o tráfego do ataque.
  • Falsificação de endereços IP de origem: Para mascarar a sua identidade e dificultar o rastreio da origem do ataque, os atacantes falsificam frequentemente os endereços IP de origem dos seus pedidos. Isto acrescenta outra camada de complexidade ao processo de mitigação, tornando mais difícil diferenciar o tráfego legítimo do tráfego de ataque.
  • Utilizando botnets: Os ataques de amplificação NTP frequentemente dependem de botnets, redes de dispositivos comprometidos controlados por invasores. Ao orquestrar um grande número destes dispositivos, os atacantes podem amplificar a escala e o impacto dos seus ataques, dificultando a defesa e a mitigação do ataque de tráfego.

Como posso prevenir ataques de amplificação NTP: 

  • Desative a lista monástica:  Monlist é uma vulnerabilidade que pode ser encontrada em um servidor NTP e que os hackers usam para conduzir ataques de amplificação NTP. Portanto, desabilitar o comando monlist é uma forma de interromper um ataque de amplificação NTP. Servidores NTP que usam software 4.2.7 e superior têm esse comando desabilitado automaticamente, para que não sejam tão vulneráveis a ataques de amplificação NTP.
  • Verificação do IP de origem: Como os invasores usam endereços IP falsificados para sobrecarregar suas vítimas com tráfego UDP, rejeitar o tráfego interno de IPs falsificados é uma forma de impedi-los de fazer isso.
  • Use ferramentas de proteção contra DDoS. Embora os ataques de amplificação NTP sejam um tipo de ataque DDoS, o uso de ferramentas ou software de proteção DDoS padrão ainda pode ajudar a evitá-los. Por exemplo, na GoCache você pode contar com segurança anti DDoS, permitindo mais segurança para suas aplicações. 

Referências: 

  • https://medium.com/@michealtremendous/ntp-amplification-attack-what-is-it-and-how-to-mitigate-92392bd73bb4
  • https://prophaze.com/learning/what-are-ntp-amplification-attacks/
  • https://nordvpn.com/pt-br/cybersecurity/glossary/ntp-amplification-attack/

Ataques DDoS Zero Day: O que é, e como funciona?

/em

“Zero-day” é um termo amplo que descreve vulnerabilidades de segurança recentemente descobertas que os hackers podem usar para explorar sistemas. O termo “zero day” refere-se ao fato de que o fornecedor ou desenvolvedor acabou de tomar conhecimento da falha – o que significa que eles têm “zero day” para corrigi-la. Um ataque de zero day ocorre quando os hackers exploram a falha antes que os desenvolvedores tenham a chance de resolvê-la.

E como funcionam os ataques de Zero Day:

Embora os desenvolvedores de software verifiquem constantemente se há falhas em seus produtos e forneçam atualizações de software, muitos aplicativos são lançados com vulnerabilidades que, quando encontradas, podem ser exploradas por invasores para roubar dados ou dinheiro, causar interrupções nos negócios ou lançar ataques mais sofisticados e devastadores. Antes que uma vulnerabilidade seja descoberta por um fornecedor de software, os invasores podem passar dias ou meses aproveitando essa fraqueza para seu próprio benefício. Hackers maliciosos podem até vender informações ou funcionalidades sobre sistemas vulneráveis ​​de zero day na dark web para outros cibercriminosos.

Os ataques de zero day podem tirar vantagem de muitos tipos de vulnerabilidades, incluindo buffer overflows, algoritmos quebrados, redirecionamentos de URL, injeção de SQL e problemas de segurança de senha. Com uma exploração de zero day, os agentes de ameaças podem acessar uma máquina para roubar dinheiro ou dados confidenciais, interromper operações ou sequestrar a máquina como parte de uma botnet projetada para lançar ataques distribuídos de negação de serviço (DDoS).

Como um ataque DDoS baseado em vulnerabilidades de zero day explora pontos fracos que são desconhecidos para um fabricante de software e seus clientes, é muito difícil defendê-lo. A melhor estratégia é adotar uma defesa em vários níveis que proteja contra os vários métodos que os agentes mal-intencionados podem utilizar para explorar uma vulnerabilidade de zero da.. Isso inclui defesas contra ransomware, malware, vírus, botnets, ataques baseados em API, injeção de SQL e outros vetores de ataque comuns, porém perigosos.

Como podemos  reduzir a vulnerabilidade de zero day? 

Para permanecerem vigilantes contra a ameaça de ataques zero day, as empresas devem ter uma estratégia em vigor.

Mantenha-se informado

Ser proativo e manter-se informado sobre os riscos mais recentes no cenário de ameaças é um primeiro passo vital na prevenção de ataques de zero day. Isso inclui a implantação de software de segurança abrangente que bloqueará ameaças conhecidas e desconhecidas. Também inclui funcionários que praticam hábitos online seguros e definem configurações de segurança para seus navegadores e sistemas. 

Execute atualizações do sistema

Garantir que os sistemas estejam atualizados é crucial para proteger uma empresa do risco de ataques de zero day. Isso inclui ter os recursos mais recentes instalados, remover recursos desatualizados ou extintos, atualizar drivers, corrigir bugs e preencher possíveis falhas de segurança.

Use um firewall adequado para aplicações web

Os softwares e plataformas gratuitas e tradicionais não conseguem proteger eficazmente as empresas contra ameaças de zero day. Em vez disso, as empresas precisam procurar soluções que bloqueiam ataques desconhecidos de zero day. 

Use um WAF com atualizações frequentes

A utilização de WAFs para proteger aplicações web contra tráfego HTTP malicioso é uma excelente solução para aumentar as barreiras de proteção contra ataques de Zero Day. Levando em consideração que os ataques e ameaças estão em constante mudança, um WAF que permita gerar regras gerenciadas pode ajudar a proteger contra ataques e vulnerabilidade. Aqui na GoCache, nós atualizamos com regularidade nossas regras gerenciadas de WAF, permitindo que nossos clientes tenham um sistema de proteção contínuo. 

Ataques DDoS Zero Day: O que é, e como funciona?

Abaixo, citamos alguns exemplos emblemáticos de ataques zero day bem sucedidos. 

RSA: 

Outro ataque de zero day altamente público viu hackers usarem uma vulnerabilidade não corrigida no Adobe Flash Player para obter acesso à rede da empresa de segurança RSA em 2011. Os invasores enviaram e-mails anexados com planilhas do Excel, que continham um arquivo Flash incorporado que explorava o zero Vulnerabilidade diária, para funcionários da RSA. Quando os funcionários abriram a planilha, ela deu ao invasor o controle remoto do computador do usuário, que ele usou para pesquisar e roubar dados. Essas informações estavam relacionadas aos produtos de autenticação de dois fatores SecurID que os funcionários usam para acessar dados e dispositivos confidenciais.

Google Chrome

Em 2021, o Chrome do Google sofreu uma série de ameaças de zero day, fazendo com que o Chrome lançasse atualizações. A vulnerabilidade resultou de um bug no mecanismo JavaScript V8 usado no navegador da web.

Microsoft Windows

Este ataque concentrou-se em privilégios de escalonamento local, uma parte vulnerável do Microsoft Windows, e teve como alvo instituições governamentais na Europa Oriental. A exploração de zero day abusou de uma vulnerabilidade de privilégio local no Microsoft Windows para executar código arbitrário e instalar aplicativos e visualizar e alterar os dados em aplicativos comprometidos. Depois que o ataque foi identificado e relatado ao Centro de Resposta de Segurança da Microsoft, um patch foi desenvolvido e implementado.

Sony Pictures: 

Potencialmente, o ataque de zero day mais famoso derrubou a rede Sony e levou à divulgação de seus dados confidenciais em sites de compartilhamento de arquivos. O ataque, no final de 2014, resultou no vazamento de informações sobre os próximos filmes, os planos de negócios da empresa e endereços de e-mail pessoais de executivos seniores.

Apple iOS

O iOS da Apple é frequentemente descrito como a mais segura das principais plataformas de smartphones. No entanto, em 2020, foi vítima de pelo menos dois conjuntos de vulnerabilidades de zero day do iOS, incluindo um bug de zero day que permitiu que invasores comprometessem iPhones remotamente.

HTTP Flood – O que é, como funciona e como se proteger?

/em

Um ataque DDoS de inundação (flood) HTTP pode parecer complexo, mas vamos simplificar. Trata-se de uma estratégia em que uma quantidade significativa de pedidos falsos HTTP, que são as solicitações feitas quando você acessa uma página da web, é direcionada a um servidor web ou aplicativo. Este tipo de ataque geralmente utiliza um exército de computadores comprometidos, conhecido como botnet, que foi tomado por malware, como um Cavalo de Tróia.

Quais são os sinais de um ataque DDoS de inundação de HTTP?

A essência desse ataque é fazer com que o servidor ou aplicativo-alvo aloquem o máximo possível de recursos em resposta a cada solicitação. O atacante busca sobrecarregar o servidor, “inundando-o” com um grande número de solicitações intensivas de processamento. Os ataques geralmente se utilizam de solicitações HTTP GET ou POST. Os GET são como uma multidão pedindo informações, enquanto os POST podem ser mais intensos, enviando dados para processar no servidor.

Tipos de ataques de inundação HTTP

Os ataques de inundação HTTP podem variar em suas técnicas para gerar tráfego e interromper o servidor de destino. Alguns tipos comuns incluem ataques GET, POST e Slowloris.

Ataque GET: Envolve o envio massivo de solicitações GET para um servidor web, visando sobrecarregá-lo com um grande número de solicitações de recuperação de dados. As solicitações GET geralmente não incluem dados no corpo e são usadas para obter informações do servidor, como uma página da web ou uma imagem.

Ataque POST: Semelhante ao ataque GET, mas usa solicitações POST, as quais incluem dados no corpo da solicitação enviados ao servidor para processamento. Isso pode ser mais eficaz, consumindo potencialmente mais recursos do servidor.

Ataque Slowloris: Mantém conexões HTTP abertas pelo maior tempo possível, utilizando largura de banda mínima. Isso impede que o servidor web feche a conexão e libere recursos, levando à sobrecarga do servidor.

Como se defender contra ataques de inundação HTTP(S)?

A proteção contra esses ataques pode ser complexa, mas algumas medidas podem ser tomadas. Limitar o número de conexões simultâneas permitidas à porta de serviço pode ajudar a prevenir ataques de inundação HTTP. Além disso, soluções automáticas fornecidas por parceiros podem interromper automaticamente o envio de novas conexões quando o limite máximo é atingido, oferecendo uma camada adicional de segurança. E é claro, a stack de soluções de segurança da GoCache pode te ajudar com esses desafios. 

Ao empregar as funcionalidades da GoCache, torna-se viável integrar automaticamente ferramentas de proteção contra ataques DDoS em sua aplicação. Essas ferramentas avaliam diversos padrões de acesso e efetivamente mitigam ataques de maneira automatizada. Adicionalmente, recomendamos a utilização de nossos recursos de mitigação de bots, possibilitando a seleção precisa dos bots que têm permissão ou restrição de acesso aos seus sistemas.

Outro aspecto crucial é a implementação de um sistema observável, como o Edge Insights, que possibilita a monitorização contínua e a criação de alertas personalizados. Essa abordagem proativa reforça a postura defensiva do seu sistema, assegurando agilidade na identificação e resposta a potenciais ameaças.

O que é Ping of Death (PoD)

/em

Antes de mergulharmos nos detalhes do Ping of Death (PoD), vale ressaltar que este termo é a tradução do inglês para “Ping da Morte”. Trata-se de um tipo de ataque de negação de serviço (DoS) em que um invasor utiliza o comando ping para enviar pacotes de dados grandes ou defeituosos, visando sobrecarregar, desestabilizar ou congelar a máquina ou serviço alvo. Mesmo com sua tradução literal, o PoD representa uma ameaça real, explorando vulnerabilidades herdadas, apesar de terem sido corrigidas ao longo do tempo.

O Primeiro Ping of Death

Em 1997, uma falha na implementação do processamento de pacotes ICMP IPv4 pelos sistemas operacionais levou à descoberta do primeiro Ping of Death. Neste cenário, pacotes de ping, também conhecidos como pacotes ICMP ECHO REQUEST, originalmente projetados para terem 64 bytes de comprimento, poderiam causar falha no sistema se tivessem um comprimento superior a 65.536 bytes, o valor máximo permitido no campo de comprimento.

Como funciona o Ping of Death?

A dinâmica do Ping of Death envolve o envio de pacotes de tamanho anormal, explorando a incapacidade de sistemas mais antigos processarem pacotes maiores. Geralmente, os invasores enviam pacotes defeituosos em fragmentos, violando o protocolo da Internet. O risco de estouro de memória surge quando a máquina alvo tenta remontar os fragmentos, resultando em falhas no sistema.

Mitigando ataques DDoS com Ping of Death

Para mitigar ataques DDoS usando o Ping of Death, são recomendadas medidas como a criação de buffers de memória capazes de lidar com pacotes maiores e a adição de verificações durante o processo de remontagem para proteger contra pacotes grandes reconstruídos. Dispositivos fabricados após 1998 não são mais suscetíveis a esse tipo de ataque, mas alguns equipamentos legados ainda podem estar em risco.

Atualizações e Novas Ameaças

Além disso, foi identificado um novo tipo de ataque Ping of Death que afeta pacotes IPv6, corrigido em meados de 2013. 

Medidas de Prevenção

Para evitar uma inundação de ping, é fundamental manter o software atualizado, filtrar o tráfego bloqueando pings fragmentados, realizar avaliações de remontagem de pacotes e criar buffers de estouro para lidar com pacotes que excedam o tamanho permitido. Essas medidas são essenciais para manter a segurança e a integridade dos sistemas.

UDP Flood – O que é?

/em

Uma inundação UDP (UDP Flood) é uma forma de ataque volumétrico de negação de serviço (DoS) em que o invasor tem como alvo e sobrecarrega portas aleatórias no host com pacotes IP contendo pacotes UDP (User Datagram Protocol).

Neste tipo de ataque, o host procura aplicações associadas a esses datagramas. Quando nenhum for encontrado, o host emite um pacote de “destino inacessível” de volta ao remetente. O efeito cumulativo de ser bombardeado por tal inundação é que o sistema fica inundado e, portanto, deixa de responder ao tráfego legítimo.

Em um ataque DDoS de Flood UDP, o invasor também pode optar por falsificar o endereço IP dos pacotes. Isso garante que os pacotes ICMP de retorno não consigam chegar ao seu host, ao mesmo tempo que mantém o ataque completamente anônimo.

Como ocorre um UPD Flood?

Ao contrário do TCP, o UDP é um protocolo sem conexão, o que significa que nenhuma conexão é estabelecida entre o cliente e o servidor antes que os pacotes sejam transmitidos. Além disso, o UDP não detecta perda de pacotes nem exibe nenhuma mensagem sobre perda de pacotes durante a comunicação cliente-servidor. Portanto, o UDP apresenta baixo consumo de recursos e alta velocidade de processamento. Tais vantagens tornam o UDP amplamente utilizado, mas também apresentam uma oportunidade para os invasores iniciarem ataques de inundação de UDP.

Os ataques de inundação UDP tradicionais são ataques de largura de banda que consomem recursos das partes atacante e atacada. Um invasor envia um grande número de pacotes UDP forjados para o dispositivo alvo por meio de uma botnet. Esses pacotes geralmente são grandes e transmitidos em alta velocidade, causando congestionamento no link ou até mesmo falha na rede. Este tipo tradicional de modo de ataque raramente é utilizado devido aos seus baixos requisitos tecnológicos.

Nos últimos anos, cada vez mais invasores usam ataques de amplificação de reflexão UDP. Os ataques de amplificação de reflexão UDP têm duas características: os ataques são baseados em UDP e o número da porta do alvo do ataque é fixo. Os princípios subjacentes aos diferentes tipos de ataques de amplificação de reflexão UDP são semelhantes. Um tipo comum é o ataque de amplificação de reflexão do Network Time Protocol (NTP), que possui dois recursos principais: reflexão e amplificação.

Como se defender contra ataques de inundação UDP?

Os incidentes de inundação UDP, embora de execução simplificada, têm o potencial de ocasionar distúrbios de considerável magnitude.

A rede  de CDN da GoCache possui uma série de mecanismos de proteção que identifica e bloqueia pacotes maliciosos, impedindo que um DDoS em camada de rede como UDP Flood, alcance os servidores de origem dos seus clientes.

Nosso serviço baseado em nuvem mantém a continuidade das operações online com níveis elevados de desempenho, mesmo em meio a ataques, mitigando potenciais perdas financeiras e preservando a integridade reputacional.

Referencias: 

https://info.support.huawei.com/info-finder/encyclopedia/en/UDP+Flood.html
https://www.netscout.com/what-is-ddos/udp-flood