Debian zayıf anahtar güvenlik açığına nasıl rastladım

Debian zayıf anahtar güvenlik açığına yakalanma hikâyesi

• 2008 Mart'ında yazar, Engine Yard(EY)'de çalışıyordu
• O dönemde EY, GitHub'a ücretsiz altyapı sağlayarak destek oluyordu
• GitHub büyüdükçe SSH oturum açma sürelerinin yavaşlaması sorunu ortaya çıktı
• GitHub, SSH anahtarlarını yönetmek için standart yöntem olan ~/.ssh/authorized_keys dosyasını kullanıyordu
• SSH, kullanıcı bağlandığında bu dosyayı açıp kullanıcının sunduğu anahtarla eşleşen anahtarı doğrusal olarak arar
• Normalde sadece birkaç anahtar olduğundan bu sorun olmaz, ancak GitHub gibi kullanıcı sayısı arttığında yavaşlar

authorized_keys dosyası yerine MySQL DB kullanma kararı

• Çeşitli alternatifler incelendikten sonra, OpenSSH'yi yamalayıp anahtar aramasını MySQL DB üzerinden yapacak şekilde değiştirmeye karar verildi
• Bu dikkatli verilmiş bir karardı ve güvenliği zedelememek için büyük çaba harcandı
• 2008 Nisan başında devreye alındı ve SSH oturum açma hızı sorunu çözüldü

Tuhaf bir şey oldu

• Bir ay sonra, Mayıs başında bazı kullanıcıların SSH ile başka kullanıcıların depolarına erişebildiği bir sorun ortaya çıktı
• İnceleme sonucunda, farklı kullanıcıların aynı anahtar parmak izine sahip anahtarlar kullandığı görüldü
• Bu, anahtarlar paylaşılmadıkça olabilecek bir şey değildi
• Kullanıcılar birbirlerini tanımadıklarını ve anahtarın nasıl sızmış olabileceğini bilmediklerini söyledi
• Başka kullanıcı çiftlerinde de aynı sorun bulundu
• Tek ortak nokta, hepsinin Debian veya Ubuntu sistemleri kullanıyor olmasıydı

Nedenin ortaya çıkması

• 13 Mayıs 2008'de DSA-1571-1 yayımlanınca her şey netleşti
• Bir Debian bakımcısı, OpenSSL'in rastgele sayı üretim kodunu düzenlerken hata yaparak olası anahtar sayısını yaklaşık 32.000'e düşürmüştü
• Pek çok kişi en iyi uygulamalara uyarak GitHub'a katılırken yeni anahtar üretti ve bu da çakışmalara yol açtı
• Sonrasında yazar, bilinen zayıf anahtarları kullanarak sorunlu sertifika otoritelerini bulmak gibi yollarla bu konuyla daha fazla ilgilenmeye devam etti

GN⁺'ün görüşü

• Bu kadar önemli bir güvenlik açığını bulabilmek için, "Bu tuhaf" diye düşünüp ısrarla araştıracak zaman ve enerji gerekiyor. Genelde böyle bir boşluk olmadığından biraz da şans gerekiyor.
• Çoğu insan yoğun günlük işlerin arasında bir sorunun kök nedenine kadar inmeyi başaramıyor. Sektörümüzün bu düşünme alanını yeniden kazanması önemli bir ödev gibi görünüyor.
• OpenSSL, en yaygın kullanılan kriptografi kütüphanelerinden biri olduğu için böyle bir açığın etkisi çok büyük oluyor. Açık kaynağın avantajı ve dezavantajı burada net biçimde görülüyor.
• Bu tür açıkları önlemek için kod incelemesi ve güvenlik denetimlerini güçlendirmek, kritik bölümlerdeki değişiklikleri daha dikkatle değerlendirmek gerekiyor. Yine de kusursuz bir yöntem yok.
• Buna rağmen açık kaynak, uzmanların kodu doğrudan inceleyip sorunları bulabilmesine olanak tanıyor. Kapalı programlarda bu da mümkün değil.

[GN⁺]

Hacker News görüşleri

• Luciano Bello, CVE-2008-0166 açığını tesadüfen keşfetti; o dönemki IRC loglarına göre birçok asal sayı gerekiyordu ve her seferinde aynı sayıyı elde etmiyordu
• Görünüşe göre sektör genelinde şanslıydık; çünkü doğru zamanda büyük fark yaratabilecek beceriye, zamana ve enerjiye sahip biri vardı. Bu, "çok göz" ve "güneş ışığı en iyi dezenfektandır" anlayışının istatistiksel olarak hissedildiği bir nokta. Birinin bir hatayı tesadüfen bulma olasılığı ne kadar düşük olursa olsun, insanlar bunu yapabildiği için sonunda bulunuyor. Öte yandan özel/kapalı kaynak kodda bu olasılık 0
• Bu açığa yol açan değişiklik aceleyle yapılmış değildi. Bakımcı, OpenSSL e-posta listesinde sorunu gündeme getirmiş, geri bildirim istemiş ve bir çözüm önermişti; upstream dahil bazı geri bildirimler de almıştı. Sonuç korkunç bir açıktı ama bu, kimsenin sorunu fark etmediği son derece talihsiz bir vaka gibi görünüyor
• GitHub, MySQL veritabanında anahtar parmak izine göre indekslenmiş anahtarları sorgulayacak şekilde OpenSSH'yi yamalamanın en iyi seçenek olduğu sonucuna vardı. ~/.ssh/authorized_keys erişimini hızlandırmaya çalıştıkları bir durumda, bunun SQLite yerine MySQL'in öne çıkabileceği türden bir senaryo olduğu anlaşılıyor
• Bu, popüler bir Bitcoin donanım cüzdanının seed üretim fonksiyonunda böyle bir şeyin yaşanma ihtimalini ve sonuçlarını düşündürüyor
• GCD kullanarak ortak p veya q çarpanı olan RSA anahtarlarını tespit etme de ilginç bir olaydı
• SSH oturum açma süresinin yavaş olmasının, çeşitli nedenlerle peşinden gidilmeye değer bir ipucu olabildiği görülüyor
• OpenSSL RNG, başlatılmamış stack belleği ve PID ile seed ediliyordu; Debian yaması olmasa bile yalnızca PID ile seed etmek başlı başına zaten oldukça riskli görünüyordu
• GitHub'ın hâlâ yamalı OpenSSH çalıştırıp çalıştırmadığını merak ediyorum
• Ezra Zygmuntowicz'in GitHub'ı yazara tanıtması ve ona GitHub ekibiyle birlikte sorunu derinlemesine inceleme zamanı vermesiyle ilgili cümle komik. Belki de GitHub ekibinin kendisinde büyük bir sorun varmış gibi okunabildiği için
• Luciano bunu keşfetmemiş olsaydı, daha ne kadar uzun süre fark edilmeyeceğini merak ediyorum. Muhtemelen bunu tesadüfen fark edebilecek az sayıdaki yer, GitHub veya büyük bulut sağlayıcıları gibi kullanıcılardan binlerce anahtar depolayan yerler olurdu