Pengalaman Meretas Aplikasi Kencan, dan Cara yang Keliru dalam Memperlakukan Peneliti Keamanan

• Cerca Dating App berada dalam kondisi berbahaya karena login berbasis nomor telepon dipadukan dengan API yang terekspos, sehingga kode autentikasi disertakan dalam respons OTP dan dapat berujung pada pengambilan data pribadi
• Pada api.cercadating.com, jika header versi aplikasi disertakan, endpoint terungkap melalui openapi.json di /docs, dan sebagian permintaan bahkan dapat memanipulasi logika bisnis seperti memaksa pencocokan pengguna
• user/{user_id} mengembalikan PII seperti nama, lokasi, tanggal lahir, sekolah, nomor telepon, email, dan status profil hanya dengan ID pengguna yang valid, sehingga jika digabungkan dengan kerentanan OTP dapat berujung pada pengambilalihan akun
• Setelah akses akun diperoleh, untuk pengguna yang telah menyerahkan data, informasi paspor atau kartu identitas, URL selfie, hingga pesan pribadi dapat diakses; skrip verifikasi menemukan 6.117 pengguna, 207 pengisi informasi ID, dan 19 pengguna yang ditandai sebagai mahasiswa Yale
• Kerentanan dilaporkan ke Cerca pada 23 Februari 2025 dan panggilan dilakukan pada 24 Februari, tetapi hingga waktu publikasi pada 21 April tidak ada respons lanjutan maupun pemberitahuan kepada pengguna; hanya status patch yang dikonfirmasi secara independen

---

Respons yang Terputus Setelah Pelaporan

• Cerca Dating App memiliki kerentanan keamanan aplikasi kencan yang dapat mengekspos pesan pribadi, informasi paspor, preferensi seksual, dan data pribadi lainnya
• Setelah menemukan kerentanan, laporan dikirim melalui email kepada tim Cerca pada 23 Februari 2025, dan keesokan harinya dalam panggilan video dibahas kerentanan, mitigasi, serta tindak lanjut
• Tim Cerca mengakui tingkat keparahan masalah, berterima kasih atas pengungkapan yang bertanggung jawab, serta berjanji memperbaiki kerentanan dan memberi tahu pengguna yang terdampak
• Setelah itu, permintaan pembaruan tentang perbaikan dan rencana pemberitahuan pengguna dikirim pada 5 Maret dan 13 Maret, tetapi hingga publikasi pada 21 April 2025 tidak ada jawaban
• Sebelum publikasi, telah dikonfirmasi secara independen bahwa kerentanan sudah dipatch, dan publikasi dilakukan berdasarkan hal tersebut

Akses Akun yang Berawal dari Login OTP

• Aplikasi hanya menggunakan login berbasis OTP yang mengirim kode ke nomor telepon
• Untuk memeriksa permintaan jaringan, Charles Proxy digunakan pada aplikasi iPhone untuk mencegat permintaan aplikasi
• Di dalam respons yang memicu OTP, kata sandi sekali pakai disertakan secara langsung
• Dengan struktur ini, siapa pun yang mengetahui nomor telepon pengguna dapat mengakses akun tersebut
• Diperlukan jalur terpisah untuk mengetahui nomor telepon pemilik akun, sehingga eksplorasi endpoint API dilakukan

Endpoint yang Terungkap lewat Dokumentasi OpenAPI

• Jalur untuk api.cercadating.com dienumerasi menggunakan directory fuzzer
• Tanpa header terkait aplikasi, bagian mana pun dari situs tidak dapat diakses
• Saat permintaan dikirim dengan header tersebut melalui Gobuster, endpoint /docs ditemukan, dan openapi.json disediakan di sana
• Fitur match-and-replace Burp Suite dikonfigurasi agar selalu menambahkan header versi aplikasi dan bearer token yang diekstrak dari Charles Proxy
• Sebagian endpoint yang tidak terlindungi memengaruhi logika bisnis, bahkan memungkinkan permintaan untuk memaksa dua orang saling match

