คุณไม่สามารถเข้าถึงลิงก์ความปลอดภัยส่วนตัวแบบสาธารณะได้ง่าย ๆ หรอก จริงไหม?

 (vin01.github.io)
2 คะแนน โดย GN⁺ 2024-03-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ลิงก์ความปลอดภัยส่วนตัวที่เข้าถึงแบบสาธารณะไม่ได้ จริงหรือ?

  • เครื่องมือวิเคราะห์มัลแวร์/URL ยอดนิยมอย่าง urlscan.io, Hybrid Analysis และ Cloudflare Radar URL Scanner เก็บลิงก์จำนวนมากไว้เพื่อการรวบรวมและแบ่งปันข้อมูล
  • แต่ยังไม่เป็นที่รับรู้อย่างกว้างขวางว่า บริการเหล่านี้กำลังเก็บลิงก์ที่เป็นข้อมูล ส่วนตัวและอ่อนไหว ซึ่งถูกส่งเข้าไปโดยผู้ใช้โดยไม่ตั้งใจ หรือถูกสแกนเป็นข้อมูลสาธารณะผ่านสแกนเนอร์และส่วนขยายที่ตั้งค่าผิดพลาด

กำลังพูดถึงลิงก์แบบไหน?

  • ไฟล์ที่แชร์ผ่านเครื่องมือคลาวด์สตอเรจ (Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive, AWS S3 เป็นต้น)
  • เครื่องมือ NAS ที่เชื่อมต่อกับคลาวด์ (Western Digital Mycloud เป็นต้น)
  • เครื่องมือสื่อสารในองค์กร (Slido, Zoom, Onedrive, Airtable เป็นต้น)
  • ลิงก์รีเซ็ตรหัสผ่าน, ลิงก์ล็อกอิน OAuth เป็นต้น
  • บริการเหล่านี้มีจุดร่วมคือใช้ลิงก์ส่วนตัวเพียงลิงก์เดียวที่มีตัวระบุแบบสุ่มเพื่อให้เข้าถึงบริการได้ บางครั้งอาจมีการป้องกันเพิ่มเติมด้วยรหัสผ่านหรือ passphrase ซึ่งในกรณีนั้น การเข้าถึงลิงก์เพียงอย่างเดียวจะไม่ทำให้ข้อมูลรั่วไหล

ใครควรรับผิดชอบ?

  • ตามข้อกำหนดการใช้งานของ Hybrid Analysis และ urlscan.io ความรับผิดชอบต่อเนื้อหาที่ส่งเข้าระบบเป็นของผู้ใช้ และไม่มีระบบสำหรับตรวจสอบและลบลิงก์อ่อนไหวโดยตรง
  • การทำสิ่งนี้ให้เป็นระบบอัตโนมัติก็อาจไม่ใช่เรื่องง่าย
  • ในฐานะนักวิจัยด้านความปลอดภัย การระบุแหล่งที่มาของลิงก์เหล่านี้ก็ทำได้ยาก

เราคือนักล่าภัยคุกคาม! ทุกลิงก์เป็นของเรา!

  • urlscan Pro อนุญาตให้ผู้ใช้/บริษัทแบบชำระเงินเข้าถึงสแกนแบบ Unlisted ได้ ไม่ใช่แค่ Public
  • Unlisted จะไม่ปรากฏบนหน้าสาธารณะหรือในผลการค้นหา แต่ลูกค้าของแพลตฟอร์ม urlscan Pro ยังมองเห็นได้
  • Cortex-Analyzers ของ TheHive ใช้การตั้งค่า public:on อย่างชัดเจนในตัววิเคราะห์ urlscan.io ทำให้ลิงก์แสดงผลเป็น unlisted
  • แม้ข้อมูลจะไม่เปิดสู่สาธารณะสำหรับผู้ใช้ urlscan Pro แต่ก็ยังเข้าถึงได้ จึงมีความเสี่ยงที่ข้อมูลอ่อนไหวจะรั่วไหลมากขึ้น

