제로데이 취약점 (Zero-Day Vulnerability)
쉽게 풀면
제로데이 취약점은 건물 설계자도 모르는 비상구가 몰래 존재하는 상황에 비유할 수 있습니다. 이 비상구를 아는 사람만이 아무런 제지 없이 드나들 수 있습니다. "제로데이"라는 이름은 개발자가 이 문제를 인지하고 고칠 수 있는 날이 "0일"이었다는 뜻에서 나왔습니다. 즉 공격자가 방어 측보다 먼저 결함을 알고 있는 상태를 가리킵니다.
왜 중요한가
제로데이 취약점은 아직 알려진 방어 방법이 없기 때문에 기존의 패치나 시그니처 기반 방어로는 막기 매우 어렵습니다. 이러한 특성 때문에 고도화된 공격이나 APT 캠페인에서 자주 활용되며, 정보보안 연구에서는 이를 사전에 발견하고 대응할 수 있는 방법을 찾는 것이 중요한 과제로 다루어집니다.
핵심 정리
- 제로데이 취약점은 제조사(개발자)가 모르거나, 알더라도 아직 패치가 없는 보안 결함입니다. “제로데이”는 제조사에게 대응할 시간이 0일이었다는 뜻입니다.
- 취약점(결함), 익스플로잇(그 결함을 이용하는 코드), 공격(이를 실제로 쓰는 행위)은 서로 다른 층입니다. 제로데이라는 말은 취약점에도, 익스플로잇에도, 공격에도 붙습니다.
- 취약점이 생겨 패치가 나오고 적용되기까지의 기간을 “취약성의 창(window of vulnerability)”으로 보는 분석틀은 Arbaugh, Fithen, McHugh(2000)가 사례 분석으로 정리했습니다.
- 실제 공격에 쓰이는 제로데이를 대규모 자료로 분석한 연구로 Bilge와 Dumitras(2012)가 있고, 비공개 상태로 오래 남는 제로데이의 수명을 분석한 보고서로 Ablon과 Bogart(2017)가 있습니다.
예시로 보기
가상의 시간표입니다. 아래 일수는 예시이며, 구간 길이는 코드로 계산했습니다.
| 사건 | 경과 |
|---|---|
| 공격자가 취약점을 발견 | 0일 |
| 공격자가 악용 시작 | 10일 |
| 제조사가 취약점을 인지 | 40일 |
| 패치 공개 | 62일 |
| 한 조직이 패치 적용 | 90일 |
- 공격자가 악용을 시작한 뒤 제조사가 알기까지: 30일
- 제조사가 안 뒤 패치가 나오기까지: 22일
- 패치 공개 뒤 이 조직이 적용하기까지: 28일
- 악용 시작부터 패치 공개까지, 방어 쪽에 해법이 없던 기간: 52일
“제로데이”로 부르는 구간은 정의에 따라 다릅니다. 제조사가 알기 전까지만(30일) 부르는 경우도 있고, 패치가 나오기 전까지(52일) 부르는 경우도 있습니다. 어느 쪽을 썼는지 논문에서 밝혀야 합니다. 패치가 나온 뒤 적용이 늦은 28일 동안의 취약성은 보통 제로데이가 아니라 “알려진(n-day) 취약점”으로 분류됩니다.
자주 하는 오해
| 오해 | 바로잡기 |
|---|---|
| 제로데이는 아주 위험한 취약점을 부르는 이름이다. | 심각도를 뜻하는 말이 아니라 “패치가 없는 시점”을 가리킵니다. 심각도는 CVSS 같은 별도 점수로 표현합니다. |
| 제로데이는 한 번 발견되면 곧 공개된다. | 비공개 상태로 오래 남는 경우가 있다고 보고됩니다(Ablon과 Bogart, 2017). 반대로 공개된 뒤에는 이를 이용하는 공격이 크게 늘어난다고 보고됩니다(Bilge와 Dumitras, 2012). |
| 패치가 나오면 문제가 끝난다. | 적용이 늦은 시스템은 계속 취약합니다. 패치 공개는 오히려 공격자에게 결함의 위치를 알려 주는 단서가 되기도 합니다. |
| 시그니처 기반 백신으로 막을 수 있다. | 알려지지 않은 공격이라 시그니처가 없습니다. 이상 탐지, 샌드박스, 최소 권한 같은 일반 방어에 의존합니다. |
논문에서는 이렇게 쓰입니다
실제 논문에서
이 용어를 직접 쓴 국내 논문 문장을 아직 수집하지 못했습니다. 수집되는 대로 출처와 함께 싣겠습니다.
예시 문장
아래는 용어의 쓰임을 보여 주려고 만든 예시로, 실제 논문에서 가져온 문장이 아닙니다.
제로데이 취약점 발견 이후의 공개 절차를 다룬 연구 사례입니다.
미지의 공격을 탐지하기 위한 방어 기법 연구 예문입니다.
조금 더 깊게 보면
제로데이 취약점을 실제로 악용하는 코드를 제로데이 익스플로잇이라 부르며, 이를 이용한 공격을 제로데이 공격이라 합니다. 취약점이 발견되면 일반적으로 개발사에 비공개로 알려 패치를 준비할 시간을 주는 책임 있는 공개(responsible disclosure) 절차가 권장되는 것으로 알려져 있습니다.
패치가 배포된 이후에도 적용이 늦어지는 시스템은 여전히 취약한 상태로 남을 수 있습니다. 정부기관이나 보안업체가 제로데이를 발견하고도 이를 공개하지 않고 자체적으로 보유하거나 거래하는 사례가 있어, 공격 대응 목적과 방어 목적 사이의 윤리적 긴장이 논의되기도 합니다.
제로데이 취약점이 실제로 공격에 악용되고 있는 정황이 확인되면 이를 흔히 '야생에서 발견된(in the wild)' 취약점이라 부르며, 이 경우 개발사는 정기 패치 주기를 기다리지 않고 긴급 패치를 배포하는 것이 일반적인 관행입니다.
주의할 점
제로데이라는 용어는 특정 심각도의 취약점을 의미하는 것이 아니라, 아직 공개되거나 패치되지 않았다는 시점상의 특성을 가리키는 개념임을 유의해야 합니다. 패치가 나온 이후에는 더 이상 제로데이로 분류되지 않습니다.
헷갈리기 쉬운 용어
| 용어 | 한 줄 설명 | 층위 |
|---|---|---|
| 제로데이 취약점 | 패치가 없는 소프트웨어 결함 | 결함(취약점) |
| 제로데이 취약점 공격 | 그 결함을 실제로 이용하는 코드·공격 | 이용(익스플로잇·공격) |
| n-day 취약점 | 이미 공개되고 패치가 나온 취약점 | 패치 이후 단계 |
| 책임 있는 공개 | 발견자가 제조사에 먼저 알려 패치 시간을 주는 절차 | 대응 절차 |
참고 문헌
- Arbaugh, W. A., Fithen, W. L., & McHugh, J. (2000). Windows of vulnerability: A case study analysis. IEEE Computer, 33(12), 52–59.
- Bilge, L., & Dumitras, T. (2012). Before we knew it: An empirical study of zero-day attacks in the real world. Proceedings of the ACM Conference on Computer and Communications Security (CCS).
- Ablon, L., & Bogart, A. (2017). Zero Days, Thousands of Nights: The Life and Times of Zero-Day Vulnerabilities and Their Exploits. RAND Corporation.
표의 기준값은 위 문헌에 근거한 관례이며, 분야·학술지마다 다른 기준을 쓸 수 있습니다.