Kategori arşivi: Güvenlik

Sertifika Zinciri Nedir?

SSL Sertifika zinciri, aslında Türkçe karşılığı olan zincir kelimesinde olduğu gibi bir birine bağlı olan ve en alttan en üste doğru sertifikaların verilim sırasına göre dizilmesidir. Bir web servisi veya güvenlik amacı ile ulaştığınız bir sistemin kullanmış olduğu sertifikayı sizin aktif olarak kullanabilmeniz için öncelikle o sertifikayı veren Sertifika dağıtıcısına bilgisayarınızın veya kullandığınız aygıtın güvenmesi gereklidir. Aksi halde size bunu belirten bir uyarı çıkacağı gibi Outlook Anywhere örneğinde olduğu gibi sistem hiç çalışmayabilir.

Yukarıda çok güzel bir örnek var, paypal malum ödeme sistemleri web sitesi olup bu uyarı hiçte normal bir durum değildir. Tabiki bu uyarının temel 3 nedeni vardır;

1 – Sertifikanın tarihi doğru mu?

2 – Sertifikanın istek dosyasındaki URL adresi yani verildiği domain’ den farklı bir adres isteği mi yapılmış? Yani sertifika üzerindeki URL ile sizin girdiğiniz URL örtüşüyor mu?

3 – Bu blog yazımın konusu, bu sertifikayı veren dağıtıcıya sizin bilgisayarınız güveniyor mu?

Peki bu sertifika zinciri ne için kullanılır? Örneğin şirketinizin bir web sitesi var ve bunun için bir sertifika satın almak istiyorsunuz, sizin satın alım yaptığınız firma aslında bir kök sertifika dağıtıcı olmayabilir, veya böyle bir firma olmasına karşın kök dağıtıcı rolünü aktif olarak sertifika dağıtımı için kullanmaz ( güvenlik nedeni ile), bu durumda kök sertifika dağıtıcısının onayladığı bir intermediate dediğimiz bir alt merci veya onunda onayladığı bir alt merci daha vermiş olabilir. İşte bunun gibi bir Root tarafından onaylanan bir intermediate CA’ in veya onunda onayladığı bir alt intermediate CA’ den sertifika almış olabilirsiniz. Ancak bu bağlantı sertifika zinciri olarak gösterilir ve günün sonunda bilgisayarınız bu aradaki dağıtıcılara güvenmiyor olsa bile kök dağıtıcıya güvenmesi otomatik olarak onun güvendiği ve güvendiği dağıtıcının verdiği sertifikaya güvenmemizi sağlar.

Not: Bazı sistemler ne yazık ki bu doğrulamayı kendisi yapamadığı için mutlaka tüm zincir içerisindeki sertifikayı ister. Örneğin Firewall, Access Point gibi network aktif cihazları veya Linux sistemler için genelde bu zincirin tamamı sisteme import edilmek istenebilir.

Burada bir kaç kafa karıştıran soru bulunmakta olup onun cevaplarını vermek istiyorum. İlk olarak web serverımız için bir sertifika aldık, bunu veren intermediate üstündeki yani en üstteki root sertifikasını sunucuma yüklemem gerekiyor mu? HAYIR, çünkü buna güvenecek olan istemci makineler olup onlarda zaten olması gerekli, aksi halde merdiven altı bir kurumdan sertifika aldınız demektir, yani çok yaygın olmayan. Peki Intermediate SSL sertifikalarını ( arada kaç tane var ise) yüklemek zorunda mıyım? EVET, aksi halde zincir kırılır ve son kullanıcının root’ u bulamadığı durumlarda zincir de kırık olduğu için sertifikanız güvenilmeyen bir sertifika olarak isimlendirilir.

Umarım faydalı bir yazı olmuştur.

RDS CVE-2019-0708 Açığı için Hızlı Önlem Adımı

Bildiğiniz gibi yakın zamanda çok kritik bir açık ile daha karşı karşıya kaldık. bu konudaki bilgiye aşağıdaki link üzerinden ulaşabilirsiniz;

