제로데이 익스플로잇: 유형, 사례 및 방어 방법

주요 내용

• 제로데이 익스플로잇이란, 공개적으로 제공되는 수정 프로그램이 없는 취약점을 악용하는 작동 가능한 공격 코드를 말합니다.
• 패치가 출시되기 전, 심지어 공격자 외부의 누구도 이를 알기 전에 악용이 시작될 수 있습니다.
• 수명 주기가 끝난 소프트웨어는 상류에서 수정 패치가 전혀 제공되지 않는 새로운 결함을 남길 수 있습니다.
• 해결책이 마련된 후, 그 해결책이 귀사의 차량에 얼마나 빨리 적용될지는 귀사가 결정합니다.

스캐너 결과에는 문제가 없는 것으로 나타납니다. 패치 주기도 최신 상태입니다. 하지만 결함이 이미 악용되고 있고, 아직 어떤 배포판에서도 수정된 패키지를 배포하지 않은 상황에서는 이러한 사항들이 아무런 도움이 되지 않습니다.

이는 제로데이 익스플로잇, 즉 공개적으로 수정 패치가 제공되지 않은 취약점을 노리는 공격 코드입니다. 때로는 해당 코드가 몇 달 동안 비공개로 남아 있기도 합니다. 때로는 익스플로잇이 당일에 GitHub에 올라오기도 하는데, 2026년 5월 ‘Dirty Frag’가 리눅스 배포판을 강타했을 때때와 같은 경우입니다. 어느 쪽이든, 익스플로잇은 단지 시작에 불과합니다. 결국 여러분이 치러야 할 대가의 상당 부분은 그 취약점이 노출된 기간이 그 후 얼마나 오래 지속되느냐에 달려 있습니다.

제로데이 취약점 vs 익스플로잇 vs 공격

취약점이란 결함을 말합니다. 익스플로잇은 실제로 작동하는 코드를 말합니다. 공격이란 실제 대상을 겨냥한 그 코드를 말합니다. 마지막 단계에 이르기 훨씬 전에 완화 조치가 가능하며, 패치 적용은 수정 프로그램이 개발되면 패치를 적용할 수 있게 됩니다. 악용이 시작된 후에는 탐지와 확산 방지가 시간을 벌어주는 수단이 됩니다.

용어	이것이 무엇인지	그에 따라 조치를 취할 수 있나요?
제로데이 취약점	이 코드의 결함은 내부적으로는 알려져 있을 수 있으나, 아직 공개적으로 밝혀지거나 수정되지는 않은 상태입니다.	항상 그런 것은 아닙니다. 결함이 확인되기 전까지는 패치할 구체적인 대상이 없으며, 결함이 확인된 후에는 수정 프로그램이 개발되는 동안 완화 조치를 취할 수 있습니다.
제로데이 취약점 악용	해당 결함을 확실하게 악용하는 작동하는 코드	어느 정도는 그렇습니다. 완화 조치, 모듈 차단 목록, 보안 강화 등을 통해 이 기법의 효과를 무력화할 수 있습니다.
제로데이 공격	해당 취약점을 악용해 실제 대상을 겨냥한 실전 공격	네. 탐지 및 차단 조치는 즉시 적용되며, 수정 프로그램이 배포되면 패치를 적용합니다.

 커널에 존재하는 결함은 아무도 사고 보고서를 제출하지 않는 한 수년 동안 그대로 남아 있을 수 있습니다. 실제 위험이 어느 정도인지 여부는 해당 결함에 접근할 수 있는지가 관건이었더라도, 그 취약점은 줄곧 존재해 왔습니다. 작동하는 익스플로잇이 바꾸는 것은 바로 그 위험이 현실화될 확률입니다. 일단 결함이나 익스플로잇이 알려지면, 대응 단계는 시간을 측정하고, 평가하며, 단축할 수 있는 과정이 됩니다.

제로데이 익스플로잇의 유형

