Hackeando jogos blockchain Play-to-Earn: o caso do Manarium

Introdução

Nos últimos anos, você provavelmente já ouviu falar, pelo menos um pouco, sobre Tokens Não Fungíveis (NFTs), a nova sensação que movimentou milhões recordes no mercado.

Em resumo, NFTs são colecionáveis digitais únicos na blockchain que contêm um código de identificação exclusivo para distingui-los uns dos outros e impedir que sejam replicados.

NFTs podem ser qualquer coisa, como uma imagem jpg, música, tweets, imagens de objetos físicos, skins de videogame ou qualquer arte digital, o que significa que qualquer pessoa pode ser um artista ao criar um conteúdo digital e vendê-lo por qualquer preço.

Em criptomoedas, você pode trocar um Bitcoin por outro e terá exatamente o mesmo token, provavelmente apenas com um preço diferente. No entanto, no mercado de NFTs, os ativos não são intercambiáveis com outros do mesmo tipo. Você pode negociar como cartas de Pokémon, mas, se trocar uma por outra, receberá um NFT diferente daquele que entregou.

Falando em coleções de NFT, uma das mais famosas é a Bored Ape Yacht Club (BAYC), que apresenta fotos de perfil de macacos desenhados, gerados processualmente por um algoritmo. Somente em 2022, as vendas de NFTs da Bored Ape Yacht Club totalizaram mais de US$ 1 bilhão.

Segundo a Bored Ape Yacht Club, o conceito não é apenas comprar um avatar, mas uma espécie de cartão de membro para um clube. Celebridades compraram esses tokens não fungíveis. Em janeiro de 2022, por exemplo, Neymar Jr anunciou em suas redes sociais que havia adquirido uma propriedade no mundo dos NFTs, a da Bored Ape Yacht Club, por pouco mais de US$ 1,1 milhão.

Mas nem tudo que reluz é ouro; como esse mercado movimenta uma grande quantidade de dinheiro, o ambiente torna-se atraente para cibercriminosos. A Bored Ape Yacht Club passou por isso. A conta do Instagram e o servidor do Discord foram hackeados, e um link de "mint" não oficial foi enviado aos seguidores.

Como resultado, as carteiras daqueles que clicaram no link foram comprometidas, e os NFTs dos macacos foram transferidos para novas carteiras pelos hackers. O preço mínimo desses ativos chegaria a quase US$ 13,7 milhões. Isso nos faz questionar como pode ser tão fácil perder milhões em um único objeto.

Como os NFTs são únicos, eles são adequados para uso em jogos como representações de itens negociáveis, como personagens, consumíveis e outros. Os jogos NFT tornaram-se populares no mundo Game-fi como uma forma de obter renda. Você pode vender seus NFTs do jogo para outros colecionadores e jogadores e até mesmo ganhar tokens com modelos play-to-earn.

Uma nova era de esquema Ponzi?

A era pré-Bitcoin começou com o eCash em 1983, cujo objetivo era permitir que as pessoas transferissem dinheiro anonimamente pela Internet. Em 2009, Satoshi Nakamoto criou o Bitcoin. Embora não tenha se tornado um gigante da noite para o dia, é a criptomoeda mais reconhecível.

Em 2012, foi lançada uma das exchanges mais reconhecidas do mundo, a Coinbase; junto com a popularidade do Bitcoin, outras criptomoedas começaram a surgir e atraíram mais investidores. Essas moedas digitais são frequentemente baseadas em redes descentralizadas e podem ser usadas como ativos para investimento e como meios de troca em transações financeiras.

Embora algumas moedas digitais como Bitcoin e Ethereum já estejam consolidadas, há perguntas frequentes relacionadas a ativos que são altamente especulativos e extremamente arriscados. O motivo principal é a alta volatilidade. No início de 2018, o Bitcoin era negociado a US$ 18.336, e depois caiu para uma mínima de US$ 3.400 em 2019. No entanto, o preço voltou a subir devido ao endosso de empresas e grandes investidores. Em novembro de 2021, o Bitcoin atingiu US$ 69 mil, o preço mais alto desde sua criação.

