Tarafından Tanımlanan Üçüncü KDC Kimlik Sahtekarlığı Güvenlik Açığı Silverfort Araştırmacılar – Bu Kez IBM QRadar'da [CVE-2019-4545]

*****Yoav Iellin tarafından, Yaron Kassner, Dor Segal & Rotem Zach, Silverfort*****

KDC sahtekarlığı asla eskimez. Şuradaki KDC kimlik sahtekarlığı güvenlik açıklarını ifşa ettik: Cisco ASA ve Palo Alto Ağları PAN-OS Mayıs 2020'de. Artık IBM QRadar'ın da yol nedeniyle saldırıya açık olduğunu paylaşabiliriz. Kerberos uygulandı.
KDC Spoofing güvenlik açığı, bir saldırganın Kerberos kimlik doğrulamasını QRadar'a atlamasına ve sonuç olarak sisteme yönetici erişimi kazanmasına olanak tanır. Bu sorunu çözmeye yardımcı olmak için IBM mühendisleriyle yakın bir şekilde çalışıyoruz ve bunun sonucunda yakın zamanda yayınlanan güvenlik bülteni . Bu blog yazısı güvenlik açığını ana hatlarıyla belirtir, Kerberos uygulayan bir geliştirici olarak bu güvenlik açıklarından nasıl kaçınılacağını açıklar ve QRadar kullanan kuruluşlar ve Kerberos kullanan diğer sistemler için hafifletme hakkında konuşur.

Güvenlik Açığının Açıklanması

IBM QRadar Security Information and Event Management (SIEM), güvenlik ekiplerinin kuruluş genelindeki tehditleri tespit etmesine ve öncelik sırasına koymasına yardımcı olur ve ekiplerin olayların etkisini azaltmak için hızla yanıt vermesini sağlayan önemli içgörüler sağlar.
Güvenlik açığı, IBM'in Kerberos protokolünü uygulamasından kaynaklanmaktadır. Kerberos, şirket içi kimlik doğrulama için en yaygın kimlik doğrulama protokolüdür. Popülerliği nedeniyle kurumsal ağlarda yaygın olarak kullanılmaktadır. Active Directoryve NTLM gibi daha zayıf kimlik doğrulama protokollerine göre tercih edilir.
IBM, yönetim erişiminin kimliğinin doğrulanması için Kerberos kimlik doğrulama protokolünü kullanır. Bu nedenle, Kerberos kimlik doğrulamasını atlamak, bir saldırganın meşru kimlik bilgileri olmadan IBM QRadar'a yönetici erişimi kazanmasına, hassas bilgileri görüntülemesine ve potansiyel olarak günlükleri değiştirmesine olanak tanır.
Kerberos protokolünün çalışması için üç şey gerçekleşmelidir:

• 1. kullanıcı sunucuya kimlik doğrulaması yapar
  2. sunucu istemciye kimlik doğrulaması yapar
  3. KDC, sunucuda kimlik doğrulaması yapar

Görünüşe göre, sunucuya yönelik KDC kimlik doğrulaması genellikle göz ardı ediliyor. Belki de bunu gerektirmesi, yapılandırma gereksinimlerini karmaşıklaştırması nedeniyledir. Bununla birlikte, KDC sunucuda kimlik doğrulaması yapmazsa, protokolün güvenliği tamamen tehlikeye atılır ve ağ trafiğini ele geçiren bir saldırganın yanlış bile olsa herhangi bir parolayla QRadar'da kimlik doğrulaması yapmasına olanak tanır.

Kerberos terminolojisi ve KDC kimlik sahtekarlığı saldırısının nasıl çalıştığına ilişkin arka plan için bu blog gönderisinin sonuna bakın.

QRadar'daki Güvenlik Açığı Nasıl Keşfettik?

QRadar'a yönetici erişimi, yetkisiz erişimi ve sistem kurcalamayı önlemek için güçlü kimlik doğrulama ile korunmalıdır. AD kimlik doğrulamasını kullanmak popüler bir seçenektir:
Bir yönetici QRadar'da kimlik doğrulaması yaptığında, yöneticinin kimliğini doğrulamak için bir dizi parametre kullanır (aşağıdaki uygulama kılavuzunun anlık görüntüsüne bakın. okuyun). İlk olarak QRadar, AD'den bir TGT ister. TGT'yi aldıktan sonra QRadar, etki alanı denetleyicisine LDAP kimlik doğrulaması için bir hizmet bileti ister. Başarılı olursa QRadar, DC'ye LDAP ile kimlik doğrulaması yapmak için SASL'yi kullanır. Kullanıcının kimliğini kanıtlamak için hizmet biletini kullanır.

