Pengalaman Meretas Aplikasi Kencan (dan Cara Keliru Memperlakukan Peneliti Keamanan)

• Ditemukan kerentanan keamanan serius pada aplikasi kencan bernama Cerca
• OTP terekspos di respons sehingga siapa pun dapat mengakses akun hanya dengan mengetahui nomor telepon
• Dari sejumlah endpoint API yang terbuka tanpa autentikasi, data pribadi dapat bocor dengan mudah
• Preferensi seksual, isi pesan, dokumen identitas, dan informasi sensitif lainnya milik pengguna terekspos dalam jumlah besar
• Pihak layanan, meski telah menerima laporan yang bertanggung jawab dari peneliti, gagal memberikan respons dan pemberitahuan yang memadai

---

Pentingnya startup menanggapi keamanan dengan serius

• Belakangan ini, dalam proses startup yang terburu-buru meluncurkan produk ke pasar, keamanan sering terabaikan
• Meski merupakan aplikasi kencan yang menghimpun banyak data pribadi, pengguna terekspos pada risiko akibat kurangnya kematangan dalam pengembangan dan operasional

Proses penemuan dan pelaporan kerentanan

• Pada 23 Februari 2025, peneliti menjelaskan kepada pihak Cerca melalui email mengenai kerentanan keamanan dan masalah terkait
• Pada 24 Februari, melalui rapat video, dibahas detail kerentanan, langkah penanganan, dan prosedur lanjutan
• Tim Cerca menyampaikan bahwa mereka memahami tingkat keparahannya, berjanji bertindak cepat, dan akan memberi tahu pengguna
• Setelah itu beberapa kali dikirim pertanyaan tentang perkembangan, tetapi hingga 21 April tidak ada jawaban maupun pengumuman
• Dari verifikasi independen, kerentanan tersebut telah selesai ditambal

Kerentanan OTP dan proses peretasan yang sederhana

• Dalam proses login aplikasi, one-time password (OTP) terekspos apa adanya di respons jaringan
• Penyerang dapat dengan mudah dan cepat mengakses akun siapa pun hanya dengan mengetahui nomor telepon

Akses ke endpoint API dan kebocoran informasi

• Terkonfirmasi bahwa semua jalur API dapat diakses hanya dengan mengisi header versi aplikasi
• Melalui endpoint /docs, seluruh dokumentasi OpenAPI terekspos
• Dengan memanfaatkan alat seperti Burp Suite, API dapat dikendalikan melalui injeksi otomatis header dan token aplikasi
• Beberapa endpoint hanya mengubah logika bisnis, tetapi endpoint inti mengembalikan data pribadi yang sangat sensitif
• Melalui user/{user_id} dan lainnya, data pribadi, nomor telepon, bahkan pembajakan akun pun dimungkinkan

Paparan massal data pribadi dan informasi dokumen identitas

• Melalui endpoint data pribadi, PII seperti jenis kelamin, kota, tanggal lahir, email kampus, dan informasi identitas terekspos dalam jumlah besar
• Khususnya pada field terkait identitas seperti national_id_verified, file sensitif seperti gambar paspor dan kartu identitas penduduk dapat diakses
• Dengan skrip serangan, terkonfirmasi 6.117 pengguna dapat diidentifikasi, dan 207 di antaranya telah memasukkan informasi dokumen identitas
• Sebagian akun juga tercantum sebagai afiliasi dengan Universitas Yale
• Berdasarkan Instagram resmi Cerca, ini setara dengan 10.000 pengguna pada minggu pertama

Risiko nyata bagi korban dan tingkat keparahan masalah

• Karena preferensi seksual, isi percakapan, dokumen identitas, dan data yang sangat sensitif lainnya bocor, terdapat risiko serius seperti stalking, pencurian identitas, dan pemerasan
• Cerca menyatakan bahwa mereka mematuhi standar industri seperti enkripsi, tetapi hal itu tidak sesuai dengan kondisi operasional yang sebenarnya
• Karena pengguna tidak dapat memverifikasinya sendiri, pengelolaan keamanan yang proaktif dan bertanggung jawab dari penyedia aplikasi adalah hal yang wajib
• Secara realistis, ada kemungkinan bahwa banyak pihak tak dikenal telah lebih dulu mencuri data pribadi dalam skala besar

Kesimpulan dan perlunya budaya keamanan yang bertanggung jawab

