Android में VPN टनल के बाहर DNS ट्रैफिक लीक होने की संभावना

 (mullvad.net)
2 पॉइंट द्वारा GN⁺ 2024-05-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Android के कुछ ऐप-और-स्थिति संयोजनों में DNS queries VPN टनल के बाहर जा सकती हैं, और Mullvad का मानना है कि इसका कारण VPN ऐप नहीं बल्कि Android OS बग है
  • लीक तब हो सकती है जब VPN चालू होने पर भी DNS server खाली हो, टनल दोबारा कॉन्फ़िगर हो रही हो, या VPN ऐप force stop/crash जैसी छोटी transition अवस्था में हो
  • असर मुख्य रूप से उन ऐप्स पर दिखता है जो getaddrinfo को सीधे कॉल करते हैं, जबकि Android API DnsResolver ही इस्तेमाल करने वाले ऐप्स में लीक नहीं मिली
  • Always-on VPN और “Block connections without VPN” चालू होने पर भी समस्या पूरी तरह नहीं रुकती, और यह Android 14 समेत कई versions में देखी गई है
  • Mullvad अस्थायी रूप से fake DNS server सेट करके कुछ स्थितियों को कम करने की योजना बना रहा है, लेकिन reconnect के दौरान होने वाली लीक को OS fix के बिना पूरी तरह रोकना मुश्किल है

Android में DNS लीक होने की स्थितियां

  • Mullvad ने 22 अप्रैल को Reddit उपयोगकर्ता की रिपोर्ट के जरिए पुष्टि की कि “Block connections without VPN” चालू होने पर VPN को बंद करके फिर चालू करने पर DNS लीक हो सकती है
  • आंतरिक जांच में ऐसे और भी scenario मिले जहां Android OS DNS ट्रैफिक को VPN के बाहर भेज सकता है
    • VPN सक्रिय है लेकिन DNS server configured नहीं है
    • VPN ऐप टनल को फिर से कॉन्फ़िगर कर रही है
    • VPN ऐप force stop हो जाए या crash हो जाए, उस छोटे समय में
  • यह व्यवहार Android OS का अपेक्षित व्यवहार नहीं है और इसे ऊपरी OS स्तर पर ठीक किया जाना चाहिए

प्रभावित ऐप्स और name resolution path

  • लगता है कि लीक उन ऐप्स में होती है जो domain name resolution के लिए C function getaddrinfo को सीधे कॉल करते हैं
  • Android API DnsResolver ही इस्तेमाल करने वाले ऐप्स में लीक नहीं मिली
  • Chrome browser ऐसे ऐप का उदाहरण है जो getaddrinfo को सीधे इस्तेमाल कर सकता है
  • getaddrinfo का इस्तेमाल अपने आप में गलत नहीं है, लेकिन सभी Android उपयोगकर्ताओं की सुरक्षा के लिए OS-स्तर का समाधान जरूरी है

Always-on VPN और block setting की सीमाएं

  • पुष्टि की गई लीक Always-on VPN और “Block connections without VPN” के सक्षम होने या न होने, दोनों स्थितियों में होती है
  • “Block connections without VPN” चालू होने पर encrypted WireGuard ट्रैफिक के अलावा कुछ भी डिवाइस से बाहर नहीं जाना चाहिए, लेकिन reproduction के दौरान router पर plain-text DNS देखी गई
  • Mullvad का आकलन है कि यह setting अपने नाम या documented behavior को पूरा नहीं करती और इसमें कई खामियां हैं
    • ऊपर बताई गई स्थितियों में DNS ट्रैफिक लीक हो सकती है
    • जैसा पहले रिपोर्ट किया गया था, connection-check ट्रैफिक भी अब भी लीक होती है

Mullvad ऐप की अस्थायी mitigation और बाकी समस्याएं

  • Mullvad ऐप फिलहाल block state में DNS server सेट नहीं करती
    • अगर टनल configuration unrecoverable तरीके से fail हो जाए, तो ऐप block state में चली जाती है
    • इस स्थिति में यह ट्रैफिक को डिवाइस से बाहर जाने से रोकती है, लेकिन DNS server खाली होने से लीक की शर्त बन सकती है
  • Mullvad ने OS bug को workaround करने के लिए फिलहाल fake DNS server सेट करने का तरीका अपनाने की योजना बनाई है, और इस fix वाला release जल्द देने की बात कही है
  • टनल reconnect के दौरान होने वाली लीक को ऐप स्तर पर कम करना ज्यादा मुश्किल है
    • Mullvad समाधान खोज रहा है
    • टनल reconfiguration की संख्या कम करने की संभावना है, लेकिन फिलहाल उसका मानना नहीं है कि इस लीक को पूरी तरह रोका जा सकता है
  • Mullvad ने समस्या और सुधार प्रस्ताव Google को रिपोर्ट किया है

WireGuard और Chrome से दोहराकर देखी गई स्थिति

  • दूसरा scenario, यानी VPN टनल configuration बदलते समय होने वाली लीक, WireGuard ऐप और Chrome का इस्तेमाल करके reproduce किया जा सकता है
    • WireGuard को Android VPN implementation के reference case के रूप में इस्तेमाल किया गया
    • Mullvad का मानना है कि यह दूसरे Android VPN ऐप्स में भी reproduce हो सकती है
    • Chrome ऐसा ऐप है जिसमें getaddrinfo का इस्तेमाल पुष्टि किया गया है, इसलिए उसे लीक trigger करने के लिए इस्तेमाल किया गया
  • reproduction प्रक्रिया में ये तत्व शामिल हैं
    • spam_get_requests.html डाउनलोड करना
    • WireGuard ऐप और Chrome इंस्टॉल करना
    • wg1.conf, wg2.conf को WireGuard में import करना
    • WireGuard में wg1 टनल सक्रिय करना और VPN permission देना
    • Android VPN settings में WireGuard के लिए Always-on VPN और “Block connections without VPN” सक्षम करना
    • router पर tcpdump -i <INTERFACE> host <IP of android device> से capture शुरू करना
    • WireGuard और Chrome को split-screen में खोलना, Chrome में spam_get_requests.html चलाना, फिर WireGuard में wg1 और wg2 के बीच बारी-बारी से switch करना
  • router पर Android डिवाइस से OpenWrt router के port 53 की ओर जाने वाली A record queries और NXDomain responses देखी गईं
  • DNS लीक का इस्तेमाल उपयोगकर्ता की लगभग location या वे कौन-सी websites और services देख रहे हैं, इसका पता लगाने में किया जा सकता है, इसलिए इसका privacy impact बड़ा हो सकता है
  • threat model के अनुसार, संवेदनशील उपयोग में Android का इस्तेमाल टालना पड़ सकता है या लीक रोकने के लिए अन्य mitigation लागू करनी पड़ सकती है
  • Mullvad ऐप उपयोगकर्ताओं को ऐप को up to date रखना चाहिए, क्योंकि इसमें आंशिक mitigation शामिल हो सकती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-05-04
Hacker News की राय

  • मैं Mullvad इस्तेमाल नहीं करता, लेकिन उसके लिए सच में सम्मान बढ़ गया है। समस्या का विवरण, अल्पकालिक workaround, दूसरे लोग इस्तेमाल कर सकने वाले संभावित workaround, और Android में क्या ठीक किया जाना चाहिए—सब कुछ बहुत high-density और अच्छी तरह व्यवस्थित है

    • प्रतिस्पर्धियों की तरह अंतहीन YouTube sponsorships करने के बजाय ऐसे blog posts प्रकाशित करने की वजह से मैंने VPN सेवा के तौर पर Mullvad चुना
    • VPN न भी इस्तेमाल करें तो भी Mullvad की एक मुफ्त DNS service है। ट्रैफिक/उपयोग बढ़ाना भी एक तरह का समर्थन हो सकता है, और DNS requests के नज़रिए से Mullvad VPN users को कम अलग दिखाने में भी मदद कर सकता है
      नुकसान यह है कि मेरे मामले में ping time quad9 या cloudflare से काफ़ी ज़्यादा है
      इस thread में मैंने DNS-level ad blocking के तरीक़े और cloudflare से जुड़ी जानकारी लिखी है: https://news.ycombinator.com/item?id=40056162
    • इसके values, thinking, core beliefs के प्रति निष्ठा, और दशकों तक अपने motto पर टिके रहने के लगातार सबूतों को देखें तो यह सबसे अच्छा VPN लगता है
    • Mullvad user के तौर पर मैं बहुत संतुष्ट हूँ। एक बार payment से जुड़े सवाल के लिए support team को mail भेजते समय, मैंने जिस समस्या का सामना कर रहा था उससे जुड़ा एक छोटा iptables सवाल भी जोड़ दिया था
      उन्होंने payment समस्या जल्दी सुलझा दी, और iptables के बारे में भी कई समाधानों के pros and cons सहित विस्तृत जवाब मिला। एक शब्द में, शानदार
    • अगर आप VPN इस्तेमाल करते हैं, तो जानना चाहूँगा कि कौन-सा इस्तेमाल करते हैं

  • मैं rethinkdns का developer हूँ
    “इन समस्याओं को, चाहे कोई भी app इस्तेमाल हो, सभी Android users की सुरक्षा के लिए OS स्तर पर हल किया जाना चाहिए” इस बात पर, Android की paranoid networking में हमेशा system apps और OEM apps, यानी Google apps सहित, exceptions रहे हैं
    संभव है कि इनमें से ज़्यादातर bug fixes भी उस मूल धारणा को न बदल सकें। संबंधित code देखें: https://github.com/celzero/rethink-app/issues/224
    “tunnel reconnect के दौरान होने वाली leak को app स्तर पर कम करना और मुश्किल है। अभी समाधान खोज रहे हैं” इस हिस्से पर, Android reconfiguration के समय दो TUN devices के बीच seamless switch को support करता है। इसे सही तरह implement करना कठिन है, लेकिन संभव है

    • जब flashlight app का internet permission तक बंद नहीं करने देते, तो यह बात समझ में आती है कि OS internet ad companies के प्रभाव में चल रहा है

  • यह Android में बहुत पहले से चली आ रही समस्या है। भले ही आप सिर्फ़ internal DNS server इस्तेमाल करना चाहें, Android अगर ज़रूरी या उचित समझे तो cellular पर switch करके वही DNS इस्तेमाल कर लेता है
    हाल ही में wireless connection क्यों/कब टूटता है यह देखने के लिए मैं adb debug logs देख रहा था, और आख़िर में पता चला कि liveness check की प्रक्रिया में अगर वह कुछ देख या समझ नहीं पाता, तो cellular data चालू करके कोशिश करता है
    जब आप सिर्फ़ अंदर मौजूद DNS records इस्तेमाल कर रहे हों, तब फ़ोन का यूँ मनमाने ढंग से काम न करना खास तौर पर परेशान करता है। डिवाइस उस Wi‑Fi से जुड़ा है जो वह internal DNS server दे रहा है जिसमें वह record मौजूद है, फिर भी Android किसी कारण से उसे बाहर से resolve कर रहा है
    Apple का हाल क्या है, पता नहीं, लेकिन यह देखते हुए कि वह डिफ़ॉल्ट रूप से अपने “privacy” VPN के ज़रिए DNS तक को DoH में proxy करने की कोशिश करता है, यह कल्पना करना मुश्किल है कि किसी प्रतिस्पर्धी जैसे उत्पाद का इस्तेमाल करने पर हालात बेहतर होंगे, और यह भी पता है कि Apple ऐसे उत्पादों के साथ कैसा व्यवहार करता है

    • यह देखना चाहिए कि “cellular पर switch करके ज़रूरत के समय इस्तेमाल करता है” कहीं Wi‑Fi assist चालू होने की वजह से तो नहीं है। उस feature को स्पष्ट रूप से इस तरह डिज़ाइन किया गया है कि Wi‑Fi signal खराब होने पर cellular पर switch हो जाए
    • Apple या iOS में configuration profiles के ज़रिए traffic को filter और block करने का काफ़ी मज़बूत built-in तरीका है। app-by-app settings संभव हैं या नहीं, यह पक्का नहीं, लेकिन hostname allow list/block list तो निश्चित रूप से सेट की जा सकती है
      असल उदाहरण के लिए यह system-wide ad blocker देखें: https://myxxdev.github.io/depictions/MYbloXXforiOS/MYbloXXfo...
    • iOS कभी भी डिफ़ॉल्ट रूप से Private Relay इस्तेमाल नहीं करता। subscription में शामिल हो तब भी उसे आपको ख़ुद स्पष्ट रूप से चालू करना पड़ता है
    • क्या आपने developer options में “मोबाइल डेटा हमेशा उपयोग करें” को बंद करके देखा है?
    • मैंने AOSP को source से build किया है। इसमें Google-विशेष requirements नहीं होनी चाहिए थीं, और Google से चुपके से कनेक्ट न हो सके इसलिए hosts file में जितने हो सके उतने Google servers block कर दिए थे
      मुझे जो एकमात्र समस्या हुई, वह यह थी कि डिवाइस एक ठीक-ठाक काम कर रहे wireless AP से जुड़ा होने पर भी इंटरनेट न होने का संकेत दिखाता था। वास्तव में वह काम कर रहा था, लेकिन status bar icon और दूसरी internal system code की ज़रूरतों के लिए शायद वह Google servers से इंटरनेट उपलब्धता जाँच रहा था
      अगर privacy आपके लिए महत्वपूर्ण है, तो Android से दूर रहना बेहतर है, और शायद सामान्य रूप से तकनीक से भी सावधान रहना चाहिए

  • कुछ साल पहले जब मैं एक project के लिए कई VPN configurations टेस्ट कर रहा था, तब कंप्यूटर और main router के बीच MikroTik firewall device रखा करता था। इसका मक़सद सिर्फ़ इतना था कि VPN server के IP address को destination न मानने वाले सभी traffic को block कर दिया जाए
    यह तरीका इस बात की गारंटी देने में बहुत अच्छा था कि PC से VPN server तक जाने वाले path के बाहर कोई traffic leak न हो। इस्तेमाल किए जा रहे VPN server का IP address लगभग कभी नहीं बदलता, और बदल भी जाए तो MikroTik firewall में बदलना आसान है
    अगर server IP पता न हो या बदलता रहे, तो VPN server के port/protocol pair के अलावा बाकी सभी traffic को block करने का तरीका भी है। उदाहरण के लिए VPN के प्रकार के अनुसार UDP 1194 destination न रखने वाले traffic को drop करना
    MikroTik router में traffic को जल्दी और आसानी से देखने के लिए torch नाम का एक छोटा tool भी है, और packet capture का support भी है। इसकी क़ीमत 30 डॉलर से 3000 डॉलर तक है, कोई software license नहीं है, और अगर आप इसे चलाना जानते हों तो यह बहुत शक्तिशाली और सक्षम है

    • इस तरह के device को network slug कहा जाता है, और यह बहुत शानदार विचार है
      तकनीकी रूप से देखें तो असली slug एक transparent layer-2 firewall होता है जिसका IP address define नहीं होता, लेकिन यहाँ उस स्तर की बारीकी में जाने की ज़रूरत नहीं है
      https://john.kozubik.com/pub/NetworkSlug/tip.html

  • स्रोत/गंतव्य पते और पोर्ट के आधार पर आउटबाउंड फ़िल्टरिंग फ़ायरवॉल की बुनियादी अवधारणा है और सभी फ़ायरवॉल-रूटिंग प्लेटफ़ॉर्म की मानक संरचना भी। गेटवे के आधार पर फ़िल्टर करने वाली policy-based routing भी इसी संदर्भ में आती है: https://en.wikipedia.org/wiki/Policy-based_routing
    आम तौर पर डिफ़ॉल्ट रूप से सारे आउटबाउंड ट्रैफ़िक को अनुमति देना सिर्फ़ consumer या semi-professional उत्पादों में होता है। इस कॉन्फ़िगरेशन में “main router” क्या था, यह जानने की उत्सुकता है। क्या वह ISP द्वारा दिया गया उपकरण था?

    • बात निकली है तो यह भी जानना है कि कोई सस्ता लेकिन ठीक-ठाक Layer 7 firewall राउटर भी है क्या
      अच्छा होता अगर हम फ़ोन ऐप और मॉडेम के बीच भी फ़ायरवॉल लगा पाते

  • Android की DNS समस्या यह है कि इस प्लेटफ़ॉर्म पर अपना IPv6 DNS server सेट नहीं किया जा सकता। Wi-Fi में हर बार कुछ बदलते ही यह बदल जाता है
    rooted Android पर भी ऐसा कोई ऐप नहीं है जो OS को इसे बदलने से रोक सके
    अगर आप ऐसा राउटर इस्तेमाल कर रहे हैं जो हमेशा IPv6 पते वितरित करता है और उसे बंद भी नहीं किया जा सकता, तो आप बस फँस जाते हैं
    यह भी पता नहीं कि उस राउटर के पीछे फ़ायरवॉल डिवाइस लगाकर राउटर द्वारा advertise किए गए IPv6 DNS server को हटाया जा सकता है या नहीं

    • DNS server IP address सेट करने की बजाय system-level DNS-over-TLS support का इस्तेमाल करना कैसा रहेगा। यह global setting है, इसलिए आप किसी भी network पर हों, वहाँ कुछ भी हो रहा हो, इस पर लागू होना चाहिए
      अगर DNS request leak की चिंता है, तो वैसे भी DoT या DoH इस्तेमाल करना चाहिए
    • क्या rethink से IPv6 DNS बदला नहीं जा सकता?
    • लगता है इसका मतलब है कि जब फ़ोन main interface हो तब ऐसा होता है
      सोच रहा हूँ कि क्या Wi-Fi tethering में भी यही होता है। अगर फ़ोन के Wi-Fi से जुड़े लैपटॉप पर VPN इस्तेमाल करें, तो क्या वह भी इसी तरह leak करेगा?

  • सबसे सुरक्षित सेटअप शायद यह है कि फ़ोन का mobile data बंद कर दिया जाए और साथ में ऐसा OpenWRT hotspot रखा जाए जो फ़ोन के upstream पर VPN संभाले

    • सही है। iOS में तो यह और भी बड़ा दुःस्वप्न है
      “always-on VPN” सिर्फ़ उन्हीं devices पर सेट किया जा सकता है जो Apple द्वारा अनुमोदित संगठन के MDM solution से “supervised” स्थिति में हों। इसके लिए दस्तावेज़ित आवेदन और मौजूदा कर्मचारी के साथ फ़ोन कॉल चाहिए
      नहीं तो Mac पर Apple Configurator ऐप का इस्तेमाल करके ही ऐसा configuration profile बनाया जा सकता है जिसमें “always-on VPN” key हो
    • मैंने पहले GL.inet E750 और बिना SIM वाले iPhone के साथ कई महीनों तक ऐसा किया था, लेकिन अमेरिकी GSM carriers अक्सर अजीब ports पर UDP traffic को बहुत ज़्यादा throttle करते थे। कभी-कभी यह 64~128kbps, यानी लगभग 0.1Mbps तक गिर जाता था
      notifications भी अक्सर देर से आती थीं
    • अगर आप public Wi-Fi या mobile network इस्तेमाल कर रहे हैं, तो यही सबसे अच्छा समाधान है। अगर कोई खुद बेस स्टेशन चला रहा हो, तो फ़ोन उससे जुड़ सकता है
      अगर नेटवर्क मेरा अपना नहीं है, तो mobile router के बिना सीधे connect न करना ही बेहतर है
    • दूसरे लोग कह रहे हैं कि Android कई स्थितियों में चुपचाप cellular data फिर से चालू कर देता है, इसलिए यह भी पक्का समाधान नहीं है
      The Grugq ने 10 साल पहले इसी उद्देश्य के लिए एक टूल बनाया था। दुर्भाग्य से अब इसका maintenance नहीं हो रहा: https://github.com/grugq/portal
      यह hackers के लिए operational security पर एक प्रस्तुति का हिस्सा था, और अगर आपको उन कई मशहूर या कुख्यात hackers के मामलों में रुचि है जो खुद को सुरक्षित समझते थे लेकिन अंत में पकड़े गए, तो यह देखने लायक है: https://www.youtube.com/watch?v=9XaYdCdwiWU

  • root access के बिना सिस्टम परिभाषा के अनुसार सुरक्षित नहीं है। Android और iOS तो हास्यास्पद हैं

    • यह भी कहा जा सकता है कि जिस सिस्टम में root access जैसी अवधारणा है, वह परिभाषा के अनुसार सुरक्षित नहीं है। इस तरह के निर्णायक वाक्य तो कोई भी कह सकता है
    • अगर फ़ोन ने ज़्यादातर लोगों के लिए desktop/laptop की जगह न ली होती, तो इस पर हँसकर आगे बढ़ा जा सकता था
      उन बच्चों के लिए अफ़सोस होता है जो बड़े हुए हैं या होंगे सिर्फ़ ऐसे उपकरणों के साथ, जो मुख्यतः media consumption और निजी data collection के लिए बनाए गए हैं
    • GrapheneOS के developers root के सख़्त ख़िलाफ़ हैं। इस बारे में उनकी सोच पर आपका क्या विचार है?
    • बात साफ़ है और विषय से मेल भी खाती है। इसी वजह से open source software और hardware mobile device projects बढ़ते ही रहेंगे
      https://en.wikipedia.org/wiki/PinePhone_Pro
    • उस परिभाषा के हिसाब से तो मेरे कई सबसे महत्वपूर्ण सिस्टम “असुरक्षित” होंगे
      अगर आप ऐसे किसी डिवाइस पर मौजूद मेरी SSH private key की कॉपी ला सकते हैं, तो मैं बिना सवाल पूछे 100,000 डॉलर नकद दे दूँगा
      वह परिभाषा निरर्थक है, और न तर्क में काम आती है न संचार में

  • “VPN के बिना कनेक्शन ब्लॉक” उतना ही भरोसेमंद निकल रहा है जितना बुफे में मेरा आत्मसंयम। अगर मैं भ्रम में नहीं हूँ, तो इस तरह की DNS leak देखी गई साइटों और लोकेशन तक काफ़ी कुछ उजागर कर सकती है, जिससे VPN का मक़सद ही विफल हो जाता है
    Android, VPN चालू होने पर भी DNS जानकारी लीक कर सकता है, इसलिए अगर privacy सच में बहुत महत्वपूर्ण है, तो Android इस्तेमाल करने पर ही पुनर्विचार करना या sensitive काम फ़ोन से दूर रखना बेहतर होगा

  • कभी-कभी संदेह होता है कि ऐसे “bugs” कहीं जानबूझकर तो सही जगह नहीं रखे गए। ख़ासकर यह देखते हुए कि बड़ी tech कंपनियाँ कई intelligence agencies के साथ सहयोग करती रही हैं
    Android में इस तरह के bugs के बारे में मैं पहली बार नहीं सुन रहा, इसलिए अब यह मानना कठिन है कि इतने सारे bugs बस “अनजाने में” आ गए

    • “एक बार संयोग, दो बार coincidence, तीन बार दुश्मन की कार्रवाई।” —Ian Fleming, Goldfinger

  • मुझे पहले से कुछ हद तक शक था कि मामला ऐसा ही होगा। Android पर VPN चालू होने पर भी MMS और Visual Voicemail फिर भी काम करते हैं
    दोनों ही कभी-कभी सीधे mobile access माँगते हैं या उसके बिना मना कर देते हैं। वे सिर्फ़ mobile network पर काम कर सकते हैं, या फिर अगर request mobile network के अंदर से न आए तो उसे ठुकरा सकते हैं। मुझे शक है VoLTE भी ऐसा ही होगा। VPN होने पर ये सुविधाएँ गड़बड़ा सकती हैं
    Mobile Linux पर VPN चालू करते ही ये सारी सुविधाएँ टूट जाती हैं, वहीं से यह पता चला
    Android में अपेक्षित बहुत-सी functionality बिगाड़े बिना इसे ठीक करने का कोई साफ़ तरीका नहीं दिखता

    • विडंबना यह है कि SMS/MMS और VVS उन गिने-चुने कामों/फ़ीचर्स में हैं जिनके carrier connection से hardcode होने को शायद जायज़ ठहराया जा सकता है। system updates भी शायद ऐसा एक मामला हो सकता है

मैंने VPN चालू होने पर iOS में AT&T advanced support team के साथ VVS समस्या को लेकर जूझा है, इसलिए यह पुष्टि की जा सकती है कि यह समस्या सिर्फ Android तक सीमित नहीं है

  • VoLTE, LTE स्टैक में dedicated bearer यानी अलग network interface का उपयोग करता है। यह data interface नहीं है
    अलग-अलग bearer की अलग priority/QCI यानी service quality हो सकती है। भीड़भाड़ वाले LTE network में VoLTE को कम-priority bearer वाले VOIP की तुलना में बेहतर अनुभव देना चाहिए