Yama uygulanmamış bir Exchange sunucusunu haydut PowerShell koduyla nasıl hacklersiniz?

İki aydan kısa bir süre önce, bazı endişe verici hata haberleri geldi: Microsoft Exchange'de bir çift sıfır gün güvenlik açığı duyurulmuştu.

Olarak biz tavsiye o zaman, bu güvenlik açıkları, resmi olarak belirlenmiş CVE-2022-41040 ve CVE-2022-41082:

İlk hata, Exchange sunucusunun kendisinde uzaktan kod yürütülmesine (RCE) izin veren ikinci hatayı tetikleyecek kadar bir delik açmak için uzaktan kullanılan, birbirine zincirlenebilecek [olabilecek] iki sıfır gündü.

İlk güvenlik açığı, zahmetli ve geniş çapta kötüye kullanılan güvenlik açığını anımsatıyordu. ProxyShell güvenlik açığı Ağustos 2021'de, Exchange'in Otomatik Bulma özelliğindeki tehlikeli davranışlara dayandığından, Microsoft tarafından açıklanan bir protokol olarak "Outlook ve EAS [Exchange ActiveSync] istemcileri tarafından Exchange'deki posta kutularını bulmak ve bunlara bağlanmak için kullanılır".

Neyse ki, oturum açmış olsun ya da olmasın, herhangi bir uzak kullanıcı tarafından ProxyShell saldırısında yararlanılabilecek Otomatik Keşfet özelliği, bir yıldan daha uzun bir süre önce yamalandı.

Ne yazık ki, ProxyShell yamaları, kimliği doğrulanmış kullanıcılara açıktan yararlanmayı kapatmak için yeterince şey yapmadı, bu da yeni CVE-2022-40140 sıfır-gün'e yol açtı; dublajlı ProxyNotShell.

O kadar tehlikeli değil ama yine de tehlikeli

Açıkçası, ProxyNotShell, kimliği doğrulanmış erişim olarak bilinen şeyi gerektirdiği göz önüne alındığında, orijinal ProxyShell kadar tehlikeli değildi, bu nedenle herhangi bir yerden herhangi biri tarafından suistimal edilmeye açık değildi.

Ancak, birçok Exchange sunucusunda, herhangi bir kullanıcının oturum açma adını ve parolasını bilmenin, bu kullanıcının düzgün bir şekilde oturum açmak için iki faktörlü kimlik doğrulaması (2FA) kullanması gerekse bile, kimliği doğrulanmış olarak geçmek ve bu saldırıyı başlatmak için yeterli olacağı kısa sürede ortaya çıktı. onların maili.

Sophos uzmanı Chester Wisniewski olarak koymak zamanında:

Eğer öyle adlandırmak istiyorsanız, bu bir "kimlik doğrulama ortası güvenlik açığı"dır. Bu karışık bir nimettir. Bu, 2021'de ProxyLogon ve ProxyShell'de olduğunu gördüğümüz gibi, otomatik bir Python betiğinin tüm interneti tarayamayacağı ve dünyadaki her Exchange sunucusunu birkaç dakika veya saat içinde potansiyel olarak kullanamayacağı anlamına gelir. […]

Bir şifreye ihtiyacınız var, ancak herhangi bir Exchange sunucusunda geçerli olan bir e-posta adresi ve şifre kombinasyonu bulmak ne yazık ki muhtemelen çok zor değil. Ve bugüne kadar istismar edilmemiş olabilirsiniz, çünkü Outlook Web Access'te [OWA] başarılı bir şekilde oturum açmak için FIDO belirteci veya kimlik doğrulayıcısı veya kullanıyor olabileceğiniz ikinci faktör ne olursa olsun gerekir.

Ancak bu saldırı, o ikinci faktörü gerektirmez. [...] Sadece bir kullanıcı adı ve şifre kombinasyonu elde etmek oldukça düşük bir engeldir.

Muhtemelen hatırladığınız gibi, Ekim Salı Yaması'na daha iki hafta olduğu göz önüne alındığında, çoğumuz Microsoft'un ProxyNotShell açıkları için bir düzeltme bulmak için acele edeceğini varsaydık (veya en azından umduk).

