SPF / DMARC para provedor de e-mail compartilhado (gmail) - como este e-mail passou no SPF?
Recentemente, recebemos um e-mail de um "hacker de chapéu branco" que se descreveu como sendo de nossa própria organização.
De acordo com os cabeçalhos de email, spf, dmarc, dkim e arc foram aprovados e o gmail não sinalizou de forma alguma.
Usamos domínios do Google para o nosso e-mail e o registro spf / dmarc em questão para o domínio é
SPF v = spf1 inclui: _spf.google.com -all
DMARC _dmarc.companyX.com v = DMARC1; p = nenhum; pct = 100; rua = mailto: [email protected]
(Sei que a configuração do DMARC não está colocando em quarentena no momento, mas não acredito que isso teria ajudado, pois todas as verificações foram aprovadas)
O passe SPF (e há dois deles - um do nosso domínio e um do domínio do remetente original)
Received-SPF: pass (google.com: domain of [email protected] designa 209.85.220.69 como remetente permitido) client-ip = 209.85.220.69;
Received-SPF: pass (google.com: domínio de [email protected] designa 195.216.236.82 como remetente permitido) client-ip = 195.216.236.82;
Pelo que posso entender, como especificamos _spf.google.com (e seus IPs associados) como um remetente permitido, qualquer e-mail enviado usando esses servidores (ou seja, por qualquer usuário do gmail) é válido. Meu entendimento está obviamente errado, mas não tenho certeza por que / como ou, mais importante, o que preciso mudar para evitar que esse spoofing passe.
Encontrei referências a uma vulnerabilidade no gmail em que o invasor usa gateways de entrada para ignorar a verificação interna do SPF, mas isso foi corrigido em agosto e, pelo que posso ver, a verificação do SPF está realmente sendo feita (e passando) - https://ezh.es/blog/2020/08/the-confused-mailman-sending-spf-and-dmarc-passing-mail-as-any-gmail-or-g-suite-customer/ e https://www.forbes.com/sites/leemathews/2020/08/20/google-fixed-a-dangerous-gmail-bug-that-allowed-email-spoofing/
Há uma pergunta semelhante - Como um e-mail de phishing passou SPF, DKIM e DMARC? mas não acho que seja relevante, pois o e-mail nessa questão era, na verdade, de um domínio diferente (De: uber, em vez de De: Bank of America), onde como De: neste e-mail estava explicitamente CompanyX), e há nenhuma resolução nessa questão sobre como bloquear remetentes como este.
Questões
O que impede qualquer usuário do Gmail de se passar por outra empresa que autoriza _spf.google.com como remetente?
O que posso alterar em minha configuração para evitar que isso aconteça?
obrigado
Cabeçalhos semi-completos - eliminei alguns que considero irrelevantes por razões de espaço.
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]>```
Respostas
Não consigo descobrir como transformar seus cabeçalhos redigidos em algo que a ferramenta Messageheader do Google possa ler, mas seria um bom primeiro passo. O Google irá guiá-lo através do que fez com um pouco mais de autoridade do que eu (especialmente considerando suas redações).
Lendo manualmente seus cabeçalhos (e presumindo que nenhum seja forjado), isso chega por meio do inbox.eu e passa seu SPF. O ARC-Authentication-Resultscabeçalho, que usa Cadeia Recebida Autenticada para estender a confiança (neste caso do Google para o Google), tem alguns dados interessantes: Observe a parte que diz header.from=inbox.eu - o cabeçalho De mudou de alguma forma depois que esse cabeçalho foi adicionado, mas antes do Authentication-Resultscabeçalho ser adicionado.
Usando o que ARC diz ser o domínio De original, ele passa o DMARC do inbox.eu graças ao SPF e ao alinhamento com o cabeçalho original From . Esse cabeçalho muda magicamente para sua empresa (talvez por meio de um filtro do GMail na conta do invasor?) E, como já está na infraestrutura do Google, ele passa o SPF.
Isso se parece muito com o vuln remendado que você referenciou.
O SPF não é ótimo em hosts compartilhados. O Google tenta atenuar isso, verificando se o mail fromcomando SMTP e o Fromendereço do cabeçalho são provavelmente seus, mas algo deu errado naquele salto final (após o cabeçalho ARC, aquele que está mais acima Authentication-Resultse Received-SPFvinculado ao Receivedcabeçalho mais alto ).
Em vez de ficar em dívida com o Google, recomendo definir um registro SPF de v=spf1 ?all(que diz "O SPF não pode passar nem falhar") e usar DKIM. DMARC requer tanto DKIM ou SPF para passar com o alinhamento, então um ataque que pode ajustar o domínio a partir do cabeçalho na infra-estrutura do Google não vai ajudar a criar um passe SPF que adquire o aceno do DMARC. Forjar DKIM requer quebrar a criptografia ou enganar algum servidor com autoridade para assinar em nome de seu domínio.
Se você tiver hosts que precisam enviar e-mails sem DKIM, adicione-os explicitamente (por endereço IP ou CIDR de IP muito restrito) a esse registro SPF, mas não abençoe todo o Google quando você pode apenas configurar o Google para usar seu domínio para DKIM .
Todos os fornecedores de serviços de e-mail responsáveis e sistemas de marketing por e-mail também oferecem suporte ao DKIM. Não se esqueça de voltar ao DMARC p=nonee monitorar seus registros agregados para descobrir quais sistemas de e-mail você pode ter perdido.