Alpine Linux'ta SSH açığı: 257 baytlık şifreyle herkese giriş

Alpine Linux OpenSSH şifre atlatma açığı nasıl çalışıyor?

Sorun, ikisi de "şifre yok" anlamına gelen iki şeyin çakışmasından kaynaklanıyor: musl'un hata dönüşü ve shadow dosyasındaki yer tutucu.

sshd PAM olmadan derlendiğinde, bir şifreyi crypt() fonksiyonundan geçirip sonucu saklanan şifre alanıyla karşılaştırıyor. Saklanan alan tuz (salt) tutamayacak kadar kısaysa, sshd makinedeki başka bir hesabın tuzunu ödünç alıyor.

musl'un crypt() fonksiyonu, anahtar 256 bayttan uzun olduğunda * dizesini döndürüyor. * ise şifresi olmayan her hesabın şifre alanında tam olarak yazan şey. "Hash" eşleşiyor ve giriş başarılı oluyor.

Saldırganın iki şeye ihtiyacı var: şifre alanı * olan bir hesabın adı ve $5$ veya $6$ hash'li en az bir başka hesap. Sonra 257-1024 bayt arası bir şifreyle tek bir bağlantı kabuk (shell) alıyor. Deneme yok, tahmin yok, şifre yok.

• Etkilenen: Alpine'ın openssh-server (PAM'sız) ve UsePAM no ayarlı openssh-server-pam paketleri.
• Etkilenen: kontrol edilen tüm Alpine sürümleri, 3.21'den 3.24'e ve edge, ayrıca desteklenmeyen 3.16-3.20.
• Etkilenmeyen: sshd çalıştırmayan konteynerler, UsePAM yes ayarlı openssh-server-pam ve $5$/$6$ hash'i olmayan sistemler.

Kimler gerçekten risk altında?

Sıradan Alpine kurulumlarının çoğu bu tanıma uyuyor, çünkü sunucularda anahtar tabanlı hesaplar standart.

Yaklaşık Alpine 3.16'dan beri temel imajda root, root:* olarak geliyor, yani şifresiz hesap sayılıyor. OpenSSH'nin varsayılan PermitRootLogin prohibit-password ayarı root'u dışarıda tutuyor — ta ki PermitRootLogin yes ayarlanana veya başka bir giriş hesabı doas ile root'a geçene kadar.

adduser ile şifresiz oluşturulan veya usermod -p '*' ile şifresi kaldırılan anahtar tabanlı her kullanıcı hedef. musl-nscd üzerinden dizin hizmetinden gelen kullanıcılar da hedef, çünkü onların shadow kaydı yok.

Resmi tiny-cloud imajları 3.18.11'den 3.24.3'e kadar ilk açılışta güvenli, ancak makinede herhangi bir $6$ hash'i oluştuğu anda savunmasız hale geliyor — yöneticinin konsol şifresi belirlemesi veya user-data'nın hashed_passwd ile kullanıcı eklemesi gibi. Saldırgan sonra alpine olarak kabuk alıp şifresiz doas ile root'a geçebiliyor.

Nasıl düzeltilir — ve neden sadece güncellemek yetmez?

Alpine düzeltilmiş paketleri yayınladı, ancak çalışan servis yeniden başlatılana kadar eski kodu kullanmaya devam ediyor.

Alpine 3.21.10, 3.22.8, 3.23.8 ve 3.24.4 düzeltilmiş paketi içeriyor. Güncellemeden sonra rc-service sshd restart komutunu çalıştırın. Paketi güncellemek çalışan sshd'yi yeniden başlatmaz, bu yüzden siz başlatana kadar açık kalır.

Hemen güncelleyemiyorsanız şifre girişlerini kapatın. sshd yapılandırmanıza PasswordAuthentication no satırını ekleyin ve sshd'yi yeniden başlatın. İki adımdan biri açığı kapatır.

3.19'dan eski sürümlerde drop-in dizini okunmaz, bu yüzden /etc/ssh/sshd_config üzerinde sed yöntemi işe yarar. Mevcut oturumu kapatmadan önce yeni bir anahtar girişini test edin.

• openssh'i güncelleyin, ardından rc-service sshd restart çalıştırın.
• Veya PasswordAuthentication no ayarlayıp sshd'yi yeniden başlatın.
• Şifresi olmayan hesaplar için /var/log/messages dosyasında 'Accepted password' satırlarını kontrol edin.
• Giriş yapılıp yapılmadığını kesin olarak bilemiyorsanız makineyi ele geçirilmiş kabul edin.

Türkiye'de durum ne?

Alpine Linux, özellikle VPS ve bulut sunucularda hafifliği nedeniyle Türkiye'deki geliştiriciler ve sistem yöneticileri arasında yaygın. Sunucunuzda sshd dışarıya açıksa ve Alpine'ın openssh-server paketini kullanıyorsanız bu haber sizi doğrudan ilgilendiriyor. Düzeltilmiş paketler Alpine depolarında mevcut; güncelleme sonrası sshd'yi yeniden başlatmayı unutmayın. Uyarı yayınlandığında henüz CVE atanmadığı için güvenlik tarayıcıları açığı hemen işaretlemeyebilir.

Türkiye'deki barındırma sağlayıcılarının çoğu Alpine tabanlı imajlar sunmuyor olsa da, kendi sunucunuzu yönetiyorsanız veya Docker konteynerlerinde sshd çalıştırıyorsanız risk altındasınız. Konteyner içinde sshd yoksa etkilenmezsiniz. Bulut-init ile yapılandırılan ve PasswordAuthentication no yazan imajlar da güvende.

Açığın ciddiyeti, son dönemdeki diğer ihlallerin ardından daha net görülüyor: DreamHost'ta çalınan FTP ve webmail şifreleri ve Harvard'da 851 bin hesabın sızdığı ihlal aynı dersi veriyor — erişim anahtarları ve şifreler ne kadar dağınık yönetilirse hasar o kadar büyüyor. Alpine sunucularında da önce güncelleme, sonra yeniden başlatma sırası atlanmamalı.

Çözüm bir paket güncellemesi ve yeniden başlatma ya da tek bir yapılandırma satırı. Asıl iş, açığın daha önce kullanılıp kullanılmadığını kontrol etmek — ve açık kalmış bir makinede bu, temiz olduğunu varsaymadan önce günlükleri okumak anlamına geliyor.