요약
WebAssembly는 현대 애플리케이션 개발 접근 방식을 혁신하고 있습니다. 이 기술은 웹 브라우저에서 이식 가능하고 높은 성능의 모듈을 만들기 위해 탄생했지만, 현재는 다양한 이질적인 사용 사례에서 그 능력이 광범위하게 활용되고 있습니다. 커뮤니티의 막대한 노력으로 새로운 툴킷들이 개발되어 이 기술의 실제 응용 프로그램 적용이 더욱 용이해졌습니다.
이러한 맥락에서 WebAssembly 생태계와 소프트웨어 보안 사이의 연관성을 연구하는 것이 중요합니다. 실제로 WebAssembly는 시스템의 보안을 향상시키는 매개체가 될 수 있지만, 탐지 시스템을 회피하거나 암호화폐 채굴 활동을 수행하는 데 악용될 수도 있습니다. 또한, C와 같은 저수준 언어로 개발된 프로그램을 WebAssembly 바이너리로 컴파일할 수 있으며, 메모리 공격에 취약한 프로그램을 WebAssembly의 샌드박스 환경에서 실행하는 것이 보안에 어떤 영향을 미치는지 평가하는 것은 흥미로운 과제입니다.
더불어, WebAssembly는 안전하고 격리된 환경을 제공하도록 설계되었지만, 이러한 기능의 약점을 분석하고 이를 해결하기 위한 새로운 메커니즘을 제안하기 위해 그 능력을 평가해야 합니다. 일부 연구에서는 WebAssembly 취약점을 발견하거나 공격을 탐지하기 위한 관련 솔루션에 대한 조사가 이루어졌지만, 작성 시점에서는 WebAssembly 생태계에서 보안 관련 문헌에 대한 포괄적인 리뷰가 없습니다.
우리는 이 격차를 메우기 위해 WebAssembly의 보안과 관련된 연구 작업에 대한 종합적인 리뷰를 제안합니다. 우리는 7가지 다른 보안 카테고리를 식별하여 121개의 논문을 분석했습니다. 우리의 작업이 WebAssembly의 복잡한 환경에 대한 통찰력을 제공하고, 연구자, 개발자, 보안 전문가들이 WebAssembly 생태계에서 새로운 길을 개척하는 데 도움이 되기를 바랍니다.
1. 소개
WebAssembly는 휴대 가능한 머신 코드에 대한 공식 사양으로, 어떤 언어로 개발되었든 현대 브라우저에서 실행될 수 있는 휴대용 코드를 실현하기 위해 탄생했습니다. 이 기술은 브라우저를 위한 클라이언트 사이드 솔루션을 제공하기 위해 개발되었지만, 현재는 여러 클라우드 공급자들이 서버 사이드를 위한 WebAssembly 런타임 환경을 제공하고 있습니다. 이는 성능, 격리, 분산, 모듈성 측면에서 WebAssembly가 촉진하는 핵심 혁신을 보여줍니다. WebAssembly의 광범위한 보급으로 인해 이 기술과 보안 사이의 연결을 연구하는 것이 중요해졌습니다. 보안 연구는 WebAssembly의 설계 및 시스템에서 보안 결함의 존재를 평가하기 위한 실증 연구, WebAssembly 보안을 강화하기 위한 솔루션의 구현, WebAssembly에서 취약점을 발견하거나 공격을 탐지하기 위한 새로운 접근 방식의 구현, 또는 보안 관련 사용 사례를 위한 WebAssembly 솔루션의 제안을 포함한 다양한 주제를 다룰 수 있습니다. 앞서 언급한 연구 분야에서 여러 연구가 개발되었지만, 우리의 지식에 따르면 기존 문헌에 대한 포괄적인 조사를 제공하는 작업은 없습니다.
이 연구는 보안과 WebAssembly 생태계 사이의 연관성을 조사한 가장 관련성 높은 연구들을 종합적으로 검토함으로써 이 방향에 기여하고자 합니다. 우리는 121개의 연구를 분석하여, 96개를 7개의 보안 카테고리로 분류하고, 특정 보안 카테고리에 맞지 않지만 WebAssembly와 보안에 대한 문헌을 확장하는 데 기본적인 지식을 제공하는 나머지 25개의 추가 연구를 설명합니다. 따라서 우리는 WebAssembly 세계의 보안 개요를 제공하여, 향후 연구를 탐구하려는 연구자들뿐만 아니라 이 매력적인 기술을 시스템에 통합하려는 보안 전문가들에게도 출발점을 제공하고자 합니다.
이 논문의 나머지 부분은 여섯 개의 섹션으로 구성됩니다. 섹션 2는 독자들에게 이후 섹션을 따라가기 위한 기본 개념을 전달합니다. 섹션 3은 우리가 리뷰와 관련된 연구를 찾기 위해 따랐던 리뷰 프로세스를 설명합니다. 섹션 4는 기존의 WebAssembly 연구를 리뷰한 연구들을 보여주며, 특히 우리의 발견과의 차이점을 설명함으로써 보안에 집중한 연구에 중점을 둡니다. 섹션 5는 리뷰한 연구들을 설명하고, 섹션 6은 관련 정보와 향후 연구에서 다룰 수 있는 연구 공백을 요약함으로써 이에 대한 논의를 제공합니다. 섹션 7은 WebAssembly 보안 분야에서 도전적인 길을 탐구하고자 하는 연구자들을 위한 통찰력을 제안함으로써 우리의 연구를 마무리합니다.
2. 기본 개념
이 섹션에서는 먼저 WebAssembly 생태계를 설명하며 독자들에게 기본적인 내용을 소개합니다. 이후 섹션 5에서 설명될 관련 연구들을 이해하는 데 유용한 개념들, 즉 스마트 계약 및 저수준 취약점을 해결하기 위한 보안 기술을 소개합니다.
2.1 WebAssembly 소개
2015년, 브렌단 아이크(Brendan Eich)는 웹을 위한 어셈블리 프로그램을 작성하는 혁신적인 방법으로 WebAssembly를 발표했으며, 이는 asm.js를 대체하는 것을 목표로 했습니다 [1]. asm.js를 대체하기 위한 주된 이유는 컴파일러 옵션을 간소화하고, JavaScript보다 훨씬 빠르게 네이티브 방식으로 코드를 디코딩할 수 있는 성능을 제공하기 위함이었습니다 [3]. 2017년에는 WebAssembly 커뮤니티 그룹이 생성되어 WebAssembly의 사전 표준화를 정의하기 위한 협력이 이루어졌고, 2019년 WebAssembly는 월드 와이드 웹 컨소시엄(W3C)의 권고안이 되었습니다 [4]. WebAssembly의 설계 목표는 다음에 중점을 두고 있습니다:
- 성능: 코드는 최신 하드웨어 기능을 활용하여 네이티브 코드 성능에 가장 가까워야 한다.
- 보안: 코드는 메모리 안전, 격리, 샌드박스 환경에서 검증되고 실행되어야 한다.
- 이식성: 코드는 언어, 하드웨어, 플랫폼에 독립적이어야 한다.
WebAssembly가 만들어진 이후, Bytecode Alliance [5]와 같은 여러 기업 및 비영리 단체들이 이 프로젝트를 지원하기 시작했습니다.
WebAssembly는 처음에 C/C++ 프로젝트를 빌드하기 위해 설계되었지만, 오늘날에는 더 많은 고수준 언어를 지원하기 위한 커뮤니티의 강력한 노력이 있습니다. 현재로서는 Python, Ruby, PHP, C, Rust 프로그램을 컴파일하여 WebAssembly 코드로 생성하고, 이를 WebAssembly 컴파일러에서 실행할 수 있습니다.
WebAssembly 생태계에 관해서는, 일부 회사들이 DockerHub를 개발하여 Docker 이미지를 검색하고 사용할 수 있는 오픈 서치 엔진 및 저장소를 제공한 Docker 커뮤니티의 접근 방식을 따르고 있습니다 [6]. 특히, Wasmer 팀은 WebAssembly 바이너리를 실행하기 위한 WebAssembly 런타임 [7], 모든 프로그래밍 언어에서 WebAssembly 프로그램을 임베드할 수 있는 소프트웨어 개발 키트(SDK) [8], SDK를 통해 개발된 프로그램을 실행할 수 있는 서버리스 플랫폼 [9], 그리고 커뮤니티에서 개발된 WebAssembly 바이너리를 검색할 수 있는 공개 저장소 [10]로 구성된 완전한 WebAssembly 프레임워크를 제공합니다.
2.1.1 WebAssembly 구성 요소
WebAssembly 생태계는 여러 언어로 작성된 프로그램을 실행할 수 있게 해주는 다양한 구성 요소로 이루어져 있습니다. WebAssembly는 주로 C 프로그램을 실행하는 데 초점을 맞췄으나, 현재는 대부분의 인기 있는 프로그래밍 언어를 지원합니다. 개발자는 자신이 선호하는 언어로 프로그램을 작성한 후, 소스 코드는 두 가지 처리 과정을 거칠 수 있습니다: (i) WebAssembly 컴파일러에서 컴파일되어 런타임 엔진에서 실행되거나, (ii) WebAssembly 인터프리터가 소스 코드를 해석하여 실행할 수 있습니다. 실행은 WebAssembly 런타임 엔진에 의해 조정되며, 이는 하위 시스템(브라우저, 운영 체제 등)과의 실행을 추상화하여, 최종적으로 WebAssembly 바이너리 파일(컴파일된 경우) 또는 현재 코드 줄(해석된 경우)을 하위 시스템 아키텍처에서 실행합니다.
WebAssembly는 저수준 어셈블리와 같은 언어로 컴파일된 임의의 소스 코드를 브라우저에서 실행하기 위한 필요성에서 발전했습니다. WebAssembly는 높은 수준의 이식성을 보여주며, 다른 플랫폼으로 확장되었습니다. WebAssembly 시스템 인터페이스(WASI) [11]는 프로그램에 안전한 인터페이스를 제공하기 위한 표준화된 API 사양 모음으로, WebAssembly의 기능을 확장합니다. 이 API는 I/O, 시계, 파일 시스템, HTTP 드라이버 등과 같은 기본 기능과의 상호작용을 용이하게 합니다.
WebAssembly 프로그램은 모듈이라는 단위로 구성되며, 이는 타입, 함수, 테이블, 메모리, 전역 변수를 정의하는 배포, 로딩, 컴파일의 단위입니다. 각 모듈은 가져오기(import)와 내보내기(export)를 선언하며, 인스턴스화될 때 자동으로 시작 함수가 호출됩니다.
2.1.2 WebAssembly 메모리 레이아웃 및 바이너리 형식
WebAssembly는 단순성을 원칙으로 하여, 단순한 선형 메모리 구조, 즉 조정 가능한 원시 바이트 배열을 정의합니다. 각 메모리에는 WebAssembly 모듈 내 메모리 레이아웃, 크기, 속성에 대한 정보를 저장하는 메타데이터 영역이 있습니다. 각 프로그램은 선형 메모리의 임의의 바이트 주소에서 값을 로드하고 저장할 수 있습니다.
WebAssembly의 계산 모델은 스택 머신에 기반합니다. 프로그램 명령은 순차적으로 실행되며, 인자를 꺼내 결과를 스택에 넣는 방식으로 값을 조작합니다. 각 명령은 1바이트짜리 연산코드(opcode)로 인코딩되며, (있을 경우) 즉시 인자(argument)가 뒤따릅니다. 명령어는 제어, 참조, 파라메트릭, 변수, 테이블, 메모리, 숫자, 벡터, 표현식 등의 여러 유형이 있습니다.
WebAssembly는 두 가지 구체적인 표현 방식이 있으며, 이는 공통 구조로 매핑됩니다:
- 텍스트 형식(.wat 확장자): 개발자가 WebAssembly 모듈의 구조를 이해할 수 있도록 설계된 형식으로, 코드 작성과 컴파일에 사용될 수 있습니다.
- 바이너리 형식(.wasm 확장자): 스택 기반 가상 머신을 위한 컴팩트한 바이너리 명령어 형식으로, 고수준 언어의 컴파일 대상입니다.
2.1.3 WebAssembly 사용 사례
WebAssembly는 높은 유연성과 이식성을 보장하도록 설계되었습니다. 예를 들어, C로 작성된 프로그램은 브라우저, x86 데스크톱, ARM 임베디드 마이크로컨트롤러 등 모든 아키텍처에서 컴파일 및 실행될 수 있습니다. 일반적인 사용 사례는 브라우저 기반 애플리케이션(게임, 피어 투 피어 애플리케이션, 이미지 인식 등)에 집중되었지만, 다른 응용 시나리오도 있습니다 [12]. Hilbig et al. (2021)은 웹에서 사용되는 100개의 무작위 WebAssembly 바이너리를 샘플링하여, WebAssembly가 게임, 텍스트 및 미디어 처리, 시각화/애니메이션, 프로그래밍 언어 데모에 사용된다는 사실을 강조했습니다. Cloud Native Computing Foundation은 매년 WebAssembly의 전 세계적인 상태를 요약한 보고서를 제공합니다 [14]. 그들의 연구에 따르면:
- WebAssembly의 주요 사용 사례는 웹 애플리케이션(58%), 데이터 시각화(35%), 사물 인터넷, 게임, 백엔드 서비스입니다.
- 개발자들은 WebAssembly를 채택할 때 성능상의 이점, 새로운 사용 사례 및 기술 탐색, 프로젝트 간 코드 공유에 관심이 있습니다. 그들은 WebAssembly를 도입할 때 성능상의 이점을 확인했습니다.
- WebAssembly는 새로운 애플리케이션을 실현하거나 기존 애플리케이션을 이전하는 데 사용됩니다.
- WebAssembly 바이너리를 컴파일하는 데 사용되는 소스 코드 언어는 주로 JavaScript, C#, C++, Python입니다.
본 연구에서는 문헌에 기록된 보안에 초점을 맞춘 가장 관련성 있는 사용 사례를 강조합니다(섹션 5.3 참조).
2.2 저수준 소프트웨어 취약점
WebAssembly는 주로 C와 같은 저수준 언어로 개발된 기본 코드를 컴파일하는 데 사용되기 때문에, 프로그램에 영향을 미칠 수 있는 저수준 취약점에 대한 기본 개념을 소개하는 것이 중요합니다. 이러한 취약점을 이해하기 위해서는 프로그램 실행에 대한 개요를 제공할 필요가 있습니다.
C 및 C++과 같은 저수준 언어는 안전하지 않은 메모리 관리 관행으로 인해 다양한 취약점을 초래할 수 있습니다:
- 스택 기반 오버플로: 공격자가 스택에 위치한 메모리 버퍼(함수 반환 주소 포함)를 덮어쓸 수 있을 때 발생하는 취약점으로, 임의 코드 실행을 유발할 수 있습니다.
- 힙 기반 오버플로: 스택 오버플로와 유사하지만, 힙 메모리 섹션에서 발생합니다.
- 정수 오버플로: 산술 연산의 결과가 변수를 저장하는 데 할당된 메모리 크기를 초과할 때 발생하며, 메모리 손상 또는 의도치 않은 코드 실행을 유발할 수 있습니다.
이러한 취약점은 안전하지 않은 함수가 입력 제어가 가능할 때 자주 발생하며, 악의적인 사용자가 메모리 버퍼를 덮어쓸 수 있는 입력을 보낼 수 있게 됩니다.
2.2.1 소프트웨어 취약점 탐지를 위한 보안 접근법
소프트웨어 취약점 탐지 기법은 크게 두 가지 범주로 분류할 수 있습니다:
- 정적 분석: 프로그램을 실행하지 않고 소스 코드를 분석합니다. 이는 부적절한 입력 검증이나 타입 불일치로 인해 발생하는 취약점을 탐지하는 데 유용하지만, 실행 중 발생하는 오류나 코드와의 복잡한 상호작용으로 인한 취약점은 발견할 수 없습니다.
- 동적 분석: 프로그램에 악의적인 입력을 주입하여(퍼징) 실행 중 취약점을 찾아내거나, 프로그램 실행 중에 코드를 분석(트레이싱 또는 심볼릭 실행)하여 취약점을 발견하는 방식입니다.
이러한 접근 방식은 아래 표에서 설명된 여러 기술로 세분화될 수 있습니다.
표 1: 취약점 탐지 기술
정적 기술 | 설명 |
제어 흐름 그래프 분석 | 프로그램 실행 중 탐색할 수 있는 모든 경로의 그래픽 표현을 분석하여 보안 문제를 발견합니다 [15]. |
컨텍스트 민감 데이터 흐름 분석 | 프로그램 내에서 함수가 호출될 수 있는 "컨텍스트", 즉 시나리오를 정의하고, 컨텍스트가 변경될 때 데이터 흐름을 분석합니다 [16]. |
코드 속성 그래프 | 분석된 프로그램의 그래프 기반 표현을 실현하여, 관련 정보를 검색하고 잠재적으로 취약점을 발견할 수 있습니다 [17]. |
상태 머신 표현 | 프로그램 상태를 기반으로 한 이론적 모델을 사용하여 프로그램의 동작을 나타내고, 잠재적인 보안 결함을 드러냅니다 [18]. |
동적 기술 | 설명 |
블랙 박스 퍼저 | 무작위 입력을 보내 충돌을 일으키고 취약점을 탐지합니다. 애플리케이션의 내부 구조에 대한 정보는 사용하지 않습니다 [19]. |
화이트 박스 퍼징 | 테스트 중인 애플리케이션의 내부 구조에 대한 완전한 지식을 가지고 퍼징을 수행합니다 [20]. |
그레이 박스 퍼저 | 블랙 박스와 화이트 박스 접근 방식을 결합하여 두 가지 모두를 활용합니다 [20]. |
심볼릭 실행 | 프로그램을 분석하여 심볼릭 변수를 통해 프로그램의 특정 부분 실행을 트리거하는 입력을 결정합니다 [21]. |
콘콜릭 실행 | 심볼릭 실행과 유사하지만, 구체적인 값을 사용하여 경로 탐색 공간을 확장합니다 [22]. |
트레이싱 및 제어 데이터 흐름 | 프로그램의 제어 흐름 및 데이터 흐름을 모니터링하고, 실행 중에 트리거된 취약점을 추적합니다 [23]. |
바이트코드 계측 및 런타임 검증 | 실행 중 바이트코드를 수정하여, 추가 검사를 삽입하고 이를 검증하여 보안 결함을 식별합니다 [24]. |
2.3 스마트 계약
이 섹션은 섹션 5와 6에서 설명된 내용들을 이해하는 데 유용한 배경 정보를 제공합니다. WebAssembly의 일반적인 사용 사례 중 하나는 스마트 계약 구현입니다. 스마트 계약은 WebAssembly의 이식성과 다재다능함 덕분에 분산 특성에 잘 맞는 사용 사례입니다. 스마트 계약은 특정 조건이 만족되면 자동으로 실행되는 블록체인 상의 디지털 계약입니다. 이들은 블록체인, 즉 분산되고, 공유되고, 불변의 원장과 관련이 있습니다 [25].
가장 널리 배포된 블록체인 플랫폼 중 하나는 이더리움(Ethereum)입니다 [26]. 이더리움은 블록체인 기술의 기능을 단순한 금융 거래를 넘어 확장합니다. 이 플랫폼은 개발자가 자가 실행 코드를 사용하여 복잡한 애플리케이션을 스마트 계약으로 생성할 수 있도록 합니다. 스마트 계약은 특정 조건이 충족될 때 자동으로 실행되어, 거래의 투명성, 불변성, 신뢰성을 제공합니다. 이더리움은 또한 이더(Ether, ETH)라는 자체 암호화폐를 도입했으며, 이는 계산을 수행하거나 트랜잭션을 검증하는 네트워크 참여자에게 보상으로 사용됩니다. 이더리움 문서 [27]는 블록체인 취약점을 이해하는 데 필요한 여러 관련 개념을 제공합니다:
- 이더리움 계정: 이더리움 블록체인 상의 디지털 정체성으로, 사용자들이 이더를 주고받거나 스마트 계약과 상호작용할 수 있습니다.
- 주소: 이더리움 계정을 식별하는 데 사용되는 고유 식별자입니다.
- 블록: 트랜잭션 또는 디지털 작업이 저장되는 데이터 구조입니다.
- 블록체인: 데이터가 소급하여 수정될 수 없도록 보장하는, 네트워크의 모든 컴퓨터에 복제 또는 공유된 트랜잭션 데이터베이스입니다 [28].
- 스마트 계약: 블록체인에서 합의를 자동으로 실행하는 프로그램으로, 자가 실행되는 디지털 계약과 같습니다 [29].
- 트랜잭션: 특정 주소를 대상으로 한 발신 계정에서 서명된 데이터를 이더리움 블록체인에 커밋한 것.
- 계약 계정: 트랜잭션을 받을 때마다 코드를 실행하는 코드를 포함하는 계정.
- 이더리움 가상 머신(EVM): 바이트코드를 실행하는 스택 기반 가상 머신.
- 외부 소유 계정(EOA): 개인 키를 통해 사람이 제어하는 가장 일반적인 유형의 이더리움 계정.
- 내부 트랜잭션: 계약 계정에서 다른 계약 계정이나 EOA로 보내진 트랜잭션.
- 메시지: 이더리움 실행 환경에서만 존재하는 내부 트랜잭션(메시지는 트랜잭션과 유사하지만, 외부 행위자가 아닌 계약에 의해 생성됨).
- 메시지 호출: 한 계정에서 다른 계정으로 메시지를 전달하는 행위.
- Delegatecall: 호출자 계약의 데이터를 사용하는 메시지 호출.
- 영수증(Receipt): 특정 트랜잭션의 결과를 나타내는 이더리움 클라이언트가 반환하는 데이터로, 트랜잭션의 해시, 블록 번호, 사용된 가스 양, 스마트 계약 배포 시 계약 주소를 포함합니다.
초기 블록체인 플랫폼들은 성능 문제를 겪었습니다. 이를 해결하기 위해 연구자들은 지분 증명(Proof-of-Stake, PoS) 및 위임 지분 증명(Delegated Proof-of-Stake, DPoS)과 같은 다양한 합의 알고리즘을 제안했습니다. 가장 관련성이 높은 DPoS 플랫폼 중 하나는 EOSIO입니다 [30]. EOSIO 스마트 계약은 여러 개념으로 구성됩니다:
- 액션(action): 스마트 계약과 계정 간 통신을 위한 단일 작업을 나타냅니다.
- 트랜잭션: 여러 액션으로 구성됩니다.
- apply 함수: 스마트 계약을 검증하기 위한 액션 핸들러를 디스패치하는 함수입니다. 이 함수는 스마트 계약을 승인한 계정을 식별하는 ‘코드’ 매개변수를 가지고 있습니다.
- eosio.token 계약: 토큰을 전송하는 데 사용할 수 있는 표준 계약으로, "전송" 기능을 가지고 있습니다.
- dApp: 분산 네트워크에서 실행되는 분산 애플리케이션.
2.3.1 스마트 계약의 취약점
스마트 계약은 스마트 계약 도메인 및 채택된 블록체인 플랫폼과 밀접하게 관련된 취약점에 영향을 받습니다. He et al. (2022)는 EOSIO 시스템의 공격 및 취약점에 대한 종합적인 조사를 제공합니다. 다음 표는 스마트 계약에 영향을 미치는 가장 중요한 취약점을 설명합니다.
표 2: 스마트 계약에서의 주요 취약점
취약점 | 설명 |
가짜 EOS 전송 | 부적절한 apply 함수 구현은 코드 매개변수를 올바르게 검증하지 않아 가짜 EOS 토큰을 통한 코드 논리 실행을 허용합니다. |
가짜 EOS 영수증 | 스마트 계약 알림이 안전하지 않은 릴레이를 허용하면, 공격자가 eosio.token에서 전송을 호출하고, 피해자에게 EOS 확인을 속여 공격자에게 토큰을 제공하도록 서비스를 제공하게끔 속입니다. |
가짜 EOS 알림 | 시스템이 유효한 apply 구현을 제공하더라도, 다른 매개변수를 이용하여 악용하는 가짜 EOS 전송의 변형입니다. |
안전하지 않은 메시지 호출 | 권한이 제대로 확인되지 않은 메시지 호출입니다. |
탐욕적인 스마트 계약 | 탐욕적인 스마트 계약은 이더를 받을 수 있지만, 이더를 외부로 보내는 함수를 포함하지 않습니다. |
위험한 Delegatecall | 공격자가 msg.data를 조작하여 피해자의 계약에서 호출된 함수를 변경합니다. |
블록 정보 의존성 | 중요한 작업을 결정하기 위해 블록 타임스탬프 또는 블록 번호를 잘못 사용합니다. 이 변수는 채굴자가 조작할 수 있으므로 신뢰할 수 있는 출처로 간주할 수 없습니다. |
잘못된 예외 처리 | 부적절한 예외 처리는 트랜잭션 중 불일치를 초래할 수 있습니다. |
재진입 취약점 | 재진입이 허용되지 않도록 설계된 함수를 재진입 방식으로 호출합니다1. |
롤백 | 공격자가 조건부로 스마트 계약을 되돌리는 방식으로 블록체인 시스템에서 안전하지 않은 롤백 작업을 악용합니다. 주로 도박 dApp에서 사용됩니다. |
권한 확인 누락 | 중요한 작업의 권한을 제대로 확인하지 않습니다. |
의사 난수 생성기 | 의사 난수 생성기의 안전하지 않은 구현을 신뢰하는 중요한 작업은 보안 문제를 초래할 수 있습니다. |
자살성 | 보호되지 않은 인터페이스로 인해 피해자 계약의 파괴가 허용됩니다. |
호출 주입 | 공격자가 중요한 함수를 호출할 수 있습니다. |
섹션 5.5에서는 이러한 유형의 공격을 탐지하기 위해 고안된 기술을 설명합니다.
2.4 신뢰 실행 환경과 보안 엔클레이브
섹션 5.3에서 설명된 바와 같이, 여러 WebAssembly 사용 사례 및 개선 사항은 프로세서 보안 기능과의 통합을 포함합니다. 신뢰 실행 환경(Trusted Execution Environment, TEE)은 코드와 데이터를 보호하기 위한 프로세서의 강화된 메모리 영역입니다 [32]. 가장 널리 사용되는 TEE 구현 기술 중 하나는 Intel Security Guard Extension(SGX)입니다 [33]. SGX는 "보안 엔클레이브" 개념을 정의하며, 민감한 데이터와 코드가 보안 엔클레이브 내에서 실행됩니다. 이 접근 방식은 애플리케이션 전체 또는 단일 함수를 엔클레이브에서 실행하여 확장성을 제공합니다. 개발자는 Intel SGX를 기반으로 한 보안 애플리케이션을 구축하기 위해 API를 사용할 수 있으며, Intel은 보안 엔클레이브를 처리하기 위한 소프트웨어 개발 키트(SDK)를 제공합니다.
3. 문헌 검토 과정
이 섹션에서는 WebAssembly 보안에 관한 문헌을 검토하는 데 사용된 과정을 설명합니다. 이 검토는 Webster와 Watson(2022) [34], Kitchemann과 Brereton(2013) [35]에서 설명된 방법론에 영감을 받아 구조화된 프로세스를 따랐습니다. 이 과정은 다음 단계로 진행되었습니다:
- 자동 검색: 특정 키워드를 사용해 자동 검색을 수행했습니다.
- 정리: 자동 검색으로 얻은 중복 항목을 제거하고, 포함 및 제외 기준을 충족하지 않는 범위 외의 연구를 제외했습니다.
- 참조 검토: 포함된 각 연구에 대해 인용 및 참조 문헌을 분석하여 다른 관련 연구를 식별했습니다.
- 연구 분류: 각 연구의 주요 기여를 식별하기 위해 첫 번째 검토를 수행하고, 이를 표 3에서 설명한 카테고리로 나누었습니다.
- 연구 검토: 검색된 연구를 자세히 검토하고, 5장과 6장에서 제시된 개념을 개발했습니다.
표 3: 분석된 문헌의 보안 카테고리
카테고리 | 설명 | 연구 개수 |
보안 분석 | WebAssembly 생태계의 보안을 분석합니다. | 4 |
공격 시나리오 | WebAssembly 기능을 사용하여 공격 시나리오를 구현하는 능력을 연구합니다. | 7 |
사이버 보안 사용 사례 | WebAssembly를 활용하여 사이버 보안 도메인에서 사용 사례를 구현합니다. | 21 |
취약점 발견 | WebAssembly 바이너리에서 취약점을 발견하는 방법을 연구합니다. | 16 |
보안 강화 | WebAssembly 언어 및 구성 요소를 확장하여 보안을 강화합니다. | 27 |
기타 | WebAssembly 보안 연구 문헌을 확장하는 데 중요한 연구입니다. | 25 |
표 4: 문헌 검토 과정에서 분석된 출판물 수
키워드 | SCOPUS 논문 수 | IeeeXplore 논문 수 |
“wasm security” | 43 | 20 |
“wasm vulnerability” | 18 | 8 |
“webassembly security” | 91 | 44 |
“webassembly vulnerability” | 26 | 10 |
총합 | 178 | 82 |
중복 제거 후 합산 | 114 | ㅤ |
포함 및 제외 기준 적용 후 | 62 | ㅤ |
참조 분석 후 최종 합계 | 121 | ㅤ |
3.1 자동 검색
우리는 WebAssembly와 관련된 보안을 다루는 네 가지 관련 키워드 쌍을 검색했습니다: (i) "webassembly security"; (ii) "webassembly vulnerability"; (iii) "wasm security"; (iv) "wasm vulnerability".
빠른 분석 결과, 다른 키워드를 추가해도 사용된 키워드 조합과 거의 동일한 결과를 제공한다는 점을 확인했기 때문에 다른 키워드는 제외했습니다. 예를 들어, "cybersecurity"라는 키워드는 "security"와 동일한 결과를 제공했습니다. "vulnerability" 대신 "vulnerabilities"와 같은 복수형을 사용하는 경우도 마찬가지입니다.
우리는 동료 심사를 거친 논문이 포함된 두 가지 주요 플랫폼인 IEEE Xplore [36]와 Scopus [37]를 사용했습니다. 논문을 확보한 후, 이를 통합하고 중복 항목을 제거했습니다. 그런 다음, 아래에서 설명하는 포함 및 제외 기준을 적용하여 범위 내의 논문만 선택했습니다. 마지막으로, 관련 연구를 찾기 위해 참조 문헌의 거꾸로 및 순방향 분석을 수행했습니다.
3.2 연구의 포함 및 제외 기준
우리는 보안 도메인에 명확히 초점을 맞춘 연구만 포함했습니다. 그러나 보안에 직접적으로 초점을 맞추지 않았더라도 WebAssembly에서 새로운 보안 연구 주제를 탐구하는 데 필수적인 자료로 간주되는 연구는 "기타"라는 부차적인 카테고리에 포함했습니다. 우리는 주로 동료 심사를 거친 논문을 고려했지만, 거꾸로 및 순방향 참조 검토 중에 사전 인쇄 서비스(pre-print services) [38]에서 제공된 관련 문헌과 잘 알려진 국제 사이버 보안 회의에서 발표된 관련 기술 논문 [39]도 포함했습니다. 영어로 작성되지 않은 연구는 제외했으며, 섹션 5.8에서는 보안 주제를 다루지만 만족스러운 분석을 제공하지 못한 예비 연구나 포스터 논문과 같은 연구를 언급했습니다.
3.3 연구 분류
문서를 검색한 후, 우리는 각 연구의 목표를 분석하여 주요 기여를 분류하고 범주화했습니다. 우리는 여러 카테고리를 정의하고, 연구의 기여 유형에 따라 항목을 구성했습니다. 그런 다음, 각 논문의 기술적 세부 사항을 더 깊이 분석하거나 다른 연구의 기능을 탐구하여 제안된 사례 연구를 더 잘 이해했습니다. 마지막으로, 우리는 분석을 종합하여 섹션 5에서 자세히 설명했습니다. 악성 코드 탐지의 특정 카테고리에서는 WebAssembly 기능을 포함하지 않은 취약점을 발견한 연구, 예를 들어 네트워크 트래픽에서 머신러닝 모델을 사용하여 암호화폐 채굴을 탐지하거나 [40, 41], WebAssembly 코드로 생성되지 않은 바이너리에 대한 동적 분석을 수행한 연구 [42]는 제외했습니다. 검토된 연구를 분류하기 위해, 우리는 여섯 가지 주요 카테고리를 식별했습니다:
- 보안 분석: WebAssembly 생태계의 보안을 분석하는 논문입니다. 이러한 연구는 WebAssembly 프로그램에 영향을 미치는 보안 결함의 초기 맥락을 제공하는 데 유용합니다.
- 실증 연구: 실제 시나리오를 분석하여 WebAssembly의 보안 측면을 조사하는 논문입니다. 이 연구들은 중요한 실증적 기여를 제공합니다.
- 공격 시나리오: WebAssembly 기능을 활용하여 복잡한 공격을 수행하는 접근 방식을 설명하는 논문입니다.
- 취약점 발견: WebAssembly를 기반으로 한 애플리케이션에서 취약점을 발견하는 방법을 제공하는 논문입니다.
- 보안 강화: 이러한 논문에서는 보안 분석 연구에서 조사된 보안 결함을 줄이기 위해 WebAssembly 구성 요소를 확장하는 것을 목표로 합니다.
- 보안 사용 사례: 이러한 논문에서는 제안된 솔루션, 시스템 및/또는 프레임워크의 보안 측면을 강화하기 위해 WebAssembly 기능을 활용합니다.
- 기타: 일부 관련 논문은 사이버 보안에 초점을 맞추지는 않지만, 새로운 보안 관련 연구 활동을 수행하는 데 있어 "초석"으로 간주될 수 있는 예비 연구로 포함됩니다.
4. 관련 연구
여러 연구들이 WebAssembly에 대한 유의미한 리뷰를 제공하지만, 명시적으로 보안에 초점을 맞추고 있지는 않습니다.
WebAssembly 런타임에 대한 분석은 Wang과 Wenwen(2022) [43]에 의해 이루어졌습니다. 이 연구에서 저자들은 다섯 가지 주요 독립 실행형 WebAssembly 런타임을 리뷰하고, 비교 목적을 위한 벤치마크 모음을 구성했습니다. 그들은 성능이 다양한 요소에 의해 영향을 받는다고 주장하며, 특정 사용 사례에 따라 최적의 런타임을 선택하는 기준을 제시했습니다. 또한, WebAssembly 바이너리 파일에 중요한 정보를 포함시켜 런타임 성능을 향상시키는 방법에 대한 통찰을 제공합니다.
클라우드 엣지 컴퓨팅 영역에서도 WebAssembly 채택에 대한 포괄적인 리뷰가 이루어졌습니다. Kakati et al.(2023) [45]은 이 분야에서 WebAssembly의 채택에 대해 자세히 분석했습니다.
- 사물인터넷(IoT)은 WebAssembly가 널리 채택되고 있는 또 다른 중요한 맥락입니다 [46]. Ray와 Partha Pratim(2023) [47]은 WebAssembly가 IoT 시스템에 채택되는 것을 다룬 포괄적인 조사 연구를 통해, WebAssembly 특성의 잠재력을 설명하고 WebAssembly 도구 및 툴체인 비교를 통해 개발자들에게 유용한 정보를 제공합니다. 또한, 이 연구 분야에서 계속 연구해야 할 미래 전망도 제시합니다.
4.1 보안 연구
섹션 5.1에서는 WebAssembly 컴파일러, 런타임, 그리고 안전하지 않은 메모리 언어로 작성된 프로그램을 포팅할 때의 영향을 다루는 보안 분석에 관한 관련 연구를 다룹니다 [48, 49, 50, 51]. 특히, Kim et al.(2022) [52]와 Harnes와 Morrison(2024) [53]은 WebAssembly 바이너리 보안을 위한 기술과 방법에 대한 포괄적인 조사를 제공합니다. 그들은 악의적인 WebAssembly 바이너리로부터의 보호, WebAssembly의 내재된 보안을 강화하기 위한 연구와 같은 그들의 연구에서 확인된 미해결 문제들을 해결하기 위한 미래 연구 방향을 제안합니다.
표 5, 6, 7에서는 리뷰를 비교 분석한 내용을 보여줍니다. 우리의 연구는 WebAssembly 구성 요소의 보안을 향상시키는 데 초점을 맞춘 연구, 다양한 사용 사례에서 보안 목적으로 WebAssembly를 활용한 연구, 실증적 연구를 수행한 연구, 그리고 보안 분석을 수행한 연구 등 다양한 문헌을 포괄하여 기존 연구 범위를 확장합니다. 또한, 우리는 다섯 가지 추가 카테고리를 다루며, 총 121개의 연구를 분석했습니다.
표 5: 우리의 분류 및 관련 연구를 기반으로 한 연구 비교
Kim et al.(2022) [52] | Harnes와 Morrison(2024) [53] | 우리의 연구 |
보안 분석 | ✓ | ✓ |
보안 강화 | ㅤ | ✓ |
취약점 발견 | ✓ | ✓ |
사이버 보안 사용 사례 | ㅤ | ✓ |
공격 시나리오 | ㅤ | ✓ |
공격 탐지 | ✓ | ✓ |
실증 연구 | ✓ | ✓ |
기타 연구 | ㅤ | ✓ |
표 6: 관련 연구에서 다룬 각 카테고리에 대해 분석한 출판물 수
카테고리 | Kim et al.(2022) [52] | Harnes와 Morrison(2024) [53] | 우리의 연구 |
취약점 발견 | 7 | 15 | 16 |
공격 탐지 | 9 | 7 | 12 |
보안 강화 | 8 | 0 | 27 |
표 7: 리뷰된 전체 연구 수
Kim et al.(2022) [52] | Harnes와 Morrison(2024) [53] | 우리의 연구 |
24 | 22 | 121 |
특히, 우리는 [54, 55]와 같은 일부 출판물을 관련 연구들과 함께 묶기보다는 "기타" 카테고리로 분류했습니다. 이는 이러한 출판물이 취약점 발견 노력으로 분류될 만큼 충분한 정보를 제공하지 못했다는 분석에 따른 결정이었습니다.
우리가 아는 한, 이는 WebAssembly 도메인에서 보안 연구에 관한 포괄적인 리뷰를 제공하는 최초의 연구입니다.
5. WebAssembly와 보안: 리뷰
이 섹션에서는 본 연구에서 분석한 연구들을 제시합니다. 이전에 설명한 바와 같이, 표 3은 섹션 3에서 설명된 제안된 카테고리를 요약하고, 각 카테고리에 대해 분석한 연구의 수를 표시합니다.
5.1 보안 분석
WebAssembly는 보안을 염두에 두고 설계되었지만, 관련 연구들은 여전히 보안 문제에 취약할 수 있음을 강조합니다. Lehmann et al.(2020) [48]이 수행한 중요한 연구가 이러한 우려를 부각시킵니다. 연구에서 저자들은 네이티브 바이너리에서 컴파일러 시스템의 개선을 통해 완화된 일부 고전적인 취약점이 WebAssembly에서는 여전히 악용될 수 있음을 보여주었습니다. 그들은 WebAssembly의 선형 메모리 시스템에 대한 광범위한 보안 분석을 수행하고, 취약한 애플리케이션의 예를 제시하며, 공격 원시(primitives)를 설명하고, 확인된 취약점에 대한 엔드 투 엔드 공격을 시연하며, WebAssembly 바이너리를 강화하기 위한 가능한 완화 전략을 제안했습니다. 특히, 저자들은 고전적인 공격 원시의 영향을 분석하고 이를 세 가지 주요 유형으로 분류했습니다: 쓰기 작업(스택 기반 버퍼 오버플로우 [56], 스택 오버플로우, 힙 메타데이터 손상 포함), 데이터 덮어쓰기(스택 및 힙 변수 덮어쓰기, "상수" 데이터 덮어쓰기 포함), 그리고 예상치 못한 동작을 유발하는 트리거(간접 호출 리디렉션, 호스트 환경에 코드 주입, 애플리케이션별 데이터 덮어쓰기 등). 그들은 이러한 공격 원시들이 크로스 사이트 스크립팅, 원격 코드 실행, 임의 파일 쓰기와 같은 엔드 투 엔드 공격을 실행하는 데 어떻게 결합될 수 있는지 설명합니다.
저자들은 분석된 보안 결함을 완화하기 위해 세 가지 접근 방식을 제안합니다: WebAssembly 언어 확장, 컴파일러 및 툴체인 개선, 개발 중 사용할 수 있는 안전하고 견고한 라이브러리 개발.
Stievenart et al.(2021) [49]는 WebAssembly 컴파일러에서 보호 기능의 부재로 발생하는 보안 취약점을 탐구합니다. 연구에서 저자들은 스택 기반 및 힙 기반 버퍼 오버플로우 취약점이 있는 4,469개의 C 프로그램을 x86 코드와 WebAssembly로 컴파일했습니다. 그 결과, 1,088개의 프로그램이 WebAssembly로 컴파일될 때 다른 동작을 보였습니다. 특히, WebAssembly는 스택 카나리(stack canary)와 같은 보안 조치가 없어 스택 스매싱 공격에 더 취약하다는 것을 발견했습니다.
앞서 설명한 것처럼, 저수준 프로그램에서의 메모리 관리는 보안 결함의 주요 원인입니다. 따라서 가장 영향을 많이 받는 프로그래밍 언어는 C [57]입니다. C는 하드웨어와 완전히 상호작용할 수 있도록 기계에 대한 추상화 수준이 가장 낮기 때문입니다.
Stiévenart et al.(2022) [50]는 C 프로그램을 WebAssembly로 교차 컴파일하는 보안 함의에 대해 조사합니다. 이 연구에서 저자들은 일반적인 취약점을 가진 17,802개의 프로그램을 64비트 x86 및 WebAssembly로 컴파일하고 실행했습니다. 그들은 4,911개의 바이너리가 WebAssembly에서 세 가지 주요 이유로 인해 다른 결과를 나타낸다고 밝혔습니다: WebAssembly에서 보안 조치가 없고, 실행 환경의 의미론이 다르며, 사용된 표준 라이브러리의 차이가 있습니다. 보안에 영향을 미치는 주요 차이점은 malloc() 및 free() 함수의 구현, 그리고 스택 스매싱 및 메모리 보호 메커니즘의 부재입니다. 이러한 문제를 해결하기 위해 저자들은 C 및 C++ 코드에서 메모리 의미론을 통합하도록 WebAssembly를 확장할 것을 제안합니다. 그들은 또한 보안 결함을 식별하는 데 정적 분석의 중요성을 강조하며, WebAssembly 런타임을 개선하고 보안 영향을 완화하기 위한 관련 연구를 강조합니다 [58, 59].
개발자들에게 유용한 리소스 중 하나는 Brian McFadden et al.(2018) [51]이 수행한 기술적 연구입니다. 이 연구에서 저자들은 WebAssembly 보안의 다양한 측면을 탐구하며, 특히:
- Emscripten의 컴파일러 및 링커 수준의 익스플로잇 완화 구현을 분석하고,
- WebAssembly에서 새로운 공격 벡터와 공격 방법을 소개하며, 버퍼 오버플로우 또는 간접 함수 호출이 크로스 사이트 스크립팅 또는 원격 코드 실행 공격으로 이어질 수 있음을 시연하고,
- WebAssembly 환경에서 메모리 손상 익스플로잇의 예를 제공하며,
- WebAssembly를 제품에 통합하려는 개발자를 위한 모범 사례와 보안 고려 사항을 제시합니다.
5.2 실증 연구
이 연구들은 WebAssembly 생태계에서 특정 현상을 분석하기 위한 실증적 사례 연구를 제공합니다. 초기 연구들은 WebAssembly가 암호화폐 채굴 공격을 실행하는 데 사용되는 빈도를 분석합니다.
Rüth et al.(2018) [60]은 채굴자를 식별하는 새로운 지문 인식(fingerprinting) 방법을 도입하여 공개된 블록 리스트보다 5.7배 더 많은 채굴자를 발견했습니다. 그들은 또한 가장 큰 최상위 도메인 및 Alexa 상위 1백만 웹사이트 [61]에서 1억 3천 8백만 도메인을 분석하여 채굴 사이트를 분류했습니다. 연구에 따르면 브라우저 기반 채굴의 비율은 0.08% 미만으로 매우 낮으며, 채굴 사이트의 75%가 웹 기반 채굴 제공자인 Coinhive를 사용하고 있었습니다.
Musch et al.(2019) [62, 63]는 Alexa 상위 1백만 웹사이트를 상세히 분석한 결과, 600개 중 1개의 웹사이트가 WebAssembly를 사용하고 있음을 발견했습니다. 그러나 WebAssembly를 사용하는 사이트의 50%가 채굴 및 코드 난독화를 목적으로 사용된다는 사실을 밝혔습니다.
Hilbig et al.(2021) [13]도 전 세계적으로 WebAssembly 사용을 분석하여 다른 결과를 제시했습니다. 그들은 다양한 출처에서 8,461개의 WebAssembly 바이너리를 수집하여 다음과 같은 결론을 도출했습니다:
- 64.2%의 바이너리는 C 및 C++와 같은 메모리 안전하지 않은 언어에서 컴파일되었으며,
- 1% 미만의 바이너리가 암호화폐 채굴과 관련이 있으며, 게임, 텍스트 처리, 시각화, 미디어 애플리케이션의 확산이 더 크며,
- 29%의 바이너리가 최소화된 상태로 존재하여, WebAssembly를 디컴파일하고 리버스 엔지니어링할 접근 방식의 필요성을 시사합니다.
Romano et al.(2021) [64]는 146개의 Emscripten 관련 WebAssembly 버그에 대한 정성적 분석과, 1,054개의 AssemblyScripts, Emscripten, Rustc/Wasm-Bindgen 같은 세 가지 오픈 소스 컴파일러에서 발생한 버그에 대한 정량적 분석을 수행했습니다. 그들은 신뢰 실행 환경(TEE)에서 민감한 정보가 노출될 수 있음을 결론지었습니다. Puddu et al.(2022) [65]는 TEE 내의 WebAssembly 런타임에서 비밀 코드를 실행할 때 발생하는 영향을 분석했으며, WebAssembly와 같은 중간 표현을 사용하는 것이 코드 누출로 이어질 수 있음을 보여주었습니다.
5.3 사이버 보안 사용 사례
WebAssembly는 보안이 중요한 비기능적 요구 사항인 다양한 도메인에서 널리 사용됩니다. 다음 섹션에서는 문헌에서 발견된 가장 흥미로운 기여들을 요약하고, 그들이 따르려고 했던 주요 연구 경로를 강조합니다.
5.3.1 브라우저 확장
WebAssembly는 주로 현대 브라우저를 위한 어셈블리 언어를 제공하기 위해 설계되었습니다. 따라서 이 기술을 사용하여 브라우저 확장을 구현하는 데 관한 광범위한 문헌이 존재합니다. WebAssembly는 이식 가능한 언어이므로 이 섹션에서 제시된 모든 연구들은 브라우저 환경으로 이식될 가능성이 있습니다. 그러나 "브라우저 확장"으로 분류한 연구들은 브라우저 기능을 확장하고 이식성, 격리성, 효율성을 높이기 위해 특별히 구현된 연구들입니다.
Baumgärtner et al.(2019) [66]은 WebAssembly와 번들 프로토콜 7 드래프트 구현을 활용한 브라우저용 장애 내성 네트워킹(DTN) 시스템을 제시했습니다 [67]. Narayan et al.(2020) [68]은 서드 파티 라이브러리를 샌드박싱하기 위한 세밀한 격리를 구현하는 새로운 프레임워크 RLBox를 정의했습니다. 이 프레임워크는 Firefox 프로덕션에 통합되어 libGraphite 글꼴 셰이핑 라이브러리를 샌드박싱합니다. Chen et al.(2023) [69]은 스트리밍의 디지털 권리 관리(DRM)를 위한 새로운 접근 방식을 제안했습니다. 이 연구는 사용자가 플러그 앤 플레이 방식으로 비디오를 쉽게 가져올 수 있도록 하며, 서버와의 상호작용을 최소화하여 암호 해독 효율성을 높입니다.
브라우저에서 Jang et al.(2022) [70]는 WebAssembly를 활용하여 브라우저 엔진 내부에서 애플리케이션을 에뮬레이션하기 위한 분산 공개 협업 퍼징 시스템을 구현했습니다.
5.3.2 암호화, 신뢰 실행 환경 및 프라이버시
여러 연구들은 암호화 기술, 신뢰 실행 환경(TEE), 프라이버시 보호 방법을 통해 데이터 무결성과 기밀성을 보호하는 것을 목표로 합니다. 이러한 접근 방식은 특정 도메인에 맞춰져 있으며, 하드웨어, 임베디드 시스템, 브라우저에 구현될 수 있습니다. Sun et al.(2020) [71]은 WebAssembly와 Web Cryptography API를 활용하여 클라이언트 측 암호화 저장 시스템을 설계하여 이종 플랫폼 간 데이터를 저장하고 공유할 수 있도록 했습니다. Attrapadung et al.(2018) [72]은 WebAssembly를 사용하여 소수 차수 쌍선형 군 내에서 효율적인 이중 레벨 준동형 공개키 암호화를 구현했습니다. Seo et al.(2023) [73]은 WebAssembly를 사용하여 Crystals-Kyber 포스트 양자 키 캡슐화 메커니즘의 이식 가능하고 효율적인 구현을 제안했습니다 [74]. Zhao et al.(2023) [75]는 재사용 가능하고 빠르며 안전한 엔클레이브를 구축하는 새로운 접근 방식을 정의했습니다. 그들은 엔클레이브의 빠른 재설정과 강력한 보안을 가능하게 하기 위해 엔클레이브 스냅샷 및 되감기, 중첩된 증명, 다중 레이어 엔클레이브 내부 구획화라는 세 가지 기술을 도입했습니다. WebAssembly는 클라우드 엣지 컴퓨팅을 위한 퍼블리시-구독 환경을 구현하는 데 사용됩니다. Almstedt et al.(2023) [76]과 Ménétrey et al.(2024) [77]은 인텔 SGX에서 실행되는 신뢰할 수 있고 분산된 통신을 위한 새로운 퍼블리시-구독 미들웨어를 설계했습니다. Qiang et al.(2018) [78]은 WebAssembly의 샌드박스 속성을 Intel SGX 엔클레이브와 결합하여 양방향 샌드박스를 개발했습니다. 이 접근 방식은 클라우드 제공자가 제기하는 잠재적 위협으로부터 민감한 데이터를 보호하고, 악의적인 사용자가 시작한 잠재적 공격으로부터 호스트 런타임을 보호하는 이중 보호를 제공합니다. 다른 연구들은 WebAssembly가 성능이 뛰어나고, 메모리 안전하며 이식 가능한 클라이언트 측 해싱 라이브러리를 구현하는 데 사용될 수 있음을 보여줍니다 (Riera et al.(2023)) [79], 또는 완전한 클라이언트 측 저장 플랫폼으로 구현될 수 있습니다 (Sun et al.(2022)) [71].
5.3.3 신원 및 액세스 관리
다른 Intel SGX와 WebAssembly의 통합 예시는 Goltzsche et al.(2019) [80]이 제안한 AccTEE 프레임워크입니다. 이 연구에서 저자들은 코드와 데이터의 기밀성과 무결성을 보존하면서 리소스 회계를 위한 세밀한 권한을 구현하는 프레임워크를 제시했습니다. 또한 Zhang et al.(2021) [81]은 개인 정보 보호를 위한 단일 로그인(SSO) 작업의 설정 및 구성을 가능하게 하는 휴대 가능하고 "제로 구성" 모듈인 EL PASSO를 제안했습니다.
5.3.4 클라우드, 클라우드 엣지 컴퓨팅 및 IoT
클라우드 및 클라우드 엣지 컴퓨팅은 WebAssembly가 채택된 일반적인 사용 사례입니다 [82]. Edgedancer [59]는 이식 가능하고, 제공자 독립적이며, 안전한 엣지 서비스 마이그레이션을 지원하는 플랫폼입니다. Ménétrey et al.(2022) [83]는 TEE를 포함한 WebAssembly가 클라우드 엣지 연속성을 구현하는 유망한 조합이라고 예측했습니다 [84].
Sun et al.(2022) [71]는 브라우저 도메인을 안전한 클라우드 저장 환경을 구현하기 위한 플랫폼으로 중점적으로 다룹니다. 이 주제는 Song et al.(2023) [85]이 속성 기반 프록시 재암호화(COAB-PRE)라는 새로운 프리미티브를 실현하고 WebAssembly의 이종 플랫폼 기능을 결합하여 크로스 플랫폼 보안 저장 아키텍처를 제공한 연구에서도 다루어졌습니다. WebAssembly는 여러 보안 이점을 제공하지만, 사물 인터넷(IoT) 및 엣지 장치와 같은 자원이 제한된 환경에서 채택될 때 성능 오버헤드가 문제될 수 있습니다. Wen et al.(2020) [86]은 Rust와 WebAssembly를 통합하여 IoT 애플리케이션을 더 효율적이고 안전하게 만드는 새로운 운영 체제를 정의함으로써 이 문제를 해결했습니다. 유사한 접근 방식은 Li와 Sato(2023) [87]에 의해 제안되었으며, 이들은 WebAssembly와 Rust의 조합을 통해 격리성, 보안성, 사용자 정의 가능성에 중점을 둔 커널을 구현했습니다.
5.3.5 얼굴 인식 시스템
WebAssembly를 사용하여 얼굴 인식 시스템을 구현하는 초기 작업이 수행되었습니다. 실제로 WebAssembly는 이미지를 보호하는 클라이언트 측 솔루션을 보장하며, 외부 서비스 도입 비용을 줄일 수 있습니다. Pillay et al.(2019) [88]은 91.67%의 얼굴 인식률을 달성할 수 있는 실시간 브라우저 기반 애플리케이션을 제공했습니다. Martín Manso et al.(2021) [89]은 얼굴 감지를 위해 JavaScript(CPU), WebGL, WebAssembly를 비교했으며, WebAssembly가 감지 정확도와 시간 오버헤드 측면에서 좋은 균형을 이루고 있다고 결론지었습니다.
5.4 공격 시나리오
다른 연구 분야는 WebAssembly 프로그램에 대한 공격을 수행하는 혁신적인 접근 방식에 중점을 둡니다. 대부분의 논문은 두 가지 주요 범주로 나뉩니다:
- 사이드 채널 공격: 이 연구들은 WebAssembly를 통해 민감한 키를 노출하거나 비밀 채널을 구축하는 방법을 설명합니다 [90, 91, 92, 93].
- 악성 코드 탐지 회피 기법: WebAssembly를 사용하여 악성 코드 탐지 시스템을 우회할 수 있는 방법을 설명하는 연구입니다 [94, 95, 96, 97].
표 8: WebAssembly에서 공격 예시를 설명하는 연구
연구 | 구현된 공격 유형 |
Genkin et al.(2018) [90] | 사이드 채널 공격 |
Easdon et al.(2022) [91] | 사이드 채널 공격 |
Rokicki et al.(2022) [92] | 사이드 채널 공격 |
Katzman et al.(2023) [93] | 사이드 채널 공격(캐시 기반) |
Cabrera-Arteaga et al.(2023) [94] | 악성 코드 탐지 회피 |
Romano et al.(2022) [95] | 악성 코드 탐지 회피 |
Cao et al.(2023) [96] | 악성 코드 탐지 회피 |
Loose et al.(2023) [97] | 악성 코드 탐지 회피 |
Oz et al.(2023) [98] | 랜섬웨어 공격 |
Oz et al.(2023) [98]는 WebAssembly를 활용하여 랜섬웨어 공격을 구현할 수 있음을 보여주는 연구를 수행했습니다. 표 8은 위 정보를 요약한 것입니다.
5.4.1 사이드 채널 공격
Genkin et al.(2018) [90]은 WebAssembly를 사용하여 CPU 캐시 충돌을 유도하고 다른 프로그램의 메모리 액세스에서 민감한 데이터를 추출할 수 있음을 보여주었습니다. 그들은 이 기술이 유명한 암호화 라이브러리에서 민감한 키를 추출할 수 있음을 시연했습니다. Katzman et al.(2023) [93]의 연구에서는 캐시 기반 공격을 설명했으며, 저자들은 트랜지언트 실행이 캐시 공격의 효과를 높일 수 있음을 결론지었습니다.
Easdon et al.(2022) [91]는 WebAssembly 기능을 활용하여 마이크로아키텍처 공격을 프로토타이핑하는 새로운 기술을 시연했습니다. 그들은 libtea 및 SCFirefox라는 두 개의 오픈 소스 프레임워크를 구현하고, Foreshadow [100] 및 Load Value Injection(LVI) [101] 공격을 실행하기 위한 개념 증명을 개발했습니다.
Rokicki et al.(2022) [92]는 브라우저 환경 내에서 최초로 수행된 포트 충돌 사이드 채널 공격을 소개했습니다. 그들의 연구는 특정 WebAssembly 명령어가 포트 충돌 공격을 유도할 수 있으며, 이를 통해 동일한 CPU 코어에서 실행 중인 병렬 프로세스의 민감한 데이터를 추출할 수 있음을 보여주었습니다.
5.4.2 악성 코드 탐지 회피
다른 두 연구는 WebAssembly 바이너리에서 악성 코드 탐지를 회피하는 혁신적인 기법을 제안합니다. Cabrera-Arteaga et al.(2023) [94]는 WebAssembly 바이너리 다양화가 안티바이러스 시스템의 탐지를 우회할 수 있는 잠재력을 분석했습니다. 한편, Loose et al.(2023) [97]는 바이너리의 명령어 스트림에 적대적 페이로드를 삽입하여 악성 코드 탐지 시스템을 우회하는 새로운 접근 방식을 제안했습니다.
추가적으로, Romano et al.(2022) [95]는 특정 JavaScript 명령어를 WebAssembly로 변환하여 악성 코드 탐지 시스템을 회피할 수 있음을 입증했습니다. Cao et al.(2023) [96]는 다양한 목적으로 사용할 수 있는 정적 바이너리 재작성 프레임워크를 개발했으며, 이 프레임워크는 난독화를 위한 목적으로도 사용할 수 있습니다. 이 프레임워크는 주로 악성 코드 탐지 시스템 회피에 초점을 맞추지 않았지만, 그 목적에 맞게 조정될 수 있으며, 취약점 패치 또는 바이너리 계측에도 사용할 수 있습니다.
5.5 공격 탐지 솔루션
이 연구들은 WebAssembly 프로그램에서 주로 암호화폐 채굴 공격(cryptojacking)을 탐지하는 데 중점을 둡니다. 표 9에 나와 있듯이, 현재 연구는 WebAssembly 기술로 촉진된 암호화폐 채굴 활동을 탐지하는 데 주로 집중하고 있습니다.
표 9: WebAssembly 애플리케이션에 대한 공격 탐지에 관한 연구
연구 | 탐지 방법 | 탐지된 공격 유형 |
Konoth et al.(2018) [102] | WebAssembly 악성 바이너리에 대한 정적 분석을 통해 발견된 세 가지 접근 방식을 기반으로 한 런타임 탐지 | 암호화폐 채굴 |
Wang et al.(2018) [103] | 런타임 중 인라인 스크립트를 통해 실행을 모니터링 | 암호화폐 채굴 |
Rodriguez와 Possega(2018) [104] | WebAssembly 및 JavaScript API를 분석하고, Support Vector Machine(SVM)을 학습시킴. 브라우저 확장 프로그램으로 솔루션 배포 가능성 제시 | 암호화폐 채굴 |
Kharraz et al.(2019) [105] | Support Vector Machine(SVM) 분류기를 사용 | 암호화폐 채굴 |
Bian et al.(2020) [106] | 런타임에서 탐지 | 암호화폐 채굴 |
Kelton et al.(2020) [107] | 런타임에서 Support Vector Machine(SVM) 분류기를 사용 | 암호화폐 채굴 |
Mazaheri et al.(2020) [108] | 웹 페이지의 시간 기반 사이드 채널 공격 여부를 나타내는 특징을 분석하는 정적 분석 | 사이드 채널 공격 |
Romano et al.(2020) [109] | "표준" WebAssembly 형식으로 바이너리를 재구성하고, 생성된 intra-procedural 및 inter-procedural 제어 흐름 그래프(CFG)를 분석하는 정적 분석 | 암호화폐 채굴 |
Yu et al.(2020) [110] | 머신러닝 및 런타임 탐지 시스템을 사용한 정적 분석. 탐지 및 차단 기능 모두 제공 | 암호화폐 채굴 |
Naseem et al.(2021) [111] | 대규모 악성 및 정상 WebAssembly 바이너리 데이터 세트를 사용하여 학습된 Convolutional Neural Network(CNN) 모델을 사용하는 런타임 탐지 | 암호화폐 채굴 |
Tommasi et al.(2022) [112] | Support Vector Machine(SVM) 분류기를 기반으로 한 브라우저 확장 프로그램을 사용한 런타임 탐지 | 암호화폐 채굴 |
Breitfelder et al.(2023) [113] | 호출, 제어, 데이터 흐름 그래프를 추가 분석을 위해 캡처할 수 있는 WebAssembly 정적 분석. 탐지 기능은 논의된 사용 사례 중 하나임 | 암호화폐 채굴 |
5.6 보안 강화
여러 연구들은 WebAssembly 구성 요소를 확장하거나 새로운 시스템을 통합하여 보안 수준을 높이고 있습니다. 일부 저자들은 WebAssembly 언어의 의미를 확장하여 다양한 위협으로부터 보호하는 방법을 제안합니다. 예를 들어, Watt et al.(2019) [114]는 시간 기반 사이드 채널 공격으로부터 보호하기 위해 암호화 라이브러리를 작성하는 타입 기반 보안 언어 CT-Wasm을 제안합니다. 비슷하게, Michael et al.(2023) [115]은 MSWasm을 도입하여 메모리 안전하지 않은 취약점을 해결하는 WebAssembly 의미를 확장하여 WebAssembly 프로그램 메모리를 보호하는 데 초점을 맞춥니다. 그들은 세그먼트 메모리라는 새로운 메모리 영역과 상호작용하는 새로운 명령어를 도입했습니다. 또한, Geller et al.(2024) [116]은 WebAssembly 의미를 확장하여 프로그램 값에 대한 안전 속성을 보장하는 인덱스된 타입을 정의했습니다 [117]. 메모리 안전을 보장하기 위한 또 다른 언어 확장은 Zhang et al.(2023) [118]에 의해 제안되었으며, 그들은 프로그램에서 카나리(canaries)를 정의할 수 있도록 했습니다.
여러 연구들은 WebAssembly 컴파일러를 수정하여 보안 속성을 공식적으로 검증하거나 [119, 120], 임베디드 시스템에서 공격 표면을 줄이는 방법을 제안합니다 [121, 122]. 다른 연구들은 WebAssembly 런타임 환경을 개선하여 격리성을 증가시키고, 실행 중 메모리 공격을 방지하는 신뢰 실행 환경(TEE)을 만드는 데 중점을 둡니다.
WebAssembly 프로그램의 실행을 보호하기 위해 여러 연구자들이 추가 메커니즘을 설계했습니다. 예를 들어, Sun et al.(2019) [123]은 허가되지 않은 웹사이트에서의 코드 실행을 방지하기 위해 자가 검증 메커니즘을 구현하는 코드 보호 기술 SELWasm을 제안했으며, 코드 기밀성을 보장하기 위한 "암호화 및 복호화" 접근 방식도 함께 제안했습니다. 비슷하게, Brandl et al.(2023) [124]은 프로시저 간 제어 및 데이터 흐름 정보와 같은 복잡한 분석을 수행할 수 있는 새로운 WebAssembly 인터프리터를 제시했습니다. 이 연구는 향후 정적 보안 분석 접근 방식의 기초로 간주될 수 있습니다.
또한, Pop et al.(2022) [125]는 WASMI [126]를 확장하여 포팅 가능한 엔클레이브 서비스를 구현하기 위한 일시 중단, 직렬화, 역직렬화, 재개 원시 명령어를 추가한 인터프리터를 제안했습니다.
다른 연구들은 WebAssembly 바이너리를 난독화하여 리버스 엔지니어링으로부터의 보호를 강화하거나, WebAssembly의 악성 코드 탐지 시스템 회피 기능을 강조하기 위한 새로운 접근 방식을 탐구합니다.
또 다른 연구들은 컴파일 후 프로그램 검증을 도입합니다. Watt(2018) [127]은 Isabelle [128]이라는 정리 증명기를 사용하여 WebAssembly 사양을 기계화하고 검증하며, WebAssembly에 대해 검증된 타입 체커와 인터프리터를 구현하는 두 가지 데모를 제시했습니다. 이 연구는 Watt et al.(2023) [129]에 의해 확장되어, Isabelle/HOL [130]로 작성된 WebAssembly 인터프리터를 정의하여 Wasmtime 인터프리터 [131]를 검증합니다. Johnson et al.(2021) [132]은 WebAssembly로 컴파일된 네이티브 x86-64 바이너리에 대한 정적 오프라인 검증기 VeriWasm을 소개했습니다. 이 검증기는 메모리 액세스 경계, 제어 흐름, 스택 사용을 검사하여 바이너리에서 소프트웨어 결함 격리(SFI) [133] 요구 사항을 충족시키는지 확인합니다. 또 다른 연구 분야는 WebAssembly 바이너리에서 악성 코드 탐지를 개선하는 데 초점을 맞춥니다. Xia et al.(2024) [134]는 JavaScript-WebAssembly 다중 언어 악성 코드(JWMM)가 등장하면서 안티바이러스 솔루션의 효과가 감소하는 문제를 강조했습니다. 저자들은 WebAssembly 바이너리를 고수준 구조로 재구성하여 안티바이러스 탐지 능력을 향상시키기 위한 새로운 접근 방식을 도입했습니다.
Watt et al.(2021) [135]은 WebAssembly 의미를 확장하여 WasmCert-Isabelle 및 WasmCert-Coq이라는 두 가지 정리 증명기를 제공했습니다.
5.6.1 WebAssembly를 간접적으로 개선하는 연구
일부 연구들은 WebAssembly 구성 요소를 직접 확장하지 않지만, 다른 시스템을 개선하여 보안 문제를 해결합니다. 예를 들어, Schrammel et al.(2020) [136]은 JavaScript(JS) V8 엔진을 개선하여 간접적으로 WebAssembly 보안을 향상시킵니다. 저자들은 JS 엔진이 일부 JavaScript 코드를 WebAssembly로 컴파일하며, 컴파일된 코드에 대한 여러 잠재적 공격을 식별합니다. 그들은 현대 CPU를 사용하여 메모리 페이지에 대한 도메인 기반 접근 제어를 시행하는 격리 메커니즘을 제공하는 JS 엔진 확장을 제안합니다. Vassena et al.(2021) [137]은 WebAssembly에서 Cranelift [138]라는 x86 컴파일러를 확장하여 암호화 코드에서 추측적 정보 누출(speculative leaks)을 자동으로 제거하는 Blade라는 접근 방식을 도입합니다. Song et al.(2023) [139]은 신뢰할 수 있는 JavaScript 메모리에서 선형 메모리의 메타데이터를 그림자로 관리함으로써 힙 메모리 손상 공격을 차단하는 흥미로운 방법을 제안합니다. 그들은 WebAssembly 프로그램이 선형 메모리의 메타데이터를 그림자 관리하고 이를 검증할 수 있는 JavaScript API를 제공합니다.
5.7 취약점 발견
여러 연구들은 WebAssembly 바이너리에서 취약점을 발견하는 데 중점을 둡니다. 표 10과 표 11은 이러한 노력들을 두 가지 그룹으로 나누어 분류합니다: (i) 정적 보안 분석을 활용하는 연구와 (ii) 동적 분석을 제안하는 연구입니다. 각 접근 방식은 다양한 기술을 실험하여 여러 유형의 취약점을 발견할 수 있습니다.
많은 연구들은 스마트 계약에서 문제를 식별하는 데 중점을 둡니다. 이는 WebAssembly가 블록체인 도메인에서 상당히 채택되고 있음을 명확히 보여줍니다.
표 10: 정적 분석 접근 방식을 제안하는 취약점 발견 연구
연구 | 정적 분석 접근 방식 | 발견된 취약점 |
Quan et al.(2019) [140] | 제어 흐름 그래프(Control Graph Flow) 분석 | 가짜 EOS 전송, 가짜 EOS 알림 |
Yang et al.(2020) [141] | 상징적 의미 그래프(Symbolic Semantic Graph) | 정수 오버플로우, 의사 난수 생성기, 안전하지 않은 메시지 호출 |
Li et al.(2022) [142] | 문맥 민감 데이터 흐름 분석(Context-sensitive data flow analysis) | 가짜 EOS 전송, 위조된 전송 알림, 블록 정보 의존성 |
Brito et al.(2022) [143] | 코드 속성 그래프(Code property graph) | 버퍼 오버플로우, 사용 후 해제(use after free), 이중 해제(double free), 위험한 함수 사용, 형식 문자열 취약점 |
Tu et al.(2023) [144] | 상태 기계 표현(State Machine Representation) | 롤백, 권한 확인 누락, 정수 오버플로우 |
표 11: 동적 분석 접근 방식을 제안하는 취약점 발견 연구
연구 | 동적 분석 접근 방식 | 탐지된 취약점 |
Huang et al.(2021) [145] | 블랙 박스 퍼저(Black-box fuzzer) | 블록 정보 의존성, 위조된 전송 알림, 가짜 EOS 전송 |
Jiang et al.(2021) [146] | 상징적 실행(Symbolic execution) | 탐욕적 스마트 계약(Greedy), 위험한 DelegateCall, 블록 정보 의존성, 재진입, 예외 처리 오류 |
He et al.(2021) [147] | 상징적 실행(Symbolic execution) | 가짜 EOS, 가짜 영수증, 롤백, 권한 확인 누락 |
Daniel Lehmann et al.(2021) [148] | 퍼징(Fuzzing) | 주로 버퍼 오버플로우 조건과 관련된 바이너리 프로그램 충돌 |
Marques et al.(2022) [149] | 콘콜릭 실행(Concolic execution) | 명시되지 않음 |
Yang et al.(2022) [150] | 추적 및 제어-데이터 흐름 분석(Tracing and control-data flow) | 접근 제어 취약점 |
Khan et al.(2023) [151] | 퍼징(Fuzzing) | 데이터 경합, 널 포인터 참조, 경계 초과 액세스, SGX 엔클레이브 애플리케이션에서 0으로 나누기 오류 |
Jin et al.(2023) [152] | 퍼징(Fuzzing) | 오버플로우, 언더플로우, 임의 값 전송(예: 재진입), 자살성(suicidal), 호출 주입(call injection) |
Haßler et al.(2022) [153] | 커버리지 기반 퍼징(Coverage-guided fuzzing) | 바이너리 프로그램 충돌 |
Chen et al.(2022) [154] | 콘콜릭 실행(Concolic execution) | 가짜 EOS 전송, 가짜 알림, 권한 확인 누락, 블록 정보 의존성, 롤백 취약점 |
Zhou et al.(2023) [155] | 바이트코드 계측(Bytecode instrumentation), 런타임 검증(Run-time validation), 그레이 박스 퍼징(Grey-box fuzzing) | 정수 및 스택 오버플로우 |
위에서 언급한 연구들의 비교 분석을 통해 제안된 방법들의 효과성을 비교할 수 있는 표준화된 접근 방식이 없음을 알 수 있습니다. 일부 연구들은 정수 오버플로우와 스택 기반 오버플로우와 같은 저수준 취약점을 식별하는 데 중점을 두는 반면, 다른 연구들은 스마트 계약 도메인에서 특정 취약점을 타겟으로 합니다. 몇몇 저자들은 실제 애플리케이션을 평가에 사용했으며, 다른 연구들은 잘 알려져 있지만 이질적인 데이터 세트를 사용했습니다. 실제 애플리케이션을 평가하는 것은 보안 스캐너가 새로운 취약점을 발견할 수 있는 능력을 효과적으로 입증하는 데 중요한 역할을 하지만, 이 접근 방식은 테스트 중인 애플리케이션에서 정확한 취약점 수가 알려져 있지 않기 때문에 거짓 긍정 및 거짓 부정 비율과 같은 성능 지표를 제공하지 못합니다. 따라서, 각 저자는 다른 성능 지표를 정의하여 제안된 방법들을 비교하는 것이 어려워집니다.
이 평가 지표의 가변성은 취약점 발견 접근 방식에서 공통된 문제이며 [156], 우리는 미래 연구에서 이 열린 문제를 해결할 것을 권장합니다.
5.8 기타 연구들
많은 연구들은 WebAssembly 외의 측면에 중점을 두고 있지만, 이러한 연구들은 여전히 WebAssembly 도메인의 보안을 강화하기 위한 향후 노력에 귀중한 통찰을 제공할 수 있습니다.
5.8.1 예비 연구
일부 예비 연구들은 혁신적인 보안 향상을 위한 기초가 될 수 있는 유망한 결과를 제공합니다. Abbadini et al.(2023) [157]는 eBPF 기능을 WebAssembly와 결합하여 기존 런타임에서 호스트 격리 보안을 강화하는 방법을 설계했습니다. Narayan et al.(2021) [158]은 WebAssembly의 샌드박싱 기능을 활용하여 안전하지 않은 C 코드를 안전하게 실행하는 방법에 관한 튜토리얼을 제공합니다. Stievenart와 De Roover(2021) [54]는 WebAssembly를 위한 최초의 정적 분석 도구 중 하나인 "Wassail"을 소개했습니다. 이 기술은 호출 그래프, 제어 흐름 그래프, 데이터 흐름 분석과 같은 여러 정적 분석을 가능하게 합니다. Cabrera et al.(2021) [55]는 WebAssembly를 위한 코드 다양화 프레임워크의 첫 번째 버전을 제시했으며, 이는 더 최근의 연구에서 확장되었습니다 [159].
Bhansali et al.(2022) [160]는 WebAssembly 바이너리에 난독화 기술을 적용하는 것에 대한 예비 개요를 제공하며, 특정 난독화 접근 방식이 MINOS 암호화폐 채굴 탐지기(Naseem et al.(2021)) [111]를 우회할 수 있음을 입증했습니다.
Zheng et al.(2023) [161]은 WebAssembly 코드에서 메모리 버그와 정수 오버플로우를 탐지할 수 있는 동적 프로그램 분석 소프트웨어 프로토타입을 제시했으며, 이는 이 도메인에서 취약점 발견을 조사하는 데 중요한 참조 자료로 작용합니다.
5.8.2 취약점 발견 접근 방식에 관한 연구
많은 연구들이 WebAssembly 코드와 바이너리 구조를 검사하는 혁신적인 접근 방식을 조사하며, 이는 향후 취약점 발견 연구의 기초를 마련합니다. William Fu et al.(2018) [162]와 Szanto et al.(2018) [163]는 WebAssembly에서 태인트 추적(taint tracking) [164]에 대한 종합적인 개요를 제공합니다. 두 연구 모두 WebAssembly 바이너리 내에서 데이터 흐름을 추적하는 데 유망한 결과를 보였지만, 상세한 보안 평가를 제공하지는 않았습니다. 따라서 실제 시나리오에서 그들의 효과를 평가하기 위한 추가 연구가 필요합니다.
Stievenart et al.(2022) [165]와 Stiévenart et al.(2023) [166]은 WebAssembly 바이너리를 슬라이싱(slicing)을 통해 최소화하는 방법을 도입했습니다. 이러한 접근 방식은 WebAssembly 바이너리의 동적 및 종속성 분석을 최적화하는 데 유용합니다.
Cabrera-Arteaga et al.(2024) [159]는 WebAssembly 바이너리를 원래 기능을 변경하지 않고 자동으로 변형하는 방법을 시연했습니다. 이 접근 방식은 WebAssembly 컴파일러를 퍼징(fuzzing)하는 데 효과적입니다.
다른 연구들은 정적 분석 접근 방식을 실현하는 데 기여할 수 있습니다. 주목할 만한 예로는 Watt et al.(2019) [167]이 제안한 Wasm Logic(WebAssembly의 일차 명령어 논리), 그리고 He et al.(2023) [168]의 Eunomia(WebAssembly용 상징적 실행 엔진)가 있습니다.
Stievenart et al.(2020) [169]는 합성 정보 흐름을 기반으로 한 WebAssembly 프로그램의 정적 분석에 기반한 새로운 절차를 제시했습니다. 이 방법은 함수 동작의 효율적이고 정확한 요약을 가능하게 하며, 정보 흐름 위반 및 잠재적 보안 침해를 탐지하는 데 기여할 수 있습니다.
Lehmann et al.(2019) [170]는 Wasabi라는 프레임워크를 사용하여 WebAssembly 프로그램을 동적 분석하여 런타임 정보를 수집하고, 메모리 액세스 및 제어 흐름과 같은 동적 동작을 탐지할 수 있도록 기여했습니다.
Kotenko et al.(2023) [171]는 전력 에너지 부문에서 안전한 애플리케이션을 구현하기 위한 실용적인 지침을 고안했습니다. WebAssembly는 단순히 언급되었지만, 이 연구는 향후 연구를 위한 기반을 마련할 수 있습니다.
Namjoshi et al.(2021) [172]는 독립적인 증명 검증기에 맞춰 프로그램의 정확성을 확인하는 흥미로운 컴파일러 확장을 정의했습니다. 제안된 기여는 컴파일된 프로그램의 최적화 과정에서 발생한 버그를 밝혀내는 것과 관련이 있지만, 보안 검증도 포함하도록 쉽게 확장할 수 있습니다.
Zhou et al.(2023) [173]는 WebAssembly 런타임에서 버그를 식별하기 위해 WADIFF라는 차이 테스트 프레임워크를 제안했으며, 이는 보안 버그를 찾는 데 특화될 수 있습니다. 코드 디버깅은 취약점을 수동으로 발견하는 효과적인 방법으로 남아 있습니다 [174]. Lauwaerts et al.(2022) [175]는 WARDuino WebAssembly 마이크로컨트롤러 가상 머신 [176]을 확장하여 디버깅 기능을 활성화했습니다. 향후 연구는 WebAssembly로 설계된 임베디드 시스템에서 취약점을 찾기 위한 보안 방법론을 제안할 수 있습니다.
5.8.3 다른 연구와의 비교
다른 연구들은 WebAssembly 보안을 다른 기술과 비교합니다. Dejaeghere et al.(2023) [177]는 WebAssembly의 보안 기능을 eBPF와 비교합니다. eBPF는 커널 내부에서 신뢰할 수 없는 사용자 정의 확장을 안전하게 실행할 수 있게 해주는 리눅스 서브시스템입니다 [178]. 그들은 이 두 기술에 대해 다른 위협 모델이 정의될 수 있으며, WebAssembly의 설계가 성능보다는 보안에 더 중점을 두고 있음을 강조합니다. WebAssembly는 eBPF와 달리 안전하지 않은 코드의 실행을 허용하지만, 구현된 헬퍼 시스템 라이브러리의 수를 제한함으로써 보안 위험 및 악용 가능성을 줄입니다.
Pham et al.(2023) [179]는 성능, 유지 관리성, 보안을 포함한 여러 비기능적 요구 사항을 평가합니다. 그들은 WebAssembly가 IoT 애플리케이션에서 Docker 컨테이너의 실행 가능한 대안임을 입증합니다. 그러나 보안 평가가 충분하지 않아, 이들 기술 간의 보안 차이를 분석하는 추가 연구가 필요함을 시사합니다.
Bastys et al.(2022) [180]는 WebAssembly에서 일반 목적 정보 흐름 제어를 위한 SecWasm 프레임워크를 제시합니다. SecWasm은 WebAssembly 프로그램에 대해 여러 관련 보안 제어를 수행하도록 도구화될 수 있습니다. 논문은 접근 방식에 대한 종합적인 설명을 제공하지만, 평가가 부족합니다. 향후 연구는 이 유망한 접근 방식을 더욱 탐구하고 분석할 수 있습니다.
커널 격리 영역에서는 Peng et al.(2023) [181]이 성능 오버헤드를 최소화하기 위해 효율적인 '암묵적' 컨텍스트 전환을 특징으로 하는 향상된 격리 기능을 제공하는 새로운 커널 컨텍스트 격리 시스템을 도입합니다. 이 논문은 격리 이점을 증명하기 위해 시스템을 WebAssembly와 비교했지만, 추가 평가가 이해를 돕는 데 기여할 수 있습니다.
6. 논의
이 섹션에서는 조사 결과를 논의하고 분석된 연구들의 특징을 요약합니다.
우리 연구에서는 총 121편의 연구를 검토했습니다. 이 중 96편(85.85%)은 7개의 범주로 분류되었습니다. 나머지 25편(14.15%)은 WebAssembly 보안 분야에 중대한 기여를 하지는 않았지만, 관련 연구 주제에서 새로운 연구 경로를 위한 중요한 참고 자료로 간주됩니다.
그림 1은 각 범주의 연구 비율을 보여줍니다. 볼 수 있듯이, 대부분의 기여(28.9%)는 WebAssembly 보안을 강화하는 것을 목표로 하고 있습니다. 또 다른 큰 비중의 연구들(21.6%)은 보안 기반 사용 사례를 구현하기 위해 WebAssembly의 기능을 활용하고 있습니다. 그 외의 중요한 연구 영역은 취약점 발견(16.5%)과 공격 탐지(12.4%)입니다.
그림 1: WebAssembly 보안 연구 논문 분류
6.1 WebAssembly 보안
WebAssembly의 보안을 분석하거나 경험적 연구를 통해 조사하거나 공격 시나리오를 제시한 연구들은 다음과 같은 주요 결론을 도출했습니다:
- WebAssembly는 더 나은 격리와 보안을 제공하도록 설계되었음에도 불구하고, 언어적 의미 및 컴파일러에서 보안 보호 메커니즘의 부족으로 인해 C와 같은 저수준 언어로 개발된 안전하지 않은 프로그램을 WebAssembly로 포팅할 때 메모리 기반 공격의 위험이 증가합니다.
- 실제 애플리케이션에서 메모리 안전하지 않은 언어로부터 파생된 많은 WebAssembly 바이너리가 존재하기 때문에 이 문제가 더욱 악화됩니다.
- WebAssembly는 민감한 데이터를 격리하고 보호해야 하지만, 여러 연구는 캐시 분석이나 포트 충돌과 같은 특정 기술을 통해 민감한 데이터를 추출할 수 있음을 확인했습니다.
- 실제로 많은 WebAssembly 바이너리가 난독화되어 있으며, 이는 WebAssembly 역공학 및 디컴파일에 대한 연구가 더 확장될 필요가 있음을 시사합니다.
- WebAssembly에 적용된 난독화는 악성 코드 탐지 시스템의 성능 저하를 초래했으며, 이는 WebAssembly 바이너리 역공학 연구가 필요함을 강조합니다.
- WebAssembly 기반 암호화폐 채굴 활동의 중요성은 논쟁의 여지가 있습니다. 일부 연구는 이것이 WebAssembly의 주요 용도라고 강조하지만, 다른 연구는 분석된 바이너리 중 1% 미만이 암호화폐 채굴과 관련이 있다고 주장합니다.
6.2 WebAssembly에서의 공격 탐지 및 취약점 발견
탐지 노력은 주로 암호화폐 채굴 공격에 중점을 두고 있으며, 취약점 발견 접근법은 주로 스마트 계약의 취약점을 다룹니다. 결과적으로 스마트 계약 환경에서 WebAssembly 애플리케이션을 분석하는 데 많은 관심이 집중되어 있습니다. 섹션 2.1.3에서 언급했듯이, 웹 애플리케이션, 데이터 시각화, 게임과 같은 다른 도메인에서도 관련 사용 사례가 존재합니다. 향후 연구에서는 이러한 다른 도메인에서 WebAssembly의 보안 영향을 분석하고 보안 문제를 해결하기 위한 접근 방안을 제안해야 합니다.
또 다른 중요한 문제는 사용된 벤치마크와 성능 지표의 이질성입니다. 일부 저자들은 단순히 정확도만을 분석하며, 실험 및 평가에 사용되는 공통 데이터 세트는 없습니다.
Alexa 상위 백만 웹사이트 벤치마크 [61]는 실제 WebAssembly 사례를 나타내는 "기준 진리"로 광범위하게 사용되었습니다. 그러나 이 출처는 2022년에 폐기되어 이후 연구에서는 더 이상 사용할 수 없습니다. 우리는 연구자들이 추가 출처를 포함하여 더 신뢰할 수 있는 기준 진리 벤치마크를 만들기를 권장합니다.
6.3 사이버보안 사용 사례에서의 WebAssembly에 대한 관심
그림 2는 각 보안 관련 도메인별로 발표된 연구 수와 WebAssembly 채택 이유를 보여줍니다. 볼 수 있듯이, WebAssembly는 다양한 애플리케이션 유형에 걸쳐 사용되며, 특히 클라우드와 암호화 도메인에서 중요하게 다루어집니다. WebAssembly는 주로 성능, 격리성, 이식성 때문에 선택됩니다. 일부 연구는 메모리 안전성을 보장하기 위해 WebAssembly를 채택했다고 강조하기도 합니다. 그러나 앞서 언급한 바와 같이, 여러 연구는 WebAssembly를 격리 및 메모리 안전을 위해 사용하는 데 보안 격차가 있음을 확인하며, 이러한 애플리케이션의 보안에 대한 추가 조사의 필요성을 강조합니다.
그림 2: WebAssembly 사용 사례
6.4 WebAssembly 보안 강화
그림 3은 WebAssembly의 특정 구성 요소를 확장하여 보안 속성을 향상시키는 연구의 수를 보여주는 히트맵을 나타냅니다.
그림 3: 보안 향상을 위한 연구의 히트맵
이 히트맵에서 알 수 있듯이 대부분의 연구는 메모리 작업에 중점을 두고 있으며, 컴파일러 및 런타임 수정과 관련이 있습니다. 테스트 가능성은 형식적 검증 방법을 통해 분석되었습니다. 실제로, 많은 개선이 인터프리터를 통해 이루어질 수 있는데, 이는 런타임 및 컴파일러 변경에 비해 영향이 적어 향후 연구의 잠재적 방향을 제공합니다. 또한, 기밀성 및 코드 서명도 추가적으로 탐구할 필요가 있습니다.
6.5 결과의 가용성
각 보안 범주에서, 우리는 관련 연구의 저자들이 그들이 수행한 실험에 사용된 소스 코드를 공개했는지 여부를 분석했습니다. 이 분석의 결과는 표 12에 요약되어 있습니다. 대신 부록의 표 13에는 우리가 확인할 수 있었던 공개된 저장소의 상세 목록이 나와 있습니다. 볼 수 있듯이, 상당수의 연구들이 그들의 코드를 공개적으로 배포했습니다. 이러한 오픈 소스 데이터 및 코드 공개는 연구자들이 WebAssembly에 대한 문헌을 더 빠르게 확장하고 이 분야에서 새로운 접근 방식을 개발할 수 있도록 할 것입니다. 우리는 이 작업에서 제공한 컬렉션이 연구의 진전을 더욱 촉진할 수 있기를 바랍니다.
표 12: 보안 범주 및 공개된 연구
범주 | 관련 연구 | 공개된 저장소 |
보안 분석 | 4 | 2 |
경험적 연구 | 7 | 4 |
사이버 보안 사용 사례 | 21 | 6 |
공격 시나리오 | 9 | 3 |
공격 탐지 | 12 | 3 |
보안 강화 | 27 | 17 |
취약점 발견 | 16 | 9 |
6.6 WebAssembly와 보안에서의 연구 격차
앞서 언급한 내용을 종합하여 다음과 같은 연구 격차를 요약할 수 있습니다:
- WebAssembly는 실제 세계에서 철저히 분석되었으며, 특히 Alexa [61] 벤치마크를 통해 연구가 이루어졌습니다. 그러나 이 벤치마크는 2022년에 폐기되었습니다. 향후 연구에서는 추가 출처를 조사하여 기존 연구의 경험적 결과를 확인해야 합니다.
- 경험적 연구는 다크 웹에서 WebAssembly의 채택을 다루지 않습니다. 이 기술이 악성 활동(예: 악성 코드 탐지 회피 및 암호화폐 채굴)에 사용된다는 점을 고려할 때, WebAssembly와 다크 웹 간의 관계를 탐구하는 것은 흥미로운 연구 방향이 될 수 있습니다.
- 암호화폐 채굴과 스마트 계약은 WebAssembly 연구에서 매우 중요한 주제이며, 이 분야에서 공격 탐지 및 취약점 발견을 위한 다양한 접근 방식이 제안되었습니다. 그러나 경험적 연구에 따르면 WebAssembly는 다른 애플리케이션에도 적용되고 있습니다. 이러한 다른 유형의 애플리케이션에서 WebAssembly의 중요성을 조사하고, WebAssembly가 두드러지게 사용되는 탐색되지 않은 분야에서 연구를 촉진할 필요가 있습니다.
- WebAssembly는 성능, 이식성, 격리성 등의 이유로 다양한 보안 사용 사례에 채택됩니다. 그러나 다른 흥미로운 애플리케이션도 검토할 수 있습니다. 그 중 하나는 사이버 훈련장(cyber ranges)과 관련이 있습니다. 즉, 보안 분야에서 사람들이 훈련을 받을 수 있는 현실적인 공격 및 방어 시나리오입니다 [182].
- 거의 모든 보안 분석 연구는 WebAssembly로 컴파일된 C 프로그램의 보안을 평가합니다. 그러나 WebAssembly 개발자는 JavaScript 및 Python과 같은 다른 언어로도 프로그램을 작성합니다. 또한 Rust 언어는 이제 C에 대한 메모리 안전한 대안으로 자리잡았습니다. 우리는 이러한 언어들을 탐구하는 보안 연구의 확장을 제안합니다.
7. 결론
이 연구에서는 WebAssembly 보안 연구의 현재 상태에 대한 종합적인 개요를 제공하며, 이 새로운 기술의 다양한 보안 측면을 다루는 주요 연구들을 강조했습니다. 우리는 총 121개의 최신 문헌을 철저히 검토하고, 이를 8개의 뚜렷한 범주로 분류한 뒤 결과를 비판적으로 평가했습니다.
우리의 분석은 WebAssembly 보안 분야에서 중요한 연구 격차가 존재함을 밝혔으며, 미래 연구들이 이를 해결해야 한다고 믿습니다. 특히, 사이버 훈련장(cyber ranges)의 탐색 부족은 유망하면서도 아직 활용되지 않은 보안 사용 사례로, WebAssembly가 보안 테스트 및 훈련 방식을 혁신할 잠재력을 가지고 있음을 제시합니다. 이 분야에 기여하기 위해, 우리는 이전 연구 [183, 184, 185]를 WebAssembly로 완전히 개발된 사이버 훈련장 솔루션과 비교하여 WebAssembly를 사용한 사이버 훈련장의 이점을 조사할 계획입니다.
우리는 또한 WebAssembly가 보다 효율적이고 효과적인 보안 테스트를 가능하게 할 잠재력을 강조하고, WebAssembly의 샌드박스 실행 환경 및 메모리 안전성 보장과 같은 고유한 기능의 보안적 함의를 고려하는 것이 중요하다고 논의했습니다.
이 연구가 WebAssembly 보안 기능을 강화하려는 연구자들에게 유용한 자료가 되고, WebAssembly를 보안 애플리케이션에 활용하려는 개발자 및 실무자들에게 귀중한 통찰을 제공하기를 바랍니다.
댓글