레이어 제로 우회

L2BEAT 초기부터 L2 프로토콜과 관련된 위험을 분석하고 이해하는 데 많은 노력을 기울였습니다. 우리는 편파적이지 않고 독립적인 감시자가 되기 위해 최선을 다하며 사용자와 생태계의 최선의 이익을 위해 행동합니다. 우리는 프로젝트나 관련된 팀에 대한 개인적인 선호도를 방해하지 않습니다. 그렇기 때문에 특정 팀이 프로젝트에 투입한 시간과 작업을 소중히 여기지만 빨간색 경고를 켜거나 다양한 프로토콜에서 우려 사항을 지적해야 하는 것이 일반적입니다. 보안 관련 논의를 조기에 시작하면 전체 생태계가 잠재적인 위험에 더 잘 대비하고 의심스러운 행동에 더 일찍 대응할 수 있습니다.

오늘 우리는 교차 체인 애플리케이션의 공유 보안 모델에 대한 토론을 시작하려고 합니다. 현재 공유 보안과 애플리케이션별 보안의 두 가지 접근 방식이 있습니다. 예를 들어 첫 번째 공유 보안은 모든 롤업에서 활용됩니다. 두 번째는 애플리케이션별 보안으로 "옴니체인" 프로젝트에서 사용됩니다. 그러한 프로젝트의 대표적인 예가 LayerZero입니다.

공유 보안 대 격리 보안

공유 보안이란 주어진 인프라에서 실행되는 특정 토큰 또는 앱이 보안 모델을 자유롭게 선택하지 않는다는 것을 의미합니다. 대신 인프라에서 요구하는 모든 보안 요구 사항을 준수해야 합니다. 예를 들어 낙관적 롤업은 일반적으로 7일의 완결 기간을 부과합니다. 이러한 롤업에서 실행되는 앱은 이 기간을 단순히 무시하거나 단축할 수 없습니다. 장애물처럼 보일 수 있지만 이유가 있는 장애물입니다. 이를 통해 사용자는 앱의 내부 보안 정책에 관계없이 해당 롤업에서 사용 중인 앱이 무엇이든 사용자가 보유할 수 있는 안전 보장을 제공할 수 있습니다. 앱은 롤업 정책을 강화할 뿐 약화시킬 수는 없습니다.

격리된 보안이란 어떤 방식으로든 인프라에 의해 제한되지 않고 모든 앱이 보안을 정의할 책임이 있음을 의미합니다. 처음에는 좋은 생각처럼 보일 수 있습니다. 결국 앱 개발자는 앱에 필요한 보안 조치가 무엇인지 가장 잘 알고 있습니다. 그러나 동시에 모든 앱의 보안 정책과 관련된 위험 평가에 대한 책임을 최종 사용자에게 이전합니다. 또한 앱 개발자가 앱 정책을 자유롭게 선택할 수 있다면 원할 때 언제든지 변경하도록 선택할 수도 있습니다. 따라서 모든 앱에 대해 위험을 한 번 평가하는 것만으로는 충분하지 않으며 앱 정책이 변경될 때마다 평가해야 합니다.

문제

우리는 각 앱이 자체 보안 정책을 자유롭게 정의할 수 있는 격리된 보안 모델이 심각한 보안 문제를 야기한다고 생각합니다. 우선 최종 사용자가 사용하려는 모든 앱에 대한 위험을 개별적으로 검증해야 하기 때문에 최종 사용자의 위험이 증가합니다.

또한 이러한 모델을 사용하는 앱의 위험도 증가합니다. 격리된 보안은 보안 정책 변경과 관련된 추가 위험을 추가합니다. 공격자가 애플리케이션의 보안 모델을 변경하게 되면 간단히 비활성화하여 자금을 빼내거나 다른 방식으로 오용할 가능성을 제공할 수 있습니다. 오용을 방지하는 애플리케이션 위에 추가 보안 계층이 없습니다.

또한 보안 정책이 언제든지 즉시 변경될 수 있으므로 매일 앱을 모니터링하고 사용자에게 위험에 대해 알리는 것이 사실상 불가능합니다.

스마트 계약의 업그레이드 가능성과 유사합니다. 우리는 이미 L2BEAT에서 이에 대해 경고합니다 . 우리는 사용자에게 스마트 계약에 업그레이드 가능성 메커니즘이 있는 롤업 및 브리지와 각 경우에 업그레이드 가능성을 제어하는 ​​정확한 메커니즘에 대해 알려줍니다. 이것은 이미 꽤 복잡하고 격리된 보안 모델을 사용하면 모든 앱에 대해 배가되므로 효과적으로 추적하는 것이 거의 불가능합니다.