Arquitetura de Jogos Play-to-Earn

Os jogos Play-to-Earn possuem uma arquitetura comum em comparação com outros jogos, como jogos de cassino, jogos MMO, entre outros. Esse tipo de arquitetura será descrito abaixo:

Lado do Cliente → Toda a lógica do jogo (por padrão, deve ser considerada insegura e não deve ser confiável sem qualquer tipo de verificação nos dados enviados). É muito comum encontrar essa abordagem, especialmente quando falamos de jogos focados no lado do cliente. Esses jogos normalmente são desenvolvidos usando softwares que suportam web assembly (que será executado no navegador do cliente), como Unity3D, e este software será o foco, já que boa parte do alvo deste artigo o utiliza.
Lado do Servidor → Nesta parte da arquitetura, todos os dados sobre o jogo serão processados via dados de entrada e saída. Esse tipo de processo inclui higienização de dados, verificações de controle de acesso, atualização de saldo/pontuação, e assim por diante. Esta parte da arquitetura pode ser atendida usando tecnologias muito conhecidas, como NodeJs, Go, Python, Ruby…
Serviço → Aqui ficarão todos os dados sobre o jogo (e as validações e higienizações), como o saldo do jogador, a pontuação de todos os usuários e o número de vezes que um usuário pode correr com seus carros (às vezes, informações mais críticas também são armazenadas, como os NFTs do jogador, que devem ser armazenados diretamente na blockchain por motivos de segurança). Esses serviços também são conhecidos pela maioria das pessoas. Por exemplo, um serviço muito conhecido usado na maioria dos jogos P2E testados por nós foi o Firebase.
Contrato Inteligente → Esta é a última parte do jogo. Aqui a tecnologia blockchain entra em cena. Nesta parte, o Token do jogo foi criado e implantado em uma blockchain (Ethereum, Binance Smart Chain (BSC), Avalanche…). O Token é um código de Contrato Inteligente que será executado dentro da blockchain e permitirá que usuários que possuem uma carteira na mesma rede interajam com ele, transferindo e armazenando. O Contrato Inteligente geralmente usa o padrão ERC20 para Ethereum, BEP20 para BSC ou ARC20 para Avalanche.
Carteira Web → Um software responsável por ajudar os usuários a interagir com a blockchain e dApps (aplicativos descentralizados). É uma interface que abstrai todas as interfaces, códigos e URLs para trabalhar com blockchain. As carteiras não guardam tokens, apenas as chaves para provar que o usuário é o proprietário desses tokens (os tokens permanecem na blockchain).

O usuário joga, conecta-se ao jogo através de uma carteira web instalada em seu navegador e joga;
O jogo buscará/enviará dados do usuário para o back-end;
O back-end processará os dados recebidos e os enviará para o serviço;
& 5. O back-end e o serviço retornarão uma mensagem sobre a modificação dos dados (200 OK, por exemplo);
Aqui, o back-end possui um script automatizado que buscará os dados no serviço procurando por alguma informação sobre o jogo;
O serviço retornará os dados solicitados pelo back-end;
O mesmo script interagirá com o Contrato Inteligente para executar alguma função dentro dele;
Aqui, o jogo não possui um processo automatizado para interagir com o contrato inteligente. Portanto, uma pessoa autorizada (neste caso, o Administrador) deve consultar o serviço e obter dados do jogo para algum tipo de verificação;
O administrador interagirá com o Smart Contract e chamará algumas funções dentro dele;
Após ser chamada, o Smart Contract executará a função solicitada (via script ou via administrador), como, por exemplo, uma função que transfere os Game Tokens para um endereço de carteira.

O exemplo acima mostra uma aplicação que armazena os dados do jogo em um serviço, processa os dados no back-end e possui dois tipos de interação com o Smart Contract:

Automatizada → Um script que interagirá automaticamente com o Smart Contract e chamará suas funções, como a transferência de tokens.
Manual → Um administrador que interagirá com o Smart Contract e chamará suas funções, como a transferência de tokens.

