매스 어답션의 걸림돌: Web3 보안과 개인 책임의 한계

1. 배경 - 계속되는 Web3 보안 취약 사태 (feat. Approve된 자산들)

2024년 7월 16일, 디파이 플랫폼 중 하나인 LIFI 프로토콜이 해킹 공격을 받아 약 1,160만 달러 규모의 자금이 유출된 사건이 발생했다. LIFI 프로토콜은 다양한 블록체인 네트워크 간 상호 운용성을 높이기 위한 플랫폼으로 주로 크로스체인 브리지와 관련된 기능을 제공하며, 여러 블록체인 간의 자산 전송과 스왑을 쉽게 할 수 있게 해주는 것으로 알려져 있다.

이번 사건은 2022년에 발생한 60만 달러 규모의 해킹 사건과 기본적으로 동일한 이유로 발생한 것으로 나타나고 있다. 이 해킹으로 인해 직접적으로 타격을 받은 피해자들은 브리지 기능과 스왑 기능을 활용하기 위해 특정 토큰들에 대해 무한정 수량만큼의 Approve 작업을 거쳤던 사용자들이었다.

Approve란, 토큰 소유자가 다른 사용자 또는 스마트 컨트랙트에게 일정 수량의 토큰을 대신 사용할 수 있도록 권한을 부여하는 기능으로 소유자가 직접 토큰을 전송하지 않고도 권한을 부여 받은 주체가 대신 특정한 양의 토큰을 전송하거나 사용할 수 있게 해준다. 이 기능은 여러 디파이 서비스들에서 널리 사용되고 있다.

물론, 7월 18일 기준으로 공격의 목표가 됐던 취약점이 해결되었고 LIFI 측은 도난당한 자금을 추적하기 위해 관련된 법 집행 기관과 긴밀히 협력하고 있다고 밝혔다. 또한, LIFI 프로토콜도 정상적으로 운영되고 있다.

Source: Thefts From Crypto Hacks and Exploits Surge in First Half of 2024

그러나 위 사례와 같은 스마트 컨트랙트 취약점을 이용한 해킹 시도나 피싱 공격으로 인한 해킹 시도로 인해 발생한 피해액은 약 14억 달러에 육박하고 있다는 보고서도 존재하는 것처럼 Web3의 보안 위기는 Web3 산업이 점점 성장하는데에 큰 걸림돌이 되고 있다.

2. 시사점 - 보안 걱정을 떨쳐내고 매스 어답션으로 가는 길

Source: OpenZeppelin ERC20.sol

배경에서 다룬 해킹 사례의 중심 주제인 Approve 기능은 권한을 위임하는 것인만큼 매우 다양한 위험에 노출되어 있다. 그 중 몇몇 경우를 살펴보면 아래와 같다:

피싱 공격*:* 공격자는 사용자를 속여 악의적인 스마트 컨트랙트에 대해 Approve를 호출하도록 유도하면, 사용자는 자신이 안전하다고 생각하고 토큰을 승인한다. 그러나 실제로는 공격자가 이를 사용하여 사용자의 모든 토큰을 훔칠 수 있는 가능성이 생긴다.
악의적인 업그레이드*:* 스마트 컨트랙트 업그레이드 권한을 가진 개발자나 관리자, 혹은 해커가 기존 컨트랙트를 악의적으로 업그레이드하여 승인된 토큰을 도용하는 방식으로 새로운 버전의 스마트 컨트랙트에서 토큰을 전송하는 함수가 사용자로부터 승인된 토큰을 임의로 다른 주소로 전송하도록 변경될 수 있다.
업그레이드 중 상태 불일치: 스마트 컨트랙트를 업그레이드하는 동안 상태 불일치가 발생하여 Approve된 토큰 정보가 올바르게 이전되지 않거나, 새로운 컨트랙트에서 부정확하게 처리될 수 있다. 예를 들어, 새로운 컨트랙트가 기존 컨트랙트의 권한 목록을 잘못 적용하거나, 권한 목록 데이터 이전 과정에서 일부 권한 정보가 손실될 수 있다.

LIFI의 경우, 위의 경우와 완전히 일치하지는 않지만 서비스 내에서 무한정 수량만큼 사용자로부터 권한을 부여받은 상태의 토큰이 스마트 컨트랙트의 취약점을 통해 탈취가 된 경우이다.

그러나 본질적인 문제점은 따로 있다. 현재 존재하는 많은 디앱들이나 디파이 서비스들을 사용하려면 토큰에 대한 권한 위임은 거의 필수적이다. 그 말인 즉슨, 서비스들을 사용하는 사용자가 권한을 부여하고 서비스 플랫폼은 권한 위임을 유도만 하는 것이기에 사실상 관리 부실의 책임은 사용자에게 전가된다.

Source: Rabby Wallet Approvals

물론, 부여했던 권한을 다시 되찾아오는 Revoke 기능도 스마트 컨트랙트 내에 함께 있기 때문에 관리만 잘 이루어진다면 보안상으론 큰 문제가 되지 않는다는 것이 정설이지만 스마트 컨트랙트 기능에 대해 깊숙이 이해하고 있는 사용자가 아닌 이상, 토큰의 권한 설정을 제대로 관리하는 사용자는 없을 것이라고 판단된다. 결국, 간단하게 브리지나 스왑 서비스를 사용하는 사용자가 대부분인 DEX 생태계에서 보안상으로 큰 구멍이 뚫릴 가능성이 언제나 열려 있다는 것이다.

