Microsoft, Azure bulut platformunun dört ayrı hizmetindeki güvenlik açıklarını düzeltti; bunlardan ikisi saldırganların sunucu tarafı istek sahteciliği (SSRF) saldırısı gerçekleştirmesine ve dolayısıyla meşru bir hesapta kimlik doğrulaması olmadan bile potansiyel olarak uzaktan kod yürütmesine izin verebilirdi. araştırmacılar bulmuşlardır.
Orca Security araştırmacıları, 17 Ocak’ta yayınlanan bir blog gönderisinde SSRF’ye karşı savunmasız dört Azure hizmeti belirlediler: Azure API Management, Azure Functions, Azure Machine Learning ve Azure Digital Twins. Ayrıca, Azure’daki kusurlardan yararlanmayı başardılar. İşlevler ve Azure Digital Twins, bir Azure hesabında kimlik doğrulaması yapmak zorunda kalmadan sunucunun adına istekler göndererek, dediler.
Bir SSRF, bir saldırganın dahili kaynakları okumak veya güncellemek ve ayrıca harici kaynaklara veri göndermek için isteklerde bulunarak sunucu tarafı bir uygulamayı kötüye kullanmasına izin verir. Bu, tehdit aktörlerinin çeşitli saldırılar başlatması da dahil olmak üzere ağ üzerinde bir dizi yıkıcı etkinliğe izin verebilir.
Bu tür bir saldırı, saldırganlar ana bilgisayarın Bulut Örneği Meta Veri Hizmetine veya “ana bilgisayar adı, güvenlik grubu, MAC adresi ve kullanıcı- Orca Security’de bulut güvenlik araştırmacısı olan Lidor Ben Shitrit, blog gönderisinde “veri” dedi. Bu, saldırganların belirteçleri almasına, başka bir ana bilgisayara geçmesine ve hatta kod yürütmesine olanak tanır.
Yerleşik SSRF Hafifletmeleri
Neyse ki, Azure’da keşfedilen SSRF güvenlik açıkları söz konusu olduğunda, araştırmacılar, IMDS uç noktasına erişim için özel gereksinimlerin ayarlanması ve Uygulama Hizmeti ve Azure için bir “Kimlik Başlığı” gerektirmesi dahil olmak üzere çeşitli SSRF azaltmaları sayesinde IMDS uç noktalarına ulaşmak için bunlardan yararlanamadı. İşlevler – Microsoft’un zaten bulut ortamlarına yerleştirdiğini söylediler.
Shitrit, “Microsoft, bu önlemleri uygulayarak Azure platformunda SSRF saldırılarının potansiyel hasarını önemli ölçüde azalttı” diye yazdı.
Bununla birlikte, kusurların diğer tehdit faaliyetlerini gerçekleştirmek için hala kullanılmış olabileceğini söyledi. Shitrit, blog gönderisinde, yerel bağlantı noktalarını taramayı ve yeni hizmetler, uç noktalar ve dosyalar bulmayı, böylece “muhtemelen savunmasız sunucular ve hizmetler hakkında ilk giriş için yararlanılacak değerli bilgiler ve hedeflenecek potansiyel bilgilerin konumunu sağlamayı” içeriyor.
Dark Reading’e “En büyük çıkarım … bir bulut hizmetinin, düzgün bir şekilde güvence altına alınmadığı takdirde, kötü niyetli aktörler tarafından hassas dahili uç noktaları ve diğer hizmetleri keşfetme aracı olarak istismar edilebileceğidir” dedi. Shitrit, bunun önemli bir bulut güvenliği ihlaline yol açabileceğini söylüyor.
Araştırmacılar, Ekim ortası ile Aralık ortası arasındaki iki aylık bir süre boyunca dört kusuru ayrı ayrı keşfettiler ve keşfedildikten kısa bir süre sonra her birini Microsoft’a ifşa ettiler. Her durumda, şirket bunları ayrı ayrı azaltmak için günler veya haftalar süren hızlı bir şekilde yanıt verdi. Shitrit, şu anda müşterinin başka bir işlem yapmasına gerek olmadığını ve araştırmacıların kusurların açık havada kullanıldığına dair hiçbir işaret görmediğini söyledi.
Tam SSRF Potansiyeli
Araştırmacılar, üç tür SSRF hatası olduğunu söyledi. Kör SSRF, bir saldırganın istekte bulunmak için bir sunucuyu manipüle etmesine izin verir, ancak bir sunucudan yanıt almaz; bu da bir saldırının başarısının belirlenmesini zorlaştırır. Yarı-kör SSRF, sunucu isteklerinde bulunma yeteneği bakımından benzerdir, ancak bir saldırgan sunucudan, hedef sistemde sınırlı bilgi toplamaya izin veren bazı yanıtlar alır.
Araştırmacılar, araştırmacılar tarafından belirlenen dört Azure SSRF kusurunun, bir tehdit aktörü için en güçlü saldırı senaryosu türü olan kör olmayan veya tam SSRF olarak adlandırılan üçüncü SSRF kategorisine girdiğini söyledi.
Shitrit, bu tür bir saldırının, bir saldırganın istekte bulunmak ve sunucudan tam yanıt almak için bir sunucuyu manipüle edebildiği ve saldırganın potansiyel olarak daha fazla saldırı başlatmak için hedef sistem hakkında daha fazla bilgi toplamasına izin verdiği zaman meydana geldiğini söyledi.
“Size bu güvenlik açıklarının ne kadar istismar edilebilir olduğu hakkında bir fikir vermek için, kör olmayan SSRF kusurları, XXE aracılığıyla SSRF, SVG dosyası aracılığıyla SSRF, proxy aracılığıyla SSRF, PDF oluşturma yoluyla SSRF, savunmasız sorgu dizesi aracılığıyla SSRF dahil olmak üzere birçok farklı şekilde kullanılabilir. URL’de – ve çok daha fazlası,” diye yazdı blog yazısında.
Koruma ve Azaltma
Araştırmacılar, bir sunucuda ne tür SSRF güvenlik açığı bulunduğuna bakılmaksızın, her türün hassas bilgilere yetkisiz erişim elde etmek veya bir hedefe karşı başka saldırılar başlatmak için kullanılabileceğinden, kuruluşlar tarafından ciddi şekilde ele alınması gerektiğini söyledi.
Shitrit, blog gönderisinde “Bu nedenle, kuruluşların bu tür saldırıları önlemek için sunucularını ve ağlarını uygun şekilde güvenceye almaları önemlidir.”
Shitrit, güvenlik ekiplerine SSRF güvenlik açıklarından kaynaklanan riskleri azaltmak için iki özel öneride bulundu. Birincisi, “kullanıcı girdilerine asla güvenmemek” diyor, çünkü bu SSRF’yi gerçekleştirme girişimi olabilir, dedi.
Shitrit, Dark Reading’e “Bu durumda, sunucu tarafından gönderilen dahili isteklerin, dahili isteklere/uç noktalara ulaşmak için kullanıcı tarafından manipüle edilebileceğini gördüm, böylece istenmeyen konumlara ulaşabilirler” dedi.
İkinci azaltmanın, bir sunucuya katılabilecek URL’lerin bir izin verilenler listesi/beyaz listesi ayarlamak ve tanımlamak olduğunu söylüyor. Shitrit, bu, kötü niyetli bir kullanıcının bir isteği manipüle etmek için kimliği doğrulanmamış bir SSRF’ye dokunması durumunda uç noktanın “izin verilmedi” hatası döndürmesini sağlayacak.