Ancak görünüşe göre güvenilir bir düzeltmenin yapıldığını görünce hayal kırıklığına uğradık. beklenenden daha karmaşıkve Ekim geldi ve geçti, ProxyNotShell uygun yamalarla değil, yalnızca geçici çözümlerle ele alındı.

Kasım ayının Salı Yaması bile gerekli düzeltmeleri doğrudan sağlamadı, ancak yamalar yine de çıktı ayrı olarak getirilip yüklenebilen Exchange'e özgü bir güvenlik güncelleştirmesinin parçası olarak aynı gün:

Kavram kanıtı ortaya çıktı

Artık ortalık yatıştığında ve herkesin Exchange sunucularını (en azından unutmadıkları sunucularını) düzeltmeye vakti olduğuna göre, Zero Day Initiative'deki (ZDI) araştırmacılar, bu güvenlik açıklarının başlangıçta sorumlu bir şekilde teslim edilmek üzere ifşa edildiği Microsoft, açıkladı böceklerden nasıl yararlanılabileceği.

Kötü haber, açık istismar açıklamalarına ilişkin fikrinize bağlı olarak, ZDI ekibinin artık Exchange sunucularına nasıl saldırılacağını açıklayan bir kavram kanıtı (PoC) sağlamasıdır.

Tabii ki iyi haber şu:

• Artık böcekleri kendimiz inceleyebilir ve anlayabiliriz. Bu, yalnızca aldığımız genel önlemlerin (yalnızca yama uygulamakla sınırlı değil) beklediğimiz korumayı sağlayacağından emin olmamıza yardımcı olmakla kalmaz, aynı zamanda gelecekte kaçınmak isteyeceğimiz programlama uygulamaları hakkında da bizi bilgilendirir; Kendi sunucu tarafı kodumuzda bu tür hataları açma tuzağına düşmeyin.
• Artık yamaları uygulamamak için hiçbir mazeretimiz kalmadı. Güncelleme konusunda ayaklarımızı sürüdüysek, ZDI'nin saldırının neden işe yaradığına dair açıklaması, tedavinin kesinlikle hastalığa tercih edildiğini açıkça ortaya koyuyor.

Nasıl çalışır

ZDI'lar açıklama Bu güvenlik açığının tamamı, bir güvenlik açığını geçerli bir açıktan yararlanmaya dönüştürmek için ihtiyaç duyduğunuz tüm parçaları bir araya getirmenin ne kadar karmaşık olabileceğine dair büyüleyici bir hikaye oluşturuyor.

Ayrıca, mevcut bir açığı derinlemesine incelemenin, neden bir güvenlik açığının kötüye kullanılabileceği, potansiyel olarak ek yamalara yol açabileceği, yapılandırma değişikliklerini teşvik edebileceği ve sadece düzeltmekle bariz olmayabilecek yeni programlama uygulamalarını teşvik edebileceğinin diğer yollarını ortaya çıkarmaya yardımcı olabileceğini anlamanıza yardımcı olması için okumaya değer. orijinal delik.

Açıklama, zorunlu olarak, karmaşık ve oldukça tekniktir ve sonunda uzaktan kod yürütmeyi (RCE) gerçekleştirmek için uzun bir dizi adım boyunca sizi ileriye götürür.

ZDI raporunu okumaya karar verirseniz, üst düzey ayrıntıları daha kolay takip etmenize yardımcı olmak umuduyla, burada, adımların tersten sıralandığı umarız çok basit olmayan bir özet…

…böylece hikayenin neden şu yönlere gittiğini önceden bileceksiniz:

• ADIM 4. Exchange'i, seçtiğiniz bir başlatma parametresiyle, seçtiğiniz bir .NET nesnesini başlatması için uzaktan kandırın.

