Wi-Fi 네트워크가 VPN을 무력화하는 방법

VPN 앱에 '연결됨'이라고 표시되어 있더라도 신뢰할 수 없는 네트워크에서는 이 상태가 기만적일 수 있다.

CVE-2024-3661(리바이어던 세큐리티의 '터널비전(TunnelVision)') 취약점을 이용하면 네트워크 운영자나 악성 DHCP 서버가 네트워크 임대 정보에 맞춤형 경로(route)를 주입할 수 있다. 이를 통해 암호화되지 않은 트래픽을 공격자가 제어하는 기기로 우회시킬 수 있다.

리눅스(Linux) 머신에서 이 VPN 트래픽 유출을 직접 재현해보았다. 아래에서는 어떤 트래픽이 유출되는지, 공격이 왜 감지되지 않고 유지되는지, 그리고 이를 방지하는 방법을 다룬다.

VPN이 켜져 '연결됨'으로 표시된 노트북. 대부분의 트래픽은 초록색 터널 안으로 흐르지만, 빨간 점선으로 표시된 한 줄기는 터널을 벗어나 로컬 Wi-Fi를 통해 평문으로 근처 공유기로 빠져나간다.

DHCP란 무엇인가?

기기가 Wi-Fi 네트워크에 접속하면 DHCP(동적 호스트 설정 프로토콜) 서버에 설정을 요청한다.

일반적으로 서버는 IP 주소, 기본 게이트웨이, DNS 서버 정보를 제공한다.

DHCP 프로토콜(RFC 3442)의 일부인 옵션 121(Option 121)은 정적 경로 옵션을 정의한다.

옵션 121은 운영체제의 라우팅 테이블에 맞춤형 경로를 직접 주입한다.

사용자의 DHCP 클라이언트는 출처를 검증하거나 네트워크 신뢰성을 확인하지 않고 이러한 경로를 자동으로 적용한다.

공격 원리

전체 터널(Full-tunnel) VPN은 모든 트래픽을 보안 터널로 라우팅한다. 대부분의 클라이언트는 0.0.0.0/1과 128.0.0.0/1이라는 두 개의 넓은 경로를 생성하여 이를 구현한다.

이 두 IP 범위는 인터넷 전체를 아우르며 표준 기본 경로보다 우선 적용된다.

라우팅 결정은 항상 가장 구체적인 일치 항목(가장 긴 서브넷 프리픽스)을 우선시한다. /32 호스트 경로는 /1 프리픽스보다 더 구체적이므로, DHCP를 제어하는 주체(카페 공유기, 악성 트윈, 악성 서버 등)는 특정 IP 주소를 타깃으로 하는 옵션 121 경로를 전달할 수 있다.

VPN 앱이 계속 '연결됨' 상태를 표시하는 동안에도 해당 IP 주소로 전송되는 트래픽은 암호화를 우회하여 평문으로 유출된다.

2024년 5월 6일 리바이어던 세큐리티가 CVE-2024-3661(CVSS 7.6)로 공개한 이 취약점은 Windows, macOS, iOS, Linux 모두에 영향을 미친다.

Android는 네트워크 스택이 DHCP 옵션 121을 지원하지 않으므로 영향을 받지 않는다.

192.0.2.123으로 향하는 패킷이 갈림길에 도달한다. VPN의 넓은 경로 0.0.0.0/1과 128.0.0.0/1은 터널로 이어지지만, 공격자의 더 좁은 192.0.2.123/32 DHCP 경로가 우선권을 얻어 패킷을 Wi-Fi로 내보낸다.

단일 머신에서 CVE-2024-3661 재현하기

가상 이더넷(veth) 쌍으로 연결된 두 개의 네트워크 네임스페이스를 사용하여 단일 리눅스 머신에서 전체 공격을 재현했다.

공격자(lan): 옵션 121이 설정된 dnsmasq DHCP 서버를 실행한다.
피해자(client): 와이어가드(WireGuard)가 전체 터널을 생성하기 전에 임대 요청을 수락하는 표준 dhcpcd 클라이언트를 실행한다.

악성 서버는 자신을 거치도록 민감한 목적지(192.0.2.123, TEST-NET 주소)를 타깃으로 하는 /32 경로를 제안한다.

