原文标题：《Contornando a camada zero: por que segurança isolada não é segurança》
Autor: Krzysztof Urbański, membro da equipe L2BEAT
Compilado por: Babywhale, Foresight News
A L2BEAT investiu esforços consideráveis desde a sua criação para analisar e compreender os riscos associados aos protocolos da Camada 2. Agimos sempre no melhor interesse dos nossos utilizadores e do ecossistema e fazemos o nosso melhor para sermos um supervisor imparcial e independente, sem permitir que as nossas preferências pessoais por projetos ou equipas relacionadas influenciem os factos. É por isso que, embora respeitemos o tempo e o esforço que a equipa do projeto dedica ao projeto, podemos “soar o alarme” ou apontar as nossas preocupações sobre os riscos potenciais de determinados protocolos. Ter discussões antecipadas sobre segurança permite que todo o ecossistema esteja melhor preparado para riscos potenciais e reaja mais cedo a qualquer comportamento suspeito.
Hoje gostaríamos de discutir o modelo de segurança compartilhada para aplicações cross-chain. Atualmente existem dois modelos de segurança: segurança compartilhada e segurança de aplicações independentes. A segurança compartilhada é como todos os Rollups. A segurança de aplicativos autônomos é usada principalmente por projetos "omnichain", que usam principalmente LayerZero.
Segurança compartilhada versus segurança independente
A segurança partilhada refere-se a um token ou aplicação específica em execução numa determinada infraestrutura e, em vez de escolher livremente um modelo de segurança, devem aderir a quaisquer requisitos de segurança impostos pela infraestrutura. Por exemplo, os Optimistic Rollups normalmente impõem uma janela final de 7 dias – um aplicativo em execução nesses Rollups não pode simplesmente ignorar ou encurtar esse período. Embora isso possa parecer um obstáculo, há uma razão para isso. Este período fornece aos usuários garantias de segurança de que, independentemente da política de segurança interna do aplicativo, que deve ser respeitada, o aplicativo só poderá fortalecer a segurança dos Rollups, e não enfraquecê-la.
Segurança independente significa que cada aplicação é responsável por definir a sua segurança e não é restringida de forma alguma pela infraestrutura. A princípio pode parecer uma boa ideia, afinal, o desenvolvedor do aplicativo sabe melhor quais medidas de segurança o aplicativo pode precisar. Mas, ao mesmo tempo, transfere a responsabilidade de avaliar os riscos associados a cada política de segurança de aplicação para o usuário final. Além disso, se os desenvolvedores de aplicativos forem livres para escolher suas políticas de segurança, eles também poderão alterá-las a qualquer momento. Portanto, não basta avaliar o risco uma vez para cada aplicação; ele deve ser avaliado sempre que as políticas de uma aplicação mudam;
Problemas
Acreditamos que um modelo de segurança independente, no qual cada aplicação é livre para definir a sua política de segurança, cria sérios problemas de segurança. Primeiro, aumenta o risco para os usuários finais porque eles devem verificar o risco de cada aplicativo que pretendem usar.
A segurança autônoma também aumenta os riscos para aplicativos que usam esse modelo, por exemplo, adicionando riscos adicionais em relação a mudanças na política de segurança - se um invasor alterasse o modelo de segurança do aplicativo, ele poderia simplesmente desativá-lo, ficando sem dinheiro ou arriscando-o. de qualquer maneira. Não há camadas adicionais de segurança no aplicativo para evitar ataques.
Além disso, como as políticas de segurança podem mudar a qualquer momento e em tempo real, é quase impossível monitorar os aplicativos em tempo real e informar os usuários sobre os riscos.
Achamos que é semelhante à capacidade de atualização dos contratos inteligentes, sobre a qual alertamos no L2BEAT. Informamos os usuários sobre pontes rollup e cross-chain que possuem mecanismos de atualização em seus contratos inteligentes e os mecanismos exatos para gerenciar a capacidade de atualização em cada caso. Isso já é bastante complexo e o uso de um modelo de segurança separado multiplica o número, tornando quase impossível o rastreamento eficaz.
É por isso que consideramos um modelo de segurança independente um risco de segurança por si só, e assumimos que cada aplicação que usará este modelo por padrão deve ser considerada arriscada até prova em contrário.
Prove que existem vulnerabilidades de segurança
Decidimos testar nossa hipótese na mainnet. A estrutura LayerZero foi escolhida para experimentação porque é uma das soluções autônomas mais populares com foco em segurança. Implantamos um token omnichain seguro e posteriormente atualizamos a configuração de segurança para permitir retiradas maliciosas do token. O código do token é baseado nos exemplos fornecidos pela LayerZero e é muito semelhante ou idêntico a muitos outros tokens e aplicativos omnichain implantados na vida real.
Mas antes de entrarmos em detalhes, vamos dar uma breve olhada na aparência do modelo de segurança LayerZero.
Como a LayerZero aponta em seu white paper, sua “comunicação entre cadeias sem confiança” depende de dois atores independentes (oráculos e retransmissores) agindo em conjunto para garantir a segurança do protocolo.
LayerZero afirma em seu site que seu conceito central é “aplicativos de usuário executando ULN (UltraLightNode), terminais configuráveis em cadeia”. O componente on-chain do LayerZero depende de dois componentes externos fora da cadeia para retransmitir mensagens entre cadeias – oráculos e retransmissores.
Sempre que qualquer mensagem M é enviada da cadeia A para a cadeia B, ocorrem as duas operações a seguir:
Primeiro, o oráculo espera até que a transação que envia a mensagem M na cadeia A seja concluída e, em seguida, escreve informações relevantes na cadeia B, como o valor hash do cabeçalho do bloco da cadeia A contendo a mensagem M (o valor exato entre diferentes cadeias/oráculos O formato pode variar).
O relé então envia uma "prova" (como Merkle Proof) para a cadeia B, provando que o cabeçalho do bloco armazenado contém a mensagem M.
LayerZero assume que relés e oráculos são participantes independentes e honestos. No entanto, LayerZero também afirmou no white paper que se esta suposição não for atendida, por exemplo, o retransmissor e o oráculo conspiram, resultando em "tanto o cabeçalho do bloco fornecido pelo oráculo quanto a prova de transação fornecida pelo retransmissor sendo inválidos, mas ainda combinando."
LayerZero afirma que “o design do LayerZero elimina a possibilidade de conluio”. Mas, na verdade, esta afirmação está incorreta (provamos isso nos experimentos mostrados abaixo), pois cada aplicação de usuário pode definir seus próprios relés e oráculos. LayerZero não garante por design que esses componentes sejam independentes e não possam ser coniventes; em vez disso, cabe ao aplicativo do usuário fornecer essas garantias; LayerZero não possui mecanismo para interromper aplicativos se eles decidirem quebrá-los.
Além disso, por padrão, todos os aplicativos de usuário podem alterar relés e oráculos a qualquer momento, redefinindo completamente as suposições de segurança. Portanto, verificar a segurança de uma determinada aplicação apenas uma vez não é suficiente, pois ela poderá sofrer alterações a qualquer momento após a verificação, como mostraremos em nossos experimentos.
design experimental
Para nossos experimentos, decidimos criar um token omnichain simples, CarpetMoon, que roda em Ethereum e Optimism e usa LayerZero para comunicação entre as duas cadeias.
Nosso token inicialmente usa o modelo de segurança padrão fornecido pelo LayerZero, tornando-o idêntico a um grande (talvez não todos) aplicativos LayerZero atualmente implantados. Portanto, geralmente é tão seguro quanto qualquer outra moeda usando LayerZero.
Primeiro, implantamos nosso contrato de token no Ethereum e no Optimism:
https://ethtx.info/mainnet/0xf4d1cdabb6927c363bb30e7e65febad8b9c0f6f76f1984cd74c7f364e3ab7ca9/
https://optimistic.etherscan.io/tx/0xf41389d71fa3942de5225efb067072728c6c6de56c241574187781db7c73d221
Em seguida, configuramos o roteamento para que o LayerZero saiba qual contrato corresponde a qual em ambas as cadeias.
https://ethtx.info/mainnet/0x19d78abb03179969d6404a7bd503148b4ac14d711f503752495339c96a7776e9/
https://optimistic.etherscan.io/tx/0x037b1bad33faa5607bb5835460a1d5caaf3a147dc3a09762ac7703befcdb3c3c
O token foi implantado e se parece exatamente com qualquer outro token omnichain usando LayerZero, usando a configuração padrão e nada de suspeito nisso.
Fornecemos 1 bilhão de tokens CarpetMoon no Ethereum para nossa “usuária de teste” Alice.
https://ethtx.info/mainnet/0x7e2faa8426dacae92830efbf356ca2da760833eca28e652ff9261fc03042b313/
Agora Alice usa LayerZero para encadear esses tokens com o Optimism.
Bloqueamos os tokens em um contrato de garantia no Ethereum:
https://ethtx.info/mainnet/0xe4dc3757b86bfda8e7baddc088fb1a599e083ed77034c29e5dd8bd11f1e17771/。
A mensagem contendo a transação está sendo passada para o Optimism via LayerZero:
https://layerzeroscan.com/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/message/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7nonced10d/。
Tokens de cadeia cruzada estão sendo cunhados no Optimism, e Alice agora possui 1 bilhão de tokens MoonCarpet no Optimism:
https://optimistic.etherscan.io/tx/0x5388ced88cf562acaff82d6798f791b0b38b90ee106df9bf91c0d86306ec302。
Tudo funciona como esperado, Alice faz o cross-chain dos tokens e vê que há 1 bilhão de tokens MoonCarpet no contrato de garantia no Ethereum e 1 bilhão de tokens MoonCarpet em sua conta no Optimism. Mas só para ter certeza de que estava tudo bem, ela transferiu metade de seus tokens de volta para Ethereum.
Começamos com uma transação no Optimism que queimou 500 milhões de tokens:
https://optimistic.etherscan.io/tx/0x118a57106488ad0bae1f3b920b1fd98b187752ad966f3a901fc53cff47f2097f。
As informações sobre a transação são repassadas ao Ethereum:
https://layerzeroscan.com/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/message/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/nonce/1。
Como esperado, 500 milhões de tokens MoonCarpet são devolvidos do contrato de garantia para o endereço de Alice:
https://etherscan.io/tx/0x27702e07a65a9c6a7d1917222799ddb13bb3d05159d33bbeff2ca1ed414f6a18。
Até agora, tudo está funcionando bem e exatamente como esperado. Alice verificou se ela pode cruzar tokens de Ethereum para Optimism e vice-versa, ela não tem motivo para se preocupar com seus tokens MoonCarpet.
Mas as hipóteses têm seus próprios problemas - por exemplo, a equipe por trás do nosso token enfrenta problemas e o bandido Bob obtém acesso à configuração LayerZero do nosso aplicativo.
Dessa forma, Bob pode alterar os oráculos e relés dos componentes padrão para componentes que ele controla.
Deve-se observar que este é um mecanismo fornecido para todos os aplicativos que usam LayerZero e está enraizado na arquitetura do LayerZero. Não é um backdoor de nenhum tipo, mas um mecanismo padrão.
Então Bob muda o oráculo para um EOA sob seu controle:
https://ethtx.info/mainnet/0x4dc84726da6ca7d750eef3d33710b5f63bf73cbe03746f88dd8375c3f4672f2f/。
O repetidor também foi alterado:
https://ethtx.info/mainnet/0xc1d7ba5032af2817e95ee943018393622bf54eb87e6ff414136f5f7c48c6d19a/。
Agora algo estranho acontece. Como o oráculo e o relé estão agora sob controle total de Bob, ele é capaz de roubar as fichas de Alice. Mesmo que nenhuma ação tenha sido tomada em relação ao Optimism (os tokens MoonCarpet ainda estavam na carteira de Alice), Bob conseguiu convencer o contrato inteligente MoonCarpet no Ethereum (usando o mecanismo LayerZero) de que ele destruiu os tokens na outra cadeia e foi capaz de retirar os tokens do token MoonCarpet no Ethereum.
Primeiro, ele atualiza o hash do bloco Ethereum usando um oráculo que ele controla:
https://ethtx.info/0xde2edee2cc7f070120e96c9df90d86696970befcfc221e18c6ac4168bb5b1d92/。
Agora ele pode retirar os tokens restantes do contrato de garantia:
https://ethtx.info/0xda695f374b375d5372efeca37aae4c5a17f114d5a76db1e86edebb0924bcdcc7/。
Resultados experimentais
Alice nem sabe por que e quando o erro ocorreu. De repente, seu token MoonCarpet no Optimism não era mais apoiado por tokens no Ethereum.
O contrato inteligente não pode ser atualizado e funciona conforme o esperado. A única atividade suspeita são as alterações do oráculo e do relé, mas esse é um mecanismo regular incorporado ao LayerZero, então Alice nem sabe se essa alteração é intencional. Mesmo que Alice saiba da mudança, será tarde demais – o invasor pode drenar os fundos antes que ela possa reagir.
Não há nada que o LayerZero possa fazer - todas essas são implementações eficientes de seus mecanismos, sobre os quais eles não têm controle. Em teoria, os próprios aplicativos poderiam evitar a mudança de oráculos e relés, mas, até onde sabemos, nenhum aplicativo implantado o fez.
Fizemos esse experimento para testar se alguém percebeu, mas como esperávamos, ninguém percebeu. É quase impossível monitorar efetivamente todos os aplicativos criados com LayerZero para verificar se suas políticas de segurança foram alteradas e alertar os usuários quando isso acontecer.
Mesmo que alguém consiga descobrir a tempo que os oráculos e os relés mudaram e criaram um risco de segurança, será tarde demais. Como os novos oráculos e retransmissores agora são livres para escolher quais mensagens entregar ou simplesmente desabilitar a comunicação entre cadeias, geralmente não há muito que os usuários possam fazer a respeito. Nossos experimentos mostram claramente que mesmo que Alice perceba a mudança na configuração do aplicativo, ela não pode fazer muito com seus tokens de cadeia cruzada - os novos oráculos e relés não são mais aceitos na mensagem original da cadeia de comunicação, então a mensagem não será devolvida ao Ethereum .
para concluir
Como podemos ver, embora nosso token tenha sido construído com LayerZero e usado sua mecânica conforme planejado, conseguimos roubar fundos do depósito do token. Claro, isso é culpa do aplicativo (no nosso caso, o token CarpetMoon) e não do próprio LayerZero, mas prova que o próprio LayerZero não oferece nenhuma garantia de segurança.
Quando LayerZero descreve seu modelo de segurança em relação a oráculos e retransmissores, eles assumem que o proprietário do aplicativo (ou quem possui a chave privada) não fará nada irracional. Mas num ambiente adversário, esta suposição está incorreta. Além disso, exige que os usuários confiem no desenvolvedor do aplicativo como um terceiro confiável.
Portanto, na prática, não se pode fazer suposições sobre a segurança dos aplicativos criados com LayerZero – cada aplicativo deve ser considerado arriscado até prova em contrário.
Na verdade, toda a história começou com um PR de que planejávamos incluir todos os tokens omnichain no site L2BEAT - estávamos tendo dificuldade em descobrir como avaliar o risco deles. Ao analisar os riscos, surgiu a ideia da experimentação.
Se o L2BEAT fosse lançado, a consequência seria que teríamos que colocar alertas em cada aplicação construída com LayerZero para alertar sobre possíveis riscos de segurança. Mas queríamos ter uma discussão mais ampla sobre modelos de segurança porque acreditamos que a segurança autônoma é um modelo que deve ser evitado, especialmente em nossa área.
Acreditamos que à medida que modelos de segurança independentes como o LayerZero se tornam mais populares, mais e mais projetos irão abusar deles, causando danos massivos e aumentando a incerteza em toda a indústria.