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

Por que Web Application Security não é suficiente para segurança em API’s?

/em ,

Houve um tempo em que as aplicações web eram formadas por um grande bloco de código, homogêneo, em que o backend já entregava a página renderizada ao cliente. Esse grande bloco era hospedado em um grande servidor (ou alguns), dentro de um datacenter, no qual o perímetro de rede era ferrenhamente guardado, tal qual um castelo, mas onde tudo o que estivesse dentro do perímetro, era considerado seguro.

Ok! Isso não é assunto para arqueologia, já que boa parte das aplicações atuais ainda usam essa arquitetura. Mas o ponto importante aqui, é que as ferramentas de Web Application Security, como WAF e Application Security, como Application Security Testing (AST) surgiram dentro deste paradigma.

Como as páginas eram entregues prontas do servidor, a aplicação era um bloco homogêneo e estável, e o perímetro de rede era totalmente conhecido e controlável, a superfície de ataques era bastante reduzida e em questão de alguns ajustes, a proteção de um WAF era efetiva. Da mesma forma, testes com SAST e DAST reproduziam o comportamento da aplicação em produção, com menos distorções.

Mas de lá para cá, muita coisa vem acontecendo gradualmente: Single-Page Application, Mobile, integração entre empresas, cloud, frameworks de frontend reativos, arquitetura de microsserviços. E junto com tudo isso, emergiu um elemento fundamental para o funcionamento de tudo o que foi mencionado anteriormente: API ou Application Programing Interface.

A segurança de APIs é peculiar em relação à segurança de aplicações web a ponto de ter a sua própria lista de top 10 ameaças da OWASP. Apesar de ter grandes vulnerabilidades em comum com aplicações web, como injection, estão em destaque problemas de autenticação e autorização, como Broken Object Level Authorization e Broken Authentication.

Um exemplo destes tipos de vulnerabilidade aconteceu com a Uber em 2019. Ao criar uma conta, o browser do motorista enviava uma chamada com o parâmetro “userUuid”, e em troca recebia um JSON com detalhes da conta. O problema é que a API não validava que quem estava chamando era realmente o dono do “userUuid”, sendo que um atacante poderia enviar uma chamada com o “userUuid” de qualquer usuário, recebendo dentre outras informações sensíveis, o token de identificação, que poderia ser usado para roubar a conta. Felizmente isso foi descoberto antes de ser explorado, mas mostra a gravidade do problema.

E por que um WAF não protege contra um ataque como esse? A resposta é que esse tipo de vulnerabilidade depende intimamente do contexto específico da aplicação. No caso acima, a requisição é idêntica a uma requisição comum, de forma que difícil ela se encaixaria no padrão de alguma regra. Seria necessário detectar que a chamada na API não foi realizada em um fluxo normal, ou que o atacante não tem autorização sobre o “userUuid”, o que é muito específico à forma como a aplicação foi construída.

Algumas são as razões para a emergência dessas vulnerabilidades específicas. Como a renderização é feita do lado do cliente, as APIs ficam mais próximas às fontes de dados sensíveis. Além disso, com a emergência da arquitetura de microsserviços, a autenticação e a lógica da API são executadas em serviços diferentes, provavelmente geridos por equipes diferentes. Mesmo que as equipes adotem boas práticas de autorização, cada interação entre microsserviços corre o risco de expor uma falha. Como a complexidade se eleva exponencialmente em relação à quantidade de serviços e equipes, os pontos potenciais de falha são multiplicados. Por isso AST também perde eficiência neste contexto: o código do serviço pode estar perfeito, mas o problema está na interação com outros serviços.

Tendo em vista tudo o que foi mencionado, para a GoCache, é fundamental investir em novas soluções mais direcionadas aos problemas de vulnerabilidades de API. E é exatamente o que está acontecendo! Estamos preparando uma série de novidades em uma nova suite de produtos de API Protection.

Entre em contato com produto@gocache.com.br para participar do beta e ajudar a construir o futuro da Segurança de Aplicações Web. Afinal, API Security também é Web Application Security, e esse é o tema do próximo artigo desta série.

Por Victor Queiroz Vilas Boas, Product Manager GoCache.

PwnKit, a nova vulnerabilidade que está abalando o ecossistema Linux e a internet

/em

Acabou de ser descoberta, pela equipe de pesquisa da Qualys, uma nova vulnerabilidade de corrupção de memória que afeta as principais distribuições Linux. Identificada pelo CVE ID CVE-2021-4034, afeta o Polkit (antigo PolicyKit), um programa presente em praticamente todas as distribuições Linux modernas, responsável pelo controle de privilégios entre processos no sistema operacional.

Essa vulnerabilidade existe há doze anos, mas só recentemente veio à tona. É facilmente explorável, e permite que qualquer usuário obtenha privilégios totais de superusuário (root) em um sistema vulnerável, o que a torna bastante crítica.

O fato do sistema operacional Linux ser amplamente utilizado, abrangendo sistemas críticos de empresas de diversos segmentos, governos, e da própria infraestutura que garante o funcionamento da Internet, agrava a situação. O Linux é também a base de muitos equipamentos da chamada Internet das Coisas (IoT), além de dispositivos embarcados (em indústrias e veículos, por exemplo), elementos de rede (roteadores, switches etc.), entre outros, o que torna a superfície de ataque potencialmente muito grande, permitindo ataques em larga escala.

