NETLOGON CVE-2020-1472 / ZEROLOGON AÇIĞI

ZEROLOGON ZAFİYETİ

17 Eylül 2020 tarihinde, Hollanda merkezli bir güvenlik şirketi olan Secura’nın yayınladığı ve CVE-2020-1472 kod numarası ile adlandırılan bu açıkta, saldırganlar Domain Controller’da ki Netlogon servisini baypass ederek, sunucu da uzaktan kod çalıştırabiliyor.


Eğer Ağustos 2020 ayına aylık Monthly Rollup’ları aldıysanız endişe edilecek herhangi bir durum söz konusu değil. Eğer hala ilgili updateleri almadıysanız burada ki adresten 2008 R2 ve sonrası için ilgili updateleri edinebilirsiniz.

Zerologon ile yeniden anladık ki;

  1. Kriptografiyi doğru yapmak zordur,
  2. Kriptografik hataları fark etmek yıllar sürebilir.

Microsoft tarafından Ağustos 2020’de açıklanan yamalarda bu açık ile ilgili herhangi bir bilgi verilmemesi biraz üzücü. Akıllarda Microsoft’un bu açığı ne zaman ve nasıl keşfettiğine dair sorular gelmekte.

Bu yazımızda ZEROLOGON açığı sömürme ile ilgili bir bilgi paylaşılmayacaktır. 


Netlogon Aracılığı İle Kimlik Doğrulama

Netlogon servisi bir RPC (Remote Procedure Call) mantığı ile çalışan bir servistir. Bu servis mantığında client ve server bulunur. Netlogon servisinde siz, oturum açmak istediğinizde client olarak DC’ye erişip, UDP 137 veya TCP 139 portundan Netlogon aracılığı ile kullanıcı kimlik doğrulaması gerçekleştirilerek oturum açarsınız.

Microsoft’un Netlogon ile ilgili olarak yayınladığı protokol özelliklerine Netlogon Remote Protocol Specification adresinden bakabilirsiniz. Bu belge, 280 sayfalık bir belgedir. Belgenin en son 26 Ağustos 2020’de 37. revizyonu gerçekleşmiştir. Bu kadar çok değişmesinin temek sebeplerinden biri teknolojinin ve ihtiyaçların hızlıca gelişmesi, güvenlik zafiyetleri ve aynı zamanda eski sürümlerinde desteklenmek zorunda olmasıdır. Buna Netlogon kullanımının birden fazla yöntemininde olması etkendir.

Netlogon’un güvenlik tarafında ki parametreleri şöyle;

Netlogon Güvenlik Parametreleri

Netlogon İle Temel Başlangıç

Windows bir client, Domain Controller ile iletişime geçerken ilk iş olarak rastgele sekiz bayt’lık bir veri göndererek başlar. Buna karşılık olarak sunucuda, istemciye aynı şekilde sekiz bayt’lık bir cevap döner ve 3.1.4.1 adımı tamamlanmış olur. Burada clientın requestine ClientChallenge, sunucunun cevabına ServerChallenge olarak tanımlanır.

Bu işlemlerden sonra her iki tarafta tek kullanımlık bir SessionKey (SK), yani şifreleme anahtarı oluşturur. Böylece güvenli bağlantı sağlanmış olur. Bu anahtar, istemcinin regedit tarafında ve active directory veri tabanında depolanır. Şifreleme ise HMAC-SHA256 ile gerçekleştirilir.

Daha öncesinde iki tarafında rastgele oluşturduğu 8 baytlık veriler sayesinde, bir sonra ki oturumunuzda bu 8 baytlık veriler gönderilir ve netlogon sunucusu ekstra bir işlem yapmadan, sizin doğru şifreyi bildiğinizi var sayar. Bu yüzden yeni pasifize ettiğiniz kullanıcı domain çatısı altında bir süre daha domainde ki bilgisayarında oturum açmaya devam eder. Yalnız bu işlem wifi gibi durumlarda geçerli değildir, çünkü 802.1x kimlik doğrulamasında netlogon arada olmaz. Veya kullanıcı bilgisayarınız pasifize ettiğinizde de kişi oturum açamaz. Çünkü burada ki algoritma ve doğrulama işlemleri, netlogon kimlik doğrulama işlemlerinden farklıdır.

