Akamai Güvenlik Araştırması, yakın zamanda Ulusal Güvenlik Ajansı (NSA) ve Ulusal Siber Güvenlik Merkezi (NCSC) tarafından Microsoft’a ifşa edilen Windows CryptoAPI’deki kritik bir güvenlik açığını analiz etti.
CVE-2022-34689 olarak atanan güvenlik açığının CVSS puanı 7,5’tir. Ağustos 2022’de yama yapıldı, ancak Salı Ekim 2022 Yaması’nda kamuya duyurulmuştu.
Microsoft’a göre, güvenlik açığı bir saldırganın meşru bir varlık gibi görünmesine izin veriyor.
Hatanın temel nedeni, MD5 tabanlı sertifika önbellek dizin anahtarının çarpışmasız olduğu varsayımıdır. 2009’dan beri MD5’in çarpışma direncinin kırıldığı bilinmektedir .
Saldırı akışı iki yönlüdür. İlk aşama meşru bir sertifikanın alınmasını, değiştirilmesini ve değiştirilmiş versiyonun kurbana sunulmasını gerektirir. İkinci aşama, MD5’i değiştirilmiş yasal sertifikayla çakışan yeni bir sertifika oluşturmayı ve yeni sertifikayı orijinal sertifikanın konusunun kimliğini taklit etmek için kullanmayı içerir.
Bu sahtekarlık saldırısına karşı savunmasız bir şekilde CryptoAPI kullanan vahşi uygulamaları aradık. Şimdiye kadar, Chrome’un eski sürümlerinin (v48 ve öncesi) ve Chromium tabanlı uygulamaların kötüye kullanılabileceğini gördük. Vahşi doğada daha savunmasız hedefler olduğuna inanıyoruz ve araştırmamız hala devam ediyor.
Veri merkezlerindeki görünür cihazların %1’inden daha azına yama uygulandığını ve geri kalanı bu güvenlik açığından yararlanmaya karşı korumasız hale getirdiğini tespit ettik.
Bu blog gönderisinde, potansiyel saldırı akışı ve sonuçları hakkında ayrıntılı bir açıklamanın yanı sıra tam saldırıyı gösteren bir kavram kanıtı (PoC) sunuyoruz. Ayrıca, CryptoAPI kitaplığının savunmasız sürümlerini tespit etmek için bir OSQuery sağlıyoruz.
Üç ay önce, Ekim 2022 Salı Yaması analizimizde , Windows CryptoAPI — CVE-2022-34689’daki kritik bir kimlik sahtekarlığı güvenlik açığının temel açıklamasını paylaştık. Microsoft’a göre, bu güvenlik açığı bir saldırganın “kimliğini taklit etmesine ve hedeflenen sertifika olarak kimlik doğrulama veya kod imzalama gibi eylemler gerçekleştirmesine” olanak tanır.
CryptoAPI, Windows’ta kriptografi ile ilgili her şeyi işlemek için fiili API’dir. Özellikle, okuma ve ayrıştırmadan doğrulanmış sertifika yetkililerine (CA’lar) göre doğrulamaya kadar sertifikaları yönetir. Tarayıcılar ayrıca TLS sertifika doğrulaması için CryptoAPI’yi kullanır; bu, herkesin kontrol etmesi öğretilen kilit simgesiyle sonuçlanan bir işlemdir.
Ancak, sertifika doğrulama tarayıcılar için benzersiz değildir ve PowerShell web kimlik doğrulaması, curl, wget, FTP yöneticileri, EDR’ler ve diğer birçok uygulama gibi diğer TLS istemcileri tarafından da kullanılır. Ayrıca, yürütülebilir dosyalar ve kitaplıklar üzerinde kod imzalama sertifikaları doğrulanır ve sürücü imzalama sertifikaları, sürücüler yüklenirken doğrulanır. Tahmin edilebileceği gibi, sertifikaların doğrulama sürecindeki bir güvenlik açığı, kimliklerini maskelemelerine ve kritik güvenlik korumalarını atlamalarına olanak tanıdığı için saldırganlar için çok kazançlı.
Bu, Ulusal Güvenlik Teşkilatının CryptoAPI’deki bir güvenlik açığını ilk kez ifşa etmesi değil. 2020’de CurveBall’u (CVE-2020-0601) bulup ifşa ettiler. CurveBall veya CVE- 2022-34689’dan yararlanmak kimlik sahtekarlığına neden olur; ancak CurveBall birçok uygulamayı etkilese de, CVE-2022-34689’un daha fazla önkoşulu vardır ve dolayısıyla daha sınırlı bir savunmasız hedef kapsamına sahiptir.
Güvenlik açığı ayrıntıları
Güvenlik açığını analiz etmek için önce yamalı kodu bulmaya çalıştık. CryptoAPI’deki çeşitli kod değişikliklerini gözlemlemek için popüler bir ikili farklılık aracı olan BinDiff’i kullandık. crypt32.dll’de yalnızca bir işlev değişti: CreateChainContextFromPathGraph . Bu işlevin bir parçası olarak, iki sertifikanın karşılaştırması vardır: biri girdi olarak alınan, diğeri ise alıcı uygulamanın sertifika önbelleğinde bulunur (bu önbellek daha sonra ele alınacaktır).
Değişikliklerin incelenmesi, memcmp kontrollerinin işleve iki konumda eklendiğini ortaya çıkardı (Şekil 1).
Şekil 1: Yamada CreateChainContextFromPathGraph’a eklenen kod (vurgulanmış)
Yamadan önce işlev, alınan bir sertifikanın zaten önbellekte olup olmadığını (ve bu nedenle doğrulanıp doğrulanmadığını) yalnızca MD5 parmak izine göre belirledi. Yamadan sonra memcmp eklenmesi, iki sertifikanın gerçek içeriğinin tamamen eşleşmesini gerektirir.
Bu noktada, bir saldırgan, MD5’i kurbanın sertifika önbelleğinde bulunan bir sertifikayla çakışan kötü amaçlı bir sertifika sunabilirse, güvenlik açığı kontrolünü atlayabilecek ve kötü amaçlı sertifikasına güvenebileceğini teorileştirdik (Şekil 2).
Şekil 2: Üst düzey saldırı akışı
CryptoAPI’nin sertifika önbelleği
CryptoAPI, performansı ve verimliliği artırmak için alınan son sertifikalar için bir önbellek kullanabilir. Bu mekanizma varsayılan olarak devre dışıdır. Bunu etkinleştirmek için uygulama geliştiricisinin , sonunda savunmasız koda yol açan Windows API işlevi olan CertGetCertificateChain’e belirli parametreleri iletmesi gerekir (Şekil 3).
Şekil 3: CertGetCertificateChain işlev bildirimi
CertGetCertificateChain birkaç ilginç parametre alır:
hChainEngine — sertifikaların doğrulanma şeklini kontrol etmek için kullanılan yapılandırılabilir bir nesne
pCertContext — giriş sertifikasının içeriği, WinAPI işlevi CertCreateCertificateContext tarafından giriş sertifikası kullanılarak oluşturulmuş bir veri yapısı
dwFlags — daha fazla yapılandırmayı belirten bayraklar
ppChainContext — (diğer alanların yanı sıra) güven durumunu içeren çıktı nesnesi; yani, zincirin doğrulama kararı
Son sertifikalar için önbelleğe alma mekanizmasını etkinleştirmek için geliştiricinin dwFlags içinde CERT_CHAIN_CACHE_END_CERT işaretini ayarlaması veya özel bir zincir motoru oluşturması ve dwFlags alanında CERT_CHAIN_CACHE_END_CERT işaretini ayarlaması gerekir .
Önbelleğin nasıl uygulandığını ve kullanıldığını anlamak için , sertifikayı önbellekten çeken FindIssuerObject işlevine bir göz atalım. Genel olarak, işlev aşağıdaki gibi davranır:
MD5 parmak izinin en önemsiz dört baytını temel alarak önbellekteki giriş sertifikasının grup dizinini hesaplar.
Önbellekte varsa işlev, önbelleğe alınan sertifikanın tüm MD5 parmak izini ve giriş sertifikasını karşılaştırır.
Parmak izleri eşleşirse (önbellek isabeti), giriş sertifikası güvenilir ve iade edilir. Bundan sonra uygulama, önbelleğe alınan sertifikayı değil, giriş sertifikası özniteliklerini (ortak anahtar, veren vb.) kullanır .
Parmak izleri eşleşmezse (önbellek eksik), kovadaki bir sonraki sertifikaya gider, MD5 parmak izini karşılaştırır ve tekrar eder.
Microsoft, doğası gereği önbelleğe alınan sertifikaların geçerliliğine güvenir ve önbellekte bir bitiş sertifikası bulunduktan sonra herhangi bir ek geçerlilik denetimi gerçekleştirmez. Bu, kendi başına, makul bir çalışma varsayımıdır. Bununla birlikte, kod, MD5 parmak izleri eşleşirse iki sertifikanın aynı olduğu varsayımında bulunur. Bu, istismar edilebilecek yanlış bir varsayımdır ve yamanın doğuşuydu.
Hipotezimizi desteklemek için CertGetCertificateChain kullanan küçük bir uygulama yazdık ve crypt32.dll’deki sertifika doğrulama akışında hata ayıkladık. WinDbg’yi kullanarak, kendi (kendinden imzalı) sertifikamızın MD5 parmak izinin önbellekte bulunan meşru bir sertifikayla eşleştiği bir senaryoyu simüle ettik. Şekil 4’te gösterildiği gibi hazırlanmış sertifikamız güvenilirdi.
Şekil 4: Önbelleğe alınan sertifikaya ve kendi hazırlanmış sertifikamıza CryptoAPI tarafından güvenildiğini gösteren günlükler
Yalnızca bir kontrolü atlayarak, Windows’u kötü niyetli sertifikamızın meşru olduğuna inandırabiliriz.
Güvenlik açığından nasıl yararlanılabilir?
Belirli bir MD5 değeriyle tam olarak eşleşen bir MD5 parmak izine sahip bir sertifika oluşturmak, ön görüntü saldırısı olarak adlandırılır ve bu, bugün bile hesaplama açısından mümkün değildir. Bununla birlikte, aynı MD5 parmak izlerine sahip olacak şekilde seçilen iki ön ek ile verimli bir şekilde iki sertifika oluşturmak mümkündür; bu tür saldırılara seçilmiş önek çarpışması denir.
Bu yolu seçerek, kurban uygulamasına bir şekilde iki sertifika sağlamamız gerekecek. Bir sertifika doğru şekilde imzalanacak, doğrulanacak ve önbelleğe alınacaktır (“değiştirilmiş hedef sertifika” olarak anılacaktır). Seçilen önek çarpışma saldırısını kolaylaştıracak şekilde üretilecektir. İkinci sertifika (“kötü niyetli sertifika” olarak adlandıracağız) sahte kimliği içerecektir. İlk sertifikanın MD5 parmak iziyle çakışacaktır (Şekil 5).
Şekil 5: Kötü niyetli sertifikanın MD5 parmak izi, değiştirilen hedef sertifikanın parmak iziyle çakışacaktır.
MD5 çarpışmaları yoluyla sertifika sahteciliği
MD5 çarpışmaları bizi yaklaşık 14 yıl öncesine, Beyoncé’nin “Single Ladies”i yayınladığı zamana, Obama’nın ilk kez başkan seçildiği ve MD5 çarpışmalarının SSL sertifikalarını taklit etmek için ilk kez kullanıldığı zamana götürüyor . İlk saldırı ile bugün ele aldığımız senaryo arasında önemli bir fark var: önceki senaryo MD5 imzalarına saldırdı , ancak mevcut güvenlik açığında MD5 parmak izleriyle uğraşıyoruz . Farkı anlayalım.
RFC 5280 , bölüm 4.1’e göre sertifika, iki bölümden oluşan bir ASN.1 dizisidir (Şekil 6):
tbsCertificate (veya “imzalanacak” sertifika) — Bu, kimlikle ilgili tüm ayrıntıları (konu, genel anahtar, seri numarası, EKU vb.) içeren kısımdır. Bu, imzalanan kısımdır.
imzaAlgoritması ve imzaDeğeri — Bu alanlar, TBS’nin imzasını oluşturur.
Bu nedenle bir sertifika imzası , sertifikanın yalnızca TBS kısmını imzalayan, sertifikanın içine yerleştirilmiş bir yapıdır. Öte yandan, bir sertifika parmak izi , tüm sertifikanın (imza dahil) bir karmasıdır.
Dolayısıyla, sertifikanın TBS dışındaki herhangi bir bölümünü sertifikayı geçersiz kılmadan değiştirebilseydik, imzayı değiştirmeden parmak izini değiştirirdik . Ayrıştırıcı imzayı doğru bir şekilde ayrıştırırsa ve TBS değişmezse, tüm sertifika yapısı değişse bile sertifika hala geçerli ve imzalanmış olarak kabul edilir (Şekil 7).
Şekil 7: TBS dışında eklenen veriler, sertifikanın geçerliliğini etkilemez
MD5 seçilmiş önek çakışmaları — kısa bir genel bakış
Aynı uzunlukta A ve B olmak üzere iki rasgele diziniz olduğunu varsayalım. Daha sonra, iki dizi, C ve D, verimli bir şekilde hesaplanabilir, öyle ki
MD5(A || C) = MD5(B || D)
nerede || dize birleştirme gösterir.
Ayrıca, sadece nihai MD5 sonucu değil, aynı zamanda C veya D’yi ekledikten sonra MD5’in dahili durumu da aynı olacaktır. Bu nedenle, herhangi bir E sonekini alırsanız, o zaman
MD5(A || C || E) = MD5(B || D || E)
(her iki tarafa da aynı E ekinin eklenmesi şartıyla).
Çarpışma blokları için yer açmak
Saldırganlar olarak, geçerli görünen ancak aynı zamanda çarpışma blokları (yukarıdaki açıklamada C ve D dizileri) için yer içeren bir sertifika oluşturmamız gerekecek. Bu, daha sonra hizmet edeceğimiz kötü niyetli sertifikamızı (aynı MD5 parmak iziyle) oluşturmamızı sağlayacaktır.
RFC 5280 , bölüm 4.1.1.2’ye göre , imza Algoritmasının yapısı şu şekildedir:
RSA algoritması için parametreler alanı ( RFC 3279’a dayalı ) “ASN.1 tipi NULL OLMALIDIR”. Başka bir deyişle: RSA, imza parametrelerini kullanmaz, bunun yerine değer olarak NULL değerini alır. CryptoAPI’nin bu alanı RSA imzaları için yok sayması mümkün mü?
Bu alana yer tutucu baytlar eklemek için (çarpışma bloklarına hazırlık olarak), ASN.1 türünü NULL’den BIT STRING’e değiştirmeye çalıştık. Bunu OpenSSL’nin yanı sıra CryptoAPI’ye karşı test ederek işe yarıyor – sertifika hala geçerli kabul ediliyor. TBS’yi değiştirmediğimiz için imza değişmedi ve kırılmadı. (Elbette MD5 parmak izi değişir.)
Sertifika MD5 parmak izi çakışmaları
Artık parçaları bir araya getirebilir ve mevcut, zaten imzalanmış bir sertifikayı kötü amaçlı bir sertifikanın MD5 parmak iziyle çarpışması için manipüle etmek için bir tarif sağlayabiliriz.
Bir web sitesinin TLS sertifikası (“hedef sertifikamız”) gibi meşru bir RSA imzalı son sertifika alın.
Kötü amaçlı sertifika oluşturmak için sertifikanın TBS bölümündeki ilginç alanları (konu, uzantılar, EKU, genel anahtar vb.) değiştirin. Not: İmzaya dokunmuyoruz, bu nedenle kötü niyetli sertifika yanlış imzalanmış. Genel anahtarın değiştirilmesi burada önemlidir — bu, saldırganın kötü amaçlı sertifika olarak oturum açmasına olanak tanır.
Her iki sertifikanın imzaAlgoritması alanının parametreler alanını değiştirerek, her iki sertifikanın aynı konumundan başlayarak MD5 çarpışma bloklarını (yukarıdaki açıklamada C ve D) koymak için yeterli alan olmasını sağlayın.
Her iki sertifikayı da MD5 çarpışma bloklarının yerleştirileceği konumda kesin.
Bir MD5 seçilen önek çarpışma hesaplaması yapın ve sonucu sertifikalara kopyalayın.
Meşru sertifikanın imza değerini (yukarıdaki açıklamada E son eki) her iki eksik sertifikayla birleştirin.
Gerçek dünyadan bir örnek
MD5 çarpışmalarına ilişkin anlayışımızla, artık bu CVE’den gerçek bir hedefle yararlanmayı deneyebiliriz. Kontrol ettiğimiz çok sayıda uygulama arasında savunmasız bir hedef bulabildik: Chrome v48. (Bu uygulama, CERT_CHAIN_CACHE_END_CERT işaretini CertGetCertificateChain’e ilettiği için savunmasızdır .) O zamana ait diğer Chromium tabanlı uygulamalar da bu CVE’ye karşı savunmasızdır.
Bu güvenlik açığından yararlanabilmemiz için önce HashClash kullanarak yaptığımız aynı MD5 parmak izine sahip iki sertifika oluşturmamız gerekiyordu (Şekil 8).
Şekil 8: Seçilen önek çakışmasını kullanarak aynı MD5 parmak izine sahip iki sertifika oluşturma
Ardından, değiştirilmiş hedef sertifikamızı Chrome’un önbelleğine eklemenin bir yolunu bulmamız gerekiyordu. Özel anahtarını bilmeden bir sertifika sunmak imkansız olduğu için bunu yapmak zordu.
TLS 1.2’de iki ilgili doğrulama aşaması vardır:
SunucuAnahtarı Değişim mesajı — bu mesaj, sertifika tarafından imzalandığından, yalnızca sertifikanın özel anahtarını bilen biri tarafından oluşturulabilir.
Sunucu Anlaşması Tamamlandı mesajı — bu mesaj, önceki tüm anlaşma mesajlarının kurcalamaya karşı koruma doğrulamasını içerir
(TLS 1.3 farklıdır ve biz buna odaklanmadık.)
Saldırının ilk aşamasında, değiştirilmiş sertifikayı Chrome’un son sertifika önbelleğine enjekte etmek istediğimizi unutmayın.
Bir Python betiğini proxy olarak kullanarak, bir ortadaki makine (MITM) saldırısı gerçekleştiriyoruz:
Kötü amaçlı MITM sunucumuz gerçek sunucu ile konuşur ve TLS el sıkışmasının ilk mesajlarını kurbana yansıtır.
Sunucu Sertifikası mesajında, kötü amaçlı MITM sunucumuz gerçek sunucunun mesajını değiştirir ve gerçek hedef sertifikayı değiştirilmiş sertifika ile değiştirir.
Sunucu Anahtarı Değişimi mesajı değişiklik yapılmadan yansıtılabilir.
Kötü niyetli sunucumuz, Sunucu Anlaşması Tamamlandı mesajını basitçe iletemez, çünkü anlaşma gerçekten de kurcalanmıştır. Böylece bağlantıyı sonlandırıyoruz.
Sunucu Anahtarı Değişimi mesajını doğrulamak için Chrome’un değiştirilen sertifikayı CryptoAPI ile yüklemesi gerekir ve bu nedenle önbelleğe enjekte edilir. Chrome, kopan bağlantıyı bir TLS güvenlik sorunu olarak ele almaz; bu yalnızca rastgele bir ağ sorunu olabilir. Chrome yeniden bağlanmaya çalışır ve bu sefer kötü niyetli sunucu, gerçek web sitesinden gelen mesajları yansıtmak yerine, kötü amaçlı sertifikaya sahip bir web sitesine hizmet verir. Chrome, sertifikanın zaten önbellekte olduğunu düşündüğü için tam doğrulama sürecini atlayacaktır. Sonuç, meşru görünen bir Microsoft web sitesine sorunsuz bir site ziyareti olacaktır (Şekil 9 ve 10). Tam kullanım akışı videomuzda görülebilir .
Şekil 9: Chrome v48’de tam saldırı akışı
Şekil 10: Güvenlik açığı bulunan Chrome, kötü amaçlı sertifikamıza güveniyor
Tespit etme
Güvenlik açığı bulunan kitaplık olan crypt32.dll dosyasının güvenlik açığı bulunan sürümlerini algılamak için bir OSQuery sağlıyoruz (Şekil 11). Akamai Guardicore Segmentation müşterileri, savunmasız varlıkları aramak için bu sorguyla birlikte Insight özelliğini kullanabilir .
Bir varlığın savunmasız olması için crypt32.dll’nin yamasız bir sürümüne sahip olması ve savunmasız bir uygulama çalıştırması gerektiğini unutmayın. (Bugüne kadar yalnızca Chrome v48’in savunmasız olduğunu gördük.)
Sertifikalar, çevrimiçi kimlik doğrulamasında önemli bir rol oynar ve bu güvenlik açığını saldırganlar için kazançlı hale getirir. Ancak kritik olarak işaretlenmesine rağmen, güvenlik açığına yalnızca 7,5’lik bir CVSS puanı verildi. Bunun, güvenlik açığı önkoşullarının karşılandığı güvenlik açığı bulunan uygulamaların ve Windows bileşenlerinin sınırlı kapsamından kaynaklandığına inanıyoruz.
Bununla birlikte, bu API’yi kullanan ve bu güvenlik açığına maruz kalabilecek çok sayıda kod olduğu söyleniyor ve Windows 7 gibi Windows’un durdurulan sürümleri için bile bir düzeltme eki garanti ediliyor.
Windows sunucularınızı ve uç noktalarınızı Microsoft tarafından yayınlanan en son güvenlik yaması ile yamalamanızı tavsiye ederiz. Geliştiriciler için, bu güvenlik açığını hafifletmek için başka bir seçenek, bir sertifikayı kullanmadan önce CertVerifyCertificateChainPolicy gibi diğer WinAPI’leri kullanarak bir sertifikanın geçerliliğini iki kez kontrol etmektir . Son sertifika önbelleğini kullanmayan uygulamaların savunmasız olmadığını unutmayın.
PoC kodumuz GitHub depomuzda bulunabilir . Akamai Security Research yayınlarının tümünü Twitter hesabımız üzerinden de takip edebilirsiniz.
Windows CryptoAPI’de Kritik Bir Kimlik Sahtekarlığı Güvenlik Açığı Kullanma – Windows Sunucu Kullananların Dikkatine
Tomer Peled ve Yoni Rozenshein tarafından
Tricia Howard’ın editoryal ve ek katkıları
Makale İçeriği
Yönetici Özeti
Video izlemek için tıklayınız
Arka plan
Üç ay önce, Ekim 2022 Salı Yaması analizimizde , Windows CryptoAPI — CVE-2022-34689’daki kritik bir kimlik sahtekarlığı güvenlik açığının temel açıklamasını paylaştık. Microsoft’a göre, bu güvenlik açığı bir saldırganın “kimliğini taklit etmesine ve hedeflenen sertifika olarak kimlik doğrulama veya kod imzalama gibi eylemler gerçekleştirmesine” olanak tanır.
CryptoAPI, Windows’ta kriptografi ile ilgili her şeyi işlemek için fiili API’dir. Özellikle, okuma ve ayrıştırmadan doğrulanmış sertifika yetkililerine (CA’lar) göre doğrulamaya kadar sertifikaları yönetir. Tarayıcılar ayrıca TLS sertifika doğrulaması için CryptoAPI’yi kullanır; bu, herkesin kontrol etmesi öğretilen kilit simgesiyle sonuçlanan bir işlemdir.
Ancak, sertifika doğrulama tarayıcılar için benzersiz değildir ve PowerShell web kimlik doğrulaması, curl, wget, FTP yöneticileri, EDR’ler ve diğer birçok uygulama gibi diğer TLS istemcileri tarafından da kullanılır. Ayrıca, yürütülebilir dosyalar ve kitaplıklar üzerinde kod imzalama sertifikaları doğrulanır ve sürücü imzalama sertifikaları, sürücüler yüklenirken doğrulanır. Tahmin edilebileceği gibi, sertifikaların doğrulama sürecindeki bir güvenlik açığı, kimliklerini maskelemelerine ve kritik güvenlik korumalarını atlamalarına olanak tanıdığı için saldırganlar için çok kazançlı.
Bu, Ulusal Güvenlik Teşkilatının CryptoAPI’deki bir güvenlik açığını ilk kez ifşa etmesi değil. 2020’de CurveBall’u (CVE-2020-0601) bulup ifşa ettiler. CurveBall veya CVE- 2022-34689’dan yararlanmak kimlik sahtekarlığına neden olur; ancak CurveBall birçok uygulamayı etkilese de, CVE-2022-34689’un daha fazla önkoşulu vardır ve dolayısıyla daha sınırlı bir savunmasız hedef kapsamına sahiptir.
Güvenlik açığı ayrıntıları
Güvenlik açığını analiz etmek için önce yamalı kodu bulmaya çalıştık. CryptoAPI’deki çeşitli kod değişikliklerini gözlemlemek için popüler bir ikili farklılık aracı olan BinDiff’i kullandık. crypt32.dll’de yalnızca bir işlev değişti: CreateChainContextFromPathGraph . Bu işlevin bir parçası olarak, iki sertifikanın karşılaştırması vardır: biri girdi olarak alınan, diğeri ise alıcı uygulamanın sertifika önbelleğinde bulunur (bu önbellek daha sonra ele alınacaktır).
Değişikliklerin incelenmesi, memcmp kontrollerinin işleve iki konumda eklendiğini ortaya çıkardı (Şekil 1).
Yamadan önce işlev, alınan bir sertifikanın zaten önbellekte olup olmadığını (ve bu nedenle doğrulanıp doğrulanmadığını) yalnızca MD5 parmak izine göre belirledi. Yamadan sonra memcmp eklenmesi, iki sertifikanın gerçek içeriğinin tamamen eşleşmesini gerektirir.
Bu noktada, bir saldırgan, MD5’i kurbanın sertifika önbelleğinde bulunan bir sertifikayla çakışan kötü amaçlı bir sertifika sunabilirse, güvenlik açığı kontrolünü atlayabilecek ve kötü amaçlı sertifikasına güvenebileceğini teorileştirdik (Şekil 2).
CryptoAPI’nin sertifika önbelleği
CryptoAPI, performansı ve verimliliği artırmak için alınan son sertifikalar için bir önbellek kullanabilir. Bu mekanizma varsayılan olarak devre dışıdır. Bunu etkinleştirmek için uygulama geliştiricisinin , sonunda savunmasız koda yol açan Windows API işlevi olan CertGetCertificateChain’e belirli parametreleri iletmesi gerekir (Şekil 3).
CertGetCertificateChain birkaç ilginç parametre alır:
Son sertifikalar için önbelleğe alma mekanizmasını etkinleştirmek için geliştiricinin dwFlags içinde CERT_CHAIN_CACHE_END_CERT işaretini ayarlaması veya özel bir zincir motoru oluşturması ve dwFlags alanında CERT_CHAIN_CACHE_END_CERT işaretini ayarlaması gerekir .
Önbelleğin nasıl uygulandığını ve kullanıldığını anlamak için , sertifikayı önbellekten çeken FindIssuerObject işlevine bir göz atalım. Genel olarak, işlev aşağıdaki gibi davranır:
Microsoft, doğası gereği önbelleğe alınan sertifikaların geçerliliğine güvenir ve önbellekte bir bitiş sertifikası bulunduktan sonra herhangi bir ek geçerlilik denetimi gerçekleştirmez. Bu, kendi başına, makul bir çalışma varsayımıdır. Bununla birlikte, kod, MD5 parmak izleri eşleşirse iki sertifikanın aynı olduğu varsayımında bulunur. Bu, istismar edilebilecek yanlış bir varsayımdır ve yamanın doğuşuydu.
Hipotezimizi desteklemek için CertGetCertificateChain kullanan küçük bir uygulama yazdık ve crypt32.dll’deki sertifika doğrulama akışında hata ayıkladık. WinDbg’yi kullanarak, kendi (kendinden imzalı) sertifikamızın MD5 parmak izinin önbellekte bulunan meşru bir sertifikayla eşleştiği bir senaryoyu simüle ettik. Şekil 4’te gösterildiği gibi hazırlanmış sertifikamız güvenilirdi.
Yalnızca bir kontrolü atlayarak, Windows’u kötü niyetli sertifikamızın meşru olduğuna inandırabiliriz.
Güvenlik açığından nasıl yararlanılabilir?
Belirli bir MD5 değeriyle tam olarak eşleşen bir MD5 parmak izine sahip bir sertifika oluşturmak, ön görüntü saldırısı olarak adlandırılır ve bu, bugün bile hesaplama açısından mümkün değildir. Bununla birlikte, aynı MD5 parmak izlerine sahip olacak şekilde seçilen iki ön ek ile verimli bir şekilde iki sertifika oluşturmak mümkündür; bu tür saldırılara seçilmiş önek çarpışması denir.
Bu yolu seçerek, kurban uygulamasına bir şekilde iki sertifika sağlamamız gerekecek. Bir sertifika doğru şekilde imzalanacak, doğrulanacak ve önbelleğe alınacaktır (“değiştirilmiş hedef sertifika” olarak anılacaktır). Seçilen önek çarpışma saldırısını kolaylaştıracak şekilde üretilecektir. İkinci sertifika (“kötü niyetli sertifika” olarak adlandıracağız) sahte kimliği içerecektir. İlk sertifikanın MD5 parmak iziyle çakışacaktır (Şekil 5).
MD5 çarpışmaları yoluyla sertifika sahteciliği
MD5 çarpışmaları bizi yaklaşık 14 yıl öncesine, Beyoncé’nin “Single Ladies”i yayınladığı zamana, Obama’nın ilk kez başkan seçildiği ve MD5 çarpışmalarının SSL sertifikalarını taklit etmek için ilk kez kullanıldığı zamana götürüyor . İlk saldırı ile bugün ele aldığımız senaryo arasında önemli bir fark var: önceki senaryo MD5 imzalarına saldırdı , ancak mevcut güvenlik açığında MD5 parmak izleriyle uğraşıyoruz . Farkı anlayalım.
RFC 5280 , bölüm 4.1’e göre sertifika, iki bölümden oluşan bir ASN.1 dizisidir (Şekil 6):
Şekil 6: Sertifikaları tanımlayan ASN.1 dizisi
Bu nedenle bir sertifika imzası , sertifikanın yalnızca TBS kısmını imzalayan, sertifikanın içine yerleştirilmiş bir yapıdır. Öte yandan, bir sertifika parmak izi , tüm sertifikanın (imza dahil) bir karmasıdır.
Dolayısıyla, sertifikanın TBS dışındaki herhangi bir bölümünü sertifikayı geçersiz kılmadan değiştirebilseydik, imzayı değiştirmeden parmak izini değiştirirdik . Ayrıştırıcı imzayı doğru bir şekilde ayrıştırırsa ve TBS değişmezse, tüm sertifika yapısı değişse bile sertifika hala geçerli ve imzalanmış olarak kabul edilir (Şekil 7).
MD5 seçilmiş önek çakışmaları — kısa bir genel bakış
Aynı uzunlukta A ve B olmak üzere iki rasgele diziniz olduğunu varsayalım. Daha sonra, iki dizi, C ve D, verimli bir şekilde hesaplanabilir, öyle ki
nerede || dize birleştirme gösterir.
Ayrıca, sadece nihai MD5 sonucu değil, aynı zamanda C veya D’yi ekledikten sonra MD5’in dahili durumu da aynı olacaktır. Bu nedenle, herhangi bir E sonekini alırsanız, o zaman
(her iki tarafa da aynı E ekinin eklenmesi şartıyla).
Çarpışma blokları için yer açmak
Saldırganlar olarak, geçerli görünen ancak aynı zamanda çarpışma blokları (yukarıdaki açıklamada C ve D dizileri) için yer içeren bir sertifika oluşturmamız gerekecek. Bu, daha sonra hizmet edeceğimiz kötü niyetli sertifikamızı (aynı MD5 parmak iziyle) oluşturmamızı sağlayacaktır.
RFC 5280 , bölüm 4.1.1.2’ye göre , imza Algoritmasının yapısı şu şekildedir:
RSA algoritması için parametreler alanı ( RFC 3279’a dayalı ) “ASN.1 tipi NULL OLMALIDIR”. Başka bir deyişle: RSA, imza parametrelerini kullanmaz, bunun yerine değer olarak NULL değerini alır. CryptoAPI’nin bu alanı RSA imzaları için yok sayması mümkün mü?
Bu alana yer tutucu baytlar eklemek için (çarpışma bloklarına hazırlık olarak), ASN.1 türünü NULL’den BIT STRING’e değiştirmeye çalıştık. Bunu OpenSSL’nin yanı sıra CryptoAPI’ye karşı test ederek işe yarıyor – sertifika hala geçerli kabul ediliyor. TBS’yi değiştirmediğimiz için imza değişmedi ve kırılmadı. (Elbette MD5 parmak izi değişir.)
Sertifika MD5 parmak izi çakışmaları
Artık parçaları bir araya getirebilir ve mevcut, zaten imzalanmış bir sertifikayı kötü amaçlı bir sertifikanın MD5 parmak iziyle çarpışması için manipüle etmek için bir tarif sağlayabiliriz.
Gerçek dünyadan bir örnek
MD5 çarpışmalarına ilişkin anlayışımızla, artık bu CVE’den gerçek bir hedefle yararlanmayı deneyebiliriz. Kontrol ettiğimiz çok sayıda uygulama arasında savunmasız bir hedef bulabildik: Chrome v48. (Bu uygulama, CERT_CHAIN_CACHE_END_CERT işaretini CertGetCertificateChain’e ilettiği için savunmasızdır .) O zamana ait diğer Chromium tabanlı uygulamalar da bu CVE’ye karşı savunmasızdır.
Bu güvenlik açığından yararlanabilmemiz için önce HashClash kullanarak yaptığımız aynı MD5 parmak izine sahip iki sertifika oluşturmamız gerekiyordu (Şekil 8).
Ardından, değiştirilmiş hedef sertifikamızı Chrome’un önbelleğine eklemenin bir yolunu bulmamız gerekiyordu. Özel anahtarını bilmeden bir sertifika sunmak imkansız olduğu için bunu yapmak zordu.
TLS 1.2’de iki ilgili doğrulama aşaması vardır:
(TLS 1.3 farklıdır ve biz buna odaklanmadık.)
Saldırının ilk aşamasında, değiştirilmiş sertifikayı Chrome’un son sertifika önbelleğine enjekte etmek istediğimizi unutmayın.
Bir Python betiğini proxy olarak kullanarak, bir ortadaki makine (MITM) saldırısı gerçekleştiriyoruz:
Sunucu Anahtarı Değişimi mesajını doğrulamak için Chrome’un değiştirilen sertifikayı CryptoAPI ile yüklemesi gerekir ve bu nedenle önbelleğe enjekte edilir. Chrome, kopan bağlantıyı bir TLS güvenlik sorunu olarak ele almaz; bu yalnızca rastgele bir ağ sorunu olabilir. Chrome yeniden bağlanmaya çalışır ve bu sefer kötü niyetli sunucu, gerçek web sitesinden gelen mesajları yansıtmak yerine, kötü amaçlı sertifikaya sahip bir web sitesine hizmet verir. Chrome, sertifikanın zaten önbellekte olduğunu düşündüğü için tam doğrulama sürecini atlayacaktır. Sonuç, meşru görünen bir Microsoft web sitesine sorunsuz bir site ziyareti olacaktır (Şekil 9 ve 10). Tam kullanım akışı videomuzda görülebilir .
Tespit etme
Güvenlik açığı bulunan kitaplık olan crypt32.dll dosyasının güvenlik açığı bulunan sürümlerini algılamak için bir OSQuery sağlıyoruz (Şekil 11). Akamai Guardicore Segmentation müşterileri, savunmasız varlıkları aramak için bu sorguyla birlikte Insight özelliğini kullanabilir .
Bir varlığın savunmasız olması için crypt32.dll’nin yamasız bir sürümüne sahip olması ve savunmasız bir uygulama çalıştırması gerektiğini unutmayın. (Bugüne kadar yalnızca Chrome v48’in savunmasız olduğunu gördük.)
Çözüm
Sertifikalar, çevrimiçi kimlik doğrulamasında önemli bir rol oynar ve bu güvenlik açığını saldırganlar için kazançlı hale getirir. Ancak kritik olarak işaretlenmesine rağmen, güvenlik açığına yalnızca 7,5’lik bir CVSS puanı verildi. Bunun, güvenlik açığı önkoşullarının karşılandığı güvenlik açığı bulunan uygulamaların ve Windows bileşenlerinin sınırlı kapsamından kaynaklandığına inanıyoruz.
Bununla birlikte, bu API’yi kullanan ve bu güvenlik açığına maruz kalabilecek çok sayıda kod olduğu söyleniyor ve Windows 7 gibi Windows’un durdurulan sürümleri için bile bir düzeltme eki garanti ediliyor.
Windows sunucularınızı ve uç noktalarınızı Microsoft tarafından yayınlanan en son güvenlik yaması ile yamalamanızı tavsiye ederiz. Geliştiriciler için, bu güvenlik açığını hafifletmek için başka bir seçenek, bir sertifikayı kullanmadan önce CertVerifyCertificateChainPolicy gibi diğer WinAPI’leri kullanarak bir sertifikanın geçerliliğini iki kez kontrol etmektir . Son sertifika önbelleğini kullanmayan uygulamaların savunmasız olmadığını unutmayın.
PoC kodumuz GitHub depomuzda bulunabilir . Akamai Security Research yayınlarının tümünü Twitter hesabımız üzerinden de takip edebilirsiniz.