Quatro sniffer de JavaScript que te espreitam em lojas online

Quase todos nós utilizamos serviços de lojas online, o que significa que, cedo ou tarde, corremos o risco de nos tornarmos vítimas de sniffer JavaScript - um código especial que os criminosos inserem no site para roubar dados de cartões de crédito, endereços, logins e senhas dos usuários.

Quase 400.000 usuários do site e do aplicativo móvel da British Airways já foram vítimas de sniffers, assim como visitantes do site britânico do gigante esportivo FILA e do distribuidor americano de ingressos Ticketmaster. PayPal, Chase Paymenttech, USAePay, Moneris - estes e muitos outros sistemas de pagamento foram infectados.

O analista do Threat Intelligence Group-IB, Viktor Okorokov, fala sobre como os sniffers são inseridos no código do site e roubam informações de pagamento, além de quais CRM eles atacam.

«A Ameaça Oculta»

Por muito tempo, os sniffers JS permaneceram fora do radar dos analistas de antivírus, e os bancos e sistemas de pagamento não os viam como uma ameaça séria. E isso foi um erro. Especialistas do Group-IB analisaram 2.440 lojas online infectadas, cujos visitantes - totalizando cerca de 1,5 milhão de pessoas por dia - estavam em risco de comprometimento. Entre os afetados estão não apenas os usuários, mas também as lojas online, sistemas de pagamento e bancos que emitiram cartões comprometidos.

Relatório O Group-IB foi o primeiro a pesquisar o mercado de sniffers no dark web, sua infraestrutura e métodos de monetização, que trazem milhões de dólares para seus criadores. Identificamos 38 famílias de sniffers, das quais apenas 12 eram conhecidas anteriormente pelos pesquisadores.

Vamos nos aprofundar em quatro famílias de sniffers estudadas durante a pesquisa.

Família ReactGet

Os snifferes da família ReactGet são usados para roubo de dados de cartões de crédito em sites de lojas online. O sniffer pode trabalhar com uma grande variedade de sistemas de pagamento diferentes usados no site: um valor de parâmetro corresponde a um sistema de pagamento, e versões específicas do sniffer podem ser usadas para roubar credenciais, bem como dados de cartões de crédito de formulários de pagamento de vários sistemas de pagamento, funcionando assim como um sniffer universal. Foi constatado que, em alguns casos, os atacantes realizam ataques de phishing contra administradores de lojas online com o objetivo de obter acesso ao painel administrativo do site.

A campanha usando esta família de snifferes começou em maio de 2017, atacando sites geridos por CMSs e plataformas como Magento, Bigcommerce e Shopify.

Como o ReactGet se insere no código da loja online

Além da injeção 'clássica' do script através de link, os operadores dos snifferes da família ReactGet utilizam uma técnica especial: através de código JavaScript, verifica-se se o endereço atual em que o usuário se encontra atende a critérios específicos. O código malicioso será executado apenas se a substring estiver presente na URL atual. checkout ou onestepcheckout, onepage/, out/onepag, checkout/one, ckout/one. Dessa forma, o código do sniffer será executado exatamente no momento em que o usuário for para o pagamento e inserir as informações de pagamento no formulário do site.

Esse sniffer utiliza uma técnica não convencional. Os dados de pagamento e pessoais da vítima são coletados juntos, codificados usando base64, e a string resultante é utilizada como parâmetro para enviar uma solicitação ao site dos criminosos. Na maioria das vezes, o caminho para o gateway imita um arquivo JavaScript, por exemplo, resp.js, data.js e assim por diante, mas também são utilizados links para arquivos de imagem, GIF e JPG. A característica é que o sniffer cria um objeto de imagem com tamanho de 1 por 1 pixel e utiliza o link obtido anteriormente como parâmetro src imagens. Isso significa que para o usuário, essa solicitação no tráfego parecerá um pedido de uma imagem comum. Uma técnica semelhante foi utilizada nos snifferes da família ImageID. Além disso, a técnica com o uso de uma imagem de 1 por 1 pixel é aplicada em muitos scripts legítimos de análise online, o que também pode enganar o usuário.

