#Veri Merkezleri Spectre Açıklarından Nasıl Korunuyor?

Bu yazımızda 2018’de büyük olay olan Spectre açığından veri merkezlerinin nasıl korunduğuna, CloudFlare tarafından uygulanan yeni güvenlik yaklaşımlarına değineceğiz.

2018 yılında teknoloji camiasını takip eden herkes biliyordur ki Spectre açıkları büyük olay olmuş, teknoloji şirketlerini ve işlemci firmalarını kökten etkilemişti. Intel, AMD ve ARM işlemcilerde tasarım kaynaklı donanımsal nedenler yüzünden ortaya çıkan bu açık kısmen yamanabiliyor, kesin çözüm için ise işlemci tasarımının değişip yeni işlemcilerin üretilmesi bekleniyordu.

Neredeyse her bilgisayar ve mobil cihazda (laptop, akıllı telefon ve bu işlemcileri kullanan diğer cihazlar) ortaya çıkan Spectre açığı büyük tehdit oluşturuyordu. Bu yazımızda Spectre açığına değinip, veri merkezleri tarafından alınabilecek önlemlere ve CloudFlare tarafından ortaya atılan güvenlik yaklaşımlarına bakacağız.

Spectre Nedir?

Spectre, Google Project Zero ekibi ve Paul Kocher tarafından tespit edilen, işlemci tasarımından kaynaklanan tehlikeli bir güvenlik açığı. Bu açık sayesinde kötü niyetli bir yazılım normalde erişemeyeceği birtakım verilere erişip, işlemcide spekülatif işlemler yapıp yönlendirebiliyor.

Açığın asıl çıkma nedeni ise işlemci üreticileri, yeni işlemcilerde performansı artırmak için bilinenin dışında alternatif yollar arayışına çıkmışlardı. Buldukları yol ise önbellek artırımı, spekülatif çalıştırma ve birden çok komut setini aynı anda çalıştırma yöntemleri olmuştu.

Spekülatif çalıştırma yönteminde işlemci, kodun daha önceki çalışmasına benzer şekilde bakıp tekrardan aynı işlemi baştan yapmak yerine önceki kayda göre çalıştırır. İşte zafiyet burada ortaya çıkmakta. Meltdown ve Spectre açıkları hakkında daha fazla bilgi edinmek için “İşlemcilerdeki Meltdown ve Spectre Açıkları Hakkında Bilmeniz Gerekenler” isimli yazımızı okuyabilirsiniz.

Peki Spectre Veri Merkezleri için Neden Tehdit?

Her ortaya çıkan güvenlik açığında olduğu gibi en çok dikkat edilmesi gereken şey verilerin güvenliği. Eğer donanım temelli bir güvenlik açığı söz konusuysa işte bu daha büyük bir sorun. Zira yazılımsal güvenlik açıkları, yazılımın yamanması yoluyla veya daha uygun yöntemler kullanılarak kapatılabilir. Donanım yüzünden ortaya çıkan güvenlik açıklarında ise işler biraz daha değişir.

Spectre, modern işlemcilerde görülen donanım temelli bir güvenlik açığıdır fakat mimariden mimariye değişecek şekilde eminiz ki henüz keşfedilmemiş birçok güvenlik açığı var. Zafiyetler her bulut ve bilişim çözümü sunan servis için büyün sorun teşkil eder. Çoğu bilgi işlem çözümünde bir aynı makine üzerinde birden fazla kod çalışır. İşte Spectre saldırılarının daha da riskli hale geldiği konumlardan birisi.

Çoğu bulut sağlayıcıda kodların çalıştırıldığı veya normal sunucu olarak kullanılan, kişiye ayrılmış alanlarda ortada gerçek bir fiziksel makine bulunur. Bu makineler HyperVisor katmanı yani sanallaştırma çözümleri ile birbirinden izole olacak şekilde ayrılmaya çalışılır. Spectre açığı donanım temelli olduğundan sunucular HyperVisor yardımıyla VM katmanları halinde ayrılmış olsa bile birbirinden etkilenebilir zira hedeflenen bölüm işlemcinin çalışmasının ta kendisi.