Tabiki pek çok müşterim başta olmak üzere hızlı bir şekilde yama dağıtımlarına pilot uygulamalar ile başladı. Ancak dışa açık sistem sayısı fazla olan müşteriler için bu biraz zaman alacağından dolayı hızlı bir çözüm düşünüldü. Zafiyetin yapısına bakınca Network Level Authentication (NLA)’ ın aktif edilmesi kimlik bilgisini elinde bulundurmaya kötü niyetli kişileri ilk aşamada durduracağını fark edildiği için bu noktada Microsoft’ da yayınladığı makalesinde öneride bulundu.

https://blogs.technet.microsoft.com/msrc/2019/05/14/prevent-a-worm-by-updating-remote-desktop-services-cve-2019-0708/

Konuyu özetlemek gerekir ise;

CVE-2019-0708 zafiyeti için sistemlerin yama geçişlerini tamamlayana kadar zafiyetin etkisini hafifletmek için (kötü niyetli kişinin şifre bilgisinin olmadığını düşünüyoruz) Network Level Authentication (NLA) özelliğini aktif etmeniz etkili olacaktır.

Sunucularda tek tek yapabileceğiniz gibi GPO ile aşağıdaki yolu izleyerekte yapabilirsiniz;

Computer Configuration \ Policies \ Administrative Templates \ Windows Components \ Remote Desktop Services \ Remote Desktop Session Host \ Security \

Intel İşlemcileri Etkileyen Zombieload Side-Channel Atak

Akademisyenler, Intel işlemcilerde saldırganların bir CPU içinde işlenen verileri almasına izin verebilecek yeni bir güvenlik açığı “sınıfı” keşfettiler. Evet sınıfı diyoruz çünkü CPU açıkları dendiği zaman aklımıza ilk olarak Meltdown ve Spectre geliyordur. Artık bu atakların karakterlerine göre sınıflandırmaya başladılar. Bu yeni güvenlik açığı bundan önce bildiğimiz Meltdown, Spectre ve Foreshadow gibi CPU temelli bir güvenlik açığıdır.

Bu atakta da tıpkı ilk üç atakta olduğu gibi İntel’ in veri işleme hızlarını ve performansını artırmak için işlemcilere eklediği “speculative execution process” özelliğini kullanmaktadır.

İşin kötü yanı 2011′ den bu yana piyasaya sürülen tüm intel işlemcilerin bu zafiyetten etkilenebileceği düşünülüyor.

Yani yine sistemler için en güncel yamaları yüklememiz gerekiyor.

Daha fazla bilgi için aşağıdaki kaynakları inceleyebilirsiniz

https://www.intel.com/content/www/us/en/architecture-and-technology/mds.html

https://www.zdnet.com/article/intel-cpus-impacted-by-new-zombieload-side-channel-attack/

Microsoft Remote Desktop Servisinde Uzaktan Kod Çalıştırma Açığı – Remote Desktop Services RCE Remote Code Execution (RCE) vulnerability CVE-2019-0708

Microsoft düzenli olarak her ay güvenlik açıkları için yamalar yayınlamaktadır. Güvenlik uzmanları kadar kötü niyetli kişilerde bu yamaları çok yakından takip etmektedir. Çünkü bu yamalar günün sonunda tespit edilen açıklar için hazırlanmıştır. Genellikle sistem yöneticileri de yama yükleme noktasında kesinti veya beklenmedik sorunlara karşı temkinli yaklaşmaktadır. Durum böyle olunca bu tarz yamaların çıktığı gün itibari ile yükleme yapmadığınız her gün tehlike riskiniz artmaktadır.

Her ay olan bu düzenli yama duyurusunda kritik bir durum söz konusu. Hatta çok ilginç bir tesadüf olarak daha geçen gün RDP ile ilgili bir makale yayınlamıştım

https://www.cozumpark.com/rdp-ataklar-icin-kritik-onlemler/

Hemen bunun ardından Windows Server 2008 R2, Windows Server 2008, Windows 7 ve öncesi işletim sistemlerini etkileyen kritik bir RDP zafiyetinin varlığından haberdar olduk

https://blogs.technet.microsoft.com/msrc/2019/05/14/prevent-a-worm-by-updating-remote-desktop-services-cve-2019-0708/

