▲

GN⁺: 안드로이드에서 VPN 터널 밖으로 DNS 트래픽 유출 가능성

 (mullvad.net)
2P by neo 7달전 | favorite | 댓글 1개

Android VPN 터널 밖으로 DNS 트래픽이 유출될 수 있음

다중 DNS 유출 가능성 확인

  • 최근 Android에서 다중 DNS 유출 가능성을 알게 됨
  • Android 자체 버그에서 기인하며, 특정 앱에만 영향을 미침
  • 4월 22일 월요일, Reddit 사용자 보고를 통해 DNS 유출을 알게 됨
    • 사용자가 "VPN 없이 연결 차단" 설정을 켠 상태에서 VPN을 비활성화하고 활성화할 때 DNS 쿼리가 유출되는 것을 발견함
  • 내부 조사를 즉시 시작하여 문제를 확인할 수 있었음
  • 조사 결과 Android에서 DNS 유출을 일으킬 수 있는 더 많은 시나리오를 발견함

발견 사항

Android OS에서 DNS 트래픽이 유출될 수 있는 시나리오 식별:

  • DNS 서버가 구성되지 않은 상태에서 VPN이 활성화된 경우
  • VPN 앱이 터널을 재구성하거나 강제 중지/충돌되는 동안 짧은 시간 동안 발생

유출은 C 함수 getaddrinfo에 대한 직접 호출로 제한되는 것으로 보임:

  • 위에 나열된 시나리오에서 도메인 이름을 확인하는 이 방법을 사용하는 앱은 유출을 일으킴
  • DnsResolver와 같은 Android API만 사용하는 앱에서는 유출을 발견하지 못함
  • Chrome 브라우저는 getaddrinfo를 직접 사용할 수 있는 앱의 예임

_Always-on VPN_과 _Block connections without VPN_이 활성화되어 있는지 여부에 관계없이 위의 내용이 적용됨:

  • 이는 예상되는 OS 동작이 아니므로 OS의 업스트림에서 수정되어야 함

여러 버전의 Android에서 이러한 유출이 발생하는 것을 확인할 수 있었음(최신 버전인 Android 14 포함)

개선 사항

현재 앱은 차단 상태에서 DNS 서버를 설정하지 않음:

  • 앱이 복구할 수 없는 방식으로 터널을 설정하지 못하면 차단 상태로 전환됨
  • 이 상태에서는 트래픽이 기기에서 나가는 것을 중지함
  • 그러나 이 상태에서는 DNS 서버를 설정하지 않으므로 위에 설명된 DNS 유출이 발생할 수 있음
  • 당분간 가짜 DNS 서버를 설정하여 OS 버그를 해결할 예정임
  • 이 수정 사항이 포함된 릴리스를 곧 기대할 수 있음

터널 재연결 중 유출을 앱에서 완화하기는 더 어려움:

  • 여전히 솔루션을 모색 중임
  • 터널 재구성이 발생하는 횟수를 최소화할 수 있지만, 현재로서는 이 유출을 완전히 방지할 수 없다고 생각함

어떤 VPN 앱에서도 이러한 해결 방법이 필요하지 않아야 함을 분명히 해야 함:

  • 도메인 이름을 확인하기 위해 앱이 getaddrinfo를 사용하는 것도 잘못된 것이 아님
  • 대신 사용하는 앱에 관계없이 모든 Android 사용자를 보호하기 위해 OS에서 이러한 문제를 해결해야 함

Google에 문제를 보고하고 개선 사항을 제안했으며 신속하게 해결되기를 바람

재현 단계

다음 단계는 위의 두 번째 시나리오를 재현하며, 여기서 VPN 사용자는 터널 구성을 변경함(예: 다른 서버로 전환하거나 DNS 서버 변경):

  • WireGuard 앱을 사용하는데, 이는 Android VPN의 참조 구현이 되었기 때문임
  • 유출은 아마도 다른 Android VPN 앱으로도 재현할 수 있음을 유의해야 함
  • getaddrinfo를 사용하는 것으로 확인된 앱 중 하나이므로 유출을 트리거하기 위해 Chrome을 사용함

  1. spam_get_requests.html 다운로드

  2. WireGuard 앱과 Chrome 설치

  3. wg1.conf, wg2.conf를 WireGuard로 가져오기

  4. WireGuard 앱에서 wg1 터널을 활성화하고 VPN 권한 허용

  5. Android VPN 설정에서 WireGuard에 대해 "Always-on VPN"과 "Block connections without VPN" 활성화

  6. 라우터에서 tcpdump를 사용하여 데이터 캡처 시작 $ tcpdump -i <INTERFACE> host <IP of android device>

  7. WireGuard와 Chrome을 나란히 보이도록 화면 분할

  8. Chrome으로 spam_get_requests.html 열고 "Start" 누르기

  9. WireGuard 앱에서 wg1과 wg2 사이를 전환하다가 다음 단계에서 유출이 보일 때까지 반복

  10. 라우터에서 다음과 같은 DNS 트래픽 관찰:

    11:50:27.816359 IP Pixel-Tablet.lan.53353 > OpenWrt.lan.53: 11200+ A? 307lf5rgn6-19282-11-50-27-519z.mullvad.test.lan. (65)
