आप सिर्फ़ private security links को public तौर पर access नहीं कर सकते, है न?

 (vin01.github.io)
2 पॉइंट द्वारा GN⁺ 2024-03-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें

जो private security links public तौर पर accessible नहीं होने चाहिए, क्या वे सच में सुरक्षित हैं?

  • लोकप्रिय malware/URL analysis tools जैसे urlscan.io, Hybrid Analysis, और Cloudflare Radar URL Scanner जानकारी इकट्ठा करने और साझा करने के लिए बड़ी मात्रा में links स्टोर करते हैं.
  • यह बात ज़्यादा जानी-पहचानी नहीं है कि ये सेवाएँ निजी और संवेदनशील links भी स्टोर कर रही हैं, जो या तो यूज़र्स द्वारा गलती से submit किए गए हैं या गलत configure किए गए scanners और extensions द्वारा public data के रूप में scan हुए हैं.

किस तरह के links की बात हो रही है?

  • cloud storage tools (Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive, AWS S3 आदि) के ज़रिए share की गई files.
  • cloud-connected NAS tools (Western Digital Mycloud आदि).
  • enterprise communication (Slido, Zoom, Onedrive, Airtable आदि).
  • password reset links, OAuth login links आदि.
  • इन सेवाओं में एक समान बात यह है कि ये service access देने के लिए random identifiers वाले एकल private link का उपयोग करती हैं. कभी-कभी इन्हें password या passphrase से अतिरिक्त रूप से सुरक्षित किया जाता है, और ऐसे मामलों में सिर्फ़ link तक पहुँच होने से data exposure नहीं होता.

ज़िम्मेदारी किसकी होनी चाहिए?

  • Hybrid Analysis और urlscan.io की terms of service के अनुसार, submit किए गए content की ज़िम्मेदारी user की होती है, और sensitive links की समीक्षा कर उन्हें हटाने का कोई mechanism नहीं है.
  • इसे automated तरीके से implement करना भी आसान नहीं हो सकता.
  • एक security researcher के रूप में, इन links के source का पता लगाना मुश्किल है.

हम threat hunters हैं! सारे links हमारे हैं!

  • urlscan Pro paid users/companies को Public के साथ-साथ Unlisted scans तक भी access देता है.
  • Unlisted public pages या search results में दिखाई नहीं देता, लेकिन urlscan Pro platform के customers को दिखता है.
  • TheHive के Cortex-Analyzers urlscan.io analyzer में public:on configuration को स्पष्ट रूप से इस्तेमाल करते हैं, जिससे link unlisted के रूप में दिखाई देता है.
  • urlscan Pro users के लिए data public नहीं होता, लेकिन accessible होता है, इसलिए अधिक sensitive information leak होने का जोखिम रहता है.

sensitive links को कैसे हटाया जा सकता है?

  • Urlscan और Hybrid Analysis links को flag करके हटाने की सुविधा देते हैं.
  • Hybrid Analysis के मामले में, public sandbox में submit की गई सभी files searchable होती हैं और पूरी दुनिया के लिए public होती हैं.

निष्कर्ष

  • यह समस्या बनी रहेगी, इसमें कोई संदेह नहीं है, लेकिन scans को default रूप से private रखना शायद सबसे अच्छा समाधान हो सकता है, हालांकि यह security community की threat intelligence और analysis sharing practices के उद्देश्य से मेल नहीं खाता.
  • इन सेवाओं का उपयोग करते समय scan visibility पर ध्यान देना चाहिए.

अस्वीकरण

  • यदि आप url database में ऐसे links/files तक पहुँचने का विकल्प चुनते हैं, तो वास्तविक malicious files और links से सावधान रहें.
  • इनमें से कुछ केवल phishing attempts हो सकते हैं और इनमें वास्तविक malware शामिल हो सकता है.
  • sandbox environment का उपयोग करने की सिफारिश की जाती है.

