Na descrição do ataque, Zdrnya dá a seguinte seqüência de ações. Depois de obter acesso ao computador da vítima, o invasor ativa o modo de desenvolvedor no Google Chrome, o que permite que ele baixe a extensão localmente, em vez de através da loja. Portanto, uma extensão maliciosa disfarçada como um plug-in de um produto de segurança é carregada no navegador.
No próprio código da extensão, o pesquisador descreve um método padrão para interagir com a infraestrutura em nuvem do Google, que permite que dados arbitrários sejam "trocados" entre dois navegadores. Ou seja, provavelmente o ataque foi assim: invadimos o computador, instalamos uma extensão maliciosa, autorizamos o navegador com uma conta única do Google. Do lado do atacante, é suficiente fazer login na mesma conta para obter dados do computador da vítima.
O que exatamente foi repassado dessa forma, o especialista não divulga, mas indica as limitações do método: o tamanho máximo das "chaves" transmitidas pela infraestrutura do Google Chrome não pode ultrapassar 8 KB, e seu número máximo é 512. Ou seja, 4 MB de dados podem ser transferidos por sessão ... Isso é suficiente para controlar um computador infectado, bem como para transferir tokens para acessar serviços corporativos em nuvem.
Zdrnya enfatiza que não havia nenhum outro software malicioso no sistema afetado. Não funcionará apenas assim para bloquear o acesso à infraestrutura em nuvem do Google no nível das políticas de rede corporativa: não só a nuvem está ligada a elas, mas também, por exemplo, verificando a disponibilidade de acesso à rede no navegador. Como solução, o pesquisador propõe a aplicação de políticas que proíbam a instalação de quaisquer extensões no navegador, exceto aquelas marcadas na lista branca. Esse método original de interação com o sistema atacado pode ser ignorado por um longo tempo - isso abrirá o caminho para os invasores acessar os dados corporativos, que em condições normais podem ser acessados por meio de um navegador. Na maioria dos casos, isso pode ser email corporativo, ferramentas de colaboração de documentos e muito mais.
O que mais aconteceu
A história do ataque a especialistas em segurança da informação (veja o resumo anterior ) teve continuidade. Uma vulnerabilidade de dia zero no motor V8 foi descoberta e fechada no navegador Google Chrome . Embora os desenvolvedores do Google não comentem sobre isso, presume-se que os organizadores do ataque o usaram. Além disso, especialistas sul-coreanos encontraram outro vetor do mesmo ataque: as vítimas receberam arquivos .mhtml com código malicioso que exploram uma vulnerabilidade anteriormente desconhecida no Internet Explorer 11. O arquivo supostamente continha informações sobre uma vulnerabilidade no navegador Google Chrome 85.
Netscout, citando pesquisadores chineses do Baidu Labs, está relatando um novo método para amplificar um ataque DDoS usando um servidor de mídia Plex configurado incorretamente.
No tópico do link acima, um pesquisador com o apelido de OverSoft fala sobre uma câmera de vídeo IP mal protegida com função de contagem de pessoas. A história começa com um identificador de rede WiFi insubstituível e uma senha, e só fica mais triste. Dentro da câmera, encontrei um Módulo de computação Raspberry Pi com um usuário pi padrão, documentos que sobraram do desenvolvedor (incluindo um arquivo mp3) e um monte de código Python. O resultado é um dispositivo que, em teoria, se conecta a uma rede corporativa com WiFi praticamente desprotegido e a capacidade de obter acesso total a uma conta com uma senha padrão e privilégios máximos.
A equipe do Google Project Zero publicavisão geral das vulnerabilidades de dia zero usadas em ataques reais no ano passado. Dos 24 furos, oito usam um novo método de explorar um problema já conhecido. Conclusão: é possível complicar um pouco a vida dos invasores se as vulnerabilidades forem fechadas após uma análise detalhada da causa para que o problema resolvido não possa ser reaberto.
Mais de um mês atrás, em 4 de janeiro, ocorreu uma grande falha no Slack Messenger. Um relatório detalhado foi publicado sobre os resultados do incidente . A queda deveu-se a uma combinação de motivos: no primeiro dia útil após os feriados na maioria dos países, os usuários carregaram a infraestrutura mais do que o necessário e a ferramenta de dimensionamento automático de capacidade no Amazon Web Services não funcionou como esperado.
Um estudo do malware Kobalos para sistemas Linux revela um alvo de ataque incomum: supercomputadores.
Um novo exemplo de ataque à cadeia de suprimentos: Pesquisadores da ESET encontraram software NoxPlayer infectado (emulação de aplicativos Android) distribuído diretamente do site do desenvolvedor.