Hello list,
sorry if this was discussed, I'm new to list and can't find related
discussion in archives.
While performing internal tests, I have found some problems I believe
are flaws current DMARC specification has due to use of DKIM
authentication without adoption/additional requirements. There are
well-known DKIM problems need to be solved to use it for message
authentication. These problems affect mostly mailbox providers, because
they require attacker/spammer to be able to obtain at least one valid
DKIM signature on manipulated content. But in some situation they can be
used against ESPs, if ESP applies his own DKIM signature to
user-provided message.
1. DKIM (and DMARC) doesn't define minimal set of headers. It makes it
possible to bypass mailbox provider's spam filters, tamper content of
the signed message (demonstration below) and reuse one signed message
for e.g. multiple spam messages with very different content/signatures
or to use it for phishing.
2. DKIM (and DMARC) doesn't define behavior for the case there are both
signed and unsigned fields of the same type (e.g. there are 3 To:
headers and only 2 To: signed fields in DKIM h= field). It only defines
a sign order (2 last fields are signed). This fact can also be used to
tamper message content.
3. DMARC adds requirement for DKIM domain to match RFC5322.From:, but
there is still no recommendations for public mailbox providers to
prevent From: field from spoofing by authenticated user, that is there
is no requirement to match RFC5322.From: to authenticated user's account
or domain. I understand it's not DMARC's aim to authenticate a user, but
this simple recommendation may increase spoofing protection for e-mail
in general, because there is no currently any standard to prevent From:
from spoofing by authenticated message sender. Explanations below.
4. DMARC does not define behavior for the case of malformed fields,
including RFC5322.From: field (DKIM has no any requirements). Content of
malformed field can be displayed to user by MUA or web interface in
unpredictable way, potentially making DMARC phishing protection useless.
All problems are confirmed with largest mailbox providers to allow
complete or partial DMARC bypass.
Messages for demonstration can be taken from
https://cloud.mail.ru/public/13de862b2b4c/dmarc.zip
Test 1, content spoofing:
Two messages look absolutely different:
http://clip.corp.mail.ru/clip/m0/1404210618-clip-33kb-BciPzLGSxbsl.png
both have valid DKIM signature. The problem is, this signature is same
for both messages. See headers of
dmarc1.eml:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru;
s=mail; t=1404209937;
bh=PUlzbqVQe585GKmhDo4TN8yKVGUku3ag7etaEnNByKk=; h=From;
b=b8AnXVrDg1kfNLEt5wVH9sAoB3p6F2b3TKTv5keSKg7r2x+QHRlzX2y5TxeWmG2Ft
ABYbHkH7HalBDmCLYfcg9f2TI7iICL2dTlltJ6FN3qfdXf/u6/vPfwBrpjU5Vh2qYt
xS/JUnlg/OOWztoFsLULK4vIv9G+6+QOukNN9CKQ=
From: Spoofed Sender <[email protected]>
To: [email protected]
Subject: Sample 1
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--ALT--1"
dmarc2.eml:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru;
s=mail; t=1404209937;
bh=PUlzbqVQe585GKmhDo4TN8yKVGUku3ag7etaEnNByKk=; h=From;
b=b8AnXVrDg1kfNLEt5wVH9sAoB3p6F2b3TKTv5keSKg7r2x+QHRlzX2y5TxeWmG2Ft
ABYbHkH7HalBDmCLYfcg9f2TI7iICL2dTlltJ6FN3qfdXf/u6/vPfwBrpjU5Vh2qYt
xS/JUnlg/OOWztoFsLULK4vIv9G+6+QOukNN9CKQ=
From: Spoofed Sender <[email protected]>
To: [email protected]
Subject: Sample 2
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="--ALT--2"
body content for both messages is same, but it's manipulated via
boundary in top-level Content-Type:
----ALT--1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
CjxIVE1MPjxCT0RZPjxicj5TUEFNIFNJR05BVFVSRSAxIElTIElULCBMVUtFPGJyPjxicj48YnI+
PC9CT0RZPjwvSFRNTD4K
----ALT--1--
----ALT--2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
CjxIVE1MPjxCT0RZPjxicj50aGlzIGlzIFNQQU0gU0FNUExFIDI8YnI+PGJyPjxicj48L0JPRFk+
PC9IVE1MPgo=
----ALT--2--
Original authenticated message, which was sent via yandex.ru relay and
was signed was dmarc.eml:
From: Spoofed Sender <[email protected]>
----ALT--1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
CjxIVE1MPjxCT0RZPjxicj5TUEFNIFNJR05BVFVSRSAxIElTIElULCBMVUtFPGJyPjxicj48YnI+
PC9CT0RZPjwvSFRNTD4K
----ALT--1--
----ALT--2
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
CjxIVE1MPjxCT0RZPjxicj50aGlzIGlzIFNQQU0gU0FNUExFIDI8YnI+PGJyPjxicj48L0JPRFk+
PC9IVE1MPgo=
----ALT--2--
it contains no headers except From:.
DKIM doesn't require even From: header to be signed. It leaves a
possibility to have a "universal" DKIM signature to be valid for any
message headers.
The problems here is, spammers can use very limited number of mailboxes
from well-known mailbox provider to create DKIM-signed spam messages
with very different signatures - different subjects, recipients and
(partially) content, misusing DMARC-protected domain's reputation.
Mailbox provider will not detect SPAM/virus signatures before signing
the message in this case due to content-type manipulation (content is
base64-encoded but in case of original messages signer sees it as a
non-encoded plaintext).
I have tested DKIM implementations of 2 world-largest mailbox providers
(GMail and Yahoo) and two largest Russian mailbox providers (Mail.Ru and
Yandex). In all cases, Subject, Content-Type, Content-Disposition and
To: are omitted from DKIM signature if not present in original message,
so content of the signed message can be manipulated.
Test 2: sender spoofing:
A second test performed, was an attempt to get valid DKIM signature on
spoofed RFC5322.From: field, 15-30-minutes long manual tests for each
service. Problem like this allows to use DKIM signature of mailbox
providers with any content and any sender (including spoofed From:
fields), it makes it impossible for recipient to recognize and ban spam
messages based on sender or domain reputation and makes DMARC protection
nearly useless.
In case of GMail and Mail.Ru few possibilities for spoofing were found,
that is From: can differ from authenticated user, examples of spoofed
messages with valid DKIM are in google.eml, mailru.eml.
Yandex has no protection against spoofing at all, there is no check for
RFC5322.From: in messages from authenticated sender. See yandex.eml.
I have failed to spoof From: after quick test run against Yahoo, but
another potentially more significant DMARC-related content manipulation
problem covered by this article was discovered.
Problems were reported to Google, Yandex and Yahoo and are fixed by
Mail.Ru. In case of Google and Yahoo problems are accepted as security
bugs. Details can be disclosed (if someone interested) after all bugs
are fixed in accordance to their disclosure policy. In case of Mail.Ru
problem was in the fact redirected message was signed with DKIM.
Based on test results, you can expect most DKIM/DMARC implementation may
have this kind of bugs. But, because there is no standard to perform a
check of RFC5322.From: to be authenticated user, accepting and fixing
bugs like this is due to good will of mailbox provider.
What I'd like to propose/discuss:
1. Include recommendation to match RFC5322.From: against authenticated
user for mailbox provider as RFC's "SHOULD".
2. Include recommendation to always add From:, To:, Cc:, Subject:,
MIME-Version:, Content-Type:, Content-Disposition: (may be something
else?) into h= of DKIM signature. DKIM allows absent headers to present
in h=, in this case header can not be added without invalidating DKIM
signature.
As an alternative, DMARC DNS record can be extended to include list of
protected fields.
3. FAIL DMARC if there are unsigned headers of this type, e.g. there are
2 To: fields and only one is signed (DKIM allows to mix both signed and
unsigned fields of the same name).
4. Fail DMARC check, if message doesn't pass RFC5322 compliance checks,
e.g. has malformed From: or has non-ASCII or control characters in the
protected headers.
WBR,
Vladimir Dubrovin
@Mail.Ru
_______________________________________________
dmarc-discuss mailing list
[email protected]
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