Sahte Kerberos/SASL kimlik doğrulaması

Bir saldırganın bu tür bir kimlik doğrulamayı atlamak için bir DC'yi taklit etmek için uygulayacağı adımlar aşağıda verilmiştir. QRadar ve DC arasındaki ağ iletişimini ele geçirme yeteneğine sahip olduğumuzu varsayalım. Bu durumda, yöneticinin kullanıcı adı ile aynı kullanıcı adı ve kendi seçeceğimiz bir şifre ile sahte bir DC oluşturabiliriz. Ardından, QRadar için bir kimlik doğrulaması başlatır ve seçtiğimiz kullanıcı ve şifreyi kullanırız. QRadar, Kerberos ile kimlik doğrulaması yapıyor ve Kerberos iletişimini ele geçirip seçtiğimiz parolaya karşılık gelen bir AS_REP döndürüyoruz; ve bizim seçtiğimiz bir hizmet oturum anahtarıyla şifrelenmiş bir hizmet biletinden ve bizim seçtiğimiz parolayla şifrelenmiş, bizim seçtiğimiz bir oturum anahtarından oluşan bir TGS_REP. Bu aşamalarda QRadar tarafında yapılan tek doğrulama, seçtiğimiz parolaya dayandığından, QRadar bu noktada kimlik doğrulamayı reddetmemelidir. Artık QRadar hizmet biletini aldığına göre, DC'ye bir LDAP isteği başlatabilir. LDAP trafiğini de ele geçireceğiz. Bu noktada iki seçeneğimiz var:
1. LDAP, TLS olmadan kullanılıyor. Bu durumda LDAP trafiğini ele geçirebiliriz. QRadar, sahip olduğumuz hizmet biletini içeren bir Kerberos AP_REQ mesajı ile DC'ye bir bağlama isteği gönderir. Seçtiğimiz hizmet oturum anahtarına dayalı bir AP_REP döndürebiliriz ve QRadar bunu kabul eder.
2. LDAPS yapılandırıldı. Bu durumda, DC adına bir yanıt döndüremeyiz çünkü TLS, DC'nin kimliğini doğrulamak için kullanılıyor, yani sertifikanın QRadar tarafında yapılandırıldığı varsayılıyor.

QRadar için Sahte Kerberos/SASL/LDAPS Kimlik Doğrulaması

2. seçenekten vazgeçmeden önce, aşağıdaki garip davranışı fark ettik. Sunucu URL'si olarak bir IP adresi yapılandırırsak, kimlik doğrulama yine de çalışır. Teorik olarak, bir IP adresiyle kimlik doğrulama çalışmamalıdır, çünkü Kerberos, bir SPN açıkça yapılandırılmadığı sürece IP adreslerinde kimlik doğrulamaya izin vermez.
TGS_REQ gönderirken, QRadar ldap/ için bir bilet ister. DC'nin bu ada sahip bir Hizmet Asıl Adı (SPN) olmadığından, bir KRB_ERR_S_PRINCIPAL_UNKOWN hatası döndürür. Kerberos protokolüne göre, QRadar'ın bu noktada kimlik doğrulamayı reddetmesi gerekiyor. Ancak bir ağ yakalama, bir LDAP isteğinin hatadan sonra bile açıldığını ve QRadar tarafından hemen sıfırlandığını ortaya çıkarır. Ardından, kullanıcı oturum açabilir. QRadar'ın, Kerberos uygulama alışverişi tamamlanmadan önce bile kimlik doğrulamayı başarılı olarak değerlendirdiği sonucuna vardık. Bu kolayca istismar edilebilir. Saldırganlar olarak, AS_REP'yi yanılttıktan hemen sonra bir KRB_ERR_S_PRINCIPAL_UNKOWN gönderebiliriz ve QRadar'ın kendi seçeceğimiz bir parola ile kimlik doğrulamasını kabul etmesini sağlayabiliriz. Saldırı aşağıda tasvir edilmiştir.

