Tautan keamanan nonpublik, benarkah tidak bisa diakses secara publik?

 (vin01.github.io)
2 poin oleh GN⁺ 2024-03-08 | 1 komentar | Bagikan ke WhatsApp
  • Layanan analisis URL/malware seperti urlscan.io, Hybrid Analysis, dan Cloudflare Radar URL Scanner menyimpan tautan untuk berbagi threat intelligence, tetapi karena kesalahan pengguna atau pemindai yang salah konfigurasi, tautan sensitif bisa tertinggal sebagai data publik
  • Layanan yang menggunakan URL itu sendiri sebagai hak akses, seperti Dropbox, iCloud, AWS S3, Zoom, OneDrive, Airtable, tautan reset kata sandi, dan tautan login OAuth, bisa terdampak secara khusus
  • Tidak semua tautan langsung terekspos, tetapi dokumen pajak, tagihan, foto, komunikasi kerja, rahasia yang dibagikan lewat onetimesecret, serta materi seperti rumah pintar dan rekaman rapat benar-benar ditemukan
  • urlscan Pro menampilkan bukan hanya Public tetapi juga pemindaian Unlisted kepada pelanggan berbayar, dan bisa ada jalur yang tanpa sengaja mengirimkan sebagai unlisted, seperti pada konfigurasi Cortex-Analyzers milik TheHive
  • Dalam 24 jam terakhir, jumlah pemindaian di urlscan.io adalah Public 398,563, Unlisted 328,147, dan Private 955,432; dalam eksperimen token kanari, akses juga terkonfirmasi dalam 1 jam setelah pengiriman, sehingga pengelolaan visibilitas pemindaian diperlukan

Tautan sensitif yang tertinggal di layanan analisis URL

  • urlscan.io, Hybrid Analysis, dan Cloudflare Radar URL Scanner menyimpan banyak tautan untuk analisis URL dan malware
  • Masalahnya, tautan nonpublik dan sensitif juga bisa ikut masuk ke penyimpanan ini
    • Pengguna mengirim tautan sensitif ke pemindaian tanpa menyadari bahwa itu akan menjadi informasi publik
    • Pemindai atau ekstensi yang salah konfigurasi mengirim tautan privat yang dipindai dari email ke data publik

Tautan dan materi yang bisa terekspos

  • Tautan yang ditemukan mencakup URL berbagi dari berbagai layanan serta URL terkait autentikasi
    • Berbagi file penyimpanan cloud seperti Dropbox, iCloud, Sync, Egnyte, Ionos Hidrive, dan AWS S3
    • NAS yang terhubung ke cloud seperti Western Digital Mycloud
    • Alat komunikasi perusahaan seperti Slido, Zoom, OneDrive, dan Airtable
    • Tautan reset kata sandi dan tautan login OAuth
  • Layanan seperti ini sering mengizinkan akses melalui satu tautan privat yang berisi pengenal acak untuk keamanan
  • Beberapa tautan juga dilindungi tambahan dengan kata sandi atau frasa sandi, jadi akses ke tautan saja tidak selalu langsung membocorkan data
  • Konten sensitif yang benar-benar ditemukan antara lain:
    • File privat seperti dokumen pajak, tagihan, foto, dan komunikasi kerja
    • Rahasia yang dibagikan lewat onetimesecret
    • Rekaman perangkat rumah pintar
    • Rekaman rapat yang disimpan di cloud

