Home Artigos técnicos Ataques de Scripts entre sites (XSS) no 4º trimestre de 2020: Tendências e Melhores Práticas
Applications

Ataques de Scripts entre sites (XSS) no 4º trimestre de 2020: Tendências e Melhores Práticas

About The Author

Outline

Fonte original: Edgecast

A segurança de aplicativos da Web continua sendo 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 visam aplicativos da Web²

No quarto trimestre de 2020, a Verizon Media viu um aumento acentuado no tráfego de scripts entre sites (XSS) em nossa rede de entrega de conteúdo (CDN) em comparação aos trimestres anteriores. Este blog explora alguns pontos de dados de tráfego e disseca uma das maiores tentativas de pagamento do XSS. Também compartilhamos como usar esses 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 mal-intencionado batendo na porta da frente da sua organização. Ele também pode ajudá-lo a ter uma conversa de segurança necessária com sua equipe de liderança e suas contrapartes comerciais/operacionais.

‍We Ter os dados – vamos explorá-los

‍The A Verizon Media WAF mitigou 1,5 bilhões de pedidos no quarto trimestre de 2020. Definimos “mitigar” como qualquer evento WAF que acionou um bloco, resposta personalizada ou redirecionamento de URL. Esses 1,5 bilhões de blocos representam solicitações HTTP que, de outra forma, teriam alcançado os servidores de origem de nossos clientes. Estes dados nos dizem:

  1. A quantidade de varredura de vulnerabilidade em segundo plano é imensa. Você está enganado se acha que está seguro porque seu alvo não vale a pena atacar ou porque você não é bem conhecido. De acordo com o Verizon DBIR, “se você nos permitir uma metáfora mista, não há nenhuma saída do urso neste caso, porque os ursos estão todos sendo impressos em 3D a granel e automatizados para caçar você.”³
  2. Se seus aplicativos da web estão protegidos, essa verificação pode parecer não mais prejudicial do que um maçanetas de portas de roubo, e permitir que esse tráfego alcance seus servidores é inofensivo, além de incorrer em carga adicional em seu servidor. Mas na guerra assimétrica de segurança cibernética, o invasor só precisa estar certo uma vez, tornando assim mais fácil para eles estarem certos no futuro. Então, por que deixar o ladrão jiggle a maçaneta se você pode 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 de script entre sites bloqueados (XSS) nos últimos três trimestres passou do primeiro lugar no segundo trimestre de 2020 para o quarto lugar no quarto trimestre de 2020, quase dobrando em volume durante esse período de tempo, representando 10% do tráfego bloqueado.

Figura 1. Em apenas seis meses, vimos o tráfego 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 um aplicativo inclui dados não confiáveis em uma nova página da Web sem validação ou fuga adequada ou quando um aplicativo atualiza uma página da Web existente com dados fornecidos pelo usuário usando uma API do navegador que pode criar HTML ou JavaScript. O XSS permite que invasores executem scripts no navegador da vítima, que podem sequestrar sessões de usuários, desencarar sites ou redirecionar o usuário para sites maliciosos.

Essa exposição ameaça sua infraestrutura, confidencialidade e integridade de dados e a disponibilidade de dados fornecidos pela Internet. Esses ataques podem resultar em acesso não autorizado ao 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 é oculto da vista uma vez que está ligado e exposto à Internet: Se você levantar, ele será escaneado. Uma vez que um novo aplicativo da web vem on-line e fica exposto à Internet, ele será testado para ver como ele reage a diferentes ações ou solicitações. Os resultados dessas descobertas podem criar uma reviravolta interessante no enredo, que discutiremos em breve.

Primeiro, vamos continuar explorando o escopo da exposição potencial. Muitos sites, aplicativos da Web e servidores recebem e processam solicitações 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 do aplicativo.

Considerando o aumento dos ataques XSS detetados pelo Verizon WAF, não é nenhuma surpresa que o XSS esteja no topo da lista do MITRE CWE Top 25 para 2020 também:⁴

Figura 2. Uma breve lista dos pontos fracos no Top 25 do CWE de 2020, incluindo a pontuação geral de cada um.

Assim como vimos um aumento no tráfego XSS bloqueado, também o número de vulnerabilidades reais documentadas no National Vulnerability Database (NVD) que também estão conetadas a exploits 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 intenção maligna por trás do tráfego. Mas poderia haver.

No mínimo, se um mau ator curioso varre com sucesso um sistema, eles poderiam tentar uma exploração do XSS – tudo no espírito de realizar reconhecimento. Pior, a atividade de reconstrução – e os resultados obtidos com ela – poderiam ser usados para deixar cair uma carga comprometedora ou destrutiva via XSS ou usados como um trampolim para algo mais nefasto, como uma falsificação de solicitação do lado do servidor (SSRF).

‍Is Que um “excelente trampolim”, eu vejo?

‍Remember O cenário de jiggling de maçaneta que mencionamos anteriormente? É hora de trazer essa metáfora de volta.

A maioria dos eventos e tráfego XSS pode não ser crítica para si mesmos, mas eles podem levar a desafios e problemas significativos no caminho – um passo para um compromisso bem-sucedido, se você quiser.

Ataques XSS bem-sucedidos podem permitir que invasores executem HTML e JavaScript arbitrários no navegador da vítima. Normalmente, o usuário precisará interagir com algum link malicioso que aponte para uma página controlada por invasor, como sites ou anúncios.

