Pihak penyerang kini mampu menyusup dan masuk secara ilegal ke dalam akun-akun sistem yang sebenarnya tidak dikonfigurasikan dengan kata sandi, seperti misalnya akun yang secara eksklusif hanya memanfaatkan kunci otentikasi SSH, pada sejumlah server berbasis Alpine Linux yang memasang paket bawaan openssh-server resmi. Untuk melancarkan eksploitasi tersebut, aktor ancaman cuma memerlukan akses jaringan langsung ke arah mesin sasaran, mengetahui sebuah nama pengguna target, dan mengirimkan susunan kredensial kata sandi dengan ukuran rentang panjang antara 257 hingga 1.024 bita.
Pihak pengembang OpenSSH, yang secara formal melabeli tingkat keparahan insiden ini pada level kritis, telah menerbitkan pembaruan aplikasi versi 10.6p2 pada hari ini guna menutup celah keamanan bersangkutan. Pada saat yang sama, tim pengembang Alpine Linux juga telah menyalurkan perbaikan paket perangkat lunak tambalan komprehensif bagi seluruh rilis sistem operasi mereka hingga versi terdahulu 3.16.
Metode serangan ini dapat bekerja dengan sukses manakala komponen daemon server OpenSSH (dikenal sebagai sshd) memvalidasi kredensial pengguna tanpa melalui antarmuka Pluggable Authentication Module (PAM), fitur otentikasi kata sandi dibiarkan aktif, dan setidaknya ditemukan minimal satu akun lain pada lingkungan server tersebut yang memiliki sandi tersimpan. Paket openssh-server milik Alpine memang dikompilasi secara spesifik tanpa modul PAM, sementara mekanisme masuk menggunakan kata sandi dalam konfigurasi standarnya berada dalam status aktif.
Akar kegagalan pengamanan ini berpangkal dari cara sshd berinteraksi dengan musl, yaitu sebuah pustaka sistem bahasa C inti yang menjadi pondasi utama tempat Alpine dibangun. Berbagai sistem operasi di luar ekosistem Linux, mesin distribusi Linux standar yang mengandalkan pustaka glibc konvensional, serta sistem yang memverifikasi kata sandi memanfaatkan integrasi PAM dipastikan sepenuhnya aman dan tidak terpengaruh, demikian dipaparkan Damien Miller dari tim inti proyek OpenSSH.
Ia menegaskan instruksi tegas kepada setiap administrator yang mengelola sistem terdampak agar mengambil langkah taktis: “setel opsi PasswordAuthentication=no atau segera nonaktifkan total layanan SSH untuk perangkat-perangkat ini SECARA INSTAN.” Sejauh rilis keterangan ini diumumkan, belum tercatat satu pun insiden eksploitasi aktif di dunia nyata yang terdeteksi menyalahgunakan kerentanan tersebut.
Dokumen peringatan keamanan resmi milik Alpine menguraikan adanya empat kriteria utama. Kondisi suatu server dinyatakan rentan dan terekspos manakala keempat situasi berikut ini terpenuhi secara bersamaan:
Pelaku peretasan juga dipersyaratkan mengantongi nama akun yang tidak disetel kata sandinya. Kehadiran tepat satu akun pengguna lain yang menyimpan kata sandi sudah lebih dari cukup guna membahayakan dan mengekspos semua akun tanpa kata sandi di server itu. Aksi peretasan ini dipastikan selalu sukses pada setiap upaya awal dengan bermodalkan satu koneksi tunggal, sebagaimana tercantum dalam lembar pengumuman penasihat resmi.
Pada lingkungan operasi distribusi Alpine, beberapa golongan akun yang kerap dibiarkan tanpa adanya susunan sandi di antaranya meliputi:
Hak istimewa akun Root sejatinya tetap terlindungi secara bawaan oleh aturan konfigurasi PermitRootLogin prohibit-password dan cuma dapat ditembus langsung apabila nilai pengaturannya sengaja diubah menjadi PermitRootLogin yes. Kendati demikian, proteksi bawaan tersebut sama sekali tidak akan berdaya menolong apabila akun pengguna yang berhasil diretas memiliki izin khusus untuk meningkatkan hak akses menuju root, semisal memanfaatkan perkakas pembantu semacam utilitas doas.
Berkas citra sistem tiny-cloud pada rentang versi 3.18.11 hingga 3.24.3 memberikan akun pengguna alpine hak operasional doas tanpa sandi. Citra ini pada dasarnya berstatus aman saat pertama kali dihidupkan, namun langsung terbuka lebar terhadap serangan begitu ditemukan adanya hash dengan awalan tipe $6$ di dalam sistem, contohnya sesaat sehabis pengelola mengatur sandi konsol fisik. Pihak peretas kemudian leluasa membobol akun alpine dan mengeksekusi doas guna menguasai status administrator tertinggi.
Lingkungan peti kemas atau kontainer yang tidak menjalankan layanan sshd aktif, instalasi server dengan konfigurasi baku PasswordAuthentication bernilai no, serta citra awan yang diatur secara otomatis lewat utilitas cloud-init—yang secara default langsung menanamkan aturan nonaktif tersebut—dipastikan bebas dari ancaman celah ini. Akun yang sengaja dikunci memakai tanda ! pada berkas /etc/shadow juga aman, begitu pula server di mana tidak ada satupun akun yang memuat format hash sandi bergaya simbol dollar.
Lingkup kelemahan perangkat lunak ini rupanya tidak semata terbatas pada sistem operasi Alpine saja. Özgün Kültekin dari Wakefield, sosok penemu yang pertama kali melaporkan masalah ini, menuliskan nama sistem OpenWrt, Buildroot, dan platform Yocto di dalam dokumen analisis teknisnya sebagai sistem lain berbasis musl yang wajib diawasi dan diteliti.
Sistem jaringan OpenWrt pada konfigurasi standarnya mengelola koneksi SSH melalui implementasi Dropbear, seperti yang dibuktikan dalam dokumentasi panduan Dropbear miliknya, dan Kültekin mengonfirmasi bahwa Dropbear sama sekali kebal terhadap permasalahan ini. Pada ekosistem OpenWrt, kerentanan praktis baru bisa bermasalah jikalau seorang pengelola sengaja mengunduh serta memasang server OpenSSH menggantikan aplikasi bawaan.
Bagi para pengguna sistem Alpine, tata cara mitigasi yang wajib dikerjakan yakni memperbarui paket ke versi terbaru disusul tindakan memuat ulang layanan, sebab tindakan pembaruan repositori paket tidak secara otomatis me-restart daemon sshd yang masih berjalan:
Edisi pembaruan bertingkat yang mencakup rilis 3.21.10, 3.22.8, 3.23.8, serta rilis 3.24.4 sudah menyertakan paket yang tertambal secara langsung. Jalur cabang lawas mulai versi 3.16 sampai 3.21 yang sejatinya telah melewati siklus masa dukungan resmi tercatat turut memperoleh rilis paket perbaikan darurat ini.
Seluruh instans komputasi awan yang dihidupkan dari citra sistem tiny-cloud dengan versi lebih lawas dari rilis-rilis tambalan tersebut tetap mutlak memerlukan proses pengkinian manual, atau menerapkan modifikasi penyesuaian parameter konfigurasi yang dijelaskan di bawah ini.
Apabila Anda mengompilasi dan membangun paket biner OpenSSH secara mandiri dari kode sumber, paket versi rilis 10.6p2 telah menyematkan penyesuaian kode penting ini, sebagaimana telah dipaparkan dalam dokumen catatan perilisannya.
Jikalau lingkungan Anda belum memungkinkan untuk segera melakukan instalasi pembaruan perangkat lunak, mematikan seluruh alur masuk berbasis sandi secara total merupakan trik efektif menghentikan vektor penyerangan. Pertama-tama pastikan akses memakai kunci privat SSH bekerja baik, dan jangan tutup sesi terminal aktif saat ini hingga login baru berhasil diverifikasi. Lantas pasang baris instruksi PasswordAuthentication bernilai no, jalankan pengujian sintaks berkas lewat perintah sshd -t, lalu muat ulang layanan sshd.
Lembar advisory menyediakan deretan perintah terstruktur untuk menambahkan aturan pembatasan di dalam berkas direktori drop-in /etc/ssh/sshd_config.d, di mana struktur bawaan Alpine telah mendukung pembacaan direktori ini sejak rilis 3.19 ke atas. Baris perintah tersebut pun memastikan pergantian semua deklarasi baris PasswordAuthentication pada berkas induk /etc/ssh/sshd_config dari semula berstatus yes menjadi no, termasuk perintah yang berada di lingkup blok Match. Setelah proses tuntas, perintah pengecekan sshd -T | grep -i passwordauthentication wajib menghasilkan keluaran tulisan berupa passwordauthentication no.
Pihak penyedia dokumen keamanan menyarankan agar para administrator memeriksa teliti berkas catatan pada /var/log/messages demi menemukan indikasi kemunculan baris catatan sshd bertuliskan Accepted password pada akun yang semestinya tanpa sandi, seperti akun alpine, root, atau entitas pemakai berbasis kunci privat. Pada perangkat yang dicurigai terekspos, telusuri rekam jejak utilitas doas, pemakai baru yang tiba-tiba dibuat, berkas tak dikenal, serta isi file authorized keys.
“Jika Anda tidak dapat memastikan keabsahan suatu riwayat sesi masuk secara pasti, perlakukan segera mesin komputer tersebut sebagai sistem yang telah sepenuhnya terkompromi,” demikian bunyi peringatan resminya.
Alasan Mengapa Sandi Berukuran Panjang Bisa Bekerja
Ketika beroperasi tanpa keberadaan fasilitas PAM, server sshd berkewajiban melakukan verifikasi keaslian kata sandi secara independen. Komponen server bakal meramu nilai tebakan menggunakan fungsi crypt(), yakni sebuah fungsi bawaan pustaka bahasa C yang mentransmisikan masukan kata sandi menjadi bentuk deretan hash tersimpan, sebelum akhirnya membandingkan hasil enkripsi tersebut dengan string data yang tersimpan pada sistem.
Suatu akun tanpa pengaturan sandi lazimnya hanya memiliki simbol tanda bintang (*) tunggal pada kolom penyimpanan data sandinya. Isian tersebut tentu terlampau ringkas untuk dapat menampung elemen salt, yaitu komponen prefiks acak unik penghasil hash, sehingga mekanisme sshd terpaksa meminjam susunan salt dari akun pengguna lain yang menyimpan hash valid nyata.
Pada algoritma pemrosesan hash kategori jenis $5$ dan $6$, fungsi crypt() di dalam pustaka musl secara tegas menolak pemrosesan untaian kata sandi yang melampaui ambang batas volume 256 bita serta otomatis menghasilkan keluaran tanda bintang (*) guna mengindikasikan status galat penolakan. Masalah fatalnya, nilai tanda bintang (*) akibat galat itu justru cocok identik dengan data bertanda bintang (*) yang tersimpan di profil akun, sehingga sshd keliru menganggap login sukses. Batas tertinggi muatan panjang ini dibatasi kapasitas internal sshd yang membatasi kredensial hingga 1.024 bita.
Perilaku keliru dari implementasi fungsi ini berakar dari modifikasi kode pada musl tertanggal 9 Agustus 2012 silam, yang dulunya sengaja mengatur agar kegagalan instruksi crypt() mengeluarkan respons “string hash yang mustahil cocok ketimbang mengembalikan status NULL” akibat banyaknya aplikasi yang luput mengecek nilai kesalahan. Kebijakan batasan ambang 256 bita menyusul disahkan pada tanggal 29 Agustus 2012 guna mencegah risiko kelumpuhan peladen dari ancaman serangan denial-of-service.
Sedangkan rutinitas teknis peminjaman salt dari pengguna lain sejatinya bermula dari pembaruan OpenSSH bertanggal 15 Juli 2016 yang kala itu dirancang khusus menutup lubang CVE-2016-6210, sebuah insiden kelemahan yang memungkinkan pihak luar menebak ketersediaan nama pengguna valid di server. Kültekin menjelaskan bahwa celah kombinasi ini praktis telah eksis mengintai sejak masa perubahan tersebut diresmikan.
Melalui modifikasi kode pada versi 10.6p2 teranyar, pengembang sshd menambahkan logika penyaring yang secara ketat menolak proses pencocokan sandi apabila kolom karakter data yang tersimpan berukuran kurang dari empat karakter. Pihak OpenSSH menyebut solusi ini sekadar penanganan sementara (workaround) dan berargumen akar persoalan mendasar sejatinya bersumber di luar ranah sshd. Sejalan dengan hal itu, paket stabil Alpine turut menyertakan tambalan internal guna menanggulangi kendala identik.
Pemicu Diterbitkannya Perbaikan Cepat dalam Tempo Satu Hari
Divisi pengembang yang dipimpin oleh Miller menerima pemberitahuan mengenai keberadaan cacat fungsional ini pada awal pekan dan langsung bergerak merilis paket pemulihan secepat kapabilitas yang mereka miliki. Pada keterangan rilis tertulisnya, ia menegaskan bahwa tim pengembang saat ini memandang penundaan masa embargo informasi yang berkepanjangan sangatlah membahayakan dan condong menguntungkan kubu penyerang jahat, sebab akhir-akhir ini mereka kerap mendapati agen kecerdasan buatan (AI) sanggup menemukan kembali jenis bug yang serupa secara independen, adakalanya hanya dalam hitungan jam saja.
Sampai informasi rilis penanggulangan ini resmi digulirkan ke ranah publik hari ini, belum ada satupun nomor registrasi tanda pengenal kerentanan resmi (kode identifikasi CVE) yang diterbitkan secara khusus bagi insiden tersebut.
About the Author