Özetlemek gerekir ise dış dünyaya RDP portu açık eski nesil bir işletim sisteminiz var ise kimlik doğrulama olmaksızın uzak kod çalıştırma zafiyeti nedeni ile aynı 2017 yılındaki “WannaCry” saldırısının bir benzeri olabilir. Bu nedenle hızlı bir şekilde bu sistemleri kapatmalı veya güncelleştirme yüklemelisiniz.

Turla LightNeuron Saldırısı Hakkında

İşletim sistemlerinde güvenlik iyileştirmeleri nedeniyle rootkit kullanımı birkaç yıldır sürekli düşüş göstermektedir. Bu nedenle kötü amaçlı yazılım geliştiricileri (özellikle casusluk gruplarında çalışanlar) yeni nesil kötü amaçlı yazılım geliştirmekle meşgul. Son zamanlarda ESET araştırmacıları bir casusluk grubu “Turla” tarafından kullanılan sofistike bir saldırı yöntemini araştırdılar. “LightNeuron” olarak adlandırılan bu arka kapı aracı özellikle yeni nesil Exchange sunucularını (2016 ve sonrası) hedefliyor.

İlgili ekip aşağıdaki 3 bölgede bu tür atakları gözlemlediklerini söylüyor;

Peki nasıl bir saldırı yöntemi izliyorlar? Tabiki öncelikle bu çok yeni nesil bir taktik ancak bir zafiyet söz konusu değil. Hatırlarsanız bundan önce de sizlere yine Exchange zafiyeti olarak anlatılan ancak bunun bir Exchange zafiyeti olmadığını “Infinitum Labs” ekibi ile dokümante ederek kanıtlamıştık. Burada da benzer bir durum olmasına karşın bu kadar yaygara kopmasının en önemli nedeni bir şekilde bu zararlının Exchange sunucularına bulaşması durumunda transport agent seviyesinde sistemi ele geçirmesi olarak gösterilebilir.

Peki Nasıl çalışıyor?

LightNeuron, Özellikle Microsoft Exchange e-posta sunucularını hedefleyen ilk kötü amaçlı yazılımdır. Daha önce hiç görülmemiş bir gizlilik – kalıcılık tekniği kullanır: “Transport Agent”

Aslında benim hemen hemen her sorunda ilk kontrol ettiğim alan olan transport agent olarak sisteme sızman Exchange gibi bir alt yapı için son derece tehlikelidir. Malum uzun yıllardır Exchange Server ile uğraşan birisi olarak ve özellikle bu maili alanların arasında beraberde proje yaptıklarımız olduğu için her transport sorununda ilk Transport Agent’ lara baktığımı bilir. Bu alışkanlığın güzel bir faydası olarak çalıştığımız hiçbir müşteride bu atak yöntemine rastlanmadı.

Zaten Exchange server mimarisinden temel olarak anlıyorsanız bir transport agent’ ın ne kadar tehlikeli olabileceğini tahmin edebilirsiniz. Daha basit bir örnek vermek gerekir ise pek çoğunuz Office 365 veya Exchange için disclaimer yazılımları kullanıyorsunuz, bütün o mail trafiğinizdeki imzaları bir transport agent sayesinde yönetmektedir.

Peki gelelim yine bu bir Exchange zafiyeti mi sorusuna?

Benimde içinde bulunduğum kapalı bir mail grubunda bir Microsoft yetkilisi konuyu son derece güzel bir şekilde özetledi;

Not: Normalde bu grup içerisindeki konuşmalar NDA altında olmasına rağmen bu public bir bilgi olduğu için sizlerle paylaşıyorum;

Özetle bu yetkili bir kullanıcının bir sisteme virüs bulaştırmasından farksız bir durum olup bunun bir Exchange zafiyeti olmadığını hatta Defender ATP ürününün bunu tespit edebildiğini söyledi.

Biz tabi bu bilgileri 3 gün önce aldık ancak malum ilk olarak Exchange SLA müşterilerimizde kontrol ettikten sonra bir şekilde sizlere ulaştırmaya çalışıyoruz. Günün sonunda bizden aktif SLA hizmeti alan müşteriler bu tür destekler için bize para ödüyorlar 😊

