Celah OpenSSH di Linux Berbasis musl Buka Akses ke Akun Tanpa Kata Sandi

Peneliti keamanan Ozgun Kultekin mengungkap celah OpenSSH yang memungkinkan penyerang masuk ke akun Linux tertentu meski akun tersebut semestinya menolak login dengan kata sandi. Celah yang dijuluki *sshole ini muncul pada sistem berbasis pustaka musl, seperti Alpine Linux, dengan konfigurasi autentikasi tertentu. Perbaikan tersedia di OpenSSH 10.6p2.

Mengapa OpenSSH bisa menerima login yang seharusnya ditolak

Linux dapat menempatkan tanda bintang (*) pada kolom kata sandi di /etc/shadow untuk menandai akun tanpa hash yang dapat digunakan. Di sisi lain, fungsi crypt() pada musl juga dapat mengembalikan tanda bintang ketika proses hashing gagal, termasuk saat masukan melampaui batas panjang yang diterima.

Interaksi itu bermula dari perubahan OpenSSH pada 2016 untuk mengurangi perbedaan waktu respons yang bisa mengungkap keberadaan nama pengguna. OpenSSH tetap mencoba menghitung hash meski akun tidak punya hash yang dapat digunakan. Dalam kondisi yang rentan, hasil kegagalan dari musl cocok dengan tanda bintang yang tersimpan sehingga pemeriksaan dapat menerima login.

Konfigurasi yang membuat server rentan

Menurut Kultekin, celah ini memerlukan OpenSSH berbasis musl, autentikasi PAM yang nonaktif, dan autentikasi kata sandi SSH yang aktif. Setidaknya satu akun harus memiliki tanda bintang pada kolom hash dan akun lain harus memiliki hash yang valid. Debian, Ubuntu, dan Fedora yang memakai glibc serta sistem yang menggunakan PAM berada di luar cakupan skenario ini.

Peneliti juga menyoroti akun bawaan alpine pada image resmi Alpine untuk AWS dan Azure. Jika konfigurasi SSH memenuhi syarat eksploitasi, hak doas tanpa kata sandi pada akun tersebut dapat membuka jalan menuju akses root.

Pembaruan dan pemeriksaan log SSH

Administrator sistem terdampak dapat memasang OpenSSH 10.6p2 atau paket distribusi yang memuat perbaikannya. Jika pembaruan belum bisa dipasang, peneliti menyarankan menonaktifkan autentikasi kata sandi SSH dengan PasswordAuthentication no dan memuat ulang konfigurasi setelah memastikan akses alternatif tersedia.

Entri Accepted password pada log SSH untuk akun yang seharusnya hanya menerima autentikasi berbasis kunci patut diperiksa. Cocokkan temuan itu dengan status kolom kata sandi akun dan konfigurasi yang berlaku saat login terjadi.

Sumber: Ozgun Kultekin – *sshole