Active Directory Güvenlik Serisi – Bölüm 8: RC4 Neden ve Nasıl Devre Dışı Bırakılmalı?

Son aylarda Microsoft destek ekipleri, Kerberos biletlerinde RC4 şifrelemenin devre dışı bırakılması konusunda çok sayıda soru almaktadır. Bu ilginin arkasında büyük olasılıkla CIS Level 1 Baseline ve RFC 8429 dokümanlarında RC4’ün devre dışı bırakılmasına yönelik öneriler yer almaktadır.

Her ne kadar RC4, Active Directory içerisinde resmi olarak kullanımdan kaldırılmış (deprecated) olmasa da, Kerberoasting olarak bilinen saldırı tekniğinin gelişimi, RC4’ten uzaklaşmak için güçlü bir gerekçe sunmaktadır. Bunun temel nedeni, RC4 şifrelemenin anahtar olarak zayıf NTLM hash’i kullanmasıdır. Bugüne kadar AES anahtarlarıyla şifrelenen Kerberos biletlerinin Kerberoasting saldırılarına karşı savunmasız olmadığı kabul edilmektedir.

Bununla birlikte, birçok güvenlik sertleştirme (hardening) ayarında olduğu gibi, Kerberos bilet şifrelemesinde RC4’ün tamamen kaldırılması kararı kesin ve tek yönlü değildir. Aşağıdaki bölümler, bu kararı verirken dikkate alınması gereken tüm teknik noktaları kurumsal bakış açısıyla ele alır.

Kısa Tarihçe

Active Directory ilk tanıtıldığında DES ve RC4 dönemin yaygın şifreleme algoritmalarıydı. Zamanla işlemci gücündeki artış ve kriptanaliz tekniklerinin gelişmesi, DES ile şifrelenmiş Kerberos biletlerinin kısa sürede brute-force saldırılarıyla kırılabilmesini mümkün hale getirdi. Bu durum, RFC 6649 ile DES’in kullanım dışına alınması yönündeki çağrıyı doğurdu.

RFC 6649 resmi olarak yayımlanmadan önce bile Microsoft, Windows Server 2008 R2 ve Windows 7 ile birlikte DES’i varsayılan olarak devre dışı bıraktı. 2009 döneminde Active Directory yöneten birçok ekip, yeni yükseltilmiş domain controller’lar üzerinde DES’in kapandığını fark etmedi. Bunun nedeni Active Directory’nin, Kerberos bileti için istemci ve hedef tarafından desteklenen en yüksek şifreleme seviyesini otomatik seçmek üzere tasarlanmış olmasıdır.

AES ile bilet şifreleme desteği, Windows Server 2008 / Windows 7 ile geldi. Ancak geriye dönük uyumluluk ihtiyacı nedeniyle, AES domain hesaplarında otomatik etkinleştirilmedi.

Kerberos 101 – Kavram Tazeleme

Uyumluluk ve RC4/AES kararlarına geçmeden önce, terimlerin net olması gerekir.

Authenticator (Kimlik Doğrulayıcı)

Parolanın ağ üzerinden açık gönderilmesi hiçbir dönemde “iyi fikir” olmadı. Active Directory, bunu önlemek için sistem saatini paroladan türetilmiş bir anahtarla şifreler. Bu çıktıya authenticator (pre-auth data) denir. DC authenticator’ı aldığında:

• Hesabın parolasını (Long-Term Key) bulur
• Authenticator’ı çözer
• Çıkan zaman bilgisini kendi saatiyle karşılaştırır

Zaman damgaları 5 dakika içinde eşleşiyorsa, doğru parolanın kullanıldığı kabul edilir ve replay saldırısı ihtimali oldukça düşer.

Ticket Granting Ticket (TGT)

Authenticator doğrulandıktan sonra DC, hesaba TGT döner. TGT içinde:

• Hesabın SID’i
• Hesabın grup SID’leri
• Bir session key
• Diğer güvenlik verileri