Paparan Profil Pengguna dan Data Pribadi

• Endpoint user/{user_id} mengembalikan berbagai data pribadi jika menerima ID pengguna yang valid
• Respons mencakup informasi berikut
  • Nama, gender, gender yang diminati, kota, lintang dan bujur
  • Email sekolah dan status verifikasi, industri, pekerjaan, tanggal lahir, tinggi badan
  • ID sekolah dan nama sekolah, status kelengkapan profil
  • Status verifikasi ID kewarganegaraan, status verifikasi mobile dan email
  • Status premium, status akun aktif/ditangguhkan/onboarding
  • Nomor telepon, email, ID pengguna, sisa jumlah pencarian
  • Gambar profil, preferensi match, prompt pengguna, informasi kontak bersama, waktu dibuat dan diperbarui, usia, dan lainnya
• Dengan skrip Python, ID pengguna yang valid dapat ditemukan dan data pengguna dapat dienumerasi secara massal
• Nomor telepon yang dikembalikan dapat digabungkan dengan kerentanan OTP untuk digunakan dalam akses penuh ke akun
• Data pribadi pengguna terekspos bahkan tanpa login OTP

Akses Berlanjut hingga Kartu Identitas dan Pesan Pribadi

• Field national_id_verified menunjukkan bahwa informasi paspor atau kartu identitas disimpan di sistem
• Respons terkait kartu identitas mencakup informasi berikut
  • verification_type: PASSPORT
  • document_number
  • front_side_url
  • back_side_url
  • selfie_url
  • Status, ID, ID pengguna
• Informasi ini hanya diberikan kepada pengguna yang sudah login, tetapi karena kerentanan OTP, kondisi saat itu memungkinkan login sebagai pengguna mana pun
• Untuk pengguna yang sudah menyerahkan data, strukturnya memungkinkan melihat informasi ID siapa pun, meski penulis menyatakan tidak benar-benar melakukannya
• Pesan pribadi dengan calon pasangan kencan juga dapat dilihat, dan jika sudah diserahkan, informasi paspor pun dapat diakses

Skala Paparan yang Dikonfirmasi

• Sebuah skrip cepat digunakan untuk menghitung jumlah pengguna yang informasinya dapat diperoleh, jumlah pengguna yang terdaftar sebagai mahasiswa Yale, dan jumlah pengguna yang telah memasukkan informasi ID
• Skrip tersebut menghitung ID pengguna yang valid, lalu berhenti jika tidak menemukan ID valid selama 1.000 kali berturut-turut
• Metode ini tidak menutup kemungkinan adanya lebih banyak pengguna
• Cerca menyatakan jumlah pengguna pada minggu pertama mencapai 10 ribu
• Angka yang dikonfirmasi adalah sebagai berikut
  • 6.117 pengguna
  • 207 pengguna yang memasukkan informasi ID
  • 19 pengguna yang menandai diri sebagai mahasiswa Yale

Janji Perlindungan Data Pribadi dan Risiko Nyata

• Kebijakan privasi Cerca menyatakan bahwa mereka “melindungi data dengan enkripsi dan langkah-langkah standar industri lainnya”
• Dibandingkan dengan kondisi kerentanan yang sebenarnya, pernyataan ini berpotensi menyesatkan
• Data yang dapat terekspos mencakup preferensi seksual, pesan pribadi, dan berbagai data pribadi
• Jika pengguna berniat jahat mengakses informasi tersebut, akibatnya dapat mengarah pada pencurian identitas, stalking, atau pemerasan
• Karena aplikasi kencan menangani data sensitif, keamanan data pengguna harus diprioritaskan dibanding kecepatan peluncuran aplikasi

[GN⁺]

Komentar Hacker News

