SpamChannel: Mengirim Email Spoofing dari Lebih dari 2 Juta Domain dan Praktis Menjadi Satan [PDF]

 (media.defcon.org)
1 poin oleh GN⁺ 2023-09-24 | 1 komentar | Bagikan ke WhatsApp
  • Presentasi SpamChannel di DEFCON 31 2023 membahas masalah spoofing yang menargetkan pengiriman email dari lebih dari 2 juta domain, berawal dari upaya mengirim email dengan Cloudflare Worker
  • Eksperimen intinya dimulai dari menangani pengiriman email secara terprogram, bukan manual, lalu menghubungkannya ke alur deployment Worker
  • Cloudflare Workers diperkenalkan sebagai lingkungan serverless computing berbasis JavaScript, TypeScript, dan WASM
  • Prosedur dasarnya adalah membuat proyek dengan npm create cloudflare@latest lalu melakukan deployment dengan npx wrangler deploy
  • Petunjuk untuk mengirim email dari Workers berlanjut dari artikel blog Cloudflare tentang integrasi MailChannels

Titik awal presentasi SpamChannel

  • SpamChannel adalah PDF yang dipresentasikan oleh Marcello Salvati(@byt3bl33d3r) di DEFCON 31 2023, membahas topik pengiriman email spoofing dari lebih dari 2 juta domain
  • Tujuan presentasi ini adalah mengimplementasikan pengiriman email dengan syarat berikut
    • mengirim email secara terprogram
    • mengirimnya melalui Cloudflare Worker
  • Terkait tanggung jawab hukum, disertakan disclaimer yang menyatakan “jangan melakukan kejahatan”

Cloudflare Workers dan petunjuk pengiriman email

Bacaan terkait