É importante mencionar que esta abordagem não é uma "verdade absoluta" e pode ser alterada de acordo com os desenvolvedores do jogo. Outro exemplo muito utilizado é a implementação apenas de Client-Side e Server-Side ou Client-Side e Service (o tipo de banco de dados mais utilizado que encontramos foi NoSQL, com MongoDB como o software de banco de dados mais escolhido. Em relação ao Service, o mais utilizado foi o Firebase).

Processo de Assinatura em Jogos P2E

É importante mencionar que os jogos P2E devem confirmar a identidade do usuário antes de permitir que ele jogue. Esse processo de confirmação é chamado de Assinatura, onde o usuário deve assinar uma mensagem + nonce (o nonce deve ser usado para proteger a assinatura contra ataques de repetição, portanto seu valor deve ser sempre aleatório) com sua chave privada e enviar o hash da assinatura para o back-end, que verificará o hash da mensagem assinada com a chave pública do usuário.

Abaixo, a imagem explica o processo de Assinatura de um jogo P2E:

O usuário conecta sua carteira ao jogo;
Solicita novos dados (String + Nonce) para assinatura;
O back-end retorna a String e um nonce aleatório para assinar;
O jogo fornecerá a String + nonce para serem assinados com a chave privada do usuário via Metamask;
Após a assinatura dos dados, a Metamask os enviará de volta ao jogo;
O jogo enviará os dados assinados para o servidor;
O servidor verifica se a assinatura é válida (usando a chave pública do usuário);
Se não for, retorna ao passo 2;
Se for válida, o back-end buscará todos os dados do usuário no Serviço e os enviará para o jogo;
O usuário agora pode interagir e jogar :).

Jogos P2E em Ação

Jogos P2E precisam apenas de um navegador web, uma conexão com a internet (claro) e um software de Carteira Web, por exemplo, Metamask. Vamos supor que o usuário já tenha realizado o processo de assinatura antes de jogar e que a arquitetura desta aplicação contenha um lado cliente (Client-Side), um lado servidor (Server-Side) e um Serviço.

A imagem abaixo ilustra o fluxo de trabalho para a atualização de dados do jogo:

Neste exemplo, o jogo era uma competição multiplayer onde os usuários podiam jogar e pontuar em um placar global. Após 10 horas, a competição termina e o usuário melhor colocado será recompensado com o token do jogo (este é um spoiler de um dos alvos explorados :p). Então, vamos explicar mais profundamente o processo, desde a conexão até a distribuição do token do jogo:

O usuário conectado joga e alcança a pontuação mais alta;
O jogo enviará a nova pontuação para o back-end processar os dados e realizar algumas verificações;
Após todas as verificações, o servidor enviará os dados para o armazenamento;
Uma resposta do back-end e do serviço para confirmar a modificação dos dados;
O mesmo que acima;
Quando a competição terminar, o servidor chamará um script personalizado para interagir com o contrato inteligente usando o endereço da carteira do vencedor;
Após ser chamado, o contrato inteligente executará a função payWinner com o endereço do usuário vencedor;
Como esta função foi chamada por meio de uma conta com permissão para executá-la, os tokens serão enviados para a carteira do usuário.

Chega de conversa; mostre-me os hacks

Manarium

De acordo com o Gitbook deles, “Manarium é a primeira plataforma de jogos play-to-earn para jogadores e desenvolvedores baseada na Binance Smart Chain. O Manarium utiliza o modelo play-to-earn em cada minijogo para recompensar os melhores jogadores com tokens. É um local onde desenvolvedores de jogos podem lançar seus minijogos e receber uma taxa do prêmio diário acumulado”. Em outras palavras, o Manarium é uma plataforma que permite aos usuários jogar jogos multiplayer e ganhar o token do jogo, neste caso, ARI.

O Manarium possui 3 jogos:

Spiky Walls → Faça o pássaro voar, mas não toque nos espinhos!
To The Moon → Lance seu foguete o mais alto possível na órbita.
In The Woods → Acalme os monstros, não deixe que eles fiquem bravos.

