L2BEAT는 실험을 통해 LayerZero를 "해킹"했습니다: 왜 "독립적인 안전성"이 안전하지 않은가?
현재 프로젝트는 오라클과 중계기의 수정 권한을 제한하지 않아 해커가 권한을 얻으면 마음대로 공격할 수 있습니다.원문 제목：《Layer Zero 우회: 격리된 보안은 보안이 아니다》
저자: Krzysztof Urbański, L2BEAT 팀원
편집: Babywhale, Foresight News
L2BEAT는 설립 이후 Layer 2 프로토콜과 관련된 위험을 분석하고 이해하는 데 많은 노력을 기울여 왔습니다. 우리는 항상 사용자와 생태계의 최대 이익을 출발점으로 삼아, 프로젝트나 관련 팀에 대한 개인적 선호가 사실에 영향을 미치지 않도록 공정하고 독립적인 감독자가 되기 위해 최선을 다하고 있습니다. 그렇기 때문에 우리는 프로젝트 팀이 프로젝트에 투자한 시간과 노력을 존중하지만, 특정 프로토콜에 존재하는 잠재적 위험에 대해 "경고"를 하거나 우리의 우려를 지적할 것입니다. 보안 관련 논의를 조기에 진행하는 것은 전체 생태계가 잠재적 위험에 더 잘 대비하고 의심스러운 행동에 더 빨리 반응할 수 있게 합니다.
오늘 우리는 크로스체인 애플리케이션의 공유 보안 모델에 대해 논의하고자 합니다. 현재 두 가지 보안 모델이 있습니다: 공유 보안과 독립 애플리케이션 보안. 공유 보안은 모든 Rollup의 예입니다. 독립 애플리케이션 보안은 주로 "omnichain" 프로젝트에서 사용되며, 이러한 프로젝트의 주요 사용자는 LayerZero입니다.
공유 보안과 독립 보안
공유 보안은 특정 토큰이나 애플리케이션이 주어진 인프라에서 실행되는 것을 의미하며, 자유롭게 보안 모델을 선택할 수 없고 인프라가 부과한 모든 보안 요구 사항을 준수해야 합니다. 예를 들어, Optimistic Rollups는 일반적으로 7일의 최종 결정 기간을 부과합니다. 이러한 Rollups에서 실행되는 애플리케이션은 이 기간을 간단히 무시하거나 단축할 수 없습니다. 이는 장애물처럼 보일 수 있지만, 이유가 있습니다. 이 기간은 사용자에게 보안 보장을 제공하며, 애플리케이션의 내부 보안 정책이 무엇이든 이 보안 정책을 준수해야 하며, 애플리케이션은 Rollups의 보안을 강화할 수는 있지만 약화할 수는 없습니다.
독립 보안은 각 애플리케이션이 자신의 보안을 정의할 책임이 있으며, 인프라에 의해 어떤 방식으로도 제한받지 않는 것을 의미합니다. 겉보기에는 좋은 아이디어처럼 보이지만, 애플리케이션 개발자가 애플리케이션에 필요한 보안 조치를 가장 잘 알기 때문입니다. 그러나 동시에, 이는 각 애플리케이션의 보안 정책 위험과 관련된 책임을 최종 사용자에게 전가합니다. 또한, 애플리케이션 개발자가 자유롭게 보안 정책을 선택할 수 있다면, 언제든지 이를 변경할 수 있습니다. 따라서 각 애플리케이션의 위험을 한 번 평가하는 것으로는 충분하지 않으며, 애플리케이션 정책이 변경될 때마다 이를 평가해야 합니다.
문제점
우리는 각 애플리케이션이 자유롭게 보안 정책을 정의할 수 있는 독립 보안 모델이 심각한 보안 문제를 초래한다고 생각합니다. 첫째, 이는 최종 사용자의 위험을 증가시킵니다. 왜냐하면 그들은 사용하려는 각 애플리케이션의 위험을 검증해야 하기 때문입니다.
독립 보안은 또한 이러한 모델을 사용하는 애플리케이션의 위험을 증가시킵니다. 예를 들어, 보안 정책 변경에 대한 추가 위험이 증가합니다. 공격자가 애플리케이션의 보안 모델을 변경하려고 한다면, 차라리 이를 비활성화하여 자금을 고갈시키거나 다른 방식으로 공격하는 것이 더 쉽습니다. 애플리케이션 위에는 공격을 방지할 추가 보안 계층이 없습니다.
또한, 보안 정책이 언제든지 즉시 변경될 수 있기 때문에 애플리케이션을 실시간으로 모니터링하고 사용자에게 위험을 알리는 것은 거의 불가능합니다.
우리는 이것이 스마트 계약의 업그레이드 가능성과 유사하다고 생각하며, 우리는 이미 L2BEAT에서 경고를 발신했습니다. 우리는 사용자에게 스마트 계약에 업그레이드 가능성 메커니즘이 있는 Rollup과 크로스체인 브리지를 알리고, 각 경우에 대한 업그레이드 관리의 정확한 메커니즘을 설명했습니다. 이는 이미 상당히 복잡하며, 독립 보안 모델을 사용하면 그 수가 기하급수적으로 증가하여 효과적으로 추적하는 것이 거의 불가능해집니다.
그래서 우리는 독립 보안 모델 자체가 보안 위험이며, 기본적으로 이 모델을 사용할 모든 애플리케이션은 위험으로 간주되어야 한다고 가정합니다. 이는 반증되지 않는 한 그렇습니다.
보안 취약점 증명
우리는 우리의 가설을 메인넷에서 테스트하기로 결정했습니다. LayerZero 프레임워크를 실험 대상으로 선택한 이유는 그것이 독립 보안을 핵심으로 하는 가장 인기 있는 솔루션 중 하나이기 때문입니다. 우리는 안전한 omnichain 토큰을 배포한 후, 악의적으로 토큰을 인출할 수 있도록 보안 구성을 업데이트했습니다. 토큰의 코드베이스는 LayerZero에서 제공하는 예제를 기반으로 하며, 실제 배포된 많은 다른 omnichain 토큰 및 애플리케이션과 매우 유사하거나 동일합니다.
하지만 세부 사항에 들어가기 전에, LayerZero의 보안 모델이 어떤 것인지 간략히 살펴보겠습니다.
LayerZero는 백서에서 "신뢰할 필요 없는 체인 간 통신"이 두 개의 독립적인 참여자(오라클과 중계자)가 공동으로 행동하여 프로토콜의 보안을 보장하는 것에 의존한다고 명시하고 있습니다.
LayerZero는 웹사이트에서 그 핵심 개념이 "ULN(UltraLightNode) 및 구성 가능한 체인 상 단말의 사용자 애플리케이션을 실행하는 것"이라고 설명합니다. LayerZero의 체인 상 구성 요소는 두 개의 외부 체인 하 구성 요소가 체인 간 메시지를 중계하는 데 의존합니다. 즉, 오라클과 중계자입니다.
어떤 메시지 M이 A 체인에서 B 체인으로 전송될 때마다 다음 두 가지 작업이 수행됩니다:
- 첫째, 오라클은 A 체인에서 메시지 M을 전송하는 거래가 완료될 때까지 기다린 후, B 체인에 관련 정보를 기록합니다. 예를 들어, A 체인이 메시지 M을 포함하는 블록 헤더의 해시 값을 기록합니다(다른 체인/오라클 간의 정확한 형식은 다를 수 있습니다).
- 그런 다음 중계자는 B 체인에 "증명"(예: Merkle Proof)을 전송하여 저장된 블록 헤더가 메시지 M을 포함하고 있음을 증명합니다.
LayerZero는 중계자와 오라클이 독립적이고 정직한 참여자라고 가정합니다. 그러나 LayerZero는 백서에서 이 가정이 충족되지 않을 경우, 예를 들어 중계자와 오라클이 공모하여 "오라클이 제공한 블록 헤더와 중계자가 제공한 거래 증명이 모두 무효하지만 여전히 일치하는 경우"를 언급합니다.
LayerZero는 "LayerZero의 설계는 공모의 가능성을 제거합니다"라고 주장합니다. 그러나 사실 이 주장은 부정확합니다(우리가 아래에서 보여줄 실험으로 입증할 것입니다). 왜냐하면 각 사용자 애플리케이션이 자신의 중계자와 오라클을 정의할 수 있기 때문입니다. LayerZero는 이러한 구성 요소가 독립적이고 공모할 수 없도록 보장하지 않으며, 이러한 보장은 사용자 애플리케이션이 제공합니다. 만약 애플리케이션이 이를 파괴하기로 선택한다면, LayerZero는 이를 막을 수 있는 메커니즘이 없습니다.
또한 기본적으로 모든 사용자 애플리케이션은 언제든지 중계자와 오라클을 변경할 수 있으므로 보안 가정을 완전히 재정의할 수 있습니다. 따라서 주어진 애플리케이션의 보안을 한 번만 검사하는 것으로는 충분하지 않습니다. 왜냐하면 검사 후 언제든지 변경될 수 있기 때문입니다. 이는 우리가 실험에서 보여줄 것입니다.
실험 설계
우리의 실험에서 우리는 간단한 omnichain 토큰 CarpetMoon을 생성하기로 결정했습니다. 이 토큰은 이더리움과 Optimism에서 실행되며, LayerZero를 사용하여 두 체인 간에 통신합니다.
우리의 토큰은 처음에 LayerZero에서 제공하는 기본 보안 모델을 사용하여 배포되었으며, 이는 현재 배포된 LayerZero 애플리케이션과 완전히 동일합니다. 따라서 일반적으로 LayerZero를 사용하는 다른 모든 토큰과 마찬가지로 안전합니다.
먼저, 우리는 이더리움과 Optimism에 우리의 토큰 계약을 배포했습니다:
https://ethtx.info/mainnet/0xf4d1cdabb6927c363bb30e7e65febad8b9c0f6f76f1984cd74c7f364e3ab7ca9/
그런 다음 우리는 LayerZero가 두 체인에서 어떤 계약이 어떤 계약에 해당하는지 알 수 있도록 라우팅을 설정했습니다.
https://ethtx.info/mainnet/0x19d78abb03179969d6404a7bd503148b4ac14d711f503752495339c96a7776e9/
토큰이 배포되었으며, LayerZero를 사용하는 모든 다른 omnichain 토큰과 완전히 동일하게 보이며, 기본 구성으로 의심스러운 점이 없습니다.
우리는 우리의 "테스트 사용자"인 Alice에게 이더리움에서 10억 개의 CarpetMoon 토큰을 제공했습니다.
https://ethtx.info/mainnet/0x7e2faa8426dacae92830efbf356ca2da760833eca28e652ff9261fc03042b313/
이제 Alice는 LayerZero를 사용하여 이 토큰을 Optimism으로 크로스체인합니다.
우리는 이더리움의 에스크로 계약에 토큰을 잠급니다:
https://ethtx.info/mainnet/0xe4dc3757b86bfda8e7baddc088fb1a599e083ed77034c29e5dd8bd11f1e17771/。
거래가 포함된 메시지가 LayerZero를 통해 Optimism으로 전달되고 있습니다:
크로스체인된 토큰이 Optimism에서 발행되고 있으며, 이제 Alice는 Optimism에서 10억 개의 MoonCarpet 토큰을 보유하고 있습니다:
모든 것이 예상대로 진행되었고, Alice는 이더리움의 에스크로 계약에서 10억 개의 MoonCarpet 토큰이 있으며, Optimism의 계좌에도 10억 개의 MoonCarpet 토큰이 있다는 것을 확인했습니다. 그러나 모든 것이 정상인지 확인하기 위해 그녀는 절반의 토큰을 이더리움으로 다시 전송합니다.
우리는 Optimism에서 5억 개의 토큰을 소각하는 거래를 시작합니다:
해당 거래 정보가 이더리움으로 전달됩니다:
예상대로 5억 개의 MoonCarpet 토큰이 에스크로 계약에서 Alice의 주소로 반환됩니다:
https://etherscan.io/tx/0x27702e07a65a9c6a7d1917222799ddb13bb3d05159d33bbeff2ca1ed414f6a18。
지금까지 모든 것이 정상이며, 가정과 완전히 일치합니다. Alice는 이더리움에서 Optimism으로 토큰을 크로스체인하고 다시 크로스체인할 수 있다는 것을 확인했으며, 그녀의 MoonCarpet 토큰에 대해 걱정할 이유가 없습니다.
하지만 가정 자체에 문제가 있습니다. 예를 들어, 우리 토큰 뒤에 있는 팀이 문제에 직면하고, 나쁜 사람 Bob이 우리 애플리케이션의 LayerZero 구성에 대한 접근 권한을 얻었다고 가정해 보겠습니다.
이렇게 되면 Bob은 오라클과 중계자를 기본 구성 요소에서 그가 제어하는 구성 요소로 변경할 수 있습니다.
이것은 LayerZero를 사용하는 모든 애플리케이션에 제공되는 메커니즘으로, LayerZero의 아키텍처에 뿌리를 두고 있으며, 어떤 종류의 백도어가 아니라 표준 메커니즘입니다.
따라서 Bob은 오라클을 그가 제어하는 EOA로 변경합니다:
https://ethtx.info/mainnet/0x4dc84726da6ca7d750eef3d33710b5f63bf73cbe03746f88dd8375c3f4672f2f/。
중계자도 마찬가지로 변경됩니다:
https://ethtx.info/mainnet/0xc1d7ba5032af2817e95ee943018393622bf54eb87e6ff414136f5f7c48c6d19a/。
이제 이상한 일이 발생합니다. 오라클과 중계자가 이제 Bob의 완전한 통제 하에 있기 때문에, 그는 Alice의 토큰을 훔칠 수 있습니다. Optimism에서 아무런 조치를 취하지 않더라도(MoonCarpet 토큰은 여전히 Alice의 지갑에 있습니다), Bob은 LayerZero 메커니즘을 사용하여 이더리움의 MoonCarpet 스마트 계약을 설득하여 다른 체인에서 토큰을 소각했다고 주장하고 이더리움에서 MoonCarpet 토큰을 인출할 수 있습니다.
우선, 그는 그가 제어하는 오라클을 사용하여 이더리움의 블록 해시를 업데이트합니다:
https://ethtx.info/0xde2edee2cc7f070120e96c9df90d86696970befcfc221e18c6ac4168bb5b1d92/。
이제 그는 에스크로 계약에서 남은 토큰을 인출할 수 있습니다:
https://ethtx.info/0xda695f374b375d5372efeca37aae4c5a17f114d5a76db1e86edebb0924bcdcc7/。
실험 결과
Alice는 왜 그리고 언제 오류가 발생했는지조차 모릅니다. 갑자기 그녀의 Optimism에서의 MoonCarpet 토큰은 더 이상 이더리움의 토큰에 의해 지원되지 않습니다.
스마트 계약은 업그레이드할 수 없으며 예상대로 작동합니다. 유일한 의심스러운 활동은 오라클과 중계자의 변화이지만, 이는 LayerZero에 내장된 일반적인 메커니즘이므로 Alice는 이 변화가 의도된 것인지조차 알지 못합니다. 설령 Alice가 이 변화를 알게 되더라도 이미 너무 늦었습니다. 공격자는 그녀가 반응하기 전에 자금을 고갈시킬 수 있습니다.
LayerZero도 무력합니다. 이들은 그들의 메커니즘의 유효한 실행이며, 그들은 이를 통제할 수 없습니다. 이론적으로 애플리케이션 자체가 자신이 오라클과 중계자를 변경하지 못하도록 막을 수 있지만, 우리가 아는 한 이미 배포된 애플리케이션은 그렇게 하지 않았습니다.
우리는 이 실험을 통해 누군가가 이를 주목할지 테스트했지만, 우리가 예상한 대로 아무도 주목하지 않았습니다. LayerZero를 사용하여 구축된 모든 애플리케이션을 효과적으로 모니터링하여 보안 정책이 변경되었는지 확인하고, 이러한 경우 사용자에게 경고하는 것은 거의 불가능합니다.
설령 누군가가 오라클과 중계자가 변경되어 보안 위험이 발생했음을 제때 발견할 수 있다 하더라도, 이미 늦었습니다. 새로운 오라클과 중계자는 이제 전달할 메시지를 자유롭게 선택하거나 체인 간 통신을 간단히 비활성화할 수 있으며, 사용자는 일반적으로 이에 대해 무력합니다. 우리의 실험은 Alice가 애플리케이션 구성의 변화를 주목하더라도 그녀의 크로스체인 토큰으로 할 수 있는 일이 많지 않다는 것을 명확히 보여줍니다. 새로운 오라클과 중계자는 더 이상 원래의 통신 체인에서 메시지를 수신하지 않으므로 이더리움으로 메시지를 반환하지 않습니다.
결론
우리가 본 바와 같이, 우리의 토큰이 LayerZero를 사용하여 구축되고 예상대로 그 메커니즘을 사용하더라도, 우리는 토큰의 에스크로에서 자금을 훔칠 수 있었습니다. 물론 이는 애플리케이션(우리의 경우 CarpetMoon 토큰)의 잘못이지 LayerZero 자체의 잘못이 아니지만, 이는 LayerZero가 아무런 보안 보장을 제공하지 않음을 증명합니다.
LayerZero가 오라클과 중계자에 대한 보안 모델을 설명할 때, 그들은 애플리케이션 소유자(또는 개인 키를 가진 사람)가 비합리적인 행동을 하지 않을 것이라고 가정합니다. 그러나 대립적인 환경에서는 이 가정이 부정확합니다. 또한 이는 사용자에게 애플리케이션 개발자를 신뢰할 수 있는 제3자로 간주하도록 요구합니다.
따라서 실제로는 LayerZero를 사용하여 구축된 애플리케이션의 보안성에 대해 어떤 가정을 할 수 없습니다. 각 애플리케이션은 위험으로 간주되어야 하며, 그렇지 않다는 것이 입증될 때까지는 그렇습니다.
실제로 이 모든 이야기는 우리가 L2BEAT 웹사이트에 모든 omnichain 토큰을 포함할 계획에서 시작되었습니다. 우리는 이들의 위험을 평가하는 방법을 알아내는 데 어려움을 겪었습니다. 위험을 분석하는 과정에서 우리는 실험의 아이디어를 제안했습니다.
L2BEAT에 배포된다면, 결과적으로 우리는 LayerZero를 사용하여 구축된 각 애플리케이션 위에 경고를 배치해야 하며, 잠재적인 보안 위험이 있을 수 있음을 경고해야 합니다. 그러나 우리는 보안 모델에 대해 더 광범위한 논의를 하고 싶습니다. 왜냐하면 우리는 독립 보안이 피해야 할 패턴이라고 생각하기 때문입니다. 특히 우리의 분야에서는 더욱 그렇습니다.
우리는 LayerZero와 같은 독립 보안 모델이 점점 더 인기를 얻음에 따라, 이러한 모델을 남용하여 대규모 파괴를 초래하고 전체 산업의 불확실성을 증가시킬 프로젝트가 늘어날 것이라고 믿습니다.