Bu tarz durumlarda açığı kapatmak da hayli zor hale gelebilir. Yamaların uygulanması esnasında herhangi bir aksilik çıkma ihtimaline karşın sürekli yedeklemeler ve uzun zaman alan işlerle uğraşılabilir. Aynı zamanda Spectre gibi donanım temelli güvenlik açıklarının yamanmasında yaşanacak geçici performans kaybı da göz önüne alınmalı.

Bulut sağlayıcıları ekstra güvenlik için sadece işletim sistemi ve sanallaştırma çözümlerinin yayınladığı yamalara güvenmekle kalmazlar. Müşterilerin korunması için büyük firmalar genelde kendi AR-GE’lerini kullanarak firma özelinde çeşitli stratejiler izlerler.

Örneğin dünyanın en büyük bulut sağlayıcılarından birisi olan CloudFlare tarafından sunulan “CloudFlare Workers” hizmetinde kodlarınız çeşitli konumlarda çalıştırılmak üzere hazırlanmış bir yapıda bulunur. Yalnızca kurumsal müşterilere değil, herkesin erişebilmesinin mümkün olduğu CloudFlare Workers’da kendi tabirleriyle “Birden çok müşteri ile uğraşılması” gerekiyor.

Klasik, normal bir sağlayıcı, az kaynak tüketen normal müşterinin trafiğini yalnızca tek makineden geçirerek işleyebilir. Yalnızca bu durumda uygulamanın bir kopyası yüklenir. Eğer makineniz çok sayıda kişinin hizmetinde ise bu fazladır ve maliyet bakımından birden çok makinenin bağlı olduğu merkezlerde barınması daha akıllıca olur. Bu da kişi özelinde maliyet bakımından ölçek bazında daha mantıklı olacaktır. Bu nedenle sunucusuz yani “serverless” adını verdiğimiz servisler gitgide yaygınlaşıyor. Daha fazla bilgi almak için “Serverless Nedir” isimli makalemizi okuyabilirsiniz.

Örneğin CloudFlare Workers tarafından bütün bunlara baktığımızda trafik düzeyi fark etmeksizin kiracılar CloudFlare üzerinde çalışıyorlar. Müşteriye bağlı olarak kimi zaman sınırlı sayıda sunucuların bulunduğu konumlar da seçilebilmekte. Bu gibi durumlarda ise sağlayıcılar mecburen bir makinede binlerce müşteri barındırıp, hizmet sağlamak zorunda kalabiliyorlar. Bu makinelerde çeşitli katmanlar ile ayrımlar olsa bile neticede hepsi güvenlik zafiyeti bulunan işlemci veya donanım üzerinde kodlar çalışıyor. Bu nedenle sağlayıcılar için bu açıkların kapatılması kritik öneme sahip.

Spectre Açığı İçin Gerçekte Bir Çözüm Yok

Yukarıda bulut sağlayıcılarının işleyişine uzun uzun değinmemizin nedeni gerçekte işlemcinin tasarımının değişmesi yani bizler ve sağlayıcılar için işlemci firmasının düzgün ve hatasız bir işlemci üretmesini bekleyip, işlemciyi değiştirmekten başka kesin olarak Spectre açığını kapatma yolunun olmamasıdır. Güvenlik yamaları bu açığı kısmen kapatır.

CloudFlare’in makalesinde yazdığına göre endüstrinin itiraf etmek istemediği kirli bir sır var. CloudFlare’a göre “kimse” Spectre açığını büyük sanal makineler kullanırken bile düzeltmedi. Çoğu makine halen savunmasız. Yine yazdığına göre araştırmacılar her seferinde yeni bir “Spectre” açığı tespit ediyor. Sürekli CPU üreticilerinden gelen mikrokod güncellemeleri ve işletim sistemi güncellemeleri ile bunlar yamanmaya çalışılıyor.