1 komentar

 
GN⁺ 2023-09-24
Opini Hacker News

  • Video presentasi: https://www.youtube.com/watch?v=NwnT15q_PS8
    Atau juga ada di sini. Format videonya tidak bisa diputar di Firefox saya, tetapi bisa diputar dengan VLC: https://media.defcon.org/DEF%20CON%2031/DEF%20CON%2031%20vid...

  • SPF rusak dalam jauh lebih banyak cara daripada yang dibahas dalam presentasi ini. Dari sudut pandang saya yang bekerja sebagai engineer untuk penguatan keamanan email/dukungan deliverability, sarannya selalu fokus pada DKIM + DMARC dibanding SPF
    Karena alasan legacy, SPF masih tetap diperlukan, tetapi jangan mengandalkannya untuk deliverability atau pencegahan impersonasi
    Slide 54 mengatakan DKIM + DMARC tidak membantu terhadap serangan ini, tetapi itu tidak sepenuhnya benar
    Kebijakan DMARC p=reject hanya bisa diaktifkan dengan aman ketika DKIM sudah dikonfigurasi untuk semua pengirim yang didelegasikan, dan setelah mencapai level itu, Anda bisa mulai mengeluarkan SPF untuk pengirim pihak ketiga dengan memakai modifier netral ? di SPF
    Misalnya v=spf1 include:relay.mailchannels.net ~all menjadi v=spf1 ?include:relay.mailchannels.net ~all
    Dengan begitu, email dari MailChannels akan diperlakukan netral oleh SPF bagi penerima yang mendukung DMARC sehingga mereka memakai DKIM, dan layanan email legacy lama pun semestinya menerima hasil netral
    Ini bukan solusi sempurna, tetapi email memang tidak akan pernah bisa 100% tepercaya atau aman

    • Kalau begitu, saya penasaran apa masalah SPF sebenarnya. Karena pemalsuan IP sumber di TCP cukup sulit, saya selalu bertanya-tanya apa keunggulan DKIM dibanding SPF
      Saya selama ini mengatur SPF agar hanya mengizinkan $myIP. Untuk mengirim spam atas nama domain saya, orang harus lebih dulu membobol ISP atau registrar saya, dan kalau sudah sejauh itu mereka juga bisa mendapatkan sertifikat TLS untuk domain saya
      Bahkan di organisasi besar yang harus memasukkan beberapa sistem pengirim ke allowlist, saya tidak tahu bagaimana caranya berpura-pura menjadi salah satu pengirim SPF yang sah ketika record DKIM tidak bisa dipalsukan
      Kasus seperti presentasi yang dikirimkan ini, yaitu memasukkan rentang IP yang bisa dipakai publik oleh siapa saja ke allowlist, hanyalah konfigurasi yang bodoh
      Untuk memalsukan seluruh pertukaran mail, dibutuhkan trafik berskala terabyte untuk satu email beberapa byte, dan jika STARTTLS diwajibkan, itu menjadi mustahil

  • Kami memakai Cloudflare Workers + MailChannels di production. Menegangkan
    Kami memang sudah sedang memindahkan dari CF Workers ke server sungguhan, dan sekarang sepertinya juga harus meninggalkan MailChannels
    Risiko keamanannya tidak sepadan dengan kemudahannya

    • Sejak Juni 2023, Anda tidak bisa mengirim email melalui MailChannels dari Workers kecuali memublikasikan record _mailchannels di DNS
    • Untuk memperjelas, isu ini terletak pada MailChannels yang tidak mengautentikasi pengirim sebagai pemilik terverifikasi dari domain pengirim. CF Workers bukan masalahnya

  • “Menampilkan banner pada semua email dari domain yang mengimplementasikan DKIM tetapi tidak memiliki tanda tangan DKIM” menurut pemahaman saya sebagian besar mustahil. Sebab tidak ada cara pasti untuk mengetahui domain mana yang mengimplementasikan DKIM
    Secara teori, Anda bisa melakukan kueri DNS ke "_domainkey.example.com" dan melihat apakah hasilnya NXDOMAIN atau NOERROR. Yang terakhir biasanya berarti ada subdomain, sehingga bisa berarti ada beberapa kunci DKIM di DNS
    Namun kita tidak tahu nama selectornya, dan juga tidak tahu apakah kunci itu aktif atau baru akan diaktifkan nanti
    Satu domain bisa memiliki beberapa pengirim terautentikasi, dan sebagian mungkin memakai tanda tangan DKIM sementara sebagian lainnya tidak
    Tidak semua server DNS mengikuti standar dengan benar, sehingga pembedaan NXDOMAIN/NOERROR pun hanya bekerja secara garis besar

    • Penyedia yang melihat proporsi trafik mail yang signifikan secara statistik bisa melihat semua atau hampir semua selector DKIM
      Kalimat yang dikutip tampaknya bermaksud menolak email dari MailChannels yang tidak memiliki tanda tangan DKIM

  • “Pelanggan utama MailChannels adalah penyedia web hosting yang tidak memiliki domain email yang mereka kirimkan” adalah alasan terburuk yang pernah saya dengar belakangan ini
    Penyedia web hosting biasanya memang tidak “memiliki” domain yang mereka hosting, tetapi mereka jelas tahu domain mana yang mereka hosting. Merutekan domain ke akun/direktori pelanggan adalah inti dari web hosting
    Yang dibutuhkan hanyalah integrasi seperti cPanel untuk melaporkan daftar domain, lalu mengikat tiap domain ke kunci yang dibuat acak
    Semua ini bisa, dan semestinya, diotomatisasi tanpa merepotkan pengguna akhir

    • Bagaimana dengan mailing list? Bagaimana dengan penerusan email?

  • Semoga spesifikasi DMARC berevolusi sehingga ada cara untuk memakai hanya DKIM, bukan SPF, untuk verifikasi. Sayangnya, hal-hal seperti undangan Google Calendar masih gagal DKIM

    • Rilis DMARC berikutnya besar kemungkinan akan menyertakan opsi untuk mengecualikan SPF dari verifikasi DMARC. Tim Google mendorong ini di milis IETF DMARC:
      https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukL...
      Menurut saya ini ide yang sangat bagus, karena pemilik domain bisa memakai DMARC sambil menetapkan, “tolong jadikan DKIM saja sebagai mekanisme yang benar-benar mengautentikasi trafik domain saya”
      Di industri ada banyak cara untuk mem-bypass kelemahan SPF dan DMARC, seperti macro SPF yang menyesuaikan autentikasi secara dinamis berdasarkan kriteria yang baru diketahui pada saat SPF dievaluasi
      Namun tidak ada workaround yang lebih baik daripada mengatakan, “untuk domain saya, tolong pakai DKIM saja”

  • Baru-baru ini saya sendiri mengalami proses menyiapkan email untuk domain saya, dan terutama dibuat sangat frustrasi oleh ISP yang menetapkan bahwa “kalau ingin mengirim email dari perangkat sendiri, harus pakai akun bisnis”; hal seperti ini benar-benar bikin marah
    Saya berusaha mati-matian menjadi anggota jaringan yang bertanggung jawab, menggali sampai standar terbaru saat ini dan membedah semuanya agar sistem saya dikonfigurasi dengan benar
    Tapi orang-orang seperti itu bukan cuma ada, mereka pada dasarnya menjalankannya dengan enteng seperti open relay, dan hampir separuh internet harus menanggung akibatnya—sungguh tidak masuk akal

  • Ringkasnya, ini soal ditemukannya open relay yang tercantum di banyak record SPF

    • Dari 2 juta domain yang membuka diri lewat record SPF, kurang dari 1.000 yang menyiapkan record DKIM/DMARC, dan bahkan ketika DKIM dikonfigurasi lalu dibiarkan begitu saja, Gmail masih meloloskannya sebagai terautentikasi
    • Lebih buruk lagi, platformnya sendiri bahkan tidak mencoba melakukan verifikasi kepemilikan domain, sehingga orang bisa mengirim atas nama siapa pun
    • Secara ketat, ini bukan open relay. Kalau MailChannels tidak mengendalikan spam dan phishing secara agresif, ia tidak akan bisa eksis di internet
      Presentasi DEFCON itu bukan membuktikan adanya lubang besar, melainkan menunjukkan fakta yang sudah ada sejak masa awal email internet
      Tanpa tanda tangan pesan seperti S/MIME atau DKIM, domain pengirim tidak bisa diautentikasi dengan memadai
      Bahkan dengan DKIM, penyalahgunaan dalam skala luas tetap dimungkinkan lewat serangan replay DKIM

  • Dampak header ARC terhadap skor spam menarik. Sebagai orang yang menjalankan server email pribadi, apakah cukup dengan menambahkan satu set header ARC yang tidak bermakna ke email saya untuk meningkatkan tingkat keterkirimannya?

    • Saya ingin mengatakan tidak. Kalau itu benar, rasanya semua inbox saya yang tersebar di berbagai penyedia akan dibanjiri spam
      Para spammer yang terorganisasi dan paham teknis pasti sedang membedah semua hal semacam ini, dan jelas akan memakainya untuk menembus filter
    • Di industri email, ARC tidak dipandang sebagai cara sempurna untuk melewati filter spam milik penerima besar. Pembicara DEFCON itu kurang siap untuk membuat penilaian seperti itu

  • Sepertinya ini sudah dikonfirmasi pada Mei 2022: https://news.ycombinator.com/item?id=30533032

    • CEO-nya tampaknya mengatakan begini:
      “Kami memiliki kemampuan deteksi spam dan phishing yang luas dan dapat menangani penyalahgunaan”
      Oh, begitu ya :D