*sshole, belirli bir OpenSSH ve musl yapılandırmasında yetkisiz erişime yol açabilen bir güvenlik açığıdır. Özellikle musl kullanan Alpine Linux sistemleri gündeme gelse de risk yalnızca Alpine ile sınırlı değildir: Aynı bileşenleri benzer biçimde yapılandıran başka Linux sistemleri de etkilenebilir.
Açığın varlığı tek başına her Linux cihazının savunmasız olduğu anlamına gelmez. Etki, OpenSSH’in PAM kullanmadan çalışması ve sistemde belirli parola yapılandırmalarının bulunması gibi koşulların bir araya gelmesine bağlıdır. Bu nedenle sistem yöneticilerinin dağıtım adına bakmakla yetinmeyip gerçek yapılandırmayı incelemesi gerekir.
Açığın temelinde hangi bileşenler var?
OpenSSH, SSH üzerinden güvenli uzaktan bağlantı kurulmasını sağlayan yazılım paketidir. Sistem yöneticileri bu paket aracılığıyla sunuculara bağlanabilir; kullanıcılar da kimlik doğrulama yöntemlerine göre sisteme erişebilir. musl ise Linux programlarının temel sistem işlevlerine ulaşmasını sağlayan C standart kütüphanelerinden biridir. Daha hafif bir alternatif olarak tercih edilir ve Alpine Linux’un temel bileşenleri arasındadır.
Birçok Linux dağıtımında musl yerine glibc adı verilen başka bir C kütüphanesi kullanılır. Bu fark, söz konusu açığın tüm Linux dağıtımlarını otomatik olarak etkilemediği anlamına gelir. Ancak musl kullanan bir sistemde OpenSSH’in de belirli koşullarla çalışması hâlinde benzer risk ortaya çıkabilir.
Önemli koşullardan biri, OpenSSH’in PAM kullanmamasıdır. PAM, kullanıcıların kimlik doğrulama ve hesap erişim kurallarını merkezi biçimde yönetmeye yarayan bir altyapıdır. OpenSSH ile musl arasındaki etkileşim, PAM’ın devre dışı olduğu ilgili yapılandırmalarda açığın tetiklenmesine zemin hazırlayabilir. Dolayısıyla yalnızca musl kullanılması, sistemin kesin olarak savunmasız olduğunu göstermeye yetmez.
Hangi hesap ve parola koşulları aranmalı?
Belirtilen saldırı senaryosunda sistemde, parolayla erişime izin verilen en az bir hesabın bulunması gerekir. Bu hesabın parolası SHA-256 veya SHA-512 kullanılarak özetlenmiş olmalıdır. Parola özeti, parolanın kendisi yerine doğrulama amacıyla saklanan dönüştürülmüş değeridir.
Senaryonun diğer parçası ise hedef hesabın parola alanının boş olmaması, ancak bu alanda * işaretinin bulunmasıdır. Bu işaret, ilgili hesap için geleneksel parola doğrulamasının devre dışı olduğunu gösterebilir. Böyle hesaplar çoğu zaman SSH anahtarı veya başka bir sertifika tabanlı yöntemle erişim için yapılandırılır. Bununla birlikte, hesabın parola alanındaki işaretin anlamı dağıtım ve yapılandırma ayrıntılarına göre değerlendirilmelidir; yöneticiler yalnızca tek bir dosya değerine dayanarak güvenlik kararı vermemelidir.
- Sistemde musl kütüphanesi kullanılmalı ve OpenSSH ilgili yapılandırmayla çalışmalıdır.
- OpenSSH, söz konusu kurulumda PAM üzerinden kimlik doğrulaması yapmamalıdır.
- Sistemde SHA-256 veya SHA-512 ile özetlenmiş parolaya sahip, parolayla erişime açık en az bir kullanıcı bulunmalıdır.
- Etkilenebilecek hedef hesabın parola yapılandırması, belirtilen senaryodaki gibi parola alanında yıldız işareti içermelidir.
Bu koşulların tümü birlikte değerlendirilmelidir. Bir veya birkaç koşulun bulunması tek başına başarılı bir saldırının mümkün olduğunu kanıtlamaz; aynı şekilde sistemin Alpine dışında bir dağıtım kullanması da benzer bir yapılandırma varsa riski kesin olarak ortadan kaldırmaz.
Saldırı riski ve yöneticilerin atabileceği adımlar
Aktarılan teknik açıklamaya göre saldırı, uygun yapılandırma mevcut olduğunda tek bir bağlantı girişimiyle gerçekleşebilir ve saldırganın tekrar tekrar deneme yapmasını gerektirmez. Bu özellik, açığın koşulları karşılayan sistemlerde ciddiye alınmasını gerektirir. Bununla birlikte risk değerlendirmesi; kullanılan OpenSSH sürümü, dağıtımın güvenlik güncellemeleri ve sistemin gerçek kimlik doğrulama ayarları üzerinden yapılmalıdır.
Sistem yöneticileri öncelikle Alpine Linux ve musl kullanan sunucuların envanterini çıkarmalı; ardından OpenSSH’in PAM ile çalışıp çalışmadığını, parola doğrulamasının hangi kullanıcılar için açık olduğunu ve parolasız hesapların nasıl yapılandırıldığını kontrol etmelidir. Üretici ve dağıtım güvenlik duyurularını izlemek, mevcut güncellemeleri uygulamak ve gerekiyorsa desteklenen bir yapılandırmaya geçmek temel önlemler arasındadır.
Parolasız hesaplar için erişim gereksinimleri yeniden gözden geçirilmeli, kullanılmayan hesaplar kapatılmalı ve SSH erişimi mümkün olduğunca anahtar tabanlı kimlik doğrulama, erişim kısıtlamaları ve izleme mekanizmalarıyla sınırlandırılmalıdır. Ancak bu önlemler, ilgili güvenlik güncellemelerinin yerine geçmez. Yöneticiler, sistemleri değiştirirken uzaktan erişimi kesmemek için önce yedekleme ve kurtarma planı oluşturmalı, değişiklikleri kontrollü biçimde uygulamalıdır.
*sshole’un yaklaşık on yıldır sistemlerde bulunduğuna ilişkin bilgi, etkilenen her cihazın bu süre boyunca saldırıya uğradığını göstermez. Bu, açığın uzun süredir mevcut olabileceğine dair bir zaman aralığıdır. Etkilenme ve olası kötüye kullanım konusunda kesin sonuca varmak için sistem günlükleri, yapılandırma geçmişi ve ilgili güvenlik duyuruları birlikte incelenmelidir.
