Anda tidak bisa begitu saja mengakses tautan keamanan privat secara publik, bukan?

Tautan keamanan privat yang tidak dapat diakses publik, benarkah demikian?

• Alat analisis malware/URL populer seperti urlscan.io, Hybrid Analysis, dan pemindai URL Cloudflare Radar menyimpan banyak tautan untuk pengumpulan dan berbagi informasi.
• Fakta bahwa layanan-layanan ini menyimpan tautan pribadi dan sensitif yang dipindai sebagai data publik, baik karena tidak sengaja dikirimkan oleh pengguna maupun karena pemindai dan ekstensi yang salah konfigurasi, belum banyak diketahui.

Tautan seperti apa yang dimaksud?

• File yang dibagikan menggunakan alat penyimpanan cloud (Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive, AWS S3, dll.).
• Alat NAS terhubung cloud (Western Digital Mycloud, dll.).
• Komunikasi perusahaan (Slido, Zoom, Onedrive, Airtable, dll.).
• Tautan reset kata sandi, tautan login OAuth, dan sebagainya.
• Layanan-layanan ini memiliki kesamaan berupa penggunaan satu tautan privat tunggal yang berisi pengenal acak untuk mengakses layanan. Kadang tautan ini juga dilindungi tambahan dengan kata sandi atau frasa sandi; dalam kasus seperti itu, mengakses tautan tidak serta merta menyebabkan kebocoran data.

Siapa yang harus bertanggung jawab?

• Menurut syarat layanan Hybrid Analysis dan urlscan.io, tanggung jawab atas konten yang dikirimkan ada pada pengguna, dan tidak ada mekanisme untuk meninjau serta menghapus tautan sensitif.
• Menerapkannya secara otomatis mungkin juga tidak mudah.
• Sebagai peneliti keamanan, sulit untuk melacak asal tautan-tautan tersebut.

Kami pemburu ancaman! Semua tautan adalah milik kami!

• urlscan Pro mengizinkan pengguna/perusahaan berbayar mengakses pemindaian Unlisted selain Public.
• Unlisted tidak terlihat di halaman publik atau hasil pencarian, tetapi terlihat oleh pelanggan platform urlscan Pro.
• Cortex-Analyzers milik TheHive secara eksplisit menggunakan konfigurasi public:on pada penganalisis urlscan.io sehingga tautan muncul sebagai unlisted.
• Bagi pengguna urlscan Pro, data ini tidak dipublikasikan tetapi tetap dapat diakses, sehingga ada risiko kebocoran informasi sensitif yang lebih besar.

Bagaimana cara menghapus tautan sensitif?

• Urlscan dan Hybrid Analysis memungkinkan tautan diberi tanda agar dapat dihapus.
• Dalam kasus Hybrid Analysis, semua file yang dikirim ke sandbox publik dapat dicari dan terbuka untuk umum di seluruh dunia.

Kesimpulan

• Masalah ini hampir pasti akan terus berlanjut, tetapi menjaga pemindaian tetap privat secara default mungkin merupakan solusi terbaik, meskipun itu tidak sejalan dengan tujuan praktik berbagi intelijen ancaman dan analisis di komunitas keamanan.
• Saat menggunakan layanan-layanan ini, perhatikan visibilitas pemindaian.

Sanggahan

• Jika Anda memilih untuk mengakses tautan/file semacam ini dari basis data URL, berhati-hatilah terhadap file dan tautan yang benar-benar berbahaya.
• Sebagian mungkin hanya upaya phishing biasa, tetapi bisa juga berisi malware nyata.
• Disarankan menggunakan lingkungan sandbox.

Tautan berguna

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

Opini GN⁺

• Artikel ini menunjukkan bagaimana alat keamanan dapat tanpa sengaja membuka informasi sensitif, sehingga menjadi pengingat penting bagi peneliti keamanan maupun pengguna umum.
• Masalah seperti ini dapat muncul akibat kesalahan pengguna atau konfigurasi alat yang keliru, dan menuntut perhatian serta tanggung jawab yang lebih besar dalam penanganan informasi sensitif di komunitas keamanan.
• Artikel ini juga menekankan pentingnya langkah-langkah yang perlu diambil individu dan perusahaan untuk melindungi data mereka.
• Dari sudut pandang kritis, kebocoran semacam ini dapat menjadi ancaman serius terhadap privasi individu dan kerahasiaan perusahaan, serta memunculkan pertanyaan tentang keandalan alat dan layanan keamanan.
• Proyek lain dengan fungsi serupa mencakup platform analisis malware seperti VirusTotal atau Any.run, dan saat menggunakan layanan semacam ini, status keterbukaan data harus selalu ditinjau dengan cermat.

[GN⁺]

Komentar Hacker News

• Masalah mendasarnya adalah tautan tersebut tidak memiliki kontrol akses, dan hanya dianggap privat karena tidak ada indeks publik. Ada cerita yang populer di Hacker News terkait menemukan ID akun AWS melalui bucket, dan konsensus yang muncul di komentar adalah bahwa mengandalkan kerahasiaan identitas akun sebagai bagian dari keamanan adalah pendekatan yang keliru. Ini hanyalah metode lain dari 'dorking'.

  • Kerahasiaan tautan: Menganggap tautan sebagai privat hanya karena tidak diindeks secara publik adalah hal yang bermasalah. Mengandalkan kerahasiaan ID akun AWS bukan pendekatan keamanan yang benar, dan ini bukan isu keamanan baru melainkan salah satu bentuk 'dorking'.