QRadar'daki ek bir hata, var olması gerekmeyen bir kullanıcı için AD'den kimlik doğrulama istemesine neden olur. QRadar yerleşik bir yerel yönetici kullanıcıya sahiptir. Yönetici kullanıcıyla kimlik doğrulama girişiminde bulunurken, QRadar'ın önce Kerberos ile DC'de kimlik doğrulaması yapmaya çalıştığı ortaya çıktı. Bu kullanıcı adının AD'de bulunması gerekmez. Kullanıcı adı saldırgan tarafından önceden bilindiği için bu saldırıyı kolaylaştırır.

Ek olarak, bu hata kendi başına bir güvenlik açığı olarak kabul edilebilir. KDC Spoofing'den bağımsız olarak, bir saldırgan örneğin bir yardım masası hesabını devralarak AD'de kullanıcı oluşturmak için ayrıcalıklar elde edebiliyorsa, AD'de admin adlı bir kullanıcı oluşturabilir. Ardından saldırgan, QRadar'da kimlik doğrulaması yapmak için bu kullanıcıyı kullanabilir.

Istismar

Artık QRadar'ın savunmasız olduğunu bildiğimize göre, QRadar ile KDC (bu durumda bir etki alanı denetleyicisi) arasındaki trafiği 88 numaralı bağlantı noktasında (Kerberos bağlantı noktası) kendi Windows Sunucumuza yeniden yönlendirerek bir saldırı simülasyonu yaptık. Windows sunucusunda sahte bir etki alanı kurduk ve gerçek etki alanında QRadar yöneticisi ile aynı UPN'ye sahip bir kullanıcı olduğundan emin olduk. Bu kullanıcının parolasını sahte etki alanında “1” olacak şekilde yapılandırdık.

Daha sonra aşağıdaki durumları denedik:
– Düzenli oturum açma (Trafik yönlendirilmedi) – beklendiği gibi, yöneticinin orijinal parolasıyla oturum açmayı başardık. “1” şifresini denerken giriş başarısız oldu.
– Sahte DC'mize yönlendirilen trafikle oturum açma – yöneticinin orijinal parolasıyla oturum açma başarısız oldu ancak “1” parolasıyla oturum açma işe yaradı.

IBM'in Azaltma

IBM'in bu güvenlik açığını azaltma yaklaşımı basit ve güvenlidir. QRadar'da tam olarak aynı kimlik doğrulama işlevi LDAPS ile elde edilebildiğinden, önerilen hafifletme yöntemi Kerberos'tan LDAPS kimlik doğrulamasına geçmektir. Bundan sonra yamayı IBM tarafından kurmalısınız. Düzeltme eki, kimlik doğrulamanın gerçekten LDAPS olarak ayarlandığını doğrulayacak ve henüz LDAPS kimlik doğrulamasına geçmediyseniz başarısız olacaktır. Bu, yamadan sonra sisteminizin güvenli olduğundan emin olmak içindir.

Eğer kullanıyorsanız Silverfort QRadar'ınızda kimlik doğrulamasını güvence altına almak için ayrıca Silverfort Kerberos TGT isteği yerine LDAPS kimlik doğrulamasını korumak için QRadar politikası.

Önleme ve Azaltma

Güvenlik Uzmanları için Etki Azaltma Adımları

1. Anahtar kimlik doğrulamasıQRadar'ınızda Kerberos'tan LDAPS'ye
2. QRadar'ınızı sabit bir sürüme yükseltin
3. Güncelle Silverfort Buna göre QRadar politikası
4. Kerberos kimlik doğrulamanızı sürekli olarak izleyin. Yalnızca AS_REQ talep eden kaynakları arayın. TGS_REQ yoksa, bu bir tehlike işaretidir.
5. Kullanmak Silverfort'nin açık kaynak aracı hizmet biletleri istemeyen hizmetler için kimlik doğrulama günlüklerini aramak için.
6. Kerberos'u uygulayan dahili olarak geliştirilmiş uygulamalar ve kendi yapılandırdığınız sistemler için geliştirici önerilerine bakın.

Bir geliştirici olarak