Todos os jogos são baseados no modelo P2E na forma de um torneio diário, no qual os jogadores podem competir entre si e receber o token ARI ao final do torneio (claro, se o usuário for elegível) diretamente no endereço de sua carteira. Os jogos também possuem um placar que gerencia as pontuações dos jogadores e os classifica de acordo com seus pontos.

O placar de vencedores terá 12 posições, onde os 10 primeiros usuários com a maior pontuação serão colocados, e as 2 posições restantes serão preenchidas com 2 usuários sorteados aleatoriamente que participaram do torneio diário.

A tabela abaixo mostra a distribuição dos prêmios entre os 12 vencedores do torneio diário:

Sobre a premiação, a Manarium declara: “Nos três primeiros meses após o lançamento da plataforma de jogos Manarium, cada jogo play-to-earn receberá um bônus diário de 15.000 ARI proveniente da carteira de recompensas” e um adicional: “A segunda parte da premiação consiste nas contribuições dos jogadores. Para participar dos torneios diários e ter a chance de ganhar um prêmio, cada usuário precisa contribuir com uma determinada quantidade de tokens para o pote de prêmios diário do jogo. Inicialmente, a contribuição fixa será de 300 ARI”. Basicamente, quanto mais jogadores participarem do torneio, maior será a recompensa para os 12 vencedores.

A Manarium utiliza uma arquitetura composta por um lado cliente (os jogos, desenvolvidos em Unity) e um serviço (onde os dados do jogo serão armazenados, utilizando o Firebase). Para a distribuição dos prêmios, o administrador realizará o processo, buscando os dados no serviço e chamando o contrato inteligente para executar a função de pagamento.

A imagem abaixo ilustra a arquitetura da Manarium:

O usuário conecta-se, joga e registra uma nova pontuação;
O jogo enviará a nova pontuação para o serviço;
- O torneio terminou?
  - Não
    - Permitir que os usuários continuem jogando
  - Sim
    - Interromper a atualização de dados no serviço (não permitir que os usuários joguem)
O administrador buscará os 10 usuários com as pontuações mais altas;
Após receber a lista de vencedores, o administrador interagirá com o contrato inteligente e chamará a função payWinners com a lista de vencedores.
- Os vencedores receberão seus tokens com base em sua classificação no placar deste torneio.
- Um novo torneio será aberto e as pontuações serão redefinidas

Como já conhecemos o arco do Manarium e como ele funciona, vamos explorá-lo 🙂

Para este alvo em específico, vamos analisar o ataque em 3 fases:

A primeira está relacionada ao exploit inicial descoberto (que foi reportado por mim à equipe do Manarium);
A segunda é sobre o primeiro bypass;
A terceira é sobre o novo bypass para a vulnerabilidade e para o anti-cheat deles (após terem "corrigido" a primeira vulnerabilidade e implementado um "Super Anti-Cheat Seguro" :p).

Explorando o Manarium – 1ª Fase

Nesta fase, o primeiro exploit foi descoberto analisando um de seus arquivos JavaScript.

Ao examinar o arquivo Build.framework.js dentro do diretório Build, notei uma função que chamou minha atenção, _UpdateAccountScore (soa bem, não é?!) na linha 3377. Abaixo podemos ver seu código:

Como podemos ver acima, alguns parâmetros são passados para esta função, sendo eles:

collectionPath → Nome do Jogo;
key → Endereço da Carteira;
valor → Um objeto JSON contendo o endereço da carteira e a pontuação correspondente;
objectName → A configuração do playground (irrelevante para o exploit);
callback → Um callback que será executado após a atualização da pontuação (também irrelevante para o exploit).

Na linha 3383, podemos ver onde os dados são enviados para o Firebase; portanto, ao substituir o parâmetro pelos valores, o código se torna:

