जब आंतरिक होस्टनेम क्लाउड में लीक हो जाते हैं

• घरेलू NAS डिवाइस के वेब इंटरफ़ेस द्वारा केवल आंतरिक उपयोग वाले होस्टनेम को बाहरी सेवा तक भेजे जाने का मामला मिला
• NAS वेब UI में शामिल sentry.io error reporting script स्टैक ट्रेस के साथ आंतरिक होस्टनेम को बाहरी रूप से भेजता है
• देखा गया कि sentry.io उस होस्टनेम पर TLS कनेक्शन को उल्टी दिशा में शुरू करने की कोशिश करता है, लेकिन वास्तविक request नहीं भेजता
• पहले से wildcard DNS सेट होने की वजह से लीक का पता लगाना संभव हुआ, और संवेदनशील होस्टनेम इस्तेमाल करने पर गंभीर जानकारी-उजागर होने का जोखिम है
• इस मेकैनिज़्म का दुरुपयोग कर मनमाने होस्ट्स के लिए DNS scan करवाने की संभावित सुरक्षा समस्या है

---

NAS इंस्टॉलेशन और आंतरिक होस्टनेम कॉन्फ़िगरेशन

• NAS डिवाइस खरीदी, ड्राइव लगाई और होम नेटवर्क से जोड़ा, तथा HTTPS mode में चलाया
• पब्लिक इंटरनेट पर अर्थहीन डोमेन के एक सब-सबज़ोन (उदाहरण: *.nothing-special.whatever.example.com) के लिए wildcard TLS certificate इंस्टॉल किया
• /etc/hosts फ़ाइल में 172.16.12.34 nas.nothing-special.whatever.example.com जैसी केवल लोकल एंट्री जोड़कर ब्राउज़र से एक्सेस किया

बाहर से अप्रत्याशित कनेक्शन का पता चला

• NAS इंस्टॉल करने के कुछ दिनों बाद, उसी होस्टनेम पर बाहरी ("outside world") से request आने लगे
• यह होस्टनेम लैपटॉप की /etc/hosts फ़ाइल में ही मौजूद एक पूरी तरह आंतरिक-उपयोग वाला नाम था
• चूँकि पहले से *.nothing-special.whatever.example.com पूरे नामक्षेत्र के लिए अपनी नियंत्रित मशीन की ओर जाने वाली wildcard DNS entry सेट थी, इसलिए लीक का पता चल सका
• हर बार NAS लोड होने पर GCP host उस आंतरिक होस्टनेम को SNI के रूप में प्रस्तुत करते हुए कनेक्शन की कोशिश करता था

लीक का कारण: sentry.io error reporting

• NAS वेब इंटरफ़ेस में phone home फ़ंक्शन शामिल है और उसके हिस्से के रूप में sentry.io को स्टैक ट्रेस भेजा जाता है
• ब्राउज़र जब sentry.io को callback करता है, तब वह आंतरिक स्टोरेज डिवाइस के लिए इस्तेमाल किया गया होस्टनेम भी साथ भेज देता है
• पुष्टि हुई कि sentry.io उस होस्टनेम पर TLS कनेक्शन वापस बनाता है, लेकिन वास्तविक HTTP request बिल्कुल नहीं भेजता

सुरक्षा निहितार्थ और प्रतिक्रिया

• अगर होस्टनेम में संवेदनशील जानकारी (जैसे mycorp-and-othercorp-planned-merger-storage जैसा नाम) शामिल हो, तो गंभीर जानकारी लीक का जोखिम है
• इस sentry reporting मेकैनिज़्म का उपयोग कर मनमाने बाहरी होस्ट्स पर DNS scan करवाना संभव है (ठोस तरीका पाठक पर छोड़ा गया है)
• उपाय के तौर पर Little Snitch चलाकर उस पूरे डोमेन को सभी apps के लिए ब्लॉक कर दिया गया

[GN⁺]

Hacker News की राय