Jalur pengiriman dan celah tanggung jawab

  • Banyak kiriman yang ditemukan di urlscan.io memiliki tag falconsandbox, yang kemudian memperluas cakupan analisis hingga ke Hybrid Analysis
  • Cloudflare Radar juga berpotensi digunakan lebih luas, dan saat ini sudah memasukkan beberapa tautan privat ke dalam data publik
  • Ketentuan Hybrid Analysis menyatakan bahwa konten yang dikirim pengguna dapat dianalisis, dipublikasikan, dan dibagikan, serta mereka tidak bertanggung jawab atas informasi yang kebetulan tercantum dalam kiriman atau laporan yang dibuat otomatis
  • Ketentuan urlscan.io juga menyatakan bahwa mereka tidak bertanggung jawab atas konten atau tindakan pengguna, dan bahwa konten serta aktivitas yang diposting di bawah akun menjadi tanggung jawab pengguna
  • Tampaknya tidak ada mekanisme yang jelas untuk meninjau konten yang sudah ada lalu menandai atau menghapus tautan sensitif, dan mengotomatiskannya juga mungkin tidak sederhana
  • Analisis Positive Security menggunakan token kanari terhadap urlscan.io untuk mendeteksi sumber otomatis, dan membahas bahwa alat keamanan yang memindai tautan berbahaya di email bisa menjadi penyebabnya
  • Perilaku yang sama juga diverifikasi dengan tautan kanari

Pemindaian Unlisted dan akses urlscan Pro

  • urlscan Pro memberi pengguna berbayar dan perusahaan akses ke kategori pemindaian yang lebih luas, bukan hanya Public tetapi juga pemindaian Unlisted
  • Di urlscan.io, Unlisted tidak terlihat pada halaman publik atau hasil pencarian, tetapi tetap terlihat oleh pelanggan platform urlscan Pro
    • Dijelaskan bahwa pelanggan urlscan Pro dibatasi pada peneliti keamanan terverifikasi atau perusahaan bereputasi baik
  • Cortex-Analyzers dari TheHive adalah contoh jalur paparan yang tidak disengaja
    • Analyzer urlscan.io secara eksplisit menggunakan pengaturan public:on
    • Karena pengaturan ini, meskipun visibilitas akun urlscan adalah Private, tautan bisa muncul sebagai unlisted
    • Kode terkait ada di urlscan.py milik Cortex-Analyzers
  • Dalam kasus ini, meskipun data tidak sepenuhnya dipublikasikan, data itu masih dapat terlihat oleh pengguna urlscan Pro, sehingga kemungkinan paparan informasi yang lebih sensitif tetap ada

Jumlah pemindaian dan hasil token kanari

  • Berdasarkan 24 jam terakhir, jumlah pemindaian di urlscan.io adalah sebagai berikut
    • Public: 398,563
    • Unlisted: 328,147
    • Private: 955,432
  • Hasil akses yang dikonfirmasi dengan token kanari adalah sebagai berikut
    • Tautan yang dikirim ke urlscan.io sebagai unlisted diakses 12 kali dalam 1 jam setelah pengiriman
    • Tautan yang dikirim ke Hybrid Analysis melalui API, bukan browser, diakses 10 kali dalam 1 jam setelah pengiriman
    • Beberapa alamat IP secara bersamaan mengakses tautan unik yang dikirim ke kedua layanan, dan menggunakan layanan anonimisasi IP asal
  • Daftar alamat IP tersebut dipublikasikan dalam berkas terpisah