Os principais desenvolvedores de distribuições Linux já estão atuando para disponibilizar atualizações do Polkit com a correção dessa vulnerabilidade. Fique atento, acompanhe os boletins de segurança da sua distribuição e, caso tenha sistemas vulneráveis, planeje a atualização com máxima prioridade.

Log4shell: A vulnerabilidade zero day encontrada na biblioteca Log4j2 do Java

/em

No dia 9 de dezembro, a internet veio abaixo com a descoberta de uma vulnerabilidade (CVE-2021-44228) de alta criticidade encontrada na biblioteca do Java log4j 2, vastamente utilizada por milhares de serviços e empresas, como Steam, Twitter e até mesmo o famoso jogo eletrônico Minecraft.

A vulnerabilidade em questão, permite Remote Code Execution (RCE) no servidor afetado, isto é, uma vez explorada, a vulnerabilidade permite controle total sobre a máquina atacada

O que é o log4j 2?

 

Para entender como esta vulnerabilidade é explorada, primeiro precisamos entender o que é o pacote log4j2.

Uma das bibliotecas de logging mais populares, o log4j2 é um framework open source de logging incorporado em muitas aplicações baseadas em Java. Ela oferece aos desenvolvedores uma maneira de criar logs para gravar sua atividade em diversos casos de uso, como monitoração, rastreamento de dados, troubleshooting, entre outras coisas. Em suma, o log4j2 é um pacote open source, gratuito, que é utilizado pelas maiores empresas do mundo.

O impacto de CVE-2021-44228

O impacto desta vulnerabilidade é enorme devido à ampla adoção desta biblioteca Log4j . Se você tiver alguns aplicativos java em seu ambiente, é provável que eles estejam usando Log4j para registrar eventos internos.

A exploração também é bastante flexível, permitindo que você recupere e execute código arbitrário de servidores LDAP locais para remotos e outros protocolos.

Todos esses fatores e o alto impacto em tantos sistemas dão a essa vulnerabilidade uma classificação de gravidade CRÍTICA de CVSS3 10.0. O fato de a vulnerabilidade estar sendo explorada ativamente aumenta ainda mais o risco para as organizações afetadas.

Por dentro da falha

A vulnerabilidade se aproveita do Java Naming and Directory Interface (JNDI), que é uma API para acesso a serviços de diretórios. Ela permite que aplicações cliente descubram e obtenham dados ou objetos através de um nome. É fornecido um nome diferente de resolução e serviço de diretórios, como DNS e LDAP.

A vulnerabilidade existe por que no pacote Log4j, o componente afetado valida de forma não ideal os dados fornecidos pelo usuário, potencialmente permitindo um atacante fornecer uma linha que é interpretada como uma variável de código, que resulta no carregamento de um arquivo de classe Java.

Segue um exemplo resumido de como essa vulnerabilidade pode ser explorada, este método se baseia em uma política de logs especialmente construída para passar dados maliciosos como uma mensagem de erro.

Para concretizar a exploração, a URL JNDI/LDAP fornece um objeto de uma classe do Java que será carregada no host vítima, onde há a presença do Log4j, e isto só é possível por que o JDNI não reforça nenhum controle de segurança nas requisições do protocolo LDAP. E além disso, o protocolo LDAP suporta o carregamento de classe por usuários remotos.

Mitigação com a GoCache

Um dos serviços GoCache é o seu WAF (Web Application Firewall), que protege aplicações contra ataques e atividades maliciosas. Foram disponibilizadas novas regras para bloquear tentativas de exploração do Log4Shell, que fazem o bloqueio de qualquer requisição que tenha em seu corpo ou parâmetro, a carga maliciosa que explora a vulnerabilidade recém-descoberta, mitigando inclusive tentativas de formatação de textos, prática comum na tentativa de contornar o sistema de segurança do WAF.

 

Por Marcos Medeiros, Support Analyst GoCache

Como funciona Criptografia

/em

Hoje em dia, quando pensamos em internet, pensamos em um meio de comunicação confiável, levamos como verdade que enviaremos uma mensagem para alguém e essa mensagem chegará nessa pessoa instantaneamente sem problemas pelo caminho.

Apesar disso, as mensagens na internet, assim como em qualquer meio de comunicação, passam por um percurso e estão sucetíveis à problemas.

Vamos imaginar um meio de comunicação mais antigo, as cartas por exemplo. Se eu enviar uma carta à alguém, não tenho garantia nenhuma de que no meio do caminho ninguém abra a minha carta e leia ela, na internet é a mesma coisa, alguém pode ver o tráfego de uma mensagem sendo enviada e ler tudo que está lá. É ai que entra a criptografia, a criptografia não impede que um agente malicioso intercepte o tráfego e leia oque está sendo enviado, porém ela garante que caso esse agente intermediário leia, a mensagem estará completamente bagunçada e não fará o menor sentido.

Como a criptografia funciona?

A criptografia é uma maneira de transformar uma mensagem em outra e conseguir pegar a mensagem original de volta, esse conceito já existe à centenas de anos, como por exemplo a cifra de cesar que substitui as letras do alfabeto, movendo-as em um número de vezes fixo para criar uma mensagem criptografada a partir da mensagem original.

