SpamChannel: 2 milyondan fazla alan adından sahte e-posta gönderip fiilen Şeytan’a dönüşmek [PDF]

 (media.defcon.org)
1 puan yazan GN⁺ 2023-09-24 | 1 yorum | WhatsApp'ta paylaş
  • DEFCON 31 2023 sunumu SpamChannel, Cloudflare Worker ile e-posta göndermeye yönelik bir denemeden yola çıkarak 2 milyondan fazla alan adını hedefleyen sahte e-posta sorununu ele alıyor
  • Temel deney, e-posta gönderimini elle değil programlama yoluyla işlemek ve bunu Worker dağıtım akışına bağlamakla başlıyor
  • Cloudflare Workers; JavaScript, TypeScript ve WASM tabanlı bir serverless computing ortamı olarak tanıtılıyor
  • Temel prosedür, npm create cloudflare@latest ile proje oluşturup npx wrangler deploy ile dağıtma akışıdır
  • Workers’tan e-posta göndermeye dair ipucu, Cloudflare blogundaki MailChannels entegrasyonu yazısından geliyor

SpamChannel sunumunun çıkış noktası

  • SpamChannel, DEFCON 31 2023’te Marcello Salvati(@byt3bl33d3r) tarafından sunulan bir PDF olup 2 milyondan fazla alan adından sahte e-posta gönderme konusunu ele alıyor
  • Sunumun hedefi, e-posta gönderimini aşağıdaki koşullarda gerçekleştirmek
    • E-postayı programlama yoluyla göndermek
    • Cloudflare Worker üzerinden göndermek
  • Yasal sorumlulukla ilgili olarak “suç işlemeyin” şeklinde bir sorumluluk reddi içeriyor

