[ Kimlik sahteciliği ve kimliğin kötüye kullanılması ]

Bildirilen bir DMARC atlamasını gerçek güven sınırına göre değerlendirin

İlgili politikayı, yetkilendirmeyi veya alıcı sınırını tam olarak bularak bir DMARC bypass iddiasını test edin.

EmailAuth araştırma ekibi tarafından · 3 dakikalık okuma

[ Anahtar noktalar ]

  • İlgili politikayı, yetkilendirmeyi veya alıcı sınırını tam olarak bularak bir DMARC bypass iddiasını test edin.
  • Bir arızayı atamadan önce aşırı yetkilendirmeyi, güvenilir kimlik doğrulama sonuçlarını ve alıcı işlemlerini ayırın.
Bu sayfada

İfade DMARC bypass çok farklı olayları tanımlayabilir. Aşırı yetkili bir kaynaktan geçerli bir geçiş, başarısız sonuca rağmen teslimat ve uygulama hatası aynı başarısızlık değildir. Yanlışlanabilir bir iddiayla başlayın: Hangi kimlik ileri sürüldü, hangi kanıtlara güvenildi ve hangi karar beklenen kuraldan farklıydı?

Gözlemlenen kararı yeniden oluşturun

Yazar etki alanını, zarf etki alanını, imzalama etki alanlarını, güvenilir kimlik doğrulama sonuçlarını ve alıcı düzenini koruyun. Politikayı ve gözlem süresini kaydedin. Teslim edilen bir mesaj tek başına DMARC geçişini kanıtlamaz. Alıcı işlemleri yerel politikayı içerir ve alan sahibinin talep ettiği işlem evrensel bir teslimat garantisi değildir. RFC 9989.

Aynı şekilde kopyalanmış Authentication-Results string, alıcı sistemin kararının kanıtı değildir. Güvenilir kimlik doğrulama hizmetini ve ilgili sekmeyi oluşturun. RFC 8601. Tek kanıt, geçti yazan bir ekran görüntüsü ise, temeldeki kimlikler ve güven bağlamı mevcut olana kadar talebi çözümlenmemiş olarak koruyun.

Aşırı yetkilendirmeyi kural kaçırmadan ayırın

BreakSPF ne kadar hoşgörülü olduğunu araştırıyor SPF yetkilendirme ve paylaşılan altyapıya erişim izin verebilir sahtekarlık. Tehdit modeli, saldırgana uygun bir kaynak yolu sağlar; alıcı daha sonra yayınlanan yetkilendirmeyi yazılı olarak değerlendirebilir. BreakSPF, Bölüm III.A ve Şekil 3.

Saldırganın kontrol ettiği kaynak yetkilendirilmiş bir aralıktaysa ve hizalanmış bir zarf kimliği kullanıyorsa sıradan geçiş kuralı başarılı olabilir. Zayıflık, DMARC yeni tanımından ziyade verilen yetki veya hizmet sınırındadır. Bunun tersine, yalnızca ilgisiz bir kimlik doğrulanırsa ve yazar alanı hizalanmazsa, talep edilen geçişin farklı bir açıklamaya ihtiyacı vardır.

Üç varsayımsal bulguyu sınıflandırın

alerts@brand.test görünür tek bir DMARC değerlendirmesinin olduğunu ve bunun dışında uygun bir DMARC değerlendirmesi olduğunu varsayalım. Bunlar yazılı hipotezlerdir, gözlemlenen olaylar değildir.

  • Yetkilendirme durumu: 192.0.2.99 kaynağı, öngörülen SPF ip4:192.0.2.0/24 aralığındadır; POSTA bounce@brand.test SPF geçer; HAYIR DKIM imzası. Hizalanmış SPF yolu, mesaj düzeyinde bir DMARC geçişi sağlar. Bu kaynağın gerçekten istenmeyen bir gönderen tarafından kontrol edilip edilemeyeceğini ve ona hangi sahibin yetki verdiğini sorun.
  • İşleme durumu: MAIL FROM bounce@other.test SPF geçer ve DKIM d=other.test passes, but assume neither aligns with brand.test. DMARC fails. If the trusted receiver record separately says delivered, investigate its handling policy; delivery alone has not changed the failed hizalama sonuç.
  • Kanıt durumu: kopyalanan bir başlık geçiş diyor ancak güvenilir alıcı kaynağı, değerlendirilen kimlikler ve uygulanan politika bilinmiyor. Ne bir protokol ihlali ne de güvenilir bir geçiş sağlanamadı. Orijinali ve alıcı tarafındaki kaydı isteyin.

Yetkili bir pozitif gönderici 192.0.2.10 ve bir dış kaynak 198.51.100.10 , ilk vakayı araştırırken önerilen kontrolleri sağlayabilir. Varsayımsal bir ip4:192.0.2.10/32 -all kayıtlar yalnızca ilkini kabul eder; Bu önek aritmetiğinden gerçek bir üretim değişikliği gelmez. Burada yürütülen hiçbir ayrıştırıcı, imza kontrolü veya istismar yoktur.

RFC9989 bölüm 7.4, alan adı yayınlama için geçerli DKIM gerektirir p=reject. Geçişli hizalanmış bir SPF mekanizması, belirli bir mesajın geçiş koşulu için yeterlidir, ancak yalnızca SPF'nin uygulanması için bir öneri değildir.

Bulguyu uygulanabilir hale getirin

Çoğaltılmış durumu ve hala eksik olan kanıtları adlandırın. Yararlı bir bulgu, belirli bir kaynağın belirli bir yetkiyle kabul edildiğini ve sorumlu sahibi tanımladığını söylüyor. Tüm DMARC korumasının bozulduğu söylenemez. Gerçek hizmetin kiracı kimliklerini kısıtlayıp kısıtlamadığını, kaynağın gerçekten kontrol edilebilir olup olmadığını ve alıcının iddia edilen sonucu uygulayıp uygulamadığını kontrol edin.

