Bagaimana email palsu melewati pemeriksaan SPF dan mendarat di kotak masuk saya

Dua puluh tahun yang lalu, Paul Vixie menerbitkan Permintaan untuk Komentar di Menolak EMAIL DARI yang membantu memacu komunitas internet untuk mengembangkan cara baru memerangi spam dengan Kerangka Kebijakan Pengirim (SPF). Masalahnya saat itu, seperti sekarang, adalah bahwa Protokol Transfer Surat Sederhana (SMTP), yang digunakan untuk mengirim email di internet, tidak menyediakan cara untuk mendeteksi domain pengirim palsu.  

Namun, saat menggunakan SPF, pemilik domain dapat memublikasikan catatan sistem nama domain (DNS) yang menentukan alamat IP yang diizinkan untuk menggunakan nama domain mereka untuk mengirim email. Di sisi penerima, server email dapat meminta catatan SPF dari semu domain pengirim untuk memeriksa apakah alamat IP pengirim diotorisasi untuk mengirim email atas nama domain tersebut. 

Email SMTP dan ikhtisar SPF 

Pembaca yang akrab dengan mekanisme pengiriman pesan SMTP dan bagaimana SPF berinteraksi dengan mereka mungkin lebih suka melewatkan bagian ini, meskipun untungnya pendek. 

Bayangkan bahwa Alice di example.com ingin mengirim pesan email ke Bob di example.org. Tanpa SPF, server email Alice dan Bob akan terlibat dalam percakapan SMTP seperti berikut ini, yang disederhanakan menggunakan HELO daripada EHLO, tetapi tidak dengan cara yang secara signifikan mengubah konstruksi dasar: 

Beginilah cara mengirim dan menerima email internet (SMTP) sejak 1980 awal, tetapi memiliki – setidaknya menurut standar internet saat ini – masalah besar. Pada diagram di atas, Chad di contoh.net bisa dengan mudah terhubung ke example.org Server SMTP, terlibat dalam percakapan SMTP yang persis sama dan dapatkan pesan email yang tampaknya dari Alice di example.com dikirim ke Bob di example.org. Lebih buruk lagi, tidak akan ada yang menunjukkan penipuan kepada Bob, kecuali mungkin alamat IP yang dicatat di samping nama host di header pesan diagnostik (tidak ditampilkan di sini), tetapi ini tidak mudah untuk diperiksa oleh non-ahli dan, tergantung pada aplikasi klien email Anda , seringkali sulit diakses. 

Meskipun tidak disalahgunakan pada hari-hari awal spam email, karena spamming massal menjadi model bisnis yang mapan, meskipun patut dibenci, teknik pemalsuan email semacam itu diadopsi secara luas untuk meningkatkan kemungkinan pesan spam dibaca dan bahkan ditindaklanjuti. 

Kembali ke Chad hipotetis di contoh.net mengirim pesan itu "dari" Alice... Itu akan melibatkan dua tingkat peniruan identitas (atau pemalsuan) di mana banyak orang sekarang merasa bahwa pemeriksaan teknis otomatis dapat atau harus dilakukan untuk mendeteksi dan memblokir pesan email palsu tersebut. Yang pertama di tingkat amplop SMTP dan yang kedua di tingkat header pesan. SPF menyediakan pemeriksaan di tingkat amplop SMTP, dan kemudian protokol anti-pemalsuan dan otentikasi pesan ekstensi dkim dan ekstensi DMARC memberikan pemeriksaan di tingkat header pesan. 

Apakah SPF berfungsi? 

Menurut salah satu belajar diterbitkan pada tahun 2022, sekitar 32% dari 1.5 miliar domain yang diselidiki memiliki catatan SPF. Dari jumlah tersebut, 7.7% memiliki sintaks yang tidak valid dan 1% menggunakan data PTR yang tidak digunakan lagi, yang menunjukkan alamat IP ke nama domain. Penyerapan SPF memang lambat dan cacat, yang mungkin menimbulkan pertanyaan lain: berapa banyak domain yang memiliki catatan SPF yang terlalu permisif?  

Penelitian terbaru ditemukan bahwa 264 organisasi di Australia saja memiliki alamat IP yang dapat dieksploitasi dalam catatan SPF mereka dan dengan demikian mungkin tanpa disadari menyiapkan panggung untuk kampanye spam dan phishing skala besar. Meskipun tidak terkait dengan apa yang ditemukan penelitian itu, saya baru-baru ini memiliki kuas saya sendiri dengan email yang berpotensi berbahaya yang memanfaatkan catatan SPF yang salah konfigurasi. 