• Mengoperasikan aplikasi yang begitu lemah keamanannya hingga siapa pun bisa meretasnya dengan mudah merupakan masalah sosial yang serius
• Jika perlindungan data pengguna tidak dijadikan prioritas utama, kerugian dapat terjadi secara real time
• Kasus Cerca, yang kurang aktif menanggapi laporan peneliti keamanan dan kurang memadai dalam memberi tahu pengguna, menjadi pelajaran penting
• Untuk membangun lingkungan internet yang lebih aman, membangun sistem keamanan harus menjadi prioritas utama bagi semua pengembang

[GN⁺]

Komentar Hacker News

• Bahkan dengan mempertimbangkan bahwa aplikasi ini tampaknya hasil buatan mahasiswa yang masih sangat pemula, saya tetap berpikir mereka harus berusaha semaksimal mungkin dalam keamanan dan komunikasi. Namun melihat bahkan perusahaan dewasa yang didanai VC besar juga menghadapi masalah seperti ini dan bereaksi dengan cara serupa, saya rasa tidak perlu terlalu keras kepada para mahasiswa ini. Saya membagikan tautan artikelnya

  • Saya sangat tidak setuju. "Tidak tahu" bukan alasan pembenar. Justru nekat jalan terus dalam keadaan tidak tahu adalah masalah yang lebih besar. Ini seperti pengemudi tidak berpengalaman menyebabkan kecelakaan tanpa SIM dan melukai orang
  • Saya juga menekan tautan sumber saat mencari info soal Cerca, dan artikelnya bertanggal April 2025, isinya memuji aplikasi yang dibuat sekitar dua bulan sebelumnya. Rasanya seperti sampah hasil halusinasi LLM. OP bilang mereka menghubungi tim Cerca pada Februari, jadi entah ini celah yang ditemukan segera setelah peluncuran atau ada situasi aneh. Tetap saja, konteksnya adalah "kerentanan berusia dua bulan" + "layanan buatan mahasiswa yang baru dua bulan"
  • Jika aplikasi dirilis atas nama "Cerca Applications, LLC", saya tidak tahu bagaimana orang bisa paham bahwa ini aplikasi buatan mahasiswa yang seharusnya diberi kelonggaran
  • Sepertinya para mahasiswa ini sebaiknya belajar hal lain
  • Ini terdengar seperti membela mereka. Tidak seharusnya ada anggapan bahwa kalau aplikasi dibuat mahasiswa maka otomatis harus dimaklumi. The Facebook juga awalnya dimulai oleh mahasiswa. Riwayat panjang penyalahgunaan privasi dan pengabaian keamanan data oleh Meta sudah sangat lama. Jadi perilaku seperti ini tidak bisa dimaafkan, dan menurut saya ini hanya bisa diatasi kalau diatur dengan benar dan didenda, terlepas dari usia atau pengalaman pendirinya
  • Kalau menangani data sensitif seperti paspor dan orientasi seksual, minimal harus merespons ketika diberi tahu bahwa data sedang bocor. Ini bencana total, dan tidak adanya keamanan di sini benar-benar berada pada tingkat yang sama sekali tidak bisa diterima
  • Kalau tidak paham apa-apa soal keamanan aplikasi, sebaiknya jangan bikin aplikasi. Saya jadi emosional, tapi melihat teman-teman memakai aplikasi kencan dan informasi mereka bisa terekspos itu mengerikan. Orang yang membuatnya harus merasa malu. Mereka juga harus malu karena tidak menjawab kontak dari peneliti keamanan. Kalau saya diabaikan seperti itu, saya akan menulis pengungkapan yang jauh lebih blak-blakan. Tolong berhenti membuat aplikasi