11:50:27.816359 IP Pixel-Tablet.lan.48267 > OpenWrt.lan.53: 44347+ A? 307lf5rgn6-19284-11-50-27-579z.mullvad.test.lan. (65) 
11:50:27.816396 IP Pixel-Tablet.lan.16747 > OpenWrt.lan.53: 44584+ A? 307lf5rgn6-19289-11-50-27-729z.mullvad.test. (61)
11:50:27.816458 IP OpenWrt.lan.53 > Pixel-Tablet.lan.53353: 11200 NXDomain 0/0/0 (65)
11:50:27.816476 IP Pixel-Tablet.lan.45727 > OpenWrt.lan.53: 40503+ A? 307lf5rgn6-19290-11-50-27-759z.mullvad.test. (61)
11:50:27.816542 IP OpenWrt.lan.53 > Pixel-Tablet.lan.48267: 44347 NXDomain 0/0/0 (65) 
11:50:27.816588 IP Pixel-Tablet.lan.43821 > OpenWrt.lan.53: 36295+ A? 307lf5rgn6-19291-11-50-27-789z.mullvad.test. (61)
11:50:27.816625 IP OpenWrt.lan.53 > Pixel-Tablet.lan.16747: 44584 NXDomain 0/0/0 (61)

"Block connections without VPN"이 활성화되어 있었기 때문에 암호화된 WireGuard 트래픽을 제외하고는 어떤 것도 기기에서 빠져나가서는 안 되지만, 여기서는 평문 DNS가 기기에서 나가는 것을 볼 수 있음

결론 및 권장 사항

DNS 유출은 사용자의 프라이버시에 심각한 영향을 미칠 수 있으며, 사용자의 대략적인 위치를 파악하거나 사용자가 사용하는 웹사이트와 서비스를 알아내는 데 사용될 수 있음

이러한 발견은 "Block connections without VPN"이 이름(또는 문서)에 부합하지 않으며 여러 결함이 있음을 다시 한 번 보여줌:

  • 위에서 언급한 조건에서 앱이 여전히 DNS 트래픽을 유출할 수 있음
  • 이전에 보고된 바와 같이 여전히 연결 확인 트래픽이 유출됨

위협 모델에 따라 민감한 작업에 Android를 아예 사용하지 않거나 유출을 방지하기 위해 다른 완화 조치를 취해야 할 수 있음:

  • 앱에서 이러한 문제를 부분적으로 완화하는 것을 목표로 하므로 앱을 최신 상태로 유지해야 함

GN⁺의 의견

  • 이 문제는 근본적으로 Android OS의 버그이므로, Google에서 빠른 시일 내에 수정해야 할 것임. VPN 기능을 제공하는 앱 개발자들이 모두 이 문제를 해결하려 노력하는 것은 바람직하지 않음
  • "Block connections without VPN" 옵션이 문서대로 동작하지 않고 DNS 유출이 있다는 것은 사용자 입장에서 큰 문제임. VPN을 사용하는 주된 이유 중 하나가 프라이버시 보호인데 DNS 유출로 인해 사용자의 웹 사용 내역 등이 노출될 수 있기 때문
  • VPN 터널링 기술 자체의 보안성은 여전히 높다고 볼 수 있으나, OS에서 의도치 않게 유출이 발생하는 것을 방지하기 위해서는 VPN 외에 추가적인 보안/프라이버시 솔루션을 함께 사용하는 것도 고려해 볼만 함
  • 앱 개발자 입장에서는 OS 버그를 피해가기 위한 임시방편으로 앱에서 보완을 하고 있지만, 장기적으로는 근본적인 문제 해결을 위해 OS 개선이 필요해 보임
  • VPN 기술이 고도화되고 대중화되면서 이런 유형의 보안 이슈들이 새롭게 부각되고 있음. 앞으로도 모바일 OS의 네트워크 및 VPN 기능에 대한 보안감사와 지속적인 개선이 필요할 것으로 보임
▲
neo 7달전  [-]
Hacker News 의견
  • Mullvad의 정보가 풍부하고 문제에 대한 설명, 단기 해결책, 잠재적 해결책, 그리고 Android에서 수정되어야 할 사항들을 잘 설명했다는 평가
  • Android의 "편집증 네트워킹"은 시스템 및 OEM 앱에 대한 예외가 있으며, 대부분의 버그 수정은 이 핵심 가정을 수정하지 않을 것이라는 rethinkdns 개발자의 의견
  • Android는 두 TUN 장치 간에 "원활한 핸드오버"를 지원하지만, 구현하기가 까다롭다는 점
  • Android는 내부 DNS 서버만 사용하려고 해도 필요에 따라 셀룰러 데이터로 전환하여 외부 DNS를 사용하는 문제가 오래전부터 있었음
  • Apple의 경우 기본적으로 "프라이버시" VPN을 통해 모든 것을 프록시하려고 하므로 경쟁 제품 사용 시 더 나은 상황은 아닐 것으로 예상
  • Android에서는 IPv6 DNS 서버를 직접 설정할 수 없으며, 와이파이에 변화가 있을 때마다 변경됨
  • MikroTik 방화벽 장치를 사용하여 VPN 서버의 IP 주소로 향하지 않는 모든 트래픽을 차단하는 방법으로 트래픽 누출을 방지할 수 있음
  • 루트 액세스가 없는 모든 시스템은 본질적으로 안전하지 않으며, Android와 iOS는 우스꽝스러움
  • 가장 안전한 설정은 휴대전화의 모바일 데이터를 끄고 OpenWRT 핫스팟을 사용하여 업스트림에서 VPN을 수행하는 것
  • DNS 누출은 사용자의 브라우징 위치와 심지어 실제 위치까지 노출시킬 수 있으므로 VPN의 목적을 무력화시킴
  • iOS에서도 APNS 트래픽이 VPN 외부로 누출됨 (프로비저닝 프로파일로 설치된 OS 지원 VPN 제외)
  • 이러한 "버그"가 의도적으로 잘 배치된 것인지 의문이 들며, 대형 기술 기업이 정보 기관과 협력한다는 점을 고려할 때 Android의 많은 버그가 "우연히" 존재한다고 믿기 어려움
답변달기