Geç siber güvenlik uzmanı Dan Kaminsky, birçok harika araştırması ve bunu sade bir İngilizce ile açıklama yeteneği ile tanınır. Ancak arkadaşı, işbirlikçisi ve şirketin kurucu ortağı Michael Tiffany’nin Kaminsky hakkında en çok hayran olduğu şey, güvenlik üzerindeki olumlu etkileri ölçeklendirme dürtüsüydü.
“Bir mucit olarak o bir mühendisti, yani sadece fikirlerinin fikir dünyasının platonik bir düzeyinde ne kadar iyi olduğuyla değil, aynı zamanda gerçekte gerçeklikle nasıl temas kurdukları ve dünyayı daha iyi bir yer haline getirmeyi nasıl başardıklarıyla da ilgilendi. Bu etkiyi bot liderliğindeki İnternet dolandırıcılığına karşı ölçeklendirmenin bir yolu olarak Kaminsky ile birlikte Human Security’nin (eski adıyla WhiteOps) kurucu ortağı olan Tiffany,” diyor. “Bu sadece haklı olmakla ilgili değil. Bu, yeniliklerinizi gerçekten geniş çapta ölçeklenebilecek bir şekilde ona ihtiyacı olan insanlarla buluşturmakla ilgili.”
Kaminsky’nin -kendi ticari çıkarlarının çok ötesine uzanan türden- ortak yarar için yaptığı çalışmaları onurlandırmak için Tiffany ve Human ekibi, siber güvenlik iyileştirmesinde güç çarpanları olma yeteneğine sahip yeni nesil güvenlik araştırmacılarını desteklemenin bir yolunu bulmak istedi.
Bu, dünyayı umarız daha güvenli bir yer haline getirecek açık kaynaklı projeler üzerinde çalışmak üzere her yıl yeni bir üyeyi finanse edecek bir program olan Dan Kaminsky Bursu’nun yaratılması için itici güçtü. Tiffany, hibe veya ödül programlarından farklı olarak, Dan Kaminsky Bursu, araştırmacıya tam istihdam desteği ve tutku projelerini hafta sonu ve ay ışığı çalışmasından tam zamanlı bir işe kaydırmak için 12 ay nefes alma odası sağlayan ücretli bir pozisyondur.
“Hibe alanlar adına bu tür bir odaklanmanın önünde hala engeller olduğunu buldum çünkü yaşamak için çalışmaya alışkınsanız, bunun ilk kez sağlık sigortası yaptırmak zorunda kaldığını görebilirsiniz. örneğin kendin,” diyor. “Burasının harika işler çıkaran insanları bulup onları maaş, İK departmanı, vergi kesintileri, sosyal haklar ve hafif bir destek altyapısı ile bir destek sistemine sararak büyük bir etki yaratabileceğimiz bir yer olduğunu düşündük.”
Bursun bu açılış yılında, bu destek Jonathan Leitschuh’a verildi.
En son Gradle’daki güvenlik ekibi için kıdemli bir güvenlik yazılımı mühendisi olan Leitschuh, son yıllarda açık kaynak projelerinde, özellikle Apache Maven projelerinde güvenlik sorunlarını araştırıp düzelterek kendisine bir isim inşa ediyor. Çalışmalarının öne çıkan özelliklerinden biri, yalnızca bir yol yaratması değil. Git depolarına karşı toplu çekme istekleri oluşturmak için güvenlik açıklarını düzeltmek için değil, aynı zamanda hizmet şartlarında takılmadan önemli Maven proje düzeltmelerini geniş ölçekte yapmak için katılım sağlamak için GitHub’daki kişilerle koordinasyonu.
“Jonathan’ın çalışmasında beni gerçekten etkileyen şey, onun da açıkça etkiyi gerçekten ölçeklendirmenin yollarını araması ve bunu başarmak için mekanizmalarından birinin iyilik için bir güç olarak bir bot yazmak olduğu gerçeği beni eğlendirdi. “diyor Tiffany. “Şirketimizin ironik cazibesinin ötesinde değildim – efsanevi bir bot savaşçısı – aslında … bazı iyi botları finanse ediyordum.”
Dark Reading, yöntemlerini, çalışmalarını ve önümüzdeki yıl neyi keşfetmeyi umduğunu daha iyi anlamak için yakın zamanda Leitschuh ile bir tartışma yaptı. İşte bu Soru-Cevap’tan bazı önemli noktalar.
Açık Kaynak Güvenlik Açıklarının Peşine Neden Bu Kadar Yatırım Yaptı?
Leitschuh: DEHB’m var ve bazen “Oh, hey, bak, bir sincap!” Bazen gidip peşinden koştuğum bir şey. Bu, “Ooh, bak, bu güvenlik açığı ilginç görünüyor. Bu konuda daha fazla şey öğrenmek istiyorum” gibi. Sonra tabii ki daha fazlasını öğrendiğimde gidip “Tamam, bu zafiyetin hangi projelerde olduğunu merak ediyorum?” diyorum.
Sonra bu tavşan deliğinden aşağı iniyorum, “Aman Tanrım, bu güvenlik açığı binlerce projede var.” Tek bir güvenlik açığını kovalamak için altı ay gibi sağlam bir yığın harcadım. Çok sayıda projeyi geçti.
Açık Kaynak Güvenliğinde İbreyi Hareket Ettirdiği İlk Büyük Anında
Leitschuh: Peşine düştüğüm ilk büyük güvenlik araştırması, Maven ve Gradle derleme dosyalarının bağımlılıklarını HTTPS yerine HTTP üzerinden çözdüğü bu güvenlik açığıydı. Ekosistem tedarik zincirini etkileyen sektör genelindeki bu güvenlik açığıydı.
Tüm bu araştırmaları yaptıktan sonra, Dan’in birkaç konuşmasını izledim ve Dan’in zorlamak istediği bazı şeyler hakkında düşündüm. Gerçekten takdir ettiğim bir tanesi, “Kullanıcı aptal değil. Kendi ayaklarına ateş etmemelerini kolaylaştıran sistemler oluşturmamız gerekiyor.” Ayrıca, “Kullanıcı, siz düzeltmedikçe bir güvenlik açığı olduğunu bilemez.”
Bağımlılıkları çözmek için HTTP kullanımıyla ilgili bu çok uzun güvenlik araştırmasını yaptıktan sonra nihayet fark ettiğim şeylerden biri, bu güvenlik açığı vakalarının çoğunun, içeriklerini hala HTTP üzerinden sunan belirli sunuculardan kaynaklanmasıydı. HTTPS yerine.
Bu yüzden gittim ve uzandım [owners of] sunucular ve dedi ki, “Hey, suçlusun. Bu güvenlik açığının var olmasına bile izin veren zincirin bir parçasısın. Neden bunu kapatmıyoruz? Neden onu öldürmüyoruz? Kırılacak. pek çok şey, ancak birçok insanı bu güvenlik açığını düzeltmeye zorlarsınız.”
Bu şeye katılmalarını sağladım ve hepsi ilerledi ve aslında “Evet, hadi bunu düzeltelim” dediler.
15 Ocak 2020’de HTTP kullanımını kapattılar ve yalnızca HTTPS’yi desteklediler. Bir sürü yazılımı bozdu. Bir sürü yapıyı bozdu. Ancak endüstriyi güvenlik perspektifinden ilerlemeye zorladı.
Uzun Süreli Maven Sorunlarını Geniş Ölçekte Düzeltmek İçin Nasıl Bir Bot Yaptı?
Leitschuh: Bu işi yapmış olmama rağmen, diğer insanların hala bu üç büyük sunucuya bağımlı olmadığı, ancak diğer yapay sunuculara bağımlı oldukları bu güvenlik açığı hala mevcuttu. Ben, “Bu son işi nasıl hallediyorsun?” Ben de dedim ki, “Eh, savunmasız olan tüm projelerin nerede olduğunu biliyorum.” “İşte savunmasız olan tüm projeler” diyen bir CodeQL sorgusu yazdım. Bir listem vardı ve “Neden düzeltmiyorum?” dedim. Ama binlerce projeydi. Bunu tek tek elle yapamam. Ama yolu görebiliyordum. Bu, bir botla düzeltebileceğiniz, çerez kesici bir güvenlik açığıydı. “Neden olmasın?” diye düşündüm.
GitHub’daki insanlarla gerçekten harika bağlantılarım var. “Bunu yapmak istiyorum” dedim. “Şey, hayır, hizmet şartlarımız buna izin vermiyor” demek yerine, GitHub’daki insanların “Bu harika. Gidip şunu yapalım” demesini sağladım.
Toplu Güvenlik Çekme İsteği Oluşturma işlemimi yaptığımda, onu canlı olarak da yayınladım. Bu yüzden GitHub’dan insanları çektim, iş arkadaşlarım, arkadaşlar bu görüşmede ve ben tüm bunları canlı olarak yayınlıyorum. Daha sonra bana şöyle diyorlar, “Ekibimize bunun geleceğini bildiriyoruz, böylece kaçınılmaz olarak spam gönderen veya benzeri bir şey olarak rapor edildiğinde, davranış ekibimiz Jonathan’ın sektörü biraz iyileştirmeye çalıştığını önceden biliyor. “
Bu aptal, çılgın fikirlerin peşinden koşuyorum, ancak bu konuda aldığım destek sistemi muhteşemdi.
Burs Desteği Yoluyla Çalışmalarında Sırada Neler Olduğu Üzerine
Leitschuh: Yazılımda gerçekten zor olan şeylerden biri, özellikle birçok farklı şekilde yazılmış ve farklı girintilere ve biçimlendirmelere ve bunun gibi şeylere sahip olabilen kodlarda değişiklik yapmaktır. Bu kolay bir problem değil. Bu yüzden, aslında gidip bir şirket kuran eski bir iş arkadaşımla ortaklık kurdum. Bu proje denilen AçYeniden Yaz. Şirketinin adı Moderne. Adı Jonathan Schneider. Ölçekte kod yeniden düzenleme yapmanızı sağlayan bu aracı geliştirdi. Çoğunlukla, gerçekten güvenlik olmayan farklı bir soruna odaklanmıştı. Ben, “Bu, bir güvenlik sorununu çözmek için mükemmel.”
Yinelenen çok yaygın güvenlik sorunları vardır ve bunlardan bazılarının temel nedeni, [a developer] bir cevap gönderir [to] Yığın Taşması ile ilgili bir soru, “Bu şeyi nasıl yaparım?” Ve bu Yığın Taşması sorusunun en iyi yanıtı bir çözümdür, ancak bu savunmasız bir çözümdür. Gidip açık kaynağa bakacaksınız ve aynı kodun açık kaynakta tonlarca kez yeniden üretilip yapıştırıldığını, kopyalayıp yapıştırıldığını göreceksiniz. Böylece bu yaygın güvenlik açıkları çoğalabilir [in] açık kaynak. Ama gidip bu şeyleri nasıl düzelteceksin?
Güvenlik açıkları hakkındaki bilgilerimi ve bu gerçek kodu yeniden yazma yeteneklerini alıyorum ve bu tür otomatik düzeltmeler için iyi adaylar olan bir dizi güvenlik açığı bulmaya çalışmak için birlikte çalışıyorum.
Bir sürü düşük asılı meyve var. Pek çok insan bununla uğraşmak istemiyor çünkü “Ah, bu ilginç değil. Ah, bu hiç hoş değil.” Ama aslında gerçekten çok etkileyici. Bu kategoriye giren bazı güvenlik açıkları var. Bu belirli olanları nasıl yakalayıp ortadan kaldırabileceğimizi bulmaya çalışıyorum. Üstüne üstlük, eğer fırsatım olursa, düşük meyveli bazı güvenlik açıkları var, ancak bunlar düşük meyveli çünkü kodun kendisi savunmasız ve kök nedeni daha derinde.
Harici varlık işleme gibi güvenlik açıklarını bulmaya yönelik tüm bu tarama araçlarının olduğu yerlerde güvenlikte göreceğiniz bir eğilim var. [XXE]; Java, Python’daki bu güvenlik açığını bulmak için tüm bu tarama araçları var, [and] C++. Bu güvenlik açıklarının temel nedeni gerçekten kitaplıkların kendisidir ve bu kitaplıkların dayandığı temel altyapının kendileri savunmasızdır. Benim de peşine düşmeye çalıştığım şeylerden bazıları, bunun kök neden perspektifinden nasıl düzeltileceğidir.