Fonte original: Edgecast
A segurança de aplicativos da Web continua a ser um vetor de ameaças de topo para organizações grandes e pequenas. De acordo com o Relatório de Investigações de Violação de Dados da Verizon 2020 (DBIR), 43% de todas as violações de dados envolveram um aplicativo da web,¹ e 80% de todos os vetores de hackers têm como alvo aplicações da web.²
No quarto trimestre de 2020, a Verizon Media viu um aumento acentuado no tráfego de scripts entre sites (XSS) na nossa rede de distribuição de conteúdo (CDN) em comparação com os trimestres anteriores. Este blog explora alguns pontos de dados de tráfego e disseca uma das maiores tentativas de pagamento do XSS. Também partilhamos como utilizar estes dados para aplicar medidas de proteção.
Use este conteúdo como um guia orientado por ação para lidar com tráfego XSS potencialmente malicioso batendo na porta da frente da sua organização. Também pode ajudá-lo a ter uma conversa de segurança necessária com a sua equipa de liderança e os seus colegas de negócio/operacional.
We Ter os dados, vamos explorá-los
The A Verizon Media WAF mitigou 1,5 mil milhões de pedidos no quarto trimestre de 2020. Definimos “mitigar” como qualquer evento WAF que desencadeou um bloco, uma resposta personalizada ou um redirecionamento de URL. Estes 1,5 mil milhões de blocos representam pedidos de HTTP que, de outra forma, teriam chegado aos servidores de origem dos nossos clientes. Estes dados dizem-nos:
- A quantidade de verificação de vulnerabilidade em segundo plano é imensa. Estão enganados se acham seguros porque o vosso alvo não vale a pena atacar ou porque não são bem conhecidos. De acordo com o Verizon DBIR, “se nos permitirem uma metáfora mista, não há como evitar o urso neste caso, porque os ursos estão todos a ser impressos em 3D a granel e automatizados para caçar-vos.”³
- Se as suas aplicações web estiverem seguras, tal digitalização pode não parecer mais prejudicial do que um maçanetas de portas de roubo, e permitir que esse tráfego chegue aos seus servidores é inofensivo, exceto incorrer em carga adicional no seu servidor. Mas na guerra assimétrica de cibersegurança, o atacante só tem de estar certo uma vez, tornando assim mais fácil para eles estarem certos no futuro. Então, por que deixar o assaltante mexer o maçaneta da porta se você puder evitá-lo?
Para conduzir esta casa um pouco mais longe, vamos dar uma olhada em alguns dos tráfegos bloqueados do quarto trimestre de 2020.
O tráfego bloqueado de scripts entre sites (XSS) nos últimos três trimestres passou do primeiro lugar no 2º trimestre de 2020 para o quarto lugar no 4º trimestre de 2020, quase duplicando em volume durante este período de tempo, representando 10% do tráfego bloqueado.
Figura 1. Em apenas seis meses, vimos o tráfego do XSS mais do que o dobro.
Getting Conhecer o seu tráfego XSS
According Para o Open Web Application Security Project (OWASP), falhas do XSS ocorrem quando uma aplicação inclui dados não confiáveis numa nova página da Web sem validação ou fuga adequadas ou quando uma aplicação atualiza uma página da Web existente com dados fornecidos pelo utilizador utilizando uma API de browser que pode criar HTML ou JavaScript. O XSS permite que os invasores executem scripts no navegador da vítima, que podem sequestrar sessões do usuário, desencarar sites ou redirecionar o usuário para sites maliciosos.
Esta exposição ameaça a sua infraestrutura, a confidencialidade e integridade dos dados e a disponibilidade de dados fornecidos pela Internet. Esses ataques podem resultar em acesso não autorizado a conteúdo, perda de informações de identificação pessoal (PII) e disseminação de informações privadas/protegidas por direitos autorais.
Este é um problema, uma vez que nada é escondido da vista uma vez que está ligado e exposto à Internet: Se o levantar, ele será analisado. Uma vez que uma nova aplicação web entra online e é exposta à Internet, será testada para ver como reage a diferentes ações ou pedidos. Os resultados destas descobertas podem criar uma reviravolta interessante no enredo, que discutiremos em breve.
Primeiro, vamos continuar a explorar o âmbito da exposição potencial. Muitos websites, aplicações web e servidores recebem e processam pedidos fora da rede interna protegida de uma empresa. Como resultado, eles são vulneráveis a várias ameaças maliciosas agrupadas pelo OWASP, incluindo injeções de SQL, XSS e ataques distribuídos de negação de serviço (DDoS) na camada de aplicação.
Considerando o aumento dos ataques XSS detetados pelo Verizon WAF, não é surpresa que o XSS esteja no topo da lista do MITRE CKE Top 25 em 2020 também:⁴
Figura 2. Uma breve lista dos pontos fracos no Top 25 do CKE de 2020, incluindo a pontuação geral de cada um.
Tal como vimos um aumento no tráfego bloqueado do XSS, também o número de vulnerabilidades reais documentadas no National Vulnerability Database (NVD) que também estão ligadas a explorações do XSS:
- 513 vulnerabilidades do XSS documentadas nos últimos três meses (171 por mês)
- 5,507 vulnerabilidades do XSS documentadas nos últimos três anos (153 por mês)
- 16,936 vulnerabilidades XSS documentadas o tempo todo
Sim, os defensores usam as mesmas ferramentas que os atacantes para investigar vulnerabilidades. Portanto, é importante reconhecer o potencial de que a existência de tráfego malicioso não significa necessariamente que haja uma má intenção por trás do tráfego. Mas poderia haver.
No mínimo, se um mau ator curioso analisar com sucesso um sistema, eles poderiam tentar uma exploração do XSS – tudo no espírito de realizar reconhecimento. Pior ainda, a atividade de reconstrução – e os resultados obtidos com ela – poderia ser usada para deixar cair uma carga comprometedora ou destrutiva via XSS ou usada como um trampolim para algo mais nefasto, como uma falsificação de solicitação no lado do servidor (SSRF).
Is É um excelente trampolim, vejo?
Remember O cenário de jiggling de maçaneta que mencionámos anteriormente? É hora de trazer essa metáfora de volta.
A maior parte do tráfego e eventos do XSS pode não ser fundamental para si mesmos, mas podem levar a desafios e problemas significativos no caminho, um passo para um compromisso bem-sucedido, se quiserem.
Ataques XSS bem-sucedidos podem permitir que os invasores executem HTML e JavaScript arbitrários no navegador da vítima. Normalmente, o utilizador terá de interagir com algum link malicioso que aponte para uma página controlada por um intruso, tais como sites ou anúncios.
Vejamos a violação da regra principal para o quarto trimestre de 2020, designada internamente como a ID da regra 941100, que mapeou uma das maiores cargas úteis, demonstrando a capacidade de usar o XSS como um ataque de passos:
><Script >alert(String.fromCharCode(88,83,83))</>script
Esta é uma cadeia de teste XSS muito comum em muitos repositórios de código, como o htmlpurifier.org.⁵, enquanto procura validar se esta carga em particular irá funcionar, é apresentada uma caixa de alerta com a cadeia de carateres “XSS”, verificando imediatamente ao intruso que um website específico está vulnerável a XSS refletido.
Uma vez que um intruso verifica que existe um XSS refletido, os “ataques refletidos são entregues através de outra rota, como numa mensagem de correio eletrónico, ou noutro website. Quando um utilizador é enganado a clicar num link malicioso, a enviar um formulário especialmente concebido para o efeito, ou mesmo a navegar num site malicioso, o código injetado viaja para o Web site vulnerável, o que reflete o ataque de volta ao browser do utilizador.”⁶
Figura 3. Como os ciberatacantes aproveitam as vulnerabilidades do XSS.
Este ataque pode executar qualquer coisa no website que o utilizador que está a ser atacado possa executar, incluindo a “divulgação do cookie de sessão do utilizador, permitindo que um intruso sequestrar a sessão do utilizador e assumir a conta.”⁷ Por exemplo, um script que altera a palavra-passe de um utilizador enviado em nome do utilizador pode resultar na aquisição de uma conta.
Há outros exemplos de passos a serem invocados. Em outro caso documentado publicamente, um ataque de SSRF foi iniciado originalmente através de uma exploração do XSS, e o pesquisador de segurança “conseguiu escalar do XSS dentro de uma imagem até uma leitura arbitrária de arquivos locais no servidor”⁸
Nem todos os investigadores (nem o cibercriminoso) serão suficientemente pacientes para ligar a sua exploração do XSS a algo mais significativo. No entanto, ter um XSS para coisas maiores e melhores parece ser um método comum para alguns pesquisadores que procuram ganhar o grande prémio nos seus programas de recompensa de erros.
Mitigation e defense
Na ausência de dados, é difícil tomar uma decisão. No entanto, torna-se mais fácil identificar um caminho que leva ao resultado desejado, uma vez que você tenha visibilidade de uma situação. Aqui está uma coleção de dicas e recursos para ajudar a mitigar o risco que o tráfego XSS traz para a sua rede e para o seu negócio.
- Certifique-se de que está ciente de todos os dispositivos que enfrentam a Internet e de que tanto os sistemas legados como os de teste são considerados para serem endurecidos ou offline. Isto é especialmente importante na era da infraestrutura em nuvem, onde as equipas de desenvolvimento podem girar máquinas com apenas alguns cliques ou enviando um formulário.
- Configure e proteja adequadamente os servidores web. Considere usar ferramentas como o Center for Internet Securities Benchmark para entender como configurar os controles do seu servidor. Configure corretamente as configurações de TLS para proteger contra ataques MITM.
- Corrija regularmente todos os servidores voltados para a Internet. Às vezes, frameworks comumente usados são vulneráveis ao XSS. Em fevereiro de 2021, a base de dados ATT&CK DA MITRE lista quase 17 000 vulnerabilidades e fraquezas com alguma ligação ao XSS.
- Verifique periodicamente a eficácia do seu reforço de segurança. Use as mesmas ferramentas de teste dinâmico de segurança de aplicativos (DAST) que os invasores usam, como o OWASP ZAP ou ferramentas similares de verificação de vulnerabilidade no Kali Linux. Como alternativa, use um serviço de teste de penetração ou DAST para descobrir e analisar servidores vulneráveis voltados para a Internet.
- Ative um firewall de aplicação web (WAF) para bloquear ataques comuns.
- Mantenha o WAF atualizado para bloquear imediatamente quaisquer vulnerabilidades descobertas, permitindo que a equipa de aplicações implante uma correção. Atualizar o WAF à medida que novas regras estão disponíveis para proteger contra vulnerabilidades descobertas recentemente.
- Ativar o registo e inspecionar esses registos.
- Proteja seus sites e infraestrutura de rede crítica contra ataques volumétricos usando um serviço de DNS autoritário altamente redundante e serviços de proteção DDoS altamente distribuídos e aceleração da web, ou seja, a CDN.
Comece com o seu data
Você pode ter seus aplicativos aperfeiçoados para fornecer conteúdo e um conjunto robusto de controles de segurança para ajudar a mitigar riscos e talvez até bloquear ataques que o fazem entrar. Ainda assim, por que deixar o tráfego potencialmente prejudicial entrar na sua rede em primeiro lugar? Por que arriscar que uma política é perdida ou que um controlo é ignorado?
Os clientes da Verizon Media Security têm duas capacidades na ponta dos dedos que podem protegê-los de ameaças:
- Vemos tráfego de rede potencialmente prejudicial (ou pelo menos inútil) a atingir o seu site.
- O Verizon Media WAF integrado pode ser ativado para bloquear tráfego malicioso antes de se tornar um problema automaticamente.
Dê um passo importante para melhorar a segurança das suas aplicações web, contacte-nos hoje para saber mais.
Referências
- Verizon, “ Relatório de Investigações de Violação de Dados de 2020,” Verizon.com/business.com, enterprise.verizon.com/resources/reports/dbir/. Página 7.
- Ibid, página 88.
- Ibid, página 23.
- CKE, “2020 CKE Top 25 Most Dangerous Software Fraquezas ” CWE.mitre.org, cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html.
- HTMLpurifier, “HTML purificador XSS ataca Smoketest,” HTMLpurifier.org, htmlpurifier.org/live/smoketests/xssAttacks.php.
- OWASP, “ Cross site scripting (XSS), owasp.org, owasp.org/www-community/attacks/xss/
- Ibid
- “Escalando XSS na renderização de imagens de PhantomJS para SSRF/LOCAL-file read, buer.haus. 29 de junho de 2020.