firebase.firestore().collection(“GameName”).doc(“USER_WALLET”).set(JSON.parse(“{\”wallet\”:\”USER_WALLET\”,\”score\”:SCORE}”)

Então, sim, basta executar este código na aba Console através da janela do jogo 🙂

Para comprovar a exploração bem-sucedida, veja as imagens abaixo…

Isso vai funcionar? É só isso? Sim (nesta fase, sim)

Após atualizar a página do jogo e verificar o placar novamente, meu valor de pontuação foi alterado para 1201:

Ok, você alterou a pontuação, mas o que mais existe? Lembre-se, este é um jogo P2E, então os vencedores são recompensados com tokens, e foi exatamente o que aconteceu; como fui o primeiro colocado, venci o torneio e recebi alguns tokens 🙂

Ao analisar a transação 0x8b08003…330268 é possível ver que os tokens foram enviados para o meu endereço (o maior valor de tokens):

Esta vulnerabilidade é ainda mais perigosa porque eles não verificavam se o usuário havia pago a taxa inicial (300 ARI) para jogar ao realizar o pagamento (para os vencedores). Assim, qualquer pessoa que execute essa linha de código pode receber os tokens sem precisar jogar ou pagar a taxa.

Vamos para a 2ª fase 🙂

Exploração Manarium – 2ª Fase

Nesta fase, a equipe do Manarium já havia corrigido a vulnerabilidade, mas a correção foi feita de forma insegura; vamos entender o porquê.

Como o Manarium “corrigiu” a vulnerabilidade?

A equipe do Manarium alterou a forma de envio do placar para o Serviço, adicionando uma autenticação antes do envio dos dados, sendo que esta autenticação deve ser feita apenas por meio de uma conta de administrador.
O problema foi que a equipe do Manarium INSERIU DIRETAMENTE NO CÓDIGO as credenciais no arquivo Build.data, onde, após uma desmontagem, encontramos as seguintes credenciais:
e-mail: [email protected]
senha: zz___zzj6;ffd]@U8CW31123@nEw<

A imagem abaixo ilustra a solicitação feita pelo jogo após registrar uma nova pontuação:

Após uma investigação mais aprofundada, encontramos essas credenciais dentro do arquivo Build.data, conforme mostrado na imagem abaixo:

BINGO!! Conseguimos manipular os dados do jogo ao comprovar essas credenciais, gerando um novo token JWT e atualizando a pontuação!

O código acima atualizará a pontuação de todas as carteiras passadas na lista WALLETS para os 3 jogos. Em outras palavras, minhas carteiras estarão entre as 10 melhores nos 3 jogos, e o maior lucro será retornado (já que não precisamos pagar a taxa inicial para entrar no jogo).

Vamos dar uma olhada no código para entender o processo de obtenção do token e atualização da pontuação de um usuário.

Primeiramente, precisamos obter um token JWT válido para usar nas próximas solicitações. Isso será feito pela função step_1():

Por esta fase, é só. O bypass aqui ocorreu porque a equipe da Manarium codificou as credenciais da instância do Firebase diretamente no código-fonte do jogo.

Explorando o Manarium – 3ª Fase

Esta foi a última fase de invasão deste projeto; aqui, a Manarium fez as seguintes modificações no projeto:

Implementou uma nova correção para a vulnerabilidade explorada anteriormente;
Implementou um sistema Super Anti-Cheat para banir usuários que tentam hackear o jogo
Eles mudaram sua arquitetura, que anteriormente era composta por Client-Side e Service. Após a implementação, a arquitetura passou a ser composta por Client-Side e Server-Side (um banco de dados local para armazenar os dados do jogo).

Com a nova infraestrutura, o jogo passou a enviar solicitações contendo os dados diretamente para o lado do servidor, que agora processa e armazena essas informações.

Durante a análise das solicitações, encontramos esta em particular:

Como podemos ver acima, esta solicitação foi usada para recuperar um novo token JWT que pode ser usado para atualizar as informações dos usuários.

A próxima solicitação é responsável por atualizar as informações em si e pode ser encontrada na imagem abaixo:

O data parâmetro nesta solicitação contém todas as informações sobre o jogador codificadas em base64, que, quando decodificadas, resultam no seguinte valor:

{ "gameTitle":"To The Moon", "wallet":"0x64C…029B2", "sessionTime":"2.804", "timeUTC":"2022-01-09 17:17:19", "ip":"XX.XXX.XX.XXX", "gameVersion":2, "score":2 }