제로데이 취약점은 스택 전체에 고르게 분포되어 있지 않으며, 이를 분류하는 유용한 방법은 취약점이 발생하는 위치를 기준으로 하는 것입니다. 해당 보고서에서 'Look What You Made Us Patch'에서 구글 위협 인텔리전스 그룹(GTIG)은 2025년 동안 실제 환경에서 악용된 제로데이 취약점이 90건으로 집계되었다고 밝혔습니다. 이는 2024년의 78건에서 증가한 수치이지만, 2023년에 기록된 100건에는 미치지 못했습니다. 운영 체제는 전체의 44%(39건)를 차지하며 가장 많이 악용된 제품 카테고리였습니다. 기업용 소프트웨어와 어플라이언스는 단일 범주가 아닌 그룹으로 집계되었으며, 43건의 취약점(48%)을 기록했는데, GTIG는 이 수치가 추적을 시작한 이래 두 가지 측면 모두에서 가장 높은 수치라고 보고했다.

반면 브라우저를 통한 공격은 정반대의 양상을 보이며 사상 최저 수준으로 떨어졌습니다. 반면, 대부분의 엣지 기기가 표준 EDR 적용 범위를 벗어나 있다는 점에 힘입어, 기업 인프라 및 엣지 기기를 대상으로 한 공격은 여전히 높은 수준을 유지했습니다.

운영 체제 및 커널 익스플로잇

GTIG의 2025년 데이터에서 운영 체제는 데스크톱, 모바일, 서버를 아우르는 가장 큰 단일 범주였으며, 리눅스 커널의 결함 는 그 파급 효과가 얼마나 광범위한지를 보여줍니다. 해당 계층에서 공격이 성공하면 애플리케이션, 컨테이너, 테넌트 간의 경계가 무너질 수 있으며, 호스트가 보유한 인증 정보가 노출될 수 있습니다.

 

2026년 리눅스 커널 권한 상승 취약점들이 이를 잘 보여줍니다. 복사 실패(CVE-2026-31431, CVSS 7.8) 은 2017년 인플레이스 최적화 이후로 커널 암호화 API의 algif_aead 모듈에 숨어 있었습니다. 권한이 없는 로컬 사용자는 su와 같은 setuid 바이너리의 메모리 내 페이지 캐시 복사본을 한 번에 4바이트씩 재작성할 수 있었으며, 경합 조건도 없었고 배포판별로 추측해야 할 오프셋도 없었습니다. 디스크 상에는 아무런 변화가 없었기 때문에 파일 무결성 모니터링 시스템은 아무런 오류도 감지하지 못했습니다.

Dirty Frag 는 일주일 후 발견되었으며, IPsec ESP 모듈의 CVE-2026-43284와 rxrpc의 CVE-2026-43500을 결합한 것이었습니다. 이 두 취약점은 연쇄적인 공격 경로가 아닌, 동일한 페이지 캐시 쓰기 작업으로 이어지는 두 개의 독립적인 경로이며, 공개된 익스플로잇은 호스트가 허용하는 경로를 시도하므로 한 경로를 차단한다고 해서 다른 경로까지 차단되는 것은 아닙니다. 

TuxCare가 라이브 패치 를 출시한 후, 5월 7일 취약점 공개 후 24시간 이내에 Dirty Frag 패치를 출시했습니다. 취약점이 공개되고 수천 대의 호스트에서 재부팅이 필요한 수정 작업을 수행해야 할 때, 재부팅 과정이 배포의 병목 현상이 될 수 있습니다. 바로 이러한 간극을 메우는 것이 KernelCare 가 존재하는 이유입니다.

