Apache Velocity Tools’daki açıklanmayan Siteler Arası Komut Dosyası (XSS) güvenlik açığı, kimliği doğrulanmamış saldırganlar tarafından NASA dahil olmak üzere devlet sitelerini hedeflemek için kullanılabilir .
Güvenlik açığının raporlanıp yamalanmasının üzerinden 90 gün geçmesine rağmen, henüz güvenlik önlemleri alınmadı.
Apache Velocity, geliştiriciler tarafından Model-View-Controller (MVC) mimarisinde görünümler tasarlamak için kullanılan Java tabanlı bir şablon motorudur .
Velocity Tools, standart ve web uygulamaları içindeki Velocity entegrasyonunu daha da kolaylaştıran sınıflardan oluşan bir alt projedir.
Başlıklar
Apache Velocity Araçlarını kullanan Gov Sitelerinde Bulunuyor !
Apache Velocity Tools, aylar önce GitHub’da yayınlanan bir düzeltmeye rağmen tüm sürümlerini etkileyen, açıklanmayan bir XSS güvenlik açığına sahiptir .
Sonatype’ın Nexus Intelligence sistemlerini sorguladığımda, bu kusuru içeren Apache Velocity Tools sınıfının npm, PyPI, Maven Central ve diğer açık kaynak depolarından indirilebilen 2.600’den fazla benzersiz ikili yazılım uygulamasına dahil edildiğini keşfettim.
Bileşenin geliştiriciler arasındaki popülaritesi, Velocity Tools’u etkileyen güvenlik açıklarının zamanında ifşa edilmesini çok önemli hale getirir.
Sakura Samurai etik hackleme grubundan güvenlik araştırmacısı Jackson Henry , ilk olarak 2020 Ekim ayı başlarında Apache’ye yönelik güvenlik açığını keşfetti ve bildirdi.
Proje, Henry’nin raporunu kabul etmiş ve 5 Kasım 2020’de GitHub’da halka açık bir düzeltme yayınlamış olsa da, Sakura Samuray araştırmacılarını endişelendiren düzgün bir kamuya açıklama asla gerçekleşmedi .
Yansıyan XSS kusuru, VelocityViewServlet görünüm sınıfının hata sayfalarını nasıl oluşturduğunda mevcuttur .
Geçersiz bir URL’ye erişildiğinde, “şablon bulunamadı” hata sayfası, URL’nin kaynak yolu bölümünü potansiyel XSS komut dosyaları için çıkış yapmadan olduğu gibi yansıtır .
Saldırgan sonuç olarak kurbanı böyle bir URL’yi tıklaması için kandırabilir, bu da kurbanı değiştirilmiş bir kimlik avı sayfasına götürür veya oturum açma bilgilerini çalabilir.
BleepingComputer’ın gözlemlediği gibi , savunmasız Apache Velocity Tools örnekleri, * .nasa.gov ve * .gov.au dahil olmak üzere devlet web siteleri tarafından kullanılıyor .
Bu XSS istismarının daha karmaşık varyasyonları, bazı sosyal mühendislik hileleriyle birleştirildiğinde, saldırganların oturum açmış kullanıcıların oturum tanımlama bilgilerini toplamasına ve potansiyel olarak oturumlarını ele geçirmesine izin verebilir.
Bu, özellikle aşağıda gösterilenler gibi devlet alan adlarında barındırılan çalışan ve yüklenici oturum açma portalları ile ilgilidir.
Apache: önem derecesine göre öncelik verilen güvenlik açığı raporları
İle temasa zaman BleepingComputer yorum için , gösterildiği gibi, Apache Software Foundation (ASF) Apache Güvenlik Ekibi yılda açığı raporları yüzlerce alır belirtti ve sorunun ciddiyetine bağlı olarak zamanında onlara cevap olduğunu onların yıllık güvenlik raporu .
“Apache Velocity araçlarındaki XSS güvenlik açığı ile ilgili olarak, Apache Güvenlik Ekibi ile ilk olarak 6 Ekim 2020’de Velocity Tools paketinin bir bölümünü etkileyen buldukları bir sorunu ifşa eden bir kişi (sorun muhabiri olarak anılır) ile iletişime geçti.”
“Bunu, raporu 7 Ekim’de araştırıp kabul eden ve muhabirin yamayı göndermesini öneren Apache Velocity Proje Yönetim Komitesi (PMC) ile özel olarak paylaştık.”
“Daha sonra muhabir bir talepte bulundu ve ekip birkaç hafta boyunca düzeltmeyi hassaslaştırmak için çalıştı. Bu düzeltme 5 Kasım’da uygulandı. Muhabir yamayı 8 Ekim’de herkese açık olarak sundu ve Güvenlik açığının kritik doğası gereği, Velocity ekibi kamuoyunda konu üzerinde çalışmaya devam etmeye karar verdi. “
ASF Güvenlik Başkan Yardımcısı Mark J Cox, BleepingComputer’a yaptığı açıklamada , “Sorun dahili olarak 8 Ekim’de CVE-2020-13959 olarak atandı,” dedi .
Proje için kalan bir sonraki adım, CVE’den bahsedecek sabit bir Hız Araçları sürümü ve tarihi henüz belirlenmemiş bir yükseltme yolu yapmaktır.
Bununla birlikte, bir düzeltmenin yayınlanmasını beklemek istemeyen kullanıcılar, herkesin görebileceği düzeltmeyi kendileri uygulamayı deneyebilirler .
CNA olarak hareket eden satıcılarla ilgili artan endişeler
Son zamanlarda güvenlik açığı raporlarının sayısı katlanarak artmaya devam ederken, CVE kimlikleri atamakla görevli kar amacı gütmeyen kuruluş MITER, ölçeklenebilirlik zorluklarıyla karşılaştı.
CVE atama ve sorumlu ifşa sürecini hızlandırmak için CVE Numaralandırma Yetkilileri (CNA’lar) kavramı tanıtıldı.
Bir CNA olarak onaylanan kuruluşlar, güvenlik açığı raporları için CVE atama ve MITER adına sorumlu ifşa sürecini yürütme yetkisine sahiptir.
Ancak son zamanlarda, giderek daha fazla satıcı CNA olmak için adım atıyor ve güvenlik açığı ifşa sürecinin kontrolünü ele alıyor.
Bu, infosec uzmanlarını bu gelişmenin uzun vadede güvenliği gerçekten engelleyip engelleyemeyeceği konusunda endişelendirdi.
The Daily Swig tarafından daha önce bildirildiği üzere , MITRE kuralları uyarınca, bir CNA’nın projelere özel olarak bildirilen ve bazıları kendi ürünlerini de içerebilecek güvenlik açıklarına CVE ataması gerekmez.
Bu, satıcıların en ciddi güvenlik sorunlarını bile hemen bunları kamuya bildirmek zorunda kalmadan sessizce çözebilecekleri anlamına gelir.
Son zamanlarda, bu, VMWare durumunda, PT Swarm araştırmacıları tarafından vCenter’da kimliği doğrulanmamış bir dosya okuma güvenlik açığı rapor edildiğinde ve hemen bir CVE yayınlanmadan VMWare tarafından sessizce yamalandığında meydana geldi.
“Şirketlerin güvenlik açıklarını ciddiye alması ve yamalar tasarlamak için araştırmacılarla birlikte çalışması gerekiyor.”
Henry , bir e-posta röportajında BleepingComputer’a “İletişim ve durum güncellemeleri, araştırmacıları döngüde tutmak için çok önemlidir, bu, gözden kaçabilen ve şeffaflığa zarar verebilecek önemli bir iyileştirme yönüdür – hatta cesaret kırıcıdır,” dedi .
Apache Güvenlik Ekibi, CVE işleme süreçlerinin ayrıntılarını BleepingComputer ile paylaştı ; bu, bazen kritik olmayan sorunlar için güvenlik açığı açıklamalarını kısa bir süre geciktirmeyi de içerebiliyor.
“Güvenlik sorunlarının kritik olmadığı durumlarda, bazı projeler diğer sorunların aynı anda ele alınmasına izin vermek için bir sürüm için kısa bir süre bekletecektir.”
“Bu örnekte dikkat edilmesi gereken nokta, sorunu bildiren kişinin ASF güvenlik ekibine gönderdiği her e-postaya bir iş günü içinde yanıt verildi ve muhabir hızlı yanıtımızı övdü, bu nedenle muhabirin bunları hissettiğini öğrendiğimizde biraz şaşırdık.
Bir başka makale: Web Sitenizi Hackerlerden Korumak için 6 Güvenlik İpucu