Penghapusan tautan sensitif dan hal yang perlu diperhatikan saat penggunaan

  • urlscan.io dan Hybrid Analysis menyediakan prosedur untuk melaporkan tautan agar dihapus
  • Di Hybrid Analysis, penghapusan dan cakupan berbagi lebih kompleks
    • Semua file yang dikirim ke Public Sandbox dapat dicari dan disediakan ke seluruh dunia
    • Sekalipun mencentang kotak “Do not share my sample with the community”, tangkapan layar dan laporan aktual tetap disediakan
    • “do not share” hanya berlaku untuk sampel input yang sebenarnya
  • Saat menggunakan layanan seperti ini, visibilitas pemindaian harus diperiksa terlebih dahulu
  • Saat mengakses tautan atau file dari basis data URL seperti ini, Anda dapat menemukan upaya phishing, file berbahaya sungguhan, atau tautan berbahaya
  • Jika akses memang diperlukan, pemeriksaan harus dilakukan dalam lingkungan sandbox

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-08
Opini Hacker News

  • Masalah mendasarnya adalah tautan tanpa kontrol akses dianggap privat hanya karena tidak ada indeks pengenal publik
    Bulan lalu, pembahasan tentang menemukan ID akun AWS lewat bucket juga cukup ramai di HN[0], dan konsensus di komentarnya adalah bahwa mengandalkan keamanan dengan asumsi pengenal akun itu privat adalah pendekatan yang keliru
    Konsep yang sama berlaku di sini, dan ini bukan isu keamanan baru, melainkan sekadar metode lain dari penelusuran berbasis operator pencarian (dorking)
    [0]: https://news.ycombinator.com/item?id=39512896

    • Masalahnya adalah tautannya bocor
      Secara teori, tautan heksadesimal 256 digit, yakni 1024-bit, jauh lebih sulit ditebak daripada nama pengguna 32 karakter dan kata sandi 32 karakter
      https://site.com/[256chars] memiliki 2^1024 kombinasi sehingga brute force secara praktis mustahil
      Sebaliknya, https://site,com/[32chars] dan kata sandi 32 karakter memiliki 2^256 kombinasi, jadi ini juga nyaris mustahil, tetapi tetap lebih mungkin dibanding yang pertama
      Anggap saja seperti https://site,com/[32chars][32chars]
      Namun meskipun yang pertama lebih sulit ditebak, URL jauh lebih sering bocor daripada kata sandi
    • Mungkin ada detail yang terlewat, tetapi masalah akarnya tampaknya adalah bahwa pesan privat antarorang dianggap benar-benar privat, padahal pada kenyataannya platform yang mengantarkan pesan tersebut membaca pesan itu dan mengakses tautannya
      Di sini pesan mencakup email, DM, sampai tautan yang ditempel ke dokumen
    • Sedikit menyimpang, tetapi baru-baru ini saya mendapat saran dari seorang konsultan bahwa karena tiap nama file NAR memiliki hash raksasa, maka closure Nix privat aman saja diunggah ke bucket S3 yang bisa diakses publik
      Saya merasa tidak nyaman sehingga akhirnya memilih cara lain, tetapi itu terus membuat saya berpikir seberapa besar perbedaan nyata antara menyimpan “rahasia” di dalam URL dan menyimpan rahasia di dalam token yang dikirim saat meminta URL
      Kesimpulan saya adalah token bisa diterbitkan per pelanggan, dan log akses bisa dipantau untuk melihat perilaku mencurigakan lalu mencabutnya
      Seperti kata orang lain juga, ada perbedaan cara pandang soal seberapa penting menjaga daftar nama file tetap rahasia
      Pada skala kesalahan yang mungkin dilakukan Amazon, membocorkan daftar nama file dari bucket publik secara tidak sengaja tampaknya bukan hal yang dipedulikan 99% pengguna, jadi prioritasnya rendah
    • Perusahaan tempat saya dulu bekerja pernah mengalami tabrakan nama bucket S3 saat bekerja dengan perusahaan pelanggan, dan ternyata kedua pihak sama-sama menganggap hyphenated-company-name sebagai nama bucket S3 yang bagus
      Tentu saja perusahaan kami kalah dalam persaingan itu
      Sejak itu, tiap kali memakai AWS, saya mendapat pelajaran kecil bahwa nama bucket sebaiknya biasanya dibuat dalam bentuk -
      Jika benar-benar harus privat, nama proyek pun bisa diacak, lalu sediakan skrip untuk mencantumkan bucket dengan nama yang “akrab”
      Dalam layanan hosting selalu ada kompromi aneh, sehingga pendekatan yang secara teknis paling sempurna, yaitu pengenal acak penuh, kemungkinan membawa beban operasional jauh lebih besar daripada pendekatan yang tidak sempurna, yaitu nama deskriptif
    • Saya penasaran apakah ada perbedaan antara tautan privat yang berisi kata sandi dan situs yang meminta kata sandi setelah membuka tautan
      Bitwarden Send membuat tautan yang bisa diteruskan ke orang lain, dengan string acak panjang setelah #
      Saya memakainya secara rutin, jadi saya ingin tahu apakah ada masalah keamanan
      Setidaknya tautan itu bisa dicabut dan juga bisa kedaluwarsa otomatis setelah beberapa hari, sedangkan kata sandi biasa umumnya tidak bekerja seperti itu

  • Jika ingin membuat tautan berbagi privat, simpan saja nilai privat di bagian hash URL
    Hash tidak dikirim lewat kueri DNS maupun permintaan HTTP
    Misalnya saat mengunjungi links.com?token=, tautan itu akan dikirim termasuk parameter pencarian dan bisa disimpan oleh perantara seperti Cloudflare
    Sebaliknya, saat mengunjungi links.com#, bagian hash tidak keluar dari browser
    Saat menangani data di bagian hash, praktis untuk mengodekannya sebagai string Base64 aman-URL
    Artinya alurnya adalah JS Object ↔ JSON String ↔ URL Safe Base 64 String

    • Jika memakai HTTPS, string parameter dan path juga dienkripsi, jadi agar bisa membaca rahasia itu, perantara tersebut harus dapat mendekripsi trafiknya
      Sisanya benar, saya hanya ingin menambahkan nuansa enkripsi HTTPS ini
    • Ada petunjuk besar: bahkan JavaScript yang berjalan di halaman itu dan tampak tidak berbahaya pun bisa mengirim fragmen tersebut ke mana saja di internet
      Menaruhnya di fragmen memang membantu, tetapi tidak sempurna
      Ini bukan sekadar omongan idealistis; saya sudah beberapa kali benar-benar melihat token privat di fragmen bocor dengan cara seperti ini
    • Apakah ada fitur DNS yang tidak saya ketahui sehingga kuerinya lebih dari sekadar bagian domain?
      [https://example.com?token=](<https://example.com?token=<secret>>;) semestinya hanya menghasilkan kueri DNS untuk “example.com”
    • Saat memikirkan cara menyelesaikan masalah ini, saya langsung teringat login berbasis email atau reset akun
      Apakah bot yang mengikuti tautan di email menjalankan JavaScript? Apakah ada risiko aksi nyata diaktifkan oleh POST yang dipicu JavaScript?
    • Sebagai catatan, itu disebut fragment

  • Tautan yang bukan bagian dari loop redirect cepat pada dasarnya pasti akan disalin-tempel untuk dibagikan
    URL memang dari awal dibuat untuk itu, bersifat universal, dan memudahkan akses ke resource yang disediakan lewat protokol apa pun
    Kontrol akses untuk sesuatu yang masa hidupnya tidak singkat harus dilakukan di luar URL
    Jika tautan dibagikan lewat kanal yang bukan terenkripsi end-to-end, maka pihak pertama yang mengakses URL itu bukan penerimanya, melainkan layanan kanal tersebut
    Bisa jadi itu sah, seperti Bitwarden mengambil favicon demi pengalaman pengguna, atau bisa juga berniat buruk, seperti crawler Facebook Messenger yang ingin tahu lebih banyak tentang apa yang dibagikan orang di pesan privat
    Alat pemindai seperti ini tidak akan membuat pengalaman pengguna menjadi lebih baik
    Jika mereka secara eksplisit menyatakan bahwa hasil pemindaian akan dipublikasikan, sebagian pengguna akan berpikir dua kali sebelum memakai layanan itu, dan itu buruk bagi bisnis, baik untuk pengguna gratis maupun pemegang lisensi pro

  • Tautan “privat” yang bisa dipakai tanpa batas memang selalu terasa agak meragukan
    Pada akhirnya ini adalah keamanan yang bergantung pada kerahasiaan
    Saat membagikan sesuatu seperti Google Docs, setidaknya ada opsi yang secara eksplisit menyatakan “siapa pun yang memiliki URL dapat mengakses”
    Saat saya membutuhkan tipe seperti ini di sistem yang saya buat, saya biasanya memakai signed URL yang masa berlakunya hanya beberapa menit
    URL umumnya hanyalah detail implementasi dan tidak ditampilkan langsung kepada pengguna, tetapi kemungkinan tetap bisa terlihat di layar debug browser

    • Jika ruang kuncinya cukup besar, secara fungsional tidak ada perbedaan antara tautan privat dan tautan yang dilindungi nama pengguna·kata sandi atau kunci API
    • Sayangnya, berbagi Google Docs berbasis ID dokumen, jadi izin akses tidak bisa diaktifkan kembali dengan URL baru

  • Jika sesuatu seperti ini di internet tidak dilindungi selain oleh string acak di dalam URL, maka itu sebenarnya tidak privat
    Ceritanya sama seperti webcam terhubung internet yang bisa ditemukan lewat pencarian
    Bukankah ini sudah diketahui? Saya tidak mengerti kenapa bagian “siapa yang bertanggung jawab” sama sekali tidak membahas hal ini

    • Tautan seperti ini sangat berguna dalam konteks “keamanan yang cukup sesuai use case”
      Tidak semua hal membutuhkan tingkat keamanan tertinggi, dan dalam beberapa kasus cukup ada hambatan yang mencegah penyebaran luas
      Misalnya, jika saya menekan “buat tautan berbagi” di galeri foto lalu mengirim tautan foto itu kepada seseorang, saya tidak ingin dia harus memasukkan kata sandi
      Saat membuka tautan, fotonya seharusnya langsung terlihat, dan untuk tujuan itu, ini tidak masalah
      Salah satu contoh di sini tepat berada dalam situasi seperti itu, dan memang sesuai dengan use case tersebut
      Dari sisi kekhawatiran privasi juga, sekalipun ada proses login, pengguna akhir tetap bisa membagikan ulang tangkapan layar pada titik itu
      Artinya, keamanannya memang sesuai dengan use case
      Ini adalah situasi ketika pengguna kini memiliki tautan foto dan bisa membagikannya lagi, tetapi kita percaya mereka tidak akan sengaja melakukannya
      Masalah besarnya di sini bukan pada tautannya sendiri, melainkan alat analisis keamanan yang memindai semua tautan yang diterima pengguna lewat email lalu membuatnya bisa diakses oleh pengguna lain di komunitas itu juga
      Itu adalah pembagian ulang yang jauh lebih luas daripada yang saya maksudkan saat mengirim foto kepada seseorang

  • Solusi alternatif untuk masalah autentikasi berbasis email ini adalah memakai kode sekali pakai sementara, tanpa harus sampai membuat akun dengan kata sandi
    Dengan begitu, kalau URL dibagikan secara tidak sengaja pun tidak terlalu menjadi masalah

    1. Pengguna mengunjungi tautan “privat”, atau bisa juga tautan publik yang meminta alamat email dimasukkan lagi
    2. Situs mengirim ulang kode sekali pakai yang memiliki batas waktu kepada pengguna lewat email
    3. Pengguna memasukkan kode sementara itu untuk memverifikasi kepemilikan email
    4. Alur kemudian dilanjutkan dengan cookie HTTP atau data sesi, sehingga ada keyakinan yang masuk akal bahwa pemilik akun email memang terlibat

  • Sedikit di luar topik, tetapi tautannya mengarah ke Cloudflare Radar, dan layanan ini apparently tampak seperti menambang data 1.1.1.1
    Saya kira 1.1.1.1 tidak menggunakan data pengguna untuk tujuan apa pun

    • Cloudflare memang tidak menjual data itu atau memakainya untuk pemasaran, tetapi cara mereka mendapatkan alamat itu sejak awal adalah karena APNIC ingin meneliti traffic noise yang masuk ke 1.1.1.1

  • Akan bagus kalau ada orang yang lebih paham menjelaskan ini. Apa perbedaan antara dua hal berikut?

    1. domain.com/login user: John password: 5 char random password
    2. domain.com/12 char random url
      Jika keduanya memiliki pencegahan brute force atau rate limit yang sama, atau sama-sama tidak punya, mengapa 1 lebih aman daripada 2?
    • Dari sudut pandang teori informasi, tidak ada perbedaan
      Dalam praktiknya, ada perbedaan
      Rahasia berbasis kepemilikan dan rahasia berbasis pengetahuan itu berbeda
      URL adalah sesuatu yang dimiliki, jadi jika ditinggalkan di tempat yang bisa diakses, itu bisa diambil
      Kata sandi adalah sesuatu yang diketahui, dan jika dikelola dengan baik, tidak akan diambil. Kecuali serangan pipa timah
      Ada satu lagi, yaitu berbasis biometrik, seperti pemindaian retina atau sidik jari
    • Tulisan ini sendiri adalah alasannya
      (1) membutuhkan informasi dari jalur terpisah untuk autentikasi, dan itu adalah jenis informasi yang sudah biasa dijaga orang dengan aman
      Sementara itu, URL pada (2) diperlakukan sebagai URL
      URL sering tercatat di log, direkam, dibagikan, dan diteruskan ke mana-mana
      Misalnya, jika firewall perusahaan mencatat nama pengguna dan kata sandi yang dipakai untuk login ke suatu layanan, itu jelas buruk, tetapi mencatat URL yang diakses kemungkinan besar tampak masih bisa diterima
      Yang terakhir itu hanya contoh; karena jaminan end-to-end dari TLS, seharusnya keduanya tidak boleh bisa diakses
    • Ada dua hal
      1. Kata “kata sandi” adalah kata ajaib yang membuat orang cenderung tidak menempelkan sembarangan di mana pun
      2. Nama pengguna dan kata sandi biasanya tidak disalin-tempel secara bersamaan, dan juga tidak ada cara standar untuk menyimpannya berdampingan sebagai dua informasi yang terpisah
    • Dalam konteks tulisan ini, perbedaannya adalah perangkat lunak pemindaian keamanan yang digunakan perusahaan atau pengguna akan mengindeks sebagian dari tautan 12 karakter di dalam email, dan dalam beberapa kasus bahkan menaruhnya ke hasil pemindaian publik
      Selain itu, jika domain.com/12-char-password diminta tanpa HTTPS, maka meskipun ada redirect, permintaan pertama tetap dikirim tanpa enkripsi sehingga memungkinkan serangan man-in-the-middle
      Sementara itu, pada halaman login ada lebih banyak cara untuk memastikan bahwa pengiriman kata sandi hanya terjadi lewat HTTPS
    • Dulu saya pernah meneliti apakah aman menaruh token autentikasi di parameter kueri
      Salah satu masalah besarnya adalah banyak aplikasi logging mencatat seluruh URL ke suatu tempat, dan itu pada dasarnya berarti meninggalkan “kata sandi” di log

  • Semua media dan foto yang diunggah ke aplikasi airtable.com privat adalah tautan publik
    Jika tahu URL-nya, siapa pun bisa mengaksesnya tanpa autentikasi

    • Bagi pengembang web yang memuat gambar dari CDN atau API, ini memang dilema
      Tag gambar biasa tidak bisa menyetel header Authorization yang berisi token pada permintaan seperti saat memakai fetch() untuk request API
      Pilihan yang memungkinkan hanyalah menambahkan token ke URL atau memakai autentikasi cookie
      Autentikasi cookie hanya berfungsi jika CDN berada di domain yang sama, dan bahkan subdomain pun dalam banyak kasus bisa menimbulkan masalah
    • Pada aplikasi yang menggunakan CDN, ini cukup umum, bukan hanya di airtable
      Saya setuju bahwa ini berpotensi menjadi masalah

  • Tautan rapat Zoom sering kali menyertakan kata sandi sebagai parameter kueri
    Apakah tautan ini merupakan tautan “keamanan privat”? Apakah tautan tanpa kata sandi merupakan tautan “keamanan privat”?

    • Jika kata sandi diacak untuk setiap rapat, tautan URL juga tidak terlalu buruk
      Karena saat URL itu muncul di tempat lain, rapat tersebut kemungkinan sudah selesai dan hilang
      Namun dalam kenyataannya, tidak ada yang terlalu peduli, dan orang ingin “klik untuk bergabung” tanpa harus memasukkan ini-itu
      Metode sebelumnya, yaitu “hanya memakai ID rapat”, terlalu mudah ditebak