• Sebagai developer yang bekerja di perusahaan kecil, saya kadang khawatir soal tanggung jawab pribadi saya. Banyak perusahaan beroperasi di area yang tidak wajib tunduk pada regulasi seperti PCI atau HIPAA. Di organisasi kecil, keamanan sering dianggap tugas engineering, bukan tanggung jawab seluruh organisasi. Tim produk hanya fokus pada fitur, PM pada jadwal, QA pada bug, dan jarang ada yang bersuara soal keamanan. Suasananya seperti engineer cukup mengerjakan yang ditugaskan. Kalau engineer sempat memikirkan keamanan itu bagus, tapi kalau tidak, malah bisa kena omelan PM dan lainnya. Dan selalu ada ucapan seperti: "Berapa lama ini akan memakan waktu?", "Seberapa besar kemungkinan itu benar-benar terjadi?", "Kita rilis MVP dulu secepatnya, nanti baru dibenahi". Jadi sebagai karyawan, saya akhirnya hanya mengerjakan apa yang diminta perusahaan. Tapi ketika perusahaan digugat karena peretasan atau kebocoran, saya sering khawatir apakah saya sebagai engineer yang "seharusnya lebih tahu" akan ikut dimintai pertanggungjawaban

  • Secara praktik, Anda bukan engineer yang menandatangani dokumen sertifikasi dan menjamin keselamatan, jadi meskipun terbukti tidak aman, Anda mungkin tidak akan dimintai tanggung jawab
  • Kalau perusahaannya berbentuk LLC atau Corp, Anda akan terlindungi oleh corporate veil. Selama tidak tercatat melakukan tindak kriminal, Anda tidak akan bertanggung jawab. Meski begitu, absennya standar keamanan adalah masalah besar di semua skala perusahaan. Merilis fitur baru selalu dianggap lebih penting daripada keamanan
  • Sebagai engineer di organisasi kecil, saya rasa tanggung jawab kita adalah mengedukasi tim tentang risiko seperti ini dan menegaskan perlunya meluangkan waktu pengembangan untuk keamanan. Itu tidak mudah, tapi kalau diabaikan, perusahaan sendiri bisa berada dalam bahaya
  • Kalau saya, saya akan cukup memahami hukum untuk melindungi diri sendiri, akan menolak permintaan yang ilegal secara tertulis, dan juga memastikan persetujuan untuk mengabaikannya diberikan secara tertulis. Tapi di startup kecil itu pun bisa sulit. Kalau rasanya tidak legal, saya akan langsung resign
  • Saya memang tidak suka pembelaan "saya hanya menjalankan perintah", tapi dalam kasus seperti ini sebaiknya memang selalu ada jejak tertulis: kirim email bahwa ada masalah keamanan, lalu simpan bukti atasan menjawab semacam "tidak usah terlalu dipikirkan". Sepanjang yang saya tahu, saya belum pernah melihat karyawan level biasa dimintai tanggung jawab hukum atas kebocoran data. Biasanya tidak ada yang benar-benar bertanggung jawab dan perusahaan hanya membayar denda simbolis lalu selesai
  • Kalau Anda bukan eksekutif perusahaan, saya rasa tidak akan ada tanggung jawab pribadi
  • Dalam pengalaman saya, itu tidak terjadi

• Untuk mengurangi tanggung jawab hukum peneliti, saya pikir cukup membuat satu akun tambahan, atau membuat profil dengan persetujuan teman untuk mendapatkan hak akses. Tidak perlu benar-benar mengikis data; misalnya kalau id saya 12345 dan id teman saya 12357, itu sudah cukup untuk membuktikan bahwa profil akun lain di id tengah bisa diakses. Seperti yang sudah banyak orang katakan, tidak perlu sampai mengakses data pribadi ribuan orang; cukup membuktikan dan mengungkapkan kerentanannya

  • Ini adalah cara standar dan jelas yang diketahui semua peneliti keamanan informasi. Mungkin ada keinginan untuk membuktikannya dengan mengikis informasi sensitif, tapi itu tidak perlu dan justru munafik

• Tulisan ini sendiri terasa cukup membingungkan. API yang menerima OTP (kata sandi sekali pakai) terdengar sangat sederhana sampai-sampai OTP terekspos langsung di respons server, sehingga siapa pun yang tahu nomor telepon bisa masuk ke akun. Disebutkan API-nya berbentuk otp/nomor-telepon dan OTP ada di responsnya, jadi tampaknya kalau nomor teleponnya benar, kodenya juga langsung didapat. Lalu mereka mengungkapkan bahwa dengan skrip untuk mengurutkan ID pengguna dan berhenti setelah 1.000 ID kosong berturut-turut, mereka mengonfirmasi total 6.117 pengguna, 207 data identitas, dan 19 mahasiswa Yale. Tetapi mengakses data pribadi orang lain tanpa persetujuan sampai sejauh ini mirip dengan kasus lama weev yang meretas AT&T lalu masuk penjara. Walaupun skalanya kecil, penelitian seperti ini berisiko secara hukum, dan mengkhawatirkan kalau penulis tampaknya tidak memahami lingkungan hukum yang tidak melindungi peneliti keamanan

  • Disebut bahwa API otp/nomor langsung mengembalikan OTP final. Artinya, kalau nomor teleponnya benar, OTP langsung diberikan begitu saja
  • Kalau membaca dakwaan awal kasus Auernheimer, ada cukup bukti niat kriminal di sana, yang tidak sama dengan kasus ini. Mereka juga dituduh benar-benar memublikasikan informasi pribadi ke pihak luar, jadi kasus kali ini tidak sampai setara dengan itu