• Aplikasi ini tampaknya merupakan proyek tahap sangat awal yang dibuat oleh mahasiswa. Memang benar mereka harus berusaha semaksimal mungkin untuk menjaga praktik keamanan dan komunikasi yang layak, tetapi mengingat bahkan “perusahaan dewasa” yang didanai VC besar pun sering merespons kacau pada masalah serupa, rasanya saya tidak ingin menghakimi mereka terlalu keras
  https://georgetownvoice.com/2025/04/06/georgetown-students-c...

  • Sangat tidak setuju. Argumen “jangan terlalu keras menilai karena mereka tidak tahu apa yang mereka lakukan” terdengar aneh. Kalau mereka memang tidak tahu apa yang mereka lakukan tapi tetap melanjutkan sampai rilis, itu bukan faktor yang meringankan, malah lebih mendekati faktor yang memberatkan
    Mirip seperti pengemudi yang membunuh seseorang dalam kecelakaan lalu ternyata bahkan tidak punya SIM
  • Saya juga melihat tautan yang sama saat mencari info tentang “Cerca”, tetapi karena itu artikel April 2025 yang memuji aplikasi yang dibuat dua bulan sebelumnya, itu terlihat seperti artikel sampah hasil halusinasi LLM
    Tulisan aslinya mengatakan mereka menghubungi tim Cerca pada Februari, jadi entah ini celah yang ditemukan saat peluncuran, atau ada struktur yang aneh. Bagaimanapun, ini adalah “kerentanan berumur dua bulan” sekaligus “aplikasi/layanan buatan mahasiswa yang berumur dua bulan”
  • Kalau aplikasi ini dirilis atas nama Cerca Applications, LLC, bagaimana orang bisa tahu bahwa ini cuma segelintir script kiddie yang seharusnya diberi kelonggaran
  • Sepertinya mereka lebih baik belajar jurusan lain
  • Ada benarnya, tapi ini tetap keterlaluan. Tidak mengembalikan OTP rahasia di body respons itu nyaris pengetahuan umum, baik bagi developer berpengalaman maupun anak SMA
    Lagi pula ini bukan sekadar proyek iseng, melainkan produk komersial. Pembelian dalam aplikasi yang tercantum adalah Cerca App $9.99, Cerca App 3 month $9.99, 10 Swipes $2.99, 3 Swipes $0.99, 5 swipes $1.99, 3 Searches $1.99, 10 Searches $3.99, 5 Searches $2.99

