Silverfort Araştırmacılar, F5 Big-IP'de [CVE-2021-23008] KDC Kimlik Sahtekarlığı Güvenlik Açığı Keşfetti

Ana Sayfa » Blog » Silverfort Araştırmacılar, F5 Big-IP'de [CVE-2021-23008] KDC Kimlik Sahtekarlığı Güvenlik Açığı Keşfetti

Geçen yıl üç Anahtar Dağıtım Merkezi (KDC) kimlik sahtekarlığı güvenlik açığı bildirdik. Cisco ASA, Palo Alto Ağları PAN-OS ve IBM QRadar. Başka birinin geleceğinden bahsetmiştik ve şimdi F5 bir düzeltme yayınladı, tespit ettiğimiz dördüncü KDC kimlik sahtekarlığı güvenlik açığını bu kez Big-IP'de yayınlıyoruz. KDC Spoofing güvenlik açığı, bir saldırganın Kerberos kimlik doğrulamasını Big-IP Access Policy Manager'a atlamasına, güvenlik politikalarını atlamasına ve hassas iş yüklerine sınırsız erişim kazanmasına olanak tanır. Bazı durumlarda bu, Big-IP yönetici konsoluna yönelik kimlik doğrulamasını atlamak için de kullanılabilir. Bu sorunu çözmeye yardımcı olmak için F5 mühendisleriyle yakın bir şekilde çalışıyoruz ve sonuç olarak yakın zamanda yayınlanan danışmanlık. Bu blog gönderisi, güvenlik açığını özetlemekte ve uygularken bu kusurlardan nasıl kaçınılacağını açıklamaktadır. Kerberosve Big-IP ve diğer Kerberos tabanlı sistemleri kullanan müşteriler için hafifletme adımlarını tartışır.

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

F5 Big-IP Uygulama Teslim Hizmetleri, uygulamaları güvenli ve ölçeklenebilir bir şekilde sunan bir çözümdür. Temel bileşenlerinden biri, erişimin uygun şekilde doğrulanmasını ve yetkilendirilmesini sağlamak için politikaları yöneten ve uygulayan Erişim Politikası Yöneticisidir (APM). APM bazen Big-IP yönetici konsoluna erişimi korumak için de kullanılır.

Güvenlik açığı, F5'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.

Kerberos, bir APM ilkesinin gerektirdiği kimlik doğrulama için bir kimlik doğrulama protokolü olarak kullanılabilir. Bir kullanıcı Big-IP yoluyla bir uygulamaya eriştiğinde, kendisine bir giriş portalı sunulabilir ve bir kullanıcı adı ile parola girmesi istenebilir. Kullanıcı adı ve parola, kullanıcının iddia ettiği kişi olduğundan emin olmak için Kerberos protokolüyle AD'ye karşı doğrulanır. Bu nedenle, Kerberos kimlik doğrulamasını atlamak, bir saldırganın yasal kimlik bilgilerine sahip olmadan Big-IP uygulamalarına erişmesine 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şık hale getirdiği için. Ancak, 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 geçersiz bile olsa herhangi bir parolayla Big-IP'de 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.

Aşağıda, bir erişim ilkesi için AD kimlik doğrulamasını yapılandırma talimatlarının şu adresten alınmış bir ekran görüntüsü bulunmaktadır: F5 web sitesi.

Bu yapılandırmadan sonra, bir kullanıcı proxy'nin arkasında oturan bir uygulamada kimlik doğrulaması yapmaya çalıştığında, kullanıcıdan bir kullanıcı adı ve parola girmesi istenir. Kullanıcı parolasını girdiğinde ürün, etki alanı denetleyicisinde (DC) kimlik doğrulaması yapmak için Kerberos'u kullanır. Ancak APM, bir hizmet bileti talep etmez ve başarılı bir AS_REP'ye dayalı olarak erişim izni verir.
Diğer senaryolardan farklı olarak F5, bir yönetici kullanıcı adı ve parolası yapılandırmanıza izin verir.