Análise de versões

A análise de domínios ativos, usados pelos operadores dos snifferes ReactGet, permitiu descobrir muitas versões diferentes desse tipo de sniffer. As versões diferem pela presença ou ausência de ofuscação, além disso, cada sniffer é destinado a um sistema de pagamento específico que processa pagamentos com cartões bancários para lojas online. Ao testar o valor do parâmetro correspondente ao número da versão, os especialistas da Group-IB obtiveram uma lista completa das variações disponíveis dos snifferes, e, com base nos nomes dos campos de formulário que cada sniffer procura no código da página, identificaram os sistemas de pagamento para os quais o sniffer é direcionado.

Lista de snifferes e seus sistemas de pagamento correspondentes

Sniffer de senhas

Uma das vantagens dos snifferes JavaScript que operam no lado do cliente do site é a versatilidade: o código malicioso incorporado no site pode roubar dados de qualquer tipo, seja informações de pagamento ou login e senha da conta do usuário. Especialistas da Group-IB descobriram um exemplo de sniffer pertencente à família ReactGet, destinado a roubar endereços de e-mail e senhas dos usuários do site.

Interseção com o sniffer ImageID

Durante a análise de uma das lojas infectadas, foi identificado que seu site foi comprometido duas vezes: além do código malicioso do sniffer da família ReactGet, foi encontrado código de um sniffer da família ImageID. Essa interseção pode ser um indicativo de que os operadores responsáveis pelo uso de ambos os snifferes aplicam técnicas semelhantes para injetar código malicioso.

Sniffer universal

Durante a análise de um dos nomes de domínio relacionados à infraestrutura dos sniffers ReactGet, foi estabelecido que o mesmo usuário registrou três outros nomes de domínio. Esses três domínios imitavam domínios de sites reais e foram usados anteriormente para hospedar sniffers. Ao analisar o código de três sites legítimos, foi detectado um sniffer desconhecido, e uma análise posterior mostrou que se tratava de uma versão aprimorada do sniffer ReactGet. Todas as versões anteriores rastreadas desse tipo de sniffer eram direcionadas a um único sistema de pagamento, ou seja, para cada sistema de pagamento era necessária uma versão específica do sniffer. No entanto, neste caso, foi encontrada uma versão universal do sniffer, capaz de roubar informações de formulários relacionados a 15 diferentes sistemas de pagamento e módulos de sites de e-commerce para pagamentos online.

Assim, no início de seu funcionamento, o sniffer procurava campos básicos de formulário que continham informações pessoais da vítima: nome completo, endereço físico, número de telefone.

Em seguida, o sniffer buscava mais de 15 prefixes diferentes, correspondentes a diferentes sistemas de pagamento e módulos para pagamentos online.

Em seguida, os dados pessoais da vítima e as informações financeiras eram reunidos e enviados para um site controlado pelo criminoso: neste caso específico, foram encontradas duas versões do sniffer universal ReactGet, localizadas em dois sites hackeados diferentes. No entanto, ambas as versões enviavam dados roubados para o mesmo site hackeado. zoobashop.com.

A análise dos prefixes que o sniffer usou para procurar campos contendo informações de pagamento da vítima permitiu identificar que este modelo de sniffer estava direcionado aos seguintes sistemas de pagamento:

• Authorize.Net
• Verisign
• First Data
• USAePay
• Stripe
• PayPal
• ANZ eGate
• Braintree
• DataCash (MasterCard)
• Realex Payments
• PsiGate
• Heartland Payment Systems

Quais ferramentas são usadas para roubar informações de pagamento

A primeira ferramenta descoberta durante a análise da infraestrutura dos atacantes serve para ofuscar scripts maliciosos responsáveis pelo roubo de cartões de crédito. Em um dos hosts dos atacantes, foi encontrado um script bash que utiliza o CLI do projeto javascript-obfuscator para automatizar a ofuscação do código dos sniffers.

