AWS Güvenlik Açığını Tespit Etmeyen IR Politikaları Risk Taşıyor

AWS altyapısında güvenlik ve uyumluluk denetimleri genellikle otomatikleştirilir. Ancak, bu sistemler yanlış yapılandırıldıklarında veya kötü niyetli bir şekilde manipüle edildiklerinde, saldırganlara kalıcı erişim sağlayabilecek birer arka kapıya dönüşebilir. Peki, standart müdahale süreçleri (IR) neden bu tehdidi tespit edemiyor ve nasıl önlem alabilirsiniz?

Standart IR Süreçlerinin Kör Noktası

Çoğu kuruluşta, AWS Config kuralları kullanılarak kaynakların uyumluluğu otomatik olarak denetlenir. Örneğin, bir S3 kovasının politika olmayan durumunu tespit eden bir kural çalıştırılır ve bu kurala bağlı bir SSM Otomasyon belgesi, uygun olmayan kaynağı düzelterek uyumluluğu sağlamaya çalışır. Bu yaklaşım AWS Well-Architected Framework tarafından da önerilir ve güvenlik ekipleri tarafından güvenilir bir yöntem olarak kabul edilir.

Ancak, bu sistemin en büyük zayıflığı, kural mantığının doğru olup olmadığının denetlenmemesidir. Saldırganlar, bu zayıflıktan faydalanarak, aslında uyumluluğu sağlamak yerine güvenlik açıklarını koruyan veya hatta artıran bir kural mantığı oluşturabilirler. Örneğin, bir kuralın mantık fonksiyonunu tersine çevirerek, bir S3 kovasının politika içermesi durumunda "uyumsuz" olarak işaretlenmesini ve ardından SSM Otomasyonu tarafından bu politikanın otomatik olarak silinmesini sağlayabilirler.

Self-Healing Döngüsü: Saldırganın En İyi Dostu

Saldırganlar, AWS Config ve SSM Otomasyonu arasındaki bu otomatik düzeltme döngüsünü kötüye kullanarak kalıcı erişim sağlayabilirler. İşte nasıl çalıştığı:

1. Başlangıç Durumu: Saldırgan, kurbanın AWS hesabına giriş yapar ve bir S3 kovasının güvenlik politikasını kaldırır. Ardından, bu kova için bir AWS Config kuralı oluşturur ve bu kurala bağlı bir SSM Otomasyon belgesi hazırlar.

1. Tersine Çevrilmiş Mantık: Kuralın Lambda fonksiyonu, kovanın politika içermesi durumunu "uyumsuz" olarak işaretler. Örneğin:

def lambda_handler(event, context):
    invoking_event = json.loads(event['invokingEvent'])
    bucket = invoking_event['configurationItem']['resourceName']
    has_policy = check_bucket_policy(bucket)  # Kovanın politika içermesi durumunu kontrol eder
    compliance = "NON_COMPLIANT" if has_policy else "COMPLIANT"  # Tersine çevrilmiş mantık
    return put_evaluation(bucket, compliance)

1. Otomatik Düzeltme: SSM Otomasyon belgesi, uyumsuz olarak işaretlenen kovanın politikasını otomatik olarak siler. Bu işlem, saldırganın ilk yaptığı değişikliği geri alır ve kova yeniden savunmasız hale gelir.

1. Sonsuz Döngü: Bu süreç, sürekli olarak tekrarlanır. Güvenlik ekipleri, bu "çelişkili otomasyon" nedeniyle kaynakların sürekli olarak değiştirildiğini fark eder, ancak kökenini tespit edemezler. Bu arada, saldırganın kalıcı erişimi de devam eder, çünkü bu süreç hiçbir kullanıcı kimliğine bağlı değildir — sadece AWS hizmet rollerini kullanır.

Saldırganın İzini Nasıl Sürülür?

Standart IR süreçleri, saldırganın AWS hesabından tüm erişimlerini kaldırsa bile, bu otomatik döngü devam eder. Çünkü:

• AWS Config ve SSM Otomasyonu, hizmet rollerini kullanır, kullanıcı kimliklerini değil.
• Saldırganın hesaptan tamamen çıkarılması, bu rollerin çalışmasını engellemez.