उपयोगी links

  • urlscan.io का SOAR spot: Chatty security tools leaking private data (2022)
  • urlscan.io Search API Reference
  • Falcon Sandbox Public API
  • Cloudflare Radar URL Scanner

GN⁺ की राय

  • यह लेख दिखाता है कि security tools किस तरह गलती से sensitive information को public कर सकते हैं, जिससे security researchers और आम users दोनों के लिए सतर्क रहने की ज़रूरत सामने आती है.
  • ऐसी समस्याएँ user की गलती या tools की गलत configuration के कारण हो सकती हैं, और यह security community के भीतर sensitive information को संभालने में अधिक सावधानी और ज़िम्मेदारी की माँग करती हैं.
  • यह लेख इस बात पर भी ज़ोर देता है कि individuals और companies को अपने data की सुरक्षा के लिए कौन से कदम उठाने चाहिए.
  • आलोचनात्मक नज़रिए से देखें तो ऐसे leaks व्यक्तिगत privacy और corporate confidentiality, दोनों के लिए गंभीर खतरा बन सकते हैं, और इससे security tools व services की reliability पर सवाल उठ सकते हैं.
  • इसी तरह की functionality देने वाले अन्य projects में VirusTotal और Any.run जैसे malware analysis platforms शामिल हैं, और ऐसी services का उपयोग करते समय हमेशा data की public visibility को सावधानी से जाँचना चाहिए.

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