Existem dois tipos diferentes de criptografia, a criptografia simétrica e a criptografia assimétrica, ambas são bem semelhantes porém com diferenças cruciais, com suas forças e fraquezas.

Criptografia simétrica

Imaginemos uma situação em que duas pessoas querem poder conversar de forma criptografada para ninguém bisbilhotar as mensagens delas, na criptografia simétrica essas pessoas vão previamente decidir uma chave e utilizar essa chave para criptografar e descriptografar as mensagens enviadas.

 

 

Por exemplo, usando a cifra de césar que eu comentei anteriormente, vamos supor que as duas pessoas decidam o número 9 para movimentar as letras do alfabeto, se a pessoa A quer enviar a mensagem “OLÁ TUDO BEM” aplicando a criptografia a mensagem vira “XUJ CDMX KNV”, visto que a pessoa B sabe que a chave é 9, ela utiliza a chave para descriptografar a mensagem e pegar a mensagem “OLÁ TUDO BEM” de volta.

Existem diversos algoritmos de criptografia simétrica, geralmente a maior vantagem deles comparado à criptografia assimétrica é que eles são bem mais rápidos, visto isso são usados para mensagens efêmeras que precisam de mais rapidez como uma conversa https por exemplo.

Criptografia assimétrica

Nessa situação hipotética, as duas pessoas já haviam decidido uma chave previamente, porém como  faremos numa situação aonde eu queira ter uma conversa criptografada com uma pessoa sem que tivéssemos decidido uma chave antes?

 Nesse caso, utilizamos a criptografia assimétrica, na criptografia assimétrica, cada indivíduo tem 2 chaves, a chave pública e a privada, a pública pode ser compartilhada com o mundo todo sem problemas, porém a privada deve ser bem guardada apenas pelo dono dela, uma vai criptografar mensagens e outra vai descriptografar mensagens.

 

 

Voltando no nosso exemplo anterior, dessa vez a pessoa A e a pessoa B irão conversar utilizando criptografia assimétrica, se a pessoa A quer mandar a mensagem “OLÁ TUDO BEM” para a pessoa B, ela deve ter a chave pública da pessoa B. Com a chave pública B , a pessoa A vai criptografar a mensagem “OLÁ TUDO BEM” transformando ela em algo que não faz sentido, e vai enviar para a pessoa B a mensagem criptografada, com a mensagem criptografada em mãos, a pessoa B consegue ler a mensagem que foi escrita utilizando a chave privada dela, dessa forma temos garantia que a comunicação será segura visto que as chaves são um par definido matematicamente e a única chave do mundo todo que consegue descriptografar a mensagem criptografada com a chave pública, é a chave privada equivalente. 

Dessa forma, com a chave pública e a privada, temos uma situação na qual “TODO MUNDO pode escrever uma mensagem que APENAS UMA PESSOA pode ler”.

Assinatura digital

Utilizando a criptografia assimétrica também conseguimos garantir uma assinatura digital, é necessário apenas inverter a frase apresentada anteriormente que então teremos uma situação em que “APENAS UMA PESSOA pode escrever uma mensagem que TODO MUNDO pode ler”, assim, teremos garantia de que a pessoa que escreveu a mensagem realmente é quem ela diz ser, essa é a lógica utilizada em certificados digitais. 

Para que possamos inverter a frase, é necessário apenas inverter a função de cada chave, para a pessoa B ter uma assinatura digital, ela usa a chave privada dela para criptografar uma mensagem, então ela envia a mensagem original, a mensagem criptografada e a chave pública equivalente para a pessoa A, então a pessoa A utiliza a chave pública para descriptografar a mensagem criptografada e verifica se ela é igual a mensagem original, caso seja, eu tenho garantia de que a pessoa B realmente tem q chave privada, logo, ela é quem ela diz ser.

Conclusão

Na internet utilizamos a criptografia simétrica e a assimétrica o tempo todo, no https por exemplo, utilizamos primeiro a criptografia assimétrica para validar o certificado enviado pelo site, assim que estiver validado, utilizamos a criptografia assimétrica novamente para fazer a troca de chave, definindo uma chave comum entre as duas partes, com a chave definida, utilizamos a criptografia simétrica para seguir com a comunicação, garantindo uma maior velocidade do que se fosse usado a criptografia assimétrica.

Por Filipe Abrão dos Santos, Technical Support Analyst GoCache. 

 

Como funciona o monitoramento de segurança via SIEM

/em

Parece que a imagem clichê de um especialista em segurança é ele sentado em uma sala escura com mais de quatro monitores brilhantes exibindo diferentes tarefas complexas. Independentemente de quantos monitores eles usam, sabemos que as equipes de segurança estão usando o mesmo número, senão mais, de ferramentas complexas. De acordo com o Security Megatrend Report da empresa de análises EMA, 75% dos entrevistados usam mais de seis consoles para fazer o seu trabalho. Embora o estereótipo do especialista em segurança cibernética em ação possa parecer emocionante, a realidade é que ter tantas ferramentas para monitorar pode ser opressor e virtualmente impossível.