Vejamos a violação da regra superior para o quarto trimestre de 2020, designada internamente como ID da regra 941100, que mapeou uma das cargas úteis superiores, demonstrando a capacidade de usar o XSS como um ataque de passos:

“>< >Script alert(String.fromCharCode(88,83,83))</>script “

Esta é uma string de teste XSS muito comum em muitos repositórios de código, como o htmlpurifier.org.⁵ Ao procurar validar se essa carga útil em particular funcionará, uma caixa de alerta pop-up com a string “XSS” é exibida, verificando imediatamente ao invasor que um site específico está vulnerável a XSS refletido.

Depois que um invasor verificar se existe um XSS refletido, os “ataques refletidos são entregues por outra rota, como em uma mensagem de e-mail ou outro site. Quando um usuário é enganado a clicar em um link malicioso, enviar um formulário especialmente criado, ou até mesmo apenas navegar em um site malicioso, o código injetado viaja para o site vulnerável, o que reflete o ataque de volta ao navegador do usuário.⁶

Figura 3. Como os ciberatacantes aproveitam as vulnerabilidades do XSS.

Esse ataque pode executar qualquer coisa no site que o usuário que está sendo atacado possa executar, incluindo a “divulgação do cookie de sessão do usuário, permitindo que um invasor sequestrar a sessão do usuário e assumir a conta.”⁷ Por exemplo, um script alterando a senha de um usuário enviada em nome do usuário pode resultar em uma aquisição de conta.

Há outros exemplos de passos a serem invocados. Em outro caso documentado publicamente, um ataque SSRF foi originalmente iniciado através de uma exploração XSS, e o pesquisador de segurança “foi capaz de escalar do XSS dentro de uma imagem até uma leitura arbitrária de arquivos locais no servidor”⁸

Nem todo pesquisador (nem cibercriminoso) será paciente o suficiente para vincular sua exploração do XSS a algo mais significativo. No entanto, manter um XSS para coisas maiores e melhores parece ser um método comum para alguns pesquisadores que procuram marcar o grande prêmio em seus programas de recompensa de bugs.

‍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 o 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 sua rede e seu negócio.

  1. Certifique-se de que você esteja ciente de todos os dispositivos voltados para a Internet e de que ambos os sistemas legados e de teste sejam considerados para proteção ou offline. Isso é especialmente importante na era da infraestrutura em nuvem, onde as equipes de desenvolvimento podem girar máquinas com apenas alguns cliques ou enviando um formulário.
  2. Configure e proteja adequadamente os servidores da Web. Considere usar ferramentas como o Center for Internet Securities benchmarks para entender como configurar os controles do seu servidor. Configure corretamente suas configurações TLS para proteger contra ataques MITM.
  3. Corrija regularmente todos os servidores voltados para a Internet. Às vezes, frameworks comumente usados são vulneráveis ao XSS. A partir de fevereiro de 2021, o banco de dados ATT&CK DA MITRE lista quase 17 000 vulnerabilidades e fraquezas com alguma conexão com o XSS.
  4. Verifique periodicamente a eficácia do seu endurecimento 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 de verificação de vulnerabilidades semelhantes no Kali Linux. Alternativamente, use um SERVIÇO de teste de penetração ou DAST para descobrir e verificar servidores vulneráveis voltados para a Internet.
  5. Ative um firewall de aplicativo da Web (WAF) para bloquear ataques comuns.
  6. Mantenha o WAF atualizado para bloquear imediatamente qualquer vulnerabilidade descoberta, permitindo que a equipe de aplicativos implante uma correção. Atualize o WAF à medida que novas regras estão disponíveis para proteger contra vulnerabilidades descobertas recentemente.
  7. Ative o registo e inspecione esses registos.
  8. Proteja seus sites e infraestrutura de rede crítica contra ataques volumétricos usando um serviço DNS autoritativo altamente redundante e serviços de proteção DDoS altamente distribuídos e aceleração da web, ou seja, o CDN.

Comece com o seu data‍

Você pode ter seus aplicativos finamente ajustados 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 tornam interno. Ainda assim, por que deixar o tráfego potencialmente prejudicial entrar em sua rede em primeiro lugar? Por que arriscar que uma política é perdida ou que um controle é ignorado?

Os clientes da Verizon Media Security têm dois recursos na ponta dos dedos que podem protegê-los contra ameaças:

  1. Visualizamos tráfego de rede potencialmente prejudicial (ou pelo menos inútil) atingindo seu site.
  2. O Verizon Media WAF integrado pode ser habilitado para bloquear tráfego malicioso antes que ele se torne um problema automaticamente.

Dê um passo importante para melhorar a segurança de suas aplicações web, entre em contato conosco hoje para saber mais.

Referências

  1. 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.
  2. Ibid, página 88.
  3. Ibid, página 23.
  4. CWE, “2020 CWE Top 25 Maiores Fraquezas de Software Mais Perigosas” CWE.mitre.org, cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html.
  5. HTMLpurifier, “HTML purificador XSS ataca Smokettest,” HTMLpurifier.org, htmlpurifier.org/live/smoketests/xssAttacks.php.
  6. OWASP, “Cross site scripting (XSS)” owasp.org, owasp.org/www-community/attacks/xss/
  7. Ibid
  8. Buerhaus, Brett, “Escalando XSS na renderização de imagem PhantomJS para SSRF/LOCAL-file read, buer.Haus. 29 de junho de 2020.