Debian weak keys açığına tesadüfen takılma hikayesi
(hezmatt.org)- 2008’de GitHub’ın SSH oturum açma darboğazını gidermeye yönelik çalışma, farklı kullanıcıların aynı SSH anahtar parmak izine sahip olduğu anormal çakışmayı ortaya çıkaran vesile oldu
- GitHub, büyüyen
authorized_keysdosyasında doğrusal arama sorunundan kaçınmak için OpenSSH’i yamalayarak anahtar parmak izlerinin MySQL’den sorgulanmasını sağladı - Yama dağıtıldıktan sonra başka kullanıcıların depolarına SSH ile erişilebilmesi sorunu ortaya çıktı; ancak tekrarlanan anahtar parmak izi çakışmaları basit bir yama hatası gibi görünmeyecek kadar tuhaftı
- 13 Mayıs 2008’de DSA-1571-1’in yayımlanmasıyla, Debian OpenSSL’in yaklaşık 18 ay boyunca tahmin edilebilir özel anahtarlar ürettiği ve olası anahtar sayısının kullanıcı başına 32.000’in biraz üzerine düştüğü doğrulandı
- Büyük güvenlik olayları çoğu zaman “tuhaf” görünen küçük bir sinyalle başlar; o ipucunu sonuna kadar takip edecek zaman ve yetkinlik asıl farkı yaratır
GitHub SSH oturum açma darboğazıyla başlayan olay
- Mart 2008’de Engine Yard’da çalışan yazar, Rails odaklı barındırma şirketinin müşterisi olan GitHub’ın SSH oturum açma performansı sorununa yardım etmeye başladı
- GitHub,
git@github.comüzerinden SSH bağlantısı kurulduktan sonra açık anahtar kimlik doğrulamasıyla Git deposu erişimi sağlıyordu - O dönemde anahtar yönetimi, yaygın yöntem olan
~/.ssh/authorized_keysdosyasına dayanıyordu- SSH, açık anahtar kimlik doğrulama isteği aldığında
authorized_keysdosyasını açıyor ve gönderilen anahtarla eşleşen girdiyi doğrusal aramayla buluyordu - Tipik bir hesapta yalnızca birkaç anahtar olduğu için bu büyük bir sorun değildi; ancak hızla büyüyen GitHub’da tüm SSH anahtarları tek bir büyük dosyada birikiyor ve oturum açma süreleri belirgin biçimde yavaşlıyordu
- SSH, açık anahtar kimlik doğrulama isteği aldığında
OpenSSH yaması ve MySQL anahtar sorgulaması
- Çeşitli çözümler değerlendirildikten sonra GitHub ekibi ve yazar, OpenSSH’i yamalayarak anahtarları parmak izine göre MySQL veritabanından sorgulama yolunu seçti
- Bu karar hafife alınacak bir değişiklik değildi
- OpenSSH’te yapılacak bir değişiklik, yanlış yapılırsa güvenlik açısından felaket sonuçlar doğurabilirdi
- Diğer seçenekler daha kötü olduğu için bu, “en az kötü” çözüm olarak değerlendirildi
- Değişiklik çalışmasının önemli bir bölümü, güvenliği zedelemediğini doğrulamaya ayrıldı
- Nisan 2008 başındaki dağıtımdan sonra SSH oturum açma hızlandı ve bir süre aynı sorunu düşünmeye gerek kalmayacak gibi görünüyordu
İmkânsız gibi görünen belirti: yinelenen anahtar parmak izi
- Mayıs 2008 başında GitHub ekibinden, bazı GitHub kullanıcılarının SSH üzerinden başka kullanıcıların depolarına erişebildiğine dair bir mesaj geldi
- Sorun doğrudan SSH anahtar kimlik doğrulamasıyla ilgiliydi ve hemen öncesinde OpenSSH yaması dağıtılmıştı; bu yüzden yazarın yazdığı kod ilk şüpheli oldu
- Hata ayıklama sonunda iki farklı kullanıcının aynı anahtar parmak izine sahip olduğu doğrulandı
- Kullanıcılar anahtarlarını birbirleriyle paylaşmadıysa bunun gerçekleşmesi pratikte çok zordu
- Etkilenen kullanıcılar birbirlerini tanımadıklarını ve anahtarlarını hiç yayımlamadıklarını söyledi
- Daha sonra başka bir kullanıcı çiftinde de aynı anahtar parmak izi bulundu ve bu parmak izi önceki vakadakinden farklıydı
- Durum artık tek bir tesadüf ya da web uygulaması hatası olarak açıklanamayacak hâle geldi
- OpenSSH yamasının neden olmadığı yeterince doğrulandıktan sonra yazarın doğrudan dahli azaldı
- Yazar GitHub çalışanı değildi ve Engine Yard’ın diğer müşterileri için destek işlerini de yürütmesi gerekiyordu
- GitHub ekibi kullanıcılarla doğrulamaya devam etti ve ortak nokta olarak SSH anahtarlarının Debian veya Ubuntu sistemlerinde oluşturulduğunu belirledi
Debian OpenSSL açığının yayımlanmasıyla ortaya çıkan neden
- 13 Mayıs 2008’de DSA-1571-1 yayımlanınca durum netleşti
- Debian OpenSSL paketi yaklaşık 18 ay boyunca tahmin edilebilir özel anahtarlar üretiyordu
- Neden, OpenSSL rastgele sayı üretim kodu temizlenirken Debian bakımcısının istemeden üretilebilir anahtar alanını büyük ölçüde daraltmasıydı
- Belirli bir kullanıcının üretebileceği olası anahtar sayısı “akıl almaz derecede büyük bir sayıdan” 32.000’in biraz üzerine düştü
- Çok sayıda kullanıcı GitHub’a katılırken, bazıları önerilen uygulamaya uyarak ayrı bir yeni anahtar üretmiş olabilir; bunun sonucunda çakışmalar yaşanabilirdi
- Bu duyuru, yazarın OpenSSH yamasının neden olmadığına dair kesin kanıt sağladı
Sonraki Debian weak keys çalışmaları
- Yazar daha sonra Debian weak keys ile daha fazla temas kurdu
- pwnedkeys.com sitesini işleterek bilinen ele geçirilmiş anahtarların büyük ölçekli bir deposuyla ilgilendi
- Bu anahtarları kullanarak yanlış çalışan Certificate Authority bulma çalışması da yürüttü
“Tuhaf” olanı takip etmeye ayrılan zamanın yarattığı fark
- Yazar, CVE-2008-0166 hâline gelen açığı Luciano Bello’nun tam olarak ne zaman ve nasıl keşfettiğini bulamadı
- Zayıf kodu içeren stable Debian sürümü duyurudan bir yıl önce çıktığı için, anahtar çakışmalarını görüp “tuhaf” diye düşündükten sonra derinlemesine araştırmaya zaman olmuş olabilir
- Yakın dönemdeki XZ backdoor olayı da “tuhaf” gözlemlerin ve yoğun araştırmanın ardından ortaya çıkarılan bir örnekle bağlantılı
- Önemli olan, böyle bir yoğun araştırmayı gerçekten yapabilecek yetenek ve zamana sahip olmak
- Yazar o dönemde derin araştırmayı bizzat yapamadı
- GitHub ekibi de hızla büyüyen bir serviste özellik geliştirme ve arıza müdahalesiyle meşguldü
- Yazar da Engine Yard’da destek talepleriyle ilgileniyordu
- Doğru anda teknik beceriye, zamana ve enerjiye sahip biri ipucunu sonuna kadar takip edebildiğinde büyük fark yaratılır
1 yorum
Hacker News yorumları
“Luciano Bello’nun daha sonra CVE-2008-0166 olacak açığı tam olarak ne zaman ve nasıl keşfettiğini bulamadım” denilen kısım için, o dönemin IRC kayıtlarında şöyle geçiyor
17:23 < luciano> has really an accident. I was needing many primes numbers... 0:-)17:23 < Sesse> and you got the same numbers every time?17:25 < luciano> Sesse, not every time :P“Doğru beceri, zaman ve enerjiye sahip birinin tam doğru anda orada olması sektör için şanstı” sözü, çok sayıda göz ve “güneş ışığı en iyi dezenfektandır” istatistiğinin somutlaştığı nokta
Birinin tesadüfen oradan geçerken bir hata bulması ne kadar düşük olasılıklı görünse de, mümkün olduğu için gerçekten gerçekleşiyor
Tescilli/kapalı kodda bu olasılık sıfıra yakın
Birisi tuhaf bir şey fark etti ve kaynak kodla birlikte gerçek durumu inceleyerek şüpheli bir şeyler olduğunu görebildi
Büyük dağıtımların güvenlik uzmanlarıyla iletişime geçip ek inceleme istedi; onlar da güvenlik sorununu doğruladıktan sonra hemen harekete geçebildi
Kamuya açıklandıktan sonra yazılım ve güvenliğin çeşitli alanlarında uzman kişiler neyin nasıl yapıldığını ve risklerin neler olduğunu didik didik edebildi
Aynı geliştiricinin başka yazılımlarda bıraktığı şüpheli commit’ler de izlenip doğrulandı ve bunların etki analizi hâlâ sürüyor
Her dağıtım, derleme arşivleri çevresinde bozulmanın nasıl gerçekleştiğine dair ayrıntılara daha duyarlı hâle geldi ve gelecekte benzer vakaları yakalayıp engellemenin yollarını aramaya başladı
Kapalı kaynakla karşılaştırıldığında, gerçek bir istismar yaşanana kadar “yazılım biraz yavaş” gibi raporların neredeyse hiç dikkat çekmemiş olması büyük olasılık
Şirket sonunda bunu fark etse bile, muhtemelen yalnızca minimum bilgiyi açığa çıkaran çok temkinli bir açıklama gelirdi; bu da sektörün tamamının aynı şeyin tekrarlanmasını önleme becerisine ciddi zarar verirdi
Ancak sorunu düzeltememe ya da hiçbir şey yapmama olasılığı yüksektir
Çoğu kişi bir hata bulsa bile ne yapacağını bilmez. Çok eskiden ben de öyleydim; ancak sonradan gördüklerimin hata olduğunu fark ettim
Neredeyse 30 yıl önce olduğu için ayrıntılar bulanık, ama Windows’ta Microsoft NetMeeting ile kurcalarken bir buffer overrun hatasıyla çökme yaratabildiğimi hatırlıyorum
O zamanlar bilgisayar konusunda acemiydim ve bir ağ uygulamasında buffer overflow olmasının çok kötü bir şey olduğunu anlamıyordum. Sektörde uzun süredir bulunan birçok kişi de öyleymiş gibi görünüyor
O dönemde güvenlik sorunlarını bildirmek de çok daha zordu, hatta bazı durumlarda tehlikeliydi
Sonuçta gereken şeyler birden fazla: sorunla karşılaşmak, bunun kötü olduğunu anlayacak kadar bilişimi derinlemesine kavramak, hatayı insanların bakacağı bir yere bildirecek bir araç ve bildirimin ne zaman, nasıl ele alınacağını bilen bir güvenlik kültürü
Ancak aynı cümleyi okurken merak ettiğim şey, Heartbleed, CVE-2008-0166, xz olayı gibi ciddi güvenlik hatalarının keşfedilmeden ve açıklanmadan ne kadar çok yaşandığı
Bu açık hakkında ancak yakın zamanda öğrendiğim önemli bir gerçek, bu değişikliğin aceleyle yapılmış bir iş olmadığı
Bakımcı, OpenSSL e-posta listesine gördüğü sorunu yazmış, geri bildirim istemiş ve bir düzeltme önermiş; upstream dâhil bazı yanıtlar da almış
Sonuç korkunç bir açıktı, ama daha çok herkesin sorunu kaçırdığı inanılmaz derecede kötü bir şans gibi görünüyor
Üstelik upstream OpenSSL kodu tanımsız davranış çağırıyordu. Bu yüzden derleyici Debian bakımcısının yaptığıyla birebir aynı dönüşümü yapsa bile bu geçerli olabilirdi
O zaman bu kulağa akademik bir tartışma gibi geliyordu. Derleyici herhâlde bu kadar kötü niyetli davranmaz diye düşünülüyordu
Sonrasında tanımsız davranıştan tamamen kaçınılması gerektiği daha iyi anlaşıldı
Ve 8 yıl sonra Heartbleed keşfedilince herkes OpenSSL’in ne kadar kötü bakım gördüğünü bir anda fark etti
Savunmak gerekirse bu neredeyse gönüllü emeğe dayanan bir işti; neyse ki sonrasında gelen finansmanla durum düzeldi
Güvenlik açısından kritik bir rastgele sayı üreteci koduysa, devasa miktarda rastgele sayı üretip hepsinin benzersiz olduğunu doğrulayan bir test gerçekten gerekli görünüyor
Böyle şeyleri okuyunca, popüler Bitcoin donanım cüzdanlarından birinin seed üretim işlevinde de bunun zaten yaşanmış olma ya da ileride yaşanma olasılığının ne kadar olduğunu merak ediyorum
Ve sonuçlarının nasıl olacağını da merak ediyorum
Son 22 ay boyunca Unciphered, tarayıcı tabanlı kripto para cüzdanı üretiminde yaygın kullanılan BitcoinJS’i ve bu yazılımla oluşturulan ürün ve projeleri etkileyen bir güvenlik açığıyla ilgilendi
Yıllar içinde bu açık, kayda değer sayıda savunmasız kripto para cüzdanının üretilmesine yol açtı
SSH açığında, erişmeye çalıştığınız sunucunun kötü parmak izlerinden birine sahip olup olmadığını aktif olarak kontrol etmeniz gerekir; cüzdan tarafında ise ağ üzerinden otomatik olarak başkalarının fonlarına erişebilir hale gelirsiniz
Ancak o durumda bunun kasıtlı olarak eklenmiş olma olasılığı düşük
Mevcut teknolojiyle yüz milyonlarca yıllık hesaplama süresi gerekebilir, ama neredeyse sınırsız parayla bu hesaplamayı birkaç hafta içinde çalıştırabilecek bir devlet aktörü için imkânsız sınırlar içinde olmayabilir
Sonunda adresi bilen herkesin tüm cüzdanlara erişebileceği bir zaman gelebilir
Aklı ve parası olan birinin hedefi olabiliyorsanız, Bitcoin değer saklamak için pek güvenli değil
“Ezra Zygmuntowitz beni GitHub’a bağladı ve GitHub ekibiyle birlikte sorunun derinine inmem için zaman sağladı” cümlesi komik
Anadili İngilizce olmayan biri olduğum için mi bilmiyorum, GitHub ekibinin kendisinde büyük bir sorun varmış gibi de okunuyor; sonraki cümlelerin bunu kurcalayacağını sandım
“Luciano bulmasaydı ne kadar zaman sonra keşfedilirdi merak ediyorum” kısmına gelince, muhtemelen buna tesadüfen yalnızca GitHub ya da büyük bulut sağlayıcıları gibi yerler denk gelirdi
Çünkü kullanıcı anahtarlarını binlerce, on binlerce saklayan yer çok değil
Cümleyi
(sorunun derinine inmek) (GitHub ekibiyle birlikte)şeklinde mi, yoksa(GitHub ekibiyle ilgili sorunu) derinlemesine incelemekşeklinde mi okumak gerektiği meselesidirBunu doğru ele almak oldukça zor bir iş olarak bilinir
Anladığım kadarıyla OpenSSL rastgele sayı üreteci, başlatılmamış stack belleği ve PID ile seed ediliyordu; Debian ise yalnızca PID ile seed edilecek hale getirdi
Ama Debian yaması olmasaydı bile zaten epey tehlikeli değil miydi?
OpenSSL kodunda bayt bloklarının kopyalandığı iki nokta vardı; bunlardan biri başlatılmamış çöp değerleri kopyalayabiliyordu. Bu gerçekten hatalıydı
Birisi bunu düzeltmek için bir yama yazdı; ardından LLM yardımı olmadan, tamamen insan beceriksizliğiyle biri “yakında benzer bir kopyalama daha var, bunu da kaldırmalıyız” dedi
Debian, iki değişikliği de içeren yamayı uyguladı
Sonuçta OpenSSL artık hiçbir bayt kopyalamaz hale geldi
Başlatılmamış veri kopyalanmıyor, bu iyi; ama gerçek rastgele entropi de havuza kopyalanmıyor. Eyvah
“Çeşitli olası çözümleri değerlendirdikten sonra, en az kötü seçeneğin OpenSSH’yi yamalayarak anahtarları, anahtar parmak izlerini indeks olarak kullanan bir MySQL veritabanında aratmak olduğu sonucuna vardık” kısmında, neden sqlite değil de MySQL’di?
~/.ssh/authorized_keys erişimini hızlandırmaya çalıştıkları bir durum; tam da MySQL’in parlaması için tasarlanmış gibi görünen bir kullanım
OpenSSH’yi ~/.ssh/authorized_keys.db’yi kontrol edecek şekilde yamalamak, MySQL kullanacak şekilde yamalamaktan daha az iş olurdu gibi geliyor
MySQL’in zaten çalışıyor olma olasılığı da yüksek. Öyleyse verileri oraya koymanın başlangıç maliyeti de olmazdı
Zaten kullanıcı veritabanı bir yerlerde mevcut olmalıydı
Az sayıda zayıf anahtarın bulunmasından ayrı olarak, yavaş SSH oturum açma sürelerinin çeşitli nedenlerle çekiştirilmeye değer bir ipucu olması ilginç
Bir başka ilginç olay da, ortak
pveyaqçarpanına sahip RSA anahtarlarını en büyük ortak bölen kullanarak tespit etme örneği: https://factorable.net/weakkeys12.extended.pdfGitHub’ın hâlâ yamalı openssh çalıştırıp çalıştırmadığını merak ediyorum
Bir GitHub Enterprise kopyası satın alıp dosya obfuscation’ını kaldırarak etrafa bakabilirsiniz. Obfuscation’ı çözmek eğlenceli bir meydan okuma ve çok da zor değil
Ne yazık ki açık kaynak olmadığı için kodu paylaşamaz, hakkında konuşamaz ya da GitHub’a linkleyemezsiniz
Yine de GitHub Enterprise hâlâ böyle bir yama kullanıyorsa, gerçek üretim GitHub’ın da kullanıyor olma ihtimali yüksek
~/.ssh/authorized_keysiçine koyma yöntemine dönmemişlerdirgithub.comüzerindeki 22 numaralı porta telnet ile bağlanırsanız sürüm dizesi hemen yazdırılıyorDüzelteyim: Başta golang demiştim ama kontrol edince golang kullananın Bitbucket olduğunu gördüm