Buna ek olarak, saldırganlar, mevcut bir AWS Config kuralını veya SSM belgesini gizlice değiştirerek de bu tehdidi uygulayabilirler. Örneğin, saldırgan, UpdateFunctionCode ve UpdateDocument API'lerini kullanarak, kuralın Lambda fonksiyonu veya SSM belgesinin içeriğini değiştirebilir. Bu değişiklikler, kuralın adı, sahibi, roller ve etiketleri gibi görünür özelliklerinde herhangi bir değişiklik yapmaz. Bu nedenle, saldırıyı tespit etmek oldukça zordur.

Tehdit Modeli: İlk Erişim Değil, Kalıcı Erişim

Burada dikkate alınması gereken önemli bir nokta, saldırganın ilk erişimi elde etmek için bu yöntemi kullanmadığıdır. Bu yöntem, saldırganın hesaptan çıkarılmasından sonra kalıcı erişimi sürdürmek için kullanılır. Yani, saldırganın hesabı temizlendiğinde, bu otomatik döngü sayesinde saldırganın erişimi yeniden oluşturulabilir.

Çoğu kuruluşun IR süreçlerinde, AWS Config kural mantığının denetlenmesi yer almaz. Bu, saldırganlar için altın bir fırsat yaratır. Bu nedenle, güvenlik ekipleri, AWS Config kurallarını düzenli olarak denetlemeli ve olası tersine çevrilmiş mantıkları tespit etmelidir.

Tehdidi Tespit Etmek için Kullanılabilecek Araç: Mirage

Bu tehdit vektörünü tespit etmek için geliştirilen Mirage aracı, AWS Config kurallarını yedi farklı heuristik kriterine göre değerlendirir. En güçlü tespit yöntemi, davranışsal analize dayanır:

• Bir mühendis bir kaynağı sertleştirir (örneğin, S3 kova politikasını ekler).
• SSM Otomasyonu, aynı kaynağı 5 dakika içinde zayıflatır (örneğin, politikanın kaldırılması).

Mirage, bu tür olayları CloudTrail kayıtlarından çıkarır ve iki olay arasındaki ilişkiyi analiz eder. Sadece bu iki olayın zaman yakınlığı değil, aynı zamanda kaynak kimliğinin de eşleşmesi gerekir. Bu şekilde, yanlış pozitiflerin sayısı önemli ölçüde azalır.

Mirage Nasıl Kullanılır?

Mirage, AWS Config kurallarını denetlemek için güvenli ve salt okunur bir yöntem kullanır. Kullanımı oldukça basittir:

pip install -e .
mirage detect --verbose

Bu komut, her bir AWS bölgesindeki tüm Config kurallarını analiz eder ve şüpheli kuralları CRITICAL, HIGH veya MEDIUM seviyelerinde puanlandırır. Raporlama süresi, bölgeye bağlı olarak yaklaşık beş dakika sürer.

Önemli Not: Mirage'ı yalnızca test ortamlarında kullanın. Çünkü araç, saldırganın kullanabileceği gerçek kalıcılık yöntemlerini (örneğin, AdministratorAccess rolünü yeniden ekleme veya KMS anahtar politikasına wildcard ilave etme) tespit edebilir. Bu yöntemler, gerçek bir saldırganın kullanabileceği araçları simüle eder.

Sonuç: IR Politikalarınızı Gözden Geçirin

AWS Config kuralları ve SSM Otomasyonu, güvenlik ve uyumluluk süreçlerinde kritik bir rol oynar. Ancak, bu sistemlerin doğru şekilde yapılandırılmaması ve düzenli olarak denetlenmemesi, saldırganlara kalıcı erişim sağlayabilecek birer arka kapıya dönüşebilir. Eğer IR süreçlerinizde AWS Config kural mantığının denetlenmesi yer almıyorsa, sisteminizin bu tehdit vektörüne karşı savunmasız olduğunu kabul etmek gerekir.

Mirage gibi araçlar, bu tehdidi tespit etmek ve önlemek için ilk adımdır. Güvenlik ekiplerinin, AWS altyapısında kullanılan otomatik süreçleri düzenli olarak gözden geçirmeleri ve olası tersine çevrilmiş mantıkları tespit etmeleri kritik önem taşımaktadır. Unutmayın, kalıcı erişim sağlamanın en iyi yollarından biri, sisteminizin kendi kendini onaran bir arka kapıya dönüşmesini sağlamaktır.