OpenSSH, Alpine Linux’ta Uzun Parolalarla SSH Doğurmasını Atlatan Açığı Acil Düzeltmeyle Düzeltiyor

Salrganlar, standard openssh-server paketini çalıştıran bazı Alpine Linux sunucularında, hiç şifresi olmayan hesaplara (örneğin yalnızca SSH anahtarıyla erişilen hesaplara) giriş yapabilir. Bunun için sunucuya ağ erişimine, bir hesap adına ve 257 ile 1.024 byte arasında uzunlukta bir şifreye ihtiyaçları vardır.

Kusuru kritik düzeyinde değerlendiren OpenSSH, bugün bu açığı kapatmak için 10.6p2 sürümünü yayımladı. Alpine, 3.16 sürümünden beri tüm sürümler için düzeltilmiş paketler yayımladı.

Saldırganlık, OpenSSH sunucusunun (sshd) şifreleri Pluggable Authentication Module (PAM) arayüzü olmadan doğruladığı, şifreyle girişlerin açık olduğu ve makinedeki en az bir hesabın şifresi olduğu durumlarda işe yarar. Alpine’in openssh-server paketi PAM olmadan derlenmiştir ve şifreyle girişler varsayılan olarak açıktır.

Kusur, sshd’nin Alpine’in temelini oluşturan C kütüphanesi musl ile nasıl çalıştığından kaynaklanıyor. Linux dışı sistemler, glibc üzerine kurulu Linux sistemleri ve şifreleri PAM üzerinden doğrulayan sistemler etkilenmiyor; OpenSSH projesinden Damien Miller.

Etkilenmiş bir sistem çalıştıran herkese “PasswordAuthentication=no ayarını yapın ya da bu sistemler için SSH’yi DERHAL kapatın” dedi. Kusuru kullanan herhangi bir saldırının bildirilmediğini belirtti.

Kimler Maruz Kalır

Alpine’in güvenlik uyarısı dört koşul sıralıyor. Bir sunucu, bu dört koşul birden doğru olduğunda maruz kalır:

• openssh-server paketini çalıştırır; bu paket PAM olmadan derlenmiştir ya da openssh-server-pam’ı UsePAM no ayarıyla çalıştırır.
• PasswordAuthentication yes durumundadır; bu OpenSSH’nin varsayılanıdır.
• Bir hesabın şifre alanında * bulunur; bu da şifrenin ayarlanmadığı anlamına gelir.
• En az bir yerel hesabın şifre karma değeri $5$ ya da $6$ ile başlar.

Salrgan ayrıca şifresi olmayan bir hesabın adına da ihtiyaç duyar. Tek bir şifresi olan hesap, şifresi olmayan tüm hesapları maruz bırakmaya yeter. Uyarıya göre saldırganlık, tek bir bağlantıyla her denemede başarılı oluyor.

Alpine’de şifresi ayarlanmamış hesaplar şunları içerir:

• adduser ile şifresiz oluşturulan ya da usermod -p ‘*’ ile oluşturulan yalnızca anahtar içeren kullanıcılar
• musl-nscd üzerinden bir dizin hizmetinden gelen, gölge (shadow) kaydı bulunmayan kullanıcılar
• root, Alpine 3.16’dan beri temel görüntüde root:* olarak dağıtılan hesap
• tiny-cloud ile oluşturulan resmi bulut görüntülerindeki alpine kullanıcısı

Root, varsayılan PermitRootLogin prohibit-password ayarı ile korunur ve yalnızca PermitRootLogin yes ayarlandığında doğrudan erişilebilir. Bu koruma, örneğin doas üzerinden erişilebilir bir hesabın root haline gelmesi durumunda işe yaramaz.

3.18.11 ile 3.24.3 arasındaki tiny-cloud görüntüleri, alpine kullanıcısına şifresiz doas izni verir. Bu görüntüler ilk açılışta güvenlidir ancak makinede örneğin bir yönetici bir konsol şifresi belirledikten sonra herhangi bir $6$ karması oluştuğinde saldırıya açık hale gelir. Saldırgan ardından alpine olarak giriş yapıp doas kullanarak root haline gelebilir.

sshd çalıştırmayan konteynerler, PasswordAuthentication no ayarına sahip sistemler ve cloud-init aracılığıyla, bu ayarı yazarak kurulan bulut görüntüleri etkilenmez. /etc/shadow içinde ! ile kilitlenen hesaplar etkilenmez; $-stili şifre karması taşıyan hiçbir hesap olmayan makineler de etkilenmez.

Hata yalnızca Alpine’e özgü değildir. Wakefield’lı Özgün Kültekin’in raporladığı bu açığı, teknik açıklamasında OpenWrt, Buildroot ve Yocto gibi diğer musl tabanlı sistemleri kontrol edilecek sistemler olarak listeler.

OpenWrt, SSH’ı varsayılan olarak Dropbear ile yönetir; Dropbear belgelerinin de gösterdiği gibi Kültekin, Dropbear’in etkilenmediğini belirtiyor. OpenWrt üzerinde hata yalnızca bir yöneticinin OpenSSH sunucusunu kurduğu durumlarda önem taşıyabilir.

Nasıl Düzeltilir

