Saldırganlar, standart openssh-server paketini çalıştıran bazı Alpine Linux sunucularında şifresi olmayan hesaplara, örneğin yalnızca SSH anahtarı olan hesaplara giriş yapabiliyor. Bunun için sunucuya ağ erişimi, bir hesap adı ve 257 ile 1.024 bayt arasında uzunlukta bir şifre gerekiyor.
OpenSSH açığı kritik olarak değerlendiriyor ve bugün bunu engellemek için 10.6p2 sürümünü yayınladı. Alpine, 3.16 sürümüne kadar her sürüm için düzeltilmiş paketler yayımladı.
Saldırı, OpenSSH sunucusu sshd şifreleri Pluggable Authentication Module yani PAM arayüzü kullanılmadan kontrol ettiğinde, şifre girişleri etkin olduğunda ve makinede en az bir hesabın şifresi bulunduğunda işliyor. Alpine’ın openssh-server paketi PAM olmadan derleniyor ve şifre girişleri varsayılan olarak açık.
Açık, Alpine’ın temelini oluşturan musl C kütüphanesiyle sshd’nin çalışma şeklinden kaynaklanıyor. Non-Linux sistemler, glibc üzerinde kurulu Linux sistemleri ve şifreleri PAM üzerinden kontrol eden sistemler etkilenmiyor. OpenSSH projesinden Damien Miller bunu söyledi.
Etkilenen bir sistemi çalıştıran herkese "PasswordAuthentication=no olarak ayarlayın ya da bu sistemler için SSH’yi DERHAL devre dışı bırakın." dedi. Açığı kullanan saldırı bildirilmemiş.
Kimler risk altında
Alpine güvenlik duyurusu dört koşul listeliyor. Sunucu bu dört koşulun hepsi doğru olduğunda risk altında:
openssh-server paketini çalıştırıyor, bu paket PAM olmadan derlenmiş ya da UsePAM no ile openssh-server-pam çalıştırıyor.
PasswordAuthentication yes , bu OpenSSH varsayılanı.
Bir hesabın şifre alanı * , yani şifre ayarlanmamış.
En az bir yerel hesabın şifre karması $5$ veya $6$ ile başlıyor.
Saldırganın şifresi olmayan bir hesabın adını bilmesi gerekiyor. Şifresi olan tek bir hesap, şifresi olmayan her hesabı açığa çıkarıyor. Duyuruya göre saldırı tek bağlantıyla her denemede başarılı oluyor.
Alpine’da şifresi ayarlanmamış hesaplar şunlar:
adduser ile şifre vermeden oluşturulan yalnızca anahtarlı kullanıcılar ya da usermod -p '*' ile oluşturulanlar
musl-nscd üzerinden dizin hizmetinden gelen kullanıcılar, çünkü bunların shadow girdisi yok
root , yaklaşık Alpine 3.16’dan beri temel imajda root:* olarak gönderiliyor
tiny-cloud ile oluşturulan resmi bulut imajlarındaki alpine kullanıcısı
Root, varsayılan PermitRootLogin prohibit-password ayarı ile korunuyor ve yalnızca PermitRootLogin yes ayarlandığında doğrudan erişilebiliyor. Bu koruma, açığa çıkan bir hesap root olabilirse, örneğin doas üzerinden, işe yaramıyor.
3.18.11 ile 3.24.3 arasındaki tiny-cloud imajları alpine kullanıcısına şifresiz doas veriyor. İlk başlatmada güvenli görünüyorlar ancak makinede herhangi bir $6$ karması oluştuğunda, örneğin yönetici konsol şifresi ayarladığında, saldırıya açık hale geliyor. Saldırgan alpine olarak giriş yapıp doas ile root olabiliyor.
sshd çalıştırmayan konteynerler, PasswordAuthentication no olan sistemler ve cloud-init üzerinden kurulan bulut imajları, bu ayarı yazdığı için etkilenmiyor. /etc/shadow içinde ! ile kilitlenen hesaplar etkilenmiyor ve hiçbir hesabın $ tarzı şifre karması olmadığı makineler de etkilenmiyor.
Açık Alpine ile sınırlı değil. Wakefield’den Özgün Kültekin’in bildirdiği açık, teknik yazısında diğer musl tabanlı sistemler olarak OpenWrt, Buildroot ve Yocto’yu kontrol edilmesi gerekenler olarak adlandırıyor.
OpenWrt varsayılan olarak SSH için Dropbear kullanıyor ve Dropbear dokümantasyonu bunu gösteriyor, Kültekin Dropbear’ın etkilenmediğini söylüyor. OpenWrt’te açık yalnızca yönetici OpenSSH sunucusunu yüklediğinde önem kazanıyor.
Nasıl düzeltilir
Alpine’da düzeltme paket güncellemesi ve yeniden başlatma ile yapılıyor, çünkü paketi yükseltmek çalışan sshd’yi yeniden başlatmıyor:
Paketleri güncelle: apk upgrade -U -a
Sunucuyu yeniden başlat: rc-service sshd restart
Nokta sürümleri 3.21.10, 3.22.8, 3.23.8 ve 3.24.4 zaten düzeltilmiş paketi içeriyor. 3.16’dan 3.21’e kadar olan dallar destek süresi geçmiş olmasına rağmen düzeltilmiş paket aldı.
tiny-cloud imajlarından oluşturulmuş ve bu nokta sürümlerinden eski bulut örnekleri hâlâ güncellemeye ya da aşağıdaki ayara ihtiyaç duyuyor.
OpenSSH’yi kendiniz derliyorsanız, 10.6p2 sürümü değişiklikleri içeriyor ve sürüm notlarında anlatılıyor.
Hâlâ güncelleyemiyorsanız şifre girişlerini kapatmak saldırıyı da durduruyor. Önce SSH anahtarı girişinin çalıştığından emin olun ve yeni bir giriş başarılı olana kadar mevcut oturumu açık tutun. Ardından PasswordAuthentication no olarak ayarlayın, sshd -t ile yapılandırmayı kontrol edin ve sshd’yi yeniden başlatın.
Duyuru, Alpine’ın varsayılan yapılandırmasının 3.19’dan itibaren okuduğu /etc/ssh/sshd_config.d içindeki bir drop-in dosyaya ayarı ekleyen komutlar veriyor. Ayrıca /etc/ssh/sshd_config içindeki her PasswordAuthentication satırını yes’ten no’ya değiştiriyor, Match bloğu içindeki satırlar da dahil. Sonrasında sshd -T | grep -i passwordauthentication komutu passwordauthentication no yazdırmalı.
Duyuru, /var/log/messages içinde sshd satırlarının alpine, root ya da yalnızca anahtarlı bir kullanıcı gibi şifresi olmayan bir hesap için Accepted password okuyup okumadığına bakılmasını öneriyor. Açığa çıkan makinelerde ayrıca doas kullanımı, yakın zamanda oluşturulan kullanıcılar, dosyalar ve authorized_keys incelenmeli.
"Girişi dışlayamıyorsanız makineyi tehlikeye girmiş olarak kabul edin," diyor.
Uzun şifreler neden işe yarıyor
PAM olmadan sshd şifreyi kendisi kontrol ediyor. Denemeyi crypt() C kütüphanesi fonksiyonuyla karmaya çeviriyor ve sonucu saklanan alanla karşılaştırıyor.
Şifresi olmayan bir hesapta bu alan yalnızca * içeriyor. Bu, bir salt yani karmada rastgele önek tutmak için çok kısa, bu yüzden sshd başka bir hesabın gerçek karmasının tuzunu ödünç alıyor.
$5$ ve $6$ karma tipleri için musl’un crypt() fonksiyonu 256 bayttan uzun şifreleri reddediyor ve hatayı belirtmek için * döndürüyor. Bu * saklanan * ile eşleşiyor, bu yüzden sshd girişi kabul ediyor. Aralığın üst sınırı sshd’nin şifre başına 1.024 bayt limiti.
Bu davranış, 9 Ağustos 2012’de musl’da yapılan bir değişiklikten geliyor; başarısız bir crypt() çağrısının NULL yerine "eşleşmeyen bir karma" döndürmesi sağlandı, çünkü birçok program hatayı kontrol etmiyordu. 256 bayt limiti 29 Ağustos 2012’de sunucuları hizmet reddi saldırılarına karşı korumak için eklendi.
Tuz ödünç alma, CVE-2016-6210 açığını ele alan 15 Temmuz 2016 tarihli bir OpenSSH değişikliğinden geliyor; bu açık saldırganların hangi kullanıcı adlarının var olduğunu öğrenmesine izin veriyordu. Kültekin sorunun o zamandan beri var olduğunu söylüyor.
10.6p2 kod değişikliği sshd’nin saklanan alan dört karakterden kısa olduğunda eşleşmeyi reddetmesini sağlıyor. OpenSSH buna bir geçici çözüm diyor ve kök nedenin sshd dışında olduğunu belirtiyor. Kararlı Alpine paketleri aynı sorun için bir yama taşıyor.
Düzeltme neden ertesi gün geldi
Miller’ın ekibi açığı bu hafta başında öğrendi ve elinden geldiğince hızlı şekilde düzeltmeyi yayımladı. Sürüm duyurusunda Miller, ekibin artık uzun gizlilik sürelerini tehlikeli gördüğünü ve saldırganlara yardımcı olduğunu, çünkü son zamanlarda yapay zekâ ajanlarının aynı hataları bazen saatler içinde bulduğunu söyledi.
Açığa bugün itibarıyla bir CVE tanımlayıcısı atanmamıştı.