Teorik olarak, bu parola DC'nin kimliğini doğrulamak ve güvenlik açığını önlemek için kullanılabilir. Ancak, bu amaçlar için kullanılmaz, yalnızca birincil veya iç içe grupları getirmek, kullanıcıdan parola değişikliği istemek veya bir karmaşıklık kontrolü veya parola sıfırlama gerçekleştirmek amacıyla kullanılır.

Sahte Kerberos kimlik doğrulaması

Saldırganın bu tür bir kimlik doğrulamayı atlamak için bir DC'yi yanıltmak için uygulayabileceği adımlar şunlardır. Big-IP ile 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, Big-IP için bir kimlik doğrulaması başlatır ve seçtiğimiz kullanıcı ve şifreyi kullanırız. Big-IP, Kerberos ile kimlik doğrulaması yapar ve Kerberos iletişimini ele geçirir ve seçtiğimiz parolaya karşılık gelen bir AS_REP döndürürüz; 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 Big-IP tarafında yapılan tek doğrulama, seçtiğimiz parolaya dayandığından, Big-IP kimlik doğrulamaya izin verecektir.

Istismar

Big-IP ile KDC (bu durumda bir etki alanı denetleyicisi) arasındaki trafiği 88 numaralı bağlantı noktasında (Kerberos bağlantı noktası) kendi bağlantı noktamıza yönlendirerek bir saldırı simülasyonu yaptık. Windows Server. Windows sunucusunda sahte bir etki alanı kurduk ve gerçek etki alanında Big-IP 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 senaryoları denedik:

  • Düzenli oturum açma (Trafik yönlendirilmedi) – beklendiği gibi kullanıcının 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ı.

Önleme ve Azaltma

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

  1. Big-IP'nizi sabit bir sürüme yükseltin
  2. Kullanmakta olduğunuz Big-IP sürümü için sabit bir sürüm yoksa, emin olun. MFA etkin.
  3. Güncelleyin Silverfort Buna göre Big-IP için politika
  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. kullanım Silverfort'nin açık kaynak aracı hizmet biletleri istemeyen hizmetler için kimlik doğrulama günlüklerini aramak için.
  6. Kerberos'u ve kendi yapılandırdığınız sistemleri uygulayan dahili olarak geliştirilmiş uygulamalar için geliştirici önerilerine bakın.

Geliştiriciler İçin

Çözümünüzün KDC sahtekarlığına açık olmadığından emin olmak için birkaç adım öneriyoruz:

  1. Kerberos uygulamasının bir parola veya keytab 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ı yapılandırmayı etkinleştirmiyorsa veya 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. Bir kimlik doğrulama protokolünü kendiniz uygulamak istiyorsanız, protokol belirtimini özenle takip etmelisiniz. Daha kolay yolu izlemenizi ve bu protokollerin mevcut bir uygulamasını kullanmanızı öneririz.
  4. 3. taraf kitaplıklarını doğru şekilde 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)

Pam Kimlik Doğrulaması

Sırada ne var?

Eminim bu, karşılaşacağımız son KDC kimlik sahtekarlığı güvenlik açığıdır.

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'nun doğrulanmasından 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.

Kimlik Doğrulama Hizmeti

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.
Bilet Verme Hizmeti

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:

İstemci ve Sunucu Değişimi

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 istedikleri 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. Örneğ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 onu sahte KDC'ye yönlendirin.
  6. AS Değişimi sırasında, "1" parolasına, sahte KDC anahtarına ve sahte oturum açma oturum anahtarına karşılık gelen bir AS_REP döndürün.
  7. TGS Değişimi sırasında herhangi bir TGS_REP döndürün.
  8. İstemci, bir uygulama değişimi gerçekleştirmeden kimlik doğrulamayı kabul edecektir.

KDC kimlik sahtekarlığı saldırıları, saldırganın KDC'ye giden ve KDC'den 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.

Teşekkür

Bu güvenlik açığının araştırılması ve keşfi, keşfedildiği sırada Exclusive Networks'te çalışan Thierry Van Steirteghem ile ortak bir çabayla gerçekleştirildi.

Kimlik Tehditlerini Hemen Durdurun