image

Versleutelde maildienst ProtonMail was slachtoffer van DKIM replay-aanval

vrijdag 14 januari 2022, 09:40 door Redactie, 12 reacties
Laatst bijgewerkt: 14-01-2022, 11:29

Versleutelde e-maildienst ProtonMail was vorige maand slachtoffer van een DKIM replay-aanval die er uiteindelijk voor zorgde dat legitieme e-mail van gebruikers door Gmail voor spam werd aangezien. Volgens ProtonMail was het slachtoffer van een DKIM replay-aanval waarbij er misbruik werd gemaakt van een kwetsbaarheid in het anti-spamsysteem van Gmail.

Bij de replay-aanval van december werd één enkel spambericht verstuurd via ProtonMail opnieuw verstuurd naar Gmail-gebruikers om zo de reputatie van ProtonMail te misbruiken en Googles anti-spammaatregelen te omzeilen. Op een gegeven moment was 98 procent van de e-mails die Gmail ontving en claimden van ProtonMail afkomstig te zijn in werkelijkheid spam. "Dit hield in dat de spammers een hoeveelheid e-mail verstuurden die gelijkstond aan vijftig keer het normale uitgaande verkeer naar Google", aldus Bart Butler van ProtonMail.

Met DKIM kan de domeinnaamhouder aangeven met welke sleutel e-mailberichten moeten zijn gesigneerd. Verzendende mailservers ondertekenen alle uitgaande e-mail namens deze domeinnaam met deze sleutel. Ontvangende mailservers kunnen met behulp van de publieke sleutel in het DKIM-record controleren of de e-mail door een geautoriseerde partij is verzonden.

"Maar het DKIM-domein in de digitale handtekening kan verschillen van de degene in de From-header in het bericht zelf. Wanneer de DKIM-handtekening is geverifieerd, bevestigt dit alleen dat het bericht via de mailserver is gegaan van het signerende domein en sindsdien niet is aangepast, niet dat het bericht afkomstig is van waar het beweert vandaan te komen", zegt Butler.

Om te controleren dat het domein in de From-header het bericht verstuurde wordt DMARC (Domain-based Message Authentication, Reporting & Conformance) gebruikt. Om aan de DMARC-controle te voldoen is er het Sender Policy Framework (SPF) of DKIM. Dat de DKIM replay-aanval werkte en Gmail de opnieuw verstuurde spamberichten als "geauthenticeerd" beschouwde kwam door het feit dat DMARC een check van DKIM of SPF vereist, niet van beide, gaat Butler verder.

"Het opnieuw verstuurde bericht had een geldige DKIM-handtekening van protonmail.com, wat inhield dat het aan DMARC voldeed. Dit bericht werd genoeg keren opnieuw verstuurd dat het de domeinreputatie van protonmail.com binnen Gmail beïnvloedde, en uiteindelijk laag genoeg werd dat het de bezorging van legitieme mail raakte."

Hierop besloot ProtonMail de DKIM-keys te roteren om zo te voorkomen dat de spamberichten door de DKIM-controle kwamen. Tevens werd Google gewaarschuwd dat een oplossing aan het spamfilter van Gmail toevoegde, waardoor legitieme e-mails weer aankwamen. Afsluitend geeft Butler verschillende adviezen, zoals het instellen van SPF, DKIM en DMARC en het regelmatig roteren van DKIM-keys.

Image

Reacties (12)
14-01-2022, 12:44 door Briolet
Mijn eerste reactie was het meegeven van een geldigheidsduur van de DKIM via de 'x' parameter. Default is oneindig geldig.

Maar in de RFC lees ik echter letterlijk:
INFORMATIVE NOTE: The "x=" tag is not intended as an anti-
replay defense.

DKIM geeft alleen aan dat de mail onveranderd is sinds het de protonmail server verlaten heeft. Als je de mail naar jezelf stuurt en dezelfde mail later naar anderen zonder iets te veranderen, blijft de DKIM geldig. Tenslotte is het ook de identieke mail die protonmail eerder verstuurd heeft.

Dat is het probleem van een DKIM ondertekening door een publiek toegangkelijke email dienst. Iedereen kan in principe via protonmail versturen.
14-01-2022, 12:50 door Anoniem
Als protonmail aan de ondertekening met hun DKIM key een of andere reputatie wil verbinden, dan moeten ze zelf daar
op cotroleren. Dus uitgaande spam scanning doen en berichten die ook maar enigszins twijfel richting spam zijn niet
DKIM signen. Maar goed dat hebben ze nu wel geleerd denk ik.
14-01-2022, 15:51 door Anoniem
Ze proberen van alles om protonmail (een op privacy gerichte en encryptie versleutelde email dienst)
een slechte naam te bezorgen,of het nu direct of indirect wel of niet met protonmail te maken
heeft hun naam moet weer genoemd worden en of beschuldigingen
verwijzend naar protonmail,de negatieve berichten druppelen
langzaam wat vaker binnen maar ze houden hun zijn rug recht,alleen maar goed.

I love protonmail,keep on the good work with privacy and encryption

The Matrix
14-01-2022, 21:32 door Briolet
Door Anoniem: Als protonmail aan de ondertekening met hun DKIM key een of andere reputatie wil verbinden, dan …
Dus uitgaande spam scanning doen en berichten die ook maar enigszins twijfel richting spam zijn niet
DKIM signen.

Klopt. Dat is ook het enige wat ze noemen over wat ze zelf doen om dit soort aanvallen te voorkomen: zeer uitgebreide spam checking.

Verder geven ze een paar adviezen voor andere domeineigenaren die verder gaan dan hun eigen maatregelen. Een van de adviezen is om ook het BCC veld op te nemen in de ondertekening. Dit is natuurlijk heel effectief omdat de aanvaller het BCC veld dan niet meer kan vullen met nieuwe adressen en dan de mail weer verzenden.

