AirSnitch: Wi-Fi 네트워크에서 클라이언트 격리를 해소하고 해제하는 방법 [pdf]

Hacker News 의견들

• 내가 보기엔 이런 공격들은 공격자가 이미 피해자의 네트워크에 연결되어 있어야 가능한 것 같음
  대부분은 공항이나 카페 같은 공유 Wi-Fi 환경에서 오래전부터 알려진 공격과 유사해 보임
  새로움은 일부 라우터가 게스트 네트워크와 일반 네트워크 간의 트래픽을 제대로 분리하지 못한 구현 취약점을 악용한다는 점임

  • 공격자는 피해자의 네트워크에 연결할 필요가 없고, 같은 하드웨어에 연결되어 있으면 됨
    Eduroam 사례처럼, 공격자는 Eduroam 자격 증명이 없어도 같은 AP에서 게스트 네트워크를 통해 Eduroam 사용자의 패킷을 가로챌 수 있음
    단일 인증된 네트워크만 있다면 이런 격리 손실은 의미 없으며, 이는 브라우저 샌드박스 탈출이 신뢰된 사이트 하나만 방문할 때 무의미한 것과 같음
  • 논문 공동 저자로서 “Wi-Fi 암호화를 깨뜨린다”는 표현은 오해의 소지가 있다고 생각함
    실제로는 클라이언트 격리 우회를 가능하게 하는 것임
    대학의 오픈 Wi-Fi에서 다른 네트워크(Enterprise SSID 포함)의 트래픽을 가로챈 사례도 있었음
    암호화를 ‘깨는’ 것이 아니라 ‘우회’하는 것임
    단일 SSID를 사용하는 개인용 라우터라면 안전함
  • XFinity처럼 사용자가 낸 요금으로 만든 Wi-Fi를 도시 전체에 공유하는 경우는 어떻게 되는지 궁금함
  • 나도 비슷하게 봄. 클라이언트 격리에 의존하는 환경엔 문제지만 일반 사용자에겐 영향이 적음
    대부분의 인증 쿠키는 TLS로 보호되므로 실제 위험은 제한적임
  • AP는 2.4GHz와 5GHz를 동시에 브로드캐스트할 때 여러 BSSID를 가지며, MAC 중복 검사나 WPA2-PSK의 GTK 공유가 약하면 공격이 쉬워짐
    오래된 하드웨어, 특히 802.11w 이전 장비는 영원히 취약할 것 같음

• AirSnitch는 Wi-Fi의 Layer 1~2 핵심 기능을 악용해 클라이언트 간 동기화 실패를 이용함
  공격자는 같은 SSID뿐 아니라 다른 SSID나 네트워크 세그먼트에서도 양방향 MitM이 가능함
  나는 2000년대 초 WEP 시절부터 이런 걸 경험했기에 지금은 Wi-Fi를 아예 쓰지 않음
  카메라엔 테이프, 안테나는 분리, 이메일도 끊음
  결국 구리선이나 광케이블만이 진정한 보안 수단이라 생각함

  • 1974년 영화 The Conversation을 좋아할 것 같다고 함
  • 나도 비슷한 접근을 함. Wi-Fi는 별도 서브넷으로 분리하고, GrapheneOS를 사용하는 등 가능한 모든 하드웨어 마이크를 제거했음

• 클라이언트 격리는 실제로는 꽤 불편한 기능임
  제조사들은 모든 장치가 하나의 큰 네트워크에서 서로 통신할 거라 가정하지만, 격리되면 Elgato 조명이나 Chromecast 같은 장치가 작동하지 않음

  • 그래도 호텔에서 다른 사람이 내 Chromecast를 조작하는 것보단 낫다고 생각함
    그래서 나는 항상 OpenWRT 기반 여행용 라우터를 들고 다니며, 어떤 네트워크에서도 내 장비들이 집처럼 동작하게 함
  • 클라이언트 격리를 쓰지 않아도 유선과 무선 간 브로드캐스트가 다리(bridge)되지 않아 장치 탐색이 안 되는 경우가 있었음
  • 클라이언트 격리의 본래 목적이 바로 이런 IoT 오용 방지임
    기숙사나 공용망에서는 불편하지만, 다른 사람이 내 장치를 제어하거나 악성코드를 퍼뜨리는 걸 막아줌
  • 특정 프로토콜이나 IP 범위 예외를 두면 편하겠지만, 그만큼 데이터 누출 위험도 커짐