Özetle, şu anda çok yaygın ve genel bir saldırı söz konusu değil, ancak her zaman tetikte olmakta fayda var. Bu mail’ den sonra en kötü Exchange sunucusu sistemlerinde Win32/Turla zararlısının bilen bir AV ile taratma yapmanızda fayda bulunmaktadır.

Yada PS bilenler için yüklemeleri aşağıdaki iki isim ile yaptığı için bu iki isim’ in sizdeki Exchange sunucularında transport agent olarak olup olmadığını kontrol edebilirsiniz

Daha fazla bilgi için aşaıdaki PDF dosyasını inceleyebilirsiniz.

https://1drv.ms/b/s!ApkDgKv0Ho0-hZtlwZn5PBhvfIzl6Q

Umarım faydalı bir yazı olmuştur.

Veri Sınıflandırma için Etiketleme İsimleri Neye Göre Belirlenir? Veri Sınıflandırma Etiketleri Nedir?

KVKK ile birlikte hayatımıza pek çok kavram girdi. Aslında benim gibi eski banka kökenli veya hala bu tarz bilgi güvenli başta olmak üzere pek çok regülasyona tabi şirketler için tabiki bilindik bir şeydi pek çoğu. Ancak veri sınıflandırma, anonimleştirme, veri karma başta olmak üzere pek çok kobi ve orta ölçekli firma için bilinen veya bilinse bile aktif olarak kullanılan kavramlar değildi.

KVKK ise her firmayı etkileyecek bir şekilde gün geçtikçe önem kazanıyor ve daha önemlisi farkındalık oluşturuyordu. Böyle bir dönemde tabiki pek çok KVKK projesinde yer almış birisi olan bazen müşterilerimin de kafasını karıştıran bir konuya açıklık getirmek istiyorum.

Veri sınıflandırma aslında bu işin en temel noktalarından. Tabiki öncelikle bu verilerin bir envanterinin çıkarılması lazım. Ancak bu envanter çalışması sonrasında elimizdeki verileri sınıflandırma çok ciddi bir sorun.

Sınıflandırma için pek çok farklı program kullanabilirsiniz, ancak hepsinin ortak özelliği veri etiketleri kullanmasıdır. Yani bir dokümanın veya belgesinin nasıl bir belge olduğunu tanımlayacak sıfatlar olarak nitelendirilebilir.

Buna ISO 27001 gözü ile bakacak olursak standart veri sınıflandırma etiketleri aşağıdaki gibidir;

Confidential (top confidentiality level)
Restricted (medium confidentiality level)
Internal use (lowest level of confidentiality)
Public (everyone can see the information)

Bunu temel alıp tabiki siz kendi şirketinizin iş ihtiyaçlarına göre burada bir farkındalık oluşturabilirsiniz. Buna hemen hızlı bir örnek vermek adına NATO bunu nasıl yapmış;

Cosmic Top Secret
NATO Secret
NATO Confidential
NATO Restricted
NATO Unclassified (copyright)
NON SENSITIVE INFORMATION RELEASABLE TO THE PUBLIC

NATO da tabiki kendi iş ihtiyaçlarına göre 27001 temelini biraz değiştirmiş.

Sizlerde veri sınıflandırma projelerinden öncelikle bunlara karar vermeniz gerekli.

Ancak ne kadar sade o kadar başarılı projeleriniz olur. Çok fazla alt kırılıma girmeden aşağıdaki gibi Türkiye’ nin en markalarından birisinin yaptığı gibi yapabilirsiniz;

Public
Confidential
Private

Başka bir müşterimden örnek;

Public
Confidential
Restricted
Private

Başka bir müşterimden örnek;

Gizli
Hizmete Özel
Şirkete Özel
Herkese Açık

Umarım faydalı bir blog yazısı olmuştur. Bu tarz projelerinizde destek ihtiyacınız olması halinde bana ulaşabilirsiniz.

NET::ERR_CERT_COMMON_NAME_INVALID Hatası Hakkında

Şirket içerisinde kullandığınız bazı web sitesi veya portal platformlarına erişimin güvenli olması için SSL sertifikası kullanmak isteyebilirsiniz. Eğer URL adresi com, net, org ve benzeri public isimler ise ve bütçeniz var ise en doğru çözüm global bir sertifika üreticisinden sertifika almaktır. Ancak bazen kurduğunuz veya kulladığınız platformlar local veya sizin iç domain isminize göre kurulmuş veya lisanslanmış olabilir. Böyle bir durumda zaten global bir üreticiden sertifika alma şansınız yok.