bulunur. TGT yalnızca üretildiği domain’in DC’leri tarafından okunur. Gizliliği sağlamak için TGT, KRBTGT domain hesabının parolasıyla şifrelenir. Bu nedenle istemci TGT’nin içeriğini okuyamaz.

Session Key

Hesap TGT’yi aldığında, simetrik bir session key kopyası da alır. Anahtar, ağ üzerinden geçerken hesabın parolasıyla şifrelenir; çözüldükten sonra TGT ile birlikte LSA (Local Security Authority) belleğine yerleştirilir. Bundan sonra hesabın parolasına gerek kalmaz.

İstemci sonraki bilet isteklerinde TGT’yi sunar ve session key + sistem zamanı ile yeni bir authenticator üretir. DC, KRBTGT parolasıyla TGT’yi çözer, session key’i çıkarır ve authenticator’ı çözer.

Her biletin kendine özgü session key’i vardır. DC, her session key’i hatırlamaya çalışmaz; işi bitince discard eder. Anahtara tekrar ihtiyaç duyduğunda TGT’den yeniden çıkarır.

Service Ticket (Servis Bileti)

Bir hesap bir kaynağa erişmek istediğinde DC’den service ticket ister. İstek sırasında:

• Kaynağın adı
• TGT’nin bir kopyası
• TGT session key ile üretilmiş authenticator

sağlanır. Authenticator geçerliyse ve istenen isim bir security principal ile eşleşiyorsa, DC ilgili service ticket’ı üretir. Bunu yaparken:

• TGT içindeki SID’leri kopyalar
• Yeni bir session key üretir
• Bileti, hedef security principal’ın parolasından türetilmiş anahtarla şifreler

Bazı durumlarda bu parola bir bilgisayar hesabı parolasıdır; bazı durumlarda kaynağı sunan servis hesabının parolasıdır. TGT’de olduğu gibi, istemci service ticket’ın içeriğini okuyamaz; kendisine biletin session key kopyası güvenli biçimde iletilir.

Referral Ticket (Yönlendirme Bileti)

Kullanıcı başka bir domain’deki kaynağa erişmek istediğinde, kaynağın domain’inden service ticket alınması gerekir. Bunun için kullanıcı domain’inde bir DC’ye referral ticket talebi yapılır. İstemci:

• TGT
• Yeni bir authenticator
• Uzak kaynağın FQDN’i

bilgilerini sunar. FQDN, kaynağın hangi trusted domain’de olduğunu DC’ye bildirir. DC, kullanıcı SID’leri ve bir session key içeren referral ticket üretir. Referral ticket, domain trust parolasından türetilmiş anahtarla şifrelenir ve istemciye döner.

İstemci bu referral ticket’ı uzak domain DC’sine iletir ve kaynağa yönelik service ticket talep eder. Her şey doğruysa service ticket ve ilgili session key istemciye döner.

Akışı Birleştirmek: RC4’ü Devre Dışı Bırakma Değerlendirmeleri

Kerberos akışı netleştikten sonra, RC4’ü kapatma kararı için kritik noktalar aşağıdaki başlıklarda toplanır.

Authenticator Şifreleme Türü

Bazı durumlarda istemci ilk TGT isteğinde (KRB_AS_REQ) authenticator gönderir ve işletim sistemi yapılandırmasına göre seçtiği şifreleme türünü beyan eder. Bazı durumlarda ise istemci authenticator olmadan TGT ister; DC bu durumda KDC_ERR_PREAUTH_REQUIRED yanıtı ile birlikte desteklediği şifreleme türlerinin listesini döner.

Her iki senaryoda da istemci ve DC’nin ortak bir şifreleme türünde anlaşması gerekir. İlgili dokümana göre Windows Server 2000, Windows Server 2003 ve Windows XP, AES’in hiçbir sürümünü desteklemez. Dolayısıyla ortamınızda bu legacy işletim sistemleri varsa, domain controller’larınızdan RC4 desteğini kaldırmaya hazır değilsiniz.

TGT Şifreleme Türü

