Falha no Rarible permitia abuso de NFTs maliciosos para tomar controle de aprovações de carteira

A vulnerabilidade permitia que arte em formato suportado pelo marketplace executasse JavaScript ao ser aberta, induzindo usuários a assinar setApprovalForAll e autorizar transferência de NFTs sob contratos afetados.

Componente	Marketplace Rarible, fluxo de visualização de NFTs e autorização de carteira baseada em setApprovalForAll do padrão EIP-721.
Vetor	NFT criado com conteúdo SVG contendo JavaScript, acionado quando o usuário abria a arte em outra aba ou acessava o link IPFS associado.
Impacto	Assinatura enganosa de aprovação ampla poderia permitir ao operador transferir NFTs do usuário dentro do contrato autorizado.
Prioridade	Verificar aprovações de tokens já concedidas, revogar permissões suspeitas e revisar fluxos de assinatura antes de confirmar solicitações de carteira.
Artefatos	Formatos aceitos no fluxo descrito incluíam PNG, GIF, SVG, MP4, WEBM e MP3, com limite de 100 MB.
Correção	A Rarible foi notificada, reconheceu a falha e aplicou uma correção no marketplace.

Resumo técnico

Uma falha de desenho no marketplace Rarible expunha usuários a um fluxo de autorização enganoso envolvendo NFTs maliciosos e carteiras de criptoativos. O problema estava na combinação entre conteúdo enviado por usuários, renderização de arte hospedada ou vinculada por IPFS e a capacidade de induzir uma assinatura de carteira com permissão ampla. O cenário não dependia de uma vulnerabilidade nomeada por CVE nem de uma quebra criptográfica no padrão de tokens; o risco surgia quando um NFT criado para fins abusivos executava JavaScript no momento em que a vítima interagia com a arte. A partir dessa execução, o operador podia preparar solicitações de autorização para a carteira e tentar convencer o usuário a confirmar uma transação que parecia parte do uso normal do marketplace.

O ponto central do abuso era a função setApprovalForAll, prevista no padrão EIP-721. Essa função permite delegar a um operador autorização para gerenciar todos os NFTs de um usuário dentro de determinado contrato. Em plataformas de negociação, esse tipo de permissão é usado para que serviços como marketplaces possam listar, transferir ou operar ativos em nome do titular. O mesmo mecanismo, quando apresentado sem clareza suficiente ou acionado por um fluxo malicioso, cria uma condição de risco: se o usuário assina a aprovação, a carteira passa a aceitar operações daquele operador para os tokens abrangidos pela autorização. No caso descrito, a consequência prática era a possibilidade de transferência não autorizada de NFTs sob o contrato aprovado.

A relevância operacional do caso é ampliada pelo porte do Rarible no período relatado. O marketplace era descrito como uma plataforma para criação, compra e venda de arte digital em NFT, incluindo fotografias, jogos e memes, com volume de negociação superior a US$ 273 milhões em 2021, mais de 2,1 milhões de usuários, suporte a três blockchains e mais de 400 mil NFTs cunhados. Esse contexto torna a superfície de ataque sensível porque o fluxo de consumo de conteúdo é parte central da experiência do usuário: qualquer pessoa podia criar e disponibilizar arte em formatos aceitos, e compradores ou colecionadores eram incentivados a abrir detalhes de itens, visualizar mídias e interagir com carteiras conectadas.

Fluxo técnico

O fluxo explorável começava com a criação de um NFT que carregava conteúdo ativo em um formato aceito pelo marketplace. Entre os formatos permitidos estavam imagens, áudio e vídeo, incluindo SVG. O uso de SVG era relevante porque esse formato pode conter lógica executável quando tratado de forma insegura pelo ambiente de exibição. No caso descrito, a arte maliciosa era enviada como um arquivo SVG com JavaScript incorporado. A execução não ocorria simplesmente por existir um token na plataforma; ela era acionada quando a vítima abria a arte em uma nova aba ou acessava o link IPFS apresentado no menu associado ao item. Essa condição de interação é importante para delimitar o risco: o ataque dependia de convencimento e de uma ação do usuário sobre o conteúdo.

