mDNS के जरिए ब्राउज़र में macOS यूज़र का वास्तविक नाम brute-force करना

 (fingerprint.com)
3 पॉइंट द्वारा GN⁺ 2023-07-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • macOS का डिफ़ॉल्ट लोकल hostname यूज़र का नाम शामिल कर सकता है, इसलिए वेबसाइट बिना अनुमति mDNS name resolution के timing difference से नाम के candidates को सीमित कर सकती है
  • हमलावर देश और gender के हिसाब से 50 लोकप्रिय नामों को device-name candidates के साथ जोड़ता है; प्रयोगों में औसतन 65% मामलों में macOS यूज़र का नाम सही मिला
  • Browser JavaScript arbitrary UDP socket नहीं खोल सकता, लेकिन fetch, iframe, Image, WebRTC requests से .local address के response delay की तुलना कर सकता है
  • timezone, language, IP location, Safari का navigator.language, screen resolution, screen.isExtended जैसी जानकारी locale और device model candidates को घटाने में इस्तेमाल होती है
  • इसकी practical उपयोगिता कम है और browser developer tools के Network tab में आसानी से दिख सकती है, लेकिन वही mDNS discovery तरीका printer, smart TV, smart speaker और IoT devices detect करने में भी इस्तेमाल हो सकता है

macOS local hostname से नाम leak होने की संरचना

  • macOS यूज़र का वास्तविक नाम permission request के बिना browser से अनुमानित किया जा सकता है; इसका core mDNS protocol और default local hostname format है
  • किसी खास देश के gender-wise top 50 popular names की list भर इस्तेमाल करने पर भी औसतन 65% मामलों में macOS यूज़र का नाम सही detect हुआ
  • Fingerprint इस technique को अपने product में इस्तेमाल नहीं करता, और cross-site tracking service भी provide नहीं करता
  • सार्वजनिक चर्चा का उद्देश्य browser providers को ऐसी techniques जल्दी fix करने में मदद करना है

mDNS और Apple Bonjour कैसे काम करते हैं

  • multicast DNS local network में devices के नाम register, discover और broadcast करने का protocol है
  • printer जैसे devices 224.0.0.251 reserved internal IP पर UDP registration packet भेजते हैं, और HP_LaserJet_Printer.local जैसा hostname शामिल कर सकते हैं
  • .local top-level domain बताता है कि उस hostname को mDNS से resolve किया जाना चाहिए
  • router ऐसे packets को local network के दूसरे devices पर automatically broadcast करता है ताकि वे hostname cache कर सकें
  • devices उसी reserved IP पर query packet भेजकर network में मौजूद हो सकने वाले किसी specific नाम के device को खोजते हैं
  • example hostnames ये हैं
    • johns-mac-mini.local
    • david-ZenBook-UX431DA-UM431DA.local
    • james-iphone.local
    • canon-mf644c.local
    • bedroom-appletv.local
    • dlinkrouter.local
  • Apple devices में Apple Bonjour feature के हिस्से के रूप में mDNS व्यापक रूप से इस्तेमाल होता है
  • default local hostname में यूज़र का नाम उजागर हो सकता है, और macOS में System Settings > Sharing से local hostname देखा या बदला जा सकता है