--dhcp-option=121,192.0.2.123/32,10.55.0.1

수정되지 않은 클라이언트는 이 경로를 자동으로 설치한다.

vcli: adding host route to 192.0.2.123 via 10.55.0.1

와이어가드가 전체 터널을 초기화한 후, 두 주소에 대한 커널의 라우팅 목적지를 조회했다.

$ ip route get 192.0.2.123
192.0.2.123 via 10.55.0.1 dev vcli src 10.55.0.115

$ ip route get 9.9.9.9
9.9.9.9 dev wg0 src 10.99.0.2

첫 번째 패킷은 vcli(물리 링크)를 통해 나간다. 공격자가 타깃으로 하지 않은 주소로 향하는 두 번째 패킷은 wg0(VPN 터널)를 통해 정상적으로 라우팅된다.

선별적 라우팅 덕분에 타깃이 아닌 트래픽은 정상 작동하며, 이 때문에 공격을 감지하기가 더욱 어렵다.

공격자의 인터페이스에서 tcpdump를 실행하자 암호화되지 않은 프로브 패킷이 포착되었다.

IP 10.55.0.115 > 192.0.2.123: ICMP echo request

'연결됨'으로 표시된 휴대폰. 192.0.2.123으로 가는 패킷은 공격자가 감시하는 로컬 Wi-Fi 링크에서 읽을 수 있는 ICMP echo request 평문으로 나타나고, 9.9.9.9로 가는 트래픽은 터널 안에 암호화된 채 남아 있다.

대응 방안

물리 인터페이스에 VPN 방화벽 규칙 적용: Mullvad의 데스크톱 앱은 공인 IP로 향하는 모든 비터널 트래픽을 차단하여 평문 유출을 막는다. 다만 리바이어던이 지적했듯, 공격자가 특정 패킷을 드롭하여 트래픽 흐름을 분석할 수 있으므로 부채널(side-channel) 공격 및 선별적 서비스 거부(DoS) 위험은 남아 있다.
리눅스 네트워크 네임스페이스 내에 VPN 격리: 독립된 네임스페이스에서 터널을 실행하면 물리 링크와 격리되므로 옵션 121 경로가 탈취할 인터페이스 자체가 사라진다. 리눅스 시스템에서 가장 효과적인 해결책이다.
관리형 네트워크에서 DHCP 스누핑(DHCP Snooping) 활성화: 기업 및 지사 LAN은 악성 DHCP 서버에 노출될 위험이 크다. 관리형 스위치에서 DHCP 스누핑을 활성화하면 승인되지 않은 DHCP 제안을 차단하여 악성 서버의 옵션 121 경로 주입을 막을 수 있다.
민감한 경로에 정책 기반 IPsec VPN 사용: 정책 기반 VPN은 로컬 라우팅 테이블 변경 여부와 관계없이 지정된 규칙에 맞는 트래픽을 암호화하므로, DHCP로 주입된 경로가 패킷을 우회시키는 것을 방지한다.
iOS 사용 시 주의: iOS에는 써드파티 방화벽 도구가 없다. 애플의 includeAllNetworks 플래그가 취약점을 완화할 수 있지만, 터널 헬스 체크를 망가뜨리고 App Store 업데이트를 교착 상태에 빠뜨리는 등 심각한 부작용을 일으킨다.

Panke는 상태 표시줄의 표시를 맹신하지 않고, 신뢰할 수 없는 네트워크에서 실제 트래픽이 어떻게 동작하는지 점검하는 네트워크 및 VPN 진단 서비스를 제공한다. 이동 중 팀의 접속 보안을 점검하고 싶다면 pankeit.com/ko 또는 contact@pankeit.com으로 문의하면 된다.

참고 자료

Leviathan Security Group — TunnelVision (CVE-2024-3661): How Attackers Can Decloak Routing-Based VPNs (2024년 5월 6일)
IETF — RFC 3442: The Classless Static Route Option for DHCPv4 (2002년 12월)
Mullvad — Evaluating the impact of TunnelVision (2024년 5월 7일)
Mullvad — Why we still don't use includeAllNetworks (2025년 3월 26일)
Red Hat — RHSA-2025:0288: NetworkManager security update (2025년 1월 13일)
Fortinet PSIRT — FG-IR-24-170: TunnelVision