CertiK: Sui 최신 취약점 "햄스터 휠", 기술 세부 사항 및 심층 분석

저자: CertiK

이전 CertiK 팀은 Sui 블록체인에서 일련의 서비스 거부 취약점을 발견했습니다. 이 취약점 중 하나는 새롭고 심각한 영향을 미치는 취약점으로 특히 주목받고 있습니다. 이 취약점은 Sui 네트워크 노드가 새로운 거래를 처리하지 못하게 하여 전체 네트워크가 완전히 중단된 것과 같은 효과를 가져옵니다.

지난 주 월요일, CertiK는 이 중대한 보안 취약점을 발견하여 SUI로부터 50만 달러의 버그 바운티를 받았습니다. 미국의 권위 있는 미디어 CoinDesk는 이 사건을 보도했으며, 이후 여러 주요 매체들도 관련 뉴스를 잇따라 보도했습니다.

이 보안 취약점은 "햄스터 휠"이라는 비유적인 이름으로 불립니다: 그 독특한 공격 방식은 현재 알려진 공격과 다르며, 공격자는 약 100바이트의 페이로드만 제출하면 Sui 검증 노드에서 무한 루프를 유발하여 새로운 거래에 응답할 수 없게 만듭니다.

또한, 공격으로 인한 피해는 네트워크가 재시작된 후에도 지속될 수 있으며, Sui 네트워크 내에서 자동으로 전파되어 모든 노드가 햄스터가 휠에서 끝없이 달리는 것처럼 새로운 거래를 처리할 수 없게 됩니다. 따라서 우리는 이 독특한 공격 유형을 "햄스터 휠" 공격이라고 부릅니다.

이 취약점을 발견한 후, CertiK는 Sui의 버그 바운티 프로그램을 통해 Sui에 보고했습니다. Sui는 즉시 효과적으로 대응하여 이 취약점의 심각성을 확인하고, 메인넷 시작 전에 문제를 해결하기 위한 조치를 적극적으로 취했습니다. 이 특정 취약점을 수정하는 것 외에도, Sui는 이 취약점이 초래할 수 있는 잠재적 피해를 줄이기 위해 예방적인 완화 조치를 시행했습니다.

CertiK 팀의 책임 있는 공개에 감사하기 위해, Sui는 CertiK 팀에 50만 달러의 보상을 수여했습니다.

아래에서는 기술적인 측면에서 이 주요 취약점의 세부 사항을 공개하고, 이 취약점의 근본 원인과 잠재적 영향을 설명합니다.

취약점 상세 설명

Sui에서 검증자의 핵심 역할

Sui와 Aptos와 같은 Move 언어 기반 블록체인은 악의적인 페이로드 공격을 방지하기 위한 보장 메커니즘으로 주로 정적 검증 기술을 사용합니다. 정적 검증 기술을 통해 Sui는 계약이 배포되거나 업그레이드되기 전에 사용자가 제출한 페이로드의 유효성을 검사할 수 있습니다. 검증자는 구조와 의미의 정확성을 보장하기 위해 일련의 검사기를 제공하며, 검사를 통과한 경우에만 계약이 Move 가상 머신에서 실행됩니다.

Move 체인에서의 악의적인 페이로드 위협

Sui 체인은 원래 Move 가상 머신 위에 새로운 저장 모델과 인터페이스를 제공하므로 Sui는 맞춤형 Move 가상 머신을 가지고 있습니다. 새로운 저장 원시를 지원하기 위해 Sui는 신뢰할 수 없는 페이로드의 안전 검증을 위해 객체 안전 및 전역 저장 접근과 같은 기능을 포함한 일련의 추가 맞춤형 검사 수단을 도입했습니다. 이러한 맞춤형 검사 수단은 Sui의 독특한 기능에 부합하므로 우리는 이러한 맞춤형 검사를 Sui 검증자라고 부릅니다.

Sui의 페이로드 검사 순서

위 그림에서 볼 수 있듯이, 검증자 내의 대부분의 검사는 CompiledModule(사용자가 제공한 계약 페이로드 실행을 나타냄)에 대해 구조적 안전성을 검증합니다. 예를 들어, "중복 검사기"를 통해 런타임 페이로드에 중복 항목이 없도록 보장하고, "제한 검사기"를 통해 런타임 페이로드의 각 필드 길이가 허용된 항목 한도 내에 있는지 확인합니다.

구조적 검사 외에도, 검증자의 정적 검사는 신뢰할 수 없는 페이로드의 의미적 강건성을 보장하기 위해 더 복잡한 분석 수단이 필요합니다.

