Bank Wareville mengalami lonjakan pendapatan yang signifikan tahun ini dan diperkirakan akan meraih keuntungan besar sebelum musim liburan. Mereka berencana untuk mengumumkan kabar baik ini kepada warga kota pada perayaan SOC-mas. Namun, hal yang tak terduga terjadi. Setelah menyelesaikan perhitungan tahunan, para akuntan terkejut melihat adanya kerugian besar. Mereka menemukan ketidaksesuaian dalam saldo akun.
Embedded Files
Pihak bank kemudian memanggil McSkidy untuk membantu menyelidiki transaksi-transaksi pengguna yang diduga curang. Setelah menganalisis log transaksi pada situs web bank, McSkidy menemukan beberapa transaksi mencurigakan. Beberapa pengguna, termasuk tim Wali Kota, melakukan banyak transaksi sekaligus dari rekening cadangan milik Bank Wareville.
Yang mengejutkan, semua transaksi tersebut berhasil diproses meskipun melebihi saldo pengguna saat ini. Glitch sudah mengetahui adanya kerentanan kritis (yang memungkinkan transaksi curang ini), yang kemudian dieksploitasi oleh Mayor Malware dan aliansinya.
Penjelasan ini mencerminkan pentingnya investigasi digital forensic dalam mendeteksi dan mencegah insiden keamanan siber di sektor perbankan.
Web Timing dan Race Conditions
Aplikasi web konvensional relatif mudah dipahami, diidentifikasi, dan dieksploitasi. Jika terdapat masalah dalam kode aplikasi web, kita dapat memaksa aplikasi tersebut melakukan aksi yang tidak diinginkan dengan mengirimkan input tertentu. Hal ini mudah dimengerti karena biasanya ada hubungan langsung antara input dan output. Ketika kita mengirimkan data yang buruk, kita mendapatkan output yang buruk, sehingga menunjukkan adanya celah keamanan. Namun, bagaimana jika kita bisa menemukan kerentanan hanya dengan menggunakan data yang valid? Bagaimana jika masalahnya bukan pada datanya, tetapi pada cara kita mengirimkannya? Inilah peran dari serangan web timing dan race condition! Mari kita eksplorasi dunia serangan ini yang sering tersembunyi dari permukaan!
Web Timing Attack
Web Timing Attack
Dalam bentuknya yang paling sederhana, web timing attack berarti kita memperoleh informasi dari aplikasi web dengan menganalisis berapa lama aplikasi memproses permintaan kita. Dengan melakukan sedikit perubahan pada apa yang kita kirimkan atau bagaimana cara kita mengirimkannya, lalu mengamati waktu responsnya, kita dapat mengakses informasi yang sebenarnya tidak diizinkan untuk kita akses.
Race Condition
Race Condition
Race conditions adalah subset dari serangan web timing yang lebih spesifik. Dalam serangan race condition, tujuan kita tidak hanya memperoleh akses ke informasi, tetapi juga memaksa aplikasi web melakukan tindakan yang tidak diinginkan atas nama kita.
Kerentanan web timing sering kali sangat halus. Berdasarkan penelitian, perbedaan waktu respons mulai dari 1300ms hingga 5ns dapat digunakan untuk melancarkan serangan. Karena sifatnya yang subtil, kerentanan ini sulit dideteksi dan sering kali memerlukan berbagai teknik pengujian. Namun, dengan meningkatnya adopsi HTTP/2, kerentanan ini menjadi lebih mudah ditemukan dan dieksploitasi.
Meningkatnya Penggunaan HTTP/2
Meningkatnya Penggunaan HTTP/2
HTTP/2 dikembangkan sebagai pembaruan besar untuk HTTP, protokol yang digunakan oleh aplikasi web. Meskipun sebagian besar aplikasi web masih menggunakan HTTP/1.1, adopsi HTTP/2 meningkat karena protokol ini lebih cepat, meningkatkan performa web, dan memiliki fitur yang mengatasi keterbatasan HTTP/1.1. Namun, jika diimplementasikan dengan salah, fitur-fitur baru ini dapat dieksploitasi oleh aktor ancaman menggunakan teknik baru.
Salah satu perbedaan utama dalam serangan web timing antara HTTP/1.1 dan HTTP/2 adalah fitur single-packet multi-requests pada HTTP/2. Network latency (latensi jaringan), yaitu waktu yang dibutuhkan permintaan untuk mencapai server web, sebelumnya menyulitkan identifikasi masalah web timing. Sulit membedakan apakah perbedaan waktu disebabkan oleh kerentanan atau hanya perbedaan latensi jaringan. Dengan single-packet multi-requests, kita dapat menggabungkan beberapa permintaan dalam satu paket TCP, sehingga menghilangkan latensi jaringan dari persamaan. Ini memungkinkan kita mengatribusikan perbedaan waktu sepenuhnya pada waktu pemrosesan server.
Jenis Timing Attacks
Jenis Timing Attacks
Timing Attack dapat dibagi menjadi dua kategori utama:
Information Disclosures
Dengan memanfaatkan perbedaan waktu respons, aktor ancaman dapat mengungkap informasi yang seharusnya tidak mereka akses. Misalnya, perbedaan waktu dapat digunakan untuk enumerasi username dalam suatu aplikasi, sehingga mempermudah serangan password-guessing untuk mengakses akun.Race Conditions
Race conditions mirip dengan cacat logika bisnis (business logic flaws) di mana aktor ancaman dapat memaksa aplikasi melakukan tindakan yang tidak diinginkan. Masalah ini biasanya berasal dari cara aplikasi web memproses permintaan, yang memungkinkan kondisi race terjadi. Misalnya, jika kita mengirimkan permintaan yang sama untuk kupon beberapa kali secara bersamaan, mungkin saja kupon tersebut dapat diterapkan lebih dari satu kali.
Contoh Race Condition: TOCTOU Flaw
Contoh Race Condition: TOCTOU Flaw
Salah satu contoh race condition adalah kerentanan Time-of-Check to Time-of-Use (TOCTOU). Misalnya, ketika pengguna mengirimkan kode kupon, aplikasi web akan memeriksa apakah kupon valid dan belum digunakan sebelumnya. Kemudian aplikasi akan menerapkan diskon dan memperbarui status kupon agar dianggap sudah digunakan.
Namun, antara waktu pemeriksaan validitas kupon dan pembaruan status kupon, terdapat beberapa milidetik di mana diskon diterapkan. Jika aktor ancaman mengirimkan dua permintaan hampir bersamaan, kupon mungkin belum diperbarui pada permintaan pertama saat permintaan kedua diperiksa. Akibatnya, kedua permintaan berhasil menerapkan diskon!
Practical
Masuk pada alamat website dan mengisi halaman login dengan kredensial glitch/account number 101
Setelah masuk ke Dashboard, terlihat Total saldo glitch adalah 2000. Melakukan transfer ke nomor akun 111 dengan nilai saldo yang di transfer adalah 500.
Setelah berhasil melakukan transfer, saldo berkurang dan terlihat pesan "Success"
Di History Burp, terdapat URL /transfer dengan method POST. Kemudian di teruskan ke Repeater
Setelah di intruder, dilakukan duplikat sebanyak 10 kali. Kemudian Create Tab Group,
Setelah di intruder, dilakukan duplikat sebanyak 10 kali. Kemudian Create Tab Group.
Setelah itu, pilih options dari tombol Send ke Send Group in parallel. Mulai jalankan/send. Perintah ini mengirim 10 kali dengan total yang di transfer adalah 500.
Setelah itu kembali ke halaman Dashboard dan terlihat saldo berkurang menjadi negatif (-) dan flag ditemukan.
Fixing the Race Condition
Dalam aplikasi perbankan yang dirancang oleh pengembang, terdapat kerentanan race condition yang terjadi selama proses transfer dana. Kerentanan ini muncul karena aplikasi tidak menangani permintaan secara concurrent (berjalan bersamaan) dengan benar. Ketika beberapa permintaan dikirim secara paralel, masing-masing untuk mengurangi dan mentransfer dana, aplikasi memprosesnya secara simultan tanpa memastikan adanya sinkronisasi yang memadai. Akibatnya, saldo akun menjadi tidak konsisten, seperti saldo negatif pada akun pengirim dan kelebihan dana pada akun penerima.
Pencegahan untuk mengatasi race condition:
- Menggunakan Transaksi Atomik
Pengembang harus mengimplementasikan atomic database transactions untuk memastikan bahwa semua langkah dalam proses transfer dana (mengurangi saldo pengirim dan menambahkan saldo penerima) dilakukan sebagai satu kesatuan. Dengan cara ini, jika salah satu langkah gagal, maka seluruh transaksi akan dibatalkan, sehingga mencegah terjadinya pembaruan parsial yang dapat menyebabkan inkonsistensi data.
- Mengimplementasikan Mutex Locks
Dengan menggunakan Mutex Locks, pengembang dapat memastikan bahwa hanya satu thread yang mengakses sumber daya bersama (seperti saldo akun) pada satu waktu. Langkah ini akan mencegah permintaan yang berjalan bersamaan saling mengganggu selama transaksi berlangsung, sehingga menjaga konsistensi saldo akun.
- Menerapkan Batasan Kecepatan (Rate Limits)
Pengembang seharusnya menerapkan rate limiting pada fungsi-fungsi kritis seperti transfer dana dan penarikan. Dengan cara ini, jumlah permintaan yang dapat diproses dalam jangka waktu tertentu dibatasi, sehingga risiko penyalahgunaan akibat permintaan berulang yang cepat dapat dikurangi.
Google Sites
Report abuse