2022 sona ererken, son olaylar bir istisna değildir: sırların sızma riski yüksektir.
Eylül ortasında, araç çağırma şirketi Uber, bir Powershell komut dosyasında sabit kodlanmış yönetici kimlik bilgilerini bulduktan sonra birkaç kritik dahili sisteme girmeyi başaran bir saldırganın raporlarını doğruladı. Sırlar, diğer birçok kimlik bilgisinin saklandığı Uber’in ayrıcalıklı erişim yönetimi platformunda oturum açmaya izin verdi: Saldırgan böylece AWS, GCP, Google Drive , Slack, SentinelOne, HackerOne ve daha pek çok yönetici hesabının kontrolünü ele geçirebildi.
Birkaç hafta sonra, otomotiv devi Toyota, yaklaşık beş yıl boyunca halka açık bir GitHub deposundaki müşteri verilerine erişmek için bir kimlik bilgisi anahtarını yanlışlıkla ifşa ettiğini açıkladı. Anahtarın geçersiz kılındığından emin olmalarına rağmen, bu kadar uzun süre maruz kalma, birden fazla kötü niyetli kişinin anahtara zaten erişmiş olduğu anlamına gelebilir.
Milyonlarca sır ortaya çıktı
Sırlar (kullanıcı adları ve parolalar, API belirteçleri, şifreleme anahtarları vb.), doğru kimliklerin (insanlara veya makinelere ait olsunlar) doğru zamanda doğru şeye erişmesine izin verdiği için güvenliğin temel taşıdır. Güvenlik, bir kuruluşun çevresinin güvenliğini sağlamakla ilgili olduğunda, sırlar yüksek düzeyde korunur ve çoğu geliştiricinin ve diğer BT uzmanlarının erişemeyeceği bir yerde tutulurdu. Geliştirme ve operasyonlar tamamen ayrı alanlar olduğu sürece, “taç mücevherlerini” güvende tutmak nispeten kolaydı.
Ancak DevOps ve çevik uygulamaların ortaya çıkmasıyla, hiper bağlantılı sistemler çevre güvenliği kavramını tamamen alt üst etti. Birbirine bağlı yazılım bileşenlerinin sayısı arttıkça, bunların iletişim kurmasını sağlamak için gereken sırların sayısı da artar. Yazılım bileşenleri arasında veritabanları, oluşturma veya çalıştırma sırasında kullanılan üçüncü taraf bileşenleri, mikro hizmetler vb. bulunur. Artık yazılım geliştirme yaşam döngüsündeki herkes ve her varlık sırları kullandığına göre, sırlar artık kıt bir kaynak değildir. Mekanik olarak da bir yerde gizli sızıntı olma olasılığı daha yüksektir.
Böylece 2021’de “dünyanın yazılım geliştirdiği” yer olan GitHub’da altı milyondan fazla sır açığa çıktı. Bu sayı 2020’ye göre ikiye katlandı. Ortalama olarak 1.000 taahhütten 3’ü, geçen yıla göre %50 daha fazla hak talebinde bulundu. Bu sırların çoğu doğrudan bulut hesapları, web sunucuları veya genel sertifikalar gibi kurumsal kaynaklarla ilgilidir ve çok daha fazlası bir çalışanın kimliğine bürünmek veya ayrıcalıkları yükseltmek için kullanılabilir.
Bu durum hackerlar için açıkça bir nimettir. Sırlar orada, istismar edilmeye hazır.
Çeşitli raporlar sorunu vurgulamıştır: En son DBIR raporuna göre, “çalınan kimlik bilgilerinin kullanılması” web uygulamalarına girmenin en yaygın yoludur. İhlallerin %80’inden fazlasını oluştururken, “güvenlik açığı istismarları” vakaların %20’sinden azını oluşturur. Rapor, bunu “bir dizi saldırgana hitap eden düşük maliyetli, yüksek kazançlı bir strateji” olarak adlandırıyor.
Kod tabanlarına dağılan sırlar sorunu katlanarak büyüyor. Ancak uygulama güvenliği bu tehdide yanıt vermede geride kalmıştır. Nedenini anlamaya çalışalım.
Uygulama Güvenliği Manzarasındaki Sırlar
Uygulama güvenliğinin odak noktası, geleneksel olarak Siteler Arası İstek Sahtekarlığı (CSRF), Sunucu Tarafı İstek Sahtekarlığı (SSRF) veya kaynak kodundaki mantık kusurları gibi güvenlik açıklarını bulmak olmuştur. Bu güvenlik açıkları her zaman bir uygulamanın geçerli ve dağıtılmış durumunda ortaya çıkar.
Sırlarla hikaye farklıdır. Yanlışlıkla sabit kodlanmış bir sırdan yararlanılabilmesi için yazılımın çalışır durumda olması gerekmez. Aslında, bu kusur, çalışan kodda bulunmasa bile tehlikeli olmaya devam edecektir!
Geliştiriciler kod üzerinde işbirliği yaptıklarında, bir sürüm kontrol sistemi kullanırlar – bugün neredeyse her zaman git. Bu araç, hatalar da dahil olmak üzere her kaynak kodu revizyonunun kaydını tutar; bu, geçerli bir sırrın kodun hiç dağıtılmamış bir sürümüne sabit kodlanabileceği ve kodun temel kopyalandığı sıklıkta çoğaltılabileceği anlamına gelir. Kimlik bilgileri, kurumsal BT çevresi içinde veya dışında, uygulama güvenliğinin yetişebileceğinden çok daha hızlı bir şekilde bu şekilde genişleyebilir.
Sabit kodlanmış kimlik bilgilerinin başka bir özelliği daha vardır: bunlar zamanla birikir. Geliştiriciler bir proje üzerinde ne kadar uzun süre çalıştıysa (veya çalışacaksa), sırların bir noktada sabit kodlanmış olma olasılığı o kadar yüksektir. Bu olasılıklar ayrıca kod tabanının boyutu ve toplam havuz sayısı ile artar. Bu nedenle, sabit kodlanmış sırlar, teknik borçların kod incelemelerinde görünmesi, sırların görünmemesi dışında “teknik borç” gibi birikmektedir. Bunun nedeni, kod incelemelerinin yalnızca mevcut durum ile önerilen değişiklik arasındaki net farkı dikkate alması ve gizli dizilerin yanlışlıkla eklenmiş olabileceği tüm ara değişiklikleri dikkate almamasıdır.
Sonuç olarak, güvenlik borcu zamanla birikir ve belirli bir noktadan sonra bir uygulama güvenlik ekibi için yönetilemez hale gelebilir.
Geçen yıl Twitch ve Samsung kod tabanlarında arama yapıldığında, 6.500 ila 7.000 arasında sabit kodlanmış sır açığa çıkarıldı: dahili şirket e-posta şifreleri, API anahtarları bulut hizmetleri, üçüncü taraf jetonları ve diğer kimlik doğrulama bilgileri vb.
Ortalama olarak, 400 geliştiricisi ve dört AppSec mühendisi olan tipik bir şirketin kod havuzlarında ortalama 1.050 benzersiz sabit kodlanmış sır keşfedeceği tahmin edilebilir. Daha da endişe verici bir şekilde, her bir sır birden çok kez (ortalama 13) sabit kodlanmıştır ve bu da uygulama güvenlik ekibi için kodu düzgün bir şekilde “temizlemek” (veya en azından her vakayı araştırmak) için gereken çabayı artırır.
Sabit kodlanmış kimlik bilgilerinden nasıl kaçınılır?
İlk adım, kimlik bilgilerinin her ay sabit kodlanmasını önlemek ve “kanamayı durdurmak” için kontrolleri şimdi uygulamaktır. Gerçek zamanlı izleme, hataları olabildiğince erken yakaladığı için sırların çoğalmasını engellemenin en iyi yoludur.
Geliştirici, VCS’ye bir sır girmeden hemen önce uyarılırsa, düzeltmenin birim maliyeti bir dakikadan azdır. Tanımlayıcı yalnızca yerel iş istasyonunda açığa çıktı ve geliştirici, ekipleri için herhangi bir sonuç olmadan katkılarını değiştirmek için birkaç komut çalıştırabilir.
Öte yandan, hatalı işlem uzak depoya ulaşırsa, sır tehlikeye atılmış olarak kabul edilmelidir: aslında, bugün veya yarın okuma erişimi olan herkes bundan yararlanabilir. Bu, bir güvenlik açığı olduğu anlamına gelir. Bunu düzeltmek için sır iptal edilmeli, yenilenmeli ve kullanıldığı her yerde yeniden dağıtılmalıdır. Bu düzeltme prosedürü dakikalar, saatler ve hatta daha uzun sürebilir ve birden çok kişinin iş akışlarını kesintiye uğratır.
Ortalama olarak, iyileştirme maliyeti genellikle en az iki adam-saattir. Bunu daha önce belirtilen sayılara uygularsak, ortalama durumda (2 saat x 1.050 sır) kodda sıfır sır elde etmek için en az 2.100 adam-saat gerekir. Ve bu minimumdur, çünkü gelecekte başka hiçbir sırrın sabit kodlanmayacağını varsayar.
Sabit kodlanmış sırlarla ilgili binlerce olayı araştırmak, bunlara öncelik vermek ve bunları düzeltmek, önceden bir stratejisi olmayan bir uygulama güvenlik ekibi için bunaltıcı görünebilir. Yine de bu bir ölüm değil. Küçükten başlayarak ve yeni güvenlik açıklarının birikmesini 6 veya 12 ay içinde kademeli olarak azaltarak, güvenlik mühendisleri ortalama düzeltme sürelerinin istikrarlı bir şekilde arttığını göreceğinden, kazanımlar belirgin olacaktır.
Sırlarını ihmal etme
Bugün olduğu gibi yazılım geliştirme dünyasında, sabit kodlanmış kimlik bilgilerinin kurumsal güvenliği tehdit eden önemli bir risk oluşturduğu gerçeğini kimse görmezden gelemez. Gerçekten uzun vadeli sonuçlar elde etmek istiyorsanız, güvenlik borcunuz üzerindeki kontrolü yeniden kazanmak için bugün başlamanız gerekir. Sabit kodlanmış sırlar için bu, zaman içinde birikimlerini azaltmak için artımlı kaynak kodu taramalarından yararlanmak anlamına gelir. Bu, geliştiricilerin ve güvenlik mühendislerinin bu sorunu birlikte çözmelerine yardımcı olmak için vazgeçilmez bir varlık olacaktır.
