Kerentanan Algoritma Hash MIGS

Dengan munculnya kartu kredit dan Internet, berbelanja menjadi lebih mudah dan, seperti kata mereka, lebih aman. Hanya beberapa klik dan produk yang Anda butuhkan sudah dalam perjalanan ke rumah Anda. Namun, tidak semua sistem sempurna, atau lebih tepatnya, tidak ada. Anda selalu dapat menemukan beberapa jenis kesalahan, celah yang memungkinkan penyerang melakukan tindakan kotor mereka. Hari ini saya ingin menarik perhatian Anda untuk mempelajari seorang programmer yang sangat berbakat, Yohanes Nugroho, yang berbicara tentang kerentanan dalam sistem MIGS.

Teks ini adalah terjemahan dari kata-kata peneliti kerentanan Yohanes Nugroho sendiri. Selamat bersenang-senang.

Kerentanan Algoritma Hash MIGS

Tahun lalu, saya menemukan kesalahan dalam algoritma hash berbasis MD5 yang digunakan oleh MIGS (Mastercard Internet Gateway Service). Itu memungkinkan Anda untuk melakukan perubahan pada ukuran transaksi. Perusahaan memberi penghargaan kepada saya karena menemukan masalah ini. Pada tahun yang sama, MIGS beralih menggunakan HMAC-SHA256, tetapi ada beberapa kerentanan.

Apa itu MIGS?

Saat Anda membayar di situs web, pemiliknya biasanya menghubungkan sistem mereka ke gateway pembayaran perantara (ada transisi ke halaman lain). Gateway pembayaran ini kemudian dihubungkan ke beberapa sistem pembayaran yang tersedia di negara tertentu. Untuk kartu kredit, banyak gateway terhubung ke gateway lain (salah satunya adalah MIGS), yang bekerja dengan banyak bank untuk menyediakan 3DSecure.

Bagaimana cara kerjanya?

Urutan pembayaran, jika Anda menggunakan MIG, biasanya terlihat seperti ini:

1. Anda memilih produk di situs.
2. Masukkan nomor kartu kredit Anda.
3. Nomor kartu, ukuran pembayaran, dan parameter lainnya ditandatangani dan dikembalikan ke browser, yang secara otomatis menghasilkan permintaan POST ke gateway pembayaran perantara.
4. Gateway ini mengubah informasi menjadi format yang didukung oleh MIGS, menandatangani dengan kunci MIGS dan mengembalikannya ke browser. Setelah itu browser menghasilkan permintaan POST lain ke server MIGS itu sendiri.
5. Jika 3DSecure tidak diaktifkan, langkah ini dilewati. Kalau tidak, MIGS mentransfer permintaan ke bank yang mengeluarkan kartu. Bank meminta OTP dan menghasilkan HTML, yang menghasilkan permintaan POST untuk server MIGS.
6. MIGS mengembalikan data yang ditandatangani ke browser dan membuat permintaan POST untuk gateway pembayaran perantara.
7. Validasi data dan tanda tangan oleh gateway pembayaran perantara. Jika data salah, halaman kesalahan dihasilkan.
8. Berdasarkan respons MIGS, gateway pembayaran mentransmisikan status pembayaran kepada penjual.

Kerentanan dalam Algoritma Hashing MD5

Kesalahan ini sangat sederhana. Metode hash menggunakan rumus berikut:

MD5 (Rahasia + Data)

Tetapi tidak ada kerentanan untuk ekstensi hash (beberapa pemeriksaan dilakukan untuk mencegah hal ini). Data dibentuk dengan cara ini: semua parameter permintaan yang dimulai dengan vpc_ diurutkan, setelah itu nilainya terhubung tanpa pemisahan. Misalnya, kami memiliki data berikut:

Nama: Joe
Jumlah: 10000
Kartu: 1234567890123456

vpc_Name = Joe & Vpc_Amount = 10000 & vpc_Card = 1234567890123456

Terapkan penyortiran:

vpc_Amount = 10000
vpc_Card = 1234567890123456
vpc_Name = Joe

Kami menghubungkan nilai-nilai:

100001234567890123456Joe

Perhatikan jika saya mengubah parameter:

vpc_Name = Joe & Vpc_Amount = 1 & vpc_Card = 1234567890123456 & vpc_B = 0000

Terapkan penyortiran:

vpc_Amount = 1
vpc_B = 0000
vpc_Card = 1234567890123456
vpc_Name = Joe

Kami menghubungkan nilai-nilai:

100001234567890123456Joe

Nilai MD5 itu akan sama. Artinya, pada kenyataannya, ketika data ditransfer ke MIGS, kita dapat menambahkan parameter tambahan setelah ukuran pembayaran untuk menghapus digit terakhir, atau sebelum itu - untuk menghapus yang pertama. Dan Anda dapat membayar $ 2 sebagai ganti 2000 untuk MacBook.

Gateway perantara dan pedagang dapat menghindari kerentanan ini dengan selalu memeriksa apakah jumlah pembayaran yang dikembalikan oleh MIGS sesuai dengan yang diminta.

MasterCard memberi saya imbalan karena mengidentifikasi kesalahan ini dengan premi $ 8500.

HMAC-SHA256 Kerentanan Hash

HMAC-SHA256 baru memiliki kerentanan yang dapat dieksploitasi jika kami menyuntikkan nilai yang salah ke gateway pembayaran perantara. Saya memeriksa kesalahan ini di salah satu gateway pembayaran (Pembayaran Fusion). Mereka membayar saya bonus $ 500 untuk ini. Kerentanan ini juga dapat memengaruhi gateway pembayaran lain yang terhubung ke MIGS.

Dalam versi baru, pembatas (&) antara bidang, nama bidang (bukan hanya nilai) ditambahkan, dan, tentu saja, HMAC-SHA256. Untuk data yang sama seperti sebelumnya, garis hash terlihat seperti ini:

Vpc_Amount = 10000 & vpc_Card = 1234567890123456 & vpc_Name = Joe

Kami tidak dapat memindahkan apa pun; semua yang ada dalam rencana ini tertata dengan baik. Tetapi bagaimana jika nilainya mengandung karakter & atau = atau lainnya?

Setelah membaca dokumen Referensi Integrasi Klien Pembayaran Virtual MiGS, saya menemukan:

"Catatan: Nilai dalam semua pasangan nama / nilai, untuk tujuan hashing, TIDAK boleh mengandung karakter URL"

Saya fokus pada TIDAK . Ini berarti jika kita memiliki bidang-bidang berikut:

Jumlah = 100
Kartu = 1234
CVV = 555

Hashing akan seperti ini: HMAC (Jumlah = 100 & Kartu = 1234 & CVV = 555)

Dan jika isiannya seperti ini (menggunakan & dan =):

Jumlah = 100 & Kartu = 1234
CVV = 555

Hash itu terlihat seperti ini: HMAC (Jumlah = 100 & Kartu = 1234 & CVV = 555)

Dengan cara yang sama. Namun sejauh ini, bukan masalah seperti itu.

Tentu saja, saya pikir mungkin ada masalah dalam dokumentasi resmi, mungkin karakter URL masih harus digunakan. Tapi saya memeriksa perilaku server MIGS, semuanya seperti dalam dokumen. Mungkin mereka tidak ingin bekerja dengan pengkodean yang berbeda (seperti + bukannya% 20).

Tampaknya seharusnya tidak ada masalah, nilai yang salah akan diperiksa oleh MIGS dan memberikan kesalahan (misalnya, ukuran pembayaran yang salah akan ditolak).

Tetapi saya perhatikan bahwa di beberapa gateway pembayaran, alih-alih memeriksa data yang dimasukkan di sisi server, mereka hanya menandatangani dan mengalihkan semuanya ke MIGS. Jauh lebih mudah untuk menguji JavaScript di sisi klien, menandatangani data di sisi server, dan kemudian membiarkan MIGS memutuskan apakah nomor kartu sudah benar, apakah CVV harus terdiri dari 3 atau 4 digit, apakah kartu kedaluwarsa dengan benar, dll. Logikanya adalah ini: MIGS akan memeriksa ulang data dan membuatnya lebih baik.

Di Pembayaran Fusion, saya mengetahui bahwa inilah yang terjadi: mereka mengizinkan Anda memasukkan kode CVV apa pun (verifikasi hanya dilakukan di JavaScript), lalu menandatangani permintaan dan mengirimkannya ke MIGS.

Eksploitasi

