Hayallerindeki eve taşınan bir aile, uğursuz mektuplar, garip bir kiracı ve uğursuz tehditlerle boğuşur. Tanıdık geliyor mu?
Olması gerekiyor. Bunun arkasındaki hikaye İzleyici13 Ekim 2022’de Netflix’te prömiyeri yapılan gerçek bir suç dizisi. Aynı zamanda, aynı gün duyurulan ve dünya çapında pek çok kişinin bilinmeyen saldırganların özel ortamlarına erişmesi ve uygulamalarını tehdit etmesi korkusuna neden olan Text4Shell güvenlik açığının hikayesidir. .
Text4Shell, saldırganların bir sunucuya uzaktan erişmesine ve üzerinde kötü amaçlı kod çalıştırmasına olanak tanıyan bir uzaktan kod yürütme (RCE) güvenlik açığıdır. RCE saldırıları, son zamanlarda aşağıdaki gibi güvenlik açıklarıyla çok popüler hale geldi: Log4Shell ve Ağlamak istiyorgenel ortamlarda API’leri (REST, GraphQL, LDAP vb.) ortaya çıkaran bulut uygulamalarının büyümesi nedeniyle.
Bu saldırılar, bilgisayar korsanlarının denemesi için kolaydır. Tek yapmaları gereken, savunmasız olduğu bilinen bir teknoloji yığınını çalıştıran uygulamalar için İnternet’i taramak ve kötü amaçlı kodlarını enjekte etmelerine izin verecek doğru harici uç noktayı aramak.
Text4Shell Nasıl Çalışır?
Apache Ortak Metin kitaplığı, metin işleme ve diğer dize algoritmaları için yaygın olarak kullanılan bir Java kitaplığıdır. Birçok OSS kitaplığı için tedarik zincirinde yaygın bir bağımlılıktır ve doğrudan birçok Java uygulaması tarafından da kullanılır.
Bir dizgedeki değişkenleri ikame etmek üzere enterpolatörler oluşturmak için kütüphane işlevlerinden biri, belirli bir dizginin bir bölümünü yalıtım kullanmadan yürüttüğü için hatalı bir mantığa sahiptir. Bu gözetim, diziyi tüm ortam için erişilebilir hale getirir. Pratik bir ifadeyle, ‘https://your.app/user/userID’ gibi bir istek parametresine sahip bir REST API’niz varsa, bu ‘userID’ değişkenini ‘createInterpolation(userID)’ işleviyle değiştirirsiniz. .
Genel bir API söz konusu olduğunda, herhangi bir saldırgan “userID” parametresini kötü amaçlı kodla değiştirebilir ve bu kodun sizin ortamınızda yürütmesini sağlayabilir. Böyle bir saldırının en kötü senaryosu, ortamınızın uzaktan kabuk kontrolünü ele geçirmektir (bu güvenlik açıkları sınıfının *4Shell olarak adlandırılmasının nedeni budur).
İleride okumak için, bu Palo Alto Ağları gönderisi yerel olarak çalıştırabileceğiniz ve bu kusuru çalışırken görebileceğiniz pratik bir kod örneğine sahiptir.
RCE’leri Proaktif Olarak Önleyebilir miyiz?
İşletmelerin asla saldırıya uğramayacaklarına dair söz vermelerinin bir yolu olmasa da, ilerici geliştirme kuruluşlarında proaktif DevSecOps metodolojisini uygulamak sizi gelecekteki RCE’lerde ve *4Shell saldırılarında çok fazla acıdan kurtarabilir.
Aşamalı DevSecOps yaklaşımları, uygulamanızın tedarik zincirinden üretimdeki çalışma zamanına kadar tüm yazılım geliştirme yaşam döngüsündeki tüm potansiyel riskleri değerlendirmek için ortak bir çaba gösterir. Yine de burada bitmiyor. Daha kritik olan kısım, bu tür güvenlik açıklarını tespit etmek, tahmin etmek ve düzeltmek için sürekli otomatikleştirilmiş boru hatları oluşturmayı kolayca mümkün kılmaktır.
Aşağıdaki en iyi uygulamalar listesi, bilinen bilgisayar korsanlığı vektörlerine karşı savunma yapmak için mevcut güvenlik alanı uzmanlığına dayalı güvenliği özerk bir şekilde sürdüren, kendini savunan mühendislik kuruluşları oluşturmada size adım adım rehberlik edecektir.
1. Kod Tabanınızda SCA Araçlarını Sürekli Çalıştırın
Yazılım Kompozisyon Analizi araçları, yazılımda kullanılan kitaplıkların ve araçların savunmasız sürümlerini tespit etmek için çevrimiçi kaynaklardan yararlanan sayısız ücretsiz ve ticari araçla birlikte uzun yıllardır mevcuttur. Piyasada bulunan birçok araç, denetim düzeyleri ve güvenlik açığı veritabanlarının kalitesi ve kapsamı bakımından farklılık gösterir. Java için, aşağıdakiler gibi açık kaynaklı araçları kullanabilirsiniz: OWASP bağımlılık kontrolü (veya Snyk ve Mend gibi ticari araçlar). Hangisini seçerseniz seçin, teknoloji yığınınız için mevcut olan SCA aracını bulmalı ve düzenli olarak çalıştırmalısınız. Biraz savunma hiç olmamasından iyidir.
Bu araçları kod tabanında periyodik olarak çalıştırarak, tedarik zincirinizde kullandığınız araçların ve kitaplıkların savunmasız sürümlerini tam zamanında tespit edebilirsiniz. Güvenlik açığı bulunan sürümleri içerebilecek güncellemeler için gönderilen yeni kodu sürekli olarak izlerken, en azından günlük olarak çalıştırmanızı öneririz.
Diğer bir nokta da, güvenlik açığı bulunan üçüncü taraf kitaplıklarının ve araçlarının sürümlerini güncellemek için iyi tanımlanmış bir strateji sağlamaktır. Güvenlik açıkları ve bunların giderildiği sürümler hakkında veri toplayan https://osv.dev gibi API’ler aracılığıyla yardım alabilir ve ayrıca Dependabot veya jit.io otomatik düzeltme özelliği gibi sabit sürümü uygulayan otomatik süreçler oluşturabilirsiniz.
2. SAST Araçlarını Kullanın
Üçüncü taraf kitaplıklarında bulunan güvenlik açıkları, düzeltme için her zaman en yüksek önceliği almamalıdır. Text4Shell örneğinde, kodda ‘createInterpolator()’ işlevini kullanmazsanız, güvenlik açığından pratik olarak yararlanmak mümkün olmadığından yükseltmeye öncelik vermeniz için hiçbir neden yoktur. (Bu Twitter dizisi OWASP ZAP’ın yaratıcısı Simon Bennetts tarafından yazılan, hala birçok kişinin çılgına döndüğü Log4Shell örneğine dayalı olarak gerçek riske öncelik verilmesi hakkında çok şey öğretebilir).
Öyleyse – bunun kodunuzun herhangi bir yerinde kullanılıp kullanılmadığını nasıl bilebilirsiniz? SAST araçlarını çalıştırarak. Statik analiz güvenlik testi (SAST) araçları, adından da anlaşılacağı gibi, kodda savunmasız yerler olup olmadığını bulmak için Özet Kaynak Ağacı (AST) veya diğer dizi tarama yöntemleri gibi araçlarla kodunuzu statik olarak tarayın bilinen sorunlara Bu tür araçların güncellenmiş sürümleri, güvenlik açığı bulunan kodu algılar ve sizi uyarır. Araçlardan bazıları güvenlik açıkları için pratik bir düzeltme bile sunacak, bu nedenle kodu yalnızca önerdikleri yama ile değiştirmeniz gerekecek.
Aşağıdakiler gibi dillere özgü SAST araçlarını bulabilirsiniz: haydut Python için ve GoSec Golang için, ancak SonarQube ve SemGrep gibi diller arası araçlar da var.
Bu araçları, otomatikleştirilmiş CI/CD ardışık düzenlerinin bir parçası olarak çalışacak şekilde de tanımlayabilirsiniz, böylece ilgili yeni sorunlar üretime yayılmasını önlemek için zamanında yakalanır.
3. Varsayılan Hatalardan Kaçının
Daha önce bahsedilen RCE saldırılarının sayısındaki patlama, saldırganlara savunmasız sunucular için halka açık İnternet’i keşfetmenin kolay bir yolunu sağlayan, halka açık API’lerin varlığının yan ürünüdür. Tipik yöntem, varsayılan hata mesajlarını ve sayfaları kullanan hata yanıtlarını tarayan otomatik betikler oluşturmaktır; bu, altta yatan teknolojiyi tanımlamayı kolaylaştırır. (Örneğin, en sık kullanılan Web sunucusu olan Apache Java 404 varsayılan sayfası, bugün bile olası saldırganlar için bir altın madeni olmaya devam ediyor.) Kullanıcılara döndürülen hatalardan herhangi birini özel bir hatayla sarmalayarak, kullanıcıların işini zorlaştırırsınız. Örneğin, hangi sunucu teknolojisini kullandığınızı belirlemek için saldırganlar.
SAST ve lint araçlarının çoğu, kod incelemeleri ve kod stili için en iyi uygulama olarak hizmet etmenin yanı sıra, her HTTP isteği statik ağacını izleme ve son kullanıcıya döndürülen herhangi bir ham hata hakkında uyarı verme avantajını da sağlar.
4. Her Şeyi Kod Olarak Yapılandırın
Her şeyi kod olarak yapılandırarak, tüm yapılandırma değişiklikleri ve geri almaları hızlı ve sessiz hale getiren güvenilir ve aranabilir bir şekilde protokollenir, izlenir ve yönetilir. Sadece bu değil, aşağıdakiler gibi otomatik araçları da kullanabilirsiniz: KICS ve Checkov, yapılandırma dosyalarını gerçek bir ortama dağıtmadan önce güvenlik açığı bulunan yapılandırmalara karşı tarar. Bu araçları çalıştırarak aşağıdakiler gibi kritik yapılandırma sorunlarını doğrulayabilirsiniz:
- Kapsayıcının yalnızca olması gereken belirli kodu çalıştırabilmesini sağlamak ve aynı zamanda en dar izin kümesini (en az ayrıcalık olarak da adlandırılır) doğrulayabilmesi için aşırı ayrıcalıklı kapsayıcılar.
- Tüm isteklerin olası kod enjeksiyonları için doğrulanmasını sağlamak için API yapılandırmaları ve uç noktalara erişim.
- Konteynerlerin beyaz adres listesine çıkış çağrısı erişimine sahip olmadığından emin olmak için kod çalıştırıcılar taranıyor.
Diğer statik analiz araçları gibi, bu araçlar da dağıtılan her yapılandırmanın en güvenli yapılandırma olmasını, değişikliklerin izlenmesini ve insan hatası faktörünün olabildiğince sıfıra indirilmesini sağlayan otomatikleştirilmiş CI/CD ardışık düzenleri oluşturmayı çok kolaylaştırır.
5. Yerel Makinelerde Kod Çalıştırmayın ve En Düşük Ayrıcalığı Kullanın
*4Shell güvenlik açıklarının verebileceği en büyük hasar, bu işlemleri (sanal) bir makinede standart işlemler olarak çalıştırmanızdır. Konteynerlerde kod çalıştırmak, mevcut çalışan ortama verilen zararı en aza indirir ve konteyner için çok dar bir izin ve ayrıcalık kümesini korumanıza olanak tanır.
Yalnızca gerekli işlemlerde çalışacak kapları izleyerek ve uygulamaları çalıştıran kullanıcıları yalnızca gerekli izinlerle sınırlandırmanın yanı sıra, saldırganların sızmak isteyeceği hassas alanlara herhangi bir etkide bulunmamasını sağlayabilirsiniz.
Tüm uygulamalarınızı kapsayıcılarda ve diğer standart buluta özgü yöntemlerle çalıştırmak, çalışan tüm uygulamaları kapsayan merkezi bir ağ ve ayrıcalık yapılandırması tanımlamanıza yardımcı olur ve kolayca kötüye gidebilecek manuel yapılandırmalardan kaçınır.
Mimariniz ölçeklendiğinde, her şeyin gerçek zamanlı olarak doğru bir şekilde tanımlandığından emin olmak için Wiz, Orca gibi araçları ve diğer bulutta yerel güvenlik gözlemlenebilirlik araçlarını kullanabilirsiniz.
6. Dinamik API Taramasını Kullanın
gibi DAST araçlarını kullanma ZAP, hangi uygulamalarınızın Text4Shell’e karşı gerçekten savunmasız olduğunu öğrenebilirsiniz. Bu, güvenlik açığı bulunan çok sayıda uygulamanız varsa ve bunları düzeltmeye öncelik vermenizi mümkün kılıyorsa veya kaynak koduna erişmeniz gerekiyorsa yararlı olabilir. ZAP Text4Shell Tarama Kuralı şu anda isteğe bağlı Alfa’da Aktif Tarama Kuralları eklentisi ve bir gerektirir OAST hizmeti çalışmak için.
Daha Hızlı Güvenlik == Geliştirme Hızı
İstismarların ortadan kalkmasını bekleyemeyiz ve yeni *4Shell veya başka herhangi bir sıfır günün ortaya çıkması bizi şaşırtmamalı. Yapabileceğimiz şey, doğru korkuluklara ve kontrollere sahip olmak, böylece zaten çıkmaza girmiş olan geliştirme süreçlerimize çok fazla zarar vermeden bunları hızlı bir şekilde keşfedebilir ve düzeltebiliriz.
Bugün harekete geçerek, yarın hazırlıksız yakalanmaktan ve mühendislik teslimatını kesintiye uğratmaktan esasen kaçınırsınız. CI/CD ve yığınlarımızla iyi bütünleşen mükemmel açık kaynaklı güvenlik araçlarının olduğu bir çağda olma ayrıcalığına sahibiz ve bunları mümkün olduğunca sık kullanmak için çaba göstermeliyiz. Üstelik bu artık alan uzmanlığı gerektirmiyor; Bunu sizin için yapacak çok sayıda DevSecOps aracı (ve yukarıda belirtildiği gibi açık kaynak araçları) ve hatta bunun için ödeme yapmaya istekli olanlar için bu işi uçtan uca yönetecek SaaS tabanlı teklifler var. Evinizi yabancılara açık bırakmayın. Kolay şeylerle başlayın – ön kapıyı kilitleyin.