As soluções de gerenciamento de eventos e informações de segurança (SIEM – Security Information and Event Management) fornecem alívio e percepções da equipe de segurança com uma análise centralizada dos dados de segurança extraídos de uma variedade de sistemas. Continue lendo para aprender sobre a grande variedade de informações que um SIEM pode consolidar, tornando-se a principal ferramenta de monitoramento de segurança da sua organização.

Informação Típica

Universalmente, os SIEMs monitoram fontes de dados padrão, que incluem sistemas operacionais como Windows e Linux, roteadores e switches, firewalls, bancos de dados e servidores. Os SIEMs monitoram esses ativos não apenas quanto a comportamentos incomuns, mas também podem garantir que as atividades planejadas, como adição ou exclusão de usuários ou dados, ocorram sem incidentes. Ter todas essas fontes monitoradas em um só lugar também permite a correlação de eventos. A correlação de eventos mostra como um único evento pode ser relacionado a outros eventos registrados, auxiliando na análise forense e fornecendo uma trilha de auditoria. Isso pode fornecer insights poderosos sobre o seu ambiente. Por exemplo, se um usuário se envolver em um comportamento incomum no seu servidor, você pode abrir todas as atividades desse usuário, capturando eventos de segurança mais rapidamente e ver se há um padrão em outros dispositivos, garantindo suspeita.

Fluxos de dados diversos

Embora as fontes de dados padrão sejam essenciais para serem monitoradas, cada organização traz fontes exclusivas que também precisam de monitoramento, como um banco de dados local ou aplicativos de terceiros. Conectar coisas como um CRM otimiza ainda mais o seu ambiente, reduzindo o número de consoles que a sua equipe de segurança precisa examinar.

Isso é particularmente importante para coisas como aplicativos financeiros, nos quais capturar eventos em tempo real pode ser especialmente crucial. Por exemplo, se um usuário credenciado foi criado, realizou várias ações e foi excluído, esse comportamento suspeito pode significar que dados confidenciais e dinheiro podem estar em risco. Sem um SIEM monitorando eventos e enviando um alerta em tempo real, essa atividade pode não ser detectada até que seja tarde demais para fazer algo a respeito. Além disso, se um usuário não autorizado tentar ou conseguir baixar dados confidenciais, um SIEM pode desabilitar imediatamente o acesso desse usuário, evitando qualquer risco adicional enquanto o evento é investigado. Os tipos de ações realizadas dependem do evento e podem ser configuradas de acordo com as necessidades de cada organização.

Mais importante, habilitar a segurança do aplicativo pode trazer mais informações sobre os relacionamentos de eventos. Quanto mais um SIEM monitora, mais fácil é localizar eventos correlacionados, fornecendo um novo ângulo para visualizar a sua imagem de segurança. Por exemplo, integrar uma solução antivírus pode permitir que você não apenas receba alertas sobre violações impedidas, mas também pode permitir que você isole a origem da tentativa de infecção, fornecendo mais informações.

Expandindo a rede SIEM

Um SIEM é tão bom quanto os fluxos de dados que ele pode avaliar. Conforme mencionado acima, embora existam fontes típicas que a maioria dos ambientes possui, muitas organizações têm necessidades fora do escopo normal. Simplificando, um SIEM não pode gerar alertas para um aplicativo que não está monitorando. Em vez disso, uma fonte de dados não filtrada por um SIEM exigirá atenção especial, aumentando não apenas a carga de trabalho da sua equipe de segurança, mas também a probabilidade de atividades suspeitas escapando pelas rachaduras. Quanto mais fontes você conectar, mais insights poderá obter.

O Event Manager fornece uma visão holística de todo o seu ambiente. Ele não apenas fornece modelos prontos para fácil implementação para fontes de dados padrão, mas também pode ser usado com aplicativos internos, software de terceiros ou dispositivos conectados, fornecendo uma trilha de auditoria completa e monitoramento em tempo real para aplicativos principais não convencionais que ainda fornecem acesso aos seus sistemas críticos. Nossos especialistas estarão prontamente disponíveis para trabalhar com a sua equipe de segurança para desenvolver um plano para conectar quaisquer fluxos de dados necessários e fornecer suporte contínuo.

Referencia: https://www.coresecurity.com/blog/monitoring-application-security-siem

O que é TLS? Vantagens do TLS 1.3

/em

TLS (Transport Layer Security) é o protocolo criptográfico que fornece segurança de comunicação para todos os sites modernos. Lançado pela primeira vez em 1999 como uma atualização para o SSL 3.0, agora obsoleto, o TLS 1.0 evoluiu para o TLS 1.1 e, em 2008, para a versão atual do TLS 1.2. Embora o TLS 1.2 tenha sido um enorme sucesso nos últimos dez anos, o cenário de segurança da web em constante mudança e as ameaças cibernéticas emergentes há muito exigem uma melhoria. Depois de uma década em construção e 28 rascunhos para ser definido, o TLS 1.3 foi finalmente lançado em agosto de 2018. Nesta visão geral rápida, mostraremos o que há de novo no TLS 1.3.

Como funciona o TLS?

O TLS usa uma combinação de criptografia simétrica e assimétrica, pois oferece um bom compromisso entre desempenho e segurança ao transmitir dados com segurança.