Move의 추상 해석기 이해하기:

선형 및 반복 분석

Move에서 제공하는 추상 해석기는 바이트코드에서 복잡한 안전 분석을 수행하기 위해 설계된 프레임워크입니다. 이 메커니즘은 검증 과정을 더욱 세밀하고 정확하게 만들어 주며, 각 검증자는 자신만의 독특한 추상 상태를 정의하여 분석을 수행할 수 있습니다.

실행을 시작할 때, 추상 해석기는 컴파일된 모듈에서 제어 흐름 그래프(CFG)를 구축합니다. 이러한 CFG의 각 기본 블록은 "전 상태"와 "후 상태"라는 상태 집합을 유지합니다. "전 상태"는 기본 블록 실행 전의 프로그램 상태 스냅샷을 제공하고, "후 상태"는 기본 블록 실행 후의 프로그램 상태 설명을 제공합니다.

추상 해석기가 제어 흐름 그래프에서 회귀(또는 루프)를 만나지 않으면, 간단한 선형 실행 원칙을 따릅니다: 각 기본 블록이 순차적으로 분석되고 블록 내 각 명령의 의미에 따라 전 상태와 후 상태가 계산됩니다. 그 결과는 프로그램 실행 과정에서 각 기본 블록 수준의 상태에 대한 정확한 스냅샷을 제공하여 프로그램의 안전 속성을 검증하는 데 도움을 줍니다.

Move 추상 해석기의 작업 흐름

그러나 제어 흐름에 루프가 존재할 경우, 이 과정은 더욱 복잡해집니다. 루프의 출현은 제어 흐름 그래프에 회귀 엣지가 포함되어 있음을 의미하며, 회귀 엣지의 출발지는 현재 기본 블록의 후 상태에 해당하고, 회귀 엣지의 목표 기본 블록(루프 헤드)은 이전에 이미 분석된 기본 블록의 전 상태입니다. 따라서 추상 해석기는 회귀와 관련된 두 기본 블록의 상태를 신중하게 병합해야 합니다.

병합 후 상태가 루프 헤드 기본 블록의 기존 전 상태와 다르면, 추상 해석기는 루프 헤드 기본 블록의 상태를 업데이트하고 이 기본 블록에서 분석을 다시 시작합니다. 이 반복 분석 과정은 루프의 전 상태가 안정될 때까지 계속됩니다. 다시 말해, 이 과정은 루프 헤드 기본 블록의 전 상태가 반복 사이에 더 이상 변하지 않을 때까지 계속 반복됩니다. 고정점에 도달하면 루프 분석이 완료되었음을 나타냅니다.

Sui IDLeak 검증기:

맞춤형 추상 해석 분석

원래 Move 설계와 달리, Sui 블록체인 플랫폼은 "목표" 중심의 전역 저장 모델을 도입했습니다. 이 모델의 두드러진 특징 중 하나는 key 속성을 가진 데이터 구조가 반드시 ID 유형을 해당 구조의 첫 번째 필드로 가져야 한다는 것입니다. ID 필드는 변경할 수 없으며 다른 목표로 전이될 수 없습니다. 각 객체는 전역적으로 고유한 ID를 가져야 하기 때문입니다. 이러한 특성을 보장하기 위해 Sui는 추상 해석기 위에 맞춤형 분석 논리를 구축했습니다.

IDLeak 검증기는 idleakverifier라고도 하며, 추상 해석기와 협력하여 분석을 수행합니다. 이 검증기는 AbstractDomain이라는 고유한 구조를 가지고 있으며, 이를 AbstractState라고 부릅니다. 각 AbstractState는 여러 지역 변수에 해당하는 AbstractValue로 구성됩니다. AbstractValue를 통해 각 지역 변수의 상태를 감독하여 ID 변수가 완전히 새로운 것인지 추적합니다.

구조체 패킹 과정에서 IDLeak 검증기는 새로운 ID만 구조체에 패킹하는 것을 허용합니다. 추상 해석 분석을 통해 IDLeak 검증기는 로컬 데이터 흐름 상태를 자세히 추적하여 기존의 ID가 다른 구조체 객체로 전이되지 않도록 보장합니다.

Sui IDLeak 검증기 상태 유지 불일치 문제

IDLeak 검증기는 AbstractState::join 함수를 구현하여 Move 추상 해석기와 통합됩니다. 이 함수는 상태 관리, 특히 상태 값의 병합 및 업데이트에서 필수적인 역할을 합니다.

이 함수의 작동 방식을 이해하기 위해 자세히 살펴보겠습니다:

