Bir S3 bucket’ının AWS hesap kimliği nasıl bulunur

 (tracebit.com)
2 puan yazan GN⁺ 2024-02-27 | 1 yorum | WhatsApp'ta paylaş
  • Tracebit, genel ve özel S3 bucket’larının AWS Account ID’sini tahmin etmeye yarayan bir tekniği derliyor ve örnek bucket bucket-alpha üzerinden 123456789101 değerini geri çıkarıyor
  • Temel ipuçları, S3 için Interface VPC Endpoint politikasındaki s3:ResourceAccount koşulu ve isteğin kendi CloudTrail loglarına düşüp düşmediği
  • Özel bucket’larda nihai yanıt sürekli AccessDenied olsa bile, yalnızca VPC Endpoint politikasını geçen istekler CloudTrail’de göründüğünden sayı deseninin eşleşip eşleşmediği anlaşılabiliyor
  • Politika yayılımı ve CloudTrail gecikmesi nedeniyle basit tarama yaklaşık 40 * 12 dakika = 8 saat sürebiliyor; ancak aws:userid ve RoleSessionName kullanılarak 120 politika ifadesi ile paralel test yapıldığında bu süre 10 dakikanın altına iniyor
  • Bu teknik, StringLike ifadesinin s3:ResourceAccount üzerinde kısmi eşleşmeye izin vermesi sayesinde mümkün oluyor ve bazı etkinlikler bucket sahibinin CloudTrail’inde de görünebiliyor

Genel bucket tekniğinden yola çıkan genişletme

  • 2021’de Ben Bridts, genel S3 bucket’larının AWS Account ID’sini bulma yöntemini yayımladı
  • Tracebit’in yaklaşımı, bu fikrin çeşitli unsurlarını yeniden kullanırken odağını S3 bucket’larının Account ID’sini özel bucket’ları da kapsayacak şekilde bulmaya veriyor
  • Örnek çalıştırmada bucket-alpha için CloudTrail’de geçen oturum adları toplanarak sonunda 123456789101 geri çıkarılıyor

Mevcut genel bucket yönteminin neden işe yaradığı

  • Ben Bridts’in yöntemi üç koşulun birleşmesiyle çalışıyor
    • İsteğe IAM politikası uygulanabiliyor
    • Politikanın isteğe izin verip vermediği ya da onu engelleyip engellemediği çıkarılabiliyor
    • s3:ResourceAccount koşul anahtarında wildcard eşleştirmesi uygulanabiliyor
  • Genel bucket’larda politika isteği engellerse AccessDenied dönüyor, politika izin verirse istek başarılı oluyor; böylece politikanın geçilip geçilmediği kolayca ayırt edilebiliyor
  • s3:ResourceAccount değeri her seferinde bir basamak daraltılarak tüm arama alanı trilyonlardan yüzler seviyesine indiriliyor

Özel bucket’larda yanıta değil CloudTrail’e bakılıyor

  • Özel bucket’larda hangi politika uygulanırsa uygulansın, hedef bucket politikası nedeniyle nihai yanıt AccessDenied oluyor
  • Tracebit yöntemi, yanıt sonucunu değil isteğin kendi CloudTrail loglarında görünüp görünmediğini ölçüt alıyor
    • İstek CloudTrail’de görünüyorsa VPC Endpoint politikası izin vermiş, ardından bucket politikası tarafından reddedilmiş demektir
    • İstek CloudTrail’de yoksa VPC Endpoint politikası tarafından engellenmiştir
  • S3 için bir Interface VPC Endpoint oluşturulduğunda isteğe VPC Endpoint politikası uygulanabiliyor ve bu politika bucket politikası ile istek öznesinin IAM politikası gibi diğer politikalarla birlikte değerlendiriliyor
  • VPC Endpoint politikasında da StringLike wildcard’ları ve kaynak koşul anahtarları kullanılabildiği için aynı arama yaklaşımı uygulanabiliyor

