Alguns dias atrás Pesquisadores da Universidade de Cambridge lançaram a publicação de uma técnica para substituir códigos sutilmente código malicioso no código-fonte do aplicativo.
O método de ataque preparou Já está listado em CVE-2021-42574 Ele vem com o nome de Trojan Source e é baseado na formação de texto que parece diferente para o compilador / interpretador e para a pessoa que visualiza o código.
Sobre o Trojan Source
O método depende da aplicação de caracteres Unicode especiais em comentários de código, que alteram a ordem de exibição do texto bidirecional. Com a ajuda desses personagens de controle, algumas partes do texto podem ser exibidas da esquerda para a direita, enquanto outras da direita para a esquerda.
Na prática diária, esses caracteres de controle podem ser usados, por exemplo, para inserir strings hebraicas ou árabes em um arquivo de código. No entanto, se você usar esses caracteres para combinar linhas com diferentes direções de texto na mesma linha, as passagens de texto exibidas da direita para a esquerda podem sobrepor o texto normal existente exibido da esquerda para a direita.
Com este método, uma construção maliciosa pode ser adicionada ao código, mas depois torne o texto com esta construção invisível ao visualizar o código, adicionando os caracteres mostrados da direita para a esquerda no próximo comentário ou dentro do literal, o que resultará em um resultado de caracteres completamente diferentes sobrepostos no insert malicioso. Esse código ainda será semanticamente correto, mas será interpretado e exibido de forma diferente.
Descobrimos maneiras de manipular a codificação de arquivos de código-fonte para que visualizadores humanos e compiladores vejam lógicas diferentes. Um método particularmente pernicioso usa caracteres de substituição de direcionalidade Unicode para exibir o código como um anagrama de sua verdadeira lógica. Verificamos que esse ataque funciona contra C, C ++, C #, JavaScript, Java, Rust, Go e Python e suspeitamos que funcione contra a maioria das outras linguagens modernas.
Ao revisar o código, o desenvolvedor será confrontado com a ordem visual dos personagens e verá um comentário suspeito em um editor texto, interface da web ou IDE, mas o compilador e o interpretador usarão a ordem lógica dos caracteres e lidarão com o código malicioso como está, independentemente do texto bidirecional no comentário. Vários editores de código populares (VS Code, Emacs, Atom), bem como interfaces para visualização de código em repositórios (GitHub, Gitlab, BitBucket e todos os produtos Atlassian) são afetados.
Existem várias maneiras de usar o método para implementar ações maliciosas: adicionar uma expressão de "retorno" oculta, que leva ao encerramento prematuro da execução da função; a conclusão no comentário de expressões que normalmente são consideradas construções válidas (por exemplo, para desativar verificações importantes); Atribuição de outros valores de string levando a falhas de validação de string.
Além disso, outra opção de ataque foi proposta (CVE-2021-42694), que envolve o uso de homoglifos, símbolos que parecem semelhantes na aparência, mas diferem no significado e têm diferentes códigos Unicode. Esses caracteres podem ser usados em alguns idiomas em nomes de funções e variáveis para enganar os desenvolvedores. Por exemplo, você pode definir duas funções com nomes indistinguíveis que executam ações diferentes. Sem uma análise detalhada, você não pode entender imediatamente qual dessas duas funções é chamada em um determinado lugar.
Como medida de proteção, Recomenda-se implementar em compiladores, interpretadores e ferramentas de montagem que suportem caracteres Unicode, apresentando um erro ou aviso se há caracteres de controle desemparelhados em comentários, literais de string ou identificadores que alteram a direção de saída. Esses caracteres também devem ser explicitamente proibidos nas especificações da linguagem de programação e devem ser levados em consideração nos editores de código e nas interfaces para trabalhar com repositórios.
Além disso vulnerabilidades já começaram a ser corrigidas preparado para GCC, LLVM / Clang, Rust, Go, Python e binutils. GitHub, Bitbucket e Jira também já estão preparando uma solução junto com o GitLab.
Finalmente Se você estiver interessado em saber mais sobre isso, você pode consultar os detalhes no link a seguir.