• Sebagai engineer di perusahaan kecil, saya kadang khawatir soal tanggung jawab pribadi saya. Ada terlalu banyak perusahaan yang beroperasi di industri tak teregulasi yang tidak tunduk pada PCI atau HIPAA, dan di organisasi kecil keamanan sering terdorong bukan sebagai kewajiban organisasi, melainkan cuma jadi perhatian engineering
  Tim produk fokus pada fitur, PM fokus pada jadwal, QA fokus menemukan bug, dan jarang ada orang yang secara masuk akal bersuara soal keamanan. Engineer tidak diharapkan lebih dari sekadar menyelesaikan tugas yang masuk ke board. Kalau bisa dibuat aman tanpa memengaruhi jadwal, bagus, tapi kalau tidak, kita akan ditekan oleh PM dan lain-lain
  Kita akan mendengar hal seperti “memangnya butuh berapa lama?”, “seberapa besar sih risiko itu benar-benar terjadi?”, “nanti saja urus keamanannya, yang penting MVP dulu keluar ke pelanggan”. Sebagai karyawan, saya hanya mengerjakan apa yang diminta pemberi kerja, tetapi kalau perusahaan digugat karena peretasan atau kebocoran data, apakah saya bisa ikut dimintai tanggung jawab pribadi hanya karena saya satu-satunya orang yang “seharusnya tahu”

  • Secara ketat, Anda bukan benar-benar engineer rekayasa. Anda tidak akan menandatangani gambar desain yang mengesahkan keselamatan, dan meskipun desain itu terbukti tidak aman, Anda juga tidak akan memikul tanggung jawab itu
  • Jika itu LLC atau korporasi, kemungkinan besar Anda dilindungi oleh tabir badan hukum, kecuali Anda meninggalkan jejak dokumen yang menunjukkan Anda melakukan tindak kriminal
    Meski begitu, kurangnya standar keamanan di seluruh organisasi, sekecil apa pun skalanya, tetap menyedihkan. Rasanya peluncuran fitur baru selalu lebih diprioritaskan daripada memastikan praktik keamanan yang baik
  • Secara pribadi saya ingin tahu hukum secukupnya untuk melindungi diri sendiri, menyatakan keberatan secara tertulis terhadap hal-hal ilegal, dan kalau disuruh mengabaikannya, saya ingin ada persetujuan tertulis juga
    Namun saya paham, kalau di startup developernya cuma satu atau dua orang, bahkan ini pun sulit. Kalau saya merasa mereka tidak berusaha melakukan hal yang legal, saya rasa saya akan pergi
  • Kalau Anda engineer di organisasi kecil, menurut saya Anda punya tanggung jawab untuk mendidik anggota tim lainnya tentang risiko keamanan seperti ini, dan mendorong supaya ada waktu engineering yang dialokasikan untuk memitigasinya
    Ini memang tidak mudah, tetapi ini hal penting yang bisa menenggelamkan bisnis kalau tidak ditangani serius
  • Saya memang tidak suka logika pembelaan “saya cuma menjalankan perintah”, tetapi untuk kasus seperti ini Anda wajib meninggalkan catatan tertulis
    Anda perlu jejak email bahwa Anda sudah mengangkat kekhawatiran soal kurangnya keamanan, dan ada balasan atasan yang menyuruh untuk tidak memedulikannya. Saya tidak tahu yurisdiksi Anda, tetapi saya belum pernah mendengar kasus karyawan biasa secara pribadi dimintai tanggung jawab hukum atas kebocoran data. Biasanya dalam kebocoran data, tidak ada yang benar-benar menanggung konsekuensi, dan perusahaan hanya membayar denda formalitas lalu lanjut seperti biasa

• Sebagai peneliti, untuk mengurangi eksposur hukum, sepertinya cukup dengan membuat akun kedua atau meminta teman membuat profil dan mendapat persetujuan akses
  Untuk membuktikan kerentanan enumerasi, tidak perlu benar-benar mengeruk data nyata. Jika ID saya 12345 dan teman saya mendaftar lalu mendapat 12357, itu sudah cukup menjadi bukti bahwa Anda bisa menemukan ID pengguna mana pun dan mengakses profilnya
  Seperti yang sudah dikatakan orang lain, untuk memverifikasi dan mengungkap kerentanan, tidak perlu mengakses begitu banyak informasi identitas pribadi milik pengguna lain

  • Ini adalah cara yang standar dan jelas yang diabaikan oleh sebagian besar peneliti keamanan
    Mengatakan ingin informasi identitas pribadi dilindungi sambil mengeruknya untuk pembuktian adalah hal yang tidak perlu dan munafik

