Ataques Cryptomining em ascensão

Nas últimas 24 horas, o pesquisador de segurança Scott Helme descobriu que um plugin de acessibilidade de terceiros chamado ‘Browsealoud’ tinha seus servidores comprometidos. O plugin depende de um site que inclui o Javascript em seu conteúdo para funcionar. Esse compromisso resultou em mais de 4.000 sites que servem o malware criptográfico.

O malware usa as CPUs do visitante do site para o meu para a moeda de criptografia Monero. Os sites que usam o Browsealoud incluíram o escritório do Comissário da Informação do Reino Unido, os sites do Serviço Nacional de Saúde do Reino Unido, um site do governo provincial australiano e muitos mais .

Texthelp é a empresa que faz o plugin Browsealoud. Eles relatam que seu produto foi infectado por quatro horas, afetando sites que usam o plugin Browsealoud antes que ele fosse desconectado. O produto permanece offline enquanto investiga.

Ataques Cryptomining em ascensão

Em novembro, escrevemos sobre um plugin do WordPress que foi banido para incluir o código criptográfico , especificamente o código CoinHive que mina a moeda Monero . Nesse caso, se um site usasse o plugin banido, qualquer visitante do site veria seus recursos de CPU do navegador explorados para explorar o Monero e os resultados foram agregados usando o CoinHive e enviados para o proprietário do plugin. Naquela época, incluí um vídeo que mostra como a velocidade do ventilador da CPU aumenta à medida que a carga de trabalho aumenta com a mineração do Monero.

Em dezembro do ano passado, escrevemos sobre uma enorme campanha de ataque criptográfica do Monero que visava o WordPress .

Scott informa que esta campanha também usou o código CoinHive para explorar o Monero e enviar o produto de volta ao atacante.

Os Ataques da Cadeia de Suprimentos têm grande impacto

No dia 2 de janeiro deste ano, meu colega Dan Moen escreveu sobre a ameaça emergente de ataques à cadeia de suprimentos . Ele me mencionou que, à luz do aumento nos ataques da cadeia de suprimentos, vimos em 2017 visando o WordPress, é bem provável que 2018 veja um grande número desses tipos de ataques que afetam os proprietários do site e é melhor ter o melhor palavra, o que fizemos.

Como escreveu Dan em janeiro, “na indústria de software, um ataque na cadeia de suprimentos explora uma relação confiável entre fornecedores de software ou autores e seus clientes”. Nessa publicação, fomos focados em discutir o risco de plugins comprometidos que afetam milhares de sites do WordPress.

Este é outro tipo de ataque da cadeia de suprimentos que afeta a “relação confiável entre fornecedores de software ou autores e seus clientes”. Você confia em um serviço que distribui o Javascript para manter a segurança do site. Se esse serviço estiver comprometido, isso afeta qualquer site usando esse código – potencialmente milhares de sites. Como é o caso dos plugins do WordPress, os ataques de cadeia de suprimentos de Javascript permitem que um ator malicioso comprometa milhares de sites com um único hack.

No caso de Browsealoud, o incidente poderia ter sido muito pior. O invasor poderia ter roubado credenciais de sites do governo em vários países. Em vez disso, eles simplesmente exploraram os recursos da CPU dos visitantes do site para explorar a moeda de criptografia Monero.

Como proteger o site e os visitantes do site dos ataques da Cadeia de Suprimentos da JS

Existe uma maneira fácil de proteger-se contra os ataques de cadeia de suprimentos Javascript usando um recurso de segurança chamado Intransource Integrity, ou SRI . Se você estiver incluindo o código javascript de uma fonte externa usando a marca <SCRIPT>, basta incluir um atributo ‘integridade’ que fará com que os navegadores não carreguem o script se ele for modificado a partir da versão original.

Normalmente você incluirá um script como este:

Para proteger seu site contra ataques de cadeia de suprimentos JS, altere-o para:

Fazer essa mudança é fácil. Você pode visitar esta página para gerar um hash e o código de inclusão a partir de um URL de script.

O atributo ‘integridade’ contém um ‘hash’ que identifica de forma exclusiva o conteúdo do script. Se esse conteúdo mudar, o navegador pode reconhecer que mudou e se recusará a carregar o script. Isso dá aos proprietários do site controle de volta sobre o que eles carregam de servidores remotos, recusando-se a carregar o código que mudou da versão original.

Você deve estar ciente de que, uma vez que você usa SRI e inclui um hash para seus scripts, se o fornecedor mudar o script, ele não será carregado. Isso tem o benefício de proteger os visitantes do seu site se um hacker comprometer o site do fornecedor e injetar malware no javascript que você está carregando. Mas também tem o efeito colateral de que, se um fornecedor atualizar seu código na mesma URL, seu script não será mais carregado.

Alguns vendedores legados podem confiar na capacidade de atualizar seu código em um URL sempre que desejarem e ter seu site simplesmente carregar o novo código sem que você tome medidas. Se um fornecedor incluir um número de versão no URL do script, como no URL jQuery acima, então você provavelmente não precisa se preocupar com isso. Mas se o URL for algo como //example.com/source/code/lives/here.js e não há nenhuma versão especificada, verifique com o fornecedor para descobrir se eles estarão atualizando o script que você está usando. Eles podem precisar avisá-lo quando realizam atualizações para evitar interrupções no serviço.

Em geral, eu evitaria qualquer fornecedor que insista na capacidade de atualizar o código remotamente sem que você altere o código do seu site. É um risco de segurança, como ilustra este caso.

Os Ataques da cadeia de suprimentos Javascript são em tempo real

O que diferencia um ataque de cadeia de suprimentos JS de outras formas é que, uma vez que o invasor instala seu código malicioso, as vítimas são afetadas instantaneamente. Nenhuma ação é necessária pelo administrador do site ou pelos visitantes do site. O código está sendo carregado por visita do servidor comprometido e no momento em que uma mudança de código é feita, ela está ativa nos navegadores vítimas.

Isto é diferente dos ataques de cadeia de fornecimento de aplicativos ou ataques de cadeia de suprimentos de plugins do WordPress. Um ataque de cadeia de fornecimento de aplicativos precisa de uma aplicação comprometida para ser distribuída antes de explorar usuários. Os usuários de desktop ou móveis precisam atualizar para a nova versão antes de serem efetuados. Mesmo que uma atualização automática seja empurrada pelo atacante de alguma forma, haverá algum atraso antes que seja efetivo.

Um ataque de cadeia de fornecimento de plug-ins WordPress precisa de proprietários de sites para atualizar para a nova versão de plugin comprometida antes que ele esteja ativo. Os ataques de cadeia de suprimentos de Javascript são instantaneamente ativos e estão sendo carregados pelos visitantes do site, assim que o invasor salva o arquivo no servidor da web de distribuição. É por isso que é extremamente importante usar SRI para todos os scripts externos em seu site.

Por favor, compartilhe.