DMARC

Lately I've overheard some people discussing email spoofing with regard to organizations that don't implement DMARC. Namely, "APTs" taking advantage of organizations that don't utilize Domain-based Message Authentication, Reporting and Conformance.

Outside, and sometimes even inside, it seems there's not a lot one can do to change the security posture of a company. Incentives are sometimes complex. Or sometimes there's a sort of creeping security nihilism.

But DMARC works like this. There's a sender policy framework (SPF) that designates who can send email - that is to say, SPF authorizes a group of senders. DomainKeys Identified Mail, or DKIM, allows receivers to check to see if these messages are forged by allowing messages to be signed. A domain will host a snippet akin to an A or MX record, like this:

"k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2Sy
MwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3
GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB"

This is used this in conjuction with information that's relayed along with email - but which is independent of SMTP - and arrives in an email header, like this:

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;
     c=relaxed/simple; q=dns/txt; i=foo@eng.example.net;
     t=1117574938; x=1118006938; l=200;
     h=from:to:subject:date:keywords:keywords;
     z=From:foo@eng.example.net|To:joe@example.com|
       Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
     bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
     b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
              VoG4ZHRNiYzR

In short, whenever an email arrives and a recipient wants to authenticate it, they can do so by verifying the hashes in the header via the DKIM keys. But how do we know if an organization implements DMARC? We can use nslookup to check if an organization uses DMARC, and if they do, view what kind of policy they implement. Per Wikipedia, DMARC provides a few different modes.

- none is the entry level policy. No special treatment is required by receivers, but enables a domain to receive feedback reports.

- quarantine asks receivers to treat messages that fail DMARC check with suspicion; different receivers have different means to implement that, for example flag messages or deliver them in the spam folder.

- reject asks receivers to outright reject messages that fail DMARC check.

With nslookup, we can check what kind of policies a domain might use, if any. For example, here's an example check of both Google and Sony's DMARC policies.

$ nslookup -type=txt _dmarc.google.com
Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
_dmarc.google.com	text = "v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

Authoritative answers can be found from:

$ nslookup -type=txt _dmarc.sony.com
Server:		1.1.1.1
Address:	1.1.1.1#53

Non-authoritative answer:
_dmarc.sony.com	text = "v=DMARC1; p=none; rua=mailto:dmarc_agg@vali.email,mailto:dmarc_rua@emaildefense.proofpoint.com; ruf=mailto:dmarc_ruf@emaildefense.proofpoint.com;fo=1"

Authoritative answers can be found from: