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

Android पर VPN टनल के बाहर DNS ट्रैफिक लीक हो सकता है

कई DNS लीक संभावनाओं की पुष्टि

• हाल ही में Android पर संभावित मल्टीपल DNS लीक का पता चला
• यह Android की आंतरिक बग के कारण है और केवल कुछ ऐप्स को प्रभावित करता है
• 22 अप्रैल, सोमवार को Reddit उपयोगकर्ता की रिपोर्ट के जरिए DNS लीक का पता चला
  • उपयोगकर्ता ने बताया कि "Block connections without VPN" सेटिंग चालू रखते हुए VPN को बंद और चालू करने पर DNS क्वेरी बाहर लीक हो रही थी
• तुरंत इन-हाउस जांच शुरू की और समस्या की पुष्टि की
• जांच में Android में DNS लीक उत्पन्न कर सकने वाले और भी कई परिदृश्य मिले

खोजे गए निष्कर्ष

Android OS में DNS ट्रैफिक लीक होने के संभावित परिदृश्य पहचाने गए:

• DNS सर्वर सेट न होने पर VPN सक्रिय हो
• जब VPN ऐप टनल को री-कॉन्फ़िगर करे या जब वह फोर्स-स्टॉप/क्रैश हो, तब थोड़े समय के लिए

लीक का कारण शायद getaddrinfo (C फंक्शन) का direct call होना है:

• ऊपर सूचीबद्ध परिदृश्यों में, डोमेन नाम रिज़ॉल्व करने के लिए यही तरीका अपनाने वाले ऐप्स में लीक दिखा
• केवल Android API जैसे DnsResolver का उपयोग करने वाले ऐप्स में कोई लीक नहीं मिला
• Chrome ब्राउज़र getaddrinfo का सीधे उपयोग करने वाले ऐप का उदाहरण है

Always-on VPN और Block connections without VPN की स्थिति की परवाह किए बिना ऊपर का व्यवहार लागू होता है:

• यह अपेक्षित OS व्यवहार नहीं है, इसलिए इसे OS के upstream में ठीक किया जाना चाहिए

हमने कई Android संस्करणों में यह लीक दोहराकर देखी, जिसमें नवीनतम Android 14 भी शामिल है

सुधार

वर्तमान में ऐप ब्लॉक स्थिति में DNS सर्वर सेट नहीं करता:

• यदि ऐप किसी अपरिवर्तनीय तरीके से टनल सेट नहीं कर पाता, तो यह ब्लॉक स्थिति में चला जाता है
• इस स्थिति में डिवाइस से ट्रैफिक बाहर जाना बंद हो जाता है
• लेकिन इस स्थिति में DNS सर्वर सेट नहीं होता, इसलिए ऊपर बताए गए DNS लीक संभव हो जाते हैं
• अभी के लिए हम OS बग को संभालने हेतु एक फर्जी DNS सर्वर सेट करने की योजना बना रहे हैं
• उम्मीद है कि इस सुधार वाला रिलीज़ जल्द आ जाएगा

टनल के पुनः-कनेक्शन के दौरान लीक को ऐप स्तर पर कम करना और कठिन है:

• अभी भी समाधान खोजे जा रहे हैं
• हम टनल री-कॉन्फ़िगरेशन की आवृत्ति कम कर सकते हैं, लेकिन वर्तमान में हमें लगता है कि इस लीक को पूरी तरह रोक पाना संभव नहीं होगा

यह स्पष्ट होना चाहिए कि किसी भी VPN ऐप को ऐसी workaround की जरूरत न पड़े:

• ऐप का getaddrinfo के जरिए डोमेन नाम रिज़ॉल्व करना किसी तरह ग़लत नहीं है
• इसके बजाय, सभी Android उपयोगकर्ताओं की सुरक्षा के लिए OS स्तर पर इस समस्या का समाधान होना चाहिए

इस समस्या की रिपोर्ट Google को कर सुधार सुझाव भेज दिए गए हैं और जल्द समाधान की उम्मीद है

पुनरुत्पादन के चरण

निम्न चरणों से ऊपर दिए गए दूसरे परिदृश्य को दोहराया गया, जहाँ VPN उपयोगकर्ता टनल कॉन्फ़िगरेशन बदलता है (जैसे किसी अन्य सर्वर पर स्विच करना या DNS सर्वर बदलना):

• WireGuard ऐप का उपयोग किया गया क्योंकि यह Android VPN का रेफरेंस इम्प्लीमेंटेशन है
• नोट: लीक शायद अन्य Android VPN ऐप्स पर भी दोहराया जा सकता है
• getaddrinfo का उपयोग करने वाले ऐप्स में से एक होने के कारण, Chrome का उपयोग ट्रिगर के लिए किया गया

1. spam_get_requests.html डाउनलोड करें

2. WireGuard ऐप और Chrome इंस्टॉल करें

3. WireGuard में wg1.conf और wg2.conf इम्पोर्ट करें

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 को स्क्रॉल होकर side-by-side दिखाई देने के लिए स्क्रीन विभाजित करें

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" चालू होने के कारण encrypted WireGuard ट्रैफिक के अलावा अन्य कोई भी ट्रैफिक डिवाइस से बाहर नहीं जाना चाहिए, लेकिन यहाँ plaintext DNS ट्रैफिक बाहर निकलता दिख रहा है

निष्कर्ष और अनुशंसाएँ

DNS लीक यूज़र की प्राइवेसी पर गंभीर असर डाल सकता है और किसी के अंदाज़े से उसके approximate location या उपयोग किए जा रहे वेबसाइट/सेवाओं का पता लगाने में मदद कर सकता है

यह खोज यह फिर दिखाती है कि "Block connections without VPN" नाम (या दस्तावेज़) से मेल नहीं खाती और इसमें कई कमियाँ हैं:

• ऊपर बताए गए हालात में ऐप अभी भी DNS ट्रैफिक लीक कर सकता है
• जैसा पहले रिपोर्ट हुआ था, कनेक्टिविटी-चेक ट्रैफिक अभी भी लीक होता है

अपनी threat model के आधार पर, सेंसिटिव काम के लिए Android से परहेज़ करने या लीक रोकने के लिए अन्य mitigation लागू करने की जरूरत पड़ सकती है:

• क्योंकि ऐप केवल इस मुद्दे को आंशिक रूप से कम करने पर केंद्रित है, इसलिए ऐप को अपडेट रखना ज़रूरी है

GN⁺ की राय

• यह मुद्दा मूलतः Android OS की बग है, इसलिए Google को इसे तुरंत सुधारना चाहिए; VPN फीचर बनाने वाले सभी ऐप डेवलपर्स से इसकी अपेक्षा करना उचित नहीं है
• "Block connections without VPN" अपेक्षित तरह से काम नहीं करता और DNS लीक का मौजूद होना यूज़र के लिए बड़ा मुद्दा है। VPN लेने का मुख्य कारण privacy protection ही है, और DNS लीक से वेब बाउंल के उपयोग जैसे डेटा लीक हो सकते हैं
• VPN टनलिंग टेक्नोलॉजी अभी भी मजबूत मानी जा सकती है, पर OS स्तर पर unintended leakage रोकने के लिए VPN के अतिरिक्त security/privacy layers जोड़ना भी एक विकल्प हो सकता है
• ऐप डेवलपर्स अभी OS बग के लिए workarounds बना रहे हैं, लेकिन लंबे समय के लिए OS में बेसिक सुधार आवश्यक है
• VPN टेक्नोलॉजी के बढ़ते उपयोग और परिपक्वता के साथ ऐसे सुरक्षा मुद्दे ज्यादा दिखने लगे हैं; आगे मोबाइल OS की नेटवर्क और VPN क्षमता पर लगातार security audit और सुधार आवश्यक है

[GN⁺]

Hacker News टिप्पणियाँ

• Mullvad द्वारा दी गई जानकारी समृद्ध और स्पष्ट थी; इसमें समस्या का विवरण, तुरंत लागू किए जा सकने वाला समाधान, संभावित समाधान और Android में क्या सुधार करना चाहिए, सब अच्छे से समझाए गए हैं।
• Android की "paranoid networking" में सिस्टम तथा OEM ऐप्स के लिए exceptions हैं, और rethinkdns डेवलपर का मानना है कि अधिकांश बग फिक्स इस मूल assumption को बदलने वाले नहीं होंगे।
• Android दो TUN डिवाइसों के बीच "smooth handover" का समर्थन करता है, लेकिन इसे लागू करना मुश्किल है।
• Android में केवल internal DNS server ही इस्तेमाल करने की कोशिश करने पर भी, ज़रूरत पड़ने पर यह मोबाइल डेटा पर स्विच होकर external DNS का उपयोग कर सकता है; यह समस्या लंबे समय से मौजूद है।
• Apple सामान्यतः अपनी "privacy" VPN के जरिए हर चीज़ को proxy करना चाहता है, इसलिए प्रतिस्पर्धी उत्पादों में स्थिति बेहतर होने की उम्मीद नहीं है।
• Android में IPv6 DNS server सीधे सेट नहीं किए जा सकते, और ये Wi-Fi बदलने पर बदल जाते हैं।
• VPN server के IP की ओर न जाने वाले सभी ट्रैफिक को ब्लॉक करके DNS leak को रोकने के लिए MikroTik firewall device का उपयोग किया जा सकता है।
• बिना root access वाली कोई भी सिस्टम मूलतः सुरक्षित नहीं मानी जा सकती, और Android तथा iOS का तो मज़ाक ही बन जाता है।
• सबसे सुरक्षित सेटअप यह है कि फोन का मोबाइल डेटा बंद करके OpenWRT hotspot का उपयोग किया जाए और upstream पर VPN रन किया जाए।
• DNS leak उपयोगकर्ता की browsing location के साथ वास्तविक location तक उजागर कर सकता है, इसलिए VPN का उद्देश्य ही खत्म हो जाता है।
• iOS में भी APNS ट्रैफिक VPN के बाहर leak होता है (प्रोvisioning profile से इंस्टॉल किए गए OS-supported VPN को छोड़कर)।
• ये "bugs" शायद जान-बूझकर इसी तरह सेट किए गए हों; जब बड़ी टेक कंपनियाँ intelligence agencies के साथ मिलकर काम करती हैं, तो Android में इतने सारे bugs का "यादृच्छिक" रूप से मौजूद रहना मानना कठिन लगता है।