알고 계셨나요? 2026년 9월 현재, CISA의 ‘악용된 것으로 알려진 취약점’ 목록에는 리눅스 커널 결함에 대한 항목 31건이 등재되어 있었습니다가 등재되어 있었습니다. 같은 시점을 기준으로, 한 공개 추적 사이트에서는 2026년에 공개된 리눅스 커널 CVE가 6,500건 이상 가 6,500건 이상 집계되었습니다. 두 수치 모두 지속적으로 변동하므로, 인용하기 전에 반드시 최신 정보를 확인하시기 바랍니다.

엔터프라이즈 엣지 및 어플라이언스 취약점 악용

방화벽, VPN 집중기, 파일 전송 어플라이언스 및 가상화 플랫폼은 기업 환경에서 가장 가치가 높은 제로데이 공격 대상에 속하며, 그 이유는 구조적인 데 있습니다. 이들은 네트워크 경계에 위치해 있고, 특권 자격 증명을 보유하고 있으며, 대부분 표준 엔드포인트 EDR 보호 범위에 포함되지 않기 때문입니다.

GTIG의 2025년 공급업체 분석 에 따르면 대형 기술 기업들이 1위를 차지했고, 보안 업체들이 그 바로 뒤를 이었으며, 시스코(Cisco)와 포티넷(Fortinet)은 아이반티(Ivanti) 및 VM웨어(VMware)와 함께 VPN 및 가상화 액세스를 노리는 지속적인 네트워킹 및 보안 공격 대상으로 지목되었습니다. 또 다른 20개 벤더는 각각 정확히 하나의 제로데이 공격을 받았는데, 이는 공격자들이 얼마나 광범위하게 공격을 퍼붓고 있는지 보여줍니다. GTIG는 또한 국가 후원 첩보 단체들이 계속해서 엣지 디바이스와 보안 어플라이언스를 주요 표적으로 삼고 있다고 보고했으며, 해당 단체들에 기인한 제로데이 공격의 절반 이상이 바로 이러한 유형의 인프라를 겨냥한 것으로 나타났습니다.

이러한 패턴이 반복됩니다: 인증 전 원격 코드 실행, 자격 증명 또는 키 탈취, 그리고 패치 적용 후에도 지속되는 침투. ToolShell 공격자들은 ASP.NET 머신 키를 이를 통해 서버가 업데이트된 지 한참이 지난 후에도 유효한 페이로드를 위조할 수 있었습니다. 패치를 통해 취약점은 해결되었지만, 이미 해당 키를 보유한 사람은 키가 교체될 때까지 계속해서 시스템에 침투할 수 있었습니다. 만약 귀사의 어플라이언스 목록이 분기별 스프레드시트에 저장되어 있다면, 그 스프레드시트 자체가 바로 보안 위험 요소입니다.

애플리케이션 및 공급망 취약점 악용

세 번째 범주는 사용자가 직접 작성하지 않았고, 대개는 자신도 모르게 설치하게 된 코드입니다. Log4Shell 은 대표적인 사례로, 수천 개의 자바 애플리케이션 의존성 트리에서 여러 단계 아래에 묻혀 있던 로깅 라이브러리인 Log4j의 치명적인 결함입니다. 취약한 구성 환경에서는, 예를 들어 로깅된 HTTP 헤더를 통해 제공된 공격자가 제어하는 JNDI 문자열이 취약한 Log4j 호출 경로에 도달하기만 하면 충분했습니다.

의존성 내의 결함에 대응하기는 더 어렵습니다. 열거할 수 없는 것에는 패치를 적용할 수 없기 때문입니다. Log4Shell 사태 이후 팀들은 단순히 취약점 목록을 작성하는 데만 몇 주를 소비했으며, 지금도 여전히 수많은 취약점이 발견되고 있습니다 수년이 지난 지금도 숨겨진 Log4j 취약점이 계속해서 발견되고 있습니다. 의존성 혼동 은 전혀 다른 유형의 문제로, 합법적인 패키지에서 버그를 찾는 대신 악성 패키지를 심는 공급망 공격이지만, 정확히 동일한 사각지대를 악용합니다.

