LavaMoat과 Ledger 소프트웨어 공급망 공격

무슨 일이 있었나요?

12월 14일, Ledger의 소프트웨어 라이브러리 중 하나인 Ledger Connect Kit이 소프트웨어 공급망 공격의 대상이 되었습니다.

이번 침해는 여전히 게시 권한을 보유하고 있던 전직 직원이 피싱 공격의 피해자가 되면서 시작된 것으로 알려져 있습니다. 이 공격으로 해당 직원의 npm 자격 증명이 탈취되었습니다. npm(Node Package Manager)은 오픈 소스 소프트웨어 라이브러리를 가져오는 데 사용되는 도구로, 웹 개발 업계와 web3 전반에서 널리 활용되고 있습니다.

이 공격을 통해 문제의 라이브러리의 악성 버전이 게시될 수 있었습니다. 해당 라이브러리는 이더리움 생태계의 많은 웹 앱에서 CDN(콘텐츠 전송 네트워크)을 통해 실시간 업데이트 방식으로 포함되어 있었습니다. 그 결과 악성 코드가 해당 웹 앱에 주입되었습니다.

이를 어떻게 방지할 수 있을까요? LavaMoat.

LavaMoat 은 웹 애플리케이션 개발자가 직면하는 소프트웨어 공급망 보안 문제를 해결하기 위해 특별히 제작된 도구 모음입니다.

LavaMoat은 소프트웨어 개발 수명 주기의 세 가지 시점에서 공급망 공격에 대한 보호를 제공합니다: 의존성 설치 시점(모든 라이브러리를 가져올 때), 빌드 시점(앱이 인터넷을 통해 제공될 준비를 할 때), 그리고 런타임 시점(빌드된 애플리케이션이 실행될 때).

LavaMoat은 런타임 보호 기능에서 독보적입니다. 개발 중에 사용할 수 있는 다른 도구들도 있습니다. 예를 들어 snyk.io는 알려진 취약점에 대한 경고만 제공하며, socket.dev는 보다 포괄적인 코드 분석을 제공하고 전문가가 중앙 데이터베이스에 결과를 보고할 때까지 기다리지 않습니다. 이러한 스캐닝 도구들은 매우 중요한 역할을 수행하며, socket.dev의 GitHub 통합 기능을 사용하실 것을 권장합니다.

그러나 이러한 도구들은 런타임 보장을 제공할 수 없습니다. 이러한 이유로, 이 도구들만 단독으로 사용하는 것은 충분하지 않다고 판단합니다.

LavaMoat의 보안 보호 기능은 지정된 권한만을 애플리케이션의 의존성에 위임하는 방식에서 비롯됩니다.

이것이 무슨 의미일까요? 계속 읽어보시고, LavaMoat의 작동 방식과 사용법에 대한 더 깊은 이해를 위해 Devcon 6 강연도 확인해 보세요.

객체 권한 모델 입문

시스템에는 권한(capabilities) 이 있다고 생각할 수 있습니다. 권한이란 정보 표시, 로컬에 저장된 데이터 읽기, 서버에 대한 웹 요청이나 지갑에 대한 트랜잭션 요청과 같이 다른 시스템에 요청을 보내는 것처럼 시스템이 수행할 수 있는 작업을 의미하며, 이러한 권한을 다른 주체에게 위임할 수 있는 능력도 포함됩니다.

권한을 위임할 때, 제한되거나 축소된 버전의 권한을 제공할 수 있습니다. 이를 감쇠(attenuation) 라고 합니다.

이 세 가지 구성 요소가 객체 권한 보안 모델의 기반을 형성합니다. 이 모델을 사용하면 누가 무엇을 할 수 있는지 파악할 수 있습니다.

웹 애플리케이션 보안

브라우저는 애플리케이션을 샌드박싱하는 데 어느 정도 효과적입니다. 즉, 애플리케이션을 서로 분리하고 컴퓨터나 다른 웹사이트에 간섭하는 것을 방지합니다.

