A2 : 2021 - Cryptographic Failures

Cryptographic Failures

Kegagalan kriptografi mengacu pada kerentanan apa pun yang timbul akibat penyalahgunaan (atau kurangnya penggunaan) algoritma kriptografi untuk melindungi informasi sensitif. Aplikasi web memerlukan kriptografi untuk memberikan kerahasiaan bagi penggunanya di berbagai tingkatan.

Ambil contoh, aplikasi email yang aman:
. Saat mengakses akun email menggunakan browser, Anda ingin memastikan bahwa komunikasi antara Anda dan server dienkripsi. Dengan demikian, penyadap mana pun yang mencoba menangkap paket jaringan Anda tidak akan dapat memulihkan konten alamat email Anda. Saat kami mengenkripsi lalu lintas jaringan antara klien dan server, kami biasanya menyebutnya sebagai encrypting data in transit.
. Karena email Anda disimpan di beberapa server yang dikelola oleh penyedia layanan Anda, sebaiknya penyedia layanan email tidak dapat membaca email klien mereka. Untuk tujuan ini, email Anda mungkin juga dienkripsi saat disimpan di server. Ini disebut sebagai encrypting data at rest.

Kegagalan kriptografi sering kali mengakibatkan aplikasi web secara tidak sengaja membocorkan data sensitif. Data ini sering kali terkait langsung dengan pelanggan (misalnya nama, tanggal lahir, informasi keuangan), tetapi bisa juga berupa informasi yang lebih teknis, seperti nama pengguna dan kata sandi.

Pada tingkat yang lebih kompleks, memanfaatkan beberapa kegagalan kriptografi sering kali melibatkan teknik seperti "Man in The Middle Attacks", di mana penyerang akan memaksa koneksi pengguna melalui perangkat yang mereka kendalikan. Kemudian, mereka akan memanfaatkan enkripsi yang lemah pada setiap data yang dikirimkan untuk mengakses informasi yang dicegat (jika data tersebut dienkripsi sejak awal). Tentu saja, banyak contoh yang jauh lebih sederhana, dan kerentanan dapat ditemukan di aplikasi web yang dapat dieksploitasi tanpa pengetahuan jaringan tingkat lanjut. Memang, dalam beberapa kasus, data sensitif dapat ditemukan langsung di server web itu sendiri.

Cara paling umum untuk menyimpan sejumlah besar data dalam format yang mudah diakses dari banyak lokasi adalah dalam basis data. Ini sangat cocok untuk aplikasi web, karena banyak pengguna dapat berinteraksi dengan situs web kapan saja. Mesin basis data biasanya mengikuti sintaksis Structured Query Language ( SQL ).

Dalam lingkungan produksi, umum untuk melihat database yang disiapkan pada server khusus yang menjalankan layanan database seperti MySQL atau MariaDB; namun, database juga dapat disimpan sebagai file. Ini disebut sebagai database "flat-file", karena disimpan sebagai satu file di komputer. Ini jauh lebih mudah daripada menyiapkan seluruh server database dan berpotensi terlihat dalam aplikasi web yang lebih kecil. Mengakses server database berada di luar cakupan tugas saat ini, jadi mari kita fokus pada database flat-file.

Seperti yang disebutkan sebelumnya, basis data flat-file disimpan sebagai file pada disk komputer. Biasanya, ini tidak akan menjadi masalah untuk aplikasi web, tetapi apa yang terjadi jika basis data disimpan di bawah direktori root situs web (yaitu salah satu file yang dapat diakses oleh pengguna yang terhubung ke situs web)? Nah, kita dapat mengunduhnya dan menanyakannya di komputer kita sendiri, dengan akses penuh ke semua yang ada di basis data. Benar-benar Paparan Data Sensitif!

Format paling umum (dan paling sederhana) dari basis data flat-file adalah basis data SQLite. Basis data ini dapat digunakan dalam sebagian besar bahasa pemrograman dan memiliki klien khusus untuk meminta kueri pada baris perintah. Klien ini disebut sqlite3 dan diinstal pada banyak distribusi Linux secara default.

user@linux$ ls -l
user@linux$ file example.db
Kita dapat melihat bahwa ada database SQLite di folder saat ini.

Untuk mengaksesnya, kami menggunakan sqlite3 [database-name]:
user@linux$ sqlite3 example.db

Dari sini, kita dapat melihat tabel dalam database dengan menggunakan .tables perintah:
Pada titik ini, kita dapat membuang semua data dari tabel, tetapi kita belum tentu tahu apa arti setiap kolom kecuali kita melihat informasi tabel. Pertama, mari kita gunakan
PRAGMA table_info(customers); untuk melihat informasi tabel. Kemudian kita akan menggunakan
SELECT * FROM customers; untuk membuang informasi dari tabel:
Kita dapat melihat dari informasi tabel bahwa ada empat kolom: custID, custName, creditCard dan password. Anda mungkin memperhatikan bahwa ini cocok dengan hasilnya. Ambil baris pertama:

0|Joy Paulson|4916 9012 2231 7905|5f4dcc3b5aa765d61d8327deb882cf99
Kami memiliki custID (0), custName (Joy Paulson), kartu kredit (4916 9012 2231 7905) dan hash kata sandi (5f4dcc3b5aa765d61d8327deb882cf99).

Kita telah melihat cara mengkueri database SQLite untuk data sensitif pada tugas sebelumnya. Kita menemukan kumpulan hash kata sandi, satu untuk setiap pengguna. Dalam tugas ini, kita akan membahas secara singkat cara memecahkannya.

Jika berbicara tentang peretasan hash, Kali telah dilengkapi dengan berbagai alat yang sudah terpasang sebelumnya. Jika Anda tahu cara menggunakannya, silakan saja; namun, alat-alat tersebut berada di luar cakupan materi ini.

Sebagai gantinya, kita akan menggunakan alat daring: Crackstation . Situs web ini sangat bagus dalam memecahkan hash kata sandi yang lemah. Untuk hash yang lebih rumit, kita memerlukan alat yang lebih canggih; namun, semua hash kata sandi yang dapat dipecahkan yang digunakan dalam tantangan hari ini adalah hash MD5 yang lemah , yang seharusnya dapat ditangani dengan sangat baik oleh Crackstation.

Mari kita coba menempelkan hash kata sandi untuk Joy Paulson, yang kita temukan di tugas sebelumnya ( 5f4dcc3b5aa765d61d8327deb882cf99). Kita selesaikan Captcha, lalu klik tombol "Crack Hashes":

Perlu dicatat bahwa Crackstation bekerja menggunakan daftar kata yang sangat banyak. Jika kata sandi tidak ada dalam daftar kata, maka Crackstation tidak akan dapat memecahkan hash.

Contoh
-https://[IP]/assets/example.db
-https://[IP]/config/config.json
-https://[IP]/scripts/encryptor.py
-https://[IP]/logs/access.log
-https://[IP]/certificates/old_cert.pem

tags