S3 Ep102.5: "ProxyNotShell" Değişim hataları – bir uzman konuşuyor [Ses + Metin]

Herhangi bir noktaya atlamak için aşağıdaki ses dalgalarına tıklayın ve sürükleyin. Ayrıca doğrudan dinle Soundcloud'da.

[MÜZİKAL MODEM]

---

ÖRDEK.  Herkese Merhaba.

Naked Security podcast'inin başka bir özel mini bölümüne hoş geldiniz.

Ben Paul Ducklin, tekrar arkadaşım ve meslektaşım Chester Wisniewski ile katıldım.

Merhaba Chet.

---

ÇET.  [SAHTE AUSSIE ACCENT] İyi günler, Ördek.

---

ÖRDEK.  Chet, eminim herkes dinliyordur. podcast yayınlandıktan kısa bir süre sonra dinliyorlarsa, ne hakkında konuşacağımızı biliyorlar!

Ve bu çift namlulu olmalı Microsoft Exchange sıfır gün Eylül 2022'nin son gününde hemen hemen yıkamada çıkan:

Satış arkadaşlarımız, "Ay sonu, çeyrek sonu, çılgınca bir zaman...ama yarın herkes 0'a sıfırlanacak" diyor.

Sistem yöneticileri ve BT yöneticileri için bu hafta sonu böyle olmayacak!

---

ÇET.  Ördek, sanırım, sevgili Douglas Adams'ın ölümsüz sözleriyle, "PANİK YAPMA" düzende olabilir.

Pek çok kuruluş artık Exchange sunucularında kendi e-postalarını şirket içinde barındırmıyor, bu nedenle çok sayıda insan derin bir nefes alabilir ve bu hafta sonu çok fazla strese girmeden biraz zaman geçirebilir.

Ancak yerinde Exchange çalıştırıyorsanız…

… ben olsaydım, Pazartesi veya Salı günü bunun daha fazla bir şeye dönüşeceğinden emin olmak için, sadece birkaç hafifletici önlem almak için biraz fazla mesai yapıyor olabilirdim. dramatik.

---

ÖRDEK.  Bu nedenle bu CVE-2022-41040 ve CVE-2022-41042… bu oldukça ağız dolusu.

Twitter'da şöyle anıldığını gördüm. ProxyNotShell, çünkü bazı benzerlikleri var. ProxyKabuğu sadece bir yıl önce büyük hikaye olan güvenlik açığı,

Ancak bu benzerliklere sahip olmasına rağmen, birbirine zincirleyen ve potansiyel olarak uzaktan kod yürütme sağlayan tamamen yeni bir istismar çiftidir - bu doğru mu?

---

ÇET.  Kulağa böyle geliyor.

Bu güvenlik açıkları, bir kurbana yönelik aktif bir saldırı sırasında keşfedildi ve GTSC adlı Vietnamlı bir kuruluş, rakiplerin bazı müşterilerine erişmesine izin veren bu iki yeni güvenlik açığını çözdü.

Sorumlu bir şekilde ifşa etmişler gibi görünüyor bu güvenlik açıkları Sıfır gün güvenlik açıklarını sorumlu bir şekilde bildirmek için Trend Micro tarafından yürütülen Sıfır Gün Girişimi'ne [ZDI].

Ve tabii ki ZDI, üç haftadan biraz daha uzun bir süre önce tüm bu istihbaratı Microsoft ile paylaştı.

Ve bugün çıkmasının sebebi bence Vietnamlı grup...

…görünüşe göre biraz sabırsızlanıyorlar ve üç hafta olduğu ve insanları sözde ulus devlet aktörlerine karşı korumaya yardımcı olacak hiçbir uyarı veya tavsiyenin gönderilmediğinden endişeleniyorlar.

Bu yüzden alarm zillerini yükseltmeye ve herkesin kendilerini korumak için bir şeyler yapmaları gerektiğini bilmelerine karar verdiler.

---