Temel prosedür: bölgeyi doğrulamadan olay sorgulamaya

  • Önce hedef bucket’ın bölgesini bulmak gerekiyor
    • Bucket HTTP endpoint’ine curl gönderildiğinde istek yasak olsa bile x-amz-bucket-region başlığı döndürülüyor
    • Örnekte bucket-alpha.s3.amazonaws.com yanıt başlıklarında us-east-1 doğrulanıyor
  • Hedef bucket ile aynı bölgede bir VPC ve S3 için bir VPC Endpoint dağıtılıyor
    • VPC Endpoint, politika uygulanabilen Interface türünde olmalı
    • Bu VPC Endpoint, VPC içindeki S3 isteklerini etkilediğinden bu amaç için ayrılmış bir VPC oluşturmak iyi oluyor
  • VPC içinde S3 isteği göndermek için bir EC2 instance’ı çalıştırılıyor ve bu instance’ın S3 için ilgili VPC Endpoint’i kullandığı doğrulanıyor
  • VPC Endpoint politikası değiştirilerek s3:ResourceAccount değerinin belirli bir rakamla başlayıp başlamadığı test ediliyor
    • Örneğin Account ID’nin 0 ile başlayıp başlamadığını görmek için s3:ResourceAccount üzerinde "0*" koşulu kullanılıyor
  • EC2 instance’ından hedef bucket’a GetBucketAcl gibi bir Management isteği gönderiliyor
    • Management isteği kullanmak, CloudTrail ayarlarında ek işlem gereksinimini azaltıyor
    • İstek sonucu beklendiği gibi AccessDenied oluyor

Sayı desenini CloudTrail ile ayırt etme yöntemi

  • İstekten sonra CloudTrail’de GetBucketAcl olayının görünüp görünmediği sorgulanıyor
  • Olay görünüyorsa VPC Endpoint politikası isteğe izin vermiştir; dolayısıyla Account ID test edilen desenle eşleşiyordur
    • Örnek: "0*" koşulunda olay görünürse Account ID 0 ile başlıyordur
  • Olay görünmüyorsa VPC Endpoint politikası isteği engellemiştir; dolayısıyla ilgili desenle eşleşmiyordur
  • Olayın CloudTrail’de görünmesi birkaç dakika sürebildiğinden, olayın yok olduğuna karar vermeden önce 10 dakika beklemek öneriliyor
  • VPC Endpoint politikası değişikliklerinin tamamen yayılıp uygulanması da zaman aldığından, politika güncellemesinden sonra 5 dakika beklemek iyi sonuç veriyor

Otomatikleştirildi ama temel yöntem yavaş

  • Tracebit, bu süreci otomatikleştiren bir betik yazarak bucket’ın Account ID’sinin güvenilir biçimde bulunmasını sağladı
  • Her basamakta tüm rakamları tek tek denemek yerine, test sayısını azaltmak için ikili aramaya yakın bir yöntem kullanılıyor
    • Örneğin s3:ResourceAccount koşuluna ["0*", "1*", "2*", "3*", "4*"] gibi birden fazla desen konularak aralıklar bölünüyor
  • Buna rağmen politika uygulama süresi ve CloudTrail kontrolü için bekleme, darboğaz olmaya devam ediyor
    • İkili arama kullanılsa bile yaklaşık 40 * 12 dakika = 8 saat sürebiliyor
  • Birkaç saat süren örnek çalışmada bucket-alpha için Account ID olarak 123456789101 başarıyla bulunuyor

120 politika ifadesiyle 10 dakikanın altına inme

  • Daha hızlı yöntem, VPC Endpoint politikasına olası tüm basamak-rakam kombinasyonlarını önceden yerleştirmek
  • Politikada toplam 120 ifade bulunuyor
    • AWS Account ID’sinin her konumu için olası 10 rakam test ediliyor
    • Her ifade, s3:ResourceAccount için belirli bir konum desenini ve aws:userid koşulunu birlikte kullanıyor
  • aws:userid koşulu, STS AssumeRole çağrısında serbestçe belirlenebilen RoleSessionName değerini eşleştirmek için kullanılıyor
    • Belirli bir RoleSessionName ile rol üstlenildiğinde, belirli bir basamak-rakam testine karşılık gelen politika ifadesi seçici olarak geçirilebiliyor
  • Bu politika, VPC Endpoint politikası için izin verilen azami karakter uzunluğuna ancak sığıyor
  • Tüm 120 olasılık paralel test edildiği için politikayı her seferinde değiştirme ya da CloudTrail sonuçlarını tek tek bekleme ihtiyacı azalıyor
  • Bu yaklaşımla Account ID arama süresi 10 dakikanın altına düşüyor

