sshole: Alpine'de 257 karakterlik herhangi bir parola, parolası olmayan hesaba SSH ile girebiliyordu

Ne oldu?

Linux’ta bir hesabın /etc/shadow satırında parola yerine * yazıyorsa, o hesaba parolayla girilemez. * geçerli bir parola özeti (hash) değil, hiçbir parola ona eşleşmez. Sadece SSH anahtarıyla girilen kullanıcılar, LDAP hesapları ve Alpine’deki root böyle kilitleniyor.

Güvenlik araştırmacısı Ozgun Kultekin, musl kullanan sistemlerde bunun doğru olmadığını gösterdi. Bu sistemlerde PAM olmadan derlenmiş sshd, * hesaplarına 257 ile 1024 bayt arasındaki herhangi bir parolayla girişe izin veriyordu. Açığa “sshole” adını verdi. OpenSSH 5 Kasım’da 10.6p2 sürümünü bu yüzden çıkardı.

Dört makul karar, bir açık

İşin ilginç yanı, tek başına hatalı görünen bir satır olmaması. Araştırmacının yazısına göre zincir şöyle:

1. Kilitli hesap * ile işaretleniyor. Hiçbir özet * olamayacağı için güvenli sayılıyor.
2. musl’ün crypt() fonksiyonu hata olunca "*" döndürüyor. 2012’de NULL yerine “hiçbir şeyle eşleşmeyecek bir metin” döndürmek daha güvenli görülmüş.
3. musl’ün SHA-512 crypt’i 256 bayttan uzun parolaları reddediyor. Bu da 2012’de, çok uzun parolalarla sunucuyu yorma (DoS) saldırılarına karşı eklenmiş. Reddetmenin yolu yine "*" döndürmek.
4. sshd, * hesaplarda da parolayı özetliyor. 2016’daki CVE-2016-6210 düzeltmesiyle, var olmayan ya da kilitli hesaplar için sshd sahte bir tuzla özet hesaplamaya başladı. Amaç, yanıt süresinden hangi kullanıcının gerçek olduğunun anlaşılmasını engellemekti. Tuz, sistemdeki gerçek bir parolanın özetinden ödünç alınıyor.

Şimdi bunları birleştir: Saldırgan 300 karakterlik rastgele bir parola gönderiyor. musl bunu çok uzun bulup "*" döndürüyor. sshd bunu shadow dosyasındaki "*" ile karşılaştırıyor. İkisi eşit, giriş başarılı. Bir hata işareti, başka bir hata işaretine eşit çıkıyor.

Kim etkileniyor?

Bütün koşullar aynı anda sağlanmalı:

• musl tabanlı bir sistem: Alpine, OpenWrt, Buildroot, Yocto ve Alpine tabanlı pek çok Docker imajı.
• sshd PAM olmadan çalışıyor. Alpine’in varsayılan openssh-server paketi böyle.
• PasswordAuthentication açık. Bu varsayılan ayar.
• Parolası * olan en az bir hesap ve SHA-256/512 özetli gerçek parolası olan en az bir hesap var.

glibc kullanan dağıtımlar, PAM’li kurulumlar, OpenBSD, FreeBSD ve macOS etkilenmiyor. Yazıya göre Alpine’in AWS ve Azure imajlarında varsayılan kullanıcı şifresiz doas yetkisine sahip olduğu için bu doğrudan root anlamına geliyordu. Araştırmacıya göre sorun 2016’dan beri var, test ettiği en eski sürüm olan 7.5p1 de etkileniyordu. Açığa henüz bir CVE numarası verilmemiş.

Ne yapmalısın?

• Güncelle. OpenSSH 10.6p2 düzeltmeyi içeriyor. Alpine paketleri de çıktı: apk upgrade openssh. OpenSSH’ın notu, kök nedenin sshd dışında olduğunu ama sshd’de engellenebildiğini yazıyor.
• Güncelleyemiyorsan PasswordAuthentication no ile parolalı girişi kapat. Sunucuya zaten anahtarla giriyorsan bunu her durumda yapmak iyi bir fikir. Tor çıkış düğümlerinin SSH tuzağı da parolalı girişin ne kadar riskli olduğunu göstermişti.
• Kontrol et. Araştırmacının deposundaki check.sh, makinenin etkilenip etkilenmediğini ve hangi hesapların açık olduğunu söylüyor. Kayıtlarda parolasız görünen root girişlerine bak.

Düşün

• Kodunda bir fonksiyon hata olunca “boş” ya da “geçersiz” bir değer döndürüyor mu? O değeri başka bir yerde neyle karşılaştırıyorsun?
• Konteyner imajlarında SSH sunucusu çalıştırmana gerçekten gerek var mı?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.