Çözümünüzün KDC sahtekarlığına açık olmadığından emin olmak için birkaç adım öneriyoruz:
1. Kerboros uygulamasının bir şifre veya tuş sekmesi gerektirdiğini doğrulayın: DC'yi doğrulamak için bir tür paylaşılan sır kullanmanız gerekir. Çözümünüz bir keytab dosyasının veya bir keytab dosyasının yapılandırılmasına olanak vermiyorsa hizmet hesabı parola, uygulama kesinlikle KDC sahtekarlığına karşı hassastır.
2. Wireshark'ı çalıştırın – kimlik doğrulama sırasında hangi Kerberos isteklerinin gönderildiğini görmek için Wireshark'ı kullanın. TGS_REQ yoksa, bu bir tehlike işaretidir.
3. Kendiniz bir kimlik doğrulama protokolü uygulamak istiyorsanız, protokol RFC'lerini özenle takip etmelisiniz. Daha kolay yolu izlemenizi ve bu protokollerin mevcut bir uygulamasını kullanmanızı öneririz.
4. 3. taraf kitaplıklarını düzgün kullanın – bazı 3. taraf kitaplıkları, KDC sahtekarlığını önlemek için özel yapılandırma gerektirir. Örneğin, Kerberos için kullanılan pam-krb5 adlı ortak bir kitaplığın düzgün çalışması için yapılandırılmış bir keytab'a sahip olması gerekir. İşte belgelerinden ilgili paragraf (https://github.com/rra/pam-krb5/blob/master/README.md)

Sırada ne var?
Başka bir KDC kimlik sahtekarlığı güvenlik açığı keşfettik ve bunun hakkında yakında yazmayı umuyoruz, ancak satıcı bir yama yayınlamadan önce değil. O zamana kadar bizi izlemeye devam edin.

Olayın Arka Planı

Kerberos Protokolüne genel bakış

Kerberos kimlik doğrulama protokolü, 1980'lerde Steve Miller ve Clifford Neuman tarafından geliştirilmiştir. Yönetilen bir ağda Çoklu Oturum Açmaya (SSO) izin verir ve Active Directory (AD) uygulaması, şirket içi kurumsal ortamlar için birincil kimlik doğrulama protokolüne dönüştürdü.
Protokol, kullanıcı ve erişilen sunucu için karşılıklı kimlik doğrulama sağlamak üzere üç değiş tokuştan oluşur. Kullanıcı oturum açtığında kimlik bilgilerini girer ve Kimlik Doğrulama Hizmeti (AS) alışverişi gerçekleşir. Kullanıcı, daha sonra Bilet Verme Hizmeti (TGS) Değişimi sırasında belirli hizmetlere bilet almak için kullanılan bir Bilet Verme Bileti (TGT) alır. Bilet daha sonra kimlik doğrulamayı tamamlamak için İstemci/Sunucu Değişimi sırasında kullanılır:

1. Kimlik Doğrulama Hizmeti (AS) Değişimi

AS değişimi sırasında kullanıcı, Anahtar Dağıtım Merkezi (KDC) ile kimlik doğrulaması yapar. Buna karşılık kullanıcı, kimlik bilgilerini tekrar girmeden ağdaki hizmetlerle kimlik doğrulaması yapmak için gereken bileti ve anahtarı alır. Kullanıcı kimlik bilgilerini ilk girdiğinde, istemci KDC'nin Kimlik Doğrulama Hizmeti (AS) işlevine bir AS_REQ gönderir. AS_REQ, kullanıcının şifresinin bir işlevi olan Ana Anahtar tarafından imzalanan bir mesajdır. KDC'nin bir parçası olan Kimlik Doğrulama Hizmeti, AS_REQ'yu KDC'nin de kullanabileceği ana anahtara göre doğrular. AS_REQ doğrulandıktan sonra KDC, bir oturum açma anahtarı ve KDC'nin anahtarıyla şifrelenmiş bir Bilet Verme Bileti (TGT) içeren bir AS_REP döndürür. AS Değişimi aşağıda özetlenmiştir. TGT, belirli hizmetlere erişim elde etmek için TGS borsası tarafından kullanılacaktır.

2. Bilet Verme Hizmeti (TGS) Değişimi