그러나 브라우저는 웹 앱 개발자가 앱의 특정 부분을 추가로 샌드박싱할 수 있는 견고한 빌딩 블록을 제공하지 않습니다. 이러한 샌드박싱이 가능하다면 앱의 특정 구성 요소가 전체 애플리케이션을 침해하는 것을 방지할 수 있을 것입니다.

이러한 이유로, 라이브러리를 애플리케이션에 가져올 때 사실상 해당 라이브러리에 모든 권한을 위임하게 됩니다. 이는 대부분의 JavaScript 라이브러리가 자체 코드만 가져오는 것이 아니라 다양한 작성자가 작성한 라이브러리 모음을 함께 가져온다는 사실로 인해 더욱 복잡해집니다.

Ledger 공격의 구체적인 내용

@ledger/connect-kit-loader 라이브러리는 Ledger 제품과 통합하기 위한 Ledger의 권장 방법입니다. 이 패키지는 CDN에서 라이브러리의 최신 버전을 로드하는 얇은 래퍼입니다.

이는 앱이 항상 최신 버전의 라이브러리를 갖게 된다는 것을 의미하지만, 동시에 사실상 웹 앱의 제어권을 Ledger 로더 라이브러리에 위임하게 되며, 이 라이브러리는 다시 CDN에 호스팅된 코드에 제어권을 위임한다는 것을 의미합니다.

위임 체인은 다음과 같이 모델링할 수 있습니다:

Web App → **@ledger/connect-kit-loader** → jsDelivr CDN → npm → Ledger → Ledger 전직 직원 → 공격자

이것도 단순화된 것입니다. jsDeliver CDN과 같은 하나의 구성 요소를 자세히 살펴보면, 공급망의 일부이자 공격 발판이 될 수 있는 추가 서비스들의 놀라운 복잡성이 드러납니다.

객체 권한 보안으로 애플리케이션 보호하기

앞서 언급했듯이 브라우저 자체는 애플리케이션의 하위 구성 요소의 권한을 제한하는 도구를 많이 제공하지 않지만, JavaScript 언어는 실제로 이 작업에 매우 적합합니다.

JavaScript는 신중한 노력을 기울이면 코드가 접근할 수 있는 것을 제한하는 Compartment를 구축할 수 있게 해줍니다. Compartment 구현에 대해서는 Agoric의 Hardened Javascript 프로젝트를 참고하세요.

MetaMask의 LavaMoat 공급망 보안 시스템과 MetaMask Snaps 플러그인 시스템은 모두 격리(confinement)를 달성하기 위해 Compartment를 기반으로 구축되었습니다.

LavaMoat이 Ledger 공급망 공격을 방지할 수 있었을까요?

LavaMoat이 이를 방지할 수 있었는지 묻는 것은, 마치 절벽에서 뛰어내리면서 톱을 잡고 있을 때 테이블 톱의 접촉 감지 정지 기능이 도움이 되었을지 묻는 것과 비슷합니다. 네, 뛰어내린 후에도 손가락이 손에 붙어 있을 가능성이 높습니다.

원칙적으로, @ledgerhq/connect-kit-loader의 작동 방식은 앱 개발자가 확립된 많은 보안 모범 사례를 포기하도록 강요합니다. 그러나 모든 희망이 사라진 것은 아닙니다.

LavaMoat(및 기타 공급망 보안 도구)의 도움을 최대한 활용하는 가장 좋은 방법은 로더에 모든 제어권을 넘기지 않고 @ledgerhq/connect-kit을 직접 사용하는 것입니다.

LavaMoat은 "event-stream 사건"으로도 알려진 Copay 지갑 해킹과 같은 공격을 완화하도록 설계되었으며, 이에 대해 효과적으로 보호합니다. 그렇다면 LavaMoat은 이번과 같은 다른 유형의 공격에는 어떻게 대응할까요?

안타깝게도 답은 오래된 격언처럼 "상황에 따라 다릅니다"입니다. LavaMoat은 앱 런타임에 통합되는 방식으로 인해 라이브러리 개발자가 아닌 애플리케이션 개발자를 위한 도구입니다. 이는 일부 웹 앱은 LavaMoat으로 스스로를 보호할 수 있었지만, LavaMoat이 없는 애플리케이션은 여전히 취약했을 것임을 의미합니다.