Standaard wordt het BCC veld overgeslagen bij ondertekening, want anders kunnen ontvangers hun mail niet meer forwarden als er de verzender er BCC adressen aan toegevoegd heeft. Er bestaan wel protocollen, zoals ARC, om dat forwarden toch nog mogelijk te maken, maar blijkbaar verwacht protonmail problemen als ze zelf het BCC veld meenemen in de DKIM ondertekening. Iets als ARC wordt nog lang niet overal ondersteunt.

En klanten te vragen om niet meer te forwarden met behoud van de originele afzender van proton mail is voor velen ook teveel gevraagd.
15-01-2022, 11:41 door Anoniem
Als je gebruik maakt van een custom domain bij ProtonMail dan heb je hier heen last van gehad
Ik ben ook benieuwd of het premium domein, pm.me ook beïnvloed was?
15-01-2022, 11:47 door Anoniem
Door Briolet:
Verder geven ze een paar adviezen voor andere domeineigenaren die verder gaan dan hun eigen maatregelen. Een van de adviezen is om ook het BCC veld op te nemen in de ondertekening. Dit is natuurlijk heel effectief omdat de aanvaller het BCC veld dan niet meer kan vullen met nieuwe adressen en dan de mail weer verzenden.

Standaard wordt het BCC veld overgeslagen bij ondertekening, want anders kunnen ontvangers hun mail niet meer forwarden als er de verzender er BCC adressen aan toegevoegd heeft.

Hier valt mijn mond toch wel even bij open... het BCC veld opnemen in de ondertekening???
Het BCC veld wordt helemaal niet mee gestuurd in de mail! Hoe kun je dat nou opnemen in de ondertekening.
Zelfs als je zou zeggen "dan moet de verzender een pseudo BCC veld maken en dat mee nemen in de ondertekening" dan nog gaat dit niet werken want de ontvanger beschikt daar niet over (dat is nou net de crux van BCC) en dus kan die dan die handeling niet herhalen om de ondertekening te checken!

Nee, als ze dit schrijven hebben ze even iets te snel gedacht.
15-01-2022, 13:43 door Anoniem
Door Briolet:
Een van de adviezen is om ook het BCC veld op te nemen in de ondertekening. Dit is natuurlijk heel effectief omdat de aanvaller het BCC veld dan niet meer kan vullen met nieuwe adressen en dan de mail weer verzenden.

Standaard wordt het BCC veld overgeslagen bij ondertekening, want anders kunnen ontvangers hun mail niet meer forwarden als er de verzender er BCC adressen aan toegevoegd heeft.
https://datatracker.ietf.org/doc/html/rfc6376#section-5.4
Signers SHOULD NOT sign an existing header field likely to be legitimately modified or removed in transit.
https://datatracker.ietf.org/doc/html/rfc5321#appendix-B
1) Any BCC header fields SHOULD then be removed from the header section.
15-01-2022, 16:59 door Anoniem
Maar wacht is even, SPF, DMARC én DKIM zijn toch allen maatregelen die bedoeld zijn om spoofing te voorkomen? Of mis ik hier nu iets?

Is het niet in de basis raar dat een spamfilter van Google (Gmail) aan spam (niet zijnde ge-spoofde berichten) gevolgen verbindt die een DKIM-key?
15-01-2022, 17:09 door Ruben89
Maar wacht is even, SPF, DMARC én DKIM zijn toch allen maatregelen die bedoeld zijn om spoofing te voorkomen? Of mis ik hier nu iets?

Is het niet in de basis raar dat een spamfilter van Google (Gmail) aan spam (niet zijnde ge-spoofde berichten) gevolgen verbindt die een DKIM-key?
16-01-2022, 20:50 door botbot - Bijgewerkt: 16-01-2022, 20:51
"Regelmatig wisselen van de DKIM keys."

Ehhh kan iemand mij dan uitleggen wat regelmatig is, en waarom zou je het bij wijze van spreken niet elke dag doen? ("bij wijze van spreken" omdat soms email een paar dagen in de uitgaande queue kan hangen bijvoorbeeld en bij het dagelijks wisselen van de key kan het dus nooit goed aankomen in dat geval)....

Maar/Want als regelmatig elke maand is dan had het die protonmail aaval niet kunnen redden, want binnen een paar dagen (1 of 2 zal het geweest zijn) waren ze geblocked met een ongeldige key.
17-01-2022, 15:31 door Briolet
Door Anoniem: [Hier valt mijn mond toch wel even bij open... het BCC veld opnemen in de ondertekening???
Het BCC veld wordt helemaal niet mee gestuurd in de mail! Hoe kun je dat nou opnemen in de ondertekening.

Hoe denk je dat een mailserver weet waar de BCC adressen heen moeten? Precies. Dit veld staat natuurlijk in de mail en kan gecontroleerd worden. Het enige speciale van dit veld is dat de mailserver dit veld verwijdert voordat hij de mail bij de ontvanger aflevert.
17-01-2022, 20:52 door Anoniem
Door Briolet:
Door Anoniem: [Hier valt mijn mond toch wel even bij open... het BCC veld opnemen in de ondertekening???
Het BCC veld wordt helemaal niet mee gestuurd in de mail! Hoe kun je dat nou opnemen in de ondertekening.

Hoe denk je dat een mailserver weet waar de BCC adressen heen moeten? Precies. Dit veld staat natuurlijk in de mail en kan gecontroleerd worden. Het enige speciale van dit veld is dat de mailserver dit veld verwijdert voordat hij de mail bij de ontvanger aflevert.
Met als gevolg dat DKIM dan altijd fout zal zijn!

(Andere anoniem)
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.