AbstractState::join에서 이 함수는 다른 AbstractState를 입력으로 받아 현재 객체의 로컬 상태와 병합하려고 시도합니다. 입력 상태의 각 지역 변수에 대해, 해당 변수의 값을 로컬 상태에서 현재 값과 비교합니다(찾을 수 없는 경우 기본값은 AbstractValue::Other입니다). 이 두 값이 다르면 "변경됨" 플래그를 설정하여 최종 상태 병합 결과가 변경되었는지를 나타내고, AbstractValue::join을 호출하여 로컬 상태의 로컬 변수 값을 업데이트합니다.

AbstractValue::join에서 이 함수는 자신의 값을 다른 AbstractValue와 비교합니다. 두 값이 같으면 전달된 값을 반환합니다. 다르면 AbstractValue::Other를 반환합니다.

그러나 이 상태 유지 논리는 숨겨진 불일치 문제를 포함하고 있습니다. AbstractState::join은 새 값과 이전 값의 차이에 따라 병합 상태가 변경되었음을 나타내는 결과(JoinResult::Changed)를 반환하지만, 병합 업데이트된 상태 값은 여전히 변하지 않을 수 있습니다.

이러한 불일치 문제는 작업 순서로 인해 발생합니다: AbstractState::join에서 상태 변경 여부의 판별이 상태 업데이트(AbstractValue::join) 이전에 발생하며, 이 판별은 실제 상태 업데이트 결과를 반영하지 않습니다.

또한, AbstractValue::join에서 AbstractValue::Other는 병합 결과에 결정적인 역할을 합니다. 예를 들어, 이전 값이 AbstractValue::Other이고 새 값이 AbstractValue::Fresh인 경우, 업데이트된 상태 값은 여전히 AbstractValue::Other가 됩니다. 즉, 새 값과 이전 값이 다르더라도 업데이트 후 상태 자체는 변하지 않습니다.

예시: 상태 연결의 불일치

이로 인해 불일치가 발생합니다: 기본 블록 상태의 병합 결과가 "변경됨"으로 판별되지만, 병합된 상태 값 자체는 변하지 않습니다. 추상 해석 분석 과정에서 이러한 불일치 문제가 발생하면 심각한 결과를 초래할 수 있습니다. 우리는 추상 해석기가 제어 흐름 그래프(CFG)에서 루프가 발생할 때의 행동을 되돌아봅니다:

루프를 만나면, 추상 해석기는 반복 분석 방법을 사용하여 회귀 목표 기본 블록과 현재 기본 블록의 상태를 병합합니다. 병합된 상태가 변경되면, 추상 해석기는 점프 목표에서 다시 분석을 시작합니다.

그러나 추상 해석 분석의 병합 작업이 잘못되어 상태 병합 결과를 "변경됨"으로 잘못 표시하고, 실제로 상태 내부 변수의 값이 변하지 않으면, 끝없는 재분석이 발생하여 무한 루프가 발생합니다.

불일치 추가 활용

Sui IDLeak 검증기에서 무한 루프 유발

이러한 불일치성을 이용하여 공격자는 악의적인 제어 흐름 그래프를 구성하여 IDLeak 검증기를 무한 루프에 빠뜨릴 수 있습니다. 이 정교하게 구성된 제어 흐름 그래프는 세 개의 기본 블록으로 구성됩니다: BB1, BB2, BB3. 주목할 점은 BB3에서 BB2로의 회귀 엣지를 의도적으로 도입하여 루프를 구성했다는 것입니다.

악의적인 CFG + 상태는 IDLeak 검증기 내부에서 무한 루프를 초래할 수 있습니다.

이 과정은 BB2에서 시작되며, 특정 지역 변수의 AbstractValue가 ::Other로 설정됩니다. BB2를 실행한 후, 흐름은 BB3로 이동하고, 여기서 동일한 변수가 ::Fresh로 설정됩니다. BB3의 끝에는 BB2로 점프하는 회귀 엣지가 있습니다.

이 예제의 추상 해석 분석 과정에서 앞서 언급한 불일치성이 중요한 역할을 합니다. 회귀 엣지가 처리될 때, 추상 해석기는 BB3의 후 상태(변수는 "::Fresh")와 BB2의 전 상태(변수는 "::Other")를 연결하려고 시도합니다. AbstractState::join 함수는 이 새 값과 이전 값의 차이를 인식하고 "변경됨" 플래그를 설정하여 BB2에 대한 재분석이 필요함을 나타냅니다.

그러나 AbstractValue::join에서 "::Other"의 지배적 행동은 AbstractValue 병합 후 BB2 상태 변수의 실제 값이 여전히 "::Other"임을 의미하며, 상태 병합 결과는 변하지 않습니다.