İstemcinin her defasında şifrelenmiş oturum şifresini paylaşmama sebebi de yine güvenlik sebeplidir. Zira ağınızda, DC trafiğini dinleyen birisi var ise kullanıcı şifrelerinizi çalması bu sayede bir nebze zorlaşmaktadır.

İşte bunun yerine istemci, başta belirlediği ClientChallenge ile birlikte yeni oluşturduğu SK’yı kullanıp, şifreleyerek Netlogon sunucusuna oturum anahtarını bildiğini ispatlar. Bu adımda ise AES-128-CFB8 kriptografik algoritma kullanılır. 

Sunucu tarafına ise bu işlemin aynısının tersi gerçekleşir. Yani CC+SK’nın şifresini decrypt eder ve CC’nin doğruluğunu teyit eder.


Peki Nereden Patladı?

Az önce, istemcinin CC+SK algoritmasında AES-128-CFB8 kriptografik algoritmayı kullandığını belirtmiştim. AES kriptografik algoritma; henüz kırılamamış, güçlü bir algoritmaya sahip olarak bilinir. Bunun yanı sıra 128 bit’lik bir anahtarlama da bir hayli zor. 2 üzeri 128’lik bir anahtarı çözebilecek bir makine henüz bulunmamakta.

Ama AES algoritmaları birçok farklı modda kullanılabilir ve hepsi tüm amaçlara tam uygun değildir.

Kriptografilere merak salan herkesin bildiği bir “düz şifreleme” modu vardır, buna AES-128-ECB denir ve bir serferde 16 baytlık veri girişini karıştırarak doğrudan 16 baytlık bir veri çıkışı verir.

AES-128-ECB ve AES-128-CFB’lerin ortak bir kötü özelliği vardır. Bu da 16 baytlık tam bir veri bloğu girişi olmadan herhangi bir çıktı üretmiyorlar. Sebep olaraktansa bu algoritmalar kriptoloji de kısmi bloklarla değil, tüm bloklar üzerinde çalışırlar. 

İşte bu yüzden tüm blokları doldurmanız gereklidir. Sizin son bloğu doldurmanız ve ardından şifresini çözdüğünüzde çıkarılması gereken fazladan bir bayt’ın olup olmadığını güvenilir bir şekilde çözmeniz gerekir. Bunun adına da AES-CFB8 deniyor.

AES-CFB8 size; girilen her bayt verinin AES-128 olarak karıştırma döngüsünü kullanmanızı sağlar. 

Kötü haber ise, Secura’nın yaptığı araştırmaya göre Netlogon servisi AES-128-CFB8 algoritmasını tam olması gerektiği gibi kullanmıyordu. Normalde AES-128-CFB8 algoritmasında 8 bitlik anahtarlar rastgele seçilir ve yalnızca bir kez kullanılır. 

Secura’nın yaptığı araştırmaya göre ise 8 adet 0’dan oluşan CC nonce’sini eğer tekrar tekrar netlogon sunucusunda kimlik doğrulama için kullanırlarsa, yani kabaca 256 kez sunucuya rastgele bir oturum anahtarı uydurarak istek gönderirseniz kimlik doğrulama mesajını alma 256’da 1 şansınız oluyor. 

Sonuç olarak;

  • Bu hata, domain yapınıza bağlı olarak ciddi sorunlar yaşatabilir. Yine yapınıza bağlı olarak dışarıda ki kullanıcılarınız ve sistemleriniz çoktan başkalarının eline geçmiş olabilir.
  • Ağustos 2020 yamalarını muhakkak geçin.
  • Geliştireceğiniz uygulamarda kriptografik algoritmalar kullanırken asla basit, kestirme yolları tercih etmeyin.
  • Her zaman en güncel teknolojiyi kullanın.

 

You may also like...

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Social media & sharing icons powered by UltimatelySocial