Security Professionals - ipfw add deny all from eindgebruikers to any

DMARC bypass (Outlook only?)

29-08-2022, 13:40 door Erik van Straten, 21 reacties
TL;DR: markeren als "veilige afzender" kan spoofing mogelijk maken, wellicht niet alleen in Outlook

Inleiding
Securitybedrijf Mitiga schreef op 24 augustus twee gerelateerde artikelen:
1) "Advanced BEC Scam Campaign Targeting Executives on O365"
https://www.mitiga.io/blog/advanced-bec-scam-campaign-targeting-executives-on-o365

2) "Advisory: Persistent MFA Circumvention in an Advanced BEC Campaign on Microsoft 365 Targets"
https://www.mitiga.io/blog/persistent-mfa-circumvention-in-an-advanced-bec-campaign-on-microsoft-365-targets

Het zijn wat lange en soms slordige artikelen met een mix van http en https links (en enkele duidelijk verkeerde link), maar m.i. toch lezenswaardig.

Het tweede artikel beschrijft vooral hoe kansloos MFA is tegen aanvallen met proxies zoals ik onder meer beschreef in https://security.nl/posting/764738, maar ook dat Microsoft jou (en een cybercrimineel) niet opnieuw om een TOTP-code vraagt om een nieuwe QR-code te genereren zodat je (of de cybercrimineel) een nieuw TOTP-device kan koppelen (Nb. voor zover dat zin heeft, als jij en de cybercrimineel snel zijn, kan de cybercrimineel de vorige TOTP code wellicht hergebruiken). Misschien besteed ik hier nog een aparte bijdrage aan.

DMARC bypass
Het eerste artikel bevat ook een m.i. interessant deel, namelijk over een phishing e-mail die een executive ontving (ik neem alleen de relevante fragmenten over, vette opmaak onderin door mij):
Phishing Email
[...]
The sender appears to be a legitimate DocuSign address (dse@docusign.net), However, it is a spoofed address.
[...]
Microsoft tags this email as a phishing attempt (since it does not pass DMARC security checks), however, due to a misconfiguration in the client environment, the email was not blocked and appeared as legitimate in the executive’s email inbox.
[...]
DocuSign provides a list of email addresses it uses to send emails, including dse@docusign.net and recommends marking them as safe sender.

Met andere woorden, markeren als "veilige afzender" kan DMARC checks (en dus ook de onderliggende SPF en/of DKIM checks) elimineren, waardoor mails met gespoofde afzenders in inboxes kunnen belanden.

Mijn advies is om DMARC-fails te droppen, of van niet te missen waarschuwingen te voorzien.
Reacties (21)
29-08-2022, 16:38 door Briolet
Interessant Erik.

It is important to note that this misconfiguration can be a result of guidance provided by DocuSign to eliminate false positive spam alerts. DocuSign provides a list of email addresses it uses to send emails, including dse@docusign.net and recommends marking them as safe sender. This can easily be misinterpreted and lead to disabling email security checks for these email addresses, enabling an attack such as this.

Toch een beetje vreemd. Als je een afzender als 'veilig' bestempelt, zou dat juist de security checks moeten activeren om te verifiëren dat dit ook de afzender is.

Dus meer buggy mail software dan een verkeerde configuratie door de gebruiker.
29-08-2022, 20:48 door Anoniem
Met andere woorden, markeren als "veilige afzender" kan DMARC checks (en dus ook de onderliggende SPF en/of DKIM checks) elimineren, waardoor mails met gespoofde afzenders in inboxes kunnen belanden.

Dit is helaas een foute conclusie. De bron vermeld het verder wel duidelijk:
Microsoft tags this email as a phishing attempt (since it does not pass DMARC security checks), however, due to a misconfiguration in the client environment, the email was not blocked and appeared as legitimate in the executive’s email inbox.


De Office 365 omgeving (tenant) was verkeerd geconfigureerd. Waarschijnlijk heeft een systeembeheerder (in ieder geval iemand met admin rechten) de afzender in een algemene whitelist gezet of DMARC volledig uitgezet. Ik heb dit soort stomme fouten wel vaker gezien.

Daarnaast wordt hier verder op in gegaan:
It is important to note that this misconfiguration can be a result of guidance provided by DocuSign to eliminate false positive spam alerts. DocuSign provides a list of email addresses it uses to send emails, including dse@docusign.net and recommends marking them as safe sender. This can easily be misinterpreted and lead to disabling email security checks for these email addresses, enabling an attack such as this. While this article discusses spam filters, it can easily be misinterpreted and lead to disabling email security checks for these email addresses, enabling an attack such as this.

