취약점
제로데이 취약점이란?
제로데이 취약점은 공급업체나 메인테이너가 수정을 내놓기 전에 공격자가 이미 알고 있거나 악용하고 있는 보안 결함입니다. 수정이 나오기 전까지 영향을 받는 코드를 실행하는 모든 시스템이 노출되며, 패치로는 그 공백을 메울 수 없습니다. 오픈 소스로 만든 소프트웨어에서 이것이 무엇을 의미하는지, 그리고 실제로 발생했을 때 어떻게 대응해야 하는지 설명합니다.
업데이트
제로데이 취약점, 익스플로잇, 공격
세 용어는 흔히 혼용되지만, 서로 다른 것을 가리킵니다.
- 제로데이 취약점: 공급업체가 모르거나 수정이 없는 결함 그 자체.
- 제로데이 익스플로잇: 그 결함을 악용하는 코드나 기법.
- 제로데이 공격: 실제 대상을 상대로 사용된 익스플로잇.
공급업체가 수정을 배포하면 그 결함은 더 이상 제로데이가 아니라 알려진 취약점이 되며, 흔히 n-day라고 부릅니다. 그때부터 두 번째 경쟁이 시작됩니다. 공격자는 패치를 분석하고 아직 패치를 적용하지 않은 시스템을 스캔하므로, 패치하지 않은 알려진 취약점은 원래의 제로데이만큼 큰 피해를 줄 수 있습니다.
종속성 속의 제로데이
최신 애플리케이션 코드의 대부분은 오픈 소스 패키지에서 오며, 그 대부분은 팀이 선택한 것이 아니라 다른 패키지가 끌어온 전이적 종속성입니다. 그중 어느 하나의 제로데이는 곧 제품의 제로데이입니다.
가장 잘 알려진 예가 Log4Shell(CVE-2021-44228)입니다. 2021년 12월에 공개된 이 취약점은 로그 메시지를 통제하는 공격자가
Apache Log4j 2를 통해 임의의 코드를 실행할 수 있게 했으며, CVSS 최고점인 10.0을 받았습니다. 대부분의 팀에게 어려운
부분은 수정이 아니었습니다. 그 전의 질문, 즉 우리 애플리케이션 중 어디에 log4j-core가 어떤 버전으로 들어
있는가였습니다. Log4j는 대개 종속성의 종속성이었고, 많은 팀이 이를 파악하는 데 며칠을 썼습니다.
공급망의 제로데이가 언제나 버그인 것은 아닙니다. 2024년 3월, Andres Freund는 SSH 로그인이 CPU를 지나치게 많이 쓰는 것을 알아차린 뒤 xz 5.6.0 및 5.6.1 버전에서 백도어(CVE-2024-3094)를 발견했습니다. 흔한 유형의 공급망 공격인 악성 패키지 릴리스도 같은 방식으로 작동합니다. Shai-Hulud npm 웜의 피해를 입은 팀처럼 감염된 버전을 가장 먼저 설치한 팀은 아직 어떤 권고나 스캐너도 알지 못하는 공격에 직면합니다.
제로데이가 종속성을 강타했을 때의 대응 방법
- 어디에 있는지 찾습니다. 전이적 종속성을 포함해 영향을 받는 구성 요소가 들어 있는 모든 애플리케이션, 이미지, 릴리스를 나열합니다. 이를 위해서는 빌드마다 정확한 SBOM이 필요합니다. 잠금 파일은 설치 스크립트가 내려받는 코드나 컨테이너 이미지의 운영체제 레이어처럼 패키지 관리자 밖에서 가져온 종속성을 놓칩니다.
- 노출 기간을 파악합니다. 어떤 빌드가 언제부터 취약한 버전을 출시했는지 확인합니다. 이를 통해 무엇을 조사하고 무엇을 보고해야 하는지 알 수 있습니다.
- 억제합니다. 수정이나 우회 방법이 있으면 적용하고, CVE가 부여된 뒤에는 새 빌드가 취약한 버전을 출시하지 않도록 막습니다. CVE 조치를 참고하세요.
- 악용 여부를 확인합니다. 노출 기간 동안 해당 결함이 악용된 흔적을 찾고, 결함이 접근할 수 있었던 시크릿을 모두 교체합니다.
우리가 영향을 받았을까?에서 처음 두 단계를 자세히 설명합니다.
아무도 모르는 제로데이를 막을 수 있을까요?
패치로도, 스캐너로도 막을 수 없습니다. 둘 다 결함이 알려져 있어야 작동하기 때문입니다. 공개 전에 효과가 있는 것은 공격자가 찾아낸 결함으로 할 수 있는 일을 제한하는 것입니다.
- 최소 권한. 각 시스템과 각 CI 작업에 필요한 접근 권한과 시크릿만 부여합니다.
- 이그레스 통제. 시스템에 필요하지 않은 호스트로의 아웃바운드 연결을 차단해, 실행된 익스플로잇이 공격자에게 데이터를 보낼 수 없게 합니다. CI 빌드에서는 새로운 악성 패키지의 첫 번째 피해자가 되더라도 효과가 있는 몇 안 되는 통제 중 하나입니다. GitHub Actions용 이그레스 정책을 참고하세요.
- 심층 방어. 통제를 여러 겹으로 쌓아 하나의 결함이 모든 것을 열지 않도록 합니다.
- 나중에 검색할 수 있는 기록. 제로데이가 공개되면, 대응 속도는 무엇을 빌드하고 출시했는지 알고 있느냐에 달려 있습니다.
CRACI가 돕는 방법
CRACI는 GitHub Actions 작업을 CRACI가 운영하는 러너에서 실행하고 모든 빌드를 실행되는 그 순간에 기록합니다.
- 빌드 시점 SBOM은 잠금 파일 기반 도구가 놓치는 숨은 종속성을 포함해 각 작업이 실제로 가져온 패키지를 나열하므로, 실제로 빌드된 것을 근거로 "어디에 있는가?"에 답할 수 있습니다. 빌드 시점 SBOM을 참고하세요.
- 빌드 이력은 과거의 모든 빌드와 그 SBOM, 그리고 직접 또는 전이적으로 취약한 종속성을 포함한 빌드를 보여 주므로, 영향을 받은 기간을 알 수 있습니다.
- 정책 게이트는 특정 CVE를 포함한 빌드를 차단할 수 있으므로, 새 빌드가 취약한 버전을 다시 출시하지 않습니다.
- 기본 거부로 설정한 이그레스 정책은 아무도 본 적 없는 공격 중에도 빌드에 필요하지 않은 호스트로의 연결을 차단합니다.
제로데이 취약점: 자주 묻는 질문
제로데이 취약점이란 무엇인가요?
공급업체나 메인테이너가 수정을 배포하기 전에 공격자가 이미 알고 있거나 악용하고 있는 보안 결함입니다. 이름은 방어자가 패치할 수 있었던 날수, 즉 0일을 뜻합니다.
제로데이 취약점, 익스플로잇, 공격의 차이는 무엇인가요?
취약점은 결함입니다. 익스플로잇은 그 결함을 악용하는 코드나 기법입니다. 공격은 실제 대상을 상대로 사용된 익스플로잇입니다.
제로데이는 언제 제로데이가 아니게 되나요?
수정이 나왔을 때입니다. 그때부터는 n-day라고도 부르는 알려진 취약점이 되며, 위험은 아직 수정을 적용하지 않은 시스템으로 옮겨 갑니다.
스캐너가 제로데이를 탐지할 수 있나요?
조회로는 불가능합니다. 취약점 스캐너는 구성 요소를 공개된 권고와 매칭하는데, 제로데이에는 아직 권고가 없습니다. 스캐너나 SBOM이 제공하는 것은 권고가 나오는 즉시 검색할 수 있는 인벤토리입니다.
제로데이가 우리 소프트웨어에 영향을 주는지 어떻게 알 수 있나요?
전이적 종속성을 포함해 각 빌드와 릴리스에 무엇이 들어 있는지에 대한 정확한 인벤토리에서 영향을 받는 구성 요소와 버전을 검색합니다. 그런 다음 어떤 릴리스가 언제부터 그것을 출시했는지 파악하면 노출 기간을 알 수 있습니다.
취약한 패키지가 어디에 출시되었는지 파악하세요
GitHub Actions 워크플로 하나를 CRACI에서 실행하면, 가져온 모든 패키지의 SBOM이 기록되어 다음 권고가 나올 때 바로 검색할 수 있습니다.
데모 예약