Para penulis artikel ini menentang mekanisme enkripsi kunci standar di OpenSSH.Penyerang baru-baru ini menggunakan paket npm eslint-scope untuk mencuri token npm dari direktori home user. Mengingat peristiwa ini, kami mulai memeriksa kerentanan serupa lainnya dan berpikir tentang cara mengurangi risiko dan konsekuensi dari insiden semacam itu.
Sebagian besar dari kita memiliki kunci SSH RSA di tangan. Kunci ini memberi pemilik beragam hak istimewa: sebagai aturan, ia digunakan untuk mengakses lingkungan produksi atau di GitHub. Tidak seperti token nmp, kunci SSH dienkripsi, dan karena itu secara umum diterima bahwa tidak ada hal buruk yang akan terjadi, bahkan jika mereka jatuh ke tangan yang salah. Tapi benarkah begitu? Ayo cari tahu.
user@work /tmp $ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): mykey
...
user@work /tmp $ head -n 5 mykey
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,CB973D5520E952B8D5A6B86716C6223F
+5ZVNE65kl8kwZ808e4+Y7Pr8IFstgoArpZJ/bkOs7rB9eAfYrx2CLBqLATk1RT/
Kunci ini dienkripsi, seperti yang ditunjukkan oleh salah satu baris pertama file. Selain itu, pada awalnya tidak ada kunci penyandian MII - base64 yang digunakan dalam RSA. Dan, tentu saja, AES menarik perhatian Anda! Itu bagus, kan? Dan CBC, sekilas, dengan vektor inisialisasi acak. Tidak ada kode otentikasi (MAC). Kalau begitu, tidak akan ada serangan padding oracle, kan?
Mencari tahu apa arti sebenarnya dari isi DEK-Info tidak sesederhana itu. Pencarian untuk kata kunci “DEK-Info” di repositori openssh-portable hanya menunjukkan contoh kunci. Tapi intinya di sini adalah bahwa kunci AES tidak lebih dari hash MD5 sederhana (kata sandi || inisialisasi vektor [: 8]). Dan ini buruk, karena praktik terbaik untuk menyimpan kata sandi mengatakan bahwa kata sandi dalam bentuk murni mereka, karena entropinya yang rendah, adalah bahan enkripsi yang buruk. Dan untuk membuatnya lebih baik, Anda memerlukan fungsi yang mahal seperti Argon2. Tetapi MD5, tidak seperti yang terakhir, mudah untuk dihitung.
Satu-satunya poin positif dalam skema ini adalah bahwa garam diletakkan setelah kata sandi, oleh karena itu, tidak akan berfungsi untuk menghitung status perantara MD5 (IV [8:]) dan menemukan kata sandi berdasarkan itu. Tapi ini sedikit penghiburan, terutama di era di mana mesin yang menghasilkan miliaran panggilan MD5 per detik tersedia untuk kita - lebih banyak daripada yang bisa dihasilkan oleh kata sandi.
Anda mungkin bertanya-tanya bagaimana OpenSSH hidup untuk melihat ini. Sayangnya, jawabannya sederhana: alat baris perintah OpenSSL awalnya menggunakan skema ini, dan itu hanya menjadi norma.
Pada akhirnya, menjadi benar bahwa kunci standar yang dienkripsi dengan kata sandi tidak lebih baik daripada kunci tidak terenkripsi biasa hanya karena mekanisme enkripsi tidak efektif. Namun, kami akan berbicara lebih berani - mereka lebih buruk. Dan mudah untuk berdebat.
Banyak orang tidak mungkin menggunakan pengelola kata sandi untuk menyimpan kata sandi untuk kunci SSH. Sebaliknya, pengguna hanya akan mengingatnya. Dan, karena ini adalah salah satu kombinasi yang dihafalkan, kemungkinan pengguna telah menggunakannya di tempat lain. Mungkin bahkan cocok dengan kata sandi pengguna dari perangkat. Sangat mungkin untuk menebaknya (fungsi formatifnya terlalu tidak bisa diandalkan), dan jika kata sandi diketahui, Anda mungkin dapat memeriksanya dengan kunci publik.
Tidak ada keluhan tentang pasangan kunci RSA itu sendiri: satu-satunya pertanyaan adalah metode enkripsi simetris kunci pribadi. Tidak mungkin melakukan serangan yang dijelaskan di atas, hanya mengetahui kunci publik.
Bagaimana saya bisa memperbaiki situasi?
OpenSSH menyediakan format kunci baru untuk digunakan. Yang baru dimaksud diperkenalkan pada 2013. Format ini menggunakan bcrypt_pbkdf, yang pada dasarnya adalah bcrypt dengan kompleksitas tetap yang diterapkan di bawah standar PBKDF2.
Mudah, Anda secara otomatis menerima kunci dalam format baru ketika membuat kunci Ed25519, karena format kunci SSH lama tidak mendukung jenis kunci yang lebih baru. Ini agak aneh, karena sebenarnya kita tidak benar-benar membutuhkan format kunci untuk menentukan bagaimana serialisasi Ed25519 bekerja, karena Ed25519 sendiri yang mengatur serialisasi berfungsi. Tetapi jika Anda benar-benar membutuhkan fungsi formatif yang baik, maka Anda tidak bisa repot dengan hal sepele seperti itu. Akibatnya, salah satu jawabannya adalah
ssh-keygen -t ed25519 .
Jika, karena alasan kompatibilitas, Anda harus mematuhi RSA, Anda dapat menggunakan ssh-keygen -o. Dengan demikian, format baru dapat diperoleh bahkan untuk jenis kunci lama. Anda dapat memperbarui kunci lama dengan perintah
ssh-keygen -p -o -f nama kunci . Jika kunci Anda tinggal di Yubikey atau kartu pintar, maka amandemen ini sudah diperhitungkan.
Dengan satu atau lain cara, kami berupaya untuk keluar yang lebih optimal. Di satu sisi, ada contoh yang baik dari aws-vault, di mana informasi kredensial dipindahkan dari disk ke gantungan kunci. Ada pendekatan lain: memindahkan pengembangan ke lingkungan bersama. Akhirnya, sebagian besar startup harus mempertimbangkan untuk meninggalkan penyimpanan jangka panjang kunci SSH dan pindah ke pusat sertifikasi SSH dengan waktu penyimpanan kunci yang terbatas ditambah dengan sistem masuk tunggal. Sayangnya, dalam kasus GitHub, pendekatan ini tidak memungkinkan.
PS Sulit untuk memverifikasi informasi ini dalam sumber otoritatif, tetapi jika memori melayani kami dengan baik, parameter versi dalam kunci pribadi format OpenSSH PEM hanya memengaruhi metode enkripsi. Namun, ini tidak memainkan peran apa pun: masalahnya adalah fungsi pembentukan kunci, dan kami pikir ini adalah argumen lain yang tidak membahas protokol di beberapa bagian. Akan ada posting terpisah tentang topik ini di blog kami.
Dan akhirnya -
tautan ke kunci lengkap. Ini kalau-kalau Anda diatur untuk meretas apa pun hari ini.