ÖRDEK.  Ve adil olmak gerekirse, dikkatlice dediler ki, "Bu güvenlik açıklarından tam olarak nasıl yararlanılacağını açıklamayacağız, ancak size etkili bulduğumuz hafifletme yöntemlerini vereceğiz."

Görünüşe göre ya kendi başına istismar özellikle tehlikeli değil…

…ancak zincirleme, sunucunuzdaki e-postaları okuma yeteneğine sahip kuruluş dışından birisinin aslında ilk hatayı kapıyı açmak için, ikinci hatayı ise esasen Exchange sunucunuza kötü amaçlı yazılım yerleştirmek için kullanabileceği anlamına gelir.

---

ÇET.  Ve bu gerçekten önemli bir nokta, Duck, söylediğin şey, "Sunucunuzda e-posta okuyabilen biri."

Bu *kimliği doğrulanmamış* bir saldırı değildir, bu nedenle saldırganların bu saldırıları başarılı bir şekilde yürütmek için kuruluşunuz hakkında biraz istihbarata sahip olmaları gerekir.

---

ÖRDEK.  Şimdi, tam olarak ne tür kimlik bilgilerine ihtiyaçları olduğunu bilmiyoruz, çünkü bunu [2022-09-30T23:00:00Z] kaydettiğimiz sırada, her şey hala büyük ölçüde gizli.

Ancak okuduklarıma göre (inanmaya meyilli olduğum insanlardan), oturum çerezleri veya kimlik doğrulama belirteçleri yeterince iyi değil ve aslında bir kullanıcının şifresine ihtiyacınız olacak gibi görünüyor.

Şifreyi girdikten sonra, ancak iki faktörlü kimlik doğrulama [2FA] varsa, ilk hata (kapıyı açan), şifrenin verildiği nokta ile 2FA kodlarının girileceği nokta arasında tetiklenir. talep edilen*.

Yani şifreye ihtiyacınız var ama 2FA koduna ihtiyacınız yok…

---

ÇET.  Öyle demek istiyorsanız, kulağa "orta-kimlik doğrulama güvenlik açığı" gibi geliyor.

Bu karışık bir nimettir.

Bu, 2021'de ProxyLogon ve ProxyShell ile gördüğümüz gibi, otomatikleştirilmiş bir Python betiğinin tüm interneti tarayamayacağı ve dünyadaki her Exchange sunucusundan birkaç dakika veya saat içinde potansiyel olarak yararlanamayacağı anlamına gelir.

Son 18 ayda solucanların pek çok kuruluşun zararına geri döndüğünü gördük.

---

ÖRDEK.  "Köstebek"?

---

ÇET.  Wormage, evet! [GÜLER]

---

ÖRDEK.  Bu bir kelime mi?

Peki, değilse, şimdi oldu!

Bunu beğendim... Ödünç alabilirim Chester. [GÜLER]

---

ÇET.  Sanırım bu biraz solucan olabilir, değil mi?

Bir parolaya ihtiyacınız var, ancak herhangi bir Exchange sunucusunda geçerli bir e-posta adresi ve parola kombinasyonu bulmak maalesef çok zor değil.

Yüzlerce veya binlerce kullanıcıdan bahsettiğinizde… birçok kuruluşta bunlardan bir veya ikisinin şifreleri muhtemelen zayıftır.

Ayrıca, Outlook Web Access [OWA]'da başarılı bir şekilde oturum açmak için FIDO belirteçlerini veya kimlik doğrulayıcılarını veya hangi ikinci faktörü kullanıyor olursanız olun, gerektiğinden bugüne kadar istismar edilmemiş olabilirsiniz.

Ancak bu saldırı o ikinci faktörü gerektirmez.

Yani, sadece bir kullanıcı adı ve şifre kombinasyonu edinmek oldukça düşük bir engel…

---

ÖRDEK.  Şimdi burada başka bir karmaşıklık var, değil mi?

Yani her ne kadar Microsoft'un yönergesi resmi olarak Microsoft Exchange Online müşterilerinin Mavi Uyarı'dan vazgeçebileceğini söylüyor, bu yalnızca şirket içi Exchange'iniz varsa tehlikelidir…