Peki sizce sürekli bu güncellemeleri yapmak güvenlik için yeterli mi? Gerçek hayatta bilinen o ki birçok firma üzerinde baskı hissetmediği sürece kamuoyuna zafiyetleri açıklamıyor. Gizlenen bu zafiyetler, Zer0day avcıları ve güvenlik araştırmacıları, yetenekli bilgisayar kurtları tarafından çoğunlukla bulunuyor. Güvenlik açığı pazarında çoğunlukla devletler, çeşitli özel siber güvenlik şirketleri, istihbarat kurumları tarafından bu zafiyetler satın alınıyor. Aynı şekilde firmaların açıklamadığı onlarca ve belki yüzlerce zafiyetin üzerinden tekrar ve tekrar işleyen farklı bir pazar dönüyor.

Bir önceki paragrafta da değindiğimiz nedenlerden ötürü Spectre gibi açıkların kapatılması için sadece güncellemelere güvenilmemeli. Kötü niyetli bir bilgisayar korsanı açıklanmayan zafiyetlerden birini tespit etmiş ise o zaman tüm makineleriniz tehlikede demektir.

Peki Bu Açıklara Karşı Nasıl Müdahale Ederiz?

Temelde başından beri bahsettiğimiz üzere donanım temelli Spectre gibi açıkları donanımı üreten firma doğrudan tasarımdaki açığa neden olan şeyi düzeltene kadar tam anlamıyla kapatmak mümkün değil. Ama yine de kapatmak mümkün değilse biz de açığa neden olan etkenleri göz önüne alarak açığın yavaşlatılmasını veya istismar edilmesini sağlayabiliriz.

Temelde CloudFlare’a göre Spectre açıkları istismar edilirken işlemcideki gizli durumları tespit etmek için farklı yan kanallar kullanır. Yan kanallar bir sistemin determinist olmayan kısmını inceler. Deterministlik olasılığın olmadığı çıktı durumlarıdır. Determinist olmayan durumlarda farklı ihtimallerde farklı çıktılar alınabilir. Yazılımın koştuğu yürütme ortamları çoğu zaman determinizmi kaldırmaya çalışır zira bahsettiğimiz gibi ihtimal hesabının olmadığı determinist çalışma şekli yazılımın yürütülmesi esnasındaki doğruluğu sıkıntıya sokar.

Bütün bunlar bir yana halen determinist olmayan birkaç şey vardır. Bunlardan en bilineni zamanlama özelliğidir.

Bilgisayar endüstrisi bir yazılım çalıştığında aynı süre zarfı içerisinde çalışması gerektiğine dair fikrinden çoktan döndü. Zira determinist zamanlama işin en ucunda sezgisel performansla uyuşmamakta. İhtimallerin olmadığı bir sistemde sezgisel işlemler çok mümkün değildir. Bunun konumuzla ne alakası var diye soracak olursanız, CloudFlare’a göre çoğu Spectre saldırısı işlemcinin gizlenmiş mimarisini tespit etmek için “timing” yani zamanlamadan yararlanır.

Birtakım çözüm önerilerinde zamanlayıcıların yanlış yapılandırılması veya rastgele anlamsız kalabalıklar meydana getirilmesi durumunda bunun çözülebileceği düşünüldü. Açığın ciddiyeti ve yaptıkları göz önüne alındığında bunun saldırıları engellemek için çok da yeterli bir çözüm olmadığı, yalnızca saldırının akışını yavaşlattığı anlaşıldı. Eğer zamanlayıcı, gerçek zamanı takip ediyorsa, saldırıyı etkisiz kılmak için yapabileceğiniz her şey, saldırıyı tekrar tekrar, tekrar yaparak ve gürültüyü filtrelemek için statik kullanarak bertaraf edilebilir.