Kullanıcı ağdaki bir hizmete erişmeye çalıştığında, KDC'nin Bilet Verme Sunucusu (TGS) işlevine bir TGS_REQ gönderir. Bu mesaj, AS Exchange sırasında elde edilen oturum açma anahtarı ile şifrelenir. TGS_REQ, daha sonra bir TGS_REP döndüren TGS tarafından doğrulanır. TGS_REP, hizmeti barındıran sunucunun ana anahtarıyla şifrelenmiş bir hizmet oturum anahtarı ve bir hizmet bileti içerir. Unix tabanlı bir sistemdeki sunucunun ana anahtarı, keytab dosyası adı verilen bir dosyada yapılandırılır. Bir üye sunucudaki sunucunun ana anahtarı, bilgisayar hesabının parolasından türetilir. TGS Borsası aşağıda özetlenmiştir.

3. İstemci/Sunucu Değişimi

Artık istemci, hizmette kimlik doğrulaması yapmak için ihtiyaç duyduğu her şeye sahiptir. İstemci, hizmet oturum anahtarıyla şifrelenen hizmete bir AP_REQ gönderir. Hizmet, AP_REQ'yi doğrulamak için hizmet oturum anahtarının şifresini çözer. Ardından sunucu bir AP_REP mesajı döndürür ve kimlik doğrulama tamamlanır. İstemci sunucu değişimi aşağıda özetlenmiştir:

Spoof-Proof Protokolü

Kerberos protokolü doğru bir şekilde uygulandığında, KDC'yi taklit etmeye çalışan bir saldırgan, kimlik doğrulamasını atlayamaz. Bunun nedeni, bir saldırgan ele geçirilen bir AS_REQ'e yanıt olarak başarılı bir şekilde geçerli bir AS_REP oluştursa bile, saldırganın hiçbir zaman geçerli bir hizmet bileti düzenleyememesidir. Hizmet bileti, saldırganın sahip olmadığı bir anahtar olan sunucu anahtarıyla şifrelendiğinden, bu imkansız olacaktır.

KDC Sahtekarlığı nedir?

2000 yılında, Dug Song bir rapor verdi. güvenlik açığı Kerberos protokolünü etkileyen (Şarkı, Dug.2000. Kerberos KDC Kimlik Sahtekarlığı Güvenlik Açığı. 28 Ağustos.).
Kerberos istemcilerinin belirli uygulamalarının ve yapılandırmalarının İstemci/Sunucu alışverişini yürütmekte başarısız olduğunu ve önceki alışverişlerin başarısına dayalı olarak kimlik doğrulamaya izin verdiğini keşfetti. Ne yazık ki, bu davranış güvenli değildir ve bir saldırgan tarafından kötüye kullanılabilir. İstemci ile DC arasındaki iletişimi ele geçirebilen bir saldırgan aşağıdaki adımları uygulayabilir:
1. Sahte bir KDC oluşturun.
2. Saldırmak istediğiniz hizmete erişme yetkisine sahip bir kullanıcı adı edinin.
3. Sahte KDC'de saldırganın seçtiği bir parolayla bir kullanıcı oluşturun. Gösterim için bu şifreye “1” diyelim.
4. Elde edilen kullanıcı adı ve parola "1" ile hizmette kimlik doğrulaması yapın.
5. İstemciden DC'ye iletişimi ele geçirin ve sahte KDC'ye yönlendirin.
6. AS Değişimi sırasında, “1” parolasına karşılık gelen bir AS_REP, sahte KDC anahtarı ve sahte oturum açma anahtarı döndürün.
7. TGS Değişimi sırasında herhangi bir TGS_REP'yi iade edin.
8. İstemci, uygulama değişimi gerçekleştirmeden kimlik doğrulamayı kabul edecektir.

KDC yanıltma saldırıları, saldırganın KDC'ye giden ve buradan gelen trafiği ele geçirebildiğini ve KDC adına yanıt verebildiğini varsayar. Bu, çeşitli teknikler kullanılarak yapılabilir. Örneğin, saldırgan istemci ile aynı fiziksel ağ segmentindeyse, Ağ Güvenliği Hack'lerinde (Lockhart 2007). Başka bir olası yaklaşım, anahtar veya yönlendirici gibi bir ağ aygıtını devralmak ve iletişimi oradan kontrol etmektir.