Pre-Model Representation Failures in GNN-Based Smart Contract Vulnerability Detection

No mundo digital das finanças descentralizadas, o dinheiro se move através de programas de computador de execução automática chamados contratos inteligentes. Esses programas vivem em uma blockchain, um registro público que registra cada transação, e são projetados para lidar com ativos reais sem intermediários humanos. Como esses contratos gerenciam fundos valiosos, uma única falha oculta pode levar a um roubo imediato e irreversível. Para proteger contra isso, pesquisadores desenvolveram sistemas automatizados que escaneiam o código para encontrar fraquezas antes que sejam exploradas. Uma abordagem popular utiliza um tipo de inteligência artificial conhecida como rede neural de grafos. Para entender como isso funciona, imagine transformar um pedaço complexo de código em um mapa de pontos e linhas conectados, onde os pontos representam partes do programa e as linhas mostram como elas interagem. O computador então estuda esse mapa para decidir se o programa é seguro ou perigoso. A esperança é que, ao olhar para a estrutura do código em vez de apenas lê-lo linha por linha, esses sistemas possam detectar armadilhas sutis que os humanos poderiam perder.

Uma equipe de pesquisadores da Carnegie Mellon University Africa decidiu testar o próprio fundamento dessa abordagem. Eles se concentraram em um sistema específico chamado GNNSCVulDetector, que é amplamente utilizado para encontrar uma falha perigosa conhecida como reentrada. Essa falha ocorre quando um programa envia dinheiro para fora antes de atualizar seus próprios registros, permitindo que um ladrão engane o sistema para que este pague mais do que deveria. Os pesquisadores não testaram o quão bem o computador aprende ou o quão rápido ele pensa. Em vez disso, investigaram a etapa que acontece antes de o computador sequer ver os dados: o processo de transformar o código-fonte no mapa. Eles queriam saber se o mapa refletia com precisão o código que deveria representar. Sua investigação revelou uma verdade alarmante: o próprio processo de criação do mapa estava quebrado de maneiras que nenhum treinamento poderia corrigir.

O primeiro problema que encontraram foi que o sistema era facilmente enganado por mudanças simples no código. Os pesquisadores pegaram um contrato vulnerável conhecido e simplesmente renomearam suas partes, mudando o nome do próprio contrato, os nomes de suas funções e os nomes das variáveis que continham o dinheiro. Eles também adicionaram linhas de código que não faziam nada, apenas para poluir o arquivo. Em um mundo normal, essas mudanças fariam o programa parecer diferente, mesmo que a lógica perigosa permanecesse a mesma. No entanto, quando os pesquisadores alimentaram tanto a versão original quanto a versão modificada no sistema, o computador produziu mapas idênticos até o último byte. O sistema não conseguiu distinguir diferença entre os dois. Isso significa que um atacante poderia contornar a verificação de segurança simplesmente renomeando variáveis, sem precisar saber nada sobre como o detector funciona ou quais dados ele foi treinado para reconhecer. O sistema era cego à estrutura real do código, vendo apenas um padrão rígido de nomes.

Aprofundando a investigação, os pesquisadores descobriram por que isso aconteceu. A ferramenta que constrói o mapa não lê e entende o código como um programador humano. Em vez disso, ela depende de uma lista pré-programada de quarenta e sete nomes de variáveis específicos que ela tem permissão para reconhecer. Se o código usa um nome desta lista, a ferramenta cria um nó no mapa. Se o nome não estiver na lista, a ferramenta o ignifica ou cria um marcador genérico. Os pesquisadores testaram isso criando quatro contratos diferentes que possuíam exatamente a mesma falha perigosa, mas usavam nomes diferentes para as variáveis de dinheiro. Quando o nome da variável correspondia perfeitamente à lista, o mapa parecia normal. Quando o nome era ligeiramente diferente, o mapa mudava de formas confusas. Quando o nome era completamente novo e não estava na lista, o mapa tornava-se degradado, perdendo detalhes importantes. No pior dos casos, quando nenhum nome correspondia, a ferramenta fabricava partes do mapa que não existiam no código original, criando uma estrutura baseada apenas em suas próprias regras internas. Isso significava que a qualidade do mapa dependia inteiramente de o programador ter usado ou não um dos quarenta e sete nomes aprovados.

A segunda grande falha envolveu uma parte específica do mapa que representa o atacante. No design do sistema, existe um nó destinado a representar o chamador externo — a entidade externa que dispara o ataque. Para que uma falha de reentrada exista, este chamador externo deve estar presente no mapa. Os pesquisadores descobriram que, para o exemplo de contrato vulnerável mais famoso da literatura, este nó estava completamente ausente. A ferramenta falhou em desenhar a conexão entre o atacante e a função vulnerável, embora o código mostrasse claramente que isso estava acontecendo. Isso não foi uma limitação do design do mapa, já que outros contratos nos dados de treinamento mostravam essa conexão. Foi uma inconsistência na forma como a ferramenta decidia construir o mapa. Como a conexão estava faltando, o computador não tinha como ver o padrão de ataque, embora o padrão estivesse ali mesmo no código.

Para provar que essa peça faltante causou a falha do sistema, os pesquisadores construíram um contrato mínimo, feito sob medida, que continha uma falha de reentrada totalmente explorável. Eles usaram um nome de variável que era conhecido por estar na lista aprovada, garantindo que o primeiro problema com a renomeação não interferisse. Eles alimentaram este contrato no sistema. O resultado foi uma classificação errônea clara: o sistema rotulou o contrato perigoso como seguro. A razão foi simples e direta. Como a ferramenta falhou em desenhar a conexão entre o chamador externo e a função vulnerável, o mapa carecia do sinal crítico necessário para identificar a ameaça. O computador não errou em seu cálculo; ele estava simplesmente trabalhando com uma imagem incompleta. A informação necessária para tomar a decisão correta havia sido descartada antes mesmo de o computador começar a pensar.

Essas descobertas sugerem que os altos números de precisão relatados em estudos anteriores são enganosos, pois foram medidos sob condições que não expunham essas falhas. Os sistemas funcionaram bem apenas porque os dados de teste por acaso usavam os nomes e padrões específicos que a ferramenta conseguia reconhecer. No mundo real, onde o código é escrito com diferentes convenções de nomenclatura e estruturas, esses sistemas podem falhar silenciosamente. Os pesquisadores enfatizam que melhorar o modelo de inteligência artificial em si não resolverá este problema. Nenhum treinamento melhor ou mais dados pode consertar um mapa que foi desenhado incorretamente em primeiro lugar. A solução exige mudar a forma como o código é convertido em um mapa, afastando-se do simples correspondência de nomes em direção a uma compreensão mais profunda do que o código realmente faz. Até que o fundamento seja corrigido, os sistemas de segurança construídos sobre ele permanecerão vulneráveis aos próprios ataques que deveriam prevenir.