▲

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

 (leviathansecurity.com)
3P by neo 4달전 | favorite | 댓글 1개
  • VPN은 사용자의 디바이스와 다른 네트워크의 서버 간에 네트워크 트래픽을 위한 터널을 만들어주는 기술임. 이로 인해 만들어진 가상 네트워크는 물리적 네트워크와 동일하게 동작하면서 지리적 위치의 제약을 받지 않음.
  • VPN 클라이언트는 가상 네트워크 인터페이스를 만들고, 트래픽을 암호화/복호화한 후 물리적 네트워크 인터페이스로 보내는 역할을 함.
  • VPN은 사용자를 위해 최대한 사용하기 쉽게 설계되었으며, 로그인하고 버튼을 클릭하는 것 외에는 많은 작업을 요구하지 않음.
  • VPN은 낮은 계층의 네트워크 트래픽을 인터넷으로 전송하기 때문에 호스트의 공격 표면을 실제로 증가시킴. VPN은 LAN 트래픽을 인터넷에서 캡슐화하여 인터넷상에 로컬 네트워크(LAN)를 만듦.
  • VPN은 패킷 암호화와 같은 보상 컨트롤을 사용하여 확장된 LAN 공격 표면을 완화함. 하지만 VPN은 물리적 LAN에 대한 로컬 네트워크 공격으로부터 사용자를 보호하지 않음.

DHCP와 DHCP 옵션 121

  • DHCP는 IP 주소를 동적으로 할당하고 원격으로 디바이스 구성을 조정할 수 있는 옵션을 제공하는 프로토콜임.
  • DHCP 옵션 121은 관리자가 클라이언트의 라우팅 테이블에 정적 경로를 추가할 수 있게 해주는 옵션임.
  • DHCP 옵션 121의 흥미로운 특징은 DHCP 서버가 경로를 설치하는 네트워크 인터페이스 디바이스를 지정할 수 없다는 것임. 대신 DHCP 클라이언트는 해당 옵션에 대한 라우팅 규칙을 설치할 때 DHCP 서버와 통신하는 네트워크 인터페이스를 암시적으로 선택함.

Decloaking 공격 요건 및 과정

  • 공격 대상 호스트는 공격자가 제어하는 DHCP 서버로부터 DHCP 임대를 수락해야 함
  • 공격 대상 호스트의 DHCP 클라이언트는 DHCP 옵션 121을 구현해야 함
  • 공격자는 VPN 사용자와 동일한 네트워크에서 DHCP 서버를 실행하고, DHCP 구성에서 자신을 게이트웨이로 설정함.
  • DHCP 옵션 121을 사용하여 VPN 사용자의 라우팅 테이블에 경로를 설정함.
  • 경로 설정을 통해 네트워크 트래픽은 VPN의 가상 인터페이스가 아닌 DHCP 서버와 통신하는 네트워크 인터페이스를 통해 전송됨.
  • VPN의 암호화된 터널 외부에서 트래픽이 전송되지만, VPN 제어 채널은 그대로 유지되어 VPN은 계속 연결된 것으로 보고됨.

영향을 받는 대상

  • RFC 사양에 따라 DHCP 클라이언트를 구현하고 DHCP 옵션 121 경로를 지원하는 Windows, Linux, iOS, MacOS 등 대부분의 운영체제가 영향을 받음. (Android는 DHCP 옵션 121을 지원하지 않아 영향이 없음)
  • 호스트의 트래픽을 보호하기 위해 라우팅 규칙에만 의존하는 VPN이 취약함.
  • 자체 VPN 서버를 호스팅하는 경우 VPN 클라이언트 구성을 강화하지 않으면 취약할 수 있음.
  • 기본 VPN 프로토콜(WireGuard, OpenVPN, IPsec 등)과 무관하게 VPN이 의존하는 OS 네트워크 스택을 재구성하기 때문에 영향을 받음.

완화 방안 및 한계

  • 리눅스의 네트워크 namespace를 사용하면 이 문제를 완전히 해결할 수 있지만, 일반적으로 잘 구현되지 않음.
  • VPN 제공업체 중 일부는 방화벽 규칙을 통해 물리적 인터페이스에서 인바운드/아웃바운드 트래픽을 차단하는 것을 관찰했지만 부분적인 완화책임.
  • DHCP 옵션 121을 무시하는 것도 가능한 완화 방안이지만 네트워크 연결이 끊어질 수 있음.
  • Hot spot이나 VM을 사용하면 공격자가 로컬 네트워크 액세스 권한을 얻기 어려워지므로 도움이 될 수 있음.
  • 절대적인 트래픽 기밀성이 필요한 경우 신뢰할 수 없는 네트워크 사용을 피하는 것이 최선의 방어책임.