Anyway, menselijke configuratie fout dus. Als ze niet met hun poten aan het spamfilter hadden gezeten was deze mail gewoon als spam of phishing gemarkeerd gezet. De les van de dag is wederom: You pay peanuts, you get monkeys...

PS. Microsoft waarschuwt hier zelfs duidelijk voor op hun site. Je moet nooit whitelisten op email of IP adressen.
30-08-2022, 00:04 door Anoniem
Door Anoniem:DocuSign provides a list of email addresses it uses to send emails, including dse@docusign.net and recommends marking them as safe sender. This can easily be misinterpreted and lead to disabling email security checks for these email addresses
Inderdaad dat soort "advies" zie je wel vaker... het zou beter zijn om dat foute advies aan te pakken ipv de gevolgen
van het verkeerd navolgen proberen te bestrijden.
Ook is er natuurlijk sprake van een verwarrende terminologie. "safe sender", "whitelisten", dat zet mensen op het
verkeerde been.
30-08-2022, 11:29 door Briolet
Door Anoniem: PS. Microsoft waarschuwt hier zelfs duidelijk voor op hun site. Je moet nooit whitelisten op email of IP adressen.

Vreemd advies. Waarop zou je anders moeten whitelisten? Dat geeft eerder aan dat hun mailserver niet goed doordacht is. Als je op email adres whitelist mag dat nooit de check overslaan op legitimiteit van dat email adres. Dus spf, dkim, dmarc etc moet je nog steeds doen om te checken of het adres gespoofed is. Je kunt alleen de spam checks overslaan als het adres ge-whitelist is.
30-08-2022, 12:03 door Erik van Straten
In aanvulling op wat Briolet schrijft (waarvoor dank):
29-08-2022, 20:48 door Anoniem:
[Door Erik van Straten:] Met andere woorden, markeren als "veilige afzender" kan DMARC checks (en dus ook de onderliggende SPF en/of DKIM checks) elimineren, waardoor mails met gespoofde afzenders in inboxes kunnen belanden.

Dit is helaas een foute conclusie.
Ik waardeer aanvullingen, correcties en zelfs kritiek - mits goed onderbouwd, maar jij bent aan het trollen en zwetst uit je nek.

29-08-2022, 20:48 door Anoniem: De Office 365 omgeving (tenant) was verkeerd geconfigureerd. Waarschijnlijk heeft een systeembeheerder (in ieder geval iemand met admin rechten) de afzender in een algemene whitelist gezet of DMARC volledig uitgezet.
Totale onzin. De lijst met "Safe Senders" wordt door gebruikers zelf beheerd.

Naar verluidt kan een beheerder middels een GPO het gebruik van "Safe Senders" in Outlook blokkeren (tenzij policies zijn uitgeschakeld omdat je niet een van de veel duurdere Office licenties gebruikt) en in de web client werken policies sowieso niet.

Als een gebruiker dse@docusign.net toevoeg aan "Safe Senders", verwacht die gebruiker niet dat voortaan ook e-mails met gespoofde afzender als "Safe" worden behandeld.

En beheerders, die weten wat DMARC e.d. is, verwachten niet dat de uitkomst van de DMARC-check vervolgens genegeerd wordt door Microsoft Exchange, en gebruikers daardoor mails met gespoofde afzenders in hun inbox krijgen.

Dit is gewoon een blunder van Microsoft.

Na googlen zag ik dat eerder anderen al op deze blunder hebben gewezen, zoals:
https://www.linkedin.com/pulse/safe-senders-list-loophole-through-your-exchange-security-r%C3%B8rvik

https://regarding365.com/email-overrides-are-not-best-practice-942a02ba8aec

29-08-2022, 20:48 door Anoniem: Anyway, menselijke configuratie fout dus. Als ze niet met hun poten aan het spamfilter hadden gezeten was deze mail gewoon als spam of phishing gemarkeerd gezet.
Je maakt dezelfde stomme fout als Microsoft, namelijk spam en/of phishing op dezelfde hoop gooien als spoofing.

