SPF / DMARC dla współdzielonego dostawcy poczty e-mail (gmail) - jak ten e-mail przeszedł SPF?
Niedawno otrzymaliśmy e-mail od opisanego przez siebie hakera „białego kapelusza”, rzekomo pochodzącego z naszej organizacji.
Zgodnie z nagłówkami poczty, spf, dmarc, dkim i arc przeszły pomyślnie, a gmail i tak go nie oflagował.
Używamy domen Google dla naszej poczty e-mail, a dany rekord spf / dmarc dla domeny to
SPF v = spf1 obejmują: _spf.google.com -all
DMARC _dmarc.companyX.com v = DMARC1; p = brak; pct = 100; rua = mailto: [email protected]
(Zdaję sobie sprawę, że ustawienie DMARC nie poddaje w tej chwili kwarantannie, ale nie sądzę, aby to pomogło, ponieważ wszystkie testy przeszły pomyślnie)
Przepustka SPF (a są ich dwa - jeden z naszej domeny, a drugi z pierwotnej domeny nadawcy)
Received-SPF: pass (google.com: domena zapytań[email protected] oznacza 209.85.220.69 jako dozwolonego nadawcę) client-ip = 209.85.220.69;
Received-SPF: pass (google.com: domena [email protected] wskazuje 195.216.236.82 jako dozwolonego nadawcę) client-ip = 195.216.236.82;
Z tego, co rozumiem, ponieważ określiliśmy _spf.google.com (i powiązane z nim adresy IP) jako dozwolonego nadawcę, każdy e-mail wysłany przy użyciu tych serwerów (tj. Przez dowolnego użytkownika Gmaila) jest ważny. Moje rozumienie jest oczywiście błędne, ale nie jestem pewien, dlaczego / jak, a co ważniejsze, co muszę zmienić, aby zapobiec przejściu tego spoofingu.
Znalazłem odniesienia do luki w Gmailu, w której atakujący używa bram przychodzących, aby ominąć wewnętrzne sprawdzenie SPF, ale zostało to naprawione w sierpniu i, o ile widzę, sprawdzanie SPF jest faktycznie wykonywane (i przechodzi) - https://ezh.es/blog/2020/08/the-confused-mailman-sending-spf-and-dmarc-passing-mail-as-any-gmail-or-g-suite-customer/ i https://www.forbes.com/sites/leemathews/2020/08/20/google-fixed-a-dangerous-gmail-bug-that-allowed-email-spoofing/
Jest to podobne pytanie - w jaki sposób wiadomość phishingowa przeszła przez SPF, DKIM i DMARC? ale nie wydaje mi się, aby to miało znaczenie, ponieważ e-mail w tym pytaniu pochodzi z innej domeny (From: uber, zamiast From: Bank of America), gdzie jako From: w tym e-mailu było wprost CompanyX) i jest brak rozwiązania w tym pytaniu, jak blokować takich nadawców.
pytania
Co powstrzymuje użytkownika Gmaila przed podszywaniem się pod inną firmę, która upoważnia _spf.google.com jako nadawcę?
Co mogę zmienić w mojej konfiguracji, aby temu zapobiec?
Dzięki
Częściowo kompletne nagłówki - usunęliśmy niektóre, które moim zdaniem są nieistotne ze względu na przestrzeń.
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]>```
Odpowiedzi
Nie mogę wymyślić, jak wmasować zredagowane nagłówki w coś, co może odczytać narzędzie Messageheader Google , ale to byłby dobry pierwszy krok. Google przeprowadzi Cię przez to, co zrobiło, z nieco większym autorytetem niż ja (zwłaszcza biorąc pod uwagę Twoje redakcje).
Ręczne czytanie nagłówków (i zakładając, że żaden nie jest sfałszowany), przechodzi przez inbox.eu i przekazuje ich SPF. ARC-Authentication-ResultsNagłówek, który wykorzystuje uwierzytelnieni Received Chain przedłużyć zaufanie (w tym przypadku od Google Google), ma kilka interesujących danych: zauważ część, która mówi header.from=inbox.eu - nagłówka From jakoś zmieniły się po tym dodano nagłówek ale przedAuthentication-Results nagłówek został dodany.
Używając tego, co według ARC jest oryginalną domeną From, przekazuje to DMARC inbox.eu dzięki SPF i wyrównaniu z oryginalnym From nagłówkiem. Ten nagłówek następnie w magiczny sposób zmienia się w Twojej firmie (być może przez filtr Gmaila na koncie atakującego?), A ponieważ znajduje się już w infrastrukturze Google, przekazuje SPF.
Wygląda to bardzo podobnie do poprawionego wulna, do którego się odwoływałeś.
SPF nie jest świetny na współdzielonych hostach. Google próbuje to złagodzić, sprawdzając, czy mail frompolecenie SMTP i Fromadres nagłówka są prawdopodobnie twoje, ale coś poszło nie tak w tym ostatnim przeskoku (po nagłówku ARC, ten najwyższy Authentication-Resultsi Received-SPFpowiązany z najwyższym Receivednagłówkiem).
Zamiast być zobowiązanym do Google, zalecam ustawienie rekordu SPF v=spf1 ?all(co oznacza, że „SPF nie może przejść ani zawieść”) i zamiast tego użyć DKIM. DMARC wymaga albo DKIM lub SPF przejść z wyrównaniem, więc atak, który można dostosować z nagłówka domenę ramach infrastruktury Google nie pomoże stworzyć podanie SPF dostaje zielone światło od DMARC. Fałszowanie DKIM wymaga złamania kryptografii lub oszukania serwera z uprawnieniem do podpisywania się w imieniu Twojej domeny.
Jeśli masz hosty, które muszą wysyłać pocztę bez DKIM, dodaj je jawnie (za pomocą adresu IP lub bardzo ścisłego IP CIDR) do tego rekordu SPF, ale nie błogosław wszystkich Google, gdy możesz po prostu skonfigurować Google do używania Twojej domeny dla DKIM .
Wszyscy odpowiedzialni dostawcy usług e-mail i systemy marketingu e-mailowego również obsługują DKIM. Nie zapomnij wrócić do DMARC p=nonei faktycznie monitorować dzienniki zbiorcze, aby dowiedzieć się, jakie systemy poczty e-mail mogłeś przegapić.