Untuk mengeksploitasi kerentanan ini, kita perlu membuat string yang akan menjadi permintaan yang benar dan mendapatkan respons yang benar dari server MIGS. Kami tidak perlu berkomunikasi dengan server MIGS, kami hanya membuat klien menandatangani data yang benar.

Permintaan dasar:

vpc_AccessCode = 9E33F6D7 & vpc_Amount = 25 & vpc_Card = Visa & vpc_CardExp = 1717 & vpc_CardNum = 459977778888999999 & vpc_CardSecurityCode = 999 & vpc_OrderInur = vdchecfurecurecureecurecurecurecurecurecurecurecurecurecurecurecurecurecurecurecureecurecurecurecurecurecurecurecurecurecurecureecurecurecurecurecurecurecurecurecurecurecurecureecurecurecureecurecurecurecureecurecurecurecurecurecurecureecurecurecurecurecurecurecureecurecurecurecurecurecurecurecurecurecureecurecureecurecurecurecurecureecurecureecurecurecureecececececure aman menjamin aman lebih aman aman aman aman aman aman aman aman aman

Dan respons dasar dari server akan seperti ini:

vpc_Message = Disetujui & vpc_OrderInfo = ORDERINFO & vpc_ReceiptNo = 722819658213 & vpc_TransactionNo = 2000834062 & vpc_TxnResponseCode = 0 & vpc_SecureHash = THEHASH & vpc_Secure25ec25252525

Dalam kasus Pembayaran Fusion, exploit diimplementasikan dengan mengimplementasikan vpc_CardSecurityCode (CVV)

vpc_AccessCode = 9E33F6D7 & vpc_Amount = 25 & vpc_Card = Visa & vpc_CardExp = 1717 & vpc_CardNum = 4599777788889999 & vpc_CardSecurityCode = 999% 26vpc_Message% 3DApproved% 26vpc_OrderInfo% 3DORDERINFO% 26vpc_ReceiptNo% 3D722819658213% 26vpc_TransactionNo% 3D2000834062% 26vpc_TxnResponseCode% 3D0% 26vpc_Z% 3DA & vpc_OrderInfo = ORDERINFO & vpc_SecureHash = THEHASH & vpc_SecureHashType = SHA256

Gateway klien / pembayaran menghasilkan hash yang benar untuk baris ini.

Sekarang kita dapat memasukkan data ini ke dalam klien itu sendiri (tanpa berinteraksi dengan server MIGS dengan cara apa pun), tetapi kami akan mengubahnya sedikit sehingga klien mengenali variabel yang diperlukan (kebanyakan klien hanya memeriksa vpc_TxnResponseCode dan vpc_TransactionNo):

vpc_AccessCode = 9E33F6D7% 26vpc_Amount% 3D25% 26vpc_Card% 3DVisa% 26vpc_CardExp% 3D1717% 26vpc_CardNum% 3D4599777788889999% 26vpc_CardSecurityCode% 3D999 & vpc_Message = Disetujui & vpc_OrderInfo = ORDERINFO & vpc_ReceiptNo = 722.819.658.213 & vpc_TransactionNo = 2000834062 & vpc_TxnResponseCode = 0 & vpc_Z = a% 26vpc_OrderInfo% 3DORDERINFO & vpc_SecureHash = THEHASH & vpc_SecureHashType = SHA256

Catatan:

Hashing akan sama dengan data sebelumnya.
Klien akan mengabaikan vpc_AccessCode dan nilainya.
Klien akan menangani vpc_TxnResponseCode, dll., Dengan asumsi transaksi sudah benar.

Dapat dikatakan bahwa ini adalah kesalahan klien MIGS, tetapi metode hash yang digunakan oleh MasterCard memungkinkan kesalahan ini ada. Jika nilai-nilai dikodekan, kerentanan ini tidak akan ada.

Balas dari MIGS

MasterCard tidak merespons bug ini di HMAC-SHA256. Saya menghubungi beberapa orang yang sebelumnya saya hubungi tentang kerentanan sebelumnya. Tidak ada jawaban. Bahkan berhenti berlangganan dengan gaya "kami mengujinya." Mereka memiliki Facebook saya jika mereka ingin menghubungi saya (karena korespondensi tentang MD5).

Beberapa tampaknya berpura-pura tidak melihat laporan saya, tetapi saya memasukkan kata sandi pada surat itu. Setidaknya ada 3 tampilan dari alamat IP MasterCard. Pada saat yang sama, ini bukan klik acak tanpa membaca, karena Anda perlu memasukkan kata sandi secara sadar. Saya menulis kepada mereka setiap minggu.