빌드에 포함되기 전에 패키지를 검사한다고 해서, 그 외에는 정상적인 종속성에서 아직 아무도 발견하지 못한 결함을 확실하게 찾아낼 수는 없습니다. 이 과정을 통해 잡아낼 수 있는 것은 악성 패키지나 타이포스쿼팅된 패키지뿐이며, 이를 통해 사고 발생 중에 직접 정리해야 할 종속성 목록을 미리 확보할 수 있습니다. 바로 이것이 그 격차입니다 TuxCare의 SecureChain 가 오픈소스 분야에서 메우기 위해 설계된 부분입니다.

2021년부터 2026년까지의 주목할 만한 제로데이 익스플로잇 사례

아래 목록에는 메일 서버부터 로깅 라이브러리, 관리형 파일 전송 도구, 협업 플랫폼, 그리고 커널 자체에 이르기까지 다양한 항목이 포함되어 있습니다. 제로데이 취약점은 스택의 특정 계층에만 국한되지 않습니다.

연도	취약점 / CVE	목표	왜 이것이 제로데이로 간주되었는가
2021	ProxyLogon / CVE-2021-26855	온프레미스 Microsoft Exchange	대규모 악용은 대역 외 패치가 배포되기 전에 시작되었다
2021	Log4Shell / CVE-2021-44228	Apache Log4j 2	공개 및 수정 조치 이전에 이미 악용 사례가 확인된 날들
2023	MOVEit / CVE-2023-34362	MOVEit 전송 진행 상황	Cl0p는 보안 권고가 발표되기 전에 데이터를 유출했다
2025	ToolShell / CVE-2025-53770	온프레미스 SharePoint Server	긴급 패치가 배포되기 전인 7월 18일부터 CVSS 9.8 등급의 원격 코드 실행(RCE) 취약점이 악용되기 시작했습니다.
2026	Dirty Frag / CVE-2026-43284, CVE-2026-43500	리눅스 커널 (ESP, rxrpc)	어떤 배포판도 수정 패치를 적용하기 전에 공개 익스플로잇이 유출되었다

 이 중 두 가지의 배경 사연은 좀 더 복잡합니다. ToolShell에 대한 연구는 2025년 5월 베를린에서 열린 Pwn2Own 행사에서 CVE-2025-49704와 CVE-2025-49706을 연쇄적으로 악용하는 시연으로 시작되었으며, 마이크로소프트는 그해 7월에 두 취약점 모두에 대한 패치를 배포했습니다. 표에 나와 있는 취약점은 그 취약점이 아닙니다. 

CVE-2025-53770은 7월 패치를 우회하는 취약점이며, 마이크로소프트가 이 취약점에 번호를 부여했을 당시 이미 악용되고 있었습니다. ‘Dirty Frag’의 경우, 누군가가 공개 금지 조치를 위반하여 조기 공개를 강요하기 전까지는 조정된 공개 절차가 진행 중이었습니다. 두 사례 모두 악의적인 연구 출처가 필요하지 않았습니다. 중요한 점은 방어 측이 완벽한 해결책을 마련하기 전에 이미 악용이 가능했다는 사실이었습니다.

제로데이 익스플로잇이 왜 그렇게 위험한가

제로데이 공격이 위험한 이유는 그 공격이 알려지지 않았기 때문이라기보다는 대응 속도의 차이에 있습니다. 공격자는 몇 시간 만에 공격을 진행할 수 있지만, 테스트, 변경 관리, 유지보수 기간 등의 제약에 묶인 기업의 대응 조치는 종종 며칠 또는 몇 주가 걸립니다. 맨디언트(Mandiant)의 ‘M-Trends 2026’ 보고서에 따르면 에 따르면, 새로운 취약점을 악용하는 데 걸리는 예상 평균 시간은 마이너스 7일로, 이는 이제 패치가 출시되기도 전에 악용이 일상적으로 시작된다는 것을 의미합니다. 맨디언트 자체의 추세선에서는 2018년과 2019년 동안 이 수치가 63일이었습니다.

 