• Tulisannya cukup membingungkan. Pada login berbasis OTP, bagian yang mengatakan respons permintaan kata sandi sekali pakai berisi OTP itu sendiri kurang dijelaskan, tetapi kemungkinan maksudnya adalah API seperti api.cercadating.com/otp/, sehingga jika menebak nomor telepon, Anda bisa menerima kode OTP tanpa memiliki nomor tersebut.
  Selain itu, disebutkan bahwa dengan skrip yang berhenti jika tidak ada pengguna valid dalam 1.000 ID berurutan, ia menemukan 6.117 orang, 207 orang yang memasukkan informasi identitas, dan 19 orang yang mengaku sebagai mahasiswa Yale; saya tidak yakin penulis menyadari seberapa berbahayanya ini. Pada dasarnya ini mirip dengan cara weev membobol AT&T, dan dia masuk penjara[0].
  Memang perusahaan itu lebih besar dan kebocorannya juga lebih besar, tetapi saya rasa saya tidak akan membanggakan secara terbuka bahwa saya mengakses data ribuan orang tanpa izin dengan memanfaatkan celah keamanan. Bukan mau menilai moralitasnya, dan saya memang berpikir peneliti keamanan harus punya ruang untuk memberi peringatan, tetapi hukum sangat tidak berpihak pada peneliti keamanan.
  [0] https://en.wikipedia.org/wiki/Goatse_Security#AT&T/iPad_emai...

  • Dia memang menyebut menebak nomor telepon, dan tertulis bahwa panggilan API yang mengirim OTP secara harfiah mengembalikan OTP
  • Jika membaca surat gugatan asli kasus Auernheimer, jaksa punya bukti kesengajaan yang luas, yang kemungkinan besar tidak ada di sini.
    Para terdakwa dalam kasus itu juga didakwa memublikasikan informasi pengenal pribadi dasar, dan di sini tampaknya hal seperti itu tidak terjadi.

• Saya pernah mengalami hal serupa di aplikasi kencan lain, dan pihak sana pada akhirnya tidak pernah merespons. Untuk menarik perhatian pendirinya, saya mengubah bio miliknya menjadi kalimat “tolong hubungi saya”, lalu mereka memulihkan backup.
  Beberapa tahun kemudian saya melihat iklan Instagram dan memeriksa apakah masalahnya masih ada, dan ternyata masih ada. Strukturnya sedemikian rupa sehingga siapa pun bisa mendapatkan hak admin penuh dan mengakses semua pesan, match, dan lain-lain, asalkan tahu endpoint API yang mudah ditemukan lewat aplikasi-proxy-server.
  Jadi saya sempat berpikir apakah perlu kembali dan mencoba sekali lagi.

  • Sebagai pengembang yang bertanggung jawab, bukankah cukup menghubungi kontak yang tersedia untuk pengungkapan kerentanan lalu berhenti di situ?

• Orang harus dipaksa berpikir dua kali sebelum menerima informasi sensitif seperti paspor atau alamat. Ini tidak bisa sekadar dianggap sebagai aplikasi buatan anak-anak lalu dibiarkan begitu saja.

  • Sama sekali tidak ada alasan untuk mengekspos secara publik informasi sensitif seperti paspor atau alamat. Bahkan jika data perlu diambil lewat API untuk ditampilkan di UI, tidak perlu menyertakan seluruh nomor paspor/kartu identitas; setidaknya cukup kirim beberapa digit terakhir yang sudah disamarkan.
    Untuk situs kencan, API seharusnya cukup mengembalikan boolean verified/not-verified atau nilai enum seperti not-verified, passport, drivers-license terkait status identitas. Tidak ada kebutuhan nyata untuk menampilkan detail tersebut di klien/UI.
    Pengecualian mungkin ada pada aplikasi maskapai yang perlu memilih dokumen identitas untuk keperluan keluar-masuk negara, tetapi bahkan aplikasi seperti United pun cukup menampilkan beberapa digit terakhir nomor paspor. Saya berharap API internal juga hanya mengirim sebatas itu.
  • Pemerintah Inggris sangat ngotot ingin mewajibkan verifikasi identitas untuk akses ke situs porno, dan saya menunggu hari ketika itu meledak di wajah mereka sendiri.
  • Harus ada semacam layanan verifikasi identitas yang aman dan privat yang dioperasikan pemerintah.
    Atau paling tidak bisa ditangani oleh pihak yang “mirip pemerintah” seperti Apple atau Google.
  • Lihat saja GDPR.
    https://en.wikipedia.org/wiki/General_Data_Protection_Regula...
  • Memangnya mereka tidak memakai layanan verifikasi identitas pihak ketiga? Biasanya aplikasi menangani ini seperti itu. Masa iya layanan pihak ketiga semacam itu benar-benar menyerahkan dokumen identitas asli seperti gambar mentah ke aplikasi?