1 टिप्पणियां

 
GN⁺ 2024-03-08
Hacker News राय

  • मूल समस्या यह है कि लिंक पर कोई access control नहीं है, और सिर्फ इसलिए इसे private मान लिया जाता है क्योंकि इसका कोई public index नहीं है। bucket के ज़रिए AWS account ID पता लगाने वाली बात Hacker News पर लोकप्रिय हुई थी, और comments से निकला consensus यह था कि account identifiers के private होने को security का हिस्सा मानकर भरोसा करना गलत तरीका है। यह बस एक और dorking तरीका है।

    • लिंक की निजीता: सिर्फ इसलिए कि लिंक publicly index नहीं होता, उसे private मान लेना समस्याग्रस्त है। AWS account ID की गोपनीयता पर निर्भर रहना security के लिहाज़ से सही तरीका नहीं है, और यह कोई नया security issue नहीं बल्कि dorking का ही एक रूप है।

  • अगर personal sharing के लिए लिंक बनाना है, तो secret information को URL के hash हिस्से में रखना चाहिए। hash, DNS query या HTTP request में शामिल नहीं होता। उदाहरण के लिए, links.com#<secret> फ़ॉर्मेट का लिंक browser के बाहर नहीं जाता। hash हिस्से के data को URL-safe Base64 string में encode करना बेहतर है।

    • लिंक को सुरक्षित तरीके से साझा करना: URL के hash हिस्से में secret information रखकर लिंक को अधिक सुरक्षित तरीके से साझा किया जा सकता है। यह तरीका इसलिए सुरक्षित है क्योंकि hash, DNS query या HTTP request में शामिल नहीं होता।

  • मुझे हमेशा unlimited-use वाले "private" लिंक संदिग्ध लगे हैं। यह बस security through obscurity है। Google Docs की तरह, जहाँ साफ़ तौर पर "URL वाला कोई भी व्यक्ति access कर सकता है" जैसा विकल्प हो, वह बेहतर है। लेखक द्वारा बनाए गए सिस्टम में short-lived signed URL इस्तेमाल होते हैं, और ये URL user को सीधे दिखाए नहीं जाते।

    • "Private" लिंक को लेकर संदेह: "Private" लिंक वास्तव में सिर्फ obscurity पर आधारित security हैं, और short-lived signed URL इस्तेमाल करना अधिक सुरक्षित तरीका है।

  • जो लिंक तेज़ redirect loop का हिस्सा नहीं हैं, वे कॉपी होकर साझा किए जाएँगे। URL universal होते हैं और protocol पर resources तक पहुँच आसान बनाने के लिए होते हैं। जो भी चीज़ थोड़े लंबे समय तक valid रहती है, उसका access control URL के बाहर होना चाहिए। जब e2ee-न-होने वाले चैनल में लिंक साझा किया जाता है, तो URL तक पहली पहुँच intended recipient की नहीं बल्कि उस चैनल की service की भी हो सकती है। ऐसे scanner tools अगर users को साफ़-साफ़ बताएँ कि scan public है, तो इससे UX बेहतर नहीं होगा।

    • URL के ज़रिए access control: URL resources तक पहुँच आसान बनाने के लिए साझा किए जाते हैं, इसलिए access control URL के बजाय किसी और तरीके से होना चाहिए। scanner जैसे tools अगर public scan के बारे में users को बताएँ, तो इससे UX बेहतर होने के बजाय लोग service इस्तेमाल करने में हिचक सकते हैं।

  • "Email-based authentication" समस्या का समाधान यह है कि account और password बनाने वाले step के बिना, ऐसे one-time code इस्तेमाल किए जाएँ जिनसे URL गलती से share हो जाए तो भी समस्या न हो। जब user उस "private" लिंक पर जाता है, तो site समय-सीमा वाला one-time code फिर से email पर भेजती है, और user email ownership verify करने के लिए वह temporary code दर्ज करता है।

    • ईमेल authentication और one-time code: email-based authentication की समस्या हल करने के लिए one-time code इस्तेमाल किए जा सकते हैं, जिससे URL गलती से share हो जाने पर भी जोखिम कम रहता है।

  • इंटरनेट पर अगर URL के पास random string से ज़्यादा कोई protection नहीं है, तो वे वास्तव में private नहीं हैं। यह वैसा ही है जैसे इंटरनेट से जुड़े webcam ढूँढना। हमें यह बात पहले से पता होनी चाहिए। फिर "किसकी ज़िम्मेदारी है" वाले section में इसका ज़िक्र क्यों नहीं है?

    • URL की private प्रकृति: अगर URL के पास random string से आगे कोई protection नहीं है, तो वे private नहीं माने जा सकते, और यह पहले से जानी-पहचानी बात है।

  • यह थोड़ा off-topic है, लेकिन एक लिंक है जिसमें कहा गया है कि Cloudflare Radar, 1.1.1.1 से data mine करता है। मुझे लगा था कि 1.1.1.1 किसी भी उद्देश्य से user data इस्तेमाल नहीं करता?

    • Cloudflare Radar और 1.1.1.1: यह दावा किया गया है कि Cloudflare Radar, 1.1.1.1 से data mine करता है, जो इस धारणा से टकराता है कि 1.1.1.1 user data का उपयोग नहीं करता।

  • Zoom meeting links में अक्सर query parameter के रूप में password जोड़ दिया जाता है। क्या ऐसा लिंक "private और secure" लिंक है? और password के बिना क्या वह "private और secure" लिंक है?

    • Zoom meeting links की सुरक्षा: password के साथ और बिना password के Zoom meeting links कितने सुरक्षित हैं, इस पर सवाल उठाया गया है।

  • क्या कोई समझा सकता है कि नीचे दिए गए दो मामलों में कौन-सा ज़्यादा सुरक्षित है?

    1. domain.com/login उपयोगकर्ता नाम: John पासवर्ड: 5-अंकों का random password
    2. domain.com/12-अक्षरों वाला random URL अगर दोनों मामलों में एक जैसी randomness/rate-limit protection मानें, या बिल्कुल भी न मानें, तो 1) को 2) से ज़्यादा सुरक्षित क्यों माना जाए?
    • लॉगिन सुरक्षा की तुलना: दो अलग-अलग login तरीकों की सुरक्षा की तुलना को लेकर प्रश्न।

  • private airtable.com app में upload की गई सभी media/photos public links होती हैं, और URL पता हो तो authentication के बिना access किया जा सकता है.

    • Airtable.com के public links: airtable.com पर upload की गई media/photos public links होती हैं, इसलिए सिर्फ URL जानने पर कोई भी उन्हें access कर सकता है।