Versleutelde maildienst ProtonMail was slachtoffer van DKIM replay-aanval
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.
Maar in de RFC lees ik echter letterlijk:
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.
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.
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
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.
Ik ben ook benieuwd of het premium domein, pm.me ook beïnvloed was?
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.
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.
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?
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?
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.
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.
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.
(Andere anoniem)
Deze posting is gelocked. Reageren is niet meer mogelijk.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.