…Muhtemelen birkaç yıl önce buluta geçen, geçiş sırasında hem kurum içi hem de bulut hizmetlerini aynı anda çalıştıran, şirket içi sistemi hiçbir zaman kapatamayan şaşırtıcı sayıda insan var. Değişim sunucusu.

---

ÇET.  Tam!

Bunun ProxyLogin ve ProxyShell'e geri döndüğünü gördük.

Çoğu durumda, suçlular ağlarına sahip olmadıklarını düşündükleri Exchange sunucuları aracılığıyla girdiler.

Örneğin, birileri VMware sunucularında çalışan VM'lerin listesini kontrol ederek, şirket içi ağları ile bulut ağı arasında verilerin taşınması sırasında kendilerine yardımcı olan göçmen Exchange sunucularının…

…aslında hala açıktı ve etkinleştirilmiş ve internete açıktı.

Ve daha da kötüsü, orada oldukları bilinmediğinde, yama alma olasılıkları daha da düşüktür.

Demek istediğim, Exchange'e sahip kuruluşlar, en azından muhtemelen düzenli olarak bakımlarını planlamak için kendi yollarından çıkıyorlar.

Ancak ağınızda “unuttuğunuz için” bir şey olduğunu bilmediğinizde, ki bu VM'lerde gerçekten kolaydır, daha da kötü bir durumdasınızdır, çünkü muhtemelen Windows güncellemeleri veya Exchange güncellemeleri uygulamamışsınızdır.

---

ÖRDEK.  Ve Murphy kanunu diyor ki, o sunucuya gerçekten güveniyorsanız ve ona düzgün bakmıyorsanız, gerçekten ihtiyacınız olmadan bir gün önce çökecektir.

Ama orada olduğunu bilmiyorsanız ve kötü amaçlarla kullanılabiliyorsa, yıllarca ve yıllarca sorunsuz bir şekilde çalışma şansı muhtemelen oldukça yüksektir. [GÜLER]

---

ÇET.  Evet, ne yazık ki, bu kesinlikle benim deneyimim oldu!

Aptalca geliyor, ancak neye sahip olduğunuzu bulmak için kendi ağınızı taramak, yine de düzenli olarak yapmanızı önereceğimiz bir şey.

Ama kesinlikle, bunun gibi bir bülteni duyduğunuzda, Microsoft Exchange gibi geçmişte kullandığınızı bildiğiniz bir ürünse, bunu dahili olarak çalıştırmak için iyi bir zaman. Nmap taraması...

…ve belki de oturum açın shodan.io ve tüm bunların kapatıldığından emin olmak için harici hizmetlerinizi kontrol edin.

---

ÖRDEK.  Artık Microsoft'un kendi yanıtından, yamaları çıkarmak için çılgınca kunduz ettiklerini biliyoruz.

Bu yamalar göründüğünde, onları oldukça hızlı bir şekilde uygulasanız iyi olur, değil mi?

Çünkü herhangi bir yama, istismarı çözmek için tersine mühendislik için hedeflenecekse, bu tür bir şey olacak.

---

ÇET.  Evet, kesinlikle, Ördek!

Bir kez yama yapsan bile, bir zaman penceresi olacak, değil mi?

Demek istediğim, tipik olarak Microsoft, Salı günleri Yama için zaten yamalarını Pasifik saatiyle 10.00'da yayınlar.

Şu anda Yaz Saati'ndeyiz, yani UTC-7… yani, UTC'nin yaklaşık 17:00'si genellikle Microsoft'un yamaları yayınladığı zamandır, böylece çalışanlarının çoğu Seattle'dan gelen sorguları yanıtlamak için tüm günlerini harcar. [Microsoft HQ Bellevue, Seattle, WA'dadır.]

Buradaki anahtar, başlamadan önce bunun ne kadar kolay istismar edildiğine bağlı olarak, saatler, belki de dakikalar arasında bir tür "yarış" olmasıdır.