Depois da execução do código embutido na arte, o fluxo tentava enumerar NFTs relevantes e preparar solicitações de autorização para a carteira conectada. A etapa crítica era a apresentação de uma transação setApprovalForAll. Para a vítima, a janela da carteira podia se parecer com mais uma confirmação relacionada ao marketplace, especialmente em um ecossistema onde conexões de carteira e assinaturas são frequentes. Tecnicamente, porém, a autorização tinha um alcance muito maior do que uma simples conexão. Ao aprovar a solicitação, o usuário concedia ao endereço operador a capacidade de movimentar todos os NFTs sob o contrato escolhido. A partir daí, o operador podia chamar uma função de transferência compatível com o contrato, como transferFrom, para mover os ativos para uma carteira controlada por ele.

O caso também mostra por que permissões de marketplace devem ser tratadas como superfície de segurança, não apenas como conveniência de uso. A assinatura não comprometia a chave privada da vítima e não exigia acesso direto ao dispositivo; o abuso ocorria porque a própria vítima autorizava, por engano, uma permissão válida no contrato. Isso reduz a visibilidade do incidente para alguns controles tradicionais, já que a blockchain registra uma aprovação e depois uma transferência que obedecem às regras do contrato. A distinção é relevante para resposta a incidentes: a defesa precisa analisar aprovações concedidas, endereços operadores, contratos envolvidos e sequência temporal de interação com NFTs suspeitos, em vez de procurar somente sinais clássicos de malware no endpoint.

O contexto relata um episódio separado, ocorrido na primeira semana de abril, no qual uma vítima conhecida foi induzida a aprovar uma solicitação setApprovalForAll. Após a aprovação, um NFT específico foi transferido para uma carteira do operador e posteriormente vendido por US$ 500 mil. Esse episódio não é apresentado como exploração direta da falha do Rarible, mas como exemplo do mesmo padrão de abuso de aprovação ampla. O paralelo técnico é a engenharia social em torno da assinatura: a transação concedia controle sobre ativos, e a vítima só percebia o efeito depois que o operador usava a permissão para transferir o NFT.

Superfície afetada

A superfície afetada estava concentrada nos usuários do Rarible que interagiam com NFTs criados por terceiros e mantinham carteiras capazes de assinar transações relacionadas a contratos EIP-721. O risco aumentava quando a navegação levava o usuário para a visualização direta da arte, para uma nova aba ou para um link IPFS associado ao item, pois era nesse ponto que o JavaScript incorporado ao SVG podia ser executado. A vulnerabilidade não exigia que o NFT fosse comprado; a interação com a arte maliciosa e a posterior confirmação da solicitação de carteira eram as condições essenciais.

O impacto também dependia do contrato e da permissão concedida. setApprovalForAll não autoriza genericamente qualquer ação em toda a blockchain; ele delega controle sobre tokens de um contrato específico ao operador definido na aprovação. Ainda assim, para coleções valiosas, essa granularidade continua crítica. Se a vítima mantivesse NFTs de alto valor naquele contrato, a autorização poderia ser suficiente para permitir a transferência desses ativos. O risco era agravado pela dificuldade de usuários distinguirem solicitações de conexão de carteira, assinaturas inofensivas e transações com permissão operacional ampla.

Ambientes corporativos que lidam com ativos digitais, equipes de criação, marcas com coleções em NFT e usuários com carteiras compartilhadas entre atividades pessoais e profissionais deveriam tratar esse tipo de falha como risco de governança de permissões. Mesmo quando a correção é aplicada no marketplace, permissões antigas concedidas em contratos continuam sendo um ponto de exposição até que sejam revogadas. A investigação, portanto, precisa combinar revisão do aplicativo com auditoria da carteira e histórico de aprovações.

• Usuários que abriram NFTs de terceiros em fluxos que renderizavam ou redirecionavam conteúdo SVG.
• Carteiras que receberam solicitações setApprovalForAll após interação com arte, detalhes do item ou links IPFS.
• Coleções EIP-721 nas quais uma aprovação ampla foi concedida a endereço operador não reconhecido.
• Ativos de alto valor em contratos nos quais o usuário não revisou permissões antigas.

Hunting e telemetria

A investigação defensiva deve começar pelo histórico de aprovações da carteira. O evento de interesse é uma chamada setApprovalForAll para contratos NFT, especialmente quando ela ocorre logo após interação com um item recém-visualizado ou de origem desconhecida. O analista deve correlacionar o horário da aprovação com acessos ao marketplace, abertura de links IPFS, visualizações de detalhes de NFT e alertas da carteira. Em carteiras usadas para custódia de ativos relevantes, aprovações amplas devem ser tratadas como mudanças sensíveis de privilégio, equivalentes a delegar controle operacional de uma coleção a um terceiro.

