Kategori arşivi: Genel

Tedarik Zincirinin Zayıf Yanlarını Belirleme

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 BulutBulut BilişimGüvenlik Açıkları konularında yayınlanmıştır

ATPX’İ BULMA: MITRE TTP’LERİ ARACILIĞI İLE SALDIRILARI İLİŞKİLENDİRME

Güvenlik ekipleri ve araştırmacılar, siber güvenlik alanındaki en güncel bulguları öğrenmek için kamuya açık olarak sunulan araç, rutin ve davranış analizlerine bel bağlıyor. Yayınlanan bilgiler, gelişmiş sürekli tehditlere (APT’ler) karşı savunma araçlarının kurulumu ve ilgili sektörlerde meydana gelmesi olası saldırıların önlenmesi için bilinen taktik, teknik ve prosedürlere (TTP’ler) referans oluyor.

Bununla birlikte, bir saldırıya karşı savunma yollarını teorik olarak bilmekle bunları ilk elden deneyimlemek arasında çok büyük fark var. Yayınlanan rutinler, araçlar ve davranışlar, hedef alınan her şirket veya sektör için suç gruplarının uygulamalarından farklı olabilir. Dahası, bu fark büyük ölçüde güvenliği ihlal edilen şirketlerin araştırılan ortamına dayanır. Araştırmaya ve giriş yollarına ayrılan çabanın ve kaynakların miktarı göz önünde bulundurulduğunda, bu tehdit oyuncularının her defasında farklı bir yöntem bulacağı, gözlem yaparken gizli kalacakları, komutları gizlice gönderip bilgi alacakları, trafiklerini maskeleyecekleri ve mümkün olduğunca uzun bir süre daha çok sayıda cihaza bulaşacakları kesindir. İşte bu noktada araştırmacılar, analistler ve teknolojik çözümler devreye giriyor.

Sunucularından birinde şüpheli bir komuta kontrol (C&C) trafiği tespit eden bir güvenlik ekibi, şirketin sistemlerindeki bu trafiği incelememiz ve analiz etmemiz için bizi aradı. Disk ve bellek görüntüleri dahil olmak üzere geri bildirim ve etkinlik günlüklerini incelememiz için sınırlı sayıda makineye ve veriye erişimimiz sağlandı. Ancak, bir uç nokta tespit ve yanıt (EDR) çözümü veya bir katmanlar arası tespit ve yanıt (XDR) çözümü olmadan, muhtemelen erişilemeyen sistemin ortamında çalışan ve keşfedilmemiş tüm örnekleri ve araçları toplamanın yolu yoktu. Bu durum, incelemeyi yapan güvenlik ekiplerinin tam bir harita çıkarıp saldırının niteliklerini görmesini engelledi.

Kapsam ve Ön Analiz

Günlüklerin ilk analizine göre, toplam 62 makineye virüs bulaştı. Bunlardan 10’u sunucu, 13’ü dosya kazıma ve veri sızdırma becerisi olan ikililere sahip makineler, 22’si arka kapı muhafazası olan makinelerken, geri kalanı ise saldırıda istismar edilen kötü niyetli ikililerin yüklenmesini sağlayan diğer araçları ve normal uygulamaları barındırıyordu.

Arka kapı saldırganın cmd.exe kullanarak komutları çalıştırmasına izin verir. Kullanıcı hesaplarını ele geçirmek için Mimikatz gibi uygulamalar kullanıldı. Virüs bulaştırılacak diğer makinelerin bulunması için kullanılan ağ tarama araçları, arka kapının diğer araçları uzaktan bırakmasına olanak tanıyan kötü niyetli bir ağa dahil edildi. Uzaktan bırakılan yürütülebilir dosyanın çalıştırılması için zamanlanmış bir görev oluşturuldu ya da bir wmic süreç oluştur komutu kullanıldı. Birçok durumda arka kapı kopyaları bırakılırken, bırakılan ve yürütülen araçlar da çeşitliydi.

Saldırganlar çoğunlukla PDF ve Microsoft Office dosyaları gibi belge dosyalarının peşindeydi. Ayrıca, ikililerin zaman damgalarına ve virüsün bulaşma yaygınlığına bakıldığında, bu saldırıların birkaç yıldır devam ettiği söylenebilir. MITRE ATT&CK ile bulduğumuz rutinleri ve araçları karşılaştırdığımızda, gözlemlenen tekniklerin hem APT32 hem de APT3 ile eşleştiğini, ancak birkaç tekniğin farklı olduğunu ve ilişkilendirilemediğini gördük.

Analiz ve Nitelendirme

Tekniklerin çeşitliliğini nedeniyle, en çok sayıda kuruluma sahip olan beş uç nokta hedefinden faydalanarak rutinlerin kullandığı ve bağlandığı araçları ve ilişki kümelerini analiz ettik. Altı tür veri sızdırma aracı, altı arka kapı ve çeşitli amaçlarla kullanılan beş farklı araç tespit ettik. Bu araçların çoğu, MySQL arka uç veritabanına sahip belge yönetimi sistemi gibi şirketin barındırdığı çeşitli sistemlerden ve yazılımlardan istifade etti. Ayrıca, araçları kötü amaçlı rutinlere bağlayan altı ilişki kümesi ve APT gruplarının ve alt gruplarının önceden belgelenen girişimleriyle eşleştirilebilecek olan dört izinsiz giriş seti bulduk. Bu araçları ve ilişkileri “Finding APTX: Attributing Attacks viaMITRE TTPs” başlıklı makalemizde ayrıntılarıyla anlatıyoruz.