• Jika ingin membuat tautan yang bisa dibagikan secara privat, informasi rahasia harus disimpan di bagian hash URL. Hash tidak disertakan dalam kueri DNS maupun permintaan HTTP. Misalnya, tautan dengan format links.com#<secret> tidak pernah keluar dari browser. Sebaiknya data pada bagian hash dikodekan sebagai string Base64 yang aman untuk URL.

  • Berbagi tautan dengan aman: Tautan dapat dibagikan dengan lebih aman dengan menyimpan informasi rahasia di bagian hash URL. Metode ini lebih aman karena hash tidak disertakan dalam kueri DNS maupun permintaan HTTP.

• Saya pribadi selalu curiga terhadap tautan "privat" yang bisa dipakai tanpa batas. Itu hanya keamanan melalui obscurity. Lebih baik jika ada opsi eksplisit seperti di Google Docs, yaitu "siapa pun yang memiliki URL dapat mengakses". Dalam sistem yang saya bangun, saya menggunakan URL bertanda tangan dengan masa berlaku singkat, dan URL ini tidak pernah ditampilkan langsung kepada pengguna.

  • Keraguan terhadap tautan privat: Tautan "privat" pada praktiknya sering hanya mengandalkan keamanan melalui obscurity, dan penggunaan URL bertanda tangan dengan masa berlaku singkat adalah metode yang lebih aman.

• Tautan apa pun yang bukan bagian dari loop redirect cepat akan disalin dan dibagikan. URL itu universal dan memang memudahkan akses ke sumber daya dalam protokol. Kontrol akses untuk apa pun yang masa berlakunya tidak terlalu singkat harus dilakukan di luar URL. Saat membagikan tautan melalui kanal yang bukan e2ee, pihak pertama yang mengakses URL bisa jadi bukan penerima yang dituju, melainkan layanan dari kanal tersebut. Alat pemindai semacam ini tidak akan meningkatkan UX jika pengguna diberi tahu secara eksplisit bahwa pemindaian itu bersifat publik.

  • Kontrol akses melalui URL: URL dibagikan untuk memudahkan akses ke sumber daya, sehingga kontrol akses seharusnya dilakukan dengan cara lain, bukan melalui URL itu sendiri. Alat seperti pemindai juga tidak membantu meningkatkan UX jika pengguna diberi tahu soal pemindaian publik karena itu bisa membuat mereka ragu menggunakan layanan.

• Solusi untuk masalah "autentikasi berbasis email" adalah memakai kode sekali pakai yang tidak menimbulkan masalah meskipun URL tidak sengaja dibagikan, tanpa perlu tahap pembuatan akun dan kata sandi. Ketika pengguna mengunjungi tautan "privat", situs akan kembali mengirimkan kode sekali pakai yang memiliki batas waktu melalui email, dan pengguna memasukkan kode sementara itu untuk memverifikasi kepemilikan email.

  • Autentikasi email dan kode sekali pakai: Masalah autentikasi berbasis email dapat diatasi dengan menggunakan kode sekali pakai, sehingga URL yang tidak sengaja dibagikan tidak menjadi masalah.

• Di internet, jika URL tidak memiliki perlindungan lebih dari sekadar string acak, maka pada dasarnya URL itu tidak privat. Ini sama seperti cerita tentang menemukan webcam yang terhubung ke internet. Kita seharusnya sudah tahu hal ini. Mengapa bagian "siapa yang harus bertanggung jawab" tidak menyebutkan hal ini?

  • Sifat privat URL: Jika URL tidak dilindungi lebih dari sekadar string acak, maka URL itu tidak benar-benar privat, dan ini seharusnya sudah menjadi pengetahuan umum.

• Ini agak di luar topik, tetapi ada tautan yang menyebut Cloudflare Radar menambang data dari 1.1.1.1. Bukankah saya selama ini mengira 1.1.1.1 tidak menggunakan data pengguna untuk tujuan apa pun?

  • Cloudflare Radar dan 1.1.1.1: Ada klaim bahwa Cloudflare Radar menambang data dari 1.1.1.1, dan ini bertentangan dengan kesan sebelumnya bahwa 1.1.1.1 tidak menggunakan data pengguna.

• Tautan rapat Zoom sering menambahkan kata sandi sebagai parameter kueri. Apakah ini tautan yang "privat dan aman"? Apakah tanpa kata sandi tautan itu tetap "privat dan aman"?

  • Keamanan tautan rapat Zoom: Ada pertanyaan mengenai keamanan tautan rapat Zoom saat kata sandi disertakan maupun saat tidak disertakan.

• Bisakah Anda menjelaskan mana yang lebih aman dari dua kasus berikut?

  1. domain.com/login pengguna: John kata sandi: kata sandi acak 5 digit
  2. domain.com/URL-acak-12-digit Dengan asumsi keduanya memiliki perlindungan acak/pembatasan laju yang sama atau sama-sama tidak memilikinya, mengapa nomor 1 lebih aman daripada nomor 2?
  • Perbandingan keamanan login: Ada pertanyaan tentang perbandingan keamanan dua metode login yang berbeda.

• Semua media/foto yang diunggah ke aplikasi privat di airtable.com adalah tautan publik, dan siapa pun dapat mengaksesnya tanpa autentikasi jika mengetahui URL-nya.

  • Tautan publik di Airtable.com: Media/foto yang diunggah ke airtable.com tersedia melalui tautan publik, sehingga siapa pun yang mengetahui URL dapat mengaksesnya.