Geniş kapsamlı S3 imzalı upload policy'leri tarayıcıya prefix altındaki herhangi bir key'e yazma izni veriyor

Dört HackerOne raporunun arkasındaki desen

İmzalı POST policy'leri, bir tarayıcının dosyayı doğrudan S3'e yüklemesini, byte'ların uygulama sunucusundan geçmesi gerekmeden sağlar. Sunucu bir policy dokümanını imzalar, tarayıcı dosyayı bu imzayla birlikte gönderir ve S3, policy'nin izin verdiği her şeyi uygular. Bir dev.to analizine göre,整个 güvenlik bu dokümanın tek bir satırına dayanıyor: object key'i kısıtlayan koşul.

Yazı, aynı işleyişsel şekli paylaştığını söylediği dört HackerOne raporunu inceliyor:

• Shopify 93691: imzalı bir upload policy, tek bir kesin key'e sabitlemek yerine key'leri starts-with $key files/ ile eşleştiriyordu.
• Shopify 98819: kimlik doğrulamalı S3 okuma erişimi geniş bir policy-yazma kapsamıyla eşleşmişti ve policy'nin kendisi kimliği doğrulanmış herhangi bir kullanıcı tarafından değiştirilebiliyordu.
• Shopify 94502: birkaç bucket, birden fazla key üzerinde herkese açık okuma, listeleme ve yazma izinleriyle açığa çıkmıştı.
• BCM 764243: bucket düzeyindeki yazma kapsamı o kadar genişti ki tek bir erişim noktası, bir supply-chain saldırısı için implant konumu haline gelmişti.

Bir prefix modeli neden bozuyor

Policy'de ["starts-with", "$key", "files/"] bulunduğunda, files/ ile başlayan her key serbesttir. Uygulama files/abc-uuid/photo.png gibi bir şey bekler, ancak koşul aynı şekilde şunları da kabul eder:

• files/admin.html, bucket'ın önündeki her neyse onun tarafından statik asset olarak sunulacak
• files/../etc/passwd, S3 için zararsız ama downstream kodu key'i naif bir şekilde dosya sistemi yoluna birleştirirse riskli
• files/customer-data-dump.csv, saldırganın üzerine yazabileceği alakasız bir object

dev.to yazısı çizgiyi basitçe çekiyor: bir prefix koşulu sınırlaması zor bir key ailesini yetkilendirirken, exact match tam olarak bir key'i yetkilendiriyor — ve tek bir key hakkında akıl yürütmek son derece kolaydır.

Çözüm

Upload controller'da yapılacak iki değişiklik bu açığı kapatır. Birincisi, sunucu key'in tamamını kendisi oluşturur ve kullanıcı ID'si ile yeni bir UUID'yi gömer, örneğin files/{user_id}/{uuid}/{filename} gibi. İkincisi, policy, prefix koşulunu bu key üzerindeki exact match ile değiştirir: {"key": key} ve content-length-range gibi kısıtlamaları korur. Böylece her imzalı form, sunucu tarafında seçilmiş tek bir belirli object'i yetkilendirir ve başka hiçbir şeyi değil. Yazının değişmezi nettir: her imzalı S3 upload policy'si bir prefix'e değil, kesin bir object key'e bağlanmalıdır.

Tespitten kanıta

Analiz daha sonra düzeltmeden araçlara geçiyor. Yazıda tartışılan Stave framework'ü, upload policy'sini bucket'tan ayrı kendi asset türü olarak modelliyor; çünkü güvenlik açlığı bucket ayarlarında değil, policy sözleşmesinde yaşamaktadır. CTL.S3.WRITE.SCOPE.001 adlı, yüksek şiddet dereceli bir control, prefix modunda çalışan herhangi bir write-mode policy'yi işaretler.

Bu control bir state assertion'dır: konfigürasyonun güvensiz olduğunu söyler ama bir saldırganın gerçekte ne elde ettiğini değil. Bu nedenle yazar takip sorusunu Z3 solver'da kodluyor — policy'nin kabul ettiği ama uygulamanın key üretecinin asla üretmeyeceği bir key var mı? Üç tanık key bu alanı temsil eder: amaçlanan UUID tabanlı bir key, files/admin.html ve bir traversal tarzı key. Prefix modunda solver SAT döner ve files/admin.html somut bir karşı örnek olur. Exact-key düzeltmesinden sonra ise UNSAT döner; yani kabul edilen hiçbir key amaçlanan kümenin dışına çıkmaz, dolayısıyla çözüm tek bir vakayı değil, tüm problem sınıfını kanıtlanabilir şekilde ortadan kaldırır.

Daha geniş metodolojik iddia şudur: CEL gibi kural motorları bir konfigürasyonun izinci olup olmadığını yanıtlarken, solver witness extraction, hangi belirli key'ler hakkında izinci olduğunu söyler. Somut bir tanık, belirsiz bir bulguyu bir raporda gösterilebilir etkiye dönüştüren şeydir. Yaklaşımı başka bir saldırı sınıfına — örneğin farklı bir kiracının prefix'i altına yazmaya — genişletmek, yeni bir program yazmak değil, yeni bir predicate yazmak demektir.

Neden önemli

Doğrudan S3'e upload, stack'ler genelinde varsayılan bir desendir ve bu hata sıradan bir Rails, Express veya Django controller'daki tek bir satırdır. Fonksiyonel testler bunu ortaya çıkarmaz, çünkü meşru upload'lar başarıyla devam eder; policy yalnızca prefix altındaki diğer her şeyi reddetmekte başarısızdır. Etki alanı gerçektir, alıntılanan raporların gösterdiği gibi — üzerine yazılan object'ler, cross-feature yazımlar ve bir supply-chain ihlali. Düzeltme ucuz ve mekaniktir: key'i sunucu tarafında üretin ve policy'yi tam olarak ona bağlayın. Ve bu iki adımlı metodoloji AWS'nin çok ötesine taşınır — bir konfigürasyonun güvensiz olup olmadığı sorusunu, bir saldırganın gerçekte neye erişebileceği sorusundan ayırın, çünkü ikinci cevap, bir bulguyu eyleme dönüştüren şeydir.