• Saya juga punya pengalaman serupa. Saya pernah mencoba melaporkan bug di aplikasi kencan lain, tapi tidak bisa menghubungi siapa pun, jadi saya ubah profil founder menjadi "tolong hubungi saya", lalu mereka memulihkannya dari backup. Beberapa tahun kemudian saya melihat iklan aplikasi itu di Instagram dan mencoba lagi, ternyata kerentanannya masih persis sama. Siapa pun yang tahu endpoint API bisa mendapat hak admin dan akses ke semua pesan/match. Saya sedang berpikir apakah perlu menghubungi mereka lagi

  • Ada saran bahwa sebaiknya hubungi saja, tunjukkan bahwa Anda developer yang bertanggung jawab, lalu cukup ungkapkan isu tersebut dan lanjutkan

• Menurut saya, ketika aplikasi mengumpulkan data sensitif seperti paspor atau alamat, itu harus benar-benar membuat orang berpikir dua kali. Ini bukan sesuatu yang bisa disepelekan dengan alasan "ini cuma aplikasi buatan mahasiswa"

  • Pemerintah Inggris sedang berusaha mewajibkan identitas untuk akses ke situs porno, dan saya menunggu seperti apa hasilnya nanti
  • Kalau mereka meminta informasi identitas seperti paspor, setelah data itu dimasukkan seharusnya tidak pernah perlu diekspos keluar lagi. Kalau ada API untuk menampilkan data identitas di UI, cukup kembalikan beberapa digit terakhir, bukan seluruh nomornya. Untuk aplikasi kencan, cukup mengembalikan status verifikasi ID sebagai boolean atau enum (belum terverifikasi/paspor/SIM), itu sudah memadai. Sistem seperti aplikasi maskapai yang memang harus memilih berdasarkan ID tertentu adalah pengecualian, tapi bahkan aplikasi United misalnya hanya menampilkan beberapa digit terakhir, jadi saya berharap API internal juga dibatasi seperti itu
  • Ada yang membagikan tautan dan menyarankan melihat GDPR
  • Saya merasa kita butuh layanan verifikasi identitas yang aman dan privat yang dijalankan pemerintah. Atau kalau tidak, perusahaan seperti Apple atau Google yang berperan sebagai "nyaris seperti pemerintah" yang menanganinya
  • Biasanya lebih umum memakai layanan verifikasi identitas pihak ketiga, tapi saya jadi bertanya-tanya apakah layanan seperti itu benar-benar sampai mengirimkan gambar identitas ke aplikasi

• Mengembalikan OTP apa adanya di respons API itu terlalu absurd. Saya tidak mengerti alasannya

  • Itu dibuat supaya UI bisa langsung membandingkannya dengan input pengguna. Kalau tidak memikirkan keamanan, itu terdengar masuk akal. Aplikasi kencan punya cakupan data pribadi yang sangat besar, jadi kesalahan seperti ini mengerikan
  • Dengan cara ini biaya database bisa langsung ditekan
  • Setelah menghasilkan OTP, lalu langsung mengembalikan respons DB atau cache, model seperti ini mudah sekali lolos begitu saja dalam POC atau MVP
  • Tampaknya OTP terekspos apa adanya dalam "respons terhadap permintaan pengiriman kata sandi sekali pakai". Mungkin ini karena framework menserialisasi seluruh objek DB dan mengembalikannya lewat HTTP
  • Kelihatannya bagus karena menghemat satu permintaan HTTP dan UX jadi lebih cepat. Pinterest juga pernah mengekspos semua informasi termasuk rahasia 2FA di API lama mereka. Saya pernah melaporkannya dan mendapat hadiah, tapi kesalahan seperti ini memang kadang terjadi bahkan di big tech
  • Saya juga tidak paham. Saya hanya bisa menganggap ini kesalahan karena ingin mempermudah pembuatan form

• Ada yang membagikan tautan ke artikel terkait lain dari Yale Daily News

• Saya berharap ada hukum yang memperlakukan data pribadi seberbahayanya limbah nuklir. Kalau bocor, bukan hanya perusahaannya yang bangkrut, tapi para penanggung jawabnya juga harus menghadapi risiko hukum. Sekarang terlalu mudah mengumpulkan data pengguna, dan kalau bocor, cukup minta maaf lalu selesai

  • Memperlakukan PII seperti bahan nuklir terdengar berlebihan. Hal seperti alamat email yang hanya dipakai untuk autentikasi/kontak bukan masalah besar
  • Mungkin baru akan benar-benar jadi perhatian kalau sampai ada penjara gaya white-collar

• Baru sekarang saya tahu soal alat bernama Charle's Proxy di iOS. Dulu saya melakukan pentest dengan mencari string langsung di biner aplikasi. Untuk analisis aplikasi khusus iOS, ini tampaknya sangat membantu

  • Alat yang cukup bagus, saya merekomendasikannya (asal tidak ada SSL pinning)