Sepanduk Penyeludupan SMTP
Beberapa hari yang lalu, Penyelidik SEC Consult mendedahkan, melalui catatan blog, maklumat tentang teknik serangan baharu yang dipanggil Penyeludupan SMTP, yang boleh membenarkan penghantaran e-mel palsu yang memintas mekanisme pengesahan.
Disebutkan bahawa teknik serangan menyasarkan Protokol SMTP, di mana penyerang boleh menyalahgunakan perbezaan dalam cara pelayan SMTP keluar dan masuk mentafsir urutan yang menunjukkan penghujung data mesej.
Mengenai Penyeludupan SMTP
Penyeludupan SMTP ialah teknik baharu yang membenarkan pemisahan mesej kepada beberapa mesej berbeza apabila dihantar oleh pelayan SMTP asal ke pelayan SMTP yang lain, yang mentafsir urutan secara berbeza untuk memisahkan huruf yang dihantar melalui sambungan.
Ini membenarkan suntikan arahan SMTP ke dalam mesej e-mel dengan cara yang menjadikan pelayan penerima menganggapnya sebagai dua mesej berasingan, salah satunya mempunyai beberapa pengepala: "Kepada: penerima@domain.com", "Daripada: pengirim@domain.com", "Subjek: Contoh subjek ", diikuti oleh badan sebenar mesej itu.
Selain itu, kerana sampul mesej utama berjaya melepasi semakan keselamatan seperti SPF, DKIM dan DMARC, mesej palsu dihantar ke peti masuk tanpa amaran.
"Penyeludupan SMTP ialah teknik spoofing e-mel baru yang membenarkan penyerang menghantar e-mel dengan alamat penghantar palsu (cth. ceo@microsoft.com) untuk menyamar sebagai orang lain," kata Longin kepada Dark Reading. "Biasanya terdapat beberapa mitigasi dalam infrastruktur e-mel untuk mengehadkan serangan sedemikian, tetapi dengan pendekatan baharu, e-mel palsu akan dihantar."
Serangan baharu itu, yang dipanggil penyeludupan SMTP, Ia telah direka oleh Timo Longin, perunding keselamatan kanan di SEC Consult. Longin meminjam konsep utama daripada satu lagi kelas serangan yang dikenali sebagai penyeludupan permintaan HTTP, di mana penyerang menipu pengimbang beban bahagian hadapan atau proksi terbalik untuk memajukan permintaan yang dibuat khusus kepada pelayan aplikasi bahagian belakang dengan cara yang bahagian belakang pelayan akhir memprosesnya sebagai dua permintaan berasingan dan bukannya satu .
Berdasarkan ini, Penyeludupan SMTP mengambil kesempatan daripada fakta bahawa pelayan SMTP mentafsir penghujung aliran data secara berbeza, yang boleh menyebabkan satu huruf dibahagikan kepada beberapa dalam sesi yang sama pada pelayan SMTP.
Urutan ini boleh diikuti dengan arahan untuk menghantar mesej lain tanpa memutuskan sambungan. Sesetengah pelayan SMTP mematuhi preskripsi dengan ketat, tetapi yang lain, untuk memastikan keserasian dengan beberapa pelanggan e-mel yang tidak biasa.
Serangan itu berpunca daripada fakta bahawa surat dihantar ke pelayan pertama, yang memproses hanya pembatas "\r\n.\r\n", di dalam badan yang terdapat pembatas alternatif, contohnya, "\ r.\r », diikuti dengan arahan yang menghantar mesej kedua. Memandangkan pelayan pertama mematuhi spesifikasi dengan ketat, ia memproses rentetan yang diterima sebagai satu huruf.
Jika surat itu kemudiannya dihantar ke pelayan transit atau pelayan penerima yang turut menerima urutan "\r.\r" sebagai pemisah, ia akan diproses sebagai dua surat yang dihantar secara berasingan (surat kedua boleh dihantar bagi pihak pengguna tidak disahkan melalui "LOGIN AUTH", tetapi kelihatan betul di sebelah penerima).
Disebutkan bahawa Masalahnya telah pun diselesaikan dalam versi terkini Postfix di mana konfigurasi «smtpd_forbid_unauth_pipelining", yang menyebabkan sambungan gagal jika pembatas tidak mematuhi RFC 2920 dan RFC 5321. Tetapan ini dilumpuhkan secara lalai, tetapi mereka merancang untuk mendayakannya secara lalai dalam cawangan Postfix 3.9, dijangka pada 2024.
Di samping itu, konfigurasi telah ditambah smtpd_forbid_bare_newline, dilumpuhkan secara lalai, yang melarang penggunaan aksara suapan baris ("\n") untuk memisahkan baris tanpa pengembalian. Juga menambah parameter smtpd_forbid_bare_newline_exclusions, yang membolehkan anda melumpuhkan sekatan sokongan "\n" untuk pelanggan pada rangkaian tempatan.
Di sebelah Sendmail, ia menyediakan pilihan 'atau' untuk melindungi daripada serangan dalam srv_features, yang membenarkan pemprosesan hanya urutan "\r\n.\r\n".
Akhirnya sekiranya anda berminat untuk mengetahui lebih lanjut mengenainya, anda boleh menyemak perinciannya Dalam pautan berikut.