FBI: verkeerd ingesteld DMARC-beleid misbruikt bij spearphishing-aanvallen
Aanvallers maken misbruik van verkeerd ingesteld DMARC-beleid bij het uitvoeren van spearphishing-aanvallen, zo claimen de FBI, de Amerikaanse geheime dienst NSA en het Amerikaanse ministerie van Buitenlandse Zaken in een waarschuwing (pdf). Domain-based Message Authentication, Reporting and Conformance (DMARC) is een protocol dat gespoofte e-mails moet detecteren en voorkomen.
DMARC wordt boven twee andere standaarden gebruikt, namelijk Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). Via DMARC kan een organisatie aangeven wat een e-mailserver moet doen met e-mails die niet aan het gepubliceerde SPF- en DKIM-beleid voldoen. Op deze manier kunnen spam en phishingmails worden gestopt.
Wanneer een organisatie DMARC-beleid op een veilige manier configureert, zorgt het ervoor dat aanvallers het e-maildomein van de organisaties bij het versturen van spearphishingberichten niet kunnen spoofen, aldus de Amerikaanse overheidsinstanties. Die stellen dat ze verschillende aanvallen hebben gezien die door verkeerd ingesteld DMARC-beleid mogelijk waren. Organisaties worden dan ook opgeroepen hun DMARC-beleid goed in te stellen. De aanvallen zijn volgens de diensten het werk van een Noord-Koreaanse groep genaamd Kimsuky.
DMARC staat op veel plekken nog op none, maar wel met reporting,
hoe vaak we nog meldingen krijgen dat mail niet voldoet (volgens bijv MS)
aan SPF en DKIM, terwijl beide gewoon correct zijn...
(meerdere domeinen, meerdere dns servers, zelfs MS eigen gehoste tennant naar MS die fouten geeft...)
Dus heel betrouwbaar m.b.t. de werking en het goed afleveren, als je zelf alles netjes doet...
Wij hebben onze eigen spam filters, die we handmatig na lopen,
hoe vaak wij ook gewoon foutmeldingen op dkim krijgen, van mails die gewoon legitiem zijn,
zelfs van bepaalde instanties, maar dan net via ander systeem verstuurd ofzo..
DMARC staat op veel plekken nog op none, maar wel met reporting,
hoe vaak we nog meldingen krijgen dat mail niet voldoet (volgens bijv MS)
aan SPF en DKIM, terwijl beide gewoon correct zijn...
(meerdere domeinen, meerdere dns servers, zelfs MS eigen gehoste tennant naar MS die fouten geeft...)
Dus heel betrouwbaar m.b.t. de werking en het goed afleveren, als je zelf alles netjes doet...
Wij hebben onze eigen spam filters, die we handmatig na lopen,
hoe vaak wij ook gewoon foutmeldingen op dkim krijgen, van mails die gewoon legitiem zijn,
zelfs van bepaalde instanties, maar dan net via ander systeem verstuurd ofzo..
Heel bijzonder, dit zijn al jaren gangbare standaarden en zou gewoon goed moeten werken (indien goed ingesteld).
Let wel op: het gaat vaak fout bij mailbox en meeting forwards. Extern ontvangen e-mail automatisch doorsturen naar een ander extern adres is niet mogelijk zonder de header from aan te passen (maar dit automatisch doorsturen wil je ook niet als organisatie).
Extern ontvangen meetings doorsturen naar een andere extern adres kan ook niet met een goed DMARC beleid.
Los van dat gaat het in 99% van de gevallen mis omdat organisaties hun SPF record niet goed hebben ingesteld.
Nee, juist is:
• Er sprake is van "SMTP sending domain alignment"
• Minstens één van de twee checks, SPF en DKIM, "OK" oplevert (als SPF klopt, maar een AitM de e-mail inhoudelijk heeft gewijzigd, merkt de ontvanger daar niets van).
Dit los van dat impersonatie een eitje is bij iets afwijkende domeinnamen. Of zelfs volstrekt afwijkende domeinnamen - omdat de ontvangende mens die domeinnaam niet ziet (in de door hen gebruikte software om ontvangen e-mails mee te lezen), geen idee heeft wat een domeinnaam is, geen idee heeft waarom je dat zou moeten weten en checken, en zo ja, -last but not least- gegeven een domeinnaam in een SMTP afzenderadres, geen enkele aanleiding ziet om aan te nemen dat die domeinnaam niet in het bezit van de kennelijke afzender (of diens opdrachtgever/werkgever) is.
Aan het kunnen bewijzen dat een e-mail is verzonden via "jouw" mailserver, heb je weinig tot niets als weinige of geen enkele ontvanger niet opmerkt dat een e-mail, die door jou verzonden lijkt, niet door jou verzonden is.
Nou nee hoor, de implementatie bij MS is niet geheel conform de standaard weet ik uit ervaring. Bij MS kijkt hun DMARC check niet alleen naar de dmarc domain records uit de mail headers [From field], maar ook die van de envelope [dus anders in geval een forwarder is gebruikt]. Heb je op de forwarder dan ook dmarc aan gezet met p=none, dan failt de MS dmarc check, heb je daarentegen geen dmarc records in de dns bij de forwarder, dan gaat de mail door ook al is er dus een SPF fail op de envelope maar niet op die van de From. Of je dan u wel of geen DKIM pass hebt [via domain uit header en dus niets met envelope te maken weer] dat doet er dan niet meer toe. Go figure...
De DMARC is helemaal niet verkeerd ingesteld en dat schrijft de FBI ook helemaal niet. Ze schrijven:
Het is niet verkeerd ingesteld, alleen niet bruikbaar tegen spoofing.
Volgens mij haal je dingen door elkaar. Ik ken MS niet, maar in een normale header staat het resultaat van de spf check van de envellope. Deze wordt nooit door DMARC gebruikt. Die doet zijn eigen check ernaast. En forwarders breken regelmatig de DMARC check. De spf faalt dan altijd en de DKIM check als ze de geforwarde tekst gaan veranderen.
Waarschijnlijk is er voor gekozen dat spf of dkim correct moet zijn en niet beide, zodat je nog mail kunt forwarden als je van de inhoud afblijft.
De DMARC is helemaal niet verkeerd ingesteld en dat schrijft de FBI ook helemaal niet. Ze schrijven:
Dat schrijven ze wel!
The Federal Bureau of Investigation (FBI), the U.S. Department of State, and the National Security Agency
(NSA) are jointly issuing this advisory to highlight attempts by Democratic People’s Republic of Korea (DPRK, a.k.a.
North Korea) Kimsuky cyber actors to exploit improperly configured DNS Domain-based Message Authentication,
Reporting and Conformance (DMARC) record policies to conceal social engineering attempts.
Omdat we niet veel mail versturen ( 15 tot 20 mails per week ) controleer ik elk rua bericht.
Wat opvalt zijn een aantal dingen, de quarantine geeft soms fail en soms pass.
policy_evaluated>
<disposition>quarantine</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
Ik heb alle combinaties van fail en pass al langs zien komen. Het lijkt er op of SPF en DMARC mechanisme veel verschillende implementatie vormen kent. En daardoor niet goed werkt.
Tot mijn grote ergernis komen juist verstuurde mail, bij veel ontvangers in de spam box.
Ook zijn er mailproviders die in de strijd tegen spam ook de PTR-record ( of Pointer Record ) controleren, ook dan belanden juist verduurde mail in de bulk mail box ( Yahoo ) of in de spam box.
…attempts by Democratic People’s Republic of Korea (DPRK, a.k.a.
North Korea) Kimsuky cyber actors to exploit improperly configured DNS Domain-based Message Authentication,
Reporting and Conformance (DMARC) record policies to conceal social engineering attempts.
Ik heb blijkbaar niet ver genoeg doorgelezen In het eerste stuk hadden ze het alleen over 'weak configuration". En een "policy=none" is ook niet direct fout. Er wordt zelfs aangeraden om hiermee te beginnen om zo je mailflow in kaart te brengen. Je moet er wel zo snel mogelijk weer vanaf stappen als je geen problemen meer ziet.
Omdat we niet veel mail versturen ( 15 tot 20 mails per week ) controleer ik elk rua bericht.
Wat opvalt zijn een aantal dingen, de quarantaine geeft soms fail en soms pass.
Ik kijk vooral naar de reports na een mailing. De ontvangers zijn kleine bedrijven, geen particulieren. Ik krijg veel spf fails. In het begin zelfs een kwart van de mails doordat blijkbaar veel ontvangers de mail naar hun domein ook nog eens forwarden naar een gmail of ander privé account. En dat doen ze blijkbaar met ons als afzender. Gelukkig blijven ze van de inhoud af en komt de mail toch nog aan vanwege een geldige dkim ondertekening. Een fail op dkim is een grote uitzondering.
Je bent niet ingelogd 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.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