A segunda ferramenta detectada é destinada à geração de código responsável pelo carregamento do sniffer principal. Essa ferramenta gera código JavaScript que verifica se o usuário está na página de pagamento, buscando na URL atual do usuário as strings checkout, cart e assim por diante, e se o resultado for positivo, o código carrega o sniffer principal do servidor dos invasores. Para ocultar a atividade maliciosa, todas as strings, incluindo as strings de teste para determinar a página de pagamento, bem como o link para o sniffer, são codificadas usando base64.

Ataques de Phishing

No curso da análise da infraestrutura de rede dos atacantes, foi constatado que frequentemente, para obter acesso ao painel administrativo da loja online alvo, o grupo criminoso usa phishing. Os atacantes registram um domínio que é visualmente semelhante ao domínio da loja e, em seguida, implantam nele um formulário falso de login do painel administrativo do Magento. Em caso de sucesso, os atacantes obterão acesso ao painel administrativo do CMS Magento, o que lhes permite editar componentes do site e implantar o sniffer para roubo de dados de cartões de crédito.

Infraestrutura

Família G-Analytics

Essa família de sniffers é usada para roubar cartões de clientes de lojas online. O primeiro domínio usado pelo grupo foi registrado em abril de 2016, o que pode indicar o início das atividades do grupo em meados de 2016.

Na campanha atual, o grupo utiliza nomes de domínio que imitam serviços reais, como Google Analytics e jQuery, disfarçando a atividade dos sniffers com scripts legítimos e nomes de domínio semelhantes aos legítimos. Os sites que foram alvos da ataque operavam sob CMS Magento.

Como o G-Analytics é implantado no código da loja online

Uma característica distinta desta família é a utilização de diferentes métodos para roubar informações de pagamento do usuário. Além da clássica inserção de código JavaScript na parte do cliente do site, o grupo criminoso também aplicou a técnica de injetar código na parte do servidor do site, especificamente scripts PHP que processam os dados inseridos pelo usuário. Essa técnica é perigosa, pois dificulta a detecção do código malicioso por pesquisadores externos. Especialistas da Group-IB descobriram uma versão do sniffer incorporada no código PHP do site, utilizando como porta o domínio dittm.org.

Também foi descoberta uma versão anterior do sniffer, que utiliza o mesmo domínio para coletar dados roubados dittm.org, mas esta versão é projetada para ser instalada do lado do cliente da loja online.

Posteriormente, o grupo mudou sua tática e começou a se concentrar mais em ocultar a atividade maliciosa e se camuflar.

No início de 2017, o grupo começou a usar o domínio jquery-js.com, disfarçado como um CDN para jQuery: ao acessar o site dos criminosos, o usuário é redirecionado para o site legítimo jquery.com.

E em meados de 2018, o grupo adotou o nome de domínio g-analytics.com e começou a disfarçar a atividade do sniffer como um serviço legítimo do Google Analytics.

Análise de versões

Durante a análise dos domínios utilizados para armazenar o código dos sniffers, foi estabelecido que o site contém um grande número de versões, que diferem pela presença de ofuscação, bem como pela presença ou ausência de código inacessível adicionado ao arquivo para desviar a atenção e ocultar o código malicioso.

No total, foram identificadas seis versões de sniffers no site. jquery-js.com Os dados roubados por esses sniffers são enviados para um endereço localizado no mesmo site que o próprio sniffer: hxxps://jquery-js[.]com/latest/jquery.min.js:

• hxxps://jquery-js[.]com/jquery.min.js
• hxxps://jquery-js[.]com/jquery.2.2.4.min.js
• hxxps://jquery-js[.]com/jquery.1.8.3.min.js
• hxxps://jquery-js[.]com/jquery.1.6.4.min.js
• hxxps://jquery-js[.]com/jquery.1.4.4.min.js
• hxxps://jquery-js[.]com/jquery.1.12.4.min.js