이것이 우리가 격리된 보안 모델을 그 자체로 보안 위험으로 간주하는 이유이며, 그러한 모델을 사용하는 모든 앱은 그렇지 않다는 것이 입증될 때까지 기본적으로 위험한 것으로 취급한다고 가정합니다.

계획

우리는 메인넷에서 현실 세계에서 우리의 가정을 테스트하기로 결정했습니다. LayerZero 프레임워크는 핵심에서 격리된 보안을 사용하는 가장 인기 있는 솔루션 중 하나이기 때문에 실험을 위해 선택되었습니다. 우리는 안전한 옴니체인 토큰을 배포했고 나중에 악의적인 토큰 인출을 허용하는 보안 구성을 업데이트했습니다. 토큰의 코드는 LayerZero에서 제공하는 예제를 기반으로 하며 생산에 배포된 다른 많은 옴니체인 토큰 및 앱과 매우 유사하거나 동일합니다.

하지만 자세히 알아보기 전에 LayerZero 보안 모델이 어떻게 생겼는지 간단히 살펴보겠습니다.

LayerZero의 백서에서 명확하게 언급한 바와 같이, 그것의 "신뢰가 필요 없는 체인 간 통신"은 프로토콜의 안전을 보장하기 위해 함께 행동하는 두 개의 독립적인 행위자(오라클과 중계자)에 의존합니다.

LayerZero가 웹 사이트에서 언급한 것처럼 핵심 개념은 "ULN(UltraLightNode)을 실행하는 사용자 애플리케이션 구성 가능한 온체인 엔드포인트"라는 것입니다. LayerZero의 온체인 구성 요소는 Oracle과 Relayer라는 체인 간에 메시지를 전달하기 위해 두 개의 외부 오프체인 당사자에 의존합니다.

메시지 M이 체인 A에서 체인 B로 전송될 때마다 다음 두 가지 작업이 수행됩니다.

• 먼저 오라클은 체인 A에서 메시지 M을 전송하는 트랜잭션이 완료될 때까지 기다린 다음 블록 헤더의 해시와 같은 메시지 번들에 대한 약속을 체인 B에 기록합니다(정확한 형식은 체인/오라클마다 다를 수 있음). 해당 메시지 M을 포함하는 체인 A에서
• 그런 다음 Relayer는 저장된 헤더에 메시지 M이 포함되어 있다는 "증명"(예: Merkle Proof)을 체인 B로 보냅니다.

LayerZero는 "LayerZero의 설계는 담합의 가능성을 제거한다"고 주장합니다. 그러나 실제로는 각 사용자 애플리케이션이 고유한 Relayer와 Oracle을 정의할 수 있으므로 이 진술은 사실이 아닙니다(아래에 표시된 실험에서 증명함). LayerZero는 이러한 구성 요소가 독립적이고 충돌할 수 없음을 설계상 보장하지 않습니다. 이러한 보증을 제공하는 것은 사용자 애플리케이션에 달려 있습니다. 그리고 응용 프로그램이 이를 중단하기로 선택하면 LayerZero 역학에서 중단할 수 있는 것은 없습니다.

또한 기본적으로 모든 사용자 애플리케이션은 Relayer와 Oracle을 언제든지 변경할 수 있으므로 보안 가정을 ​​완전히 재정의할 수 있습니다. 따라서 주어진 앱의 보안을 한 번 확인하는 것만으로는 충분하지 않습니다. 실험에서 확인할 수 있듯이 확인 후 언제든지 변경되었을 수 있습니다.

실험

실험에서 우리는 이더리움과 Optimism 모두에서 작동하는 간단한 옴니체인 토큰인 CarpetMoon을 만들고 ZeroLayer를 사용하여 두 체인 간에 통신하기로 결정했습니다.

우리의 토큰은 초기에 LayerZero에서 제공하는 기본 보안 모델을 사용하므로 현재 배포된 대부분의(전부는 아니지만) LayerZero 응용 프로그램과 상당히 동일하게 보입니다. 따라서 일반적으로 LayerZero를 사용하는 다른 토큰만큼 안전합니다.

먼저 이더리움과 Optimism 모두에 토큰 계약을 배포합니다.
https://ethtx.info/mainnet/0xf4d1cdabb6927c363bb30e7e65febad8b9c0f6f76f1984cd74c7f364e3ab7ca9/
https://optimistic.etherscan.io/tx/0xf41389d71fa3942de5225efb067072728c6c6de56c241574187781db7c73d221

그리고 LayerZero가 두 체인의 어느 계약에 해당하는지 알 수 있도록 라우팅을 설정합니다.
https://ethtx.info/mainnet/0x19d78abb03179969d6404a7bd503148b4ac14d711f503752495339c96a7776e9/
https://optimistic.etherscan.io/tx/0x037b1bad33faa5607bb5835460a1d5caaf3a147dc3a09762ac7703befcdb3c3c