(Microsoft leert nooit, 17+ jaar geleden: https://www.security.nl/posting/10403/Waarom+SPF+en+FairUCE+op+termijn+geen+spam+bestrijden).

M.b.t. DMARC
DMARC (bouwend op SPF of DKIM) is géén antispammaatregel, maar antispoofing (niets belet hufters om vanaf een eigen afzenderdomein spam en/of phishingmails te verzenden met correcte SPF, DKIM en DMARC attributen).

Ik kan me tijdelijke uitzonderingssituaties voorstellen waarbij, als gevolg van configuratiefouten, de DMARC-check onbedoeld een negatieve uitkomst heeft, en je dergelijke mails niet wilt droppen - maar dan wel voorzien van toeters en bellen in de spambox of desnoods de inbox wilt plaatsen. Dit zou echter niets met "Safe Senders" te maken moeten hebben, want hier is niets Safe aan.

Eventueel kun je een negatieve DMARC-uitkomst gebruiken als één van de inputs van je spamfilter (positief zou ik negeren), om, als het tevens om spam lijkt te gaan, te besluiten alsnog te droppen of om aanvullende toeters en bellen aan de mail toe te voegen.

DMARC en dergelijke zijn al halve maatregelen, nl. omdat SMTP-from niet altijd getoond wordt, ontvangers er niet op letten en als ze dat wel doen, niet weten dat afzenderdomein X niet van de kennelijke afzender is.

Voor ontvangers die wel het afzenderdomein checken en weten (of uitzoeken) dat dit domein van de kennelijke afzendende partij is, is DMARC zeker zinvol, maar met dit soort idioterie van Microsoft kunnen we -wat mij betreft- stoppen met DMARC et al.

29-08-2022, 20:48 door Anoniem: PS. Microsoft waarschuwt hier zelfs duidelijk voor op hun site. Je moet nooit whitelisten op email of IP adressen.
Helemaal niet "duidelijk": ik moest er flink naar zoeken, met als resultaat zeer veel pagina's die vooral beschrijven hoe handig "Safe Senders" is en het gebruik ervan aanmoedigen, zonder ook maar één waarschuwing daarbij.

De duidelijkste waarschuwingen vond ik (niet bovenaan) in https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/create-safe-sender-lists-in-office-365?view=o365-worldwide:
Create safe sender lists in EOP
Article 08/19/2022
[...]
If you're a Microsoft 365 customer with mailboxes in Exchange Online or a standalone Exchange Online Protection (EOP) customer without Exchange Online mailboxes, EOP offers multiple ways of ensuring that users will receive email from trusted senders. These options include Exchange mail flow rules (also known as transport rules), Outlook Safe Senders, the IP Allow List (connection filtering), and allowed sender lists or allowed domain lists in anti-spam policies. Collectively, you can think of these options as safe sender lists.

The available safe sender lists are described in the following list in order from most recommended to least recommended:

    1. Mail flow rules
    2. Outlook Safe Senders
    3. IP Allow List (connection filtering)
    4. Allowed sender lists or allowed domain lists (anti-spam policies)

Mail flow rules allow the most flexibility to ensure that only the right messages are allowed. Allowed sender and allowed domain lists in anti-spam policies aren't as secure as the IP Allow List, because the sender's email domain is easily spoofed. But, the IP Allow List also presents a risk, because email from any domain that's sent from that IP address will bypass spam filtering.
Hoezo zou een lezer plaats 2 van 4 in een lijstje met volgorde "most recommended to least recommended" als "not recommended" moeten beschouwen (zoals verderop blijkt)? Dit artikel spreekt zichzelf tegen.

Daaronder volgt een lichtblauwe "information box" met pas bij de derde bullet de volgende tekst:
• While you can use safe sender lists to help with false positives (good email marked as bad), you should consider the use of safe sender lists as a temporary solution that should be avoided if possible. We don't recommend managing false positives by using safe sender lists, because exceptions to spam filtering can open your organization to spoofing and other attacks. If you insist on using safe sender lists to manage false positives, you need to be vigilant and keep the topic Report messages and files to Microsoft at the ready.
Met andere woorden, we maken superhandige "Safe Sender Lists" maar tussen neus en lippen door zeggen we "Do Not Use" want we hebben een aanpak die anders is dan weldenkende mensen verwachten.

Pas een stuk verderop, direct onder het kopje "Use Outlook Safe Senders" (niet: "Do Not Use Outlook Safe Senders") staat een roze box met de tekst:
(X) Caution
This method creates a high risk of attackers successfully delivering email to the Inbox that would otherwise be filtered; however, the user's Safe Senders or Safe Domains lists don't prevent malware or high confidence phishing messages from being filtered.

Maar het is natuurlijk een illusie dat eindgebruikers dit lezen, laat staan begrijpen dat in Microsoft's denkwereld "Safe Senders" gelijk staat aan "bypass DMARC" en dus "Allow Spoofing".
30-08-2022, 12:23 door Anoniem
Door Erik van Straten 12:03:DMARC en dergelijke zijn al halve maatregelen, nl. omdat SMTP-from niet altijd getoond wordt, ontvangers er niet op letten en als ze dat wel doen, niet weten dat afzenderdomein X niet van de kennelijke afzender is.
Misschien begrijp ik je hier verkeerd, maar DMARC gaat altijd over het header-from (RFC5322) adres, het adres dat in je mailprogramma wordt getoond en niet over het envelope-from (RFC5321) adres!
30-08-2022, 12:54 door Erik van Straten
Als aanvulling hoe tegenstrijdig Microsoft's adviezen zijn, bijna onderin https://docs.microsoft.com/en-gb/microsoft-365/security/office-365-security/set-up-anti-phishing-policies?view=o365-worldwide staat een roze box met:
(!) Note
If Microsoft 365 system messages from the following senders are identified as impersonation attempts, you can add the senders to the trusted senders list:

  - noreply@email.teams.microsoft.com
  - noreply@emeaemail.teams.microsoft.com
  - no-reply@sharepointonline.com
Go figure...
30-08-2022, 14:29 door Erik van Straten
Door Anoniem:
Door Erik van Straten 12:03:DMARC en dergelijke zijn al halve maatregelen, nl. omdat SMTP-from niet altijd getoond wordt, ontvangers er niet op letten en als ze dat wel doen, niet weten dat afzenderdomein X niet van de kennelijke afzender is.
Misschien begrijp ik je hier verkeerd, maar DMARC gaat altijd over het header-from (RFC5322) adres, het adres dat in je mailprogramma wordt getoond en niet over het envelope-from (RFC5321) adres!
Sorry, ik had duidelijker kunnen zijn: met "SMTP-from" bedoel ik het feitelijke (door SMTP "begrepen") deel dat in principe tussen <> geschreven wordt.

Bij een afzender zoals:
"DocuSign" <dse@docusign.net>
toont een deel van de mail clients (MUA's), vooral mobiel, slechts:

From: DocuSign
in plaats van:
From: DocuSign <dse@docusign.net>

Nb. dat MUA's "" weggelaten vind ik geen probleem, maar ik wil wel dat tweede deel zien. Want als DMARC checkt (en Microsoft een negatief resultaat niet weggooit "want Safe Sender"), dan vindt die check -in dit geval- plaats op docusign.net.

Dan hoef ik "alleen nog maar" te weten dat het domein docusign.net van het bekende bedrijf DocuSign is (zo niet dan weet ik hoe ik dat op moet zoeken, wat helaas niet voor iedereen geldt).

Overigens zouden MUA's van mij een slotje mogen tonen als er betrouwbaar op DMARC gecheckt is en het resultaat positief is, maar erg lastig is dan wel dat je dan alle gebruikers moet uitleggen dat je daar bar weinig aan hebt bij bijvoorbeeld @gmail.com (alleen afzenderdomein wordt gecheckt) en dat er ook nog zoiets bestaat als BEC (Business Email Compromise) - dat niet alleen zakelijke gebruikers treft (nog even los van het feit of elke DocuSign medewerker te vertrouwen valt).

Het blijft tobben met de authenticiteit, betrouwbaarheid, vertrouwelijkheid en beschikbaarheid van e-mail, en Microsoft weet het ook nog eens onnodig ondoorzichtig te maken...
30-08-2022, 15:02 door Erik van Straten
Als ik https://support.microsoft.com/en-us/office/add-recipients-of-my-email-messages-to-the-safe-senders-list-be1baea0-beab-4a30-b968-9004332336ce goed begrijp, is Microsoft nog stommer en nog tegenstrijdiger dan ik al dacht (verbeter me s.v.p. als het anders werkt dan ik opmaak uit die pagina, bevestigingen zijn ook welkom natuurlijk).

Daaruit:
By default, email addresses in your Outlook contacts are considered safe senders by the Junk Email Filter, but you can change this setting. Email messages from safe senders are never moved to the Junk E-mail folder.

Dus als je n.a.v. mijn post bovenaan deze pagina jouw lijst met "Safe Senders" hebt leeggemaakt, zul je ook de instructies onderaan die Microsoft-pagina moeten opvolgen om te voorkomen dat jouw contacten ook allemaal "Safe Senders" zijn en blijven. In plaats daarvan kun je natuurlijk ook al jouw contacten verwijderen (daarmee bedoel ik de contactgegevens die jij van hen hebt ;-)

Weer serieus: alle marketing-speak van Microsoft over hun omarming van "Zero Trust" is, tot nu toe, gebakken lucht gebleken. Het is m.i. de hoogste tijd dat dit soort "geen daden maar woorden"-producenten financieel aansprakelijk worden gesteld voor de vele "datalekken" (o.a. ransomware en uitlekken van vertrouwelijke gegevens) waar zij op z'n minst mede voor verantwoordelijk zijn.
30-08-2022, 16:45 door Briolet
By default, email addresses in your Outlook contacts are considered safe senders by the Junk Email Filter, but you can change this setting. Email messages from safe senders are never moved to the Junk E-mail folder.

Op zich is het koppelen met je adresboek een handige zet. Bij mij zet de mailserver junk direct in de junk folder. Mijn eigen mail client bekijkt vervolgens de inbox nog een keer en verplaatst alle mail met een afzender die niet in mijn adresboek staat, naar een postbus "onbekende afzenders". (Via een filterregel)

Gespoofde afzenders haalt de mailserver er dan al uit (Spambox of bouncen) en gelijkende afzenders worden ook uit de inbox geweerd. De inbox blijft zo betrouwbaar. En de onbekende afzenders worden extra gecontroleerd en indien goedgekeurd, aan mijn adresboek toegevoegd.

----
Het probleem van Microsoft lijkt te zijn dat de mailserver zowel spam als gespoofde mail in de spambox plaatst en hun mail cliënt bij whitelisted afzenders, deze mail weer naar de inbox verplaatst zonder in de header te kijken of deze mail vanwege spoofing in de spambox terecht gekomen was.

Gewoon een super stomme denkfout. In plaats van het plaatsen van waarschuwingen in hun handleidingen, hadden ze beter het probleem van hun mail cliënt kunnen oplossen. Want blijkbaar waren ze op de hoogte van dit probleem. Het bedrijf is te log en de schrijvers van handleidingen praten blijkbaar niet met de programmeurs als ze problemen zien.
31-08-2022, 22:23 door Anoniem
Soms vragen bedrijven je in hun e-mail om hun the allowlisten. Dit is een van de redenen dat je dat niet moet doen.
Als een mail legitiem is en hij wordt toch tegengehouden dan is dat onderzoek waardig, dat moet je niet willen corrigeren met allowlists.
13-09-2022, 01:09 door Anoniem
Hmm ja e.a. valt op Microsoft met spoofing zaken klopt eigenlijk wel.

Maar best veel echt grote partijen hun mail en hun mailsystemen en servers ook al hebben ze ( is vaak ook niet zo) dmarc, dkim en spf en eventueel meer) op orde zijn in basis nog steeds zeer veel voorkomende spam emailadresen en of erger zelfs zonder spoofing.

Ze houden hun eigen hok overduidelijk niet schoon! ( op zijn minst niet op tijd) zo ook hun cloud oplossingen bieden nog steeds heel veel scammers teveel ruimte.

Wat dan gek is als andere kleinere partijen wel alles, dmarc, dki, spf, dnssec ezn op orde hebben en ook de EU test en score betwrouwbare mail optimaal, blokken ze toch als smap of grey list enz. ( ip zelf clean en indien je de report functie gebruikt schrijven ze dat alles ok is , dat moet je dan nog 1 tot 2 keer doorlopen pas daarna krijg je manuele aandacht en kan je het oplossen.

Zoiets is natuurlijk "oneerlijke mededinging" en komt andersom niet voor.

Ook zonder dat je spamt en ip toch clean is en blijft moet dat alles soms vaker.

Ik wil dus aanhalen dat het gehele dmarc, dkim, spf enz door in ieder geval Microsoft op meerdere vlakken niet juist aangepakt is van twee kanten bekeken.

Waarbij jammer dat de grote partijen onderling grote "whitelisten" naja white in ieder geval mails vertrouwen en doorlaten waar niet uitmaakt of scam.
En anderen tevaak op "verborgen" listen of procedures aangwezen zijn om bij die partijen wel goed met hun mailserver systemen door te komen.
Maakt ook niet uit of je aangifte doet van deze praktijken AP en co lijken geen tijd te hebben , en de grotere hosters moeten dan ook vaak andere oplossingen voor mail aan hun klanten aanbieden, die treden niet op tegen microsoft want ze zijn ook partner!
13-09-2022, 01:16 door Anoniem
Door Anoniem: Soms vragen bedrijven je in hun e-mail om hun the allowlisten. Dit is een van de redenen dat je dat niet moet doen.
Als een mail legitiem is en hij wordt toch tegengehouden dan is dat onderzoek waardig, dat moet je niet willen corrigeren met allowlists.

Naja na onderzoek kan er dus wel degelijk een geldige reden zijn om dat toch te doen, bijvoorbeeld hen te helpen een goed mail reputatie op te bouwen indien werkelijk legitiem kan reeds een reden zijn.
Als ze via verschillende oplossingen via thuiswerken en dus mogelijk andere ip in client van providers gebruiken kunnen deze grey listed zijn en dus vertraging geven enz.
Of net een nieuwe IP die nog geen reputatie heeft en of voorheen block abuse list enz....

Wel dienen die partijen dan minstens spf, dmarc, en dkim op orde te hebben vind ik, en moet dit spf streng ingesteld zijn dat een fail daar ook echt een blok op gaat leveren, ( ook zou ik niet hele maildomain toelaten maar specifiek adres maar ok)
13-09-2022, 11:32 door Erik van Straten - Bijgewerkt: 13-09-2022, 11:33
Door Anoniem:
Door Anoniem: Soms vragen bedrijven je in hun e-mail om hun the allowlisten. Dit is een van de redenen dat je dat niet moet doen.
Als een mail legitiem is en hij wordt toch tegengehouden dan is dat onderzoek waardig, dat moet je niet willen corrigeren met allowlists.

Naja na onderzoek kan er dus wel degelijk een geldige reden zijn om dat toch te doen [...]
Maar is dat verstandig?

Als e-mails die echt afkomstig zijn van "piet@example.com", om welke reden dan ook, in jouw spambox belanden of worden geweigerd door jouw ontvangende mailserver, dan kun je dat e-mail adres "allowlisten". Probleem opgelost zou je zeggen. Totdat een aanvaller weet dat genoemd e-mailadres in jouw allowlist zit, want dan kan die aanvaller vanaf een willekeurige mailserver liegen dat hij of zij "piet@example.com" is. Tot zover "security by obscurity".

Anders wordt het als een bedrijf als Docusign aanraadt om "dse@docusign.net" te allowlisten, en mensen die dat doen niet weten dat ze daarmee de deur openzetten voor e-mails met vervalste afzender. Aanvallers kunnen gokken dat jij Docusign gebruikt of dat wellicht op internet vinden (bijv. omdat je er op een forum een vraag over gesteld hebt), en gokken dat jij "dse@docusign.net" in jouw allowlist hebt.

Door Anoniem: Wel dienen die partijen dan minstens spf, dmarc, en dkim op orde te hebben vind ik, en moet dit spf streng ingesteld zijn dat een fail daar ook echt een blok op gaat leveren [...]
Als gebruiker weet je niet welk criterium doorslaggevend is: jouw "allowlist" of maatregelen "onder water" waaronder "hard fail" of "soft fail". En als je dat wel hebt uitgezocht kan het morgen weer anders zijn (bijv. omdat andere gebruikers een probleem hebben aangekaart).

Daar komt bij dat de meningen verdeeld zijn over wat de juiste instellingen zijn voor o.a. SPF en DMARC (bijvoorbeeld omdat indien een forwarder geen SRS heeft, mails met SPF "-all" niet aankomen). Zie bijvoorbeeld deze (m.i. tekenende) discussie: https://tweakers.net/nieuws/182316/e-mail-spoofing-was-mogelijk-bij-domein-testen-voor-toegang.html?showReaction=16117012#r_16117012.

SPF/DKIM/DMARC blijft half werk, gecompliceerd en foutgevoelig, nog los van dat veel ontvangers het echte afzenderadres niet checken (of niet eens te zien krijgen in hun mail client).
13-09-2022, 14:02 door Briolet
Door Erik van Straten:Als e-mails die echt afkomstig zijn van "piet@example.com", om welke reden dan ook, in jouw spambox belanden of worden geweigerd door jouw ontvangende mailserver, dan kun je dat e-mail adres "allowlisten". Probleem opgelost zou je zeggen. Totdat een aanvaller weet dat genoemd e-mailadres in jouw allowlist zit, want dan kan die aanvaller vanaf een willekeurige mailserver liegen dat hij of zij "piet@example.com" is. Tot zover "security by obscurity".

In mijn optiek zou je zo'n mail moeten kunnen whitelisten, maar blijkbaar zijn er mailclienten (Outlook?) die dan ook gespoofde mail weer doorlaten. Gespoofde mail zou ook met ge-whiteliste mail niet doorgelaten mogen worden.

Er zijn bedrijven die zelf mail spoofen, maar als die niet aankomt is het eerder zaak van de verzender dan van de ontvanger om hier wat aan te doen.

Als voorbeeld kwam ik gespoofde mail van de ziggo helpdesk tegen. Dit zal een externe helpdesk geweest zijn die hun eigen mailserver gebruikt om de mail namens Ziggo te versturen. Bij mij kwam die mail wel binnen omdat Ziggo hun dmarc indertijd nog op policy=none had staan. Het is niet aan mij om mijn beveiliging te verlagen om de mail binnen te krijgen, maar die helpdesk moet via de Ziggo mailserver gaan versturen, of Ziggo moet de externe mailserver opnemen in hun spf allow-lijst.

Ik moet toegeven dat dmarc voor een klein bedrijf als wij zijn, een stuk eenvoudiger te implementeren is dan bij een groot versplinterd bedrijf met vele mailservers en ingehuurde afdelingen.
13-09-2022, 15:29 door Anoniem
Het is inderdaad wel heel krom dat er een koppeling is tussen "vertrouwde afzender" en "dan hoeven we DMARC niet te checken"! Dat zou eerder andersom moeten zijn: als je een adres op je lijst van vertrouwde afzenders zet dan word dit strenger gechecked dan wanneer dit niet het geval is.
Dan moet dit uiteraard wel een expliciet beheerde lijst zijn, niet "alle afzenders in je adresboek zijn vertrouwd".

Zoals meestal is het hele idee van "vertrouwd" niet als een simpele ja/nee vraag te beanwoorden. Vertrouwd voor WAT?
13-09-2022, 16:20 door Anoniem
Door Erik van Straten: TL;DR: markeren als "veilige afzender" kan spoofing mogelijk maken, wellicht niet alleen in Outlook

Met andere woorden, markeren als "veilige afzender" kan DMARC checks (en dus ook de onderliggende SPF en/of DKIM checks) elimineren, waardoor mails met gespoofde afzenders in inboxes kunnen belanden.

Mijn advies is om DMARC-fails te droppen, of van niet te missen waarschuwingen te voorzien.

Voor het droppen, daar is de DMARC Policy van de afzender voor: p=none / p=quarantine / p=reject

Als iemand jouw afzender domein met adres@voorbeeldje.local gebruikt dan kun je met een DMARC Policy in je DNS record aangeven wat er met email die vanuit naam van @voorbeeldje.local wordt verstuurd moet gebeuren, als de DKIM/SPF check mislukt. (met p=none, dan gebeurd er dus verder niks met de email en kan deze worden afgeleverd)

Maar als je dan DMARC Policy p=reject hebt ingesteld, dan komt deze email niet aan.
(Als de ontvangende mail server DMARC checkt)
13-09-2022, 18:27 door Anoniem
De manier hoe je omschrijft omzeilt DMARC helemaal niet. De safe sender list in de Outlook MUA zorgt er voor dat mail die eigenlijk in 'junk' afgeleverd wordt, nu in Inbox komt. Dat is wat anders.

Hoewel ik het er mee eens ben dat dat niet wenselijk is voor de gemiddelde gebruiker, omzeilt dit geen DMARC.

Het probleem is vooral dat Microsoft365 de DMARC-standaard niet volgt en p=reject negeert en de mail vrolijk bij de user aflevert. p=reject == p=quarantaine volgens MS, want anders mist de gebruiker misschien mail (false positives).

https://docs.microsoft.com/en-gb/microsoft-365/security/office-365-security/use-dmarc-to-validate-email?redirectedfrom=MSDN&view=o365-worldwide#how-microsoft-365-handles-inbound-email-that-fails-dmarc

Grappige (nou ja...) is dan ook weer dat MS vervolgens hier ook vertelt hoe je de mail ipv in de junk gewoon in je inbox krijgt, maar goed.

Kortom, met DMARC/DKIM/SPF is helemaal niet zoveel mis als je stelt, maar men moet e-mail wel op de juiste manier implementeren en de standaarden volgen, anders werkt het inderdaad maar half.
14-09-2022, 11:47 door Erik van Straten - Bijgewerkt: 14-09-2022, 12:35
Door Anoniem: Maar als je dan DMARC Policy p=reject hebt ingesteld, dan komt deze email niet aan. (Als de ontvangende mail server DMARC checkt)
Zie mijn antwoord hieronder.

Door Anoniem: De manier hoe je omschrijft omzeilt DMARC helemaal niet. De safe sender list in de Outlook MUA zorgt er voor dat mail die eigenlijk in 'junk' afgeleverd wordt, nu in Inbox komt. Dat is wat anders.
Als de DMARC check wel wordt uitgevoerd maar met een fail niets wordt gedaan als de afzender in de allowlist staat, is dat effectief toch bypassen van DMARC?!

In de link die je gaf (hier clickable en iets korter: https://docs.microsoft.com/en-gb/microsoft-365/security/office-365-security/use-dmarc-to-validate-email#how-microsoft-365-handles-inbound-email-that-fails-dmarc) staat klip en klaar (opmaak toegevoegd door mij):
How Microsoft 365 handles inbound email that fails DMARC
If the DMARC policy of the sending server is p=reject, Exchange Online Protection (EOP) marks the message as spoof instead of rejecting it. In other words, for inbound email, Microsoft 365 treats p=reject and p=quarantine the same way.
[...]
Microsoft 365 is configured like this because some legitimate email may fail DMARC. For example, a message might fail DMARC if it's sent to a mailing list that then relays the message to all list participants. If Microsoft 365 rejected these messages, people could lose legitimate email and have no way to retrieve it. Instead, these messages will still fail DMARC but they'll be marked as spam and not rejected.

If desired, users can still get these messages in their inbox through these methods:
    • Users add safe senders individually by using their email client.

[...]
Oftewel:
1) Fail wordt spoof
2) Afzender in allowlist: spoof wordt not spoof
Effectief: DMARC bypass

Door Anoniem: [...]Kortom, met DMARC/DKIM/SPF is helemaal niet zoveel mis als je stelt, maar men moet e-mail wel op de juiste manier implementeren en de standaarden volgen, anders werkt het inderdaad maar half.
Ik herhaal, en dat vind ik nog meer na te lezen dat er kennelijk nog steeds legitieme mail op Microsoft's servers wordt afgeleverd met (onnodige) DMARC fail:
SPF/DKIM/DMARC blijft half werk, gecompliceerd en foutgevoelig, nog los van dat veel ontvangers het echte afzenderadres niet checken (of niet eens te zien krijgen in hun mail client).
Ik mis steekhoudende argumenten in jouw post waarom dit niet zo zou zijn.

Aanvulling 12:35: de mogelijk grootste e-mail provider (vooral zakelijk), Microsoft, zegt hiermee tegen prutsers die SRS en dergelijke niet of niet goed implementeren, beloont hen in feite: "geeft niet, zeg gewoon tegen je gebruikers dat ze jou aan safe senders moeten toevoegen" - terwijl gebruikers er geen idee van hebben welke backdoor ze hiermee open zetten.

Daarmee ondermijnt Microsoft het hele systeem onder DMARC (nog los van dat veel ontvangers het echte afzenderadres niet checken - of niet eens te zien krijgen in hun mail client).

En daarom: SPF, DKIM en DMARC suck. Ontvangers en verzenders kunnen er niet op vertrouwen. Curiosity killed the cat, maar complexity kills the computer.
14-09-2022, 14:12 door Anoniem
"1) Fail wordt spoof"
Fail wordt helemaal geen spoof. Fail blijft fail. Alleen de manier hoe de ontvanger (MS) hier mee omgaat is niet volgens de voorschriften. Dat dit effectief hetzelfde resultaat oplevert, betekent niet dat dat de schuld van DMARC is.

"Ik mis steekhoudende argumenten in jouw post waarom dit niet zo zou zijn."

Nou, die missen bij jou net zo goed waarom het wel zo zou zijn. DMARC doet toch prima zijn werk? Geeft namelijk een fail wanneer het adres gespooft is. Dat de ontvanger (dat is Microsoft in dit geval, niet de MUA/gebruiker,) er voor kiest om dat resultaat te negeren, is niet de schuld van DMARC. En dat is ook precies de reden dat je statement "en daarom: SPF, DKIM en DMARC suck" kant nog wel steekt met de redenering die je aanvoert. Microsoft is hier de schuldige, niet spf/dkim/dmarc.
16-09-2022, 16:30 door Anoniem
Even de discussie nog vanuit een ander perspectief belichten. Ook hier werd gebruik gemaakt van een safelist voor mail (niet in M365 maar in een firewall onderdeel). Hierop stond ook een wetransfer mailadres. Wij hebben de proef op de som genomen en een spoof mail gestuurd vanuit dat mailadres met daarin ook een url via een shortener opgenomen. Het resultaat was dat deze netjes in de mailbox binnenkomt terwijl SPF, DKIM en DMARC failen.

De safelist zorgde er dus voor dat alle controles uitgeschakeld werden. Risico is dus dat wij daadwerkelijk een spoofmail krijgen met daarin een valse link waar een gebruiker op gaat klikken.

Ik denk dus dat een safelist, allowlist of whitelist alleen maar zorgen voor schijnveiligheid voor gebruikers. Je kunt geen mail volledige vertrouwen op basis van e-mailadres. Er zullen dus nog steeds aanvullende controles uitgevoerd moeten worden welke er vervolgens in resulteren dat de mail nog steeds als spam of quarantaine beoordeeld gaan worden.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.