Na camada de endpoint e navegador, a telemetria útil inclui navegação para conteúdo IPFS associado a NFTs, abertura de arte em nova aba, carregamento de SVG proveniente de marketplace e execução de scripts em contexto inesperado de visualização de mídia. A análise não deve depender de uma URL específica, porque o vetor é uma classe de conteúdo abusivo, não um único indicador. Em ambientes gerenciados, registros de proxy, DNS e EDR podem ajudar a reconstruir a sequência entre clique, renderização, solicitação de carteira e confirmação de transação. O objetivo é estabelecer se a aprovação foi uma ação legítima de marketplace ou um evento induzido por conteúdo ativo.

Na camada blockchain, a sequência de maior risco combina aprovação ampla seguida de transferência de NFT para um endereço sem relação com o usuário. Quando a transferência ocorre pouco depois da aprovação e envolve coleção valiosa, a hipótese de abuso ganha força. Como a transação aprovada é válida do ponto de vista do contrato, a detecção precisa olhar para comportamento, reputação do operador, novidade do endereço, frequência de aprovações e distância temporal entre autorização e movimentação. A ausência de malware no dispositivo não elimina a possibilidade de incidente, porque o abuso pode ter sido inteiramente conduzido por assinatura enganosa.

• Chamadas setApprovalForAll recentes para contratos NFT após navegação em itens desconhecidos.
• Aprovações concedidas a operadores não reconhecidos ou sem histórico legítimo com a carteira.
• Transferências transferFrom realizadas pouco tempo depois de uma aprovação ampla.
• Acessos a links IPFS ou renderização de SVG associados a NFTs recebidos, listados ou visualizados.
• Alertas de carteira confirmados sem justificativa operacional clara para delegação de todos os tokens de um contrato.

Mitigação

A primeira medida defensiva é revisar aprovações de tokens já concedidas e revogar permissões que não tenham finalidade atual e reconhecida. Essa ação é especialmente importante para carteiras que já interagiram com marketplaces de NFT, porque autorizações antigas podem permanecer válidas mesmo depois que a experiência do site foi corrigida. A revisão deve priorizar contratos de coleções valiosas, operadores desconhecidos e aprovações concedidas em datas próximas a interações suspeitas com NFTs. Quando houver indício de transferência não autorizada, a resposta deve preservar o histórico de transações, registrar endereços envolvidos e separar carteiras ainda não afetadas.

Usuários e equipes que operam ativos digitais devem diferenciar conexão de carteira, assinatura de mensagem e transação com alteração de permissão. Antes de confirmar uma solicitação, é necessário verificar qual contrato está sendo chamado, qual função será executada e qual endereço receberá autorização. No caso de setApprovalForAll, a pergunta defensiva principal é se há razão legítima para permitir que aquele operador movimente todos os NFTs de um contrato. Se a finalidade for apenas visualizar um item, navegar no marketplace ou consultar detalhes de arte, uma aprovação ampla deve ser considerada anormal.

Do lado das plataformas, a mitigação passa por sanitização rigorosa de conteúdo ativo, isolamento de mídia enviada por usuários, controle de como SVG é renderizado e mensagens de carteira que expliquem o alcance real das permissões solicitadas. Marketplaces também devem reduzir a ambiguidade entre ações de navegação e ações que alteram autorização on-chain. A correção aplicada pela Rarible elimina o ponto específico relatado, mas a lição técnica permanece: aplicações Web3 que aceitam conteúdo gerado por usuários precisam tratar arquivos de mídia como entrada não confiável e tratar aprovações de carteira como operações privilegiadas, com contexto claro para o usuário e limites de execução bem definidos.

• Revogar aprovações setApprovalForAll que não sejam necessárias ou que apontem para operadores desconhecidos.
• Separar carteiras de navegação e teste de carteiras usadas para manter ativos de alto valor.
• Revisar solicitações de carteira pelo contrato, função chamada, operador autorizado e escopo da permissão.
• Bloquear ou isolar execução de JavaScript em mídia enviada por usuários, especialmente SVG.
• Correlacionar aprovações amplas com transferências subsequentes para identificar abuso já consumado.