Com a criptografia simétrica, os dados são criptografados e descriptografados com uma chave secreta conhecida pelo remetente e pelo destinatário, tipicamente 128, mas preferencialmente 256 bits de comprimento (qualquer coisa menor que 80 bits agora é considerada insegura). A criptografia simétrica é eficiente em termos de computação, mas ter uma chave secreta comum significa que ela precisa ser compartilhada de maneira segura.

A criptografia assimétrica usa pares de chaves – uma chave pública e uma chave privada. A chave pública está matematicamente relacionada à chave privada, mas dado o comprimento de chave suficiente, é computacionalmente impraticável derivar a chave privada da chave pública. Isso permite que a chave pública do destinatário seja usada pelo remetente para criptografar os dados que deseja enviar, mas esses dados só podem ser descriptografados com a chave privada do destinatário.

A vantagem da criptografia assimétrica é que o processo de compartilhamento de chaves de criptografia não precisa ser seguro, mas a relação matemática entre as chaves públicas e privadas significa que tamanhos de chave muito maiores são necessários. O comprimento mínimo de chave recomendado é de 1.024 bits, com preferência de 2.048 bits, mas isso é até mil vezes mais intensivo em termos de computação do que as chaves simétricas de força equivalente (por exemplo, uma chave assimétrica de 2048 bits é aproximadamente equivalente a uma chave simétrica de 112 bits) e torna a criptografia assimétrica muito lenta para muitos propósitos.

Por esse motivo, o TLS usa criptografia assimétrica para gerar e trocar com segurança uma chave de sessão. A chave de sessão é então usada para criptografar os dados transmitidos por uma parte e para descriptografar os dados recebidos na outra extremidade. Assim que a sessão termina, a chave da sessão é descartada.

Uma variedade de diferentes métodos de geração e troca de chaves pode ser usada, incluindo RSA, Diffie-Hellman (DH), Diffie-Hellman efêmero (DHE), Curva elíptica Diffie-Hellman (ECDH) e Curva elíptica efêmera Diffie-Hellman (ECDHE). DHE e ECDHE também oferecem sigilo direto em que uma chave de sessão não será comprometida se uma das chaves privadas for obtida no futuro, embora a geração fraca de números aleatórios e/ou o uso de um intervalo limitado de números primos tenham sido postulados para permitir o cracking de até mesmo chaves DH de 1024 bits com recursos de computação de nível de estado. No entanto, eles podem ser considerados problemas de implementação, em vez de problemas de protocolo, e existem ferramentas disponíveis para testar os conjuntos de criptografia mais fracos.

Com o TLS, também é desejável que um cliente conectado a um servidor seja capaz de validar a propriedade da chave pública do servidor. Isso normalmente é realizado usando um certificado digital X.509 emitido por um terceiro confiável conhecido como Autoridade de Certificação (CA), que afirma a autenticidade da chave pública. Em alguns casos, um servidor pode usar um certificado auto assinado que precisa ser explicitamente confiável pelo cliente (os navegadores devem exibir um aviso quando um certificado não confiável é encontrado), mas isso pode ser aceitável em redes privadas e/ou onde a distribuição segura de certificados é possível. No entanto, é altamente recomendável usar certificados emitidos por CAs publicamente confiáveis.

TLS 1.3 é mais rápido que o TLS 1.2

O TLS 1.3 apresenta um novo handshake que reduz o tempo que leva para criptografar uma conexão. Anteriormente, o TLS 1.2 exigia duas viagens de ida e volta para concluir o handshake do TLS, mas agora a versão 1.3 precisa de apenas uma viagem de ida e volta. Essa alteração diminui a latência de criptografia pela metade. Mesmo que a diferença seja em milissegundos, ela aumenta em escala e ajuda as empresas a melhorar o desempenho da rede.

Outro novo recurso que reduz o tempo de criptografia é o Zero Round Trip Time Resumption (0-RTT). Quando um usuário visita novamente o seu site em um curto espaço de tempo, o 0-RTT torna a conexão quase instantânea.

Quais navegadores suportam TLS 1.3?

No momento em que este artigo foi escrito, Chrome (67+), Firefox (61+), Opera (57+), Edge (76) e Safari (12.3), todos suportam a versão mais recente do TLS. O Chrome e o Firefox foram os primeiros a implantar o suporte para TLS 1.3. Use este link para verificar quais versões de navegador são compatíveis com TLS 1.3.

TLS 1.2 vs TLS 1.3: Quais são as principais diferenças?

O TLS 1.3 oferece várias melhorias em relação às versões anteriores, principalmente um handshake de TLS mais rápido e conjuntos de criptografia mais simples e seguros. As trocas de chaves do Zero Round-Trip Time (0-RTT) otimizam ainda mais o handshake TLS. Juntas, essas mudanças fornecem melhor desempenho e segurança mais forte.

Handshake TLS mais rápido

