Güvenlik araştırmacıları SilverfortAracısız kimlik doğrulama platformu sağlayıcısı, bilgisayar korsanlarının Cisco Adaptive Security Appliance (ASA) üzerinde kontrol sahibi olmasını sağlayabilecek ciddi bir güvenlik açığı belirledi. Tüm ASA sürümleri etkilenir. Güvenlik açığını Cisco'ya ifşa ettikten sonra Cisco, desteklenen tüm ASA sürümlerini düzeltti ve bir danışma yayınladı üstünde. Güvenlik açığına (CVE-2020-3125) 8.1 üzerinden 10 CVSS risk puanı verildi ve bu puan "Yüksek" olarak değerlendirildi. Bunun nedeni, güvenlik açığının bir saldırganın Kerberos Cisco ASA'ya kimlik doğrulama. Silverfort güvenlik açığını keşfettikleri için kredilendirilen araştırmacılar şunlardır: Yoav Iellin, Yaron Kassner, Dor Segal & Rotem Zach.

Cisco, ASA'nın tüm sürümlerinde bu güvenlik açığını düzeltti. Kuruluşların bir açıktan yararlanmaya karşı koruma sağlamak için en son ASA sürümlerine yükseltme yapmalarını önemle tavsiye ederiz.

Bu makale, KDC kimlik sahtekarlığı güvenlik açığını özetlemekte ve bunun Cisco ASA'ya yönelik kimlik doğrulamasını atlamak için nasıl kullanılabileceğini göstermektedir. Kerberos'u uygulayan bir geliştiricinin yanı sıra bu çözümleri ağlarında zaten uygulamış olan kuruluşlar olarak bu güvenlik açıklarından nasıl kaçınılacağını açıklayacaktır.

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

Güvenlik açığı, Cisco'nun Kerberos uygulamasında yatmaktadı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 bulunur. Active Directoryve NTLM gibi daha zayıf kimlik doğrulama protokollerine göre tercih edilir.

Cisco, birçok ASA arabiriminde Kerberos kimlik doğrulama protokolünü kullanır; örneğin, VPN, güvenlik duvarı oturumlarını açma ve web yönetim konsolu veya SSH aracılığıyla yönetici erişimi. Bu nedenle, Kerberos kimlik doğrulamasını atlamak, bir saldırganın Cisco cihazını ele geçirmesine, güvenliğini atlamasına ve diğer ağlara erişim kazanmasına 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 Cisco ASA'da kimlik doğrulaması yapmasına olanak tanı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ılar oturum açtıklarında kimlik bilgilerini girerler 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, Kerberos protokolünü etkileyen bir güvenlik açığı bildirdi. Ş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 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 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 ana hatlarıyla belirtildiği gibi bir ARP sızdırma saldırısı gerçekleştirebilir. 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.

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

Eklemenin bir yolunu arıyorduk Çok Faktörlü Kimlik Doğrulama (MFA) Cisco ASA ve Anyconnect VPN'e erişen yöneticilere. Cisco'yu kimlik doğrulama protokolü olarak Kerberos kullanacak şekilde yapılandırdıktan sonra, kimlik doğrulama günlüklerini inceledik. Silverfortkonsolu. Silverfort ağdaki tüm kimlik doğrulama faaliyetlerine tam görünürlük sağlar. Silverfort'nin günlükleri, Cisco ASA'nın hizmet bileti talep etmeden TGT talep ettiğini gösterdi.

Yapılandırma kılavuzuna geri döndük Cisco. 2007. PIX/ASA : ASDM/CLI Yapılandırma Örneği Yoluyla VPN İstemci Kullanıcıları için Kerberos Kimlik Doğrulaması ve LDAP Yetkilendirme Sunucusu Grupları. 30 Temmuz. ; ve Kerberos kimlik doğrulamasını yapılandırmak için gereken parametrelere baktı:

Yukarıda görüldüğü gibi, Kerberos kimlik doğrulaması için parola veya keytab yapılandırmasını girebileceğiniz bir yer yoktur. Parola veya keytab, Kerberos tarafından KDC'ye güvenilir bir şekilde kimlik doğrulaması yapmak için kullanılan "sırrı" oluşturduklarından, doğru bir uygulama için gereklidir. 'Sır' olmadan, kimlik doğrulama kriptografik olarak güvenilir olamaz.

Devam ettik ve aynı şeyi diğer Cisco arayüzleri için denedik ve aynı güvenlik açığının güvenlik duvarı oturumlarını açarken, yönetici kimlik doğrulamasında ve hatta VM'ye erişmek için SSH kullanırken var olduğunu gördük. Farklı kimlik doğrulama protokolleri için Cisco desteğini özetleyen tablodaki Kerberos sütununun altına bakın.

Istismar

Ardından, bu güvenlik açığından yararlanılıp yararlanılamayacağını görmek istedik. Bunun için DC'ye yönelik Kerberos trafiğini ele geçirdik ve sunucumuza yönlendirdik. Kendi KDC mantığımızı geliştirmek yerine, sahte sunucumuza AD Etki Alanı Hizmetlerini yükledik ve sunucumuzu bir etki alanı denetleyicisi olarak yükselttik. Tabii orijinal domainde yönetici olmadığımız için yeni bir fake domain oluşturduk.

İlk etki alanındaki Cisco yöneticisinin kullanıcı adını bildiğimiz için (bu örnekte Bob), sahte etki alanımızda Bob adında bir kullanıcı oluşturduk. Sahte alanımızdaki o kullanıcının şifresini “1” olarak yapılandırdık.

Daha sonra aşağıdaki durumları denedik:

• Düzenli oturum açma (Trafik yönlendirilmedi) – beklendiği gibi Bob'un 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çmak – Bob'un orijinal parolasıyla oturum açmak başarısız oldu, ancak "1" parolasıyla oturum açmak işe yaradı.

Önleme ve Azaltma

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

1. Öncelikle Cisco ASA'nızı sabit bir sürüme yükseltin ve gerekli yapılandırma değişikliklerini aşağıda ayrıntıları verilen şekilde yapın. Cisco danışma
2. 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.
3. kullanım Silverfort'S Silverfort'nin açık kaynak aracı hizmet biletleri istemeyen hizmetler için kimlik doğrulama günlüklerini aramak için.
4. Kerberos'u ve kendi yapılandırdığınız sistemleri uygulayan dahili olarak geliştirilmiş uygulamalar için geliştirici önerilerine bakın.
5. Silverfort Palo Alto Networks ile adım adım kimlik doğrulama yeteneğinden yararlanan müşteriler, Silverfort PAN-OS'lerini yükselttikten sonra bir TGT politikasından bir hizmet bileti politikasına MFA politikası.

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. 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. 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'i kullan^rd uygun şekilde parti kitaplıkları - bazı 3^rd 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)