Bazı güvenlik araştırmacılarına göre hikayemiz burada son bulur. Saldırıyı yavaşlatmanın ne önemi var? Saldırgan 1 gün veya 1 ayda da olsa özel anahtarları ele geçirdikten sonra bu oyunun sonu demektir, doğru değil mi?

Adım Adım Yavaşlatma

Aslında saldırıyı yavaşlatan birtakım önlemlerin oldukça güçlü seviyede olduğunu görüyoruz. İşin özünde ortada bir saldırı varsa biz bunu yavaşlattıkça daha da yavaşlatmak için yeni tekniklerin uygulanması daha kolay bir hale gelecektir. O halde amacımız saldırıyı zorlaştırıp yavaşlatarak daha az hale getirmek olmalı.

Örneğin şifrelenmiş, kripto metinlerin çoğu teorik açıdan bakıldığında deneme yanılma yoluyla şifre kırma yöntemi yani kaba kuvvet saldırısına karşı savunmasızdır. Teknik açıdan baktığınızda ise yeterince zaman varsa onu kırabilirsiniz, belki milyonlarca veya milyarlarca yıl sürecek. İşte bu çok güzel bir vazgeçirme ve yavaşlatma tekniğidir. Korsanlar daha çok insanların ömrünün yeteceği süre içerisinde saldırının sonucunu almak isterler. Evet, azimli bir saldırgan hedefinin peşinde aylarca ve yıllarca bekleyebilir fakat istese bile milyarlarca yıl bekleyemeyeceği kesin.

Peki Spectre Saldırılarını Anlamsızlaştıracak Seviyede Nasıl Yavaşlatabiliriz?

Adım 0 : Müşterilerinizin ağınızda çalıştırılmak üzere birtakım yürütülebilir dosya yüklemelerini engelleyin.

Şu soruyu sorduğunuzu duyar gibiyim: “E o halde bu hizmet ne için var?” Bu soruya verebileceğimiz yanıt ise dosyaların çalıştırılmasını engellemeniz olacaktır, kodların değil. JavaScript, WebAssembly ve Python gibi herhangi bir dile ait kodları çalıştırırken kendi izolasyon yöntemlerinizi kullanarak güvenli bir alanda bu işlemleri gerçekleştirin.

Elbette bu yalnızca Spectre saldırılarını zorlaştırmak için yetersizdir. Diğer adımlardaki önerileri bu adımdan sonra uygulamak çok daha önemli.

Native kodları kabul etmek tipik bir işlemci mimarisine (x86 veya x86-x64 gibi) bağımlı olmayı gerektirir. Kod yürütülürken yeterli ve yüksek ölçüde performansla çalışabilmesi için gerçek bir donanım üzerinde çalıştırmak her zaman daha mantıklıdır fakat bunun yapılması durumunda ana makinenin yürütülecek kodun nasıl çalıştırılacağıyla ilgili kontrol azalır. Örnek verecek olursak hypervisor veya kernel seviyesinde yönetici çözümleri, yan kanalları hedefleyen saldırılarda çok faydalı olan ve neredeyse başka hiçbir işlevi olmayan CLFLUSH komutunun yürütülmesini engelleyememekte.

Aynı zamanda native kodların desteklenmesi demek bilindiği üzere kodların mimari altında ne şekilde yürütüldüğüne dair on yıllarca süren bir beklentinin yanında halihazırda mevcut işletim sistemleri ve yazılımlara destek verildiğini gösterir.

Normal x86 işlemcilerde, yüksek hassasiyetli bir zamanlayıcıyı okuyan RDTSC özelliğini bir hypervisor yönetici veya çekirdeğin devre dışı bırakması mümkün. Yine de her ne kadar böyle bir imkan söz konusu olsa da bu özelliğin devre dışı bırakılması neticesinde çoğu programda bozulmalar meydana gelecektir. Programlar, mevcut saati öğrenmek için RDTSC özelliğini kullanmak üzere ayarlanmıştır.

