Secure Internet Access Enterprise: como detectar JavaScript mal-intencionado com o gateway seguro da Web
Escrito por: Jordan Garzon
Introdução
Imagine um mundo sem JavaScript. Não consigo contar o número de vezes que meus colegas e eu pensamos sobre isso em algum momento de nossas carreiras e, a partir de agora, um mundo sem JavaScript é difícil de imaginar. Como alguém que trabalha em uma empresa que vem lidando com JavaScript há vários anos, estou bem ciente de seus desafios e sobre sua predominância em nosso setor. Na verdade, a proteção JavaScript continua sendo uma grande parte de nossa missão, quer gostemos ou não.
O JavaScript está em todos os lugares. Cada solicitação para um website e aplicação móvel carrega dezenas de linhas de código JavaScript; todo navegador oferece suporte ao JavaScript. Ele é tão onipresente que poderia ser facilmente considerado uma tecnologia crítica, que molda a maneira como os websites são criados e como funcionam. E, como todos sabemos, na segurança, quanto mais crítica uma tecnologia, mais maneiras ela pode ser usada maliciosamente.
Uma vez que é tão difundido, segmentar e utilizar o JavaScript fornece aos adversários a chance de criar danos significativos abusando da enorme superfície de ataque que o JavaScript fornece. O possível impacto de um grande vetor foi ilustrado pela vulnerabilidade Log4j , descoberta em dezembro de 2021, um vetor de ataque que forneceu escala imediata após sua exploração. A Log4j, uma biblioteca Java, fornece recursos de criação de logs, uma funcionalidade básica que quase todos os desenvolvedores usam. Essa é a diferença entre as vulnerabilidades do JavaScript e outras vulnerabilidades: sua enorme presença entre os códigos de produção.
Com tudo isso em mente, a pergunta sempre presente prevalece: "Então, o que podemos fazer sobre isso?" Depois de ver os estragos causados pela Log4j, decidimos tentar responder definitivamente à pergunta e iniciamos uma investigação para entender e detectar JavaScript malicioso. Isso levou ao projeto sobre o que estou escrevendo hoje. A pesquisa de segurança é sempre divertida, e quando vimos nossa teoria funcionar, demos um passo adiante e experimentamos algumas situações contextuais do mundo real.
Nesta publicação do blog, quero contar sobre nossa investigação e as técnicas que usamos para identificar e isolar JavaScript malicioso, a fim de criar um novo recurso em nosso produto. Ele incluirá uma revisão do cenário de ameaças quando se trata de ameaças relacionadas ao JavaScript, incluindo arquitetura do sistema, algoritmos aplicados e um estudo de caso.
Cenário de ameaça de JavaScript malicioso
Antes de entrarmos a fundo no projeto, vamos olhar para o cenário que faz do JavaScript malicioso um vetor de ameaça tão notável. Já mencionei sua penetração, mas qual nível de profundidade ele atinge? Entender esse fator realmente coloca o projeto em perspectiva. Abaixo estão descritos alguns dos ataques mais prevalentes usando JavaScript.
Exploração do navegador
Não preciso dizer o quanto essa ameaça é grande: navegadores e plug-ins de navegadores são um elemento-chave de qualquer pessoa com um computador. Um grande exemplo é apresentado com o Browser Exploitation Framework Project (Projeto de estrutura de exploração de navegador), também conhecido como BeEF. O BeEF é uma ferramenta de teste de penetração focada em navegadores da Web, um dos maiores vetores de ataque do lado do cliente, que esclarece bem a capacidade de exploração.
Skimmers
Os skimmers são um exemplo infame de como a segurança virtual pode afetar a vida fora do mundo corporativo e se tornar muito pessoal. Uma vez que o JavaScript controla o Document Object Model (Modelo de objeto de documento), ele é capaz de modificar não apenas o HTML gerado, mas também as solicitações HTTP destacadas. Isso pode ser visto em uma ação tão simples quanto um usuário clicando em um botão.
Um exemplo real disso pode ser derivado de qualquer site com comércio digital associado. Se um JavaScript malicioso for injetado em um site benigno, todas as credenciais de cartão de crédito capturadas pelo skimmer podem ser redirecionadas para o invasor. O caso mais notável disso foi o ataque Magecart no website da British Airways em 2018, que roubou aproximadamente 380.000 números de cartão de crédito.
O skimming se transformou desde 2018. Uma maneira comum de usar essa técnica hoje é substituindo endereços bitcoin pelo endereço do invasor em um site benigno, como vimos com o grupo Lazarus nos últimos anos.
Clickjacking
Embora operar em um website benigno permita uma ampla divulgação, isso é limitado em escopo em comparação com um servidor sobre o qual você mantém controle total. Se o invasor pode fazer o usuário ir até ele, o invasor tem vantagem. Isso permite um impacto significativamente maior para o invasor. Uma vez que as vítimas pousam em seu território, o invasor pode fazê-los baixar malware, recuperar informações de sua sessão de navegação e executar muitas outras atividades maliciosas.
Uma maneira clássica de fazer isso é criar um iframe transparente em cima de um legítimo, dando aos usuários uma falsa sensação de segurança quando clicam nele. Este iframe redireciona os usuários para o servidor controlado pelo invasor, no qual os invasores podem executar suas inúmeras atividades maliciosas.
Cryptomining não autorizado
O cryptomining ganhou muita atenção nos últimos anos com o aumento severo de criptomoedas usadas atualmente. Por que não usar a CPU do usuário para extrair criptomoedas? Especialmente quando isso requer apenas uma linha de JavaScript. A biblioteca mais famosa para isso foi a Coinhive, supostamente fechada em 2019, mas que desde então foi substituída por exemplos como CoinIMP ou CryptoLOOT.
Mecanismo de detecção de JavaScript malicioso – arquitetura e algoritmos
Agora que já analisamos o cenário, é hora de chegar ao que criamos. Existem duas maneiras de inserir JavaScript em um website: escrevendo um arquivo JavaScript no mesmo servidor ou usando um existente de outra fonte e inserindo o link na página HTML. No lado proxy, veremos duas solicitações HTTP diferentes, uma para o HTML e outra para o arquivo JavaScript. Ao entrar em um único website, seu navegador pode estar realizando centenas de solicitações HTTP para renderizar todo o website.
Você também pode escrever o código JavaScript no próprio HTML. Em seguida, nenhuma solicitação adicional é necessária para recuperá-lo. Ao discutir como detectar JavaScript malicioso, é necessário haver uma maneira de abordar ambos os lados, que é o que criamos.
Nosso novo mecanismo é capaz de extrair os códigos JavaScript "inline" e escaneá-los separadamente. Abaixo está um trecho da página de origem do website do mostrando estes dois tipos de JavaScript:
Trecho do código HTML do website do New York Times (https://www.nytimes.com/) em 2 de fevereiro de 2022
O SWG (gateway seguro da Web) Secure Internet Access Enterprise da Akamai é composto por diferentes mecanismos que verificam o tráfego em tempo real. Ele também está conectado à nossa inteligência contra ameaças e conta com a tecnologia de nossos algoritmos personalizados.
High-level overview of the Enterprise Threat Protector secure web gateway
Vamos aplicar zoom dentro da caixa vermelha rotulada "Modelos de JS":
Banco de dados
Os modelos dependem de um banco de dados relacional para manter metadados e armazenar o código JavaScript real por meio de um fornecedor de armazenamento.
O banco de dados inclui um conjunto de treinamento, ou seja, nossos dados rotulados. Os dados benignos são provenientes principalmente de JavaScript popular visto em nosso tráfego. Os dados maliciosos são preenchidos com várias fontes: VirusTotal (VT), detecções de outros algoritmos e código malicioso que realmente detectamos. Portanto, ele é constantemente atualizado.
O banco de dados também contém o conjunto de testes, que contém basicamente os últimos dias de tráfego que vemos no proxy.
Modelo para detecção em tempo real
Para ser capaz de detectar JavaScript malicioso em tempo real, usamos regras YARA que implantamos na edge. Essas regras são criadas com base no conjunto de treinamento. Como a criação de regras não é uma tarefa fácil, baseamos um algoritmo nesse artigo que gera automaticamente as regras Yara. Nós o adaptamos para classificar o código JavaScript em vez de binário, e mudamos a lógica de geração de regras, o que significa que podemos atualizar o mecanismo JavaScript malicioso em execução no SWG sob demanda.
Example of a YARA rule generated with AutoYara
Enriquecimento da inteligência contra ameaças por modelo de aprendizado de máquina
Um problema conhecido que os pesquisadores têm ao capturar JavaScript é a ofuscação, uma técnica (também usada por sites benignos) que minimiza o código e torna o código incompreensível. Or Katz escreveu uma postagem no blog sobre isso em outubro de 2020.
Para ser capaz de detectá-los, integramos nossa lógica em um modelo inspirado pelo JStap, que é executado na árvore de sintaxe abstrata , uma representação em árvore do código, que é como contornar essa técnica.
Um modelo de aprendizado de máquina pode fornecer mais precisão do que as regras YARA. No entanto, implantá-lo na edge para verificação em tempo real é um desafio. Então, encontramos o meio-termo. Nosso modelo é treinado com o mesmo conjunto de treinamento, verifica o tráfego offline (no ambiente de aprendizado de máquina Azure) e preenche a inteligência contra ameaças com o que encontra.
A inteligência contra ameaças é verificada em todas as conexões com o SWG, dessa forma, os clientes se beneficiam da detecção do modelo de aprendizado de máquina.
Observando-o em ação: um estudo de caso
A melhor maneira de demonstrar isso é usando um exemplo real. Em 8 de março de 2022, o modelo de aprendizado de máquina detectou o JavaScript hospedado em cigarettesblog[.]blogspot[.]com.
Este domínio, a partir de 10 de março de 2022, mostrava 0 detecções no VT.
![Página inicial do cigarettesblog[.]blogspot[.]com visto em 9 de março](/site/pt/images/blog/2022/detecting-malicious-javascript-with-swg5.jpeg)
Home page of cigarettesblog[.]blogspot[.]com seen on March 9
No trecho a seguir, o código JavaScript substitui todos os links HTML por URLs maliciosos.
Um deles, hxxps://myprintscreen[.]com/soft/myp0912.exe, que agora comentou no código, está, na verdade, baixando um Trojan (4a6ffa02ff7280e00cf722c4f2235f0e318e6cc8a2b9968639ba715f1a38c834), que tem 23 detecções no VT. Havia alguns outros URLs marcados como maliciosos por muitos fornecedores no VT.
Este é um comportamento clássico do JavaScript malicioso: substituindo URLs nas páginas, enviando solicitações POST para outros domínios (veja o trecho abaixo) ou conduzindo um ataque de download por transferência para inserir malware na máquina do usuário.
![Código JavaScript extraído do cigarettesblog[.]blogspot[.]com em 9 de março de 2022](/site/pt/images/blog/2022/detecting-malicious-javascript-with-swg6.png)
JavaScript code extracted from cigarettesblog[.]blogspot[.]com on March 9, 2022
URLs:
myprintscreen[.]com/soft/myp0912.exe
www[.]blog-hits.com
Hash do arquivo:
4a6ffa02ff7280e00cf722c4f2235f0e318e6cc8a2b9968639ba715f1a38c834 (Trojan)
fc311d002d7139e0a58b00464731ba8d4faea4670cff9fedfb35057fe838c285 (Arquivo JavaScript carregado por nós em 10 de março)
O mesmo mecanismo foi detectado no penis-photo.blogspot[.]com.br (no dia 10 de março) ou mateyhderesa[.]blogspot.com (no dia 13 de março), playboy-college-girls.blogspot.sk (14 de março).
Resumo
Como eu disse no início desta publicação, qualquer coisa crítica para a segurança também pode ser usada maliciosamente, e algo tão prevalente quanto o JavaScript pode ter algumas consequências importantes. Também pode ser muito difícil descriptografar; uma postagem anterior no blog mostrou que 25% dos códigos maliciosos que vemos é ofuscado. Essa não é uma porcentagem insignificante, e considerando quanto da Internet vemos, é bastante representativa da extensão disso.
Esta pesquisa começou como uma forma de tornar nossos clientes mais seguros, então pegamos o que encontramos e aplicamos em nosso SWG. Temos dois novos modelos: Baseado em YARA e no aprendizado de máquina. O modelo baseado nas assinaturas de regras YARA verifica qualquer código JavaScript que passa pelo SWG para proteção em tempo real. O modelo baseado no aprendizado de máquina verifica o tráfego para atualizar a inteligência contra ameaças na borda. Ambos os modelos são constantemente atualizados e treinados novamente, e levam em conta as ameaças mais recentes, bem como o novo JavaScript benigno observado.