Um domínio posterior g-analytics.com, utilizado pelo grupo em ataques desde meados de 2018, serve como depósito para um maior número de sniffers. No total, foram descobertas 16 versões diferentes do sniffer. Nesse caso, a porta para enviar os dados roubados estava disfarçada como um link para uma imagem do formato GIF: hxxp://g-analytics[.]com/__utm.gif?v=1&_v=j68&a=98811130&t=pageview&_s=1&sd=24-bit&sr=2560×1440&vp=2145×371&je=0&_u=AACAAEAB~&jid=1841704724&gjid=877686936&cid
=1283183910.1527732071:

• hxxps://g-analytics[.]com/libs/1.0.1/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.10/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.11/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.12/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.13/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.14/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.15/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.16/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.3/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.4/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.5/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.6/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.7/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.8/analytics.js
• hxxps://g-analytics[.]com/libs/1.0.9/analytics.js
• hxxps://g-analytics[.]com/libs/analytics.js

A monetização dos dados roubados

O grupo criminoso monetiza os dados roubados, vendendo cartões através de uma loja subterrânea especificamente criada, que presta serviços a fraudadores. A análise dos domínios utilizados pelos atacantes permitiu determinar que google-analytics.cm foi registrado pelo mesmo usuário que o domínio cardz.vc. O domínio cardz.vc está associado a uma loja de venda de cartões bancários roubados chamada Cardsurfs (Flysurfs), que ganhou popularidade ainda na época da ativa plataforma de mercado clandestina AlphaBay como uma loja que vendia cartões bancários roubados através de sniffers.

Analisando o domínio analytic.is, localizado no mesmo servidor que os domínios usados por sniffers para coletar dados roubados, especialistas da Group-IB descobriram um arquivo contendo logs de Cookie-stealer, que aparentemente foi posteriormente abandonado pelo desenvolvedor. Um dos registros no log continha o domínio iozoz.com, que havia sido utilizado anteriormente por um dos sniffers ativos em 2016. Presumivelmente, este domínio foi previamente usado por um invasor para coletar cartões roubados através de sniffers. Este domínio foi registrado em um endereço de email kts241@gmail.com, que também foi utilizado para registrar domínios cardz.su e cardz.vc, que pertencem à loja de carding Cardsurfs.

Com base nos dados obtidos, pode-se supor que a família de sniffers G-Analytics e a loja clandestina de cartões bancários Cardsurfs são operadas pelas mesmas pessoas, e a loja é usada para a venda de cartões bancários roubados através de sniffers.

Infraestrutura

Família Illum

Illum é uma família de sniffers utilizados para ataques a lojas online que operam sob CMS Magento. Além da injeção de código malicioso, os operadores deste sniffer também utilizam a implementação de formulários de pagamento falsos completos, que enviam dados para gateways controlados pelos criminosos.

Na análise da infraestrutura de rede utilizada pelos operadores desse sniffer, foi notada uma grande quantidade de scripts maliciosos, exploits, formulários de pagamento falsos, além de uma coletânea de exemplos de sniffers maliciosos concorrentes. Com base nas informações sobre as datas de surgimento dos nomes de domínio utilizados pelo grupo, pode-se supor que o início da campanha remonta ao final de 2016.

Como o Illum é injetado no código da loja online

As primeiras versões detectadas do sniffer eram injetadas diretamente no código do site comprometido. Os dados roubados eram enviados para cdn.illum[.]pw/records.php, o gateway foi codificado utilizando base64.

Mais tarde foi encontrada uma versão empacotada do sniffer, utilizando outro gateway — records.nstatistics[.]com/records.php.

De acordo com relatório Willem de Groot, o mesmo host foi utilizado no sniffer que foi implantado em um site de loja, pertencente ao partido político alemão CSU.

Análise do site dos criminosos

Especialistas da Group-IB descobriram e analisaram um site usado por esse grupo criminoso para armazenar ferramentas e coletar informações roubadas.

Entre as ferramentas encontradas no servidor dos criminosos, estavam scripts e exploits para elevação de privilégios no sistema operacional Linux: por exemplo, o Linux Privilege Escalation Check Script, desenvolvido por Mike Czumak, além de um exploit para CVE-2009-1185.