A criptografia TLS e a descriptografia SSL requerem tempo de CPU e adicionam latência às comunicações de rede, degradando um pouco o desempenho. No TLS 1.2, o handshake inicial era realizado em texto não criptografado, o que significa que mesmo ele precisava ser criptografado e descriptografado. Dado que um handshake típico envolvia de 5 a 7 pacotes trocados entre o cliente e o servidor, isso adicionava uma sobrecarga considerável à conexão. Na versão 1.3, a criptografia do certificado do servidor foi adotada por padrão, possibilitando que um handshake TLS fosse realizado com 0 – 3 pacotes, reduzindo ou eliminando esta sobrecarga e permitindo conexões mais rápidas e responsivas.

TLS 1.3 na GoCache

O protocolo TLS 1.3 já é nativamente integrado a ferramenta da GoCache, permitindo que sua aplicação usufrua de todos os benefícios em nível de segurança e performance fornecido por essa versão.

Referencia: https://www.a10networks.com/blog/key-differences-between-tls-1-2-and-tls-1-3/

 

Ataque DDoS? Don’t Worry! Aplique o Rate Limit

/em

Ataques DDoS acabam por se tornar cada vez mais uma ameaça constante à aplicações web, devido a facilidade de se encomendar e/ou aplicar o mesmo utilizando a computação em nuvem, com isso é importante sempre estar preparado para mitigar e se proteger dos danos de um ataque DDoS. Caso você não saiba o que é um ataque DDoS, clique AQUI.

O Rate Limit é conhecido por ser uma ferramenta de alta eficiência quando bem configurado contra ataques DDoS e DoS, já que ambos são baseados em volumetria, que visam por padrão gerar indisponibilidade em alguma aplicação web.

Neste artigo traremos alguns possíveis cenários de ataques, ilustrando como poderíamos mitigá-los utilizando o recurso de Rate Limit da GoCache

Primeiramente, é importante compreender o padrão de acessos de sua aplicação em um momento sem ataque para assim definir limitações seguras que não bloqueiem usuários legítimos. No exemplo a seguir, que é uma aplicação WordPress, começaremos avaliando:

  • Quantidade de requests por IP que acessaram a hospedagem por minuto;
  • Quantidade de requests por IP em áreas sensíveis do site, como um arquivo PHP.

Com essas informações em mãos, podemos destacar alguns destes dados, dispostos nos gráficos abaixo:

Feita a análise, já podemos preparar regras e formular ideias para uma política de segurança, com o objetivo de mitigar algum ataque que venha acontecer.

Considerando que o público-alvo deste site é o Brasil, uma primeira abordagem seria a criação de regras mais restritivas para os acessos provenientes de outros países.

A primeira e mais delicada ação, é a definição de limites seguros para cada perfil de acesso, em que serão utilizados como base os picos de acessos com o acréscimo de uma margem. No nosso caso, adicionaremos 10 acessos, acima do pico de tráfego do dia.