Peki nedir çözüm? Internal bir CA kurmak veya var olan CA’ den sertifika almaktır. Genelde IIS üzerinden talep edilen ve sonra yüklenen bu sertifikaları kullanırken aşağıdaki gibi bir durum ile karşılaşabilirsiniz;

Ancak aynı web sitesini IE, EDGE veya Firefox ile ziyaret ettiğinizde ise herhangi bir hata almadığınızı fark edersiniz.

Bunun temel sebebi aşağıdaki linkte güzelce açıklanmaktadır;

https://support.google.com/chrome/a/answer/7391219?hl=en

Yani özetlemek gerekir ise, web tarayıcıları güvenli bir bağlantı kurmak için kullanılan sertifikanın 3 temel özelliğini kontrol eder.

Okumaya devam et

IDC ve CISO Expert Club Türkiye’nin En Kapsamlı BT Güvenlik Zirvesinde

International Data Corporation (IDC) Türkiye, BT Güvenliği Konferans Serisi etkinliklerini, 28 Şubat’ta İstanbul’da ve 5 Mart’ta Ankara’da, gerçekleştirecek. Finans, perakende, üretim, hizmet, devlet kurumları ve holding şirketlerinden 1000 civarında üst düzey BT güvenlik yöneticisini ve BT profesyonelinin ağırlanacağı bu etkinliklerde öne çıkacak konular:

  • Yapay zeka, otomasyon ve orkestrasyon
  • Blok zinciri ve güvenlik
  • Aldatma teknolojilerinin kullanılma nedenleri
  • Kuantum hesaplama ve siber güvenlik üzerindeki etkisi
  • KVKK: Sadece bir regülasyon mu yoksa inovasyon için motivasyon mu?
  • Siber güvenliği artırmak için analitik
  • Konteyner güvenliği nedir?
  • Çok bulutlu ortamda siber güvenlik
  • OT güvenliği etrafındaki en iyi uygulamalar

IDC Türkiye yazılım pazarından sorumlu kıdemli araştırma analisti Yeşim Öztürk’e göre, “Türkiye’de şirketler rutin işleri sürdürmekle iş çevikliğini arttırmak arasında bir denge kurmaya çalışıyorlar. Ulusal düzeyde stratejiler ve değişen endüstri dinamikleri; yeni teknolojilerle ilgili denemeler yapan ve inovasyonu şirket kültürü haline getirmeye çalışan organizasyonları yönlendiriyor. Bu değişim ise sadece BT’yi değil, işin bütününü kapsıyor. Çağımızda BT güvenliği artık sadece teknoloji varlıklarını korumakla sınırlı olmamalı, iş esnekliğini arttırmayı amaçlamalıdır. Dijital dönüşüm süreci ilerledikçe, kuruluşların iş düzeyinde bir güvenlik stratejisi geliştirmeleri gerekir. Güvenlik ortamının mevcut durumunu ve inovasyon çağına girerken risk, güven ve rızanın güvenlik stratejilerine nasıl dahil edilmesi gerektiğini etkinliğimizde konuşulacak.”

“IDC CIO Zirvesi 2018 Anketi” sonuçlarına göre önümüzdeki yıllarda da güvenlik, ortak bir endişe olarak yine birinci sırada yer alıyor. Günümüzde siber güvenlik tehdit ortamı, gelişen tehditler ve tekrarlayan siber saldırılardan oluşmaktadır. Bu nedenle, CIO’lar dijital dönüşüm inisiyatiflerinin bu tehditlerden etkilenebileceğini anlamalı ve gerekli önemlerin alınması konusunda güvenlik ekiplerini hem strateji hem de teknoloji yatırım planları açısından desteklemelidir.