따라서 이 루프 과정이 시작되면, 검증기가 BB2 및 모든 후속 기본 블록 노드(BB3)를 계속 재분석하게 되어 무한히 지속됩니다. 무한 루프는 모든 사용 가능한 CPU 주기를 소모하여 새로운 거래에 대한 응답을 처리할 수 없게 만들며, 이 상황은 검증기가 재시작된 후에도 여전히 존재합니다.

이 취약점을 이용하여 검증 노드는 햄스터가 휠에서 끝없이 달리는 것처럼 무한 루프에 빠져 새로운 거래를 처리할 수 없습니다. 따라서 우리는 이 독특한 공격 유형을 "햄스터 휠" 공격이라고 부릅니다.

"햄스터 휠" 공격은 Sui 검증기를 효과적으로 정지시켜 전체 Sui 네트워크를 마비시킬 수 있습니다.

취약점의 원인과 유발 과정을 이해한 후, 우리는 다음 Move 바이트코드를 사용하여 구체적인 예제를 시뮬레이션하여 실제 환경에서 이 취약점을 성공적으로 유발했습니다:

이 예제는 정교하게 구성된 바이트코드를 통해 실제 환경에서 취약점을 유발하는 방법을 보여줍니다. 구체적으로, 공격자는 IDLeak 검증기에서 무한 루프를 유발하여 약 100바이트의 페이로드만으로 Sui 노드의 모든 CPU 주기를 소모하고, 새로운 거래 처리를 효과적으로 방해하며 Sui 네트워크의 서비스 거부를 초래할 수 있습니다.

"햄스터 휠" 공격의 Sui 네트워크에서의 지속적인 해악

Sui의 버그 바운티 프로그램은 취약점 등급 평가에 대해 엄격한 규정을 가지고 있으며, 주로 전체 네트워크에 대한 해악 정도에 따라 평가됩니다. "심각한(critical)" 등급을 충족하는 취약점은 전체 네트워크를 중단시키고 새로운 거래 확인을 효과적으로 방해해야 하며, 문제를 수정하기 위해 하드 포크가 필요합니다. 만약 취약점이 일부 네트워크 노드만 서비스 거부를 초래할 수 있다면, 최대 "중간(medium)" 또는 "높음(high)" 등급으로 평가됩니다.

CertiK Skyfall 팀이 발견한 "햄스터 휠" 취약점은 전체 Sui 네트워크를 중단시킬 수 있으며, 공식적으로 새로운 버전을 발표하여 업그레이드 및 수정이 필요합니다. 이 취약점의 해악 정도에 따라 Sui는 최종적으로 이를 "심각" 등급으로 평가했습니다. "햄스터 휠" 공격이 초래하는 심각한 영향의 원인을 더 잘 이해하기 위해, 우리는 Sui 백엔드 시스템의 복잡한 구조, 특히 체인 상의 거래 게시 또는 업그레이드의 전체 과정을 이해할 필요가 있습니다.

Sui에서 거래 제출의 상호 개요

처음에 사용자의 거래는 프론트엔드 RPC를 통해 제출되며, 기본 검증 후 백엔드 서비스로 전달됩니다. Sui 백엔드 서비스는 들어오는 거래 페이로드를 추가로 검증하는 역할을 합니다. 사용자의 서명을 성공적으로 검증한 후, 거래는 거래 증명서(거래 정보 및 Sui의 서명을 포함)로 변환됩니다.

이 거래 증명서는 Sui 네트워크 작동의 기본 구성 요소로, 네트워크 내의 여러 검증 노드 간에 전파될 수 있습니다. 계약 생성/업그레이드 거래의 경우, 블록체인에 올라가기 전에 검증 노드는 Sui 검증기를 호출하여 이러한 증명서의 계약 구조/의미의 유효성을 검사하고 검증합니다. 바로 이 중요한 검증 단계에서 "무한 루프" 취약점이 유발될 수 있습니다.

이 취약점이 유발되면, 검증 과정이 무기한 중단되어 시스템이 새로운 거래를 처리하는 능력을 효과적으로 방해하고, 네트워크가 완전히 중단됩니다. 설상가상으로, 노드가 재시작된 후에도 이 상황이 지속되므로 전통적인 완화 조치는 충분하지 않습니다. 이 취약점이 한 번 유발되면 "지속적인 파괴" 상황이 발생하여 전체 Sui 네트워크에 지속적인 영향을 미치게 됩니다.

Sui의 해결 방법