Diretamente para os ataques a lojas online, os criminosos utilizaram dois exploits: o primeiro é capaz de injetar código malicioso em core_config_data através da exploração do CVE-2016-4010, o segundo explora uma vulnerabilidade do tipo RCE em plugins do CMS Magento, permitindo a execução de código arbitrário no servidor web vulnerável.

Durante a análise do servidor, foram encontrados vários exemplos de sniffers e formulários de pagamento falsos, usados pelos criminosos para coletar informações de pagamento de sites hackeados. Como pode ser observado na lista abaixo, alguns scripts foram criados individualmente para cada site invadido, enquanto soluções universais foram empregadas para determinados CMS e gateways de pagamento. Por exemplo, os scripts segapay_standart.js e segapay_onpage.js são destinados à injeção em sites que utilizam o gateway de pagamento Sage Pay.

Lista de scripts para vários gateways de pagamento

Host paymentnow[.]tk, usado como gateway no script payment_forminsite.js, foi encontrado como subjectAltName em vários certificados relacionados ao serviço CloudFlare. Além disso, havia um script hospedado evil.js. A julgar pelo nome do script, ele poderia ter sido usado no contexto da exploração do CVE-2016-4010, permitindo a injeção de código malicioso no rodapé de um site gerido por CMS Magento. Como gateway, este script foi aplicado pelo host request.requestnet[.]tk, que usa o mesmo certificado que o host paymentnow[.]tk.

Formas de pagamento falsas

Abaixo, na imagem, está um exemplo de formulário para entrada de dados do cartão. Este formulário foi utilizado para injeção em um site de loja online e roubo de dados de cartões.

A imagem a seguir é um exemplo de um formulário de pagamento falso do PayPal que foi utilizado por criminosos para invadir sites que utilizam este método de pagamento.

Infraestrutura

Família CoffeMokko

A família de snifers CoffeMokko, projetada para roubar informações de cartões de crédito de usuários de lojas online, tem sido utilizada desde pelo menos maio de 2017. Presumivelmente, os operadores dessa família de snifers pertencem ao grupo criminoso Group 1, descrito por especialistas da RiskIQ em 2016. Sites sob gestão de CMS como Magento, OpenCart, WordPress, osCommerce e Shopify foram alvos de ataques.

Como o CoffeMokko é inserido no código da loja online

Os operadores dessa família criam snifers únicos para cada infecção: o arquivo do snifer está localizado no diretório src ou js no servidor dos criminosos. A injeção no código do site é feita por meio de um link direto para o snifer.

O código do snifer contém de forma rígida os nomes dos campos do formulário dos quais os dados precisam ser roubados. Além disso, o snifer verifica se o usuário está na página de pagamento, comparando uma lista de palavras-chave com o endereço atual do usuário.

Algumas versões do snifer detectadas estavam ofuscadas e continham uma string criptografada, onde estava armazenado o array principal de recursos: é nele que estão os nomes dos campos de formulários para vários sistemas de pagamento, bem como o endereço do gateway para onde os dados roubados devem ser enviados.

As informações de pagamento roubadas eram enviadas a um script no servidor dos criminosos pelo caminho /savePayment/index.php или /tr/index.php. Presumivelmente, esse script serve para enviar dados do gateway para o servidor principal, que consolida dados de todos os snifers. Para ocultar os dados transmitidos, todas as informações de pagamento da vítima são codificadas usando base64, e então ocorrem várias substituições de caracteres:

• o símbolo «e» é substituído por «:»
• o símbolo «w» é substituído por «+»
• o símbolo «o» é substituído por «%»
• o símbolo «d» é substituído por «#»
• o símbolo «a» é substituído por «-»
• o símbolo «7» é substituído por «^»
• o símbolo «h» é substituído por «_»
• o símbolo «T» é substituído por «@»
• o símbolo «0» é substituído por «/»
• o símbolo «Y» é substituído por «*»

Como resultado das substituições de caracteres, a codificação usando base64 não pode ser decodificada sem a transformação reversa.

Este é um fragmento de código de um sniffer que não foi ofuscado:

Análise da infraestrutura

Em campanhas anteriores, os invasores registravam nomes de domínio semelhantes aos domínios de sites legítimos de e-commerce. Seu domínio poderia diferir do legítimo por apenas um caractere ou outro TLD. Os domínios registrados eram usados para armazenar o código do sniffer, cuja referência era inserida no código da loja.

Além disso, este grupo utilizou nomes de domínio que lembravam os nomes de plugins populares do jQuery (slickjs[.]org para sites que utilizavam o plugin slick.js), gateways de pagamento (sagecdn[.]org para sites que usavam o sistema de pagamento Sage Pay).

Posteriormente, o grupo começou a criar domínios cujos nomes não tinham nada a ver com o domínio da loja nem com o tema da loja.

Cada domínio correspondia a um site que criava um diretório /js ou /src. Neste diretório, eram armazenados scripts de sniffers: um sniffer para cada nova infecção. O sniffer era inserido no código do site por meio de um link direto, mas em raras ocasiões os invasores modificavam um dos arquivos do site e adicionavam código malicioso a ele.

Análise do código

O primeiro algoritmo de ofuscação

Em algumas amostras detectadas dos sniffers desta família, o código foi ofuscado e continha dados criptografados necessários para o funcionamento do sniffer: em particular, o endereço do gateway do sniffer, a lista de campos do formulário de pagamento e, em alguns casos, o código de um formulário falso de pagamento. No código dentro da função, os recursos foram criptografados usando XOR com uma chave que era passada como argumento dessa mesma função.

Descriptografando a string com a chave correspondente, única para cada amostra, é possível obter uma string que contém todas as strings do código do sniffer separadas por um delimitador.

O segundo algoritmo de ofuscação

Em amostras mais recentes dos sniffers desta família, foi utilizado outro mecanismo de ofuscação: neste caso, os dados foram criptografados usando um algoritmo próprio. A string contendo os dados criptografados, necessários para o funcionamento do sniffer, era passada como argumento para a função de descriptografia.

Usando o console do navegador, é possível descriptografar os dados criptografados e obter um array que contém os recursos do sniffer.

Relação com os primeiros ataques do MageCart

Durante a análise de um dos domínios utilizados pelo grupo como porta de entrada para coletar dados roubados, foi constatado que nesse domínio havia uma infraestrutura para roubo de cartões de crédito, idêntica àquela utilizada pelo Grupo 1 — um dos primeiros grupos, descobertos pelos especialistas da RiskIQ.

No host da família de sniffers CoffeMokko, foram encontrados dois arquivos:

• mage.js — um arquivo contendo o código do sniffer do Grupo 1 com o endereço do gate js-cdn.link
• mag.php — um script PHP responsável pela coleta de dados roubados pelo sniffer

Содержимое файла mage.js
Foi também identificado que os primeiros domínios utilizados pelo grupo por trás da família de sniffers CoffeMokko foram registrados em 17 de maio de 2017:

• link-js[.]link
• info-js[.]link
• track-js[.]link
• map-js[.]link
• smart-js[.]link

O formato desses nomes de domínio coincide com os nomes de domínio do Grupo 1, que foram usados em ataques de 2016.

Com base nas evidências encontradas, pode-se supor que há uma conexão entre os operadores dos sniffers CoffeMokko e o grupo criminoso Grupo 1. Presumivelmente, os operadores do CoffeMokko poderiam ter emprestado ferramentas e software de roubo de cartões de seus predecessores. No entanto, é mais provável que o grupo criminoso por trás do uso de sniffers da família CoffeMokko seja o mesmo que realizou ataques como parte das atividades do Grupo 1. Após a publicação do primeiro relatório sobre as atividades do grupo criminoso, todos os seus nomes de domínio foram bloqueados e as ferramentas foram minuciosamente analisadas e descritas. O grupo foi forçado a fazer uma pausa, aprimorar suas ferramentas internas e reescrever o código dos sniffers para continuar seus ataques e permanecer invisível.

Infraestrutura

Fonte: habr.com