Görünürlük kapsamı ve olası uygulamalar

  • Bazı etkinlikler hedef bucket sahibinin CloudTrail loglarında görünebilir
  • Tracebit, yayımlamadan önce AWS Security ekibi ile görüştü
  • AWS Account ID’nin hassas bilgi sayılıp sayılmadığı konusunda zaten çok tartışma vardı ve örnek CloudTrail olayında üçüncü taraf Account ID HIDDEN_DUE_TO_SECURITY_REASONS olarak gizlenmiş durumda
  • Aynı teknik, bucket ile ilişkili başka kaynak koşul anahtarlarına da uygulanabilir
    • Örnek: aws:ResourceOrgID
    • Örnek: aws:ResourceOrgPaths
    • Örnek: aws:ResourceTag
  • S3 dışında, bu tekniğin uygulanabildiği başka servislerde de kullanılabilir
  • Tüm bölgelerde birbirine peered VPC’ler ve VPC Endpoint’ler oluşturulursa, hedef bucket’ın bölgesinden bağımsız çalışan bir yapı kurmak mümkün olabilir
  • Bu teknik, s3:ResourceAccount koşulu üzerinde StringLike ile kısmi eşleşme kullanılabildiği için mümkün
  • VPC Endpoint politikası tarafından reddedilen olaylar da CloudTrail’e kaydedilse faydalı olabilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-02-27