Alpine üzerinde düzeltme, paket güncellemesini takiben yeniden başlatmayı gerektirir, çünkü paketin yükseltilmesi çalışan sshd’yi yeniden başlatmaz:

1. Paketleri güncelleyin: apk upgrade -U -a
2. Sunucuyu yeniden başlatın: rc-service sshd restart

3.21.10, 3.22.8, 3.23.8 ve 3.24.4 sürümleri zaten düzeltilmiş paketi içeriyor. 3.16 ile 3.21 dalları destek sürelerini tamamlamış olsa da onlar da düzeltilmiş paketler aldı.

Kıtiny-cloud görüntülerinden, bu sürüm noktalarına ulaşmayan eski sürümlerden başlatılan bulut örnekleri hâlâ güncellemeye ya da aşağıdaki ayara ihtiyaç duyar.

OpenSSH’ı kendiniz derliyorsanız, 10.6p2 sürümü değişikliği içeriyor; sürüm notları bunu açıklıyor.

Güncelleyemiyorsanız, parola girişlerini kapatmak saldırıyı durdurur. Önce SSH anahtarı girişinizin çalıştığını emin olun ve yeni giriş başarılı olana kadar mevcut oturumunuzu açık tutun. Sonra PasswordAuthentication no ayarını yapın, yapılandırmayı sshd -t ile denetleyin ve sshd’yi yeniden başlatın.

Duyuru, bu ayarı /etc/ssh/sshd_config.d klasöründeki bir drop-in dosyaya ekleyen komutları veriyor; bu dosyayı Alpine varsayılan yapılandırması 3.19’dan itibaren okur. Ayrıca /etc/ssh/sshd_config dosyasındaki tüm PasswordAuthentication satırlarını, Match bloğu içindekiler de dahil olmak üzere yes’den no’ya değiştirirler. Ardından, sshd -T | grep -i passwordauthentication komutu passwordauthentication no çıktısı vermelidir.

Duyuru, /var/log/messages içinde, alpine, root veya yalnızca anahtarlı bir kullanıcı gibi şifresi olmayan bir hesaba ait “Accepted password” diye okunan sshd satırlarını incelemeyi öneriyor. Açığa çıkmış makinelerde ayrıca doas kullanımını, yakın zamanda oluşturulan kullanıcıları, dosyaları ve yetkili anahtarları gözden geçirin.

“Bir girişi eleyemiyorsanız, makineyi ele geçirilmiş olarak değerlendirin,” diyor.

Neden Uzun Şifreler İşe Yarar

PAM olmadan, sshd parolayı kendisi kontrol eder. Denemeyi crypt() ile karmaşır; bu, C kütüphanesinin parolayı saklanan biçimine dönüştüren işlevidir ve sonucu saklanan alanla karşılaştırır.

Şifresi olmayan bir hesapta bu alanda yalnızca * bulunur. Bu, bir tuz için çok kısadır; tuz, bir karma’nın rastlantısal ön ekindir, bu nedenle sshd gerçek bir karmaya sahip başka bir hesabın tuzundan faydalanır.

$5$ ve $6$ karma türleri için musl’ın crypt() işlevi 256 bayttan uzun şifreleri reddeder ve hatayı belirtmek için * döndürür. Bu *, saklanan * ile eşleşir, böylece sshd girişi kabul eder. Aralığın üst ucu ise sshd’nin her şifre için 1.024 baytlık kendi sınırüdür.

Bu davranış, 9 Ağustos 2012’de bir musl değişikliğinden kaynaklanıyor; bu değişiklik, birçok programın hatayı kontrol etmemesinden dolayı başarısız bir crypt() çağrısının NULL yerine “eşleştirilemeyen bir karma” döndürülmesini sağladı. 256 baytlık sınır, sunucuları hizmet dışı bırakma saldırılarından korumak amacıyla 29 Ağustos 2012’de getirildi.

Tuz ödünç alma, saldırganların hangi kullanıcı adlarının var olduğunu öğrenebilmesini sağlayan ve CVE-2016-6210 olarak bilinen bir açığı gideren 15 Temmuz 2016 tarihli bir OpenSSH değişikliğinden geliyor. Kültekin, sorunun o günden beri var olduğunu söylüyor.

10.6p2 kod değişikliği, sshd’nin saklanan alanın dört karakterden kısa olması durumunda eşleşmeyi reddetmesini sağlıyor. OpenSSH bunu bir geçici çözüm olarak adlandırıyor ve kök sorunun sshd’nin dışında olduğunu belirtiyor. Alpine’ın kararlı paketleri, aynı sorun için bir yama içeriyor.

Neden Düzeltme Ertesi Gün Geldi

Miller’ın ekibi, açığı bu hafta daha önce öğrendi ve düzeltmeyi mümkün olduğunca hızlı bir şekilde yayımladı. Sürüm duyurusunda, ekibin artık uzun embargo’ları tehlikeli ve çoğunlukla saldırganlara yardımcı olarak gördüğünü söyledi; çünkü son zamanlarda yapay zeka ajanlarının aynı açıkları bazen saatler içinde tekrar bulduğunu gördü.

Açığa bugün itibarıyla atanmış bir CVE numarası yoktu.

Açık Kaynak Güvenliği