1. 필요할 때 패치가 없다

대부분의 취약점 관리 프로세스 는 공급업체의 수정 패치가 제공된다는 전제를 바탕으로 합니다. 제로데이 취약점에 대한 패치가 출시되기 전 기간에는 대신 보완 조치를 취해야 합니다. 즉, 기능을 비활성화하거나, 네트워크 노출을 제한하거나, 구성을 변경하거나, 리눅스의 경우 커널 모듈을 차단 목록에 추가하고 seccomp 프로필을 강화하는 등의 조치입니다. 이러한 조치는 노출 위험을 줄여주지만, 일부는 정상적인 기능까지 함께 제한하기도 하므로, 전체 시스템에 적용하기 전에 반드시 테스트를 거쳐야 합니다. Dirty Frag의 경우, CERT/CC가 제시한 임시 해결책은 esp4, esp6, rxrpc를 차단 목록에 추가하고, 이를 언로드하며, 페이지 캐시를 삭제하는 것이었습니다. 이 조치로 인해 IPsec과 AFS도 작동하지 않게 되므로, 완전히 무해한 해결책은 아니었습니다.

300노드 규모의 쿠버네티스 플랫폼을 운영하는 팀이 주중 어느 날, 이미 공개된 익스플로잇이 첨부된 보안 권고문을 받는 상황을 상상해 보십시오. 해당 모듈을 차단 목록에 추가하려면 먼저 클러스터 내 어떤 시스템도 IPsec이 필요하지 않다는 사실을 입증해야 하는데, 그 입증 과정은 공격자가 이미 접근 가능한 호스트에서 공격을 수행하는 데 필요한 시간보다 더 오래 걸립니다.

2. 시그니처 기반 탐지는 애초부터 불리한 위치에서 시작된다

시그니처 기반 안티바이러스와 CVE 기반 스캔은 모두 누군가가 이미 식별하고 분류해 둔 정보에 의존합니다. 완전히 새로운 제로데이 취약점에는 아직 CVE에 해당하는 시그니처도 없고, 이를 탐지할 수 있는 스캐너 검사 기능도 없습니다.

행동 탐지 기술은 이러한 격차의 일부를 메워주며, 5년 전보다 훨씬 개선되었습니다. 하지만 이 기술 역시 오탐이 발생하기 쉬우며, 2026년 커널 결함 사건을 통해 그 한계가 드러났습니다. ‘Copy Fail’은 메모리 내 페이지 캐시에만 영향을 미쳤기 때문에, 디스크상의 파일은 바이트 단위로 동일하게 유지되었고 파일 무결성 모니터링은 아무런 반응을 보이지 않았습니다. 재부팅을 통해 깨끗한 페이지가 다시 로드되면서 해당 특정 흔적도 함께 사라졌습니다.

이 모든 문제에 스캐너 문제까지 겹치고 있습니다. 팀들은 오탐지 로 인해 허위 양성에 허덕이는 팀들은 스캔 결과를 꼼꼼히 확인하지 않게 되는데, 바로 그 순간에 진짜 문제가 잡음으로 치부되어 간과되고 맙니다.

3. 수명이 다한 시스템은 제로데이 취약점을 무기한으로 패치되지 않은 상태로 방치할 수 있다

지원되는 시스템에서 제로데이는 대개 수정 프로그램이나 실행 가능한 해결책이 제공되면 종료되는 기간을 의미합니다. 지원 종료(EOL) 버전의 경우, 해당 릴리스에 대해 업스트림에서 더 이상 지원이 제공되지 않으므로, 사용자가 이를 막을 다른 방법을 찾을 때까지 그 창은 열린 상태로 남아 있습니다.