browser में mDNS hostname check करने का workaround

  • mDNS UDP packets पर आधारित है, इसलिए browser JavaScript environment में इसे arbitrary UDP socket के जरिए सीधे इस्तेमाल नहीं किया जा सकता
  • इसके बजाय browser द्वारा URL के hostname को resolve करने की कोशिश करने वाली प्रकृति का उपयोग करके timing attack किया जाता है
  • proof of concept मौजूद device-1.local और गैर-मौजूद device-2.local पर सामान्य fetch GET request भेजने के तरीके पर आधारित है
  • address resolve हो जाए तो browser port 80 पर TCP packet भेजता है, और यह port आम तौर पर बंद होने की संभावना अधिक होती है
  • network level पर अलग-अलग errors दिखाई देते हैं
    • मौजूद device-1.local: ERR_CONNECTION_REFUSED
    • गैर-मौजूद device-2.local: ERR_NAME_NOT_RESOLVED
  • JavaScript में दोनों errors एक ही Failed to fetch error में map होते हैं, इसलिए error type पर भरोसा नहीं किया जा सकता
  • local network तेज होता है, इसलिए valid mDNS hostname default connection timeout से कहीं जल्दी resolve हो जाता है
  • example में valid address 4ms और invalid address 5 seconds में अलग हुआ
  • यह approach proof of concept के लिए पर्याप्त रूप से consistent है और major browsers में similar ढंग से काम करता है
  • असल में fetch के अलावा iframe, Image, WebRTC जैसे network JavaScript APIs से भी DNS resolution timing attack किया जा सकता है

macOS username को brute-force करने का तरीका

  • default macOS local hostname यूज़र का नाम और device name शामिल करता है, और format system language locale के हिसाब से बदलता है
    • English: <name>s-macbook-pro.local
    • French: macbook-air-de-<name>.local
    • Russian: mac-mini-<name>.local
  • simple approach में top 1,000 names, top 10 locales और 5 common macOS device names को combine करने पर 50,000 hostnames check करने होंगे
  • इस स्थिति में पूरी जांच में 1 घंटे से ज्यादा लग सकता है
  • ज्यादा efficient strategy search range को single locale, single device और उस locale के 50 common names तक सीमित करना है
  • range घटाने से accuracy कम होती है, लेकिन attack time घटता है और scenario ज्यादा realistic बनता है
  • locale चुनने के लिए browser timezone, language और IP address location इस्तेमाल किए जा सकते हैं
  • Safari navigator.language property से system locale expose करता है, और यह value आम तौर पर target hostname locale से match करती है
  • यूज़र का origin country पता करने के दूसरे workaround के रूप में पहले कवर की गई Apple ID region detection method है
  • device candidates को screen resolution से narrow किया जा सकता है
    • उदाहरण के लिए 1728x1117 resolution के 16-inch MacBook Pro होने की संभावना अधिक है
    • extended screen को screen.isExtended property से detect किया जा सकता है
    • extended screen detect होने पर device candidates को सबसे common 3–5 Apple macOS devices पर वापस लाया जा सकता है

सीमाएँ और अन्य संभावित उपयोग

  • यह attack अंतर्निहित कमजोरियों और कई limitations के कारण practical नहीं है
  • जब तक website operator visitors को जानबूझकर deanonymize करना नहीं चाहता, इसे browser developer tools के Network tab में आसानी से detect किया जा सकता है
  • इस method को installed applications detection के साथ combine करने पर, बिना permission यूज़र का वास्तविक नाम और इस्तेमाल हो रही professional applications की list के आधार पर job title दिखाने वाली malicious website बन सकने की संभावना है
  • macOS चलाने वाले Apple devices मुख्य example हैं, लेकिन mDNS discovery technique कई तरीकों से extend हो सकती है
  • local network scan के जरिए printers, smart TVs, smart speakers और अन्य home IoT devices detect करने के लिए भी इसका इस्तेमाल किया जा सकता है
  • यह iPhone और iPad पर भी लागू हो सकता है, शर्त यह है कि Wi-Fi syncing या Safari remote debug feature enabled हो

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

