Dalam kontes Capture‑The‑Flag (CTF) berskala internasional, tim “Lovely Login” dari BroncoCTF menyajikan tantangan yang tampak sederhana: formulir login minimalis yang diklaim sebagai “Secure Database”. Endpoint login menggunakan API Express yang menerima permintaan POST JSON dengan pasangan username dan password. Pengujian awal menunjukkan pola error dua langkah—“No such user” dan “Wrong password”—yang mengindikasikan bahwa sistem melakukan pencarian akun terpisah sebelum memverifikasi kata sandi.
Hipotesis pertama yang alami adalah injeksi operator NoSQL (misalnya $gt, $ne, $regex) pada salah satu field. Penguji mencoba berbagai payload seperti {"username": {"$gt": ""}, "password": "test"}, {"username": "admin", "password": {"$ne": ""}}, dan bahkan penyuntikan array untuk menguji type‑juggling. Setiap upaya menghasilkan respons generik yang sama, tanpa perbedaan antara pola yang cocok dan tidak cocok. Konsistensi ini mengkonfirmasi bahwa input tunduk pada pemeriksaan tipe/konversi server-side yang ketat sebelum mencapai database, sehingga operator NoSQL tidak pernah mencapai MongoDB—injeksi terbukti menjadi jalan buntu.
Dengan injeksi yang tidak mungkin, perhatian beralih ke rekognisi web standar. Permintaan terhadap robots.txt mengungkapkan dua temuan penting:
User‑agent: * Disallow: /security # amVmZixzYXJhaCxhZG1pbixndWVzdA==
Entri “Disallow: /security” adalah permintaan kesopanan untuk crawler, bukan kontrol akses. Komentar yang disematkan adalah daftar username yang disandikan base64: “jeff,sarah,admin,guest”. Mengungkapkannya menunjukkan daftar akun valid tanpa perlu brute‑force.
Mengunjungi jalur yang dilarang memberikan akses langsung ke halaman Catatan Keamanan internal:
<h1>Catatan Keamanan Internal</h1> <p><b>Status:</b> Dalam pengembangan</p> <ul> <li>Kata sandi berasal dari username</li> <li>Implementasi saat ini menyimpannya terbalik untuk penyamaran</li> <li>Rencana peningkatan: hashing + salting</li> </ul> <p><b>TODO:</b> hapus halaman ini sebelum penyebaran produksi!</p>
Dokumentasi tersebut secara eksplisit menyatakan bahwa kata sandi adalah username yang dibalik (misalnya username “admin” → password “nimda”). Tidak ada hashing, salting, atau acak—hanya manipulasi string sederhana. TODO dari pengembang mengkonfirmasi bahwa kontrol ini tidak pernah diterapkan.
Eksploitasi dilakukan dengan mudah. Mengirimkan permintaan POST ke /login dengan username “admin” dan password “nimda” berhasil:
curl -X POST https://broncoctf-lovely-login.chals.io/login \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":"nimda"}'
<h2>Welcome, admin.</h2> <pre>bronco{[REDACTED]}</pre>
Login berhasil pada upaya pertama, memberikan flag CTF. Insiden ini menyoroti tiga kerentanan yang saling terkait:
1. **Menggunakan robots.txt sebagai kontrol akses** – halaman /security yang sensitif diungkapkan oleh entri Disallow yang dapat dibaca siapa pun. 2. **Kebocoran daftar akun** – komentar base64 dalam file publik menghilangkan kebutuhan akan enumerasi akun. 3. **Derivasi kata sandi yang dapat diprediksi** – skema reversal string memungkinkan penyerang untuk menghitung kata sandi yang valid untuk setiap username yang diketahui tanpa usaha komputasi.
Root cause adalah kombinasi dari kebiasaan buruk pengembangan (meninggalkan catatan internal), kepercayaan yang salah pada robots.txt, dan kurangnya kebijakan kata sandi yang kuat. Tim pengembang sendiri mengakui kerentanan tersebut dalam TODO, yang menunjukkan kurangnya proses QA yang ketat sebelum peluncuran.
Untuk mencegah insiden serupa, organisasi harus:
- **Jangan pernah mengandalkan robots.txt untuk keamanan**; itu adalah konvensi crawler, bukan mekanisme autentikasi/otorisasi. - **Lindungi halaman debug/internal** dengan autentikasi yang tepat dan pastikan halaman tersebut tidak diekspos di produksi. - **Jangan derivasi kata sandi dari data yang dapat diprediksi**; gunakan algoritma hashing yang aman (bcrypt, Argon2, scrypt) dengan salt unik per pengguna. - **Lakukan audit kode dan tinjauan keamanan** sebelum deployment, dengan fokus pada kontrol akses dan penyimpanan rahasia.
Bagi komunitas keamanan siber di Indonesia, tantangan ini berfungsi sebagai pengingat berharga. Banyak CTF lokal dan internasional masih menemukan kerentanan “sederhana” yang berasal dari praktik ini. Belajar dari kasus Lovely Login mendorong profesional keamanan lokal untuk menekankan pentingnya “shift-left” dalam keamanan, menerapkan kontrol akses yang ketat, dan menghindari pengungkapan informasi yang tidak sengaja. Ketika industri di Indonesia mempercepat adopsi cloud dan mikrolayanan, kebiasaan seperti itu dapat memiliki konsekuensi yang luas, sehingga membuat analisis mendalam seperti ini sangat berharga bagi praktisi dan pengambil keputusan.
Kesimpulannya, kerentanan BroncoCTF Lovely Login adalah pengingat bahwa kontrol keamanan sering kali gagal bukan karena kode yang canggih, tetapi karena asumsi yang salah dan kebiasaan buruk. Dengan menerapkan prinsip-prinsip dasar—autentikasi yang kuat, hashing kata sandi yang tepat, dan audit yang ketat—organisasi dapat mencegah kebocoran data yang memalukan dan melindungi aset digital mereka di era ancaman yang semakin canggih.