같은 메모리를 두 번 반납한 IKEEXT, CVE-2026-33824가 노린 지점

이미지 출처: CISA KEV

윈도우 서비스 목록을 아래로 훑다 보면 IKE and AuthIP IPsec Keying Modules라는 유난히 긴 이름이 지나간다. 이름은 거창한데 대부분의 관리자는 이 서비스를 켠 기억도, 쓴 기억도 없다. VPN도 안 쓰고 IPsec 정책도 없는 사무실 PC에서조차 이 녀석은 조용히 자동 시작 상태로 앉아 있음. 그 조용한 서비스에서 더블 프리(double free) 결함이 나왔다는 게 이번 CVE-2026-33824의 요지임.

핵심 요약

• 윈도우 IKE 서비스 확장(IKEEXT)에서 같은 힙 메모리를 두 번 해제하는 결함이 확인됨. 인증 이전 단계의 프로토콜 처리 경로가 문제 지점임.
• IKE는 UDP 500·4500번에서 동작하며, 협상 초기 패킷은 신원 확인 전에 파싱되므로 노출 표면이 넓음.
• 방어의 핵심은 패치 적용, 두 포트의 인바운드 노출 차단, 그리고 IKEEXT 서비스 크래시·재시작 이벤트를 탐지 신호로 삼는 것임.

더블 프리가 왜 위험한 결함인가

메모리를 할당했다가 반납하는 건 지극히 평범한 동작임. 문제는 이미 반납한 블록을 한 번 더 반납할 때 생김. 힙 관리자는 해제된 블록들을 자유 목록(free list)으로 엮어 관리하는데, 같은 주소가 목록에 두 번 들어가면 자료구조의 일관성이 깨짐. 그다음 할당 요청이 들어오면 서로 다른 두 개의 코드 경로가 같은 메모리를 각자 자기 것인 줄 알고 쓰게 됨.

여기서부터가 공격자가 노리는 구간임. 한쪽이 문자열 버퍼로 쓰는 영역을 다른 쪽이 함수 포인터가 든 구조체로 해석하는 상황이 만들어지면, 값의 내용을 통제할 수 있는 쪽이 실행 흐름의 방향을 바꿀 여지가 생김. 개념적으로는 이 정도만 이해하면 충분하다고 봄. 실제로 이걸 안정적인 코드 실행까지 끌고 가려면 힙 배치를 원하는 모양으로 정렬하는 작업이 별도로 필요하고, 그건 이 글에서 다룰 영역이 아님.

하필 IKEEXT라서 신경 쓰이는 이유

취약점의 위험도는 결함 자체보다 그 코드에 누가 말을 걸 수 있느냐로 결정되는 경우가 많음. IKEEXT는 그 점에서 조건이 나쁨.

• 인증 이전에 파싱함 — IKE는 이름 그대로 키 교환 프로토콜임. 서로 신뢰할 근거를 만드는 게 목적이니, 협상 첫 패킷은 당연히 인증되지 않은 상대에게서 온 것임. 즉 결함이 있는 파서가 아무 자격 없는 발신자에게 열려 있음.
• UDP 기반임 — TCP처럼 핸드셰이크를 완료할 필요가 없어 출발지 주소를 위조한 패킷 한 통으로 코드 경로를 건드릴 수 있음. 로그에 남은 IP를 그대로 믿기 어려운 이유도 여기 있음.
• 안 쓰는데 켜져 있음 — 앞서 말한 대로 IPsec을 전혀 쓰지 않는 시스템에서도 서비스가 살아 있는 경우가 흔함. 사용하지 않는 기능이 공격 표면으로 남아 있는 전형적인 사례임.
• 권한이 높음 — 이 서비스는 시스템 수준 컨텍스트에서 동작하므로, 성공적인 악용의 결과가 곧바로 상위 권한임.

우리 환경이 노출됐는지부터 확인하기

패치를 돌리기 전에 노출 범위를 아는 게 순서라고 봄. 순서대로 해보면 됨.

