Resumo: Plugin de acessibilidade BrowseAloud, cryptojacking com CoinHive
- Plugins viraram mineradores: Plugins de acessibilidade transformados em mineradores. O ataque ao BrowseAloud provou que um script de terceiros útil tem os mesmos privilégios de execução que o seu próprio código — e foi precisamente o site do ICO, entre todos, que esteve a minerar Monero através dos visitantes.
- 4.000 sites minerados: Um único ficheiro comprometido do BrowseAloud arrastou mais de 4.000 sites, incluindo páginas governamentais do Reino Unido e dos EUA, para a mineração não consentida de Monero antes de a Texthelp o retirar. O cside consegue bloquear a execução de um script de terceiros com base no comportamento observado, e não apenas na origem.
- SRI não basta: Se depende do Subresource Integrity para um widget de um fornecedor, saiba que o SRI só ajuda em recursos estáticos. Se o seu plugin serve código dinâmico, adicione monitorização em tempo de execução antes que a próxima atualização transforme uma ferramenta de conversão de texto em fala num minerador.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
Em fevereiro de 2018, mais de 4.000 sites, incluindo organismos governamentais de grande visibilidade como o Information Commissioner's Office (ICO) do Reino Unido, foram vítimas do ataque ao BrowseAloud. Isto mostrou como um único script de terceiros comprometido pode atingir milhares de sites em simultâneo.
O que aconteceu no ataque ao BrowseAloud?
Um serviço de terceiros aparentemente inofensivo chamado BrowseAloud, que ajuda os sites a melhorar a acessibilidade convertendo texto em fala, foi comprometido. Atores maliciosos injetaram o script de mineração de criptomoeda CoinHive no código-base do BrowseAloud. Este script foi então executado, sem que os utilizadores se apercebessem, pelos navegadores de milhares de visitantes em vários sites, usando os seus dispositivos para minerar criptomoeda sem consentimento.
A mineração de criptomoeda envolve o processo de resolver problemas matemáticos complexos para validar transações na blockchain, uma tarefa que tradicionalmente requer recursos computacionais substanciais. No entanto, com o surgimento de scripts como o CoinHive, este processo passou a ocorrer nos navegadores de utilizadores desprevenidos. Eis como funciona:
- Execução de JavaScript: o CoinHive e scripts semelhantes são escritos em JavaScript, que pode ser executado em qualquer navegador web padrão. Isto torna extremamente fácil implementá-los em larga escala. Provavelmente o aspeto mais importante dos ataques à cadeia de abastecimento web, e aquilo que o cside protege.
- Uso não consensual de recursos: ao contrário da mineração típica, que requer consentimento explícito e hardware dedicado, a mineração baseada em navegador usa os recursos de CPU de qualquer visitante de um site infetado. O script é executado enquanto a página estiver aberta, o que o torna menos percetível mas potencialmente prejudicial para os dispositivos dos utilizadores, devido ao aumento do consumo de energia e ao desgaste.
- Rentabilidade para os atacantes: cada dispositivo sequestrado contribui com uma pequena quantidade de poder de mineração. No entanto, quando multiplicado por milhares de dispositivos, isto pode gerar quantidades significativas de criptomoeda para os atacantes.
O impacto deste ataque
Este ataque afetou mais de 4.000 sites, incluindo sites governamentais e educativos, expondo milhares de utilizadores ao cryptojacking sem o seu conhecimento. Não foram roubados dados pessoais, mas as implicações foram ainda assim significativas. Vários sites tiveram de ser retirados do ar, causando interrupções de serviço e danos reputacionais. Os atacantes exploraram uma prática comum, mas arriscada: a aceitação automática de atualizações de scripts de terceiros. O incidente deixou claro que os componentes de terceiros precisam de monitorização e gestão rigorosas — algo que muitas organizações tinham negligenciado.
É precisamente isto que o cside previne, tanto ao monitorizar a alteração como através da possibilidade de agir de forma autónoma para impedir que o código malicioso seja carregado no navegador do utilizador.
Por outras palavras, é muito provável que isto não tivesse acontecido se o cside já existisse e estivesse implementado na altura. Pode começar a usar o cside para se proteger gratuitamente contra qualquer tipo de ataque a scripts de terceiros.
O que aconteceu ao BrowseAloud depois?
Após o ataque de cryptojacking, a empresa-mãe do BrowseAloud, a Texthelp, tomou medidas imediatas, retirando temporariamente o serviço do ar para mitigar o problema e realizar uma revisão de segurança exaustiva. O incidente aumentou a consciencialização sobre a segurança de serviços de terceiros e a necessidade de vigilância contínua e auditorias de segurança regulares.
O BrowseAloud voltou a estar online com medidas de segurança reforçadas destinadas a prevenir incidentes semelhantes. O ataque também gerou uma discussão mais alargada entre os fornecedores de serviços web sobre a importância de proteger e monitorizar rigorosamente os scripts de terceiros.
O destino do CoinHive
O CoinHive, por outro lado, seguiu uma trajetória diferente. Inicialmente lançado como uma ferramenta legítima para monetizar conteúdo de sites sem anúncios, usando o poder de CPU dos visitantes para minerar criptomoeda, o CoinHive rapidamente passou a estar associado ao cryptojacking não autorizado. A conotação negativa e o uso indevido do script em vários ataques maliciosos levaram a um escrutínio significativo.
A viabilidade do serviço foi ainda mais afetada pela queda do valor do Monero e pela dificuldade crescente em minerá-lo de forma lucrativa. Consequentemente, o CoinHive anunciou o seu encerramento em março de 2019, citando a inviabilidade económica como principal razão para o fecho.
O domínio CoinHive.com pertence agora ao especialista da indústria Troy Hunt. É seguro e aloja a sua perspetiva sobre como proteger-se contra ataques semelhantes e contra o cryptojacking em geral.
Tal como agora somos donos do domínio Baways.com e o transformámos num site educativo.
Usar domínios antigos como estes pode causar outros problemas, como Troy Hunt experienciou recentemente.
E-mail divertido / estúpido / idiota do dia:
gerem um serviço para rastrear casos de imagens protegidas por direitos de autor a serem usadas sem licença. Em março, enviaram-me vários e-mails a exigir dinheiro por violação de direitos de autor. Hoje recebi outro a pedir várias centenas de euros:
, Troy Hunt (@troyhunt)
Voltando agora às suas recomendações sobre o tema, a sua abordagem passa por usar CSP para fazer com que os navegadores ignorem quaisquer comandos vindos de domínios que não estejam explicitamente autorizados. No seu caso, depois de garantir o domínio CoinHive, implementou uma CSP que assegura que, mesmo que scripts maliciosos sejam injetados, estes não seriam executados por não provirem de uma lista de domínios permitidos.
Na nossa perspetiva, esta abordagem é boa, mas não é suficiente. Em suma, as CSPs não devem ser a única medida de segurança contra ataques de JavaScript de terceiros. A nossa página de comparação oferece uma excelente visão geral das funcionalidades que implementámos para além das CSPs, de forma a garantir a melhor proteção possível contra violações provocadas por scripts de terceiros.
Acreditamos que a verdadeira resposta passa por analisar todo o script antes que este chegue ao navegador do utilizador. Naturalmente, isto apresenta alguns desafios, para os quais desenvolvemos soluções. Pode ler mais sobre esta perspetiva, e sobre como protegemos scripts de terceiros, aqui.