Modern kodlamada, bir somutlaştırılmış nesne kullanım sırasında ihtiyaç duyacağı veri ve kaynaklarla otomatik olarak başlatılan ve üzerinde çalışabilecek belirli bir işlev grubuna bağlı, tahsis edilmiş bir bellek parçası için kullanılan jargon sözcüktür. (Örneklendirmek için sadece süslü bir kelime yaratmak.)

Nesneler, genellikle belleği kendiniz ayırmanız, ilgili veri alanlarını elle doldurmanız ve hatırlamanız gereken C gibi bir dilde yaygın olan bellek yanlış yönetimi hatalarından kaçınmaya yardımcı olmak için işletim sisteminin kendisi tarafından yönetilebilir ve kontrol edilebilir. işiniz bittiğinde ağ soketleri veya disk dosyaları gibi kullanmakta olduğunuz bellek ve kaynakları serbest bırakın.

Nesneler genellikle kendileriyle ilişkilendirilmiş programatik bir işleve sahiptir. inşaatçı, doğru miktarda belleği ve doğru sistem kaynaklarını ayırmak için yeni bir nesne oluşturulduğunda otomatik olarak yürütülür.

Genellikle, nesnenin başladığında nasıl yapılandırılmasını istediğinizi belirtmek için yapıcıya argüman olarak bir veya daha fazla parametre iletmeniz gerekir.

Basitçe söylemek gerekirse, örneğin bir örnek oluşturursanız, TextString gibi bir metin dizesi olan bir parametre kullanarak nesne (bu adları biz uyduruyoruz, ama siz anladınız) example.com:8888...

…muhtemelen metninizi tutmak için tahsis edilmiş bir bellek arabelleği ile sonuçlanacaksınız, bu, ilettiğiniz değeri, yani ham metni tutacak şekilde başlatıldı. example.com:8888.

Bu bağlamda, nesne kurucusuna veri olarak iletilen metin dizesi, oluşturucuyu uzaktan tetiklediğinizde, tekrar tekrar daha büyük dizeler isteyerek olası bir hizmet reddi (DoS) dışında hemen herhangi bir açık siber güvenlik tehdidi oluşturmaz. hafızayı tüketmeye çalışın.

Ama örnek verecek olursan, diyelim ki, bir ConnectedTCPClient aynı metin dizesi parametresini kullanan nesne example.com:8888, geçici verileri tutmaya hazır bir bellek arabelleği ve sunucuyla veri alışverişi yapmaya hazır işletim sistemi tarafından ayrılmış bir ağ soketi elde edebilirsiniz. example.com TCP bağlantı noktası üzerinden 8888.

Açık sokete hiçbir zaman veri gönderemeseniz bile, sunucuyu kontrol ettiğiniz bir konuma evi çağırması için kandırmış olsanız bile, orada uzaktan kod yürütme riskini görebilirsiniz.

Diyelim ki, adında bir nesne bile bulabilirsiniz. RunCmdAndReadOutput, burada parametre olarak gönderdiğiniz metin dizesi, kelimenin tam anlamıyla, nesne oluşturulur oluşturulmaz otomatik olarak çalıştırmak istediğiniz bir komuttur, böylece çıktısını daha sonra toplayabilirsiniz.

Komutun çıktısını hiçbir zaman kurtaramayacak olsanız bile, böyle bir nesneyi yalnızca başlatmak yine de çalıştırılacak bir komut seçmenize izin verir, böylece size genel uzaktan kod yürütme olanağı tanır ve yalnızca sunucu işleminin kendisinin erişim haklarıyla sınırlı bir risk sunar. .

Elbette, saldırı ancak son aşamaya geldiğinizde bu kadar kolaydır ki bunu yapamamanız gerekir çünkü Exchange'in örneğini oluşturmak için herhangi bir eski nesneyi seçmenizi engelleyen katı bir izin verilenler listesi vardır.

Teorik olarak, PowerShell aracılığıyla yalnızca güvenli veya düşük riskli nesneler uzaktan oluşturulabilir, böylece hayali TextString yukarıda veya bir SimpleIntegerValue, kabul edilebilir olarak kabul edilebilirken, bir ConnectedTCPClient ya da RunCmdAndReadOutput kesinlikle olmazdı.