IDC Türkiye Ülke Direktörü Nevin Çizmecioğulları konuya şöyle yaklaşıyor: “Siber güvenlik CIO ajandalarındaki önemini korurken, yatırım planlarında da üst sıralarda yer almaya devam ediyor. 2019 yılının ekonomik olarak zorlayıcı bir yıl olması beklenirken, yaptığımız görüşmeler ve analizler doğrultusunda güvenlik yatırımlarının hız kesmeden devam edeceğini öngörüyoruz. Bu yıl IDC Türkiye olarak gerçekleştirdiğimiz CISO Zirvesi 2018 anketimizde CISO’ları uykusuz bırakan konuların başında Kişisel Verileri Koruma Kanunu (KVKK) ihlalinin %63 ile ilk sırada geldiğini gördük. Nitekim 2018 yılının en çok konuşulan konularından biri olan KVKK yine 2019 yılında da sıkça konuşuluyor olacak. Kurumlar regülasyonlardan kaynaklı endişelerini gidermek amacıyla çeşitli yatırımlar yapmaya ve uyumluluk konusunda danışmanlıklar almaya devam edecekler. Gerçek zamanlı tehdit istihbaratı ve güvenlik operasyon merkezi yatırımları, yönetilebilir güvenlik servisleri CISO’ların 2019 yılında önceliklendirdiği yatırımların başında geliyor.”

Konferans çerçevesinde en son teknolojilerin ele alınması için IDC bu etkinlikte; KoçSistem, IBM, Cisco, Oracle, Barikat, CyberArk, Endpoint, FireEye, Forcepoint, Fortinet, Google Cloud, Infosec, Juniper, Kaspersky, Nebula, NormShield, Picus Security, Platin Bilişim, VMware, Symantec, BG-Tek, Biznet, Demsistem, Dereka-Natika, Detech-Titus, FileOrbis, Imperva, Invento, Karya Bilişim, Keepnet, Kron, Logsign, Netsec, Netsmart, Roksit, Secure Future, Sekom, Tripware, Zero Second gibi sektörün önde gelen tedarikçileri ile, STK’ları ve CISO’ları ile iş birliği içindedir.

Daha fazla bilgi için IDC BT Güvenlik Konferansı “www.idcitsecurity.com” web sitesini ziyaret edebilir, #idcsecurity19 hashtag’ini kullanarak etkinlikle ilgili paylaşım yapabilirsiniz.

IDC etkinlikleri ve ortaklık fırsatları hakkında daha fazla bilgi almak için lütfen IDC İş Geliştirme Müdürü Onur Hamitoğlu (ohamitoglu@idc.com) -+90-533-3018998 ile iletişime geçiniz.

LepideAuditor 18.6 Sürümü ile Ver Bulma ve Sınıflandırma Özelliği Sunuyor

Lepide temelde bir Audit ürünü olmasına karşın pek çok ek özellik sunmaktadır. Audit temelinde aldığı bilgiler ile raporlama yanında örneğin sistem yöneticileri için çok deperli olan eski hesapların belirlenmesi, lock olan hesapların nereden lock olduğunun sunulması, dosya sunucularındaki değişen izinlerin gösterilmesi gibi bizlerin hayatını kolaylaştıracak özellikler sunmaktadır.

Yeni sürüm 18.6 ile çok popüler konular’ dan GDPR ve KVKK için önemli bir başlık “Data Discovery and Classification” özelliğini de eklediğini duyurdu.

Bu özellikle benim gibi KVKK noktasında global firmalarda da proje yapan birisi olarak çok heyecanlandırdı. İlk fırsatta bunun makalesini yazmaya başlayacapım.

Daha fazla bilgi ve kaynak için aşağıdaki linki kullanabilirsiniz

https://www.lepide.com/news/lepideauditor-now-includes-data-discovery-and-classification/

 

Kritik Zafiyet Uyarısı – Speculative Execution Side-Channel Vulnerabilities L1TF – L1 Terminal Fault

Hikâye nasıl başladı?

Intel iki hafta önce Spectre/Meltdown benzeri bir zafiyet olan “speculative execution side channel” ile ilgili aşağıdaki gibi duyuru yaptı;

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00161.html

Hatta 23 Ağustos itibari ile bir güncelleme de yapıldı.

Microsoft’ da hızlı bir şekilde bu konuda yama ve bilgilendirme geçti;

https://blogs.technet.microsoft.com/srd/2018/08/14/analysis-and-mitigation-of-l1-terminal-fault-l1tf/