Uzun lafın kısası, “native” kodları desteklemek tehlikeyi azaltmak ve yavaşlatmamızda önümüze engel olarak çıkabilmekte.

Adım 1 : Zamanlayıcılar ve çoklu iş parçacıklarına izin vermeyin.

CloudFlare Workers’da geçerli saati almak için JavaScript Date API kullanabilirsiniz. Örneğin Date.now() çağırarak bunu yapmak mümkün. Fakat gerçekte dönen saat şimdiki zamanı ifade etmemekte. Uygulamanın çalışmasına neden olan şey ağa ait mesajın alındığı zamandır. Uygulamanın çalıştırılması sırasında arkada zaman olması gerektiği gibi kilitlenir.

Örnek verecek olursak bir saldırganın şu kodları yazdığını düşünelim:

let start = Date.now();


for (let i = 0; i < 1e6; i++) {


  doSpectreAttack();


}


let end = Date.now();


Koda bakıldığında başlangıç ve bitiş dizileri hep aynı olacaktır. Bu nedenle saldırgan kişi saldırı yapacağı kodun çalıştırma zamanını ölçmek amacıyla Date fonksiyonunu kullanamaz.

CloudFlare’nin açıkladığına göre bu engelleme yöntemi daha Spectre açıkları duyurulmadan önce, 2017 yılının ortalarında kendileri tarafından kullanılan bir önlemdi. Bu önlemin uygulanmasının nedeni yan kanalları çalışmasından endişeli olmalarıydı. Yan kanallar serverless servisi (CloudFlare Workers) ekibinin çekindiği ve kaygılandığı bir şeydi. Bu nedenle sistemlerini bu şekilde baştan tasarladıklarını söylüyorlar.

Yine alınan başka bir önlem ise zamanlamayı durdurmanın dışında çoklu iş parçacıklarının ve paylaşılan belleğin kullanılmasına izin verilmemesi. Normalde bir olay çalıştırılmak üzerine işlenirken olayla ilgili her şey aynı iş parçacığında çözülmeye başlanır. Workers üzerinde aynı olaydan gelen istekler olsa bile birden fazla iş parçacığının aktif olarak kullanımına müsaade edilmez. Örneğin bulunduğunuz yerde Workers’dan yararlanarak çalışan bir CloudFlare uygulaması yüklemişseniz ve bulunduğunuz kısım Workers üzerinden çalışıyorsa sizin alanınız üzerine gelen istekler iki CloudFlare Workers servisi tarafından işleniyor olabilir. Bunlar aynı iş parçacığında çalışır.

Bu şekilde saldırganın kodun yürütülme zamanını yerel şekilde ölçülmesini engellemiş olsanız bile saldırgan yine de uzaktan ölçebilir. Nasıl mı? Yürütmeyi başlatmak üzerine bir HTTP isteği gönderen istemci yardımıyla ne kadar sürede yanıt verildiği öğrenilebilir. Elbette ki bu işlemin uygulanılabilirliğini göz önüne aldığımızda yoğunluk ve çeşitli etkenler nedeniyle gelen cevap gerçekten biraz daha farklı olabilir. Teorik olarak gelen cevapların ortalaması alınarak saldırgan tarafından strateji çizilebilir.

Teoride ihtimal dahilinde olan bu yöntem, gerçek dünyada ele alındığında uzaktan bu şekilde zamanın ölçüldüğü ve ona göre planlandığı bir saldırı uygulanabilir mi? CloudFlare, Spectre konusunda uzman kişilerle beraber deneme amaçlı bu şekilde başarılı bir saldırı geliştiremedi. Yine de halen çalışmakta olan bu saldırıyla alakalı yeni ve daha gelişmiş koruma yöntemlerinin devreye girmesi bekleniyor.

Adım 2 : Dinamik Process İzolasyonu