• लगता है लोग इसे गलत समझ रहे हैं। यह CT logs का मुद्दा नहीं, बल्कि wildcard certificate से जुड़ा मामला है
  Sentry क्लाइंट-साइड traces इकट्ठा करते समय request भेजने वाले hostname को निकाल रहा था और फिर उसे दोबारा poll करने की कोशिश में block हो गया

  • संभव है कि यह trace UI में दिखाने के लिए favicon लाने की कोशिश रही हो
  • लेकिन अगर संरचना ऐसी है, तो Sentry मनचाहे IP पर request भेज सकता है, जिससे security vulnerability पैदा हो सकती है। खासकर उन IP पर बार-बार पहुँचने का जोखिम है जो malicious traffic को अपने-आप report करते हैं
  • लोग इसलिए भी भ्रमित हैं क्योंकि blog post बहुत उलझे हुए और अस्पष्ट तरीके से लिखी गई थी

• hostname अपने आप में गोपनीय जानकारी नहीं है
  यह DNS queries, TLS certificates और कई दूसरे रास्तों से बाहर उजागर हो जाता है
  private service को छिपाना हो तो hostname की जगह URL path में secret रखना बेहतर है
  उदाहरण के लिए fileservice.example.com/my-hidden-service-007-abc123/ जैसा path HTTPS के अंदर ही जाता है, इसलिए exposure काफी कम होता है

  • हालांकि इस स्थिति में भी path, Sentry जैसी external services तक भेजा जा सकता है, इसलिए opaque URL इस्तेमाल करना और URL में secrets न रखने की आदत ज़रूरी है
  • किसी ने यह भी पूछा: “अगर सिर्फ HTTP इस्तेमाल करें तो क्या ऐसा exposure कम होगा?”

• मुझे जिज्ञासा थी कि “clown GCP Host” कोई technical term है क्या। बाद में पता चला कि लेखक ने cloud का व्यंग्य करने के लिए यह लिखा था
  समस्या का मूल यह है कि NAS web interface Sentry को logs भेजते समय internal hostname भी शामिल कर रहा था
  ऐसी स्थिति में मैं शायद विश्वसनीय open source OS पर switch करूँ, या PiHole जैसी DNS blocking से Sentry calls रोकूँ

  • “clown” Big Tech के cloud का मज़ाक उड़ाने वाला शब्द है; किसी ने कहा कि पुराने IRC दौर में “clown computing” भी कहा जाता था
    एक व्यक्ति ने बताया कि वह local DNS और TLS proxy से outbound traffic पूरी तरह block करता है
  • किसी और ने जोड़ा कि “clown” बड़े cloud providers और उनके users पर व्यंग्य करने वाला पुराना शब्द है
  • एक और ने मज़ाक में कहा कि “clown” की जगह “weenie” शब्द भी इस्तेमाल किया जाता है
  • “सर्कस चला गया, लेकिन जोकर यहीं रह गए” जैसी हँसी-मज़ाक वाली बात भी आई

• ऐसे मामलों की वजह से मैं uBlock Origin को web security का न्यूनतम मानक मानता हूँ
  ज़्यादातर webpages इतने सारे third-party scripts लाती हैं कि data leakage बेहद गंभीर हो चुका है
  यह मूल समाधान नहीं है, लेकिन अभी हमारे हाथ में यही सबसे अच्छा उपाय है

  • मैंने भी router पर AdGuard Home लगाया है, और 15~20% traffic block हो जाता है। इससे tracking और ads की गंभीरता का अंदाज़ा होता है