1 टिप्पणियां

 
GN⁺ 2023-07-14
Hacker News की रायें

  • मैं macOS पर Little Snitch इस्तेमाल कर रहा/रही हूँ, और यह एक अच्छा UI है जिसे इस तरह सेट किया जा सकता है कि नेटवर्क request allow करने से पहले local user से साफ़ तौर पर पूछा जाए
    https://www.obdev.at/products/littlesnitch/index.html
    Remote login के दौरान कभी-कभी यह अटकता है, आम तौर पर जब SSH session NPM से NodeJS components लेने जैसी कोई नई चीज़ download करने की कोशिश करता है। Text terminal में SSH download रुक जाता है, और जब पता चलता है कि वजह Little Snitch है, तो नीचे वाले desk तक जाकर mouse हिलाकर monitor को जगाना, screensaver unlock करना और Little Snitch dialog में “Allow” दबाना पड़ता है
    यानी यह अपने मकसद के हिसाब से ही काम कर रहा है। बस ऐसे tools में अक्सर local network requests को चुपचाप allow करने की default setting होती है, इसलिए नहीं जानता/जानती कि मूल लेख वाली शरारत मेरे setup में भी काम करेगी या नहीं

    • मेरे मामले में browser में सिर्फ़ किसी खास hostname को allow करने के लिए LittleSnitch configure करना कल्पना करना मुश्किल है। मेरे पास “53/80/443 पर जाने वाला सारा traffic allow” rule है, वरना ज़्यादातर websites LittleSnitch के सैकड़ों popups खोल देंगी
    • Jailbroken iPhone पर NetFence इस्तेमाल कर रहा/रही हूँ
      Apps चुपके से कौन-कौन से socket connections खोलती हैं, यह देखकर हैरानी होती है, इसमें banking apps भी शामिल हैं
      https://havoc.app/package/netfence
    • लेकिन Little Snitch block करते समय भी IP leak हो जाता है :(
      https://news.ycombinator.com/item?id=35363343
    • Linux पर इसी तरह का software OpenSnitch इस्तेमाल करके देखा। कोई अजीब चीज़ पकड़ नहीं पाया, लेकिन basic कामों के दौरान काफ़ी ज़्यादा परेशान किया
    • ध्यान दें, DNS resolution connection allow/deny popup से पहले होता है। उदाहरण के लिए www.example.com 1.1.1.1 में resolve होता है, लेकिन Confirm दबाने तक 1.1.1.1 से असल connection नहीं बनता
      Network में Pi-hole जोड़ेंगे तो समय/पैसा/investment पर पछतावा नहीं होगा

  • क्या broader internet की websites को मेरे local network पर network requests करने से रोकने का कोई तरीका है? समझना मुश्किल है कि इसे default रूप से allow क्यों होना चाहिए
    मेरा मतलब IE के Local Intranet Zone permissions को वापस लाने से नहीं है

    • आम तौर पर CORS की वजह से ऐसा नहीं हो सकता। यह “hack” सिर्फ़ इसलिए काम करता है क्योंकि unresolved domain request और resolved लेकिन rejected request के rejection timing में फर्क होता है
      लेकिन अगर https://192.168.2.1 पर कुछ चल भी रहा हो, तो जब तक 192.168.2.1 की service Origin के रूप में my-own-domain.com को allow नहीं करती, https://my-own-domain.com पर चल रही web app access नहीं कर सकती
    • Brave ने हाल ही में local network access के लिए permission मांगने वाला feature जोड़ा है
      https://brave.com/privacy-updates/27-localhost-permission/
      HN पोस्ट: https://news.ycombinator.com/item?id=36574775
    • इस तरीके का अक्सर दुरुपयोग करने वाली app Discord desktop app है, जो local port खोलकर सुनती रहती है
      जब browser Discord channel invite page पर जाता है, तो यह इस port के जरिए localhost को request भेजता है और channel ID client को pass करता है। फिर app native “Join Channel” experience दिखा सकती है
      मुझे यह तब पता चला जब incognito mode में भी यह काम करता रहा और browser Discord से logged out था, फिर भी यह behavior जारी रहा। अच्छा नहीं है। Desktop दुनिया में सभी applications की sandboxing में बहुत सुधार की जरूरत है
    • uBlock Origin static filter से block किया जा सकता है:
      ||local^$all
      इससे .local पर जाने वाली सभी requests block हो जाएंगी, जिसमें .local से ही आई requests भी शामिल हैं। अगर webserver चलाने वगैरह की वजह से foo.local को खुद से बात करने देना हो, तो हर domain के लिए अलग exception चाहिए:
      @@||foo.local^$domain=foo.local,all
      या अगर पूरे .local पर भरोसा करके किसी भी foo.local को किसी भी bar.local से communicate करने देना हो, तो पूरे .local के लिए एक exception जोड़ सकते हैं:
      @@||local^$domain=local,all
    • भ्रम से बचने के लिए, यह internet server द्वारा local network को request भेजने की समस्या नहीं है, बल्कि local web browser द्वारा वह request भेजने की समस्या है। ज़ाहिर है, browser में चल रहा JavaScript internet server से load हो सकता है

  • समय बीतने के साथ internet इस्तेमाल करना आम तौर पर Qubes box में, disposable Whonix/Tor VM से, JavaScript बंद करके करना ज़्यादा मन को सुकून देने लगा है
    यह वाकई घिनौना है। हैरानी की बात नहीं, लेकिन इसका संभव होना ही कई मायनों में भयावह है
    अगर fingerprint.com को नहीं जानते, तो ये लोग “deep user profiling” करते हैं। समझिए कि computer, browser, operating system अलग होने पर भी वही user ID बनाए रखते हैं। Main page पर demo है, और यह कितना सही पहचानता है, थोड़ा डरावना है

    • अलग-अलग VPN IP पर भी उसी device के रूप में पूरी तरह पहचान लेता है। सच में डरावना
    • यह घिनौना है। Default iPhone के incognito mode में दो IP बदलने पर भी यह कर लेता है, यह प्रभावशाली है, जबकि वह निश्चित रूप से दूसरे iPhones जैसा ही दिखना चाहिए
      Demo को तोड़ने वाला uBlock Origin filter:
      ||fpjscdn.net

  • इसी तरह के timing attack से browser में local machine और local network के दूसरे devices का port scan किया जा सकता है
    https://github.com/Flu1dTeam/PortScanner
    पहले eBay यह करते हुए पकड़ा गया था
    https://blog.nem.ec/2020/05/24/ebay-port-scanning/

    • क्या बात है, यह तो काफी creepy है; अब तक इसके बारे में सुना क्यों नहीं?

  • अच्छा है कि मैं device name हमेशा बदलकर रखता हूं
    Apple की default naming एक privacy mistake है। पहले law enforcement में काम करने वाली एक महिला के साथ मेरी first date थी; वह अकेली आई थी और साफ था कि वह अपनी सुरक्षा को लेकर सजग थी, इसलिए उसने मेरा background check किया था और आसपास की community के कुछ लोगों को हमारी location भी बता रखी थी
    दूसरी तरफ, मुझे उसका surname भी नहीं पता था, और मैंने इसे मजाक का विषय बनाया। dinner के बाद जब हम कार में बैठे, dashboard screen पर दिखा कि iPhone अपने-आप pair हो गया है, और उस iPhone का नाम उसके first name और surname पर था—यह देखकर मुझे दिलचस्पी हुई। मैंने उसे बताया नहीं, और drive खत्म होने तक उससे अंदाजा लगाने को कहा कि मुझे नाम कैसे पता चला

    • rental cars में अक्सर पहले pair किए गए phones के दर्जनभर profiles बचे होते हैं, और उनके साथ phonebook, saved map locations और history तक जुड़ी होती है। बेशक, काम की चीजें ज्यादा नहीं होतीं, लेकिन बिना सोचे-समझे information leak हो जाती है
      दिक्कत यह है कि car return करने से पहले अपना profile delete करना खुद को याद दिलाना ही सबसे मुश्किल होता है

  • ऊपर वाले example में valid address में 4 milliseconds, invalid address में 5 seconds लगते हैं
    यह unexpected है। मुझे लगा था कि DNS lookup failure, successful DNS lookup के बाद आने वाले default connection timeout से कहीं तेज होगा
    फिर भी s-mac-xxxx हमेशा थोड़ा अजीब choice लगा। खासकर यह देखते हुए कि company privacy को बड़ा selling point बनाती है। शायद उन्होंने उम्मीद की होगी कि लोग real name नहीं इस्तेमाल करेंगे, या यहां “user-friendliness” को प्राथमिकता दी गई होगी। privacy के लिहाज से Windows के randomly generated hostname बेहतर हैं

    • सामान्य DNS में एक single IP वाले single server से yes/no जवाब पूछा जाता है, लेकिन mDNS multicast है, इसलिए कोई एक server अधिकारपूर्वक “नहीं” नहीं कह सकता†। जब कोई server जवाब नहीं देता और lookup timeout होता है, तभी पता चलता है कि record नहीं है
      † सख्ती से कहें तो यह पूरी तरह सही नहीं है। अगर किसी device को पता है कि वह उस name का मालिक है, तो वह no कह सकता है
    • user का real name hostname में होने की वजह शायद AirDrop हो सकती है। ऐसा लगता है कि system Personal Hotspot या AirDrop जैसी features में hostname इस्तेमाल करता है, और अलग तरह के names file share करते समय बड़े पैमाने पर confusion पैदा कर सकते हैं
    • default connection timeout वाली बात के अलावा, यहां यह भी है कि यह connection refused, यानी RST मिला था, connection timeout नहीं था

  • लेख अच्छी तरह लिखा गया है और रोचक है। खासकर “inherent weakness और बहुत सी limitations को देखते हुए यह attack practical नहीं है” जैसी बिना अतिशयोक्ति वाली tone पसंद आई

    • किसी और universe में यह “FINGERBleed” बन जाता, और इसके साथ एक stylish website और logo भी होता
    • पक्का नहीं
      यह तरीका यह test करने देता है कि network में कोई specific hostname मौजूद है या नहीं
      एक unique hostname हो तो शायद बड़ी समस्या न हो, लेकिन IoT दुनिया में आम fixed hostname या default hostname का क्या
      website चुपचाप अंदाजा लगा सकती है कि user के पास कोई specific device है या नहीं। targeted attack में इस्तेमाल हो तो और भी बुरा। अगर network के कुछ devices के बारे में पता हो, तो यह अंदाजा लगाया जा सकता है कि connected user target network के अंदर है या नहीं

  • काश JavaScript बंद करने से end-user experience भी बंद न हो जाता

    • यही एकमात्र वजह है कि मैं JavaScript globally disable नहीं कर पाता
      फिर भी लगता है कि privacy concerns की वजह से आगे चलकर इसे default रूप से बंद रखना पड़ेगा
    • क्या JavaScript engine जो कर सकता है, उसे सख्ती से limit करने का कोई तरीका नहीं है?

  • शुक्र है, मेरे device names आम तौर पर “xxxs's MacBook Pro (34)” जैसे होते हैं। bug नहीं, feature है

    • laptop का username user, hostname hostname सेट करें। जितने ज्यादा लोग ऐसा करेंगे, उतना बेहतर

  • रोचक है, लेख भी अच्छा लिखा है, और एक ठीक-ठाक proof of concept भी है। बढ़िया बनाया है
    एक मजेदार countermeasure यह हो सकता है कि device hostname को atemptingurl.local जैसा कुछ बदल दें, ताकि attacker उस website को visit करना चाहे। उस page को इस तरह crafted रखा जाए कि वही technique attacker पर चलाए, और ऐसा message लौटाए:
    “नमस्ते [hacker का device name]! आपकी machine information, IP address, geolocation और दूसरी fingerprint information collect कर ली गई है और [डरावने cyber agency का नाम डालें] को report कर दी गई है।” अगर सामने वाला seasoned veteran हो और script kiddie न हो, तब भी कम-से-कम उसे हंसा तो सकता है
    लोगों को हंसने की वजहें और चाहिए :-)

    • ऐसा करने के लिए CORS allow-all enabled HTTP server चलाना होगा। तब आप चुने हुए HTTP server के सभी bugs के exposure में आ जाएंगे, इसलिए अपनी security भी कम हो जाएगी