Yüklenen yamalar ve alınan önlemler neticesinde olası bir saldırının uzun zaman alacağını artık biliyoruz. Herhangi bir istisna durumunda saldırı saniyeler sürse bile önlemleri arttırmak için çok sayıda uygun veri mevcut.

Spectre saldırıları görüldüğü üzere programların normal davranışlarını bozacak şekilde arkada garip işler çevirir. Saldırıyı planlayanlar mikro işlemci mimarisinin etkilerinden daha fazla yararlanmak adına kasten performans senaryoları oluştururlar. Bu, şu ana kadar yukarıda değinmiş olduğumuz saldırıyı yavaşlatma yöntemlerini aşmak için milyarlarca kez saldırının çalıştırılması gerektiğinde gerçekleşir. İşlemci performans sayaçlarında bu tarz olağan dışı hareketler görünebilir.

Performans ölçümü yoluyla saldırı tespitinde karşınıza çıkabilecek en büyük sorun, masum ve yasal bir yazılımın da gereksiz yere tuhaf davranışlar ve kaynak tüketiminde bulunan yazılımın gerçekten kötü kodlanmış olmasıdır. Kötü performans gösteren her programı kapatmanız doğru olmayacaktır.

CloudFlare Workers üzerinde kötü ve şüpheli performans gösteren çalışanları kendi processi üzerinde yeniden planlayabilirsiniz. Bu biraz masraflı olacak olsa da veri merkezlerinde uygulanabilecek bir çözüm.

Gereken izole işlemlerini de yaptıktan sonra işletim sistemi ve işlemci üreticilerinin yayınlamış olduğu yamaya güvenebiliriz.

Yazıda bildiğiniz üzere izolasyonun tam savunma olmadığına başlarda değinilmişti. Bu halen doğru bir yaklaşım fakat burada amacımız saldırının akışını yavaşlatarak değiştirmek olduğundan bir nebze amacımıza ulaştık diyebiliriz.

Adım 3: Periyodik Hafızayı Karıştırma

Şu ana kadar olan tüm adımları uyguladığımızda büyük ölçüde bilinen açıklıkları yavaşlatmış veya engellemiş olabiliriz. Yine de bir veri merkezi işletiyorsanız bilinmeyen açıklara karşı da önlemler geliştirmelisiniz. Yeni bilinmeyen saldırıların ne kadar zaman alacağını bilemesek de tedbirler sonrası günler veya haftalar süreceğini söylenebilir.

CloudFlare’a göre bellek yüzünden oluşan açıklar kullanılarak yapılan saldırılara ve bilinmeyenlere karşı alınabilecek bir diğer önlem de belirli aralıklarla çalışan sistemi yeniden başlatmaktır. Yeniden başlatma sonrası çalışan şeylerin bellekteki konumları öncekinden farklı bir hal alacağı için saldırganın istismar edilecek şeyin adresini tekrar bulması gerekecek. Bunun dışında çalışanları birbirinden fiziksel olarak farklı makinelere ayırıp süreci yönetmek de mantıklı bir çözüm.

Sonuç

Bu yazıda değinmek istenilen asıl şey; çıkan güvenlik açıklarından korunmak için gerçek bir makine ve yönetilmesi gereken süreç söz konusu olduğunda, işlerin bilinen yaklaşımdan daha farklı şekilde geliştiğidir.

Özellikle bir veri merkezi işleticisiyseniz veya veri merkezinde güvenlikten sorumluysanız teknik olarak donanımın tasarımının değişmediği sürece kesin olarak kapatılmayan “Spectre” ve benzer diğer açıklara karşı kendi izolasyon tekniklerinizi geliştirmelisiniz. Yaklaşımınızı belirlerken yalnızca halihazırda çıkmış açıklara karşı değil, henüz tespit edilmeyenleri de hesaba katmalısınız.

Eklemek istedikleriniz varsa yorum yazabilir, sorularınız için Technopat Sosyal üzerinde konu açabilirsiniz. Esen kalın.