Yıllar Eski, Yamasız GWT Vuln, Uygulamaları Sunucu Tarafı RCE’ye Açık Bırakıyor


Google Web Araç Seti açık kaynak uygulama çerçevesinde gizlenen, kimliği doğrulanmamış bir Java seri durumdan çıkarma güvenlik açığı, ilk ortaya çıkışının üzerinden sekiz yıldan fazla bir süre geçtikten sonra yama yapılmadan kalıyor ve savunmasız uygulamalar için temel çerçeve düzeltmeleri gerektirebilir.

GWT, Web geliştiricilerinin Java’da JavaScript ön uç uygulamaları oluşturmasına ve sürdürmesine olanak tanıyan açık kaynaklı bir araç setidir. Teknoloji takip platformu Enlyft’e göre 2.000 civarında GWT kullanan şirketlerçoğunluğu 1 ila 10 çalışanı olan ve yıllık gelirleri 1 milyon ila 10 dolar arasında değişen küçük şirketlerdir.

Yeni araştırmada, Piskopos Fox’un genel müdürü Ben Lincoln, bu duruma inanmadığını ifade etti. GWT güvenlik açığıUzaktan kod yürütülmesine izin veren bu sorun bunca yıldır düzeltilmedi. Java seri durumdan çıkarma hatası şuna benzer Spring4Shell güvenlik açığı 2022’de keşfedildi.

Lincoln, “Herhangi bir yama yayınlanmasaydı, en azından savunmasız çerçeve özellikleri kullanımdan kaldırılmış olarak işaretlenebilirdi (olabilirdi) ve çerçeve belgeleri, savunmasız kodun güncellenmiş alternatiflerle değiştirilmesine yönelik öneriler sağlayabilirdi (olabilirdi),” diye yazdı Lincoln. “En azından, çerçeve geliştiricileri, işlevselliği vurgulamak yerine, savunmasız özellikleri kullanmanın doğasında olan tehlikeyi belirtmek için ‘başlangıç’ eğitimlerini ve diğer belgeleri şüphesiz güncelleyebilirdi.”

Kodun bakımcıları, bu adımların hiçbirini o tarihten bu yana atmadı. GWT kusuru Lincoln, bu konunun ilk kez 2015 yılında açıkça tartışıldığını ve paylaşımında savunmasız bir GWT uygulamasının gerçek dünyada nasıl istismar edilebileceğini tam olarak detaylandırdığını söyledi.

Savunmasız Uygulama Azaltma

Lincoln, açığa çıkan Web uygulamalarına yönelik önlemlerin ağır bir yük olacağı konusunda uyarıyor.

Araştırmasında, güvenlik açığı o kadar temel düzeyde ki “bu çerçeve kullanılarak yazılan savunmasız Web uygulamalarının güvenliğinin sağlanması muhtemelen bu uygulamalarda veya çerçevenin kendisinde mimari değişiklikler gerektirecektir” diye açıkladı.

Başlangıç ​​olarak Lincoln, Dark Reading’e, savunmasız uygulamaları çalıştıran yöneticilerin en kötü senaryoya göre plan yapması ve oradan çalışması gerektiğini söylüyor.

“[They should ask] İşletmemiz bu uygulamaya erişimi derhal engellemek zorunda kalsaydı ve bir düzeltme sağlanana kadar erişimi yeniden sağlamasaydı ne yapardık?” Lincoln diyor.

Daha genel anlamda, bu tür bilinen, yama yapılmamış kusurlarla çalışmaktan kaçınmak için, üçüncü taraf bileşen operatörlerinin yama uygulamaya ne kadar duyarlı olduklarının izlenmesini öneriyor.

“Yama yerine ‘bizim sorunumuz değil’ türünde bir sonuca yol açtıklarında, kuruluşunuzun bu görüşe katılıp katılmadığını veya bileşeni değiştirmeyi, iyileştirme ile özelleştirilmiş bir sürüm oluşturmayı vb. hak edip etmediğini değerlendirin.” Lincoln tavsiye eder. “Düşük riskli kabul edilirse, kuruluşun hala aynı sonuca ulaşıp ulaşmadığını görmek için en az yılda bir kez gözden geçirilecek bir güvenlik açığı olarak dahili olarak takip edin.”

Şunları ekliyor: “Şirket içinde geliştirilen uygulamalar için, temel aldıkları üçüncü taraf bileşenlerinin listesini düzenli aralıklarla inceleyin ve popülerliğin veya geliştirici etkinliğinin azalmakta olduğu herhangi bir yerden, öyle olmasalar bile, geçiş yapmayı düşünün. resmen terk edilmiş veya desteklenmiyor.”





Source link