SPF / DMARC untuk penyedia email bersama (gmail) - bagaimana email ini lolos SPF?
Kami baru-baru ini menerima email dari "peretas topi putih" yang dideskripsikan sendiri, yang mengaku dari organisasi kami sendiri.
Menurut header surat, spf, dmarc, dkim, dan arc semuanya lolos dengan baik dan gmail tidak menandainya dengan cara apa pun.
Kami menggunakan domain google untuk email kami dan data spf / dmarc yang dimaksud untuk domain tersebut adalah
SPF v = spf1 termasuk: _spf.google.com -all
DMARC _dmarc.companyX.com v = DMARC1; p = tidak ada; persen = 100; rua = mailto: [email protected]
(Saya menyadari pengaturan DMARC tidak mengkarantina apa pun saat ini, tetapi saya tidak percaya ini akan membantu karena semua pemeriksaan telah berlalu)
Kartu SPF (dan ada dua di antaranya - satu dari domain kami, dan satu dari domain pengirim asli)
Received-SPF: pass (google.com: domain of [email protected] menetapkan 209.85.220.69 sebagai pengirim yang diizinkan) client-ip = 209.85.220.69;
Received-SPF: pass (google.com: domain [email protected] menunjuk 195.216.236.82 sebagai pengirim yang diizinkan) client-ip = 195.216.236.82;
Dari apa yang dapat saya pahami, karena kami telah menetapkan _spf.google.com (dan itu terkait dengan IP) sebagai pengirim yang diizinkan, semua email yang dikirim menggunakan server tersebut (yaitu, oleh pengguna gmail) adalah valid. Pemahaman saya jelas salah, tapi saya tidak yakin mengapa / bagaimana, atau yang lebih penting, apa yang perlu saya ubah untuk mencegah spoofing ini lewat.
Saya telah menemukan referensi tentang kerentanan di gmail di mana penyerang menggunakan gateway masuk untuk melewati pemeriksaan SPF internal, tetapi ini telah diperbaiki kembali pada bulan Agustus, dan sejauh yang saya lihat, pemeriksaan SPF sebenarnya sedang dilakukan (dan lolos) - https://ezh.es/blog/2020/08/the-confused-mailman-sending-spf-and-dmarc-passing-mail-as-any-gmail-or-g-suite-customer/ dan https://www.forbes.com/sites/leemathews/2020/08/20/google-fixed-a-dangerous-gmail-bug-that-allowed-email-spoofing/
Ada pertanyaan serupa ini - Bagaimana email phishing lolos dari SPF, DKIM, dan DMARC? tapi menurut saya itu tidak relevan karena email dalam pertanyaan itu sebenarnya dari domain yang berbeda (Dari: uber, bukan Dari: Bank of America), sedangkan Dari: di email ini ada kejelasan CompanyX), dan ada tidak ada resolusi dalam pertanyaan tentang bagaimana memblokir pengirim seperti ini.
Pertanyaan
Apa yang membuat pengguna gmail tidak dapat meniru perusahaan lain yang memberi otorisasi _spf.google.com sebagai pengirim?
Apa yang dapat saya ubah di penyiapan saya untuk mencegah hal ini terjadi?
Terima kasih
Header semi lengkap - menghapus beberapa yang menurut saya tidak relevan karena alasan ruang.
Delivered-To: [email protected]
Return-Path: <[email protected]>
Received: from mail-sor-f69.google.com (mail-sor-f69.google.com. [209.85.220.69])
by mx.google.com with SMTPS id a77sor4025261wme.15.2020.12.10.15.34.18
for <[email protected]>
(Google Transport Security);
Thu, 10 Dec 2020 15:34:19 -0800 (PST)
Received-SPF: pass (google.com: domain of [email protected] designates 209.85.220.69 as permitted sender) client-ip=209.85.220.69;
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=20150623 header.b="xcnlWAQ/";
arc=pass (i=2 spf=pass spfdomain=inbox.eu dkim=pass dkdomain=inbox.eu dmarc=pass fromdomain=inbox.eu);
spf=pass (google.com: domain of [email protected] designates 209.85.220.69 as permitted sender) [email protected];
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=companyX.com
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass [email protected] header.s=20140211 header.b=OQtRvw0v;
spf=pass (google.com: domain of [email protected] designates 195.216.236.82 as permitted sender) [email protected];
dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=inbox.eu
Received: from eu-shark2.inbox.eu (eu-shark2.inbox.eu. [195.216.236.82])
by mx.google.com with ESMTPS id v7si6670766wra.295.2020.12.10.15.34.17
for <[email protected]>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 10 Dec 2020 15:34:17 -0800 (PST)
Received-SPF: pass (google.com: domain of [email protected] designates 195.216.236.82 as permitted sender) client-ip=195.216.236.82;
Received: from eu-shark2.inbox.eu (localhost [127.0.0.1])
by eu-shark2-out.inbox.eu (Postfix) with ESMTP id B3004442C39
for <[email protected]>; Fri, 11 Dec 2020 01:34:16 +0200 (EET)
Received: from localhost (localhost [127.0.0.1])
by eu-shark2-in.inbox.eu (Postfix) with ESMTP id A70E64428EF
for <[email protected]>; Fri, 11 Dec 2020 01:34:16 +0200 (EET)
Received: from eu-shark2.inbox.eu ([127.0.0.1])
by localhost (eu-shark2.inbox.eu [127.0.0.1]) (spamfilter, port 35)
with ESMTP id CNGUsZY_Hba1 for <[email protected]>;
Fri, 11 Dec 2020 01:34:16 +0200 (EET)
Received: from mail.inbox.eu (eu-pop1 [127.0.0.1])
by eu-shark2-in.inbox.eu (Postfix) with ESMTP id 08A1B440DC5
for <[email protected]>; Fri, 11 Dec 2020 01:34:16 +0200 (EET)
Received: from DESKTOPR10AFHO (unknown [39.34.131.177])
(Authenticated sender: [email protected])
by mail.inbox.eu (Postfix) with ESMTPA id 36E2F1BE00DA
for <[email protected]>; Fri, 11 Dec 2020 01:34:14 +0200 (EET)
From: "'Mr White Hat' via Sales & Enquiries" <[email protected]>
To: <[email protected]>
X-Original-Sender: [email protected]
X-Original-Authentication-Results: mx.google.com; dkim=pass
[email protected] header.s=20140211 header.b=OQtRvw0v; spf=pass
(google.com: domain of [email protected] designates 195.216.236.82
as permitted sender) [email protected];
dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=inbox.eu
X-Original-From: "Mr White Hat" <[email protected]>
Reply-To: "Mr White Hat" <[email protected]>```
Jawaban
Saya tidak tahu cara memijat header Anda yang telah disunting menjadi sesuatu yang dapat dibaca oleh alat Google Messageheader , tetapi itu akan menjadi langkah pertama yang baik. Google akan memandu Anda melalui apa yang dilakukannya dengan sedikit lebih banyak otoritas daripada yang saya miliki (terutama memberikan redaksi Anda).
Secara manual membaca header Anda (dan dengan asumsi tidak ada yang dipalsukan), ini datang melalui inbox.eu dan meneruskan SPF mereka. The ARC-Authentication-Resultsheader, yang menggunakan dikonfirmasi Diterima Rantai untuk memperluas kepercayaan (dalam hal ini dari Google untuk Google), memiliki beberapa data menarik: Perhatikan bagian yang mengatakan header.from=inbox.eu - Dari sundulan entah bagaimana berubah setelah header ini telah ditambahkan tapi sebelum itu Authentication-Resultssundulan ditambahkan.
Menggunakan apa yang dikatakan ARC sebagai domain Dari asli, ini meneruskan DMARC inbox.eu berkat SPF dan keselarasan dengan header asli From . Header itu kemudian secara ajaib berubah ke perusahaan Anda (mungkin melalui filter GMail dalam akun penyerang?) Dan karena sudah ada di infrastruktur Google, kemudian melewati SPF.
Ini terlihat sangat mirip dengan vuln yang ditambal yang Anda rujuk.
SPF tidak bagus di host bersama. Google mencoba menguranginya dengan memverifikasi mail fromperintah SMTP dan Fromalamat header terbukti milik Anda, tetapi ada yang salah dalam lompatan terakhir itu (setelah header ARC, yang paling atas Authentication-Resultsdan Received-SPFterkait dengan Receivedheader paling atas ).
Daripada terikat dengan Google, saya sarankan untuk menyetel data SPF v=spf1 ?all(yang mengatakan "SPF tidak dapat lulus atau gagal") dan sebagai gantinya gunakan DKIM. DMARC membutuhkan baik DKIM atau SPF untuk lulus dengan keselarasan, sehingga serangan yang dapat men-tweak Dari sundulan domain dalam infrastruktur Google tidak akan membantu menciptakan lulus SPF yang mendapat anggukan dari DMARC. Memalsukan DKIM memerlukan pembobolan kriptografi atau menipu beberapa server dengan otoritas untuk masuk atas nama domain Anda.
Jika Anda memiliki host yang perlu mengirim email tanpa DKIM, tambahkan secara eksplisit (menurut alamat IP atau IP CIDR yang sangat erat) ke data SPF tersebut, tetapi jangan memberkati semua Google saat Anda dapat mengonfigurasi Google untuk menggunakan domain Anda untuk DKIM .
Semua Penyedia Layanan Email dan sistem pemasaran email yang bertanggung jawab juga mendukung DKIM. Jangan lupa untuk kembali ke DMARC p=nonedan benar-benar memantau log agregat Anda untuk mencari tahu sistem email apa yang mungkin Anda lewatkan.