• Tidak masuk akal jika respons API permintaan mengembalikan OTP. Kenapa mereka melakukan itu?

  • Mungkin supaya UI bisa memeriksa apakah nilai yang dimasukkan pengguna benar.
    Jika tidak memikirkan keamanan, ini memang solusi yang sangat masuk akal dan tampak jelas. Aplikasi kencan pada dasarnya termasuk jenis aplikasi paling berbahaya untuk dibuat karena pasti memuat banyak informasi pengenal pribadi, dan ini mengerikan.
  • Bisa jadi mereka membuat dan menyimpan OTP, lalu mengembalikan respons database atau cache apa adanya.
    Dalam proof of concept cepat atau MVP, orang sering memakai model penyimpanan apa adanya sebagai respons API untuk menghemat waktu, jadi hal seperti ini mudah terlewat.
  • Trik sederhana untuk menghilangkan biaya database.
  • Mengurangi satu permintaan HTTP dan juga membuat pengalaman pengguna lebih cepat. Apa alasannya untuk tidak menyukainya?
    Saat API baru Pinterest keluar, API itu membagikan seluruh informasi pengguna ke semua aplikasi yang memakai integrasi OAuth, termasuk secret 2FA. Saya melaporkannya dan mendapat bounty, tetapi hal seperti ini juga terjadi pada API perusahaan besar yang seharusnya lebih paham.
  • OTP tampaknya dikirim dalam “respons yang memicu kata sandi sekali pakai”.
    Mungkin ini salah framework. Dugaan saya, objek yang dimasukkan ke database diserialisasi langsung oleh ORM atau sistem penyimpanan lain lalu dikembalikan sebagai respons HTTP.

• https://yaledailynews.com/blog/2025/04/24/yale-student-expos...
  Ini artikel lain tentang kasus ini.

  • “Pengembang harus menggunakan praktik terbaik, tetapi itu mungkin tidak cukup. Menjaga data tetap aman adalah masalah yang belum terpecahkan.” Oh begitu. Ya sudah, berarti tidak bisa diapa-apakan.

• Seandainya ada cara untuk membuat penyimpanan informasi pengenal pribadi seriskan penyimpanan limbah nuklir. Jika bocor, perusahaan hampir pasti bangkrut, dan para penanggung jawabnya harus menghadapi risiko hukum.
  Menurut saya ini cara terbaik untuk menyelaraskan insentif dengan benar. Saat ini hampir tidak ada sisi negatif dari menyimpan sebanyak mungkin data pengguna. Kebocoran data? Tinggal unggah satu tweet permintaan maaf lalu lanjut seperti biasa.

  • Menyamakan informasi pengenal pribadi dengan limbah nuklir menurut saya agak berlebihan. Informasi pengenal pribadi juga mencakup data yang relatif tidak berbahaya seperti alamat email untuk autentikasi dan kontak.
  • Mungkin kita butuh penjara khusus kejahatan kerah putih.
    Dengan begitu, masalah ini bisa mendapat perhatian yang memang seharusnya diterimanya.

• Jika “tidak menerima respons apa pun”, itu berarti saatnya memberi tahu bahwa jika kebungkaman terus berlanjut, kerentanan akan diungkap setelah 90 hari

  • Itu justru menjadi hukuman yang lebih besar bagi pengguna yang tidak bersalah daripada bagi perusahaan
  • Di sini bahkan tidak ada yang bisa disebut sebagai kerentanan. Ini hanya kondisi yang terbuka lebar secara terang-terangan
  • Melakukan itu adalah jalan tercepat untuk digugat secara perdata dan bahkan dilaporkan secara pidana