Ancak ZDI araştırmacıları, son adımı tetiklemeden önce şunu yapabileceklerini fark ettiler:

• ADIM 3. Exchange'i, güvenlik testini geçen düşük riskli bir nesnenin aslında sizin seçtiğiniz başka bir nesne olduğuna inandırmak için uzaktan kandırın.

Buna rağmen, tehdidi daha da azaltmak için Exchange'in düşük riskli nesnelerin bile uzaktan oluşturulmasını engellemesini bekleyebilirsiniz.

Ancak araştırmacılar yapabileceklerini buldular:

• ADIM 2. Exchange'i kullanması için uzaktan kandırın. PowerShell Uzaktan İletişim harici olarak kontrol edilen başlatma parametrelerine dayalı bir nesne oluşturma özelliği.

Ve bu, yalnızca yarı yamalanmış ProxyShell benzeri delik sayesinde mümkün oldu:

• 1. ADIM. Geçerli bir e-posta göndererek Exchange'i uzaktan kandırarak kod içeren bir web isteğini kabul etmesi ve işleme koyması için username:password alanı da istek alanına ekleyin.

İstekte adı geçen kullanıcı gerçekten oturum açmamış olsa ve kendi posta kutusuna erişmek için bir tür 2FA sürecinden geçmesi gerekse bile, bir saldırgan username:password kombinasyon, Exchange'i yukarıda 2 ila 4. adımlarda açıklanan saldırı zincirini başlatmak için kullanılabilecek bir web bağlantısını kabul etmesi için kandırmaya yetecek kimlik doğrulama bilgisine sahip olacaktır.

Kabaca söylemek gerekirse, herhangi bir geçerli username:password Exchange'in HTTP isteğini baştan reddetmesini önlemek için "kimlik doğrulamanın" gerekli olduğu göz önüne alındığında, kombinasyon işe yarardı.

Ne yapalım?

Bu saldırının yalnızca işe yaradığını unutmayın:

• Şirket içi Exchange sunucularınız varsa. Microsoft, kendi bulut hizmetlerini hızlı bir şekilde kilitlediğini iddia ediyor, bu nedenle Exchange Online etkilenmedi. Emin olun Exchange sunucularınızın nerede olduğunu bilin. Şu anda Exchange Online kullanıyor olsanız bile, çalışan şirket içi sunucularınız olabilir, bunlar belki de geçiş işleminizden yanlışlıkla kalmış olabilir.
• Sunucularınız yamalanmamışsa. Sahip olduğunuzdan emin olun 2022-11-08 tarihli Exchange Yazılım Güncellemesini uyguladı için güvenlik açıklarını kapatın istismarın gerektirdiği.
• Sunucularınız hala eski kimlik doğrulama olarak da bilinen Temel Kimlik Doğrulamayı kabul ediyorsa. Sahip olduğunuzdan emin olun eski kimlik doğrulamanın tüm yönlerini engelledi sunucularınız kabul etmeyecek username:password yukarıda belirtilen başlıklar ve ilk etapta riskli Otomatik Keşfet protokol isteklerini kabul etmeyecektir. Bu saldırganları durdurur bir sunucuya yama uygulanmamış olsa bile bubi tuzaklı nesne başlatma numaralarını kabul etmesi için kandırmak.

Yapabilirsin izlemek resmi önleme, iyileştirme ve yanıt tavsiyelerimizin bir parçasıdır ve Sophos müşterileri, ürünlerimiz tarafından kullanılan tehdit algılama adlarını Sophos X-Ops Twitter akışı aracılığıyla takip edebilirler (@SophosXOps).

CVE-2022-41040 ve CVE-2022-41082 ile ilgili yeni bilgiler yayınlandı: https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops (@SophosXOps) 21 Kasım 2022

---

DEĞİŞİM KİMLİK DOĞRULAMA VE OAUTH2 HAKKINDA DAHA FAZLA BİLGİ EDİNİN

Paul Ducklin ve Chester Wisniewski ile
Giriş ve çıkış müziği Edith Çamur.

---