이는 보안 부채 로 이어집니다. 해당 버전에 영향을 미치는 새로 공개된 모든 결함(제로데이 여부와 상관없이)은 패치되지 않은 항목을 하나씩 추가하며, 이러한 항목들은 누적됩니다.

팀들이 EOL(지원 종료) 운영 체제를 계속 사용하는 데는 타당한 이유가 있습니다. 인증된 애플리케이션 스택, 하드웨어 제약, 분기 단위로 측정되는 검증 주기 등이 바로 그 이유입니다. TuxCare의 ‘Endless Lifecycle Support’ 는 바로 이러한 상황을 위해 마련된 것으로, 지원 대상인 EOL 시스템 및 소프트웨어에 보안 패치를 제공하는 동시에 기업이 실제로 설정한 일정에 따라 마이그레이션이 이루어지도록 합니다. 이는 수정 패치가 출시될 것으로 예상되지만 아직 제공되지 않은 ‘제로데이’ 문제와는 다른 문제입니다. 노후화된 시스템 군에서는 이 두 가지 문제가 서로 복합적으로 작용합니다.

제로데이 공격에 대비하는 방법

아직 누구도 식별하지 못한 사항에 대해서는 CVE 검사를 수행할 수 없으므로, 이를 중심으로 전체 계획을 세우지 마십시오. 여기서 가장 중요한 두 가지 목표는, 수정 패치가 나온 후 실제 적용되기까지 걸리는 시간을 단축하고, 악용 코드가 시스템에 침투했을 때 접근할 수 있는 범위를 제한하는 것입니다. 탐지, 사고 대응, 접근 제어 역시 여전히 중요하지만, 대부분의 팀이 가장 큰 개선 여지를 가지고 있는 부분은 바로 이 두 가지입니다.

 

수정 사항이 마련되면 패치까지 걸리는 시간을 단축

상류 단계에서 언제 배포할지는 여러분이 통제할 수 없습니다. 여러분이 통제할 수 있는 것은 그 이후의 배포 기간이며, 많은 조직의 경우 패치 자체가 아니라 바로 그 기간 때문에 몇 주가 소요되는 것입니다.

재부팅 없이 패치 적용 은 커널 계층의 제약을 제거합니다. 관리 중인 시스템 군이 하루 이내에 재부팅을 감당할 수 있다면, 기존의 패치 적용 방식으로도 충분할 수 있습니다. 커널 재부팅으로 인해 3주간의 변경 작업 기간이 필요한 경우, 재부팅 없이 패치 적용을 통해 그 배포 공백을 대폭 단축할 수 있으며, 그 동안 3주 동안의 보안 취약 기간을 감수할 필요도 없습니다.

필요해지기 전에 폭발 반경을 줄이세요

압박 속에서 내린 완화 조치는 잘못된 결정이다. 조기에 결정하라.

즉, 플릿 내 어떤 시스템에서도 사용하지 않는 커널 모듈을 차단 목록에 추가하여, 해당 경로가 노출되기 전에 미리 차단하는 것입니다. 또한 신뢰할 수 없는 워크로드, CI 러너, 멀티테넌트 노드에 seccomp 프로필을 적용해야 합니다. Docker의 기본 프로필은 ‘unshare’를 거부하므로, 공개된 xfrm/ESP Dirty Frag 익스플로잇에 필요한 사용자 및 네트워크 네임스페이스 설정을 차단하며, EKS, GKE 및 Talos에서 수행한 테스트 결과 결과, RuntimeDefault만으로도 취약한 커널에서 해당 경로를 차단하는 데 충분하다는 사실이 확인되었습니다. 동일한 테스트에서 EKS나 GKE에서 seccomp를 설정하지 않은 상태는 RuntimeDefault와 동등하지 않으며, 프로파일 없이 실행되는 포드는 컨테이너 루트 권한까지 침해당했으므로, 이는 RuntimeDefault가 단순히 가정되는 것이 아니라 실제로 적용되는 경우에만 도움이 됩니다. 또한 동일한 제어 방식이 Copy Fail에 대해서는 아무런 효과가 없었으며, Restricted 포드 보안 설정하에서도 AF_ALG에 접근할 수 있었다는 점을 알아두어야 합니다. 이는 프로덕션 자격 증명을 보유한 호스트에서 신뢰할 수 없는 코드를 차단하고, 침해된 VPN 집중기가 데이터베이스 계층에 접근할 수 없도록 어플라이언스를 세분화해야 함을 의미합니다.