따라서 토큰이 설정되고 기본 구성으로 LayerZero를 사용하는 다른 모든 옴니체인 토큰과 똑같이 보입니다.

우리는 테스트 사용자에게 테스트 토큰을 Alice라고 부르도록 제공하므로 Alice는 Ethereum에서 10억 개의 CarpetMoon 토큰을 갖게 됩니다.
https://ethtx.info/mainnet/0x7e2faa8426dacae92830efbf356ca2da760833eca28e652ff9261fc03042b313/

이제 Alice는 LayerZero를 사용하여 해당 토큰을 Optimism에 연결합니다.

Ethereum의 에스크로에 토큰을 잠급니다.
https://ethtx.info/mainnet/0xe4dc3757b86bfda8e7baddc088fb1a599e083ed77034c29e5dd8bd11f1e17771/

트랜잭션이 포함된 메시지는 LayerZero를 통해 Optimism에 전달됩니다.
https://layerzeroscan.com/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/message/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/nonce/1

브리지된 토큰은 Optimism에서 발행되고 있으며 Alice는 이제 Optimism에서 10억 MoonCarpet 토큰을 보유하고 있습니다.
https://optimistic.etherscan.io/tx/0x5388ced88cf562acafff82d6798f791b0b38b90ee106df9bf91c0d86306ec302

좋아, 모든 것이 예상대로 작동했기 때문에 Alice는 토큰을 연결하고 Ethereum의 에스크로에 10억 개의 MoonCarpet 토큰이 있고 Optimism에서 그녀의 계정에 10억 개의 MoonCarpet 토큰이 있음을 확인했습니다. 그러나 모든 것이 올바르게 작동하는지 확인하기 위해 그녀는 토큰의 절반(500M MoonCarpet)을 이더리움으로 다시 전송합니다.

따라서 우리는 Optimism에서 5억 개의 토큰을 태우는 트랜잭션으로 시작합니다.
https://optimistic.etherscan.io/tx/0x118a57106488ad0bae1f3b920b1fd98b187752ad966f3a901fc53cff47f2097f

해당 거래에 대한 정보가 이더리움으로 전달됩니다.
https://layerzeroscan.com/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/message/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/nonce/1

그리고 예상대로 5억 개의 MoonCarpet 토큰이 에스크로에서 Alice의 주소로 다시 전달됩니다.
https://etherscan.io/tx/0x27702e07a65a9c6a7d1917222799ddb13bb3d05159d33bbeff2ca1ed414f6a18

지금까지는 가정한 대로 모든 것이 잘 작동합니다. 앨리스는 이더리움에서 옵티미즘으로 토큰을 옮길 수 있고 다시 그 반대로 옮길 수 있음을 확인했습니다. 그녀는 MoonCarpet 토큰에 대해 두려워할 이유가 없습니다.

하지만 문제가 발생했다고 가정해 보겠습니다. 예를 들어 토큰 배후의 팀이 손상되고 악의적인 행위자 Bob이 앱의 LayerZero 구성에 대한 액세스 권한을 얻습니다.

이러한 액세스를 통해 Bob은 Oracle 및 Relayer를 기본값에서 자신이 제어할 수 있는 것으로 변경할 수 있습니다.

이것은 LayerZero의 아키텍처에 뿌리내린 LayerZero를 사용하는 모든 앱에 제공되는 메커니즘이며 백도어가 아니라 표준 메커니즘이라는 점을 명심하십시오.

따라서 Bob은 Oracle을 자신의 통제하에 있는 EOA로 변경합니다.
https://ethtx.info/mainnet/0x4dc84726da6ca7d750eef3d33710b5f63bf73cbe03746f88dd8375c3f4672f2f/

Relayer도 마찬가지입니다.
https://ethtx.info/mainnet/0xc1d7ba5032af2817e95ee943018393622bf54eb87e6ff414136f5f7c48c6d19a/

그리고 이제 이상한 일이 일어납니다. 이제 Oracle과 Relayer가 Bob의 완전한 통제하에 있으므로 Bob은 Alice의 토큰을 훔칠 수 있습니다. Optimism에서 아무 조치도 취하지 않더라도(MoonCarpet 토큰은 여전히 ​​Alice의 지갑에 있음) Bob은 다른 체인에서 토큰을 소각하고 MoonCarpet 토큰을 인출할 수 있다고 Ethereum의 MoonCarpet 스마트 계약(LayerZero 메커니즘 사용)을 설득할 수 있습니다. 이더리움에서.

먼저, 그는 불량 Oracle을 사용하여 Ethereum의 블록해시를 업데이트합니다.
https://ethtx.info/0xde2edee2cc7f070120e96c9df90d86696970befcfc221e18c6ac4168bb5b1d92/

