[단독방어] 분석 — CVE-2026-43024

• 심각도 medium · CVSS 5.5 · EPSS 0.00129 · 악용난이도 hard

본 취약점은 로컬 사용자가 netfilter nf_tables 인터페이스에 즉시 NF_QUEUE 결정을 전달하도록 트리거할 수 있습니다. arp 패밀리는 큐를 지원하지 않음에도 불구하고, 커널 내부 경로에서 바로 NF_QUEUE 판정이 도달하게 되며, 이는 커널이 해당 패킷을 대기열에 넣지 못하고 처리 루틴을 중단시켜 시스템 전체의 네트워크 스택을 마비시킬 수 있습니다.

악용 가능성: AV가 L(Local)이라는 점은 공격자가 해당 호스트에 직접 접근해야 함을 의미합니다. AC가 L(Low)이고 UI가 N(No Interaction)인 만큼, 특수한 입력이나 순서 없이 간단히 nf_tables Netlink 메시지를 전송하면 충분합니다. PR이 L(Low)이라는 점은 루트 권한이 아니더라도 네임스페이스 내에서 제한된 권한만 있으면 해당 취약점을 이용할 수 있음을 나타냅니다. 실제 공격 경로는 nftables 사용자‑공간 도구가 내부적으로 사용하는 Netlink 인터페이스이며, 특히 ARP 패밀리에서 즉시 NF_QUEUE 판결을 전달하도록 조작된 규칙을 삽입하면 트리거됩니다. EPSS = 0.00129라는 매우 낮은 확률에도 불구하고, 공격이 성공할 경우 커널 네트워크 필터링 로직을 우회하거나 임의의 패킷을 큐에 넣어 후속 악성 처리를 가능하게 하므로 이론적 심각도와 무관하게 실질적인 위협으로 간주됩니다. KEV 목록에 등재되지 않은 점은 아직 대규모 공격이 보고되지 않았음을 뜻하지만, 로컬 권한만으로 복잡도가 낮은 전개가 가능한 hard 등급 평가는 여전히 방어 차원에서 주의가 필요함을 설명합니다.

즉시 NF_QUEUE 결정을 강제하면 커널이 해당 흐름을 정상적으로 처리하지 못해 서비스 가용성이 크게 저하됩니다(Availability High). 다른 보안 속성(C, I)은 영향을 받지 않으며, 공격자는 로컬 권한(L)만으로도 복구가 어려운 DoS 상황을 유발할 수 있습니다.

NF_QUEUE와 연관된 기존 CVE(예: 과거 nf_tables‑related 버그)는 커널 내부 검증 부족을 이용해 임의 코드 실행이나 권한 상승을 시도하는 경우가 있었습니다. 현재 취약점은 바로 그 검증 로직 중 “즉시 NF_QUEUE 판정”만을 차단함으로써, 동일 경로를 활용한 추가적인 권한‑상승 체이닝을 방어합니다.

• 로그 지표

  • audit.log (또는 kern.log)에 기록되는 netlink 메시지 중 NFNL_SUBSYS_NFTABLES와 NFQUEUE 플래그가 동시에 나타나는 경우. 예: msgtype=NFT_MSG_NEWRULE verdict=NF_QUEUE immediate=1.
  • dmesg 출력에서 “nf_tables: reject immediate NF_QUEUE verdict” 와 같은 경고 메시지가 발생하면 시도된 공격을 의미합니다.

• SIEM 쿼리 예시 (Elastic Kibana)

  text복사

   1// 즉시 NF_QUEUE 판정 감지
   2event.module:"auditd" and audit.type:"netlink" 
   3  and message:*"NFQUEUE"* and message:*"immediate=1" 
   4  and process.name:"nft"

• 정규식 기반 탐지 (Suricata)

  text복사

   1- rule_id: 1000010
   2  description: "Detect immediate NF_QUEUE verdict in nf_tables netlink messages"
   3  match:
   4    payload:
   5      regex: 'NFNL_SUBSYS_NFTABLES.*verdict=NF_QUEUE.*immediate=1'
   6  action: alert

• 오탐 튜닝

  • 정상적인 nft rule 업데이트 시 immediate 필드가 존재하지 않으므로, 위 조건을 만족하는 경우만 알림으로 제한합니다.
  • arp family에 대한 규칙이 없을 때 발생하는 로그는 무시하도록 process.args:*arp* 를 추가해 필터링합니다.

1. nftables 규칙으로 즉시 NF_QUEUE 차단

   text복사

    1nft add rule inet filter arp reject verdict nfqueue num 0 immediate

   구현 난이도: 중간 → 기존 nft 테이블에 한 줄 추가만 필요합니다.
   운영 영향: arp 트래픽에 대한 NF_QUEUE 사용을 완전히 차단하므로, 해당 기능을 의존하는 특수 애플리케이션은 일시적 장애가 발생할 수 있습니다.
   검증 방법: nft list ruleset 로 규칙이 적용됐는지 확인하고, 공격 시도 로그가 더 이상 기록되지 않는지 관찰합니다.

2. 감사 정책 강화

   • /etc/audit/rules.d/nf_tables.rules 에 다음을 추가하여 모든 nft 명령 호출을 기록합니다.

 1-a always,exit -F arch=b64 -S netlink -F subj_type=nft_t -k nf_queue_attempt

구현 난이도: 낮음 → 파일 편집 후 auditctl -R 로 적용.
운영 영향: 로그 양 증가(소량) 외 별도 영향 없음.
검증 방법: ausearch -k nf_queue_attempt 로 이벤트가 수집되는지 확인합니다.

• 조치: monitor (모니터링)
• 근거: CVSS=5.5 · non-KEV · EPSS=0.00129 · exploit=hard · in_scope=None