Cloudflare Workers ve e-posta gönderimi ipuçları

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-24
Hacker News yorumları

  • Sunum videosu: https://www.youtube.com/watch?v=NwnT15q_PS8
    Ya da burada da var. Benim Firefox’umda video biçimi çalışmadı ama VLC ile oynatılıyor: https://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20vid...

  • SPF, bu sunumda ele alınandan çok daha fazla şekilde bozuk. E-posta güvenliği güçlendirme/teslim edilebilirlik destek mühendisi olarak çalışan biri olarak tavsiyem her zaman SPF’den ziyade DKIM + DMARC’a odaklanmak yönünde
    Eski sistemlerle uyumluluk nedenleriyle SPF hâlâ gerekli, ancak teslim edilebilirlik ya da kimliğe bürünmeyi önleme için ona güvenilmemeli
    54. slayt DKIM + DMARC’ın bu saldırıya yardımcı olmadığını söylüyor ama bu tamamen doğru değil
    DMARC p=reject politikasını ancak yetkilendirdiğiniz tüm göndericilerde DKIM’i yapılandırdığınızda güvenle açabilirsiniz; o seviyeye geldiğinizde, üçüncü taraf göndericiler için SPF’yi devreden çıkarmaya başlamak üzere SPF’de ? nötr niteleyicisini kullanabilirsiniz
    Örneğin v=spf1 include:relay.mailchannels.net ~all, v=spf1 ?include:relay.mailchannels.net ~all olur
    Böylece MailChannels’tan gelen postalar, DMARC destekleyen alıcılarda SPF açısından nötr işlenir ve DKIM’i kullanmaya yönelir; eski legacy posta hizmetleri de nötr sonucu kabul etmelidir
    Mükemmel bir çözüm değil, ama e-posta zaten hiçbir zaman %100 güvenilir ya da güvenli olamaz

    • Öyleyse SPF’nin sorununun ne olduğunu merak ediyorum. TCP’de kaynak IP sahteciliği oldukça zor olduğu için, DKIM’in SPF’ye göre ne avantajı olduğunu hep merak etmişimdir
      Ben SPF’yi yalnızca $myIP’ye izin verecek şekilde ayarlıyordum. Benim alan adımla spam göndermek için önce ISP’mi ya da kayıt kuruluşumu ele geçirmeleri gerekir; o noktada alan adım için TLS sertifikası da alabilirler
      Birden fazla gönderim sistemini izin listesine almak zorunda olan büyük kuruluşlarda bile, DKIM kayıtlarını sahtelemek mümkün değilken meşru SPF göndericilerinden biri gibi davranmanın yolunu bilmiyorum
      Gönderilen sunumdaki gibi herkesin herkese açık şekilde kullanabildiği IP aralıklarını izin listesine almak basitçe aptalca bir yapılandırma
      Tüm posta alışverişini sahtelemek için birkaç baytlık tek bir e-posta karşılığında terabayt ölçeğinde trafik gerekir ve STARTTLS zorunluysa bu imkânsız hale gelir

  • Prodüksiyonda Cloudflare Workers + MailChannels kullanıyoruz. Tüyler ürpertici
    Zaten CF Workers’tan gerçek sunucuya taşıma üzerinde çalışıyorduk; şimdi sanırım MailChannels’tan da ayrılmamız gerekecek
    Güvenlik riski, sağladığı kolaylığa değmez

    • Haziran 2023’ten beri DNS’te _mailchannels kaydını yayımlamazsanız Workers üzerinden MailChannels aracılığıyla e-posta gönderemiyorsunuz
    • Açık olmak gerekirse, bu sorun MailChannels’ın göndericinin gönderici alan adının doğrulanmış sahibi olup olmadığını doğrulamamasından kaynaklanıyor. Sorun CF Workers değil

  • “DKIM imzası olmayan ama DKIM’i uygulayan bir alan adından gelen tüm e-postalarda banner gösterme” fikri, anladığım kadarıyla çoğu durumda imkânsız. Çünkü bir alan adının DKIM’i uygulayıp uygulamadığını kesin olarak bilmenin bir yolu yok
    Teorik olarak "_domainkey.example.com" için DNS sorgusu yapıp NXDOMAIN mı NOERROR mı döndüğüne bakabilirsiniz. İkincisi genellikle alt alan adı olduğu anlamına gelir ve dolayısıyla DNS’te bazı DKIM anahtarları bulunduğu anlamına gelebilir
    Ama selector adını bilemezsiniz; o anahtarın etkin mi olduğu yoksa ileride etkinleştirilmek üzere mi durduğu da bilinemez
    Bir alan adında birden fazla yetkili gönderici olabilir; bazıları DKIM imzası kullanırken bazıları kullanmayabilir
    Tüm DNS sunucuları standardı düzgün izlemediği için NXDOMAIN/NOERROR ayrımı da ancak genel olarak işe yarar

    • Posta trafiğinin istatistiksel olarak anlamlı bir oranını gören bir sağlayıcıysanız tüm veya neredeyse tüm DKIM selector’larını görebilirsiniz
      Alıntılanan cümle, MailChannels’tan gelen ve DKIM imzası olmayan postaları reddetmeyi öneriyor gibi görünüyor

  • “MailChannels’ın başlıca müşterileri, gönderdikleri e-postaların alan adlarına sahip olmayan web hosting sağlayıcılarıdır” ifadesi, bir süredir duyduğum en kötü mazeretlerden biri
    Web hosting sağlayıcıları genelde barındırdıkları alan adlarının “sahibi” değildir, ama hangi alan adlarını barındırdıklarını kesinlikle bilirler. Alan adlarını müşteri hesabına/dizine yönlendirmek web hosting’in özüdür
    Gereken şey, cPanel gibi bir entegrasyonla alan adı listesini raporlamak ve her alan adını rastgele üretilmiş bir anahtara bağlamak kadar basit
    Tüm bunlar son kullanıcıyı uğraştırmadan otomatikleştirilebilir ve öyle de olmalıdır

    • Mailing listeler ne olacak? Posta yönlendirme?

  • DMARC belirtiminin evrilip doğrulamada SPF değil yalnızca DKIM kullanılmasını sağlayacak bir yol sunması iyi olurdu. Ne yazık ki Google Calendar davetleri gibi şeyler hâlâ DKIM’de başarısız oluyor

    • Bir sonraki DMARC sürümüne, DMARC doğrulamasında SPF’yi hariç tutma seçeneğinin girme olasılığı yüksek. Google ekibi bunu IETF DMARC e-posta listesinde destekliyor:
      https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukL...
      Alan adı sahibinin DMARC kullanırken “alan adımın trafiğini gerçekten doğrulayan mekanizma yalnızca DKIM olsun” diye belirtebilmesi bence çok iyi bir fikir
      Sektörde, SPF ve DMARC zayıflıklarını etrafından dolanmanın birçok yolu var; örneğin kimlik doğrulamayı yalnızca SPF yorumlama anında bilinebilen ölçütlere göre dinamik olarak ayarlayan SPF makroları gibi
      Ama hiçbir geçici çözüm, “alan adım için lütfen yalnızca DKIM kullanın” demekten daha iyi değil

  • Kısa süre önce kendi alan adımın e-posta hazırlığını bizzat yaşadım; özellikle de “kendi ekipmanından e-posta göndermek istiyorsan işletme hesabın olmalı” diye karar veren ISP yüzünden çıldırtıcı derecede bunaldım, böyle şeyler gerçekten insanı öfkelendiriyor
    Ağın sorumlu bir üyesi olmaya canla başla çalışıyorum; sistemimi düzgün ayarlamak için mevcut en güncel seviyeye kadar inip didik didik ettim
    Ama böyle insanların yalnızca var olmakla kalmayıp fiilen açık relay gibi gevşek biçimde çalıştırması ve internetin neredeyse yarısının bunun bedelini ödemesi akıl alır gibi değil

  • Özetle, birçok SPF kaydında yer alan açık relay’leri buldukları söyleniyor

    • SPF kaydıyla kendini açık bırakan 2 milyon alan adının binden azı DKIM/DMARC kaydı ayarlamıştı; hatta DKIM’i yapılandırıp öylece bırakan durumlar bile Gmail’de hâlâ doğrulanmış olarak geçiyor
    • Daha da kötüsü var. Platformun kendisi alan adı sahipliği doğrulamasını denemeye bile kalkmadığı için herhangi birinin adına gönderim yapılabiliyordu
    • Kesin konuşmak gerekirse bu bir açık relay değil. MailChannels spam ve phishing’i agresif biçimde kontrol etmeseydi internette var olamazdı
      DEFCON sunumu devasa bir deliğin varlığını kanıtlamadı; internet e-postasının ilk günlerinden beri var olan bir gerçeği gösterdi
      S/MIME veya DKIM gibi ileti imzaları kullanmadan gönderen alan adını yeterince doğrulamak mümkün değil
      DKIM olsa bile DKIM yeniden gönderim saldırısıyla geniş çaplı kötüye kullanım mümkün

  • ARC başlıklarının spam puanına etkisi ilginç. Kişisel posta sunucusu işleten biri olarak, e-postalarıma anlamsız bir ARC başlığı seti eklemem bile teslim edilme oranını artırabilir mi?

    • Öyle olmadığını söylemek isterim. Eğer doğru olsaydı, farklı sağlayıcılara dağılmış tüm gelen kutularımın spam’le dolup taşacağını düşünüyorum
      Organize ve bilgili spam gönderenler bu tür şeylerin tamamını kurcalıyor olmalı ve bunları aşmak için kullandıklarına şüphe yok
    • E-posta sektörü ARC’yi büyük alıcıların spam filtrelerini atlatmanın kusursuz bir yolu olarak görmüyor. DEFCON sunumunu yapan kişi böyle bir yargıya varmaya yeterince hazır değildi

  • Bu durum Mayıs 2022’de de zaten doğrulanmış gibi görünüyor: https://news.ycombinator.com/item?id=30533032

    • CEO’nun şöyle dediği anlaşılıyor:
      “Geniş kapsamlı spam ve phishing tespit yeteneklerimiz var ve kötüye kullanımı ele alabiliriz”
      Ah, tabii :D