Özellikle zafiyet için bu bölümde çok detaylı bir analiz yapılmış durumda;

L1TF arises due to a CPU optimization related to the handling of address translations when performing a page table walk. When translating a linear address, the CPU may encounter a terminal page fault which occurs when the paging structure entry for a virtual address is not present (Present bit is 0) or otherwise invalid. This will result in an exception, such as a page fault, or TSX transaction abort along the architectural path. However, before either of these occur, a CPU that is vulnerable to L1TF may initiate a read from the L1 data cache for the linear address being translated. For this speculative-only read, the page frame bits of the terminal (not present) page table entry are treated as a system physical address, even for guest page table entries. If the cache line for the physical address is present in the L1 data cache, then the data for that line may be forwarded on to dependent operations that may execute speculatively before retirement of the instruction that led to the terminal page fault. The behavior related to L1TF can occur for page table walks involving both conventional and extended page tables (the latter of which is used for virtualization).

Peki nedir özeti derseniz aslında bir sanal makine içerisinden diğer tüm sanal makinelere erişim yapılabilir, bu da özellikle veri merkezleri için veya ortak platformdan hizmet veren sağlayıcılar için çok büyük bir risk. Tabiki risk sadece bunlar ile sınırlı değil, örneğin 30 tane sanal makineniz var ve bir danışman sadece kendi yetkisi olan bir makineden işlem yapıyor ama bu açık sayesinden aslında yetkisi olmayan makinelere de erişebilir demektir. Özetle öncelik evet büyük ve çok fazla müşteri, kişi bağlanan ortamlar olsa bile her platform için ciddi bir risk söz konusu.

Bu zafiyet işlemci temelli olduğu için bundan önce olduğu gibi Microsoft başta aslında tüm sanallaştırma platformlarını etkilemiş durumda. Her üretici Microsoft gibi hızlı bir şekilde yama + config önerilerinde bulundu.

Hyper-V ortamları için çözüm aşağıdaki gibidir;

https://support.microsoft.com/en-us/help/4457951/windows-server-guidance-to-protect-against-l1-terminal-fault

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180018

Peki ne yapmamız gerekiyor?

En güncel yamaların yüklenmesi şart.

En güncel donanım firmwarelerin yüklenmesi tavsiye ediliyor (ama bu Microsoft veya Vmware ya da diğer sanallaştırma üreticilerinden bağımsız olarak yapıldığı için onu ayrıca donanım üreticilerinizin web sayfalarından takip etmeniz gereklidir.)

Hyper-threading (HT) Özelliğinin kapatılması. Tabiki bu madde performans kayıplarına yol açacağı için detayı işletim sisteminize göre değişkenlik gösteriyor. Eğer Windows Server 2016’ dan daha eski sürüm bir hyper-v kullanıyorsanız yani 2012 ve 2008 gibi ne yazık ki şu anda tek çözüm HT özelliğini kapatmanız. 2016 kullanıyorsanız ise devamında çözüm önerisini paylaşıyor olacağım.

Eğer Server 2016 işletim sistemi kullanıyorsanız Hypervisor scheduler tipinin “core scheduler” olarak güncellenmesi ve çekirdek başına VM donanım iş parçacığı sayısının 2 olarak ayarlanması gereklidir.

Kullandığınız işletim sistemi sürümüne göre iki farklı çözüm söz konusu

İlk olarak Hypervisor scheduler tipinin “core scheduler” olarak güncelleyelim

bcdedit /set HypervisorSchedulerType core

Daha sonra Hyper-V üzerinde çalışan sanal makineler için “hardware thread count” değerini core başına iki yapalım

Set-VMProcessor -VMName <VMName> -HwThreadCountPerCore 2

CVE-2017-5715 ve CVE-2017-5754 güvenlik zafiyet tavsiyelerini mevcut zafiyetin etkisini azalmak için etkinleştirin

https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution

Vmware için gerekli bilgilere aşağıdaki linklerden ulaşabilirsiniz

https://kb.vmware.com/s/article/55806

https://kb.vmware.com/s/article/55807

Kaynak

https://support.microsoft.com/af-za/help/4457951/windows-server-guidance-to-protect-against-l1-terminal-fault