Bahkan sebelum saya mulai memahami ilmu yang kompleks tentang keamanan informasi, saya merasa bahwa otentikasi 2FA adalah cara yang dijamin untuk melindungi akun Anda dan tidak ada "ini peretas Anda" yang dapat, misalnya, menarik mata uang internal saya untuk membeli pakaian untuk karakter pada akun game. Namun seiring berjalannya waktu, telah terbukti secara eksperimental bahwa sistem otentikasi dua faktor dapat memiliki sejumlah besar kerentanan.
Dengan kata sederhana, otentikasi dua faktor adalah konfirmasi tindakan dengan memasukkan kode yang dihasilkan untuk meningkatkan keamanan dan melemparkan tongkat ke roda peretas bersyarat selama gerakan atau sebelum dimulai.
Sistem konfirmasi kode sangat luas, digunakan di mana-mana di berbagai situs dan dapat dihubungkan untuk login primer dan sekunder. Tetapi aplikasi ini tidak terbatas pada ini - pengembang melampirkan konfirmasi tentang fungsi pemulihan kata sandi, konfirmasi pendaftaran / berlangganan, konfirmasi tambahan transaksi keuangan, perubahan kata sandi, perubahan data pribadi. Juga, dari waktu ke waktu, 2FA digunakan sebagai tembok setelah logout untuk menentukan waktu, dan bukan kata sandi atau cara konfirmasi lainnya.
Dalam artikel ini, saya telah mengumpulkan cara untuk menguji 2FA untuk kerentanan, eksploitasi mereka, serta opsi yang mungkin untuk menghindari perlindungan yang ada terhadap jenis serangan tertentu. Mari kita lihat daftar cek kerentanan yang berlaku untuk 2FA:
1. Kurangnya Batas Tingkat
Algoritme Batas Nilai digunakan untuk menguji apakah sesi pengguna (atau alamat IP) dapat dibatasi dalam upaya atau kecepatan, dan dalam kondisi apa ini terjadi. Jika pengguna telah menyelesaikan terlalu banyak permintaan dalam periode waktu tertentu, aplikasi web dapat merespons dengan kode 429 (banyak permintaan) atau menerapkan batas Nilai tanpa menunjukkan kesalahan. Tidak adanya batas nilai menyiratkan bahwa selama penghitungan normal tidak ada batasan pada jumlah upaya dan / atau kecepatan - itu diperbolehkan untuk mengulangi kode beberapa kali (pada kecepatan apa pun) dalam sesi / periode validitas token.
Cukup sering Anda harus berurusan dengan batas-tingkat "bersuara", jika Anda melihat bahwa tidak ada kesalahan dan tubuh / kode HTTP tidak berubah dalam permintaan berikutnya, Anda harus senang terlalu dini, dan pertama-tama Anda perlu memeriksa hasil akhir serangan menggunakan kode yang valid.
2. Batas nilai ada, tetapi dapat dielakkan
Kasus yang harus saya temui sebelumnya:
1) Membatasi kecepatan aliran tanpa penyumbatan setelah mencapai kecepatan tertentu
Seringkali, peneliti keamanan mencoba mengambil kode menggunakan 5 utas atau lebih untuk membuat serangan lebih cepat (dalam Burp Intruder, jumlah utas default adalah 5 tanpa penundaan). Tetapi kadang-kadang sistem keamanan dari penghilang atau Load Balancer biasa hanya dapat menanggapi faktor tunggal ini. Jika Anda mencoba kekerasan dengan 5 utas, Anda harus mengurangi angkanya menjadi 1, dan kemudian menjadi 1 dengan penundaan satu detik. Sebelumnya, saya beruntung mengamati perilaku seperti itu dan dengan bantuan manipulasi seperti itulah pemilihan kode yang berhasil terjadi, yang mengarah pada Pengambilalihan Akun. Jika kode 2FA tidak memiliki tanggal kedaluwarsa tertentu, maka kami memiliki banyak waktu untuk memilah-milah. Jika periode validitas hadir, maka keberhasilan serangan berkurang, tetapi potensi bahaya kerentanan masih ada, karena masih ada peluang untuk masuk ke kode yang diinginkan.
2) Kode OTP yang dihasilkan tidak berubah
Ini tidak berlaku untuk kode yang terus berubah seperti di Google Authenticator, tetapi hanya kode statis yang datang melalui SMS, email atau secara langsung melalui messenger.
Inti dari bypass ini adalah bahwa kode OTP yang sama dikirim terus-menerus atau untuk beberapa waktu, misalnya, 5 menit, yang berlaku selama ini. Juga bermanfaat untuk memastikan bahwa tidak ada batas tingkat diam yang terjadi.
Contoh laporan:
hackerone.com/reports/420163Misalkan aplikasi menghasilkan kode acak dari 001 hingga 999 dan mengirimkannya ke telepon, dalam waktu 10 menit ketika fungsionalitas "kirim lagi" diaktifkan, kami mendapatkan kode yang sama. Tetapi batas-nilai terikat pada permintaan, yang membatasi jumlah upaya per token permintaan. Kami dapat terus-menerus meminta kode baru, menghasilkan token permintaan baru, menerapkannya pada permintaan berikutnya (menggunakan grep-match dalam sendawa atau menggunakan skrip kami sendiri) dan melakukan bruteforce dari sejumlah angka dari 001 hingga 999. Dengan demikian, terus-menerus menggunakan token permintaan baru kami akan berhasil memilih kode yang benar, karena tidak berubah dan statis untuk jangka waktu tertentu. Keterbatasan serangan ini adalah angka yang panjang atau campuran huruf dengan angka sebagai kode konfirmasi.
Situasi ini tidak boleh didorong, Anda harus mencoba memilah setidaknya sebagian dari daftar kami, karena ada kemungkinan bahwa kode yang dihasilkan akan ada di bagian daftar ini, karena dihasilkan secara acak. Saat mencoba, Anda harus mengandalkan acak, tetapi masih ada peluang untuk masuk ke kombinasi yang tepat, yang membuktikan kerentanan yang pasti perlu diperbaiki.
3) Reset rate-limit-a saat memperbarui kode.
Dalam permintaan verifikasi kode, batas nilai ada, tetapi setelah mengaktifkan fungsi pengiriman ulang kode, itu diatur ulang dan memungkinkan Anda untuk melanjutkan kode brute-force.
Contoh laporan:
https://hackerone.com/reports/149598 , - teori;
hackerone.com/reports/205000 , eksploitasi langsung berdasarkan laporan sebelumnya.
4) Melewati batas tingkat dengan mengubah alamat IP
Banyak kunci didasarkan pada pembatasan menerima permintaan dari IP, yang telah mencapai ambang sejumlah upaya ketika menjalankan permintaan. Jika alamat IP diubah, maka ada peluang untuk menghindari pembatasan ini. Untuk memeriksa metode ini, cukup ubah IP Anda menggunakan Proxy server / VPN dan lihat apakah pemblokiran tergantung pada IP.
Cara untuk mengubah IP:
- Proxy dapat digunakan dalam serangan menggunakan add-on Rotator IP untuk Burp Suite github.com/RhinoSecurityLabs/IPRotate_Burp_Extension . Menurut pendapat saya, ini adalah pilihan terbaik, karena memberi kami ~ upaya brute force yang tidak terbatas dan alamat IP yang memungkinkan Anda untuk melakukan serangan brute-force tanpa 42x kesalahan dan interupsi.
- Pilihan yang baik mungkin skrip python dengan modul permintaan proxy, tetapi pertama-tama Anda perlu mendapatkan sejumlah besar proxy yang valid di suatu tempat.
Karena alat putar IP mengirimkan permintaan menggunakan alamat IP AWS, semua permintaan akan diblokir jika aplikasi web berada di belakang firewall CloudFlare.
Dalam hal ini, Anda perlu menemukan IP tambahan dari server web asli atau menemukan metode yang tidak berkaitan dengan alamat IP AWS.
5) Situs ini mencakup dukungan untuk X-Forwarded-For
Header X-Forwarded-For bawaan dapat digunakan untuk mengubah IP. Jika aplikasi memiliki pemrosesan bawaan untuk header ini, cukup kirim X-Forwarded-For: diinginkan_IP untuk mengganti IP untuk melewati pembatasan tanpa menggunakan proxy tambahan. Setiap kali permintaan dikirim dari X-Forwarded-For, server web akan berpikir bahwa alamat IP kami cocok dengan nilai yang dikirimkan melalui header.
Materi tentang topik ini:
hackerone.com/reports/225897medium.com/@arbazhussain/bypassing-rate-limit-protection-by-spoofing-originating-ip-ff06adf341573. Lewati 2fa dengan mengganti sebagian permintaan dari sesi akun lain
Jika parameter dengan nilai tertentu dikirim untuk memverifikasi kode dalam permintaan, coba kirim nilai dari permintaan ke akun lain.
Misalnya, saat mengirim kode OTP, ID formulir, ID pengguna atau cookie yang terkait dengan pengiriman kode diperiksa. Jika kami menerapkan data dari parameter akun yang ingin Anda bypass verifikasi kode (Akun 1) ke sesi akun yang sama sekali berbeda (Akun 2), kami akan mendapatkan kode dan memasukkannya di akun kedua, maka kami dapat memintas perlindungan di akun pertama. Setelah memuat ulang halaman 2FA akan hilang.
4. Lewati 2FA menggunakan "fungsi menghafal"
Banyak situs yang mendukung otorisasi 2FA memiliki fungsi "ingat saya". Ini berguna ketika pengguna tidak ingin memasukkan kode 2FA pada login berikutnya. Penting untuk mengidentifikasi cara di mana 2FA "diingat". Ini bisa berupa cookie, nilai dalam penyimpanan sesi / lokal, atau hanya melampirkan 2FA ke alamat IP.
1) Jika 2FA dilampirkan menggunakan cookie, nilai cookie harus tidak dapat dilewati
Yaitu, jika sebuah cookie terdiri dari sejumlah angka yang meningkat untuk setiap akun, maka sangat mungkin untuk menerapkan serangan brute-force pada nilai cookie dan memotong 2FA. Pengembang harus menyediakan cookie (bersama dengan cookie sesi kunci dan token CSRF) dengan atribut HttpOnly sehingga tidak dapat dicuri menggunakan XSS dan digunakan untuk memotong 2FA.
2) Jika 2FA dilampirkan ke alamat IP, maka Anda dapat mencoba untuk menggantinya
Untuk mengidentifikasi metode ini, masuk ke akun Anda menggunakan fungsi penyimpanan 2FA, lalu beralih ke browser lain atau mode penyamaran dari browser saat ini dan coba masuk lagi. Jika 2FA tidak diminta sama sekali, maka 2FA telah dilampirkan ke alamat IP.
Untuk mengganti alamat IP, Anda dapat menggunakan header X-Forwarded-For pada tahap memasukkan login dan kata sandi, jika aplikasi web mendukungnya.
Dengan menggunakan tajuk ini, Anda juga dapat mem-bypass fungsi daftar putih alamat IP, jika ada di pengaturan akun. Ini dapat digunakan bersama dengan 2FA sebagai perlindungan akun tambahan atau 2FA bahkan mungkin tidak diminta jika alamat IP cocok dengan daftar putih (dengan persetujuan pengguna). Dengan demikian, bahkan tanpa melampirkan 2FA ke alamat IP, dalam beberapa kasus 2FA dapat dielakkan dengan mengelak dari metode perlindungan yang terkait.
Secara umum, melampirkan 2FA ke alamat IP bukanlah cara perlindungan yang sepenuhnya aman, karena ketika Anda hadir di jaringan yang sama, saat terhubung ke penyedia layanan VPN / Internet yang sama dengan alamat IP statis, 2FA dapat dilewati.
Cara teraman untuk melindungi diri Anda adalah dengan tidak mengingat 2FA sama sekali dengan merugikan kegunaan.
5. Bug kontrol akses yang tidak benar pada halaman input 2FA
Terkadang halaman dialog untuk memasukkan 2FA disajikan sebagai URL dengan parameter. Akses ke halaman seperti itu dengan parameter dalam URL dengan cookie yang tidak cocok dengan yang digunakan untuk menghasilkan halaman atau tanpa cookie sama sekali tidak aman. Tetapi jika pengembang memutuskan untuk menerima risiko, maka Anda harus melewati beberapa poin penting:
- Apakah tautan kedaluwarsa untuk input 2FA?
- apakah tautan diindeks di mesin pencari.
Jika tautan memiliki umur yang panjang dan / atau mesin pencari berisi tautan yang berfungsi untuk masukan / tautan 2FA dapat diindeks (tidak ada aturan dalam tag robots.txt / meta), maka ada kemungkinan menggunakan mekanisme pintas 2FA pada halaman masukan 2FA, di mana sepenuhnya memotong login dan kata sandi, dan mendapatkan akses ke akun orang lain.
6. Sensor data pribadi yang tidak memadai pada halaman 2FA
Saat mengirim kode OTP pada suatu halaman, sensor digunakan untuk melindungi data pribadi seperti email, nomor telepon, nama panggilan, dll. Tetapi data ini dapat sepenuhnya diungkapkan di titik akhir API dan permintaan lain yang haknya cukup pada tahap 2FA. Jika awalnya data ini tidak diketahui, misalnya, kami hanya memasukkan info masuk tanpa mengetahui nomor teleponnya, maka ini dianggap sebagai kerentanan Pengungkapan Informasi. Mengetahui nomor telepon / email dapat digunakan untuk serangan phishing dan kekerasan berikutnya.
Contoh mengeksploitasi kerentanan menggunakan Isian Kredensial. Katakanlah ada database di domain publik dengan login dan kata sandi untuk situs A. Penyerang dapat menggunakan data dari database ini di situs B:
- Pertama, mereka memeriksa apakah pengguna ada di database situs B menggunakan bug "Penghitungan Akun" dalam mendaftarkan / memulihkan kata sandi. Biasanya, banyak situs tidak menganggap ini sebagai kerentanan dan mengambil risiko. "Kerentanan" terletak pada adanya kesalahan tentang fakta pendaftaran pengguna di situs. Idealnya, pesan aman pada halaman pemulihan kata sandi adalah sebagai berikut:
- Setelah mendapatkan basis data pengguna yang ada, penyerang menerapkan kata sandi ke akun ini.
- Jika mereka bertemu 2FA, maka mereka macet. Tetapi dalam hal sensor data pengguna tidak cukup, mereka dapat melengkapi database mereka dengan data pribadi mereka (jika mereka tidak ada dalam database asli).
7. Mengabaikan 2FA dalam kondisi tertentu
Saat melakukan beberapa tindakan yang mengarah ke login otomatis ke akun Anda, 2FA mungkin tidak diminta.
1) Abaikan 2FA saat memulihkan kata sandi
Banyak layanan yang secara otomatis masuk ke akun Anda setelah menyelesaikan prosedur pemulihan kata sandi. Karena akses ke akun disediakan secara instan, saat Anda masuk ke akun 2FA Anda, itu dapat diabaikan dan sepenuhnya diabaikan.
Dampak laporan hackerone serupa yang saya kirim baru-baru ini:
Jika penyerang mendapatkan akses ke email korban (ia dapat meretas akun menggunakan phishing, serangan brutal, isian kredensial, dll.), Ia dapat mem-bypass 2FA, meskipun dalam kasus ini 2FA harus melindungi akun. Saat ini, untuk 2FA ada verifikasi kode Google Authenticator atau kode cadangan, tetapi bukan kode dari email, jadi Bypass ini masuk akal.
2) Mengabaikan 2FA saat masuk melalui jejaring sosial
Anda dapat melampirkan jaringan sosial ke akun pengguna Anda untuk dengan cepat masuk ke akun Anda dan pada saat yang sama mengatur 2FA. Saat Anda masuk ke akun Anda melalui jejaring sosial, 2FA dapat diabaikan. Jika email korban diretas, akan mungkin untuk memulihkan kata sandi untuk akun jejaring sosial (jika memungkinkan) dan masuk ke layanan tanpa memasukkan 2FA.
Dampak salah satu laporan:
- Sekelompok kerentanan lain, seperti kesalahan konfigurasi OAuth # 577468 yang dikirim sebelumnya, untuk sepenuhnya menangkap akun, melanggar 2FA.
- Jika penyerang meretas email pengguna, ia bisa mencoba mendapatkan kembali akses ke akun jejaring sosial dan masuk ke akun tersebut tanpa verifikasi tambahan.
- Jika penyerang pernah meretas akun korban, ia dapat mengaitkan jejaring sosial dengan akun tersebut dan masuk ke akun tersebut di masa depan, sepenuhnya mengabaikan 2FA dan memasukkan login / kata sandi.
3) Mengabaikan 2FA dalam versi aplikasi yang lebih lama
Pengembang sering menambahkan versi pementasan aplikasi web ke domain / subdomain untuk menguji fungsi tertentu. Menariknya, jika Anda masuk menggunakan nama pengguna dan kata sandi Anda, 2FA tidak akan diminta. Mungkin pengembang menggunakan versi aplikasi yang lebih lama, di mana tidak ada perlindungan untuk 2FA, 2FA sendiri dinonaktifkan atau sengaja dinonaktifkan untuk pengujian.
Selain itu, Anda dapat memeriksa kerentanan lain pada saat yang sama, - mendaftarkan pengguna baru di server pementasan yang emailnya ada di basis data versi produksi dapat memberi kami data pribadi dari produksi; tidak adanya batas kecepatan dalam fungsionalitas penting, misalnya, pemulihan kata sandi. Contoh dari kerentanan terbaru adalah bug facebook $ 15.000, yang memungkinkan peretasan akun menggunakan kode pemulihan kata sandi bruteforce di beta.facebook.com
www.freecodecamp.org/news/ponsible-disclosure-how-i-could-have-hacked-all- facebook-accounts-f47c0252ae4d .
4) Mengabaikan 2FA jika cross-platform
Implementasi 2FA dalam versi seluler atau desktop mungkin berbeda dari versi web aplikasi. 2FA mungkin lebih lemah daripada versi web atau sama sekali tidak ada.
7. Saat menonaktifkan 2FA, kode saat ini tidak diminta.
Jika, ketika menonaktifkan 2FA, konfirmasi tambahan tidak diminta, seperti kode saat ini dari aplikasi google authenticator, kode dari email / telepon, maka dalam hal ini ada risiko tertentu. Dengan permintaan bersih, ada kemungkinan serangan CSRF. Jika vektor bypass perlindungan CSRF ditemukan (jika ada), maka 2FA dapat dinonaktifkan. Kerentanan clickjacking juga dapat digunakan - setelah beberapa klik dari pengguna yang tidak curiga, 2FA akan dinonaktifkan. Validasi kode sebelumnya akan menambah perlindungan 2FA tambahan, mengingat potensi serangan CSRF / XSS / Clickjacking, serta kesalahan konfigurasi CORS.
Saya akan memberi Anda contoh hackerone.com, - ketika Anda mematikan 2FA dalam satu bentuk, Anda harus memasukkan dua variabel secara bersamaan, - kode saat ini dengan aplikasi dan kata sandi google authenticator. Ini adalah perlindungan terbaik dan direkomendasikan.
8. Sesi yang dibuat sebelumnya tetap valid setelah aktivasi 2FA
Ketika 2FA diaktifkan, diharapkan sesi paralel pada akhir akun yang sama dan dialog input 2FA ditampilkan, sama dengan perubahan kata sandi. Jika akun dikompromikan dan reaksi pertama korban adalah dimasukkannya 2FA, maka sesi penyerang akan dinonaktifkan dan login dan kata sandi berikutnya akan membutuhkan 2FA. Secara keseluruhan, ini adalah praktik terbaik yang harus diikuti. Saya sering memperhatikan bagaimana pertukaran mata uang kripto menambah perlindungan serupa. Contoh laporan HackerOne, -
https://hackerone.com/reports/534450.
9. Tidak adanya batas nilai dalam akun Anda
2FA dapat diimplementasikan dalam berbagai fungsi akun pribadi pengguna untuk keamanan yang lebih besar. Ini bisa berupa perubahan alamat email, kata sandi, konfirmasi perubahan kode untuk transaksi keuangan, dll. Kehadiran rate-limit-a di akun Anda mungkin berbeda dari keberadaan rate-limit-a di 2FA setelah memasuki akun Anda. Saya sering menemukan kasus serupa ketika dimungkinkan untuk secara bebas memilih kode 2FA di akun saya, sementara di pintu masuk batas tingkat "Ketat" telah ditetapkan.
Jika pada awalnya pengembang menambahkan perlindungan terhadap perubahan data yang tidak sah, maka perlindungan ini harus didukung dan diperbaiki oleh semua bypass-s yang mungkin. Jika bypass ditemukan, maka ini dianggap sebagai fitur keamanan bypass kerentanan yang diterapkan oleh pengembang.
10. Versi API
Jika Anda melihat sesuatu seperti / v * / dalam permintaan aplikasi web, di mana * adalah angka, maka kemungkinan Anda dapat beralih ke versi API yang lebih lama. API . , API production/staging .
, /endpoint/api/v4/login , . 2FA , /endpoint/api/v4/2fa_check, . API 2FA, , , . /endpoint/api/v3/login /endpoint/v3/login_successful?code=RANDOM, 2fa_check , API, 2FA .
, — /endpoint/api/v4/2fa_check rate-limit, /endpoint/api/v3/2fa_check - .
11. Improper Access Control
2FA . ( ). CORS /XSS , «» , 2FA, .
, 2 , , , 2FA web , — . , 2FA ( Salesforce, Valve) 2FA. 2FA , 2FA bypass-.
, , bug bounty , , . Stay safe!