또한 LavaMoat은 개발자가 지정한 정책만 적용합니다. 안전하지 않은 정책을 지정하면 LavaMoat이 보호해 드릴 수 없습니다.

LavaMoat을 사용하는 애플리케이션이 이 공격으로부터 어떻게 보호될 수 있었는지 살펴보겠습니다.

LavaMoat은 정책 파일을 사용하여 의존성이 전역 플랫폼 API 형태로 어떤 권한을 가져야 하는지 결정합니다. 이를 더 쉽게 하기 위해 LavaMoat이 패키지를 분석하고 패키지가 작동하는 데 필요한 것이 무엇인지 자동으로 결정하도록 할 수 있습니다. 이를 정적 분석(static analysis) 이라고 합니다.

정적 분석은 코드가 무엇을 하려는지 이해하는 데 완벽한 수단은 아니지만, LavaMoat은 정책 파일 생성을 돕기 위한 편의 목적으로만 정적 분석을 사용합니다. 런타임에 정책을 적용하는 데는 정적 분석을 사용하지 않습니다. 생성된 정책은 이후 개발자가 검토, 조정, 승인합니다.

원래 질문에 대한 한 가지 답은: 네, LavaMoat은 런타임에 새 코드를 로드하는 패키지의 권한을 차단함으로써 공급망 공격으로부터 앱과 사용자를 보호할 수 있습니다. 올바르게 구성하고 지나치게 강력한 권한을 요구하지 않는 의존성을 사용했다면 보호받을 수 있습니다.

또 다른 답은: 아니요. @ledgerhq/connect-kit-loader가 정상적으로 작동하고 스크립트 태그를 주입하여 LavaMoat 런타임 외부에서 원하는 코드를 실행할 수 있도록 LavaMoat을 구성했다면, 공격은 여전히 성공했을 것입니다. 이는 LavaMoat이 하위 호환성과 더 안전한 시스템 사이에서 타협한 부분입니다. LavaMoat은 최대한의 호환성을 위해 매우 유연하게 설계되어 있어, 앱을 처음부터 다시 작성하지 않고도 적용할 수 있습니다. 합리적인 정책을 설정하고 합리적인 의존성을 선택하는 책임은 여전히 앱 개발자에게 있습니다. LavaMoat을 사용하면 전역 브라우저 API를 선택적으로 제공할 수 있지만, 일부 전역 API는 서드파티 패키지에 안전하게 제공하기에는 너무 강력한 권한을 포함하고 있습니다. 이러한 권한을 더욱 제한하는 여러 방법을 연구 중이지만, 제어를 제한하려는 노력을 전혀 하지 않는 패키지에서도 그냥 작동하는 것을 만드는 것은 쉽지 않습니다.

Scuttling이라고 불리는 LavaMoat의 기능 중 하나는 @ledgerhq/connect-kit-loader가 로드한 악성 패키지와 원본 패키지 모두에 영향을 미칩니다. Scuttling은 LavaMoat 샌드박스 외부에서 실행되는 코드의 권한 접근을 제거합니다. 이를 통해 처음부터 안전하지 않은 @ledgerhq/connect-kit-loader를 사용하지 못하게 하고, @ledgerhq/connect-kit 업데이트 프로세스를 직접 사용하고 소유하도록 유도하여 앱에서 실행되는 코드에 대한 완전한 제어권을 유지할 수 있습니다.

LavaMoat은 만능 해결책이 아니지만, 그렇지 않으면 전혀 가질 수 없었던 제어권과 가시성을 제공합니다. LavaMoat은 보안 전략에서 하나의 도구로만 활용되어야 합니다.

지금 당장 내일의 공격에 대비하기 위해 할 수 있는 일:

• 무료 Socket.dev 의존성 모니터를 추가하세요 (2분).

• 리소스를 엄격하게 제어하는 CSP를 추가하세요 (30분).

• 빌드 시스템과 앱 번들에 LavaMoat을 추가하세요 (1시간).