공격자들, 라우팅 기반 VPN 노출 가능

 (leviathansecurity.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • TunnelVision(CVE-2024-3661) 은 DHCP의 기존 기능을 악용해 사용자의 트래픽을 VPN 터널 밖으로 우회시키며, 이때 패킷은 VPN으로 암호화되지 않음
  • 공격자는 DHCP option 121로 더 구체적인 라우트를 주입해 VPN 가상 인터페이스보다 우선되는 경로를 만들고, 트래픽을 물리 인터페이스로 보낼 수 있음
  • 대상이 공격자 제어 DHCP 임대를 수락하고 클라이언트가 option 121을 구현하면 공격이 가능하며, 테스트에서는 Windows, Linux, iOS, macOS가 영향받고 Android는 제외됨
  • VPN 제어 채널은 계속 유지돼 사용자는 연결 상태로 보게 되며, 관찰된 사례에서는 kill switch도 트래픽 누출을 막지 못함
  • Linux의 네트워크 네임스페이스는 강한 해결책이 될 수 있지만, 방화벽 기반 완화는 선택적 서비스 거부와 트래픽 목적지 추론 사이드 채널을 만들 수 있음

TunnelVision이 만드는 VPN decloaking

  • TunnelVision은 VPN 캡슐화를 우회해 사용자의 트래픽을 터널 밖으로 강제로 보내는 네트워크 기법임
  • 공격자는 DHCP(Dynamic Host Configuration Protocol)를 이용해 대상 패킷이 VPN으로 암호화되지 않은 채 전송되게 만들 수 있음
  • VPN 제어 채널은 유지되므로 사용자는 계속 VPN에 연결된 것처럼 보이며, 이 효과가 decloaking으로 불림
  • 이 기법은 2002년까지 거슬러 올라가 가능했을 수 있고, 공개 후 DHCP option 121과 VPN 영향에 대한 선행 연구가 최소 2015년부터 있었다는 정보가 확인됨

VPN 라우팅이 공격 표면이 되는 이유

  • VPN은 호스트 장치와 다른 네트워크의 서버 사이에 트래픽용 터널을 만들고, VPN 클라이언트는 가상 네트워크 인터페이스에서 트래픽을 암호화·복호화함
  • 전체 트래픽을 VPN으로 보내는 구성은 full-tunnel VPN, 로컬 네트워크 등 예외가 있는 구성은 split-tunnel VPN으로 부름
  • VPN은 서버와의 연결을 유지해야 하므로, VPN 서버 IP로 향하는 트래픽을 물리 인터페이스로 보내는 예외 라우트가 필요함
  • 라우팅 테이블은 목적지에 따라 트래픽 경로를 정하며, 대부분의 네트워크 스택에서는 더 구체적인 CIDR prefix length가 높은 우선순위를 가짐
    • /32 라우트는 /24나 /0보다 우선됨
    • 많은 full-tunnel VPN은 0.0.0.0/0 또는 두 개의 /1 라우트로 트래픽을 VPN 인터페이스에 보냄

DHCP option 121을 이용한 경로 주입

  • DHCP는 로컬 네트워크 장치에 IP 주소 임대를 동적으로 제공하고, options를 통해 기본 게이트웨이와 DNS 서버 같은 설정도 전달함
  • 일반적인 흐름은 클라이언트가 DHCPDISCOVER를 브로드캐스트하고, 서버가 DHCPOFFER로 시간 제한이 있는 임대를 제안하는 방식임
  • RFC 3442에서 도입된 DHCP option 121은 classless static routes 기능으로, DHCP 서버가 클라이언트 라우팅 테이블에 정적 라우트를 추가할 수 있게 함
  • option 121은 DHCP 서버가 설치할 라우트의 네트워크 인터페이스 장치를 직접 지정하지 못함
    • DHCP 서버는 CIDR 범위와 라우터를 지정함
    • 클라이언트는 DHCP 서버와 통신 중인 인터페이스를 해당 라우트의 인터페이스로 암묵적으로 선택함
  • 이 동작 때문에 주입된 라우트의 트래픽은 VPN 가상 인터페이스가 아니라 DHCP 서버와 통신하는 물리 네트워크 인터페이스로 나갈 수 있음

공격 조건과 수행 방식

  • TunnelVision 공격에는 두 조건이 필요함
    • 대상 호스트가 공격자 제어 DHCP 서버의 임대를 수락해야 함
    • 대상 호스트의 DHCP 클라이언트가 DHCP option 121을 구현해야 함
  • 같은 네트워크에 있는 공격자는 여러 방식으로 대상의 DHCP 서버가 될 수 있음
    • 실제 DHCP 서버에 DHCP starvation 공격을 수행한 뒤 새 클라이언트에 응답
    • DHCPDISCOVER 브로드캐스트에 먼저 응답해 DHCP 클라이언트의 first-offer 선택 동작 악용
    • ARP spoofing으로 실제 DHCP 서버와 클라이언트 사이 트래픽을 가로챈 뒤 임대 갱신 대기
  • 공격자는 대상 VPN 사용자와 같은 네트워크에서 DHCP 서버를 실행하고 자신을 게이트웨이로 설정함
  • 이후 DHCP option 121로 VPN 사용자의 라우팅 테이블에 임의 라우트를 추가하고, VPN의 /0보다 더 구체적인 라우트를 넣어 VPN 가상 인터페이스보다 우선되게 함
    • 여러 /1 라우트를 설정해 대부분 VPN이 쓰는 0.0.0.0/0 전체 트래픽 규칙을 재현할 수 있음
    • 공격자는 어떤 IP 주소가 VPN 터널로 가고 어떤 주소가 공격자 DHCP 서버와 통신하는 인터페이스로 갈지 선택할 수 있음
  • 이미 설정된 VPN 연결에도 적용 가능하며, DHCP 임대 시간을 짧게 설정하면 라우팅 테이블 갱신을 더 자주 유도할 수 있음

PoC와 실험 시나리오

영향받는 운영체제와 VPN

  • 테스트에서는 RFC 사양에 따른 DHCP 클라이언트를 구현하고 DHCP option 121 라우트를 지원하는 운영체제가 영향을 받음
    • 영향 관찰: Windows, Linux, iOS, macOS
    • 예외: Android는 DHCP option 121을 지원하지 않아 영향을 받지 않음
  • 호스트 트래픽 보호를 라우팅 규칙에만 의존하는 VPN은 취약함
  • 자체 VPN 서버를 운영하는 시스템 관리자도 VPN 클라이언트 구성을 강화하지 않았다면 취약할 가능성이 있음
  • 암호화 알고리듬의 강도는 영향을 주지 않음
    • TunnelVision은 WireGuard, OpenVPN, IPsec 같은 VPN 프로토콜 자체를 깨지 않음
    • 운영체제 네트워크 스택의 라우팅 구성을 바꿔 사용자가 VPN 터널을 쓰지 않게 만드는 방식임

수정과 완화책

  • Linux의 네트워크 네임스페이스는 이 동작을 완전히 고칠 수 있음
    • WireGuard 문서는 VPN을 사용해야 하는 애플리케이션 트래픽을 별도 네임스페이스에서 처리한 뒤 물리 인터페이스가 있는 다른 네임스페이스로 보내는 방법을 보여줌
    • Windows, macOS, 기타 운영체제에서 같은 수준으로 견고한 해결책이 있는지는 불분명함
  • 일부 VPN 제공자는 물리 인터페이스의 모든 인바운드·아웃바운드 트래픽을 방화벽 규칙으로 차단하는 완화를 사용함
    • LAN과 VPN 서버 연결 유지를 위해 DHCP와 VPN 서버 IP 예외가 필요함
    • 심층 패킷 검사로 DHCP와 VPN 프로토콜만 허용할 수도 있지만 성능 페널티가 있을 가능성이 있음
  • 방화벽 완화는 DHCP 라우트를 사용하는 트래픽에 선택적 서비스 거부를 만들고 사이드 채널을 추가함
    • 공격자는 VPN 암호화 트래픽의 볼륨 변화를 분석해 대상 사용자가 특정 목적지로 트래픽을 보내는지 통계적으로 입증할 수 있음
    • 사전 정의된 목록과 대조하거나, 검열 메커니즘으로 선택적 차단을 수행하거나, IP 공간 차단을 이진 탐색처럼 사용해 현재 연결을 로그 시간에 찾을 수 있음
  • VPN 사용 중 option 121을 무시하는 방법도 있지만, 이 기능은 합법적 네트워크 연결에 필요할 수 있어 연결 장애를 만들 수 있음
    • 이 완화가 선택 사항이면 공격자가 네트워크 접근을 거부해 VPN이나 사용자가 option 121을 다시 켜도록 유도할 수 있음
  • 핫스팟이나 VM도 완화에 도움이 될 수 있음
    • 셀룰러 장치가 제어하는 비밀번호 잠금 LAN은 공격자의 로컬 네트워크 접근을 막는 데 도움이 됨
    • VM은 네트워크 어댑터가 bridged mode가 아니면 유사하게 동작함

사용자와 운영자에게 필요한 조치

  • 민감한 트래픽에는 신뢰할 수 없는 네트워크 사용을 피하고, 불가피하면 TunnelVision에 효과적인 완화책이 있는 VPN 제공자를 사용해야 함
  • VPN decloak이 발생해도 HTTPS 웹사이트에 접속하는 경우 대부분의 사용자 데이터는 로컬 네트워크 공격자에게 보이지 않지만, 목적지와 프로토콜은 노출될 수 있음
  • 기업 VPN을 카페, 호텔, 공항 등에서 쓰는 경우 네트워크 관리자는 위험을 알리고 가능한 한 피하도록 안내해야 함
    • 실용적이지 않다면 완화나 수정이 적용된 VPN 사용을 안내해야 함
    • 신뢰할 수 있는 핫스팟을 사용한 뒤 VPN에 연결하거나, 가상 DHCP 서버에서 임대를 받는 VM 안에서 VPN을 실행하는 방식도 가능함
  • 자체 네트워크나 site-to-site VPN을 운영하는 회사는 스위치를 점검하고 DHCP snooping과 ARP 보호 같은 Layer 2 보호 기능을 켜야 함
    • 이런 보호는 rogue DHCP 서버를 줄이는 데 도움이 되지만 악성 관리자 시나리오는 제거하지 못함
    • 내부 리소스에 HTTPS 또는 다른 암호화 프로토콜을 적용하면 신뢰할 수 없는 네트워크에서 접속한 VPN 사용자의 데이터 누출을 막는 데 도움이 됨
  • VPN 제공자는 네트워크 인터페이스로 나가는 아웃바운드 패킷을 차단하는 방화벽 기능을 클라이언트에 추가할 수 있지만, 사용자는 로컬 네트워크 리소스와 상호작용하지 못하게 됨
  • Linux용 full-tunnel VPN 클라이언트는 네트워크 네임스페이스를 이용한 격리를 고려해야 함
  • 운영체제 유지보수자는 Linux 외 운영체제에서 네트워크 네임스페이스 관련 기능 추가나 강화를 검토해야 함
  • LAN 보안 연구와 실제 공격 시연을 위한 ArcaneTrickster라는 adversarial infrastructure 라이브러리가 개발 중이며, 나중에 공개될 계획임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이건 2016년 Samy Kamkar의 PoisonTap 공격을 살짝 변형한 것임. USB/Thunderbolt 네트워크 어댑터로 같은 일을 하며, 피해자 장치에 꽂고 0.0.0.0/1과 128.0.0.0/1처럼 더 구체적인 경로 두 개를 광고하면 인터페이스 순서와 상관없이 다른 시스템 인터페이스보다 우선해 모든 트래픽을 가져갈 수 있음: https://github.com/samyk/poisontap
    아마 다른 선행 사례도 있을 텐데, 이건 아주 잘 알려진 사례임. 글 제목에서는 모든 VPN 클라이언트가 영향을 받는다고 하지만, 본문에서도 인정하듯 많은 VPN 클라이언트는 물리 인터페이스로 오가는 트래픽을 막는 방화벽 규칙을 설정함
    신원 은닉을 내세우거나 그런 은닉이 중요한 VPN은 대체로 이를 구현하는 편임. 기본값으로 켜져 있지 않은 설정도 많겠지만, 주요 개인/상용/기업 VPN 솔루션 중 몇 퍼센트가 기본으로 이를 켜는지 문서화했으면 더 생산적이었을 것 같음
    일반 독자를 위한 설명은 좋지만, 이런 방화벽 규칙으로 대부분의 데이터 유출을 막는 클라이언트가 많고 이 분야의 선행 사례를 인정하지 않는 점을 보면 제목은 약간 과장돼 보임

    • 잘 짚었음. 기본적인 방화벽 규칙조차 없어 이미 많이 새고 있을 가능성이 큰 VPN을 제외하면 별일 아닌 취약점임
      “부채널 공격”이라는 표현도 보다가 음료를 뿜을 뻔했음
      수정: 보니 NordVPN은 적어도 mac에서는 그런 기본 방화벽 규칙이 없어서 이 공격에 취약한 듯함

  • 이 글이 왜 이렇게 긴지 모르겠음
    DHCP Option 121은 DHCP 서버가 특정 CIDR 범위에 대한 라우팅 규칙을 설정하게 해주며, 더 긴 접두사라서 기본 0.0.0.0/0 규칙보다 우선순위가 높아짐

    • 글 작성자 중 한 명임. 비기술 배경 독자도 들어올 거라고 봐서 관련 주제를 먼저 설명하려는 의도였음
      인터넷에 있는 VPN 정보의 절반은 VPN 제공업체가 쓴 것이고, 실제로 어떻게 동작하는지 설명하기엔 부정확하거나 충분히 기술적이지 않음
      도입부에 “이미 아는 내용이면 POC 섹션으로 건너뛰라”는 문장을 링크로 넣으려 했는데, 더 잘 보이도록 업데이트하겠음
    • 그리고 공격자가 이 공격을 유발하려면 피해자와 같은 2계층 네트워크에 있어야 함
      글은 안 읽고 위 댓글만 보고 하는 추측임

  • 예전에 다른 작성자에게서 이 공격을 읽은 것 같아서 찾아봤고, 검색 결과에 쏟아지는 VPN 업체 스팸을 헤치고 선행 작업 [1]을 찾았음
    이번 글은 결함을 악용하는 방법을 더 깊게 다루고, 개념증명에 도움이 되는 코드도 있음
    1: https://www.usenix.org/conference/usenixsecurity23/presentat...

    • 그 논문은 부록에서 참조하고 있음
      다만 2023년 8월 논문에 나온 두 기법 모두 DHCP option 121로 경로를 푸시하지는 않았음. DHCP로 경로를 푸시하면 같은 공격자 위치에서 훨씬 영향이 커짐. 예를 들어 비-RFC1918 범위의 IP 임대를 나눠주거나 DNS 응답을 위조할 수 있는 위치임
    • 이 “공격”은 널리 알려져 있고, OpenVPN 클라이언트의 설정 옵션인 redirect-gateway def1로도 쓰임

  • 위협 모델은 임의의 공격자가 어떻게든 내 LAN에서 DHCP 서버가 될 수 있다는 것인데, 가능성은 낮지만 불가능하진 않음
    반대로 ISP가 제공한 게이트웨이 장치를 쓰고 있다면 이야기가 달라짐

    • “임의의 공격자가 내 LAN에서 DHCP 서버가 된다”는 게 가능성 낮지만 불가능하다는 얘기라면, 카페 와이파이가 바로 그런 상황 아닌가?
      대다수 VPN 상품의 1번 판매 포인트가 그거임
      이 경우 올바른 대응은 4G/5G 연결을 쓰고, 신뢰하지 않는 수상한 네트워크에는 연결하지 않는 것임
    • “그 DHCP 서버”라는 표현은 네트워크 안에 특별한 장치가 따로 있다는 전제를 깔고 있는데, 그 전제가 잘못됐음. DHCP는 브로드캐스트 프로토콜이고 장치는 첫 번째 제안을 받아들임
      일반 가정에서는 DHCP가 라우터에서 제공되고 그래서 보통 가장 먼저 응답한다는 사실은 부차적임. 네트워크 안의 악성 장치라면 누구나 이 취약점을 사용할 수 있음
    • VPN의 큰 사용 사례 중 하나가 내가 연결한 네트워크를 신뢰할 수 없을 때 아닌가?
    • 또는 내가 연결한 제3자 와이파이에서 DHCP 서버가 되는 경우도 있음
    • 신뢰할 수 없는 와이파이 네트워크에서 보호해준다는 건 VPN이 흔히 광고하는 이유 중 하나임

  • Linux에서는 VPN 인터페이스를 VRF에 넣어서도 완화할 수 있음. 예를 들어 systemd-networkd는 이를 기본으로 지원함
    주의할 점은 VRF를 켜면 l3mdev용 ip rule 항목은 1000으로 잡히지만 로컬 트래픽 규칙은 0으로 잡힌다는 것임. 로컬 규칙을 1000 이상으로 옮겨야 함

    • 요즘은 앱을 특정 VRF에서 실행하는 방법이 있나?

  • 이 “공격”은 DHCP option 121을 영리하게 쓴 것일 뿐임. 심하게 망가진 클라이언트 설정에는 유효한 공격임
    기본 경로를 바꾸거나 /1 경로 두 개로 덮어쓰고 VPN 종단점으로 가는 호스트 경로를 추가하는 방식은 안전하지 않음. 캡슐화된 트래픽을 하위 네트워크에서 제대로 격리하려면 정책 기반 라우팅을 써야 함. 예를 들어 Linux 네트워크 네임스페이스, FreeBSD vnet, OpenBSD rdomains 같은 것들임
    패킷 필터와 사용자 공간 “킬 스위치”를 억지로 엮어 만들려는 방식은 설계부터 깨져 있고, 흔한 VPN 호스팅 업체들이 자기 핵심 역량이라는 것조차 얼마나 이해하지 못하거나 신경 쓰지 않는지 보여줌. 오래된 “나쁜 것 열거하기” 문제가 또 나온 셈임

  • 새삼스러운 일도 아님
    시스템에서 IPv6가 켜져 있는데 IPv4 전용 VPN 서비스를 쓰는 사람들이 더 걱정됨
    그건 정말 크게 잘못될 수 있음

  • 클라이언트 장치에서 VPN을 우회하는 방법은 아주 많음. 그래서 VPN이 필요할 때는 클라이언트와 인터넷 사이에, VPN 터널을 종료하고 다른 경로가 없는 라우터를 두는 편을 선호함
    이런 여행용 라우터는 아주 쉽게 설정해서 어디든 들고 다닐 수 있고, 실제로 그렇게 하고 있음

    • 집에서는 각 라우터가 자기 와이파이 네트워크를 갖는 전용 VPN 라우터를 강하게 추천함. 각 장치에서 VPN 소프트웨어를 로컬로 돌리는 것보다 연결이 쉽고 더 안정적이라고 봄
      예를 들어 직장 인트라넷으로 VPN 연결을 항상 유지하는 “work” 와이파이 라우터가 있고, 호주 TV를 보고 싶을 때마다 호주 서버로 VPN을 연결하는 “Australia” 와이파이가 있으며, 마지막으로 일반 가정 인터넷 와이파이가 있음
      오래된 와이파이 라우터 몇 대만 있으면 아주 쉽게 할 수 있고, 요즘 저렴한 가정용 라우터도 어느 정도 VPN 지원은 하는 듯함. VPN 설정을 중앙화해 실수할 여지를 줄이는 것 말고도, 어떤 장치든 해당 와이파이에 붙기만 하면 VPN을 쓸 수 있다는 큰 장점이 있음
      여러 낡은 라우터로 이렇게 쓰고 있지만, 사실 하나의 가정용 라우터가 세계 여러 위치로 VPN을 맺고 위치별로 다른 와이파이 네트워크를 제공하는 제품 시장도 있을 것 같음. TV/Roku/iPad가 손쉽게 다른 지역에서 접속한 것처럼 보이게 하려는 용도임
    • 이 공격은 로컬 LAN에 신뢰할 수 없는 장치가 있을 때만 가능함. 이미 VPN이 올라간 게이트웨이를 직접 들고 다닌다면, 신뢰할 수 없는 LAN 장치는 그리 큰 걱정이 아닐 듯함
      다만 LAN에 신뢰할 수 없는 장치가 있고 DHCP를 쓴다면, 그 장치는 이 기법으로 암호화되지 않은* 트래픽을 엿볼 수 있음. 그래도 게이트웨이가 숨겨주기 때문에 실제 IP는 찾지 못함
      이 공격이 가장 현실적인 곳은 카페 와이파이 같은 상황임. 그런 곳에 자기 라우터를 들고 갈 가능성은 낮음
      여기서 “암호화되지 않은 트래픽”은 VPN 제공업체로 전송되도록 캡슐화되지 않은 트래픽을 뜻함. 요즘은 대부분 HTTPS라서 그 트래픽의 내용 자체는 여전히 암호화돼 있을 것임
    • 쓸 만한 하드웨어와 소프트웨어를 몇 가지 나열해주면 수고를 덜 수 있을 듯함
    • 대부분의 여행용 라우터도 여전히 이 문제에 취약할 것 같음

  • 기술적인 사람에게는 꽤 뻔했어야 하는 내용이지만, 네트워킹과 VPN 입문 설명으로는 좋음. Linux VPN 게이트웨이 VM을 몇 번 구성해봤는데, 라우팅 테이블에만 의존하는 구조는 늘 취약하게 느껴졌고, 특히 그 연결을 쓰는 같은 머신에서 실행될 때 더 그랬음
    네트워크 네임스페이스와 물리 VPN 게이트웨이 라우터에 더해, VM 기반 아키텍처도 이 문제를 풀 수 있음. 내 홈랩에서는 방화벽이 VPN 게이트웨이 VM에서 나오는 예상 밖 트래픽을 막음. VPN VLAN의 장치들은 외부로 직접 연결할 수 없고, 게이트웨이 VM은 외부 연결용 별도 VLAN을 가짐
    개인용 해법으로는 QubesOS가 비슷한 구성을 꽤 마찰 없이 설정하게 해주지만, 역시 일반 OS보다 더 많은 기술 지식이 필요함

  • “Android는 DHCP option 121 지원을 구현하지 않았기 때문에 유일하게 영향을 받지 않았다”는 부분이 흥미로움
    Google이 이 문제를 알고 의도적으로 내린 결정이었는지, 완전히 우연이었는지 궁금함

    • https://issuetracker.google.com/issues/117544989를 보면 Google은 이 기능 요청을 이유도 제시하지 않고 대체로 무시한 것 같음. 나도 같은 점이 궁금함. 내부 Buganizer에 접근 가능한 Google 직원이라면 더 알지도 모름
      추측하자면 Android 네트워킹 팀은 IPv6에 매우 우호적임. IPv4의 빠진 틈새 기능에는 별 관심이 없는 것 같음. IPv6에 대해서도 어떻게 써야 하는지 특정한 비전이 있어서, 상태 저장 DHCPv6 같은 기능을 의도적으로 지원하지 않는 결과가 나옴
    • DHCP 옵션은 아주 많아서, Android 같은 경우에는 최소한만 지원하는 것부터 시작하고, 어떤 옵션에 대한 요구가 올라올 때만 추가 지원을 켜는 전략이 타당함
      이 DHCP 옵션은 흔히 쓰이지 않으므로, 그런 전략을 쓰면 보안 우려와 무관하게 지원되지 않았을 가능성이 큼
    • Android는 21년 전에 처음 정의된 새 DHCP 버전조차 구현하지 않았음: https://www.rfc-editor.org/rfc/rfc3315
      그러니 그리 놀랄 일은 아님
답변달기