Pihak penyerang kini dilaporkan memiliki kemampuan untuk menyusup serta masuk secara ilegal ke dalam akun-akun sistem yang sama sekali tidak memiliki kata sandi, seperti halnya akun yang hanya mengandalkan kunci SSH semata, pada sejumlah peladen Alpine Linux tertentu yang menjalankan paket standar openssh-server. Untuk melancarkan tindakan eksploitasi tersebut, pelaku kejahatan siber hanya membutuhkan konektivitas atau akses jaringan terarah langsung menuju ke peladen target, mengetahui nama akun yang dituju, serta menyiapkan kiriman rentetan kata sandi khusus yang berukuran panjang antara 257 byte hingga mencapai 1.024 byte.
Tim pengembang OpenSSH, yang mengkategorikan serta menilai celah keamanan berbahaya ini pada level kritis, telah secara resmi meluncurkan rilis versi 10.6p2 pada hari ini guna menutup serta memblokir celah tersebut. Pada saat yang bersamaan, tim pengelola proyek Alpine Linux juga telah menerbitkan pembaruan paket perbaikan menyeluruh yang mencakup setiap edisi rilis terdahulu mereka ke belakang sampai ke versi 3.16.
Mekanisme serangan siber ini dapat bekerja secara efektif saat daemon peladen OpenSSH (sshd) melakukan proses validasi dan pemeriksaan kata sandi tanpa memanfaatkan perantara antarmuka Pluggable Authentication Module (dikenal sebagai PAM), opsi autentikasi login menggunakan kata sandi dibiarkan aktif, serta setidaknya terdapat satu akun pengguna lain di dalam mesin peladen yang memiliki kata sandi aktif tersimpan. Paket openssh-server bawaan pada sistem operasi Alpine Linux sendiri memang secara baku dibangun tanpa disertai dukungan modul PAM, ditambah lagi pengaturan opsi autentikasi login kata sandi secara default selalu berada dalam keadaan menyala.
Kerentanan keamanan yang mencuat ini pada dasarnya berakar langsung dari bagaimana cara kerja sshd saat berinteraksi bersama musl, yakni pustaka dasar C (standard C library) yang menjadi fondasi utama pembangunan sistem Alpine Linux. Sistem operasi di luar keluarga Linux, seluruh sistem Linux yang dikompilasi memakai pustaka standar glibc, maupun beraneka sistem yang mengeksekusi pemeriksaan kata sandi lewat mekanisme PAM dipastikan sama sekali tidak terdampak oleh masalah ini, sebagaimana disampaikan secara resmi oleh Damien Miller yang merupakan perwakilan dari proyek pengembang OpenSSH.
Melalui keterangannya, Miller memberikan peringatan keras sekaligus instruksi kepada siapa pun pihak administrator yang saat ini mengoperasikan sistem terdampak untuk segera mengambil tindakan pencegahan dengan cara “menyetel nilai opsi PasswordAuthentication=no atau segera menonaktifkan layanan SSH untuk sistem-sistem tersebut SECEPATNYA.” Hingga kabar pembaruan darurat ini dipublikasikan secara luas, belum ada temuan maupun laporan insiden eksploitasi serangan siber di dunia nyata yang memanfaatkan celah keamanan tersebut.
Lembar pengumuman penasihat keamanan resmi dari Alpine Linux secara gamblang merinci adanya empat buah kondisi teknis utama. Sebuah instalasi peladen dinyatakan berada dalam status rentan dan terbuka secara penuh terhadap potensi eksploitasi berbahaya hanya jika keempat parameter prasyarat ini terpenuhi secara bersamaan:
Selain kondisi teknis tadi, sang peretas juga tetap harus mengetahui secara pasti identitas nama akun pengguna yang tidak dilengkapi dengan perlindungan kata sandi. Keberadaan satu akun lain saja yang memiliki kata sandi sah sudah terbukti lebih dari cukup untuk membuat seluruh akun tanpa sandi di dalam mesin tersebut terekspos bahaya secara massal. Berdasarkan penjelasan mendalam dari dokumen penasihat keamanan terkait, serangan ini dipastikan bakal selalu berhasil dalam setiap percobaan eksekusi hanya melalui satu sesi sambungan jaringan tunggal.
Dalam ekosistem lingkungan sistem operasi Alpine Linux, sejumlah akun pengguna yang pada umumnya terkonfigurasi tanpa penyetelan kata sandi antara lain meliputi:
Akun administrator utama yakni root pada dasarnya masih mendapatkan proteksi perlindungan baku melalui penerapan parameter bawaan PermitRootLogin prohibit-password, sehingga akun tertinggi ini hanya bisa diakses dan ditembus secara langsung apabila pengelola sistem sengaja mengubah konfigurasi menjadi PermitRootLogin yes. Kendati demikian, skema perlindungan baku tersebut sama sekali tidak akan banyak membantu apabila akun pengguna biasa yang berhasil diretas dan dieksploitasi ternyata memiliki wewenang atau hak akses khusus untuk bertransisi naik menjadi akun root, sebagai contoh misalnya melalui fasilitas utilitas doas.
Citra mesin tiny-cloud untuk edisi distribusi versi 3.18.11 hingga varian 3.24.3 diketahui memberikan izin akses istimewa doas tanpa sandi kepada akun pengguna bawaan bernama alpine. Konfigurasi citra mesin awan ini sebetulnya masih tergolong aman pada saat proses booting pertama kali dijalankan, namun status keamanannya akan langsung berubah menjadi sangat terbuka terhadap serangan seketika hash kata sandi berjenis $6$ mulai tercipta dan tersimpan di dalam sistem, seperti halnya ketika seorang administrator sistem mulai mengatur sebuah kata sandi konsol baru. Dalam skenario tersebut, peretas dapat dengan leluasa masuk memanfaatkan akun alpine lalu mengeksekusi perintah doas untuk mengambil alih kendali sistem sebagai pengguna root sepenuhnya.
Di lain sisi, lingkungan peti kemas kontainer yang tidak mengaktifkan dan menjalankan proses sshd di dalamnya, peladen yang sudah dikonfigurasi menggunakan aturan PasswordAuthentication no secara eksplisit, serta aneka citra lingkungan cloud yang diatur otomatis lewat modul cloud-init (yang secara baku langsung menyuntikkan konfigurasi penonaktifan sandi tersebut) dipastikan aman terbebas dari kerentanan ini. Akun-akun yang sengaja dikunci rapat menggunakan penanda tanda seru (!) pada berkas /etc/shadow juga sama sekali tidak terpengaruh, begitu juga terhadap mesin-mesin peladen yang tidak memiliki satu pun akun dengan nilai hash kata sandi yang berawalan simbol tanda dolar ($).
Permasalahan keamanan yang cukup rumit ini nyatanya tidak semata-mata terbatas hanya pada ekosistem distribusi Alpine Linux saja. Sosok peneliti keamanan bernama Özgün Kültekin dari Wakefield, yang tercatat sebagai pihak pertama yang menemukan sekaligus melaporkan keberadaan celah kritis ini, secara spesifik mencantumkan nama-nama platform lain seperti OpenWrt, Buildroot, serta Yocto di dalam laporan analisa teknisnya sebagai deretan sistem lain berbasis pustaka musl yang wajib segera diperiksa keamanannya.
Perangkat yang menjalankan sistem operasi OpenWrt sendiri pada konfigurasi standarnya mengelola dan menangani seluruh sambungan komunikasi SSH menggunakan paket piranti lunak alternatif Dropbear secara baku, sebagaimana dipaparkan di dalam lembar petunjuk panduan dokumentasi resmi Dropbear milik mereka, dan Kültekin menegaskan bahwa piranti lunak Dropbear tersebut sama sekali tidak terjangkit masalah ini. Dengan demikian, di dalam platform OpenWrt, risiko munculnya celah kritis ini murni hanya akan berdampak apabila administrator perangkat memang sengaja memasang dan mengoperasikan paket OpenSSH server secara mandiri di dalamnya.
Bagi para administrator yang mengelola sistem operasi Alpine Linux, langkah penanganan dan penuntasan masalah ini dapat dilakukan dengan memperbarui paket piranti lunak yang bersangkutan kemudian dilanjutkan dengan melakukan tindakan restart secara manual, mengingat prosedur pemutakhiran paket instalasi sistem pada dasarnya tidak akan memicu dimulainya ulang proses daemon sshd yang tengah beroperasi aktif di latar belakang:
Edisi pembaruan rilis minor yang mencakup versi 3.21.10, kemudian 3.22.8, rilis 3.23.8, hingga versi 3.24.4 dilaporkan telah memuat paket aplikasi yang sudah diperbaiki secara langsung di dalamnya. Menariknya lagi, sejumlah cabang pengembangan versi lama seperti dari seri 3.16 hingga 3.21, yang status dukungannya sebenarnya telah resmi berakhir atau melewati masa end of support, tetap memperoleh pasokan paket perbaikan keamanan khusus ini demi menjamin proteksi para pengguna setia mereka.
Sementara itu, bagi instans komputasi awan yang awalnya dibangun atau diaktifkan dari fondasi citra sistem tiny-cloud dengan versi yang lebih lawas daripada varian rilis minor perbaikan di atas, maka sistem tersebut mutlak tetap membutuhkan instalasi pembaruan segera, atau setidaknya wajib mengaplikasikan penyesuaian aturan konfigurasi mitigasi darurat sebagaimana diterangkan di bawah.
Apabila Anda terbiasa membangun atau mengompilasi sendiri seluruh paket piranti lunak OpenSSH secara independen dari sumber aslinya, maka versi rilis 10.6p2 telah secara utuh menyertakan modifikasi kode perbaikan keamanan ini di dalamnya, sebagaimana dijelaskan secara terperinci di dalam lembaran catatan rilis resmi proyek piranti lunak tersebut.
Bagi administrator sistem yang saat ini masih menghadapi kendala teknis sehingga belum memungkinkan untuk segera mengaplikasikan pembaruan paket secara langsung, menonaktifkan opsi autentikasi login menggunakan kata sandi merupakan metode mitigasi efektif lain yang terbukti ampuh membendung skema serangan ini seketika. Namun sebelum melangkah lebih jauh, pastikan terlebih dahulu bahwa metode login berbasis kunci kriptografi SSH key Anda telah teruji berfungsi dengan normal tanpa hambatan, serta selalu pertahankan sesi sambungan konsol terminal aktif Anda tetap terbuka sampai proses verifikasi login di jendela sesi baru berhasil dilakukan. Setelah kondisi aman terkonfirmasi, setel konfigurasi PasswordAuthentication no, periksa keabsahan sintaks tata bahasa berkas konfigurasi melalui perintah evaluasi sshd -t, lantas segera muat ulang layanan daemon sshd sistem Anda.
Panduan penasihat keamanan resmi tersebut turut memberikan serangkaian instruksi baris perintah praktis untuk menambahkan baris aturan setelan baru tersebut ke dalam berkas konfigurasi drop-in tambahan di direktori /etc/ssh/sshd_config.d, yang mana struktur berkas ini telah menjadi standar baku pembacaan konfigurasi di lingkungan sistem Alpine Linux semenjak rilis versi 3.19 ke atas. Rangkaian instruksi tersebut juga bertugas mengganti setiap keberadaan baris bertuliskan PasswordAuthentication di dalam berkas konfigurasi sentral /etc/ssh/sshd_config yang semula bernilai yes agar beralih menjadi no secara menyeluruh, termasuk penyesuaian pada baris-baris opsi yang terletak di dalam blok Match. Sebagai langkah pengujian akhir, perintah pengecekan sshd -T | grep -i passwordauthentication idealnya harus menampilkan keluaran string konfirmasi berupa passwordauthentication no.
Lebih lanjut lagi, dokumen penasihat keamanan tersebut merekomendasikan para pengelola server untuk melakukan audit mendalam terhadap isi catatan berkas /var/log/messages guna menyisir kemungkinan adanya rekaman log aktivitas sshd mencurigakan yang berbunyi Accepted password untuk nama-nama akun pengguna yang semestinya tidak mengantongi kata sandi sah, seperti halnya pengguna alpine, akun root, atau akun-akun yang murni berbasis kunci SSH. Khusus bagi mesin peladen yang terindikasi sempat terbuka terhadap potensi celah ini, sangat dianjurkan pula untuk mengevaluasi riwayat pemakaian perintah doas, mencermati pembuatan akun-akun pengguna baru yang mencurigakan, memeriksa keabsahan integritas berkas sistem, serta meneliti kejanggalan pada daftar kunci otentikasi authorized keys.
Pihak pengelola secara lugas menegaskan sebuah peringatan serius: “Jika Anda tidak dapat memastikan atau mengesampingkan terjadinya insiden login tanpa izin, maka anggaplah mesin tersebut telah berhasil diretas dan disusupi sepenuhnya,” demikian pernyataan tegas penasihat keamanan tersebut.
Mengapa Kata Sandi Berukuran Panjang Mampu Menembus Sistem
Ketika peladen beroperasi tanpa kehadiran dukungan modul PAM, layanan daemon sshd dituntut untuk memproses dan menguji validitas kata sandi pengguna secara independen dan mandiri. Komponen server ini akan memproses upaya autentikasi kata sandi tersebut melalui fungsi hash crypt(), yakni fungsi bawaan dari pustaka bahasa C yang berfungsi mengonversi untaian kata sandi mentah menjadi bentuk terenkripsi yang siap disimpan di dalam catatan basis data, untuk selanjutnya mencocokkan hasil enkripsi tersebut dengan isi kolom data sandi yang telah tersimpan sebelumnya di dalam berkas kredensial sistem.
Pada akun-akun pengguna yang sedari awal memang tidak dikonfigurasi memiliki kata sandi, bagian kolom penyimpanan hash kredensial tersebut biasanya hanya akan terisi oleh sebuah karakter bintang tunggal (*) saja. Format karakter tunggal semacam ini tentu saja terlampau pendek untuk dapat memuat sebuah nilai salt, yakni deretan karakter acak yang mutlak dibutuhkan sebagai awalan pengacak hash, sehingga daemon sshd secara otomatis akan berinisiatif meminjam struktur nilai salt milik akun pengguna lain di dalam sistem yang kebetulan telah memiliki hash sandi sungguhan yang valid.
Dalam skenario pengolahan format tipe hash modern seperti jenis $5$ maupun varian $6$, fungsi algoritma crypt() milik pustaka musl secara tegas akan menolak pemrosesan setiap masukan kata sandi yang panjangnya melampaui ambang batas 256 byte, dan sebagai konsekuensinya fungsi ini akan mengembalikan keluaran berupa karakter bintang tunggal (*) sebagai pertanda adanya kegagalan fungsi. Nilai keluaran bintang (*) dari penolakan fungsi ini lantas secara fatal dinilai identik dan cocok secara sempurna dengan karakter bintang (*) yang memang tersimpan pada kolom sandi akun target, sehingga daemon sshd menyimpulkan autentikasi berhasil lalu menerima proses login penyusup. Sementara itu, batas maksimal 1.024 byte pada rentang parameter serangan ini dipengaruhi oleh batasan internal yang dipatok secara baku oleh sshd sendiri untuk batas maksimal ukuran kata sandi.
Penyimpangan perilaku pemrosesan teknis ini bermula dari adanya perubahan kode pada proyek pustaka musl yang diresmikan pada tanggal 9 Agustus 2012 silam, yang mana modifikasi tersebut sengaja dirancang agar pemanggilan fungsi crypt() yang mengalami kegagalan proses dapat segera menghasilkan “sebuah bentuk hash yang tidak dapat dicocokkan alih-alih mengembalikan nilai kosong (NULL)”, langkah ini diambil lantaran pada masa itu banyak program perangkat lunak tidak menyertakan fungsi pengecekan kegagalan. Aturan batasan ketat maksimal 256 byte kemudian mulai ditambahkan tidak lama berselang, tepatnya pada tanggal 29 Agustus 2012, dengan tujuan utama guna memproteksi daya komputasi peladen dari potensi serangan penolakan layanan (Denial-of-Service atau DoS).
Di sisi lain, perilaku daemon yang secara otomatis meminjam nilai salt dari akun lain sebenarnya merupakan konsekuensi dari implementasi tambalan keamanan yang diterapkan oleh OpenSSH pada tanggal 15 Juli 2016 lalu, yang saat itu ditujukan khusus guna menuntaskan masalah celah kerentanan berkode CVE-2016-6210, yakni celah informasi yang kala itu memungkinkan aktor jahat menebak dan memetakan keberadaan nama pengguna valid di dalam sebuah peladen. Peneliti Kültekin mengungkapkan bahwa potensi bahaya dari kombinasi masalah teknis ini sejatinya telah eksis mengintai secara diam-diam semenjak perubahan tersebut diberlakukan.
Langkah perbaikan baris kode pada versi 10.6p2 kini secara tegas memaksa sshd untuk langsung menolak setiap kecocokan autentikasi apabila panjang karakter pada kolom data kredensial yang tersimpan ternyata tercatat kurang dari empat karakter. Pihak pengembang OpenSSH sendiri menyebut langkah taktis ini sebagai sebuah solusi sementara (workaround) dan berpendapat bahwa akar muasal permasalahan yang sesungguhnya berada di luar kendali lingkungan kode sshd. Bersamaan dengan itu, paket-paket rilis stabil di repositori Alpine Linux kini telah dibekali dengan tambalan kode terpadu untuk membereskan persoalan serupa secara permanen.
Alasan Perbaikan Diterbitkan Hanya Berselang Satu Hari
Tim pengembang di bawah komando Miller dilaporkan baru menerima laporan mengenai keberadaan kerentanan genting ini pada awal pekan ini, dan mereka langsung bergerak cepat mengoordinasikan penerbitan paket perbaikan sesegera mungkin tanpa menunda-nunda waktu. Dalam pengumuman rilis perbaikan resminya, ia secara terbuka menyatakan bahwa timnya kini memandang penerapan masa embargo informasi celah keamanan berdurasi panjang sebagai sebuah langkah yang justru sangat berisiko dan pada kenyataannya malah cenderung lebih menguntungkan kubu penyerang siber, hal ini disebabkan oleh tren terkini di mana mereka belakangan kerap menyaksikan agen-agen kecerdasan buatan (AI) sanggup menemukan kembali kelemahan celah yang sama secara mandiri, terkadang hanya dalam rentang hitungan beberapa jam saja.
Tercatat hingga hari ini saat informasi pembaruan ini diumumkan secara publik, belum ada kode identifikasi CVE resmi yang disematkan untuk menandai keberadaan celah kerentanan keamanan bypass autentikasi SSH tersebut.
