Saat ini, ada begitu banyak jenis kerentanan sehingga pengembang sepenuhnya melupakan yang mendasar. Suatu hari, saya berhasil melewati otorisasi dalam aplikasi WOG baru (TOV "VOG RETAIL" - jaringan pompa bensin terbesar kedua di Ukraina). Pada 2017, saya menemukan kerentanan yang persis sama dalam aplikasi salah satu penyedia ponsel Ukraina (juga yang terbesar kedua). Situasi identik - aplikasi baru dan kurangnya perlindungan terhadap kekuatan kasar.
Belum lama ini saya menerima pemberitahuan - perusahaan mengeluarkan aplikasi baru dan menawarkan untuk menginstalnya. Saya benar-benar menyukai fungsi aplikasi - melihat bonus di akun yang Anda dapat membeli bahan bakar. Kemampuan untuk melampirkan kartu bank dan membayar barang tanpa kontak atau dengan kode QR. Profil ini juga menampilkan nama dan rincian kontak saya, riwayat transaksi lengkap - daftar barang dan nilainya pada saat pembelian.
Otorisasi dalam aplikasi menjadi lebih mudah - sekarang Anda tidak perlu memasukkan nomor kartu loyalitas, cukup tentukan nomor ponsel. Namun, bahkan di pintu masuk saya curiga ada yang bisa melihat data saya - saya khususnya, lebih dari 5 kali, memasukkan kode yang berbeda dari yang saya terima dalam SMS. Mengapa - Karena sebelumnya, dalam aplikasi serupa dari operator seluler, saya menemukan kerentanan yang memberikan akses penuh untuk mengelola akun pelanggan.
Memasukkan kode yang salah, adalah mungkin untuk mengetahui bahwa perlindungan terhadap kekuatan kasar kemungkinan besar tidak.
Saya benar - aplikasi tidak memiliki perlindungan. Anda dapat mengakses akun apa pun, dan terlebih lagi, “membajak” akun Anda - tautan ke nomor lain, habiskan dana orang lain.
Saya mendapat kesan bahwa pengembang aplikasi sepenuhnya lupa bahwa lalu lintas jaringan tidak sulit untuk dicegat, bahkan permintaan https.
Secara pribadi, saya menggunakan program fiddler - alat ini memungkinkan proxy traffic, melihatnya atau mengubahnya. Untuk mengakses konten permintaan https, di samping pengaturan proxy, di properti koneksi smartphone, Anda juga harus menginstal sertifikat tepercaya yang dihasilkan oleh program.
Pertama-tama, saya senang dengan harga diri para pengembang aplikasi - API yang menggunakan aplikasi ini terletak di domain .wog.ua. Hanya dengan menelusuri URL, saya dapat mengetahui bahwa
IIS 7.5 dan
1C: Enterprise 8 hidup di server, serta gambar dari header (mungkin penggemar Machinarium menulis API?).
Skema otorisasi sederhana - permintaan dengan "permintaan" untuk mengirim kode ke SMS terbang ke salah satu
metode API. Dan di sini kerentanan pertama adalah tidak adanya batasan. Pada nomor telepon yang sama, dari satu IP Anda dapat "memesan" SMS sebanyak yang Anda suka.
Kemudian, dalam tender perusahaan, saya menemukan
informasi bahwa mereka berencana untuk mengirim hingga 1.000.000 SMS per bulan (mereka siap untuk menghabiskan ~ $ 98.000 untuk ini selama setahun). Ternyata kerentanan dapat menyebabkan kerugian perusahaan ~ $ 8,200 per hari jika 12 permintaan dikirim per detik.
Perlu dicatat bahwa bagi server untuk memproses permintaan dengan benar, diperlukan
otorisasi dasar - ini adalah salah satu metode perlindungan yang digunakan pengembang. Mengapa Tidak jelas - saya tidak melihat artinya - mencegat
login / kata sandi atau header http yang diperlukan tidak menjadi masalah sama sekali.
Setelah pengguna menerima SMS dan memasukkan kode ke dalam aplikasi, ia mengirim
permintaan untuk memverifikasi keandalan kode dan menerima token. Kerentanan berikutnya dan paling kritis ada di sini - tidak ada perlindungan terhadap kekerasan. Pemilihan kode, yang terdiri dari 4 (!) Digit, tidak memerlukan banyak waktu.
Setelah menerima token, Anda dapat menggunakan metode API lainnya. Salah satunya memungkinkan untuk mengubah kode PIN dari kartu loyalitas. Prosedurnya standar - masukkan PIN lama, masukkan yang baru. Saya ingin fokus pada metode ini, karena di sini pengembang menggunakan metode lain yang tidak berguna "perlindungan". Secara alami, juga tidak ada perlindungan terhadap kekerasan, tetapi pin lama dikirim dalam bentuk tersembunyi. Idenya bagus - hanya menyortir kombinasi 0000-9999 akan gagal. Implementasinya buruk - alih-alih kode, hash md5 dikirim. Tanpa penggantian garam atau apa pun.
Jujur, saya tidak tahu cara mengakses kode aplikasi dan apakah ini mungkin - bahkan md5 yang sudah ketinggalan zaman akan menghentikan saya jika garam digunakan.
Saya juga berhasil tidak hanya memaksa token untuk akun "asing", tetapi juga memasukkannya ke dalam aplikasi - saya menulis sebuah skrip kecil di node.js yang mem-proksi lalu lintas dan hanya mengganti respons dari metode gettoken.
Artikel itu ditulis setelah berbicara dengan "wakil direktur departemen TI" perusahaan. Orang-orang bereaksi dengan cepat - Saya bisa mendapatkan kontak untuk komunikasi dalam 24 jam. Saya mengirim deskripsi kerentanan dan pertanyaan tentang keberadaan karunia bug.
Sebagai tanggapan, saya menerima surat dengan informasi yang mereka duga “melihat” saya - “
Kami melihat Anda (380958302 ---) segera dan kunci bekerja ... Saya tidak akan memberi tahu tentang semua kunci, tetapi banyak dari mereka yang muncul kemarin ”
Bagi saya, itu lebih mirip embun beku - karena, ketika saya menjawab surat ini, “
leluconnya adalah bahwa angka ini tidak saya kenal. Saya menguji pada nomor 095866 ... "
Berbeda dengan perusahaan WOG, kepala departemen keamanan informasi operator seluler jauh lebih banyak bicara, dan mereka memasang smartphone sebagai ucapan terima kasih =)