• 서비스 상태 확인 — Get-Service IKEEXT로 실행 여부를 봄. 자산 관리 도구가 있다면 조직 전체를 한 번에 뽑는 게 훨씬 빠름.
• 리스닝 포트 확인 — Get-NetUDPEndpoint -LocalPort 500,4500로 실제로 대기 중인지 봄. 서비스가 떠 있어도 정책이 없으면 소켓이 안 열리는 경우가 있어서 둘을 같이 봐야 함.
• 경계에서 확인 — 방화벽·클라우드 보안그룹 규칙에서 UDP 500과 4500이 외부로 열린 대상이 있는지 훑음. 예전에 VPN 테스트하다 열어두고 잊은 규칙이 이런 순간에 발목을 잡음.
• 정책 확인 — Get-NetIPsecRule이 비어 있다면 그 시스템은 IPsec을 사실상 안 쓰는 것임. 서비스를 유지할 이유가 없는 후보군임.

탐지: 무엇을 신호로 볼 것인가

메모리 손상 계열은 시그니처로 잡기 어렵지만, 실패의 흔적은 꽤 시끄럽게 남는 편임. 익스플로잇은 성공보다 실패가 압도적으로 많고, 실패는 곧 프로세스 종료로 나타남.

• 서비스 비정상 종료·자동 재시작 — 시스템 로그에서 서비스 제어 관리자가 남기는 종료/복구 이벤트(7031, 7034)를 IKEEXT 기준으로 걸어둠. 평소엔 거의 안 뜨는 이벤트라 오탐 부담이 적음.
• WER 크래시 리포트 — 응용 프로그램 오류 및 Windows Error Reporting 항목에서 해당 서비스 호스트가 반복 등장하는지 봄. 힙 손상은 종종 STATUS_HEAP_CORRUPTION 계열 코드로 남음.
• 비정상 IKE 트래픽 패턴 — 짧은 시간에 다수의 협상 시작 패킷이 몰리거나, VPN 피어가 아닌 낯선 대역에서 500·4500번으로 유입되는 흐름. NetFlow만 있어도 잡히는 수준임.
• 사후 행위 탐지 — 서비스 호스트 프로세스가 갑자기 스크립트 해석기나 셸을 자식으로 띄우는 순간. 결국 공격자는 뭔가를 실행해야 하고, 그 지점이 EDR이 가장 자신 있어 하는 구간임.

완화: 순서를 정해서 처리하기

급한 순서대로 정리하면 이렇게 됨.

• 패치가 1순위임 — 더블 프리는 설정으로 우회할 수 있는 종류의 결함이 아님. 공급업체 수정이 정답이고 나머지는 시간을 버는 수단일 뿐임.
• 노출 축소 — 인터넷 경계에서 UDP 500·4500 인바운드를 차단하고, VPN 게이트웨이처럼 정말 필요한 장비만 예외로 남김. 내부에서도 IPsec을 쓰는 세그먼트로 출발지를 제한하면 표면이 크게 줄어듦.
• 안 쓰는 곳은 서비스 정지 — 개인적으로는 이 방법을 추천하는데, 조건이 붙음. IPsec 규칙이나 DirectAccess, L2TP 계열 VPN을 쓰는 환경에서 이걸 끄면 연결이 통째로 죽음. 반드시 소규모 그룹에 먼저 적용해보고 확대하는 게 안전함.
• 완화 기능 확인 — 익스플로잇 보호와 힙 무결성 관련 완화가 꺼져 있지 않은지 점검. 이런 완화들은 공격을 막아준다기보다 안정적인 악용을 어렵게 만들어 실패율을 올리고, 그 실패가 앞서 말한 탐지 신호가 됨.

정리하며

이번 건에서 개인적으로 가장 크게 남은 교훈은 결함의 종류가 아니라 "안 쓰는데 켜져 있는 것들" 쪽임. IKEEXT처럼 기본으로 살아 있는 서비스는 평소엔 존재감이 없다가, 이런 CVE가 나오는 날 한꺼번에 자산 전체가 대상이 됨. 취약점 하나 대응하는 것보다, 이참에 우리 시스템에서 아무도 쓰지 않는 서비스와 포트 목록을 한 번 정리해두는 게 훨씬 오래 가는 방어라고 봄.

오늘 당장은 세 줄만 해도 충분함. IKEEXT 실행 여부 확인, UDP 500·4500 외부 노출 점검, 그리고 서비스 크래시 이벤트에 알림 하나 걸어두기. 다들 자기 환경에서 한 번씩 돌려보고, 우리 쪽은 이렇게 나왔다는 결과 댓글로 공유해 주시면 저도 같이 배우겠음. 같이 해보아요!