GN⁺의 의견

  • VPN은 물리적 네트워크에서의 LAN 공격을 완화하도록 설계되지 않았기 때문에, 신뢰할 수 없는 네트워크에서 VPN이 고객을 보호한다는 VPN 제공업체의 마케팅 주장은 위험할 수 있음. VPN 제공업체는 TunnelVision에 대한 완화 방안이나 수정 사항을 공개적으로 문서화하고 사용자에게 알려야 함.
  • 기업 VPN은 커피숍, 호텔, 공항 등에서 자주 사용되므로 네트워크 관리자는 직원들에게 이러한 장소에서 일하는 것의 위험성을 알리고 가능한 한 피할 것을 권고해야 함. 또한 내부 리소스에 HTTPS 등의 암호화 프로토콜을 구현하여 신뢰할 수 없는 네트워크에서 연결하는 VPN 사용자로 인한 데이터 유출을 방지해야 함.
  • 대부분의 인터넷 트래픽은 HTTPS로 보호되고 있기 때문에 VPN이 무력화되더라도 대부분의 사용자 데이터는 로컬 네트워크 공격자에게 노출되지 않을 것임. 하지만 민감한 트래픽의 경우 경고가 필요함.
  • 리눅스를 제외한 OS 유지 관리자는 네트워크 namespace와 관련된 기능을 추가하거나 향상시키는 것이 가능한지 확인해야 함.
  • VPN 기술 자체의 보안 속성을 위반하는 것은 아니지만 VPN 제공업체의 보장과는 모순되기 때문에 취약점으로 볼 수 있음. 연구진은 이 기법이 2002년 이후로 가능했을 것으로 추정하며, 영향을 받는 당사자들에게 폭넓게 알리기 위해 연구 결과를 공개하기로 결정함.
▲
neo 4달전  [-]
Hacker News 의견

요약:

  • 이 공격은 2016년 Samy Kamkar의 "Poison Tap" 공격과 유사함. USB/Thunderbolt 네트워크 어댑터를 사용하여 더 구체적인 두 개의 경로를 광고하고 시스템의 다른 인터페이스보다 우선적으로 모든 트래픽을 가로챌 수 있음.
  • 헤드라인에서는 모든 VPN 클라이언트에 영향을 준다고 주장하지만, 많은 클라이언트가 방화벽 규칙을 설정하여 물리적 인터페이스와의 트래픽을 차단함. 주요 개인/상용 및 기업 VPN 솔루션 중 이 기능이 기본적으로 활성화된 비율을 문서화하는 것이 생산적이었을 것임.
  • DHCP 옵션 121을 사용하면 DHCP 서버가 특정 CIDR 범위에 대한 라우팅 규칙을 설정할 수 있음. 이는 더 긴 접두사로 인해 기본 0.0.0.0/0 규칙보다 우선 순위가 높아짐.
  • 이 "공격"은 DHCP 옵션 121을 영리하게 사용한 것임. 제대로 격리하려면 적절한 정책 기반 라우팅(예: 리눅스 네트워크 네임스페이스, FreeBSD vnet, OpenBSD rdomains)을 사용해야 함.
  • 리눅스에서 VPN 인터페이스를 VRF에 배치하여 이를 완화할 수 있음. systemd-networkd는 기본적으로 이를 지원함.
  • 공격자가 LAN의 DHCP 서버가 될 수 있다는 위협 모델은 가능성은 낮지만 불가능하지는 않음.
  • 가상 머신 기반 아키텍처도 이 문제를 해결할 수 있음. QubesOS는 유사한 설정을 매우 쉽게 구성할 수 있게 해줌.
  • 네트워크 네임스페이스에 대한 흥미로운 대안은 커널 네트워킹을 완전히 우회하고 사용자 공간 네트워크 스택을 사용하는 것임.
  • IPv4 전용 VPN 서비스를 사용하면서 시스템에서 IPv6를 활성화하는 것이 더 걱정됨. 심각한 문제가 발생할 수 있음.
답변달기