Saldırıyı yaptığını düşündüğümüz gruplar, çeşitli araçlar kullanıyor ve daha önce diğer araştırmacıların yayınladığı diğer gruplarla güçlü bağlantıları bulunuyor. Araçların paketlenme biçimi veya “açıklayıcılığı” arasındaki tezatlara bakıldığında yazı stillerinin de çok değişiklik gösterdiği görülüyor. Ayrıca, her bir izinsiz giriş setindeki veri sızdırma süreçlerinde görülen yedekler, hedefin sürekli bilgi çalma, veri güncellemeleri ve sistemde gizli kalarak uzun süre mevcudiyet olduğu düşünüldüğünde hiç de şaşırtıcı değil.

Her ne kadar bir talihsizlik olsa da mağdur kuruluşlar, referans olarak kullanabilecekleri ihlal göstergelerini (IOC’ler) belirleme konusunda benzersiz bir konuma sahipler. Günümüzde mevcut teknoloji çözümleri (EDR ve XDR gibi) göz önünde bulundurulduğunda, tanımlanmayan günlükler, izinsiz girişin eksiksiz bir haritasının oluşturulması için gereken eksik bağlantıları kanıtlayabilir ve tespit edebilir.

Bu çözümler, saldırının nasıl meydana geldiğini tanımlamak ve bu etkinlikleri yeniden oluşturmak için ihtiyaç duyulan zamanı kısaltabilir. Yine de güvenlik ve inceleme ekiplerinin işbirliği, özellikle saldırıdan sorumlu grupların bulunması bakımından tehditlerin tanımlanmasında, önlenmesinde ve azaltılmasında önemli bir rol oynar. Süreç çok açık olmasa da kullanılan tekniklerin ve araçların belirlenmesi, etkinlikler ve araçlar arasındaki ilişki belirlendiğinde güvenlik ekiplerinin tüm şirket yapısını savunmalarını sağlayabilir.

İncelememizin tüm teknik ayrıntılarını ve analizlerini okumak için “Finding APTX: Attributing Attacks via Mitre TTPs” başlıklı makalemizi indirin.

Yönetimli Tespit ve MüdahaleAraştırmaGelişmiş ve Israrlı TehditlerSiber SuçSiber GüvenlikKurumsalOlay yanıtıMDRMITRE ATT&CKyazılarında yayınlanmıştır.

Yazanlar: Lenart Bermejo (Tehdit Mühendisi), Gilbert Sison(Siber Tehdit Avlama Teknik Yöneticisi) ve Buddy Tancio(Olay Yanıtı Analisti)

2020 yılında ABD’yi vuran siber saldırı: Sunburst

Geçtiğimiz günlerde, ABD’de 3 binden fazla çalışanı olan ve yaklaşık bir milyar dolarlık yıllık gelire sahip global yazılım şirketi SolarWinds’ın uğradığı geniş kapsamlı siber saldırı, tüm siber güvenlik camiasında büyük ses getirdi. Dünya çapında binlerce şirkete ve devlet kurumuna hizmet veren Solarwinds’a yapılan saldırı, saldırganların şirketin en popüler ürünlerinden Orion adlı IT yönetim ve izleme yazılımının güvenlik açığından faydalanarak ürüne Sunburst isimli zararlı yazılımı yerleştirmesiyle başladı. Böylece Orion’u kullanan binlerce kurum, ürünü güncelledikleri anda yüklenen zararlı yazılımı sistemlerine yüklemiş oldular.

“Tedarik Zinciri Saldırısı” olarak nitelendiriliyor

SolarWinds’ın toplam 300 binden fazla müşterisinin, aralarında devlet kurumlarının da bulunduğu 33 bine yakını Orion ürününü kullanıyor. Şirket tarafından yapılan açıklamada, Solarwinds’ın IT yönetim ve izleme ürünü Orion’u güncelleyen 18 bin müşterisinin bu saldırıdan etkilendiği belirtildi. Üretici firmanın tek bir ürününe yerleştirilen zararlı yazılımla bu ürünü kullanan tüm müşterilerin sistemlerine sızıldığı bu tür saldırılar tedarik zinciri (supply chain) saldırısı olarak adlandırılıyor. Solarwinds’ın Orion ürününe yapılan bu saldırı da binlerce kurumu etkileyen bir saldırı olması nedeniyle “Tedarik Zinciri Saldırısı” olarak lanse edildi.

Okumaya devam et

Siber Saldırganlar Yapay Zekayı Nasıl Kullanıyor?

Avrupa Polis Teşkilatı (Europol), Birleşmiş Milletler Bölgelerarası Suç ve Adalet Araştırma Enstitüsü (UNICRI) ve Trend Micro, mevcut ve olası yapay zeka (AI) tehditlerini ve bu tehditlerle nasıl mücadele edilmesi gerektiğini ortaya koyan bir rapor yayınladı. Raporda yapay zeka teknolojisinin siber saldırganlar tarafından Deepfake ve başka pek çok zararlı yazılımda nasıl kullanıldığı detaylı bir şekilde incelendi.

Okumaya devam et