Hacker News yorumları

  • s3:ResourceAccount koşul anahtarına wildcard eşleştirme uygulanabilmesi gerçekten tuhaf
    Hesap kimliğinin kısmi eşleşmesine göre izin vermek veya reddetmek için geçerli bir neden yok gibi görünüyor

    • AWS politika yürütmede birden çok operatör ve operand var; bu durumda hesap kimliği dizesinde StringLike kullanılan bir yapı olduğu için böyle sanırım
      DevOps tarafında artık yan kanal saldırılarının keşfediliyor olması biraz ilginç. CPU’nun spekülatif yürütme yan kanalları olan Meltdown ve Spectre da ilk keşfedildiklerinde büyük yankı uyandırmıştı; ondan önce de güç analizi, manyetik bozulma tespiti ve sabit zamanlı kriptografi gibi alanlar vardı
      https://en.m.wikipedia.org/wiki/Side-channel_attack
      https://en.m.wikipedia.org/wiki/Power_analysis
    • Ben de o kısma şaşırdım. Bu alanın tam eşleşme dışında hiçbir şeye izin vermemesi gerekir gibi geliyor; hesap kimliğinde desen eşleştirme kullanmak için bir senaryo aklıma gelmiyor
    • Muhtemelen genelleştirme eğiliminden çıkmış gibi
      Yakın zamanda bir yan projede, OWL’den esinlenen bir biçimde sorgu yazma özelliği yaptım; URL’den host çıkarma, önek sorguları, like sorguları, regex sorguları vb. yapan bir ilişkisel operatör kütüphanesi var
      Yan projemin başka bir yan projesi olduğu için kolayıma geldiği gibi yaptım ve mantıklı olmayan durumlarda bile operatörlerin her zaman kullanılabilmesine izin verdim. Sayılar üzerinde regex sorgusu yapınca ne olur bilmiyorum ve umursamıyorum. AWS içinde de benzer bir şey olabilir; ama kullanıcı sayısı çok olan ve güvenlik açısından hassas bir sistemde standart farklı olmalı
    • Unix sistemlerinde grup kimliğinin bit alanını eşleştirmeye benziyor
      Birisi böyle bir fikir bulup kendini zeki sanabilir, ama %100 kontrol etmediğiniz bir sisteme bunu uygulamak aptalca görünüyor

  • Genel olarak hesap kimliğini herkese açık şekilde ortalığa saçmazsınız, ama bir gün bir kısmının açığa çıkacağını varsaymak gerekir
    Daha fazla üçüncü taraf tedarikçi ve SaaS platformu, IAM kullanıcıları ve erişim anahtarları yerine rol devrini tercih eden entegrasyon yöntemlerine geçiyor; doğrusu da bu. O zaman en azından entegrasyon noktası olarak kullanılan hesabın hesap kimliği diğer taraflara bilinir; onların tarafında da bağımlılıklar, açıklar vb. vardır

    • Bunu merak ediyorum. Bir saldırgan AWS hesap kimliğiyle ne yapabilir? Birinin e-posta adresini bilmekten farkı ne?

  • AWS hesap kimliği IP adresine benzer. Hassas olabilir, ama iş yapabilmek için birilerinin bilmesi gerekir
    Örneğin 1-2 yıl önce kara para aklamayı önleme süreçleri nedeniyle entegre olmamız gereken bir üçüncü taraf vardı. Genelde herkese açık SFTP portundan daha güvenli olduğu için o kuruluşla PrivateLink kurmayı önerdik; karşı şirket ise hesap kimliğini gizlemeleri gerektiği yönündeki güvenlik gerekçesiyle reddetti. Karşılıklı yetkilendirme için PV endpoint’inin rol ARN’sinde gerekli olmasına rağmen böyle yaptılar
    Sonunda inbound 22 numaralı portta kullandıkları herkese açık IP aralığını allowlist’e ekledik
    Alınacak ders şu: Kimliği obfuscate edip kendinizi zeki sanabilirsiniz, ama karşı tarafın geri döneceği adresi bilmiyorsanız iş yürütmek zordur

    • AWS PrivateLink’in bu tür entegrasyonlar için onu genelde istenmeyen kılan bir özelliği daha var. İletişim çift yönlüdür ve IP subnet’leri çakışmamalıdır
      Biz tedarikçi tarafında genelde VPC Endpoint Service ile entegre oluyoruz. Bu yöntemde iletişim tek yönlüdür ve hizmetimiz müşteri VPC’si içindeki load balancer endpoint’i olarak açığa çıkarılır

  • İlgilenenler için kodu buraya koydum: https://github.com/tracebit-com/find-s3-account

  • İlginç bir keşif olduğu kesin, ama başlığı görünce biraz daha doğrudan bir yöntem olduğunu sanmıştım
    AWS’de yönetici hesabıyla organizasyon içinde “X kaynağı nerede” diye basitçe sorup belirli bir S3 bucket’ının hangi hesapta olduğunu hızlıca öğrenebilmek güzel olurdu. Diğer kaynaklar için de öyle, ama S3 bucket’ları özellikle büyük mesele
    Açıkçası bu daha çok daha iyi uygulamalar ortaya çıkmadan önceki legacy bucket’larda veya tüm bucket’ların kodla tanımlanmasından önce var olanlarda yaşanan bir sorun. Yine de çok sayıda AWS hesabınız varsa bilinmeyen hesap ve region’lardaki kaynakları bulmak sıkıcı hale gelebilir

    • Organizasyon için AWS Config aggregator kurarsanız, tüm organizasyon hesaplarının kaynak envanterini Athena SQL ile sorgulayabilirsiniz
      Böylece bir kaynağın hangi hesap tarafından sahiplenildiğini bulmak kabaca select accountId where arn = "x" gibi bir şeyle mümkün olur

  • Global namespace’e sahip diğer herkese açık AWS kaynakları da AWS hesap kimliğini açığa çıkarır
    https://blog.plerion.com/conditional-love-for-aws-metadata-e...

  • Biraz bağlantılı olarak, Cloudflare account_id ve zone_id herkese açık olsa da güvenlidir
    https://github.com/cloudflare/cloudflare-docs/issues/474
    https://community.cloudflare.com/t/api-zone-id/355566

    The Zone ID and Account ID are not sensitive. Sensitive data like account API Key, Secrets etc. can all be revoked, rotated or changed. See the comment 36 below on the Wrangler repo: as per our security team, it’s completely Fine to have your zone_id and account_id public, the Global API key and associated email address should be kept secret.

    • AWS hesap kimliği de herkese açık olsa da güvenlidir
      Ancak bununla yapılabilecek şeylerden biri korelasyon kurmaktır. Aynı AWS hesabında birden fazla S3 sitesi işletiyorsanız, insanlar bunların aynı hesapta barındırıldığını görebilir. Bunun önemli olup olmadığı tehdit modelinize bağlıdır
    • CF hesabı için Gmail'in + özelliğini kullanarak kolayca tahmin edilemeyen, tamamen benzersiz bir e-posta adresi oluşturuyorum
      Kusursuz değil ama bir soyutlama katmanı daha ekliyor

  • Bununla bağlantılı olarak, AWS key ID, gizli anahtar kısmı olmasa bile içinde hesap kimliğini bir bit kaydırılmış biçimde barındırır
    https://medium.com/@TalBeerySec/a-short-note-on-aws-key-id-f...
    Bu key ID, S3 ön imzalı URL'lerine dahil edildiği için, muhtemelen hesap kimliğini zaten açığa çıkarıyordunuz

    • Bu başlıkta epey kişinin AWS key ID'yi gizlilik yoluyla güvenlik ya da derinlemesine savunmanın bir parçası olarak varsaydığı görülüyor
      Muhtemelen downvote alacak ama yine de okuyorsanız, bu, gizlilik yoluyla güvenliğin neden iyi bir savunma olmadığını gösteren bir örnek. Siz bir şeyi kaçırırsınız, inatçı bir saldırgan kaçırmaz
      Gizliliğe dayanmayan güvenlik, saldırgan örneğin AES-256'yı doğrudan kıracak bir dâhi tutmadığı sürece, benim bir şeyi anlayıp anlamamamdan bağımsız olarak geçerlidir: https://www.youtube.com/watch?v=KEkrWRHCDQU

  • Bu neden önemli olabilir? Net bir örnek olarak, prodüksiyon bucket verildiğinde artık aynı kuruluşun geliştirme bucket'larını bulmak mümkün olur. Kişisel olarak bu beklenen bir davranış değil

    • Yalnızca prodüksiyon ve geliştirme için aynı hesabı kullanıyorsanız doğru. Aynı hesabı kullanmamak için bir neden daha
    • Bunu yapmak için yalnızca bucket adına ihtiyaç var
      Bu tür listeleme denemelerini engellemek için bucket adına rastgele oluşturulmuş bir önek veya sonek eklemek gerekir. Ayrıca bunun yerine değil ek bir önlem olarak, bucket nesnelerini varsayılan host adı yerine başka bir adla herkese açıp bucket adının kendisinin sızmamasını sağlamak da iyi bir yöntemdir
    • Bu nasıl oluyor? Önce geliştirme bucket'ının adını bilmek gerekmiyor mu?
    • Geliştirme bucket'ı bir şekilde aynı hesapta olmadığı sürece pek olası değil

  • While account IDs, like any identifying information, should be used and shared carefully, they are not considered secret, sensitive, or confidential information.
    https://docs.aws.amazon.com/accounts/latest/reference/manage...

    • En azından dijital dünyada bilgi ya herkese açık ya da özel gibi görünüyor. Yetki gerektiren bilgi ya da korunan bilgi kavramı pek iyi değil
      Örneğin ev adresim teknik olarak herkese açık bilgidir, ama aile fotoğrafımla birlikte otoyol kenarındaki bir reklam panosuna nerede yaşadığımın yazılmasını kesinlikle istemem. Bunu yalnızca ihtiyacı olan kişilere veririm ve genel olarak gizliye yakın tutulacağını ya da kullanımının sınırlandırılacağını varsayar ve beklerim
    • Bu ne anlama geliyor?
      Gizli, hassas ya da mahrem değilse neden dikkatli paylaşmak gerekiyor?
    • “Gizli, hassas veya mahrem bilgi olarak kabul edilmez” ifadesinin “bizim ölçütlerimize göre” diye yazılması gerekir gibi
      Kullanıcılar bunu farklı görebilir