จะลบลิงก์อ่อนไหวได้อย่างไร?

  • Urlscan และ Hybrid Analysis อนุญาตให้ทำเครื่องหมายลิงก์เพื่อขอให้นำออกได้
  • ในกรณีของ Hybrid Analysis ไฟล์ทั้งหมดที่ส่งเข้า public sandbox จะสามารถค้นหาได้และเปิดเผยต่อคนทั่วโลก

บทสรุป

  • ปัญหานี้น่าจะยังคงเกิดขึ้นต่อไป แต่ทางออกที่ดีที่สุดอาจเป็นการตั้งค่าให้การสแกนเป็นแบบส่วนตัวโดยค่าเริ่มต้น อย่างไรก็ตาม แนวทางนี้ไม่สอดคล้องกับเป้าหมายของชุมชนความปลอดภัยที่ต้องการแบ่งปัน threat intelligence และผลการวิเคราะห์
  • เมื่อต้องใช้บริการเหล่านี้ ควรใส่ใจกับระดับการมองเห็นของการสแกน

ข้อปฏิเสธความรับผิดชอบ

  • หากคุณเลือกเข้าถึงลิงก์/ไฟล์เหล่านี้จากฐานข้อมูล URL ควรระวังไฟล์และลิงก์ที่เป็นอันตรายจริง
  • บางส่วนอาจเป็นเพียงความพยายามฟิชชิงธรรมดา แต่บางส่วนก็อาจมีมัลแวร์จริงอยู่ด้วย
  • แนะนำให้ใช้สภาพแวดล้อม sandbox

ลิงก์ที่มีประโยชน์

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

ความเห็นของ GN⁺

  • บทความนี้ชี้ให้เห็นว่าเครื่องมือด้านความปลอดภัยสามารถเปิดเผยข้อมูลอ่อนไหวโดยไม่ตั้งใจได้อย่างไร ซึ่งเป็นการเตือนทั้งนักวิจัยด้านความปลอดภัยและผู้ใช้ทั่วไป
  • ปัญหาเหล่านี้อาจเกิดจากความผิดพลาดของผู้ใช้หรือการตั้งค่าเครื่องมือที่ไม่ถูกต้อง และสะท้อนว่าชุมชนความปลอดภัยต้องระมัดระวังและรับผิดชอบต่อการจัดการข้อมูลอ่อนไหวมากขึ้น
  • บทความนี้ยังตอกย้ำความสำคัญของการที่ทั้งบุคคลและองค์กรต้องมีมาตรการปกป้องข้อมูลของตนเอง
  • หากมองในเชิงวิพากษ์ การรั่วไหลลักษณะนี้อาจเป็นภัยร้ายแรงต่อความเป็นส่วนตัวของบุคคลและการรักษาความลับขององค์กร และอาจทำให้เกิดคำถามต่อความน่าเชื่อถือของเครื่องมือและบริการด้านความปลอดภัย
  • โครงการอื่นที่มีฟังก์ชันคล้ายกัน ได้แก่แพลตฟอร์มวิเคราะห์มัลแวร์อย่าง VirusTotal หรือ Any.run และเมื่อใช้บริการเหล่านี้ก็ควรตรวจสอบอย่างรอบคอบเสมอว่าข้อมูลจะถูกเปิดเผยหรือไม่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-03-08