• 기사 제목이 다소 과장된 느낌임
  Wi-Fi 암호화를 깨는 게 아니라, 같은 네트워크 내에서 기기 격리만 무력화하는 수준임

  • 하지만 많은 기업·대학·정부 기관이 네트워크 분리를 위해 클라이언트 격리에 의존하므로, 그들에게는 심각한 문제임
  • 논문 공동 저자로서 “break”보다는 “bypass”라는 표현이 정확하다고 강조함

• 논문을 읽어보니 대부분의 가정용 Wi-Fi는 SSID를 2.4GHz와 5GHz에서 공유하므로 취약할 수 있음
  Radius 인증도 일부 영향을 받을 수 있음
  완화책은 단일 MAC의 AP만 사용하는 것임
  EAP-TLS를 쓰면 안전하지만, 여전히 VLAN 분리가 필요함

  • 집에 게스트 네트워크가 없다면 안전하다는 의견도 있음
  • 공격자는 최소한 하나의 네트워크에 인증해야 하므로 완전한 외부자는 불가능함
  • EAP-TLS는 강력하지만, 동일 AP 내 다른 인증된 장치로부터의 수평 공격은 막지 못함
    내가 일하는 Supernetworks.org에서는 기기별 VLAN과 비밀번호를 제안함

• 이건 정말 큰 문제임
  하나의 AP에서 서로 다른 Wi-Fi 네트워크가 있을 때, 한쪽 네트워크의 클라이언트가 다른 네트워크의 트래픽을 MITM할 수 있음
  대부분의 기업 Wi-Fi가 이런 격리에 의존하고 있음

  • 즉, 게스트 네트워크에 접속한 내가 기업 네트워크의 트래픽을 읽을 수 있다는 뜻임
  • 실제로 많은 AP가 SSID만 여러 개일 뿐, L2/L3 격리 보장이 명시된 사양이 없다는 점이 문제임

• 기사에서 언급된 논문은 AirSnitch: Demystifying and Breaking Client Isolation in Wi-Fi Networks 임

  • 논문 저자 중 한 명이 Hacker News 스레드에서 직접 토론 중임

• 논문을 끝까지 읽어보니 핵심은 “강력한 비밀번호로 보호된 단일 네트워크라면 AirSnitch는 큰 위협이 되지 않는다”는 점임

  • 하지만 보안 네트워크와 게스트 네트워크가 같은 AP를 공유하면, 게스트 쪽에서 보안 네트워크의 클라이언트에 접근할 수 있음
    Xfinity의 자동 게스트 네트워크처럼 비활성화하기 어려운 경우도 있음

• 이 공격은 기본적으로 하나의 SSID에서만 작동함
  Private-PSK/Dynamic-PSK나 EAP/Radius VLAN 속성을 쓰면 완화 가능함
  WPA3/SAE에서는 더 복잡하며, 대부분의 장비가 아직 이를 지원하지 않음

  • Hostapd는 이제 WPA3 다중 비밀번호를 지원함
    spr-networks/super 프로젝트에서 기기별 PSK+VLAN을 구현해 사용 중임
    다만 Apple 기기의 Keychain 동기화와 MAC 랜덤화 때문에 실제 배포가 어렵고, SAE의 구조상 여러 비밀번호를 동시에 시도하기 힘듦

• macOS용 방화벽 추천을 찾고 있음
  내장 방화벽은 거의 쓸 수 없고, 클라이언트 격리가 우회된다면 로컬 방화벽이 더 중요해짐
  개발용 서버를 0.0.0.0에 바인딩해두는데, 공용 Wi-Fi에 연결할 때 포트가 닫혀 있는지 확실히 하고 싶음

  • macOS 방화벽 구조를 깊이 이해한 개발자들이 만든 Little Snitch가 가장 유명함
    공식 사이트
  • 무료 대안으로 LuLu도 있음
  • 나도 Little Snitch를 사용 중임