Os acessos a home e ademais (/*) recursos têm um pico de 120 acessos por minuto, provenientes do mesmo IP no Brasil. Dessa forma, iremos criar uma regra para 130 acessos neste período de tempo, limitado ao “País de Origem” Brasil.

Limitação de 130 requisições / minuto de um IP proveniente do Brasil

Agora, podemos nos direcionar para as regras de áreas mais sensíveis do site, como as requests para arquivos .php, veja o exemplo criado:

Limitação de 50 requisições / min em requisições .php

Pelo fato da aplicação ser um WordPress, é preciso ter cuidado com a área logada, esta que por padrão faz muitas requisições de conteúdo dinâmico, seja num /wp-json, /plugin-install.php, /admin-ajax.php, e que poderiam acabar bloqueando um usuário legítimo.

Neste caso, seria possível excluir alguns paths do Rate Limit, e também criar regras mais brandas para acessos feitos pelos administradores do site.

Veja um exemplo:

Regra com uma limitação mais abrangente para usuários logados.

Assim aqueles que estiverem logados e tiverem o cookie que comece com wordpress_logged_in*, poderão ter uma margem maior de requests antes de ativar o Rate Limit.

Com as principais regras criadas, temos uma certa segurança para ataques locais do Brasil. Agora, podemos criar regras mais rígidas para acessos estrangeiros, que possuem um padrão de 30 acessos por minuto, conforme exemplo abaixo:

Limitação de 30 requisições / minuto de um IP de fora do Brasil

Essas regras foram construídas em um cenário fora de ataque, mas supondo que um atacante resolveu fazer um DDoS na aplicação após as regras serem criadas, é possível notar no Analytics (Ferramenta da GoCache que mostra métricas da CDN) que a ferramenta foi bastante eficiente no bloqueio:

Analytics GoCache: Requisições bloqueadas pelo rate-limit em timeline

Neste momento, podemos criar regras para mitigar um ataque que já está ocorrendo, como por exemplo, um ataque de Brute Force de senha.

Supondo um cenário em que o atacante queira fazer um Brute Force no wp-login, e para tentar fazer o bypass de eventuais controles de Rate Limit, crie variações no User Agent, utilizando strings de até 5 caracteres aleatórios ( js321, ksfg, las, 0w324, 99097, 2456d , 4k).

Ao analisar o padrão dos acessos, foi possível identificar que o mesmo fazia requisições de diferentes lugares de fora do Brasil, tentando 20 vezes de cada IP.

Sendo assim, poderíamos mitigar esse ataque usando o Rate Limit com uma regra específica para esse padrão. Vejamos a regra criada:

Customização de rate-limiting utilizando critérios de user-agent e geolocalização

Com essa última regra, podemos bloquear apenas User Agents menores que 5 caracteres, com métodos POSTs, podendo assim bloquear essa tentativa de Brute Force.

Todas as regras em conjunto são ilustrativas para o contexto. O nível de customização da GoCache permite criar limitações combinando uma série de critérios e fazendo uso de expressões regulares.

Quer saber como ter uma aplicação mais segura com a GoCache? Agende uma demonstração.

O que é um ataque de força bruta? Brute Force

/em

Um ataque de força bruta (também conhecido como quebra de força bruta) é um ataque cibernético equivalente a tentar todas as chaves do seu chaveiro e, por fim, encontrar a correta. 5% dos incidentes de violação de dados confirmados em 2017 resultaram de ataques de força bruta.

Os ataques de força bruta são simples e confiáveis. Os invasores permitem que um computador faça o trabalho – tentando diferentes combinações de nomes de usuário e senhas, por exemplo – até encontrarem um que funcione. Capturar e neutralizar um ataque de força bruta em andamento é o melhor contra-ataque: depois que os invasores têm acesso à rede, eles são muito mais difíceis de serem capturados.

Tipos de ataques de força bruta

O ataque de força bruta mais básico é um ataque de dicionário, em que o invasor trabalha por meio de um dicionário de senhas possíveis e tenta todas elas. Ataques de dicionário começam com algumas suposições sobre senhas comuns para tentar adivinhar a partir da lista no dicionário. Esses ataques tendem a ser um tanto desatualizados, devido a técnicas mais novas e eficazes.

Computadores recentes fabricados nos últimos 10 anos podem quebrar com força bruta uma senha alfanumérica de 8 caracteres – letras maiúsculas e minúsculas, números e caracteres especiais – em cerca de duas horas. Os computadores são tão rápidos que podem descriptografar por força bruta um hash de criptografia fraco em poucos meses. Esses tipos de ataques de força bruta são conhecidos como uma busca exaustiva de teclas, em que o computador tenta todas as combinações possíveis de todos os caracteres possíveis para encontrar a combinação certa.

A reciclagem de credenciais é outro tipo de ataque de força bruta que reutiliza nomes de usuário e senhas de outras violações de dados para tentar invadir outros sistemas.

O ataque de força bruta reverso usa uma senha comum como “password” e, subsequentemente, tenta forçar um nome de usuário a acompanhar essa senha. Como “password” é uma das senhas mais comuns em 2017, essa técnica é mais bem-sucedida do que você imagina.

Como se defender contra ataques de força bruta

Ataques de força bruta precisam de tempo para funcionar. Alguns ataques podem levar semanas ou até meses para fornecer algo utilizável. A maioria das defesas contra ataques de força bruta envolve aumentar o tempo necessário para o sucesso além do que é tecnicamente possível, mas essa não é a única defesa.

• Aumentar o comprimento da senha: Mais caracteres equivalem a mais tempo para a quebra de força bruta

• Aumentar a complexidade da senha: Mais opções para cada caracter também aumentam o tempo para quebrar a força bruta

• Limitar as tentativas de login: Ataques de força bruta incrementam um contador de tentativas de login malsucedidas na maioria dos serviços de diretório – uma boa defesa contra ataques de força bruta é bloquear os usuários após algumas tentativas fracassadas, anulando assim um ataque de força bruta em andamento

• Implementar Captcha: Captcha é um sistema comum para verificar se um humano é humano em sites e pode impedir ataques de força bruta em andamento

• Use autenticação multi-fator: A autenticação multi-fator adiciona uma segunda camada de segurança a cada tentativa de login que requer intervenção humana, isso pode impedir o sucesso de um ataque de força bruta

A maneira proativa de impedir ataques de força bruta começa com o monitoramento. Varonis monitora a atividade Active Directory e Tráfego VPN para detectar ataques de força bruta em andamento. Temos modelos de ameaças que monitoram comportamentos de bloqueio (geralmente um sinal de que há um ataque de força bruta em andamento), modelos de ameaças que detectam o potencial de preenchimento de credenciais e muito mais – todos projetados para detectar e prevenir ataques de força bruta antes que o ataque se intensifique.

É melhor detectar um ataque em andamento e interromper ativamente o ataque do que esperar que as suas senhas não possam ser quebradas. Depois de detectar e interromper o ataque, você pode até mesmo colocar endereços IP na lista negra e evitar outros ataques do mesmo computador.

O que é um ataque de força bruta?

Um ataque de força bruta, ou pesquisa exaustiva, é um hack criptográfico que usa tentativa e erro para adivinhar possíveis combinações de senhas usadas para logins, chaves de criptografia ou páginas da web ocultas.

Referencia: https://www.varonis.com/blog/brute-force-attack/

Cross-site Scripting – O que é?

/em

O que é cross-site scripting (XSS)?

Cross-site scripting (também conhecido como XSS) é uma vulnerabilidade de segurança da web que permite que um invasor comprometa as interações que os usuários têm com um aplicativo vulnerável. Ele permite que um invasor contorne a política de mesma origem, que é projetada para separar sites diferentes uns dos outros. As vulnerabilidades de script entre sites normalmente permitem que um invasor se disfarce de usuário vítima, execute quaisquer ações que o usuário possa realizar e acesse qualquer um dos dados do usuário. Se o usuário vítima tiver acesso privilegiado ao aplicativo, o invasor poderá obter controle total sobre todas as funcionalidades e dados do aplicativo.

Como funciona o XSS?

O script entre sites funciona manipulando um site vulnerável para que ele retorne JavaScript malicioso para os usuários. Quando o código malicioso é executado dentro do navegador da vítima, o invasor pode comprometer totalmente a interação com o aplicativo.

Prova de conceito XSS

Você pode confirmar a maioria dos tipos de vulnerabilidade XSS injetando uma carga que faz com que o seu próprio navegador execute algum JavaScript arbitrário. Há muito tempo é uma prática comum usar a função alert()para esse propósito, porque é curta, inofensiva e muito difícil de perder quando é chamada com sucesso. Na verdade, você resolve a maioria de nossos laboratórios de XSS invocando alert() no navegador de uma vítima simulada.

Infelizmente, há um pequeno problema se você usar o Chrome. A partir da versão 92 (20 de julho de 2021), iframes de origem cruzada são impedidos de chamar alert(). Como eles são usados ​​para construir alguns dos ataques XSS mais avançados, às vezes você precisará usar uma carga útil PoC alternativa. Neste cenário, recomendamos a função print().

Como a vítima simulada em nossos laboratórios usa o Chrome, alteramos os laboratórios afetados para que eles também possam ser resolvidos usando print(). Indicamos isso nas instruções sempre que for relevante.

Quais são os tipos de ataques XSS?

Existem três tipos principais de ataques XSS. Estes são:

• XSS refletido, em que o script malicioso vem da solicitação HTTP atual.

• XSS armazenado, onde o script malicioso vem do banco de dados do site.

• XSS baseado em DOM, onde a vulnerabilidade existe no código do lado do cliente em vez de no código do lado do servidor.

Perguntas comuns sobre cross-site scripting

Quão comuns são as vulnerabilidades XSS? Vulnerabilidades XSS são muito comuns e XSS é provavelmente a vulnerabilidade de segurança da web que ocorre com mais frequência.

Quão comuns são os ataques XSS? É difícil obter dados confiáveis ​​sobre ataques XSS do mundo real, mas provavelmente são explorados com menos frequência do que outras vulnerabilidades.

Qual é a diferença entre XSS e CSRF? XSS envolve fazer com que um site retorne JavaScript malicioso, enquanto CSRF envolve induzir um usuário vítima a executar ações que não pretende fazer.

Qual é a diferença entre XSS e injeção SQL? XSS é uma vulnerabilidade do lado do cliente que visa outros usuários do aplicativo, enquanto a injeção de SQL é uma vulnerabilidade do lado do servidor que visa o banco de dados do aplicativo.

Como posso prevenir XSS em PHP? Filtre as suas entradas com uma lista de permissões de caracteres permitidos e use dicas de tipo ou conversão de tipo. Fuja das suas saídas com htmlentities e ENT_QUOTES para contextos HTML ou escapes Unicode JavaScript para contextos JavaScript.

Como faço para evitar XSS em Java? Filtre as suas entradas com uma lista de permissões de caracteres permitidos e use uma biblioteca como o Google Guava para codificar em HTML a sua saída para contextos HTML ou use escapes Unicode JavaScript para contextos JavaScript.

Referencia: https://portswigger.net/web-security/cross-site-scripting

Mais transparência e flexibilidade para o WAF

/em

Sabemos que assertividade é palavra chave quando se trata de proteger aplicações contra ameaças com o mínimo impacto possível sobre a audiência legítima. Por isso, avançamos mais um passo nessa direção, trazendo mais transparência e flexibilidade para nossa solução de WAF.

Clientes da GoCache agora podem alterar o comportamento das regras de WAF para ajustá-lo ao comportamento de sua aplicação. Cada regra de WAF pode se comportar de maneira diferente em aplicações diferentes, sendo que algumas regras nem fazem sentido para determinadas aplicações, enquanto outras podem ser mais assertivas, ou até mesmo menos assertivas, mas não menos importantes.

Essa customização toma proveito de toda a flexibilidade das smart rules, de forma que, caso seja necessário desativar uma regra para minimizar falsos positivos, você pode limitar esse contexto da forma mais estreita possível para evitar brechas de segurança.

No exemplo a seguir, temos um site cujas páginas do caminho /blog são servidas por WordPress, enquanto o resto do site não. O grupo de regras gocache-v1/90* protege contra ameaças específicas ao WordPress, portanto, não é necessário aplicá-lo em todo o site. Esta configuração desativa esse grupo de regras em todo o site, habilitando com o comportamento padrão apenas em caminhos que comecem com /blog. Você pode entender melhor o funcionamento através da documentação disponível em https://docs.gocache.com.br/waf_custom/.

Ainda temos muitas novidades a divulgar, que permitirão um maior nível de assertividade das soluções de segurança, com menos necessidade de gerenciamento por parte do usuário. Fique atento ao nosso blog. Se não for cliente, faça sua conta, com 7 dias de teste gratuito, em https://painel.gocache.com.br/trial, para conhecer essa e outras soluções.