ความคิดเห็นจาก Hacker News

  • ปัญหาพื้นฐานคือไม่มีการควบคุมการเข้าถึงลิงก์ โดยสมมติว่ามันเป็นแบบส่วนตัวเพราะไม่มีดัชนีสาธารณะ เรื่องการค้นพบ AWS account ID ผ่านบักเก็ตเคยได้รับความนิยมบน Hacker News และข้อสรุปจากคอมเมนต์คือการพึ่งพาความไม่เปิดเผยของตัวระบุบัญชีเป็นส่วนหนึ่งของความปลอดภัยนั้นเป็นแนวทางที่ผิด นี่ก็เป็นเพียงอีกวิธีหนึ่งของการทำ "dorking" เท่านั้น

    • ความเป็นส่วนตัวของลิงก์: การสมมติว่าลิงก์เป็นส่วนตัวเพียงเพราะไม่ได้ถูกจัดทำดัชนีแบบสาธารณะนั้นมีปัญหา การพึ่งพาความไม่เปิดเผยของ AWS account ID ไม่ใช่แนวทางด้านความปลอดภัยที่ถูกต้อง และนี่ไม่ใช่ปัญหาความปลอดภัยใหม่ แต่เป็นรูปแบบหนึ่งของ "dorking"

  • ถ้าต้องการสร้างลิงก์ที่แชร์กันได้แบบส่วนตัว ควรเก็บข้อมูลลับไว้ในส่วน hash ของ URL เพราะ hash จะไม่ถูกรวมอยู่ใน DNS query หรือ HTTP request ตัวอย่างเช่น ลิงก์รูปแบบ links.com#<secret> จะไม่ออกไปนอกเบราว์เซอร์ ควรเข้ารหัสข้อมูลในส่วน hash เป็นสตริง Base64 ที่ปลอดภัยสำหรับ URL

    • การแชร์ลิงก์อย่างปลอดภัย: สามารถแชร์ลิงก์ได้อย่างปลอดภัยโดยเก็บข้อมูลลับไว้ในส่วน hash ของ URL วิธีนี้ปลอดภัยกว่าเพราะ hash ไม่ถูกรวมอยู่ใน DNS query หรือ HTTP request

  • โดยส่วนตัวแล้วฉันสงสัยมาตลอดเกี่ยวกับลิงก์ "ส่วนตัว" ที่ใช้งานได้ไม่จำกัด มันก็เป็นแค่ security through obscurity เท่านั้น กรณีที่มีตัวเลือกชัดเจนแบบ Google Docs ว่า "ใครก็ตามที่มี URL นี้สามารถเข้าถึงได้" จะดีกว่า ในระบบที่ผู้เขียนสร้างขึ้น มีการใช้ signed URL ที่มีอายุสั้น และ URL นี้จะไม่ถูกแสดงให้ผู้ใช้เห็นโดยตรง

    • ข้อกังขาเกี่ยวกับลิงก์ส่วนตัว: ลิงก์ "ส่วนตัว" แท้จริงแล้วเป็นเพียง security through obscurity และการใช้ signed URL ที่มีอายุสั้นเป็นวิธีที่ปลอดภัยกว่า

  • ลิงก์ใดก็ตามที่ไม่ได้เป็นส่วนหนึ่งของลูป redirect อย่างรวดเร็วจะถูกคัดลอกและแชร์ต่อ URL เป็นสิ่งสากลและมีไว้เพื่อช่วยให้เข้าถึงทรัพยากรตามโปรโตคอลได้ การควบคุมการเข้าถึงสำหรับสิ่งใดก็ตามที่มีอายุไม่สั้นควรทำอยู่นอกเหนือจาก URL เมื่อแชร์ลิงก์ผ่านช่องทางที่ไม่ใช่ e2ee ผู้ที่เข้าถึง URL เป็นรายแรกอาจไม่ใช่ผู้รับ แต่เป็นบริการของช่องทางนั้น หากเครื่องมือสแกนเหล่านี้ระบุให้ผู้ใช้ทราบอย่างชัดเจนว่าการสแกนเป็นแบบสาธารณะ ก็ไม่น่าจะช่วยให้ UX ดีขึ้น

    • การควบคุมการเข้าถึงผ่าน URL: URL มีไว้เพื่อให้ถูกแชร์เพื่อเข้าถึงทรัพยากร และการควบคุมการเข้าถึงควรทำด้วยวิธีอื่นที่ไม่ใช่ URL เครื่องมืออย่างสแกนเนอร์หากแจ้งผู้ใช้เรื่องการสแกนสาธารณะ อาจทำให้ผู้ใช้ลังเลที่จะใช้บริการ จึงไม่ได้ช่วยปรับปรุง UX

  • วิธีแก้ปัญหา "การยืนยันตัวตนผ่านอีเมล" คือไม่ต้องมีขั้นตอนสร้างบัญชีและรหัสผ่าน แต่ใช้ one-time code ที่แม้ URL จะถูกแชร์โดยไม่ตั้งใจก็ไม่เป็นปัญหา เมื่อผู้ใช้เข้าเยี่ยมชมลิงก์ "ส่วนตัว" เว็บไซต์จะส่ง one-time code ที่มีเวลาจำกัดไปยังอีเมลอีกครั้ง แล้วผู้ใช้จึงกรอกรหัสชั่วคราวเพื่อยืนยันความเป็นเจ้าของอีเมล

    • การยืนยันทางอีเมลและ one-time code: ใช้ one-time code เพื่อแก้ปัญหาการยืนยันตัวตนผ่านอีเมล ซึ่งทำให้การแชร์ URL โดยไม่ตั้งใจไม่ก่อปัญหา

  • บนอินเทอร์เน็ต หาก URL ไม่มีการป้องกันมากไปกว่าสตริงสุ่ม มันก็ไม่ได้เป็นส่วนตัวจริง ๆ นี่ก็เหมือนกับเรื่องการค้นหาเว็บแคมที่เชื่อมต่ออินเทอร์เน็ต เราควรรู้อยู่แล้ว แล้วทำไมในส่วน "ใครควรรับผิดชอบ" ถึงไม่พูดถึงเรื่องนี้?

    • ความเป็นส่วนตัวของ URL: หาก URL ไม่มีการป้องกันมากไปกว่าสตริงสุ่ม ก็ไม่ถือว่าเป็นส่วนตัว และนี่เป็นเรื่องที่ทราบกันอยู่แล้ว

  • เป็นเรื่องนอกประเด็นเล็กน้อย แต่มีลิงก์ที่บอกว่า Cloudflare Radar ขุดข้อมูลจาก 1.1.1.1 ฉันนึกว่า 1.1.1.1 ไม่ใช้ข้อมูลผู้ใช้เพื่อวัตถุประสงค์ใด ๆ เสียอีก?

    • Cloudflare Radar และ 1.1.1.1: มีข้ออ้างว่า Cloudflare Radar ขุดข้อมูลจาก 1.1.1.1 ซึ่งขัดกับความเข้าใจเดิมที่ว่า 1.1.1.1 ไม่ใช้ข้อมูลผู้ใช้

  • ลิงก์ประชุม Zoom มักเพิ่มรหัสผ่านไว้ใน query parameter แบบนี้ถือเป็นลิงก์ที่ "เป็นส่วนตัวและปลอดภัย" หรือไม่? แล้วถ้าไม่มีรหัสผ่าน ยังถือว่าเป็นลิงก์ที่ "เป็นส่วนตัวและปลอดภัย" หรือไม่?

    • ความปลอดภัยของลิงก์ประชุม Zoom: เป็นคำถามเกี่ยวกับความปลอดภัยของลิงก์ประชุม Zoom ทั้งในกรณีที่มีรหัสผ่านรวมอยู่และไม่มีรหัสผ่าน

  • ช่วยอธิบายได้ไหมว่าระหว่างสองกรณีต่อไปนี้ แบบไหนปลอดภัยกว่ากัน?

    1. domain.com/login ผู้ใช้: John รหัสผ่าน: รหัสผ่านสุ่ม 5 หลัก
    2. domain.com/URL สุ่ม 12 ตัวอักษร โดยสมมติว่าทั้งสองกรณีมีการป้องกันแบบการสุ่ม/การจำกัดความเร็วเท่ากัน หรือไม่มีเลย ทำไมข้อ 1 ถึงปลอดภัยกว่าข้อ 2?
    • การเปรียบเทียบความปลอดภัยของการล็อกอิน: เป็นคำถามเกี่ยวกับการเปรียบเทียบความปลอดภัยของวิธีล็อกอินสองแบบที่ต่างกัน

  • สื่อ/รูปภาพทั้งหมดที่อัปโหลดไปยังแอป private บน airtable.com เป็นลิงก์สาธารณะ และหากรู้ URL ก็สามารถเข้าถึงได้โดยไม่ต้องยืนยันตัวตน

    • ลิงก์สาธารณะของ Airtable.com: สื่อ/รูปภาพที่อัปโหลดไปยัง Airtable.com เป็นลิงก์สาธารณะ และใครก็ตามที่รู้ URL ก็เข้าถึงได้