Ve yine, ProxyShell ve ProxyLogon ile önceki Exchange istismarlarına geri dönersek, genellikle üç, dört, beş gün içinde yama uygulayan müşterilerin bile…

… dürüst olmak gerekirse, bir Exchange sunucusu için biraz hızlıdır, e-posta sunucularınızı kesintiye uğratmadan önce güvenilir olduğundan emin olmak için çok sayıda test yapılması gerektiğinden yama yapmak çok zordur.

Bu sunucuların alması için yeterli zamandı Web kabukları, cryptominers, her türlü arka kapılar üzerlerine kurulur.

Ve böylece, resmi yama çıktığında, sadece hızlı hareket etmeniz gerekmiyor…

…*hareket ettikten sonra*, geri dönüp bu sistemlerin, yamanın kullanıma sunulduğu zaman ile sizin onu uygulayabildiğiniz zaman arasındaki boşlukta saldırıya uğramış olabileceğine dair kanıtlar için baştan sona kontrol etmeye değer.

Eminim Naked Security hakkında çokça konuşulacaktır. Twitter ve diğer yerlerde, ne arayacağınızı bilmeniz için gördüğümüz saldırı türleri hakkında konuşuyoruz.

---

ÖRDEK.  Halihazırda sınırlı sayıda saldırıda dağıtılmış olan bir dizi bilinen kötü amaçlı yazılım karmalarını arayabilirsiniz…

…gerçekten, sonuçta, her türlü kötü amaçlı yazılım olasılıktır.

Ve böylece, sanırım söylediğin gibi son mini bölüm yaptığımıza göre, artık sadece kontrol panelinize gelen kötü bir şeyle ilgili uyarıları beklemek yeterli değil:

Proaktif olarak dışarı çıkmalı ve dolandırıcıların ağınızda olup olmadığına ve sizin henüz fark etmediğiniz bir şeyi arkalarında bırakmış olmalarına (uzun zamandır orada olabilirdi!) bakmalısınız.

---

ÇET.  Bence bu bizi şuna yönlendiriyor, “Yamayı beklerken şimdi ne yapacağız?”

Microsoft Güvenlik Araştırma Merkezi (MSRC) blogu yayınlandı bazı hafifletme tavsiyeleri ve ayrıntılar… Microsoft'un şu anda ifşa etmeye istekli olduğu kadar.

saf olsan derdim Microsoft Exchange Çevrimiçi müşteri, hemen hemen ortadasınız ve bir şeylerin değişmesi durumunda dikkat etmelisiniz.

Ancak hibrit bir durumdaysanız veya hala şirket içinde Microsoft Exchange çalıştırıyorsanız, muhtemelen bu öğleden sonra veya yarın sabah yapmaya değer bazı işler olduğunu düşünüyorum.

Tabii ki, kayıt sırasında, bu Cuma öğleden sonra… yani, gerçekten, bunu dinlerken, “Hemen, ne zaman duysanız, daha önce yapmadıysanız.”

Buradaki en iyi uygulamalar nelerdir, Ördek?

Açıkçası, yapabileceğiniz bir şey, bir yama bulunana kadar harici web erişimini kapatmaktır.

Sadece IIS sunucunuzu kapatabilirsiniz ve o zaman bunu yapacaktır!

---

ÖRDEK.  Pek çok şirketin bu durumda olmayacağından şüpheleniyorum.

Ve Microsoft, söyledikleri iki şeyi listeler… pekala, söylemezler, "Bu kesinlikle işe yarayacak."

Riskinizi büyük ölçüde sınırlayacağını öne sürüyorlar.

