Tedarik zincirindeki zayıf noktalara sürekli olarak kötü amaçlı saldırılar gerçekleştirilmektedir. Tüm saldırılar gibi, bu saldırılar da daha gelişmiş şekillere bürünebilir. Risklerle karşılaşılabilecek birden çok aşaması bulunan yazılım geliştirme çalışmaları ise nispeten daha savunmasızdır.
Meşhur Orion Solar Winds vakası, hem siber güvenlik topluluğunda hem de kamuda büyük yankı uyandırırken tüm dünyanın dikkatini tedarik zinciri saldırılarına çekti. Söz konusu saldırılar yeni değil, hatta bu tür tehditler epeydir oldukça yaygın. Bu saldırılar da tüm saldırılarda olduğu gibi gelişmiş formlar alıyor. Bu makalede bu tür saldırıların örneklerini inceleyecek ve olası yeni senaryolara bakacağız.
Zayıf Halkalar Nerede?
Öncelikle tedarik zincirine somut bir tanım getirelim. Genel tanım, “bir ürünü müşteriye sunma süreci” şeklinde. Bilgisayar dünyasında ise bu tanımdaki ürünün karşılığı, geliştirilen yazılım oluyor. Bu nedenle, öncelikle yazılım geliştirme sürecinin kendisini mercek altına alalım.
Yazılım geliştiriciler, hangi yöntemi kullanırlarsa kullansınlar karmaşık projeleri daha basit görevlere bölmek zorundadırlar. Böylece görevler tanımlandıktan sonra istenilen sorun izleme yazılımında belirli geliştiricilere atanabilir. Ardından yazılım geliştirici bir kod yazar ve bu kodu test edip değişiklikleri kaynak kod yönetimi (SCM) yazılımına aktarır.
Kod, sürekli entegrasyon ve sürekli teslimat (CI/CD) hattında işlenir. Bu hat; derlemeler, testler ya da proje tercihinin son devreye alımını gerçekleştirmek üzere belirli görevleri yürütür.
Tanımlanan tedarik zinciri sürecimizin her adımında kendine özgü güvenlik riskleri ve etkileri bulunur. Örneğin, bazı güvenlik ihlalleri sorun izleme yazılımını kullanan kötü amaçlı kullanıcılardan kaynaklanabilir. Bu kullanıcılar, güvenlik bilgilerinden fayda sağlayan şirket içerisindeki öfkeli kişiler veya güvenlik açıklarından istifade eden herhangi biri olabilir. Bu senaryolar gerçekleşebilir, ancak zincirde başka birçok adım olduğu için etkisi muhtemelen küçük olacaktır. Tedarik zincirinin diğer bölümlerinin kötü amaçlı görevlerden etkilenme olasılığı oldukça yüksektir. Bu nedenle, bu senaryo üzerinde çok fazla durmayacağız. Ancak kimlik doğrulaması için bir istisna yapalım.
Bütün tedarik zincirinin gücü ve dayanıklılığı en zayıf halkalarına bağlı olduğundan, güvenlikle ilgili en iyi uygulamaların göz ardı edilmesi (parolaların tekrar kullanılması veya düzgün kimlik doğrulama mekanizmalarının eksikliği gibi) kötü amaçlı oyuncuların sistemlere erişebileceği ve saldırının etkisinin daha büyük olabileceği anlamına gelir.
Yazılım Geliştiriciler ve SCM
Zincirin diğer bir ayrılmaz parçası, kod yazması için kendisine ihtiyaç duyulan geliştiricidir. Zayıflık ve olası bir güvenlik riski olarak insan faktörünü göz önünde bulundurmak gerekir. Geliştiricinin yerine makineleri koyalım, demiyoruz, ancak geliştiricileri karşılaşabilecekleri riskler konusunda eğitmeliyiz.
Son zamanlarda, tehdit oyuncularının güvenlik açıklarını araştıran kişileri hedef aldıklarını gözlemliyoruz. Teknik bakış açışıyla, bu tehdidin bir Visual Studio proje dosyasında ve spesifik olarak ön derleme olayında gizlenmiş olup PowerShell destekli bir yükte ortaya çıkması ilginçtir. Bu senaryodan öğrenilecek dikkate değer iki bağlantı vardır. Birincisi “meslektaşlar” arasındaki güven düzeyi, ikincisi ise daha kaynak kodunun daha fazla benimsenmesi ve üçüncü taraf proje entegrasyonlarıdır. Hangi kaynak kodunun ve hangi projelerin entegre edileceğine dikkat edilmelidir. Bunun için kullanılan kodun, yazılımın, eklentilerin veya konteynerlerin kaynağının doğrulanması gerekir. Daha önceki çevrimiçi kod yazma platformlarına ilişkin makalelerimizden birinde sorunları ele almıştık.
Geliştiricinin zincirin sonraki bölümü olan SCM’ye de erişimi vardır. Bunun için giriş bilgileri gereklidir ve her erişimde bu bilgilerin tekrar tekrar girilmesi can sıkıcı olduğundan bu bilgiler depolanırlar. Bilgilerin depolanması, sızma riskini de beraberinde getirir ve şifrelenmemiş şekilde depolandıklarında saldırının etkisi daha büyük olur.
DevOps topluluğunda yaygın bir davranış biçimi görüyoruz: Geliştiriciler, hizmet simgeleri, kullanıcı adları ve e-posta adresleri gibi bilgileri şifrelenmemiş şekilde depoluyor (örneğin, metin tabanlı yapılandırma dosyaları veya çevresel değişkenler).
Şekil 2. Giriş bilgilerinin ve simgelerin “güvenli” ortamlarda düzyazı (plaintext) içinde depolanmasına bir örnek
Bu güvenlik meselelerini konuşmak lüzumsuz gibi görünse de bir zincirin en zayıf halkası kadar güçlü olduğu klişesinde doğruluk payı vardır. Bu nedenle de riskleri azaltan önlemler (örneğin parola kasaları kullanmak), üzerinde düşünülmeye değer konulardır.
Şekil 3. Kaynak kodda sabit kodlu düzyazı giriş bilgilerinin kullanılmasına bir örnek
Özünde, geliştiriciler sabit kodlu giriş bilgilerini SCM’yeaktarmamalıdır. Örneğin, kod olarak altyapı (IaC)kullanırken, giriş bilgilerini depolamayı genel olarak göz önünde bulundurmalıdırlar.
CI/CD Hattı
Zincirin sonraki parçası CI/CD hattıdır. Jenkins, GitLab, TeamCity, Azure DevOps gibi tanıdık isimlerin yer aldığı yazılım tedarikçileri arasında yoğun bir rekabet vardır.
CI/CD yazılımının içindeki hat aşağıdakilere bölünebilir:
Şekil 4. CI/CD Hattı
Sistem Erişimi
Güvenlik açısından bakıldığında, bu tür sistemlere erişimin sınırlanması ve herkese erişim izni verilmemesi gerekir. Bu sistemler kurumsal ağda gizlenmeli, yalnızca belirli rollerdeki ve belirli erişim haklarına sahip kullanıcılar tarafından erişilebilir olmalıdır. Güvenlik açıkları söz konusu olabileceği için basit bir şekilde internete erişmek bile bir güvenlik riskidir ve bu durum, daha önce de şahit olduğumuz gibi tehdit oyuncuları tarafından aktif olarak istismar edilebilir.
Sistem Yapılandırılması
Yanlış yapılandırma da güvenlik riskine ve ilgili sorunlara neden olabilir. Belirli ortamlar için belirli yapılandırmalar gerekir. Örneğin, bir kuruluşta birden çok kullanıcının sisteme erişmesi gerekir, ancak herkesin rolü farklıdır. Bu durumda role dayalı güvenlik yapılandırması gereklidir. Bununla birlikte, daha önce Jenkins vakasında da açıkladığımız gibi, bu yapılandırmalarda bazı tuzaklar bulunur. Yazılımın ve yapılandırma seçeneklerinin giderek karmaşık bir hal almasıyla birlikte, yazılımın yanlış yapılandırmalara karşı test edilmesi ısrarla tavsiye edilir.
Kaynak Kodun Alınması
Burada iki modelden söz edebiliriz:
Azure DevOps sunucusunda olduğu gibi SCM CI/CD hattına entegre edilir
SCM farklı ortamlarda çalışır; bu nedenle erişim belirteçlerinin veya giriş bilgilerinin sistemin içinde depolanması gerekir
Kaynak kodu bilgilerinin açığa çıkması kötü amaçlı kaynak kodu modifikasyonlarına neden olabileceği için yazılımın kaynak kodu giriş bilgilerini nasıl depoladığı çok önemlidir. Bununla birlikte, CI/CD yazılımında güvenli olmayan uygulamalardan faydalanıldığını da gördüğümüzü ve üçüncü taraf uzantılarında şifrelenmemiş giriş bilgisi depolama zafiyetlerini keşfettiğimizi (Jenkins eklentileri vakasında olduğu gibi) söylememiz gerekir.
Derleme Ortamının Yapılandırılması
Buradaki güvenlik konuları elbette giriş bilgilerinin aktarılmasıyla ilgilidir. Şifrelenmemiş giriş bilgilerinin ve depolarının derleme varlıklar halinde aktarılması riski vardır. Esas olarak, bazı yapılandırma ön koşulları, bir derlemeden sonra genellikle geride bırakılacak olan hassas bilgileri içerir.
Derleme
Bu adımda asıl kaynak kod hedeflenen ikili formda derlenir. Solar Winds ve CCleaner vakalarında bu aşamada saldırılar olduğunu gördük. Saldırganın bu aşamada saldırı düzenlemesinin mantıklı nedenleri vardır. Birincisi, bu aşama tedarik zincirindeki son adımlardan biri olduğu için sonrasında çok fazla doğrulama olmayacaktır. İkincisi, üretilen yürütülebilir ikililer günümüzde genellikle dijital olarak imzalanır. Bu da kodun imzalanmasından sonraki kod modifikasyonlarının tamamı için geçerli bir dijital imza mümkün olmayacağı anlamına gelir. İkilinin sağlaması eşleşecektir ve özel bir anahtarla şifrelendiği için bu bilgi olmadan geçerli bir sağlama üretilmesi mümkün olmayacaktır. Bu nedenle derleme süreci, tedarik zinciri saldırıları için uygun bir hedeftir. Bununla birlikte, yazılımların hepsi dijital bir imza ile gönderilmez.
Dijital imzadan söz ederken, sertifikanın özel anahtarını gizli tutma ihtiyacını vurgulamamız gerekir. Bu özel anahtarın ele geçirilmesi, saldırganların istedikleri yazılımı söz konusu sertifikayla dijital olarak imzalayabilecekleri anlamına gelir ve bu nedenle bu anahtar iptal edilmelidir.
Devreye Alma veya Ürün Teslimatı
Zincirin CI/CD hattına ekleyebileceğimiz son parçası devreye almadır. Öncelikle, devreye alma süreci CI/CD yazılımında belirlenebilir ve başarılı bir derleme veya test üzerine tetiklenebilir. Bu yüzden, mimari bilgilere giriş bilgileri ve diğer hassas bilgilerle birlikte buradan ulaşılabilir. Bu nedenle, düzgün şekilde yönetilmeleri gereklidir.
Bir saldırgan için en kolay yol yazılım ürününü tamamıyla değiştirmektir. Ayrıca, kötü amaçlı kodlar enjekte edilebilir ve bu, belirli uygulamalar için uygundur (dijital olarak imzalanmaz). Örneğin, WordPress tabanlı web sitelerindekötü amaçlı kod parçalarının bir güvenlik açığından veya güvenlik zayıflığından faydalanılarak eklendiği kod enjeksiyonu saldırılarıyla karşılaşabiliriz.
Yürütülebilir bir ikili kod enjeksiyonu da mümkündür, ancak bu tür bir saldırı derlenen ikiliye ve saldırganın becerilerine bağlıdır. Ayrıca ikili dijital olarak imzalanırsa saldırı kolaylıkla keşfedilebilir ve etkili değildir. Basitçe ikililerin değiştirilmesi saldırganlar için daha kolaydır. Bununla birlikte, ikilinin depolandığı teslimat sunucusunun (kullanıcıların asıl yazılım ürünlerini indirmelerine olanak tanıyan sunucular) hack’lenmesi kolay bir iş değildir ve önemli kaynaklar gerektirir. Bunun yerine; kimlik avı, dolandırıcılık kampanyaları veya DNS sahtekarlığı saldırıları gibi taktikler kullanılmakta ve bilinen yazılım markalarının (hatta güvenlik tedarikçilerinin) kötü amaçlı veya aldatıcı yazılım yüklerinden istifade edilmektedir.
Sonuç
Bu blog yazısı, tedarik zinciri güvenliğine ilişkin temel konuları ana hatlarıyla açıklar. Bu tür saldırıların neden olduğu sorunlar bir yazıda anlatılamayacak kadar karmaşıktır. Yıllık tahminlerimizde daha önce bahsettiğimiz gibi kuruluşların 2021 yılının sonuna kadar iş yüklerinin çoğunu bulutta çalıştırmaya başlamış olacakları tahmin ediliyor. Bu nedenle bu konunun bir an önce ele alınması gerekiyor. Karşılaşılan sağlık krizi sonucunda birçok kuruluş güvenlik endişelerinin kapsamını tam olarak anlamadan yeni yazılımları aceleyle benimsiyor.
Belirlenen tedarik zinciri saldırılarıyla ilgili daha fazla bilgi edinmek için bu GitHub sayfasını ziyaret edin.
Sanallaştırma ve Bulut, Bulut Bilişim, Güvenlik Açıkları konularında yayınlanmıştır