이러한 잠재적 보안 리스크는 크립토 및 블록체인 산업계로 많은 사용자들이 진입할 때 매우 큰 장벽이 될 가능성이 높다. 특히, 우리들만을 위한 잔치에서 벗어나기 위해서는 블록체인 서비스들을 가볍게 사용하는 사용자들이 많아져야 하는데, 이러한 사용자들은 보안적인 리스크와 이 리스크에 대한 책임을 본인들이 짊어지는 행태를 극도로 회피하는 경향을 가진다.

즉, 우리가 매스 어답션으로 가기 위해서는 잠재적 보안 리스크를 해결해야 하고 사용자들을 보안 책임으로부터 점점 멀어지게 해야한다. 그 방법은 크게 두 가지로 나뉘어져 동시에 수행되어야 한다고 필자는 생각한다.

먼저, 디앱 서비스 주체들은 스마트 컨트랙트에 보안상 취약점은 없는지 수시로 확인하며 운영해야 한다. 당연히 코드로 이루어진 보안적으로 완벽한 스마트 컨트랙트는 지금도 미래에도 없겠지만, 적어도 보안 취약점이 있는데 아무 조치도 취하지 않는 것보단 훨씬 나을 것이다. 또한, 이러한 운영이 외부적 관점으로 안전하고 깨끗한 디앱 서비스로 알려지면 서비스 주체 측도 나쁠 것이 하나 없기 때문에 이 부분을 중요하게 여겨야 한다.

또 하나는, 사용자들에게 지어져 있는 보안 책임을 나눌 수 있는 서드 파티의 발전이다. 위의 사례에 대입하여 생각하면 Approve로 인해 권한이 위임된 자산은 사용자가 Revoke를 통해 직접 권한 회수를 할 수 있다. 그러나 이 방법이 라이트한 사용자 입장에서는 복잡하고 번거로워서 쉽게 할 수 없다는 큰 단점이 있다. 이때, Revoke.cash와 같은 권한 회수를 도와주는 서비스의 등장을 통해 사용자의 보안 책임을 소분할 수 있게 된다. 이러한 사례 말고도 사용자들이 쉽게 기술적으로 다가가지 못하는 보안적 부분의 해결을 도와주는 서비스들이 많이 생기게 된다면, 훨씬 안전하고 쾌적한 Web3 환경이 될 것이다.

Web3 산업은 계속해서 발전하고 있지만, 매스 어답션을 바라는 입장에서 아직은 라이트한 사용자들을 받아들이기에 내실이 부족하다고 느낀다. 특히, 매스 어답션이 이루어지려면 여러 환경들이 마련되어야 하지만 사용자들 입장에서 가장 크게 다가오는 보안적인 측면이 해결된다면 이 업계가 우물 안 개구리를 벗어나 진정한 금융 탈중앙화를 이룰 수 있을 것으로 믿어 의심치 않는다.

3. 다른 사람의 의견

3.1 ChainLight의 C4lvin - “디앱은 여러 보안 회사로부터 감사를 받아야 한다.”

블록체인 업계에서 완벽한 스마트 컨트랙트 감사는 없다고 하지만, 트랜잭션 내의 데이터 검증 부족으로 발생한 LiFi 류의 사고는 정상적으로 스마트 컨트랙트 감사를 받았다면 절대 발생해서는 안되는 취약점이다. 그래서 이러한 사고가 발생했던 프로젝트들을 살펴보면 해당 스마트 컨트랙트의 감사를 받지 않은 경우가 대부분이었다. 필자가 이런 취약점으로 인해 발생하는 사고를 예방하기 위해 필요하다고 생각하는 점은 감사의 범주에서 빠지는 스마트 컨트랙트가 없도록 프로젝트를 유지하는 것과 다양한 감사 기관에서 스마트 컨트랙트 감사를 받는 것이다.

Revoke.Cash와 같은 서비스가 피해를 일부 막을 수 있긴 하겠지만, 라자루스(북한의 해킹 그룹) 등에 의해 발생하는 대형 사고는 공격 자체가 대중에게 알려지기도 전에 이미 자산이 탈취되는 경우가 대부분이다. 때문에 사용자가 위임된 권한을 되찾을 새도 없이 권한이 위임된 자산이 모두 탈취되는 경우가 많다. 결국은 사용자가 모든 자산에 대해 권한 위임을 하지 않도록 유도하는 것이 중요한데, 라이트 사용자 입장에서는 지갑이나 서비스 차원에서 이에 대해 보다 강력하게 경고하는게 효과적이라고 생각된다.

또한 본 글에서 Approve가 주요 이슈로 다뤄지는 것 같은데, 필자는 이런 류의 해킹 사고의 책임 소재에는 Approve 함수가 해당되지 않는다고 생각한다. 사용자에게 자신의 보안 수준을 결정하도록 하는 것은 오히려 바람직한 방향이라고 생각하기 때문이다. 주요한 책임 소재는 엄청나게 많은 사례가 존재하여 미리 막을 수 있던 원데이 취약점에 대해 미리 대비하지 못한 감사자와 프로젝트 책임자들에게 있지 않나 생각한다. 오히려 웹3 개발자들에게 원데이 취약점 학습의 중요점을 강조해주는 편이 좋지 않을까 싶다. 특히, 요즘에는 취약점 학습과 관련된 플랫폼들도 존재하기 때문에 많은 도움을 받을 수 있다. (예시: Phalcon Blocksec Explorer, Lumos Chainlight, De.Fi Rekt Database)

4. 참고 자료

관련 기사, 뉴스, 트윗 등 :