Birincisi, IIS sunucunuza uygulayabileceğiniz bir URL yeniden yazma kuralının olmasıdır. (Anladığım kadarıyla, Exchange Web Hizmetlerine [EWS] erişime dönüşen gelen bağlantıyı kabul eden IIS'dir.)

Dolayısıyla, PowerShell tetiklemesinin başlatılmasını önleyecek, ilk deliğin olası istismarlarını arayacak, yapabileceğiniz bir IIS ayarı vardır.

Ayrıca Exchange Sunucunuzda engelleyebileceğiniz bazı TCP bağlantı noktaları vardır.

5985 ve 5986 numaralı bağlantı noktası olduğuna inanıyorum, bu da denilen şeyi durduracak. PowerShell Uzaktan İletişim… bu sahte PowerShell uzaktan yürütme komutlarının Exchange sunucusuna gönderilmesini durduracaktır.

Bununla birlikte, Microsoft'un, her şeyi düzelteceğini bildiklerini vaat etmek yerine, bunun maruz kalmanızı “sınırlandıracağını” söylediğini unutmayın.

Ve bunun nedeni, bunun tetiklenebileceği başka yollar olduğundan şüphelenmeleri olabilir, ancak henüz ne olduklarını tam olarak çözemediler. [GÜLER]

Hiçbir ayar, Exchange'in kendisinde yaptığınız bir şey değildir.

Bunlardan biri IIS'de, diğeri ise bir tür ağ filtreleme kuralı.

---

ÇET.  Microsoft bize kalıcı bir düzeltme sağlarken, bu önümüzdeki birkaç gün içinde bize yardımcı olur.

İyi haber şu ki, güvenlik duvarınıza entegre edilebilecek bir IPS veya Microsoft Windows Server altyapınızı koruyan uç nokta güvenlik ürünleri olsun, birçok güvenlik yazılımı olduğunu düşünüyorum…

…bunun için yapılan saldırılar, çoğu durumda (en azından ilk raporlar), ProxyLogon'a çok benziyor ve sonuç olarak, mevcut kuralların bu saldırılara karşı koruma sağlayıp sağlayamayacağı belirsiz.

Olabilir, ancak buna ek olarak, çoğu satıcı, şu anda herkese açık olarak paylaşılan tüm göstergelere dayanarak, mümkün olduğunca hazır olduklarından emin olmak için onları biraz sıkılaştırmaya çalışıyor gibi görünüyor, böylece tespit edecekler ve Exchange sunucularınızda meydana gelirse size uyarılar gönderir.

---

ÖRDEK.  Bu doğru, Chester.

Ve Sophos müşterileri için iyi haber şu ki, gidip günlüklerinize bakmak istiyorsanız Sophos'a özel algılamaları takip edebilirsiniz.

İster güvenlik duvarındaki ister uç noktadaki IPS olsun, yalnızca IPS için değil, aynı zamanda bir dizi davranış kuralımız da var.

Onları aramaya gitmek istiyorsanız, bu tespit adlarını takip edebilirsiniz… @SophosXops Twitter beslemesi.

Tehdit avcılığı için kullanabileceğiniz yeni tespit adları edindikçe, kolayca arayabilmeniz için bunları orada yayınlıyoruz:

Sophos X-Ops aşağıdaki algılamaları ekledi:

Troj/WebShel-EC ve Troj/WebShel-ED, saldırılarda tartışılan web kabuklarını algılar.

IPS imzası sid:2307757, Microsoft tarafından hem Sophos XG Güvenlik Duvarı hem de Sophos Endpoint IPS için yayınlanan bilgilere dayanmaktadır.

— Sophos X-Ops (@SophosXOps) Eylül 30, 2022

---

ÇET.  Gelecek haftanın podcast'inde, Doug'un aranıza katılması mı, yoksa bir kez daha misafir koltuğuna oturmam mı hakkında söyleyecek daha çok şeyimiz olacağına eminim.

Ama bunu bir süreliğine yatağa atamayacağımızdan oldukça eminim….

---

ÖRDEK.  Sanırım, ProxyShell gibi, Log4Shell gibi, uzunca bir süre yankılanan bir yankı olacak.

Belki de her zaman yaptığımız gibi söylesek iyi olur, Chester:

Bir sonrakine kadar…

---

HER İKİSİ DE.  Güvende kalın.

[MÜZİKAL MODEM]