‘Copy Fail’과 ‘Dirty Frag’ 모두 로컬 코드 실행이 필요합니다. 공격자가 이를 확보할 수 있는 곳—공유 CI, 컨테이너 빌드 팜, 멀티테넌트 쿠버네티스, 또는 초기 침투 후 접근 가능한 모든 호스트—이 바로 취약점이 집중되는 곳입니다.

실제로 어떤 프로그램이 실행 중인지, 어떤 패치가 실제로 적용되었는지 파악하세요

대응 속도는 인벤토리 정확도에 따라 제한을 받습니다. 어떤 호스트에서 영향을 받는 커널이 실행되고 있는지 실시간으로 파악할 수 있는 팀은 해당 호스트에 더 빨리 패치를 적용할 수 있는데, 이는 악용 코드가 이미 공개된 상황에서 가장 중요한 요소입니다. 이를 파악하지 못하는 팀은 사고 발생 시 스프레드시트를 작성하느라 시간을 허비하게 됩니다.

여기서 중요한 점은 두 가지입니다. 첫째, 컨테이너와 어플라이언스를 포함한 정확한 자산 및 버전 목록입니다. 둘째, 패키지 메타데이터가 아닌 실행 중인 시스템의 상태를 반영하는 패치 확인입니다. 버전 문자열을 통해 상태를 추론하는 스캐너들은 바로 이 부분에서 백포트 및 재부팅 없이 적용되는 수정 사항에 대해 오류를 범하는 경향이 있습니다.

실제로 필요해지기 전에 노출 대응 훈련을 실시하세요. 평소와 같은 화요일 상황을 가정하고, 가상의 CVE를 설정해, 어떤 호스트가 영향을 받았는지, 그리고 문제가 해결되었는지 파악하는 데 얼마나 걸리는지 확인해 보세요. 대개 자산 관리의 허점이 가장 먼저 드러나게 됩니다.

제로데이 공격으로부터 시스템을 보호하는 최고의 도구

이 중 어느 것도 악용이 시작되기 전에 알려지지 않은 결함을 찾아낼 것이라고 보장할 수는 없습니다. 이 방법들이 하는 역할은 악용이 발생한 후의 대응 시간을 단축하고, 시스템이 실제로 어떤 상태에 있는지 확인할 수 있게 해주는 것입니다.

1. TuxCare

TuxCare는 제로데이 문제의 세 가지 측면을 다루고 있는데, 이는 제품 범위가 무분별하게 확대된 것이 아니라 의도적인 선택입니다. 왜냐하면 보안 침해는 커널, 사용자 공간, 그리고 이미 개발이 중단된 업스트림 소프트웨어 간의 경계를 가리지 않기 때문입니다.

KernelCare 는 재부팅이나 유지보수 시간 없이 실행 중인 리눅스 커널에 패치를 적용하며, 다양한 주요 엔터프라이즈 배포판을 폭넓게 지원합니다. 이는 OS별로 별도의 툴을 사용해야 할 경우 별도의 계약과 관리 공백이 발생하는 혼합 환경에서는 매우 중요한 장점입니다. LibCare 는 glibc 및 OpenSSL과 같은 사용자 공간 라이브러리에도 동일한 접근 방식을 적용합니다. 끝없는 라이프사이클 지원 업스트림 지원이 중단된 지 오랜 시간이 지난 후에도 표준 패키지 관리 시스템을 통해 지원 대상인 EOL(수명 주기 종료) 운영 체제, 런타임, 라이브러리 및 프레임워크에 대한 보안 패치를 제공합니다.