• ऐसी समस्या रोकने के लिए सामने Nginx reverse proxy रखकर CSP headers inject करना अच्छा है
  इससे NAS के खुद बाहर request भेजने पर रोक नहीं लगेगी, लेकिन browser की तरफ़ से होने वाली requests को block किया जा सकता है
  उदाहरण के लिए Steam avatar request (https://avatars.steamstatic.com/HASH_medium.jpg) को भी CSP policy से रोका जा सकता है
  ज़रूरत हो तो केवल कुछ चीज़ें allow की जा सकती हैं। साथ ही Referrer-Policy: no-referrer जोड़ने से hostname external logs में जाने से रोका जा सकता है

  • किसी ने “ATM machine” कहकर दोहराव वाले phrasing की ओर इशारा किया
  • किसी और ने मज़ाक में जवाब दिया, “NPM काफ़ी simple है”

• मैंने Synology NAS खरीदा था, और कई बार पछताया हूँ
  community software के अलावा उससे बहुत कम काम हो पाता है
  Let's Encrypt से SSL लगाना भी जटिल है, और paths non-standard होने से config location ढूँढना मुश्किल होता है
  पुराना rsync version, default utilities की कमी जैसी शिकायतें भी हैं। लगता है कि Linux या BSD आधारित NAS लेना बेहतर रहता

  • कुछ लोगों का कहना था कि Synology को अगर सिर्फ file server की तरह इस्तेमाल करें तो यह बहुत स्थिर है। लेकिन उसकी closed policies के कारण कोई UniFi NAS पर जाने की योजना बना रहा था
  • एक प्रतिक्रिया यह भी थी कि “आप server चाहते हैं, फिर शिकायत करते हैं कि NAS server नहीं है”
  • किसी ने साझा किया कि Synology NAS पर नया Debian चलाने की guide Doozan forum में है
  • एक सलाह यह भी थी कि “इसे बस file/iscsi server की तरह रखो, बहुत स्थिर रहेगा, छेड़ो मत”
  • दूसरी तरफ़, किसी ने कहा कि उसने RS217 model $100 में लिया और वह उसकी सबसे अच्छी खरीद थी। वह Synology Office को Google Docs की जगह इस्तेमाल करता है और UI की polish से प्रभावित था

• मैंने हाल में Sentry configure किया, और इसमें अपने-आप uptime monitoring सेट करने की सुविधा है
  host पहचानते ही यह periodic ping भेजता है, और अगर कुछ दिनों तक stable response मिले तो “क्या आप इस host के लिए uptime monitoring सेट करना चाहेंगे?” जैसी notification दिखाता है

  • किसी ने बस इतना कहा: “expansion opportunity”

• मैं व्यक्तिगत रूप से Sentry से जुड़े पूरे domain set को block करता हूँ
  यह सामान्य समाधान नहीं है, लेकिन मेरे environment में यही सबसे अच्छा है

• reverse address lookup servers को अक्सर internal network addresses (ULA, RFC1918) तक resolve करने की कोशिश करते देखा गया है
  ऐसे data को दूसरी जानकारी के साथ जोड़कर internal state का अनुमान लगाया जा सकता है
  किसी ने कहा, “Darknet collection के दौरान UDP audio भी पकड़ा गया था”

  • इस पर सवाल आया: “वह UDP audio किस साल के SIP traffic से जुड़ा था?”

• पहले मैंने Heroku पर ऐसा ही एक मामला जाँचा था
  जब नया app बनाया जाता है, तो उसे एक random subdomain मिलती है, और DNS lookup किए बिना ही vulnerability scanners की requests आने लगती हैं
  Heroku से पूछने पर पता चला कि नए app का URL certificate transparency (CT) logs में public हो जाता है

  • किसी ने कहा, “यह तो हर नई service पर ‘मुझ पर हमला कीजिए’ का बोर्ड टाँगने जैसा है,” और जोड़ा कि CT logs में असली certificate की जगह सिर्फ hash रिकॉर्ड होना चाहिए था
    Certificate Transparency कैसे काम करता है वाला लिंक भी साझा किया गया
  • किसी और ने screenshot (image link) के साथ लिखा कि “मैं wildcard domain इस्तेमाल करता हूँ, इसलिए इस तरह की समस्या से बचा हुआ हूँ”