Email palsu di kotak masuk saya 

Baru-baru ini, saya menerima email yang mengaku dari perusahaan asuransi Prancis Prudence Créole, tetapi memiliki semua ciri-ciri spam dan pemalsuan: 

 

Meskipun saya tahu bahwa memalsukan tajuk pesan alamat Dari: dari sebuah email adalah sepele, rasa ingin tahu saya muncul ketika saya memeriksa tajuk email lengkap dan menemukan bahwa domain dalam amplop SMTP MAIL FROM: alamat balasan@prudencecreole.com telah lulus pemeriksaan SPF: 

Jadi saya mencari catatan SPF domain Prudencecreole.com: 

Itu adalah blok besar alamat IPv4! 178.33.104.0/2 berisi 25% dari ruang alamat IPv4, mulai dari 128.0.0.0 untuk 191.255.255.255. Lebih dari satu miliar alamat IP adalah pengirim yang disetujui untuk nama domain Prudence Creole – surga spammer. 

Hanya untuk memastikan saya tidak bercanda, saya menyiapkan server email di rumah, diberi alamat IP acak, tetapi memenuhi syarat, oleh penyedia layanan internet saya, dan mengirimi saya email spoofing Prudencecreole.com:  

Sukses! 

Untuk melengkapi semua ini, saya memeriksa catatan SPF domain dari email spam lain di kotak masuk saya yang spoofing wildvoyager.com: 

Lihatlah, 0.0.0.0/0 blok memungkinkan seluruh ruang alamat IPv4, yang terdiri dari lebih dari empat miliar alamat, untuk lulus pemeriksaan SPF sambil menyamar sebagai Wild Voyager. 

Setelah eksperimen ini, saya memberi tahu Prudence Créole dan Wild Voyager tentang catatan SPF mereka yang salah dikonfigurasi. Kehati-hatianéole memperbarui catatan SPF mereka sebelum publikasi artikel ini. 

Refleksi dan pelajaran yang didapat 

Membuat catatan SPF untuk domain Anda bukanlah pukulan mematikan terhadap upaya spoofing spammer. Namun, jika dikonfigurasi dengan aman, penggunaan SPF dapat menggagalkan banyak upaya seperti yang masuk ke kotak masuk saya. Mungkin rintangan paling signifikan yang menghalangi penggunaan langsung, lebih luas, dan penerapan SPF yang lebih ketat adalah kemampuan pengiriman email. Dibutuhkan dua orang untuk memainkan permainan SPF karena pengirim dan penerima perlu menyelaraskan kebijakan keamanan email mereka jika email gagal terkirim karena aturan yang terlalu ketat yang diterapkan oleh kedua belah pihak. 

Namun, mengingat potensi risiko dan kerusakan dari spammer yang memalsukan domain Anda, saran berikut dapat diterapkan sebagaimana mestinya: 

• Buat catatan SPF untuk semua identitas HELO/EHLO Anda jika ada pemeriksa SPF yang mengikuti rekomendasi di RFC 7208 untuk memeriksa ini 
• Lebih baik menggunakan semua mekanisme dengan "-" or "~" kualifikasi daripada "?" kualifikasi, sebagai yang terakhir secara efektif memungkinkan siapa pun untuk menipu domain Anda 
• Siapkan aturan "lepaskan semuanya" (v=spf1 -semua) untuk setiap domain dan subdomain yang Anda miliki yang seharusnya tidak pernah menghasilkan email (dirutekan ke internet) atau muncul di bagian nama domain dari perintah HELO/EHLO atau MAIL FROM: 

• Sebagai pedoman, pastikan data SPF Anda berukuran kecil, lebih disukai hingga 512 byte, untuk mencegahnya diabaikan oleh beberapa pemeriksa SPF secara diam-diam 
• Pastikan Anda hanya mengotorisasi kumpulan alamat IP yang terbatas dan tepercaya dalam data SPF Anda 

Meluasnya penggunaan SMTP untuk mengirim email telah menciptakan budaya TI yang berfokus pada mentransfer email secara andal dan efisien, daripada secara aman dan dengan privasi. Menyesuaikan kembali dengan budaya yang berfokus pada keamanan mungkin merupakan proses yang lambat, tetapi harus dilakukan untuk mendapatkan keuntungan yang jelas dari salah satu bahaya internet – spam.