이제 그는 에스크로에서 남은 토큰을 인출할 수 있습니다.
https://ethtx.info/0xda695f374b375d5372efeca37aae4c5a17f114d5a76db1e86edebb0924bcdcc7/

결과

앨리스는 왜, 언제 무슨 일이 일어났는지조차 모를 것입니다. 갑자기 Optimism의 MoonCarpet 토큰이 더 이상 Ethereum의 토큰으로 지원되지 않습니다.

스마트 계약은 업그레이드할 수 없으며 의도한 대로 작동합니다. 유일하게 의심스러운 활동은 Oracle과 Relayer의 변경이지만 이것은 LayerZero에 내장된 일반적인 메커니즘이므로 Alice는 이 변경이 의도적인 것인지 여부조차 알 수 없습니다. 그리고 앨리스가 그 변화에 대해 알게 되더라도 이미 너무 늦었을 것입니다. 공격자는 그녀가 대응하기도 전에 자금을 고갈시킬 수 있습니다.

그리고 LayerZero는 여기에서도 도움을 줄 수 없었습니다. 이것들은 모두 더 이상 제어할 수 없는 메커니즘의 유효한 실행이었습니다. 이론적으로 애플리케이션 자체는 Oracle 및 Relayer를 변경하지 못하도록 차단할 수 있지만 이미 배포된 애플리케이션 중 어느 것도 차단하지 않았습니다.

우리는 누군가가 그것을 알아차리는지 확인하기 위해 이 실험을 했지만 예상대로 아무도 알아차리지 못했습니다. LayerZero로 구축된 모든 애플리케이션을 효과적으로 모니터링하여 보안 정책이 변경되지 않았는지 확인하고 변경된 경우 사용자에게 경고하는 것은 사실상 불가능합니다.

Oracle과 Relayer가 보안 위험을 내포하는 방식으로 변경된 것을 따라잡을 수 있었다고 해도 발생했을 때는 이미 너무 늦었습니다. 새로운 Oracle 및 Relayer는 이제 체인 간의 통신을 검열하거나 단순히 비활성화하도록 자유롭게 선택할 수 있으므로 일반적으로 사용자는 이에 대해 아무 것도 할 수 없습니다. Alice가 애플리케이션 구성의 변경 사항을 알아차리더라도 브리지된 토큰으로 많은 작업을 수행할 수 없기 때문에 이는 실험에서 명확하게 나타납니다. 새로운 Oracle 및 Relayer는 더 이상 원래 체인에서 수신 대기하지 않으므로 이더리움으로 돌아가는 메시지.

결론 및 CTA

위에서 볼 수 있듯이 우리의 토큰은 LayerZero를 사용하여 구축되었고 의도한 대로 메커니즘을 사용했지만 토큰의 에스크로에서 자금을 훔칠 수 있었습니다. 물론 이는 LayerZero 자체가 아니라 애플리케이션(우리의 경우 CarpetMoon 토큰)의 결함이었지만, 이는 LayerZero 자체가 어떠한 보안 보장도 제공하지 않는다는 것을 증명합니다 .

LayerZero가 Oracle 및 Relayer에 관한 보안 모델을 설명할 때 앱 소유자(또는 개인 키를 소유한 사람)가 비합리적인 작업을 수행하지 않을 것이라고 가정합니다. 그러나 그 가정은 적대적인 환경에서 올바르지 않습니다. 또한 사용자는 애플리케이션 소유자를 신뢰할 수 있는 제3자로 신뢰해야 합니다.

실제로 이 결과로 LayerZero를 사용하여 구축된 애플리케이션의 보안에 대해 어떤 가정도 할 수 없습니다. 각 앱은 그렇지 않다는 것이 입증될 때까지 위험한 것으로 간주되어야 합니다.

실제로 전체 이야기는 L2BEAT 사이트에 모든 옴니체인 토큰을 포함할 계획인 PR로 시작되었습니다. 위험을 평가하는 방법을 파악하는 데 어려움을 겪었습니다. 위험 벡터를 분석하는 동안 우리는 실험 아이디어를 생각해 냈습니다.

L2BEAT의 경우 LayerZero를 사용하여 구축된 모든 앱 위에 경고를 표시하여 가능한 보안 위험에 대해 경고해야 합니다. 그러나 우리는 격리된 보안이 특히 우리 공간에서 피해야 하는 안티 패턴이라고 믿기 때문에 보안 모델에 대해 더 폭넓은 논의를 시작하고 싶습니다.

우리는 LayerZero와 같은 격리된 보안 모델이 점점 더 대중화됨에 따라 이를 악용하는 프로젝트가 점점 더 많아져 많은 피해를 입히고 전체 산업에 대한 불확실성을 증가시킬 것이라고 확신합니다.