CertiK의 피드백 후, Sui는 신속하게 이 취약점을 확인하고 이 주요 결함을 해결하기 위한 패치를 발표했습니다. 이 패치는 상태 변경과 변경 후 플래그 간의 일관성을 보장하여 "햄스터 휠" 공격이 초래하는 주요 영향을 제거했습니다.

위의 불일치를 제거하기 위해, Sui의 패치는 AbstractState::join 함수에 대한 작지만 중요한 조정을 포함합니다. 이 패치는 AbstractValue::join을 실행하기 전에 상태 병합 결과를 판별하는 논리를 제거하고, 대신 먼저 AbstractValue::join 함수를 실행하여 상태를 병합한 후 최종 업데이트 결과와 원래 상태 값(old_value)을 비교하여 병합이 발생했는지를 나타내는 플래그를 설정합니다.

이렇게 하면 상태 병합 결과가 실제 업데이트 결과와 일치하게 되어 분석 과정에서 무한 루프가 발생하지 않게 됩니다.

이 특정 취약점을 수정하는 것 외에도, Sui는 향후 검증기 취약점의 영향을 줄이기 위해 완화 조치를 배포했습니다. Sui의 버그 보고서에 대한 응답에 따르면, 완화 조치는 Denylist라는 기능을 포함합니다.

"그러나 검증기에는 특정 거래 유형을 일시적으로 거부할 수 있는 노드 구성 파일이 있습니다. 이 구성은 게시 및 소프트웨어 패키지 업그레이드를 일시적으로 금지하는 데 사용할 수 있습니다. 이 버그는 Sui 검증기를 실행하기 전에 게시 또는 소프트웨어 패키지 업그레이드 tx를 서명하는 동안 발생했기 때문에, 거부 목록은 검증기의 실행을 중단하고 악의적인 tx를 폐기하여 이러한 tx 유형을 일시적으로 거부하는 것이 100% 효과적인 완화 조치입니다(비록 이것이 게시 또는 업그레이드를 시도하는 사람의 서비스를 일시적으로 중단시킬 것입니다).

덧붙여서, 우리는 이 TX 거부 목록 구성 파일을 한동안 가지고 있었지만, 우리는 증명서에 대해서도 유사한 메커니즘을 추가하여 이전에 보고된 "검증기 무한 루프" 취약점의 후속 완화 수단으로 삼았습니다. 이 메커니즘을 통해 우리는 이러한 공격에 대해 더 큰 유연성을 가질 수 있습니다: 우리는 증명서 거부 목록 구성을 사용하여 검증기가 나쁜 증명서를 잊게 하고(무한 루프를 깨뜨리기 위해), TX 거부 목록 구성을 사용하여 게시/업그레이드를 금지하여 새로운 악의적인 공격 거래 생성을 방지할 것입니다. 이 문제에 대해 생각하게 해주셔서 감사합니다!

검증기는 거래 서명 전에 바이트코드 검증을 위해 제한된 "틱(ticks)"(가스와는 다름)를 가지고 있으며, 거래에 게시된 모든 바이트코드가 이만큼의 틱 내에서 검증되지 않으면 검증기는 해당 거래의 서명을 거부하여 네트워크에서 실행되는 것을 방지합니다. 이전에는 측정이 선택된 복잡한 검증기 그룹에만 적용되었습니다. 이 문제를 해결하기 위해, 우리는 각 검증기에 대한 측정을 확장하여 각 틱의 검증 과정에서 검증기가 수행하는 작업에 제약을 두도록 했습니다. 우리는 또한 ID 누출 검증기 내의 잠재적인 무한 루프 오류를 수정했습니다."

-- Sui 개발자에 의한 취약점 수정 설명

결론적으로, Denylist는 검증자가 게시 또는 업그레이드 프로세스를 비활성화하여 검증기 내의 취약점 악용을 일시적으로 회피하고 일부 악의적인 거래가 초래할 수 있는 잠재적 파괴를 효과적으로 방지할 수 있도록 합니다. Denylist 완화 조치가 발효되면, 노드는 자신의 게시/업데이트 계약 기능을 희생하여 계속 작업할 수 있도록 보장합니다.

요약

본 문서에서는 CertiK Skyfall 팀이 발견한 "햄스터 휠" 공격의 기술적 세부 사항을 공유하고, 이 새로운 유형의 공격이 어떻게 주요 취약점을 이용하여 Sui 네트워크를 완전히 중단시키는지를 설명했습니다. 또한, Sui가 이 주요 문제를 해결하기 위해 신속하게 대응한 방법을 면밀히 조사하고, 취약점 수정 및 유사한 취약점 완화 방법을 공유했습니다.