TGT yalnızca üretildiği domain’in DC’leri tarafından okunur. Bu nedenle TGT’nin şifreleme türünün yalnızca DC’ler tarafından desteklenmesi yeterlidir. Domain Functional Level (DFL) 2008 veya üzeri olduğunda KRBTGT hesabı varsayılan olarak AES şifrelemeye geçer.

Diğer hesap türleri (kullanıcı ve bilgisayar) için seçilen şifreleme türü, hesap üzerindeki msDS-SupportedEncryptionTypes özniteliğine göre belirlenir. Bu öznitelik doğrudan düzenlenebilir veya Account sekmesindeki AES checkbox’ları ile AES etkinleştirilebilir.

msDS-SupportedEncryptionTypes “Decoder Ring” Tablosu

Aşağıdaki tablo, tek bir HEX değer ile hangi şifreleme türlerinin desteklendiğini gösterir. Bu tablo, makaledeki “decoder ring” içeriğinin kurumsal formatta korunmuş halidir.

Decimal Value	Hex Value	Supported Encryption Types
0	0x0	Not defined – defaults to RC4_HMAC_MD5
1	0x1	DES_CBC_CRC
2	0x2	DES_CBC_MD5
3	0x3	DES_CBC_CRC, DES_CBC_MD5
4	0x4	RC4
5	0x5	DES_CBC_CRC, RC4
6	0x6	DES_CBC_MD5, RC4
7	0x7	DES_CBC_CRC, DES_CBC_MD5, RC4
8	0x8	AES 128
9	0x9	DES_CBC_CRC, AES 128
10	0xA	DES_CBC_MD5, AES 128
11	0xB	DES_CBC_CRC, DES_CBC_MD5, AES 128
12	0xC	RC4, AES 128
13	0xD	DES_CBC_CRC, RC4, AES 128
14	0xE	DES_CBC_MD5, RC4, AES 128
15	0xF	DES_CBC_CBC, DES_CBC_MD5, RC4, AES 128
16	0x10	AES 256
17	0x11	DES_CBC_CRC, AES 256
18	0x12	DES_CBC_MD5, AES 256
19	0x13	DES_CBC_CRC, DES_CBC_MD5, AES 256
20	0x14	RC4, AES 256
21	0x15	DES_CBC_CRC, RC4, AES 256
22	0x16	DES_CBC_MD5, RC4, AES 256
23	0x17	DES_CBC_CRC, DES_CBC_MD5, RC4, AES 256
24	0x18	AES 128, AES 256
25	0x19	DES_CBC_CRC, AES 128, AES 256
26	0x1A	DES_CBC_MD5, AES 128, AES 256
27	0x1B	DES_CBC_MD5, DES_CBC_MD5, AES 128, AES 256
28	0x1C	RC4, AES 128, AES 256
29	0x1D	DES_CBC_CRC, RC4, AES 128, AES 256
30	0x1E	DES_CBC_MD5, RC4, AES 128, AES 256
31	0x1F	DES_CBC_CRC, DES_CBC_MD5, RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96

KRBTGT Üzerinde AES Etkin Olduğu Halde TGT’ler Hala RC4 ile Çıkıyorsa

KRBTGT hesabında AES etkinleştirildiği halde TGT’ler hâlâ RC4 ile üretiliyorsa, KRBTGT parolasının manuel resetlenmesi gerekebilir. Bunun nedeni KRBTGT parolasının otomatik olarak döndürülmemesidir (rotate). Mevcut parola, AES anahtar üretiminin desteklenmediği 2003 döneminde set edilmiş olabilir.

Bu durumda parola güncellemesi gerekiyorsa ilgili script kullanılabilir. Ayrıca, password history özniteliğinde AES anahtarının bulunması için, en az 10 saat (varsayılan TGT süresi) beklenerek ikinci bir reset önerilir.

Session Key Şifreleme Türü

İstemcinin desteklediği şifreleme türü, authenticator tarafına benzer şekilde istemci işletim sistemi yapılandırmasına bağlıdır ve bilet isteği sırasında (KRB_AS_REQ) beyan edilir.