Önerilen bir hafifletmeyi test ederken zararsız, yetkili pozitif kontrolü koruyun. Aralığın daraltılması veya bağlayıcının değiştirilmesi meşru gönderenleri bozabilir. Rotaya özel değişiklik onayını ve değişiklik sonrası doğrulamayı zorunlu tutun ve sağlayıcının laboratuvarda test edilmemiş davranışını açıkça çözümsüz tutun. Bu, eğitim modelini üretimdeki bir güvenlik açığına kadar abartmadan kesin bir düzeltmeyi destekler.

[ Götürmek ]

Bir arızayı atamadan önce aşırı yetkilendirmeyi, güvenilir kimlik doğrulama sonuçlarını ve alıcı işlemlerini ayırın.

[ Role göre ]

Bu sizin için ne anlama geliyor?

Sonraki pratik adımlar için rolünüzü seçin.

BT / Posta Yöneticisi

Negatif kontrolleri koru

Yararlı bir test, izin verilen ve amaçlanmayan rotaları birbirinden ayırır.

Sonraki adımlar

  1. Değerlendirilen tanımlayıcıları yakalayın.
  2. Çalışan bir yasal gönderen vakasını saklayın.
  3. Test girişlerini ve çıkışlarını saklayın.

CISO / SecOps

Bulgunun kapsamı

Araştırma kanıtları ve kurumsal maruziyet ayrıdır.

Sonraki adımlar

  1. Savunulabilir bir tehdit modeli gerektirir.
  2. Riski kabul etmeden önce test edilmemiş varsayımları takip edin.
  3. Maruziyeti kapatmadan önce değişiklik sonrası kanıt isteyin.

Kurucu / Teknik Olmayan

Kesin bir iddia talep edin

Geniş bir baypas başlığı, düzeltilebilir kontrolü gizleyebilir.

Sonraki adımlar

  1. Gerçekte neyin çoğaltıldığını sorun.
  2. Hizmet riskini protokol anlamından ayırın.
  3. Çoğaltılmış sınırın sahibini atayın.

[ SSS ]

Sık sorulan sorular

Gelen kutusu teslimi DMARC bypassını kanıtlar mı?

Hayır. Kimlik doğrulama sonucunu alıcının konumundan ve yerel politikadan ayırın.

SPF çok fazla yetki verdiği için DMARC geçebilir mi?

Evet, geçen bir SPF kimliği yazarın etki alanıyla uyumluysa. Yetki sınırını araştırın.

İlgisiz SPF ve DKIM geçişleri hizalamayı karşılayabilir mi?

Sadece geçtikleri için değil. Kimliği doğrulanmış alan adlarının yazar alan adıyla gerekli ilişkiye sahip olması gerekir.

İstenecek ilk kanıt nedir?

Orijinal mesaj, güvenilir alıcı sonuçları, değerlendirilen kimlikler, politika bağlamı ve eğilimi.

Gerçek bir yetkilendirme testi hangi kontrolleri içermelidir?

Meşru bir onaylanmış kaynak ve izin verilen kümenin dışında kalan, yetkili girdileri ve gözlemlenen sonuçları içeren bir kaynak.

Burada minyatür bir SPF değerlendiricisi çalıştırıldı mı?

Hayır. Üç bulgu ve önek karşılaştırması yazılı varsayımlardır; yürütülen kimlik doğrulama veya yararlanma testleri değildir.

Mevcut bir sağlayıcı güvenlik açığı oluşturuldu mu?

Hayır. Gerçek bir hizmette kaynak kontrolü ve alıcı davranışı henüz test edilmemiştir.

Bir düzeltme nasıl doğrulanmalıdır?

Yetkili pozitif gönderen kontrolünü, hedeflenen negatif durumları ve rotaya özgü değişiklik sonrası gözlemleri kullanın.

[ Kaynaklar ]

Kaynaklar

  1. BreakSPF orijinal araştırması NDSS

    Bölümler III.A Saldırı modeli · Şekil 3 · VIII Tartışma

  2. RFC 7208 SPF

    Bölümler §2.4 · §5.6

  3. RFC 9989 DMARC

    Bölümler §4.4 · §5.3.5 · §5.4 · §7.4 · §8

  4. RFC 8601 Kimlik Doğrulama Sonuçları

    Bölümler §1.2 · §1.6 · §7

[ Sözlük ]

Sözlük

Negatif kontrol
Bir test senaryosunun araştırılan koşulu karşılamaması bekleniyor.
Mevki
Alıcının bir mesajı kimlik doğrulama sonucundan ayrı olarak işlemesi.

Kurumsal menşe

Neden en iyi finans kurumları ve hükümetler e-posta güvenlik kontrol panellerini kullanımdan kaldırdı.

Geleneksel e-posta kimlik doğrulama platformları size bir gösterge tablosu satar ve mühendislerinizden bu işi yapmalarını ister. Riskli ortamlarda, manuel gözetim, gecikmeli uygulama, konfigürasyon kayması ve izlenmeyen gölge alanlar anlamına gelir.

EmailAuth aracılı e-posta kaynak platformudur. Temsilcilerimiz uyguluyor p=reject, üçüncü taraf gönderenleri uyumlu tutun ve alan adlarınızı tam sürüme taşıyın RFC 9989 döngüdeki insan tarafından denetlenebilirliğe sahip yeni DMARC standardı uyumluluğu.

Hükümetler Büyük işletmeler 1. Seviye finans kurumları

SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi

Bilgi Bankası