2. CISA 알려진 악용 사례 취약점 목록

“이론적으로 악용될 수 있는” 것과 “현재 실제로 사람들을 상대로 악용되고 있는” 것을 구분할 수 있는, 무료이면서 신뢰할 수 있고 가장 빠른 방법입니다. 바로 KEV 카탈로그 에는 실제 환경에서 악용이 확인된 CVE가 나열되어 있으며, 연방 민간 행정부 기관들은 각 항목에 대해 반드시 준수해야 하는 시정 기한을 부여받습니다.

이를 선별 필터로 활용하세요. KEV에 등록된 CVE는 CVSS 점수와 상관없이와 관계없이 대기열의 맨 앞으로 이동합니다. 문제는 타이밍입니다. KEV는 후행 지표이기 때문에, 제로데이 취약점은 KEV에 등록되기 훨씬 전에 이미 악용되고 있는 경우가 많기 때문입니다. ‘Copy Fail’은 공개된 지 이틀 뒤인 5월 1일에 추가되었는데, 그와 같은 이틀 동안 이미 공개된 익스플로잇이 유포되고 있었습니다. 이는 확인된 악용 사례를 우선순위로 지정해야 한다는 점을 나타내는 가장 강력한 공개 신호 중 하나로 남아 있습니다.

3. 행동 기반 EDR 및 런타임 탐지

서명 대신 동작을 모니터링하는 엔드포인트 및 런타임 도구는 취약점별 탐지 기능이 구축되어 있지 않아도 악용 시도를 포착할 수 있으며, 이것이 바로 이러한 도구의 핵심 목적입니다. Falco와 같은 런타임 도구나 여러분이 직접 개발한 eBPF 프로브와 같은 런타임 도구는, 공개된 Dirty Frag 코드가 페이지 캐시 쓰기 기본 연산을 수행하기 위해 사용한 스플라이스 기반의 페이지 차용 시퀀스와 같이, 익스플로잇이 의존하는 시스템 호출 패턴을 식별할 수 있습니다.

두 가지 주의할 점이 있습니다. 탐지는 예방이 아니므로, 경보가 발생하더라도 이를 처리할 수 있는 사람이 깨어 있어야 합니다. 또한 수많은 가전제품과 네트워크 기기는 에이전트를 실행할 수조차 없는데, 이것이 GTIG가 2025년에 14건의 엣지 기기 제로데이 취약점을 집계했음에도 불구하고, 이 수치가 실제 규모를 과소평가하고 있을 가능성이 높다고 지적한 이유 중 하나입니다.

TuxCare로 제로데이 공격으로부터 시스템을 보호하세요

제로데이 취약점은 사라지지 않을 것입니다. 패치가 제공되기 전에 악용이 시작될 가능성은 소프트웨어를 운영하는 데 있어 피할 수 없는 특징이며, 예고 없이 다시 찾아올 것입니다.

사용자가 제어할 수 있는 것은 유지보수 기간이 얼마나 지속되는지입니다. 재부팅 없이 적용되는 커널 패치 덕분에 유지보수 기간을 고려할 필요가 없어집니다. 확장 지원은 지원 대상인 EOL(제품 수명 종료) 시스템에 대한 패치 경로를 복원해 줍니다. 정확한 패치 검증 기능을 통해 단순히 겉보기만 고쳐진 호스트가 아닌, 실제로 문제가 해결된 호스트를 파악할 수 있습니다.

대규모로 리눅스를 운영 중인데도 커널 패치 적용이 여전히 재부팅 일정을 기다리고 있다면, 우선 그 격차를 해소하십시오. KernelCare는 바로 이러한 문제를 해결하기 위해 개발되었습니다.

자주 묻는 질문