• TGT için seçilen session key, istemci ve ilgili domain’in DC’leri ile uyumlu olmalıdır.
• Service ticket için seçilen session key, istemci ve kaynağı barındıran sunucu ile uyumlu olmalıdır.

Uygun session key seçimi sırasında KDC:

• İstemcinin talebini
• Hedef hesabın msDS-SupportedEncryptionTypes özniteliğini

değerlendirir.

Service Ticket Şifreleme Türü

Service ticket talep edildiğinde DC, biletin şifreleme türünü talep edilen SPN ile ilişkili hesabın msDS-SupportedEncryptionTypes özniteliğine göre seçer. Bu hesap:

• Bir computer object olabilir
• Ağı üzerinde kaynağı sunan bir service account olabilir

Öznitelikte bir değer tanımlı değilse, DC uyumluluk için bileti RC4 ile şifreler.

Varsayılan olarak kullanıcı hesaplarında değer set edilmediği için, manuel olarak AES etkinleştirilmemiş servis hesaplarına ait biletler RC4 ile şifrelenir.

Bilgisayar nesnelerinde:

• msDS-SupportedEncryptionTypes doğrudan güncellenebilir
• Desteklenen şifreleme türleri GPO ile tanımlanabilir
• Bilgisayar bu policy’yi işlediğinde, kendi bilgisayar hesabı üzerinde attribute’u günceller

Referral Ticket Şifreleme Türü (Trust Senaryoları)

Referral ticket ve session key için kullanılan şifreleme:

• Trust özellikleri
• İstemcinin desteklediği şifreleme türleri

tarafından belirlenir.

Eğer “The other domain supports AES Encryption” seçilirse referral ticket’lar AES ile üretilecektir. Aksi halde referral ticket RC4 ile şifrelenir.

Varsayılan olarak trust’larda (inter-forest trust dahil) AES etkin değildir. Trust üzerinde AES etkinleştirmeyi değerlendirirken:

• İstemci referral ticket içeriğini okumaz
• Ancak istemcinin ortak bir session key şifreleme türüne ihtiyacı vardır

Trust üzerinde RC4 devre dışı bırakılması düşünülüyorsa önce KB4492348 incelenmelidir. Ayrıca Daniele’nin blogunda belirtildiği gibi, “Active Directory Domains and Trusts” GUI üzerinden AES etkinleştirmek trust üzerinde RC4’ü devre dışı bırakır; ksetup kullanımı ise RC4’ü devre dışı bırakmadan AES desteği eklemeye olanak sağlar.

Güncelleme Notu (Kasım 2022)

Kasım 2022 güncellemesi, referral ticket şifreleme mantığını değiştirmiştir. Bu nedenle artık trust’lar için AES’i manuel etkinleştirmek gerekli değildir.

Şifreleme Türü için Denetim (Auditing)

Sertleştirme önerilerinin uygulanmamasının en yaygın nedeni, kurumsal ortamlarda bilinmeyene duyulan endişedir. Kerberos için AES zorunluluğuna doğru ilerlemek, analiz gerektirir. Bu değerlendirmede en değerli girdilerden biri, DC Security loglarındaki 4769 event’leridir. Bu event’ler, üretilen service ticket’ların şifreleme türünü Ticket Encryption Type alanında gösterir.

Benzer şekilde 4768 event’i, üretilen TGT’lerin şifreleme türünü gösterir.

Merkezi log toplama ve analiz çözümünüz varsa, kısa sürede genel görünüm elde edilebilir. Yoksa süreç daha zorlayıcıdır. Aşağıdaki tablo, event’lerdeki değerlerin hangi şifreleme türüne karşılık geldiğini gösterir.

Type Value	Encryption Type Used
0x1	DES-CBC-CRC
0x3	DES-CBC-MD5
0x11	AES128-CTS-HMAC-SHA1-96
0x12	AES256-CTS-HMAC-SHA1-96
0x17	RC4-HMAC
0x18	RC4-HMAC-EXP