gameTitle → O nome do jogo

wallet → A carteira do usuário

sessionTime → O tempo que o usuário leva jogando

timeUTC → O horário atual

ip → O IP do usuário

gameVersion A versão do jogo

pontuação A pontuação do usuário nesta tentativa

Certo, mas como o ‘Super Anti-Cheat’ funciona nesta versão?

O anti-cheat valida os seguintes campos: sessionTime, timeUTC e score, nos quais o usuário deve ter “tempo suficiente” para atingir a pontuação. Em outras palavras, se um usuário marcar 10 pontos em um sessionTime de 1 segundo (o que é impossível, já que o jogo possui obstáculos que exigem um tempo de espera para serem evitados), o anti-cheat detectará um possível trapaceiro.

Após 10 a 20 minutos analisando este anti-cheat, nós o contornamos criando um script com “comportamento humano” (um simples sleep e alguns números aleatórios) que gera uma pontuação alta em um “tempo compatível com humanos”. Vamos analisar as funções da Fase 3 do Manarium Exploit.

A função get_auth_token() é autoexplicativa:

A send_data() gera o corpo da requisição com os valores gerados e envia os dados para o back-end:

A generate_session_time() é a função para gerar um tempo compatível com humanos para cada pontuação, na qual calculamos uma média de 2 segundos por ponto e adicionamos um número aleatório para torná-la mais variável:

A main função contém o brilho do bot, onde o “comportamento humano” ocorre. As primeiras 3 linhas obtêm e exibem o placar atual:

O que será algo como isto:

Dentro do loop While, na linha 287, geramos um sessionTime com base na pontuação mais alta (lembre-se, o sessionTime é calculado com pontuação * 2,03 + algum_número_aleatório).

A linha 290 obterá o token JWT e a linha 291 enviará os dados. Na linha 294, calculamos a variável sleep_back_menu com o valor de sessionTime + 7,34 segundos (esses segundos estão relacionados à atualização da página e ao reingresso no jogo) e, na linha 296, pausamos a execução do script com um sleep (aqui, simulamos uma tentativa do usuário, perder e voltar ao menu).

A linha 300 verificará se a pontuação gerada é a maior pontuação neste torneio; se sim, buscamos e exibimos novamente o placar e, na linha 310, chamamos o sleep novamente com os valores 3600 (1 hora) + um número aleatório entre 0-360; isso foi usado para simular um usuário que se tornou líder do torneio e parou de jogar por 1 hora.

Na linha 319, se não formos os líderes do torneio, aumentaremos nossa pontuação com um valor entre 3-12 (aumentar valores pequenos para não sermos detectados com diferenças de pontuação mais significativas a cada tentativa).

A imagem abaixo mostra a execução do script usando uma nova carteira, desta vez a carteira 0x221…483eF:

A próxima imagem mostra o placar dentro do jogo:

Finalmente, após o término deste torneio, podemos ver na transação 0x78d…221e que meu endereço recebeu 1089 tokens ARI, já que fiquei em 3º lugar:

Nas próximas versões do script, implementamos alguns recursos, como multithreading e suporte para explorar todos os 3 jogos simultaneamente.

Como a Manarium corrigiu a vulnerabilidade?

A Manarium alterou todas as abordagens iniciais, que eram: solicitações com dados não assinados que poderiam ser modificados (ou gerados) por um usuário. A correção implementada funciona; não encontramos uma maneira de contornar essa implementação até o momento, que consiste no uso de Solicitações Assinadas.

A Manarium agora gera 3 solicitações, data1, data2, e data3. Todas essas solicitações podem ser encontradas abaixo:

dados1

dados2

dados3

Como podemos observar, o corpo de todas essas solicitações é assinado com uma chave privada; se tentarmos decodificar esse corpo, o resultado será uma mensagem ilegível, e essa chave provavelmente está dentro do jogo.

Pesquisas futuras se concentrarão na busca por essa chave e na tentativa de realizar um novo bypass.