Harapan saya adalah mereka akan memperingatkan semua orang yang terhubung ke sistem mereka untuk memeriksa dan menyaring data yang disematkan.

Kesenjangan dalam Gateways Pembayaran

Selain itu, saya ingin mengatakan: terlepas dari kenyataan bahwa gateway pembayaran berurusan dengan uang, mereka tidak seaman kelihatannya. Selama pentest (tes penetrasi), saya menemukan beberapa kerentanan dalam protokol pembayaran di beberapa gateway perantara. Sayangnya, saya tidak bisa memberi tahu detailnya (jika saya mengatakan "terpendam", maka ini adalah sesuatu yang termasuk dalam perjanjian tanpa pengungkapan).

Saya juga menemukan kesalahan implementasi. Misalnya, serangan ekstensi hash, XML, kesalahan verifikasi tanda tangan, dll. Salah satu bug termudah yang saya temukan di Pembayaran Fusion. Bug pertama yang saya temukan adalah: mereka bahkan tidak memeriksa tanda tangan dari MIGS. Ini berarti bahwa kita dapat dengan mudah memodifikasi data yang dikembalikan oleh MIGS dan menandai transaksi sebagai berhasil. Ini hanya berarti mengubah satu karakter: dari F (tidak berhasil) menjadi 0 (berhasil).

Faktanya, kita dapat memasukkan nomor kartu apa saja, menerima respons yang salah dari MIGS, mengubahnya, dan tiba-tiba pembayarannya berhasil. Ini adalah perusahaan dengan anggaran 20 juta, dan saya menerima 400 dolar dari mereka. Ini bukan satu-satunya gateway pembayaran dengan kerentanan seperti itu, selama pentest saya, saya menemukan ini di gateway lain. Meskipun hadiah kecil, Pembayaran Fusion saat ini adalah satu-satunya gateway pembayaran yang saya hubungi, yang sangat jelas dalam program hadiahnya untuk bug yang ditemukan. Mereka menanggapi pesan saya dengan sangat cepat dan dengan cepat memperbaiki bug mereka.

Kesimpulan

Gateway pembayaran tidak seaman yang Anda pikirkan. Dengan hadiah rendah (dan dalam beberapa kasus saya menerima $ 0), saya bertanya-tanya berapa banyak orang yang telah mengeksploitasi kerentanan ini dalam gateway pembayaran.

Komentar dari penerjemah

Dari diri saya sendiri saya ingin menambahkan beberapa kata pada kesimpulan penulis penelitian ini. Pertama-tama, penelitian ini adalah peringatan dan seruan untuk berhati-hati terhadap penjual, karena kerentanan yang ditemukan menjadikan mereka sebagai korban pengganggu. Tetapi ada banyak bug lain yang dapat membahayakan pelanggan (pemegang kartu, pengguna sistem pembayaran, dll.). Hati-hati saat memasukkan informasi penagihan pribadi Anda di situs yang tidak diverifikasi. Lebih baik lagi, miliki kartu kredit terpisah yang Anda miliki, di mana akan ada jumlah persis yang Anda butuhkan untuk melakukan pembelian di Internet.

Pernahkah Anda menemukan bug dalam sistem pembayaran, atau mungkin Anda bahkan menjadi korban bug seperti itu? Bagikan pengalaman, pendapat, dan kiat Anda tentang cara melindungi diri dalam komentar. Semoga hari Anda menyenangkan dan berbelanja dengan aman.

Sebagai iklan. Promosi! Hanya sekarang mendapatkan hingga 4 bulan penggunaan gratis VPS (KVM) dengan drive khusus di Belanda dan Amerika Serikat (konfigurasi dari VPS (KVM) - E5-2650v4 (6 Cores) / 10GB DDR4 / 240GB SSD atau 4TB HDD / 1Gbps 10TB - $ 29 / bulan dan di atasnya, tersedia opsi dengan RAID1 dan RAID10) , analog penuh dari server khusus, saat memesan untuk periode 1-12 bulan, ketentuan tindakannya ada di sini, pelanggan yang ada bisa mendapatkan 2 bulan sebagai bonus!

Cara membangun infrastruktur gedung. kelas menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?