Ek olarak, hesapta AES anahtarı olmadığı için service ticket isteğinin başarısız olduğu durumlarda Event ID 16 da faydalı olabilir.

Kerberos Şifreleme Türlerinde RC4 Devre Dışı Bırakma: Yapılması ve Yapılmaması Gerekenler

Yapılmaması Gerekenler

• Kapsamlı bir değerlendirme yapmadan domain genelinde RC4’ü devre dışı bırakmayın.
• Bu rehberi, TLS/SSL (Schannel) tarafında RC4’ü kapatma ayarlarıyla karıştırmayın. TLS tarafında RC4 kapatma gerekiyorsa MSRC içeriğine bakın.
• RC4’ün size zorla kapattırılmasını beklemeyin. AES’in bilgisayarlarda, hesaplarda ve trust’larda tamamen etkin olduğundan emin olmaya başlayın. Sonrasında merkezi log toplama ile 4769 event’lerini analiz ederek hala RC4 bilet üretilip üretilmediğini tespit edin.

Yapılması Gerekenler

• SPN tanımlı servis hesaplarında AES’i etkinleştirin. msDS-SupportedEncryptionTypes alanının boş olması, DC’nin service ticket ve session key’i RC4 ile üretmesine neden olur.
  
• AES anahtarı olmayan servis hesaplarının parolalarını resetleyin. 2008 öncesinde set edilmiş parolalarda AES anahtarı yoktur.
  
  • İpucu: “Read-only Domain Controllers” domain grubunun oluşturulma tarihi, domain’inizde 2003’ten yeni ilk DC’nin ne zaman yükseltildiğini gösterir. PowerShell ile SPN’i olan ve pwdLastSet değeri bu tarihten eski olan kullanıcı hesaplarını tespit edin.
    
• TGT’lerinizin AES ile şifrelenip şifrelenmediğini doğrulayın. Hala RC4 üretiliyorsa KRBTGT hesabının pwdLastSet değerinin, “Read-only Domain Controllers” grubunun created tarihinden yeni olup olmadığını kontrol edin.
  
• Kerberoasting’in RC4 ile şifrelenmiş bir service ticket alındığında zayıf servis hesabı parolalarını saldırgana pratik olarak “hazır” hale getirdiğini unutmayın. Özellikle ayrıcalıklı servis hesaplarında güçlü parola ve AES etkinleştirme önceliklidir. Kerberoasting, service ticket elde edildikten sonra offline yapılabildiği için EDR’a güvenilecek bir alan değildir.
  
• KeyTab dosyalarını iyileştirmeyi unutmayın. Mevcut KeyTab ile kullanılan bir servis hesabında AES etkinleştirirseniz yeni KeyTab üretimi gerekebilir. Birçok kurumun sağlam bir KeyTab envanteri olmadığı için bu alan zordur.
  
• RC4’e bağımlı cihazları tespit etmek için 4768 event’lerini kullanın.
  
• klist ile bilet ve session key üzerinde kullanılan şifreleme türünü nasıl göreceğinizi öğrenin. UAC açıksa, yükseltilmiş komut istemi ile normal komut isteminde farklı sonuçlar görebilirsiniz; çünkü teknik olarak iki ayrı oturum ve iki ayrı bilet seti vardır. Sistem hesabına ait biletleri görmek için yükseltilmiş pencerede klist –li 0x3e7 çalıştırın.
  
• Bilet şifrelemesinin yalnızca bileti “açan” hesapla uyumlu olmasının yeterli olduğunu; ancak session key’in bağlantının her iki tarafıyla uyumlu olması gerektiğini aklınızda tutun.
  
• AES şifreli biletlerle uyumlu olmayan legacy işletim sistemlerini (Server 2003 ve daha eski) emekli edin.
  
• Ağ trafiği yakalamalarında göreceğiniz şifreleme türü müzakerelerini iyi anlatan diğer teknik blogları da inceleyin.