Murray S. Kucherawy пишет:
Hi Vladimir,
Thanks for putting all this thought into your research. I hope you
stick around as all of this develops.
On Tue, Jul 1, 2014 at 5:53 AM, Vladimir Dubrovin via dmarc-discuss
<[email protected] <mailto:[email protected]>> wrote:
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.
I'm not sure why this is a DMARC problem. If the sending domain uses
a DKIM signature weak enough to allow this kind of spoofing, then it's
not doing a very good job of protecting itself. This isn't a flaw in
DKIM, it's a flaw in how the signer is using DKIM, and hence they're
not getting the kind of protection they probably really want.
The problem is, while DKIM only guaranties identity of signed fields,
DMARC adds some validity assurances and authenticates message at whole.
The difference between "This fields are signed by this domain"(DKIM) vs
"This sender sent this message" (DMARC) is oblivious for me. How can you
say so, if message content can be significantly affected by untrusted party?
Receivers can always look at the parameters of a signature and decide
it was too weak to accept. Going a long way back for an example,
there were some verifiers that would decide that a signature that
didn't cover Subject: was basically unacceptable, and would decline to
verify it even if it was otherwise valid and passed the crypto
checks. You could do this if you want, but if you do then I'd also be
sure to find a way to include that in your DMARC aggregate reports.
It's impossible because people just send messages without subject.
Imagine you want to protect banking company's example.com domain. You
have employee [email protected] who once sent a message without
subject with some neutral or empty content in the body. It's quite
possible situation.
With current DKIM implementations, if there is no Subject: field in the
message, it's not included into h=. It means I can manipulate this field
without invalidating DKIM signature of the message and I can resend
message from [email protected] with any subject. If I have some
message with neutral content, I can re-sent it to some victim with
subject, e.g. "Mr. %USERNAME%, Please call me urgently at
1-11-11111111". During a phone talk victim is assured he talks with bank
employee.
Another possible situation is some autoreply/filter/antivirus/etc, which
auto-replies or rejects incoming e-mail with user's From: without adding
Content-Type or Content-Transfer-Encoding field and bounces back some
content of original message. If this message is signed with DKIM during
transfer, I can create spoofed message with any visible content without
breaking DKIM signature.
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.
You can't have three or even two To: fields and call the message valid
(RFC5322, Section 3.6). DKIM insists that the input message be in
valid format (RFC6376, Section 3.8), so I would argue that your
receiver should decline to verify any signature on such a message.
For fields that are legitimately repeated, it is possible to have some
covered by the signature hash and some not. This is designed into
DKIM and isn't a flaw. That some MUAs make interesting decisions about
what stuff to render in the presence of multiple fields is certainly a
complication, but it's not a flaw in DKIM or DMARC. Moreover, if the
MUAs (which aren't bound by any standards I know of) change how they
choose to render this case, any advice DKIM or DMARC might make would
be immediately obsolete.
You are absolutely right. It's legal for DKIM, but it should not be
legal for DMARC, because it can lead to phishing. If user sees his name
and address in recipients list of e-mail from trusted source he reacts
differently.
An example: Bob sends message to Alice and John with the text "you are
invited to birthday party". Alice adds To: header with Mary's e-mail and
re-sends message to her. Because DKIM signature is valid, it passes
DMARC policy. Mary sees her name and address in recipients list and
trusts the message, getting into unpleasant situation.
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.
I'm unclear on how this would be accomplished even given your
examples. Does yandex.ru <http://yandex.ru> really generate
signatures that only sign the From field? That to me would suggest
that their reputation for even signed mail will dwindle fast, as it
gets abused, and their mail treated with suspicion even if it does
pass DMARC.
I would imagine that an email service provider can only sign mail as a
domain for which it holds a private key, so if you change the From
field domain to something else, you lose domain alignment and thus
can't satisfy DMARC. That means you're limited to generating From
fields that use the signing domain. I would suspect further that such
an email service provider will quickly find the abuse and quash its
source.
Yandex really generates signature, which signs only From: field because
only From: field presents in signed message. This From: is spoofed and
it violates nothing.
Google and Yahoo behavior is absolutely same except few more fields
(Date:, Message-ID and few Yahoo-specific X- fields in case of Yahoo)
are generated and signed and From: is validated to have authenticated
sender's address.
All DKIM implementations I saw behave in this way.
Mail server holds the keys of all served domains. In case of e.g. GMail,
all Google domains, including private ones, gmail.com and customers
domains of Google Apps users. In case of ESP it may be domains of all
client served by this ESP. If I want to spoof e.g. example.com I can buy
some services from the same ESP and try to exploit it.
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.
This isn't correct. As I mentioned above, the input has to be
properly formed for DKIM to consider it. Verifiers that blindly
process malformed input are, by definition, broken.
There was extensive discussion about things like multi-From attacks
during the time the DKIM working group was active. This resulted in
the text you can see in RFC6376 Section 8.15.
[...]
Yes, section 8.15 is exactly why I say this kind of attacks against DKIM
is well-known. RFC 6376 describes this kind of attack, it doesn't says
to recipient how to act upon it.
These can represent serious attacks, but they have nothing to do with
DKIM; they are attacks on the recipient or on the wrongly identified
author.
DMARC authenticates a message at whole, this kind of attack should be
eliminated. At my opinion, malformed message should not be
DMARC-authenticated even if DKIM check passes.
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.
That's not correct (RFC6376, Section 6.1.1).
My mistake, thanks.
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.
Isn't this a problem at the mailbox provider, and not a DKIM or DMARC
problem?
May be. But this problem affects 100% of tested mailbox providers and
DKIM implementations. I strongly believe, in this case it's a common
problem and it should be acted somehow. In russian we call it "rakes
placed on the pass".
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'm not sure how encoding enters into this. If you're talking about
the mailbox provider scanning content for spam before it goes out,
surely it knows how to decode simple things like base64 to do so.
Look into dmarc.eml, open it in any MUA or re-send it to your mailbox.
That's what mailbox provider sees in this case, that is some unreadable
garbage. SPAM text is not visible. It only becomes visible and can be
recognized/decoded from base64 after additional headers added.
dmarc1.eml / dmarc2.eml is a same messages with additional headers added
without invalidating DKIM. After adding missing headers message becomes
readable.
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.
I suggest those are choices made by those operators that they might
want to reconsider. They are not, however, flaws in either protocol;
they're operational choices.
Again, it affects 100% of mailbox providers and, probably, 100% of open
source DKIM implementation in at least default configuration and this
behavior doesn't violate DKIM in any way. How can you inform all mailbox
providers and all implementors of DKIM/DMARC on how to make valid
DMARC-compatible DKIM implementation/configuration without adding
information to DMARC RFC?
Apart from that, as I mentioned above, receivers could decide that an
unprotected Subject field on an arriving message might be grounds to
consider the signature invalid.
As a mailbox provider, I can not implement protection like this, because
according to all current specifications, mail with unsigned Subject must
pass. It has valid DKIM signature and is DMARC-validated, it doesn't
violate any technical standard/specification.
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.
I'm assuming you mean producing (for example) a gmail.com
<http://gmail.com> signature on a message with an arbitrary From:
field. If that's the case, doesn't that mean you're getting a
gmail.com <http://gmail.com> signature rather than something aligned
with the domain you're trying to spoof? An unaligned signature
doesn't mean anything to DMARC, so there's no benefit to an attacker.
In case of GMail two different problems were identified. One (fixed)
allows to obtain google.com signature on any content. Second (most
probably fixed too, haven't check) allows to get any GMail's domain
signature. I was able to "steal" DKIM signatures for gmail.com,
google.com and accounts.google.com on my own message.
Second problem clearly violates DMARC recommendation and was caused by
insufficient input validation, so it's nothing special about it, it's
implementation bug anyone can have. But the first one was clearly
because of misunderstanding the fact placing transaction domain's
(google.com is) signature on user-supplied content is a bad practice.
The problem is, this bad practice is never explained in any RFC.
I imagine there are reasons a mailbox operator would want to allow one
user to generate mail appearing to be another. Gmail allows me to do
this, for example, so long as I can prove ownership of the other
mailbox prior to doing so. It will still generate a gmail.com
<http://gmail.com> signature, however.
With current recommendations, there is a high chance (and is actually a
very common case) d= domain is chosen based on From: content. That's why
I believe it must be noted, that domain should be chosen based on user's
authentication, not on the From: field content and/or From: must be
validated to match authenticated user.
You can check attached EMLs and re-send to you mailbox. You'll see they
pass DKIM/DMARC check, e.g.(see authentication results)
Authentication-Results: mxfront8h.mail.yandex.net; spf=softfail
(mxfront8h.mail.yandex.net: transitioning domain of google.com does not
designate 81.18.133.210 as permitted sender)[email protected];
[email protected]
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=delivered-to:domainkey-status:from:subject:date:message-id:to
:mime-version:content-type:content-transfer-encoding;
bh=Tsdq8mxHe0Tqjmu/IB4m4tlxk7ClbAxqY+JDztT2PXE=;
b=XOb3lbBi3vhsFz2tzw/r2huI5oNB3kEBuHu8zjJpTYABKgPKP4+S6HFomUeLXktFMX
CfakpwNMfWomwBELIvfFYFySparrwyu+i3mvh+lOqWfgW8uw19uQFedjV+c9tXbH81vX
D1ZAH+akE7mPC5n1LTqHMGVPLoEKQ6M3XN+lvJeWgfqqhr8VJKpDDVwj1G7TmZ0Ot/9Y
A3b7sYOt/gqcDMgo/M53lEehfqkWFIedD3ooelIZjRuoTB6+KW6VTOkoVMxs2dmfNSAs
JRO2mlQnpZNSxUZ2KHewZaxJnVmQQrFj87tVbg6i1xhaAQVl5qx6dnJFdH8FNtUmUs3Q
+gSg==
Delivered-To:[email protected]
DomainKey-Status: bad format
From: Google security<[email protected]>
Subject: I never wrote this message
Date: Sun, 18 Aug 2013 08:50:28 +0400 (MSK)
Message-Id:<[email protected]>
To: 3APA3A<[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Return-Path:[email protected]
X-Yandex-Forward: b7da1583aaeb27ec8132fdfd0c9be2a2
I never wrote this message
you may think it's Yandex problem - no, it really has valid DKIM.
What I'd like to propose/discuss:
1. Include recommendation to match RFC5322.From: against
authenticated user for mailbox provider as RFC's "SHOULD".
This sounds like something reasonable to put in the operations guide
(the "BCP", as we're currently calling it) but not necessarily in the
protocol itself.
Nice.
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.
RFC6376 Section 5.4.1 covers this nicely. It doesn't talk about
Content-Type; we had that in RFC4871 but removed it. At the moment I
can't remember why, but I believe it has to do with the fact that very
little in the way of current email is signed with body limitation (the
"l=" tag), so monkeying with MIME fields offers little benefit.
Nope. This section doesn't cover the situation field is absent in signed
e-mail. At least it's unclear from this section, this field SHOULD be
added to h= even if it's absent and it's clearly untrue for e.g. Date:,
because it's a quite common situation Date: and Message-Id: are added in
transit after DKIM signature is already applied.
As an alternative, DMARC DNS record can be extended to include
list of protected fields.
How would this be used? Specifically:
(a) If a sender wants to sign different messages in different ways,
how would it advertise the difference via a DNS record?
(b) This creates additional DNS burden, because now even if both SPF
and DKIM pass and are aligned, the DMARC record has to be retrieved to
confirm compliance with the header field list. Is the benefit worthwhile?
Yes, actually it's useless. The only reason I noticed it as a possible
solution is I afraid current DKIM implementations have incorrect
reaction in case h= contains a header which absents in message, e.g. h=
contains subject and there is no Subject: field. It must be tested.
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).
Both DMARC and DKIM already state that malformed messages of this sort
ought to be disregarded by DKIM, which might lead to rejection by DMARC.
Current standard say malfromed message may break DKIM/DMARC check. That
is, it can lead to problems for somebody, who sends malformed messages.
I say DMARC SHOULD fail on malfromed messages to prevent security
issures. Quite different things.
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.
DMARC Sections 3.1.4 and 10.1 talk about what to do with messages
that contain invalid header blocks.
Yes, these sections are very useful and cover some cases. But it's still
possible to play with content of the From: field and potentially spoof
domain via e.g. \0 character or Unicode right-to-left symbols in mailbox
name. Also, there is still no protection against Content-Type
spoofing/modification. Being able to modify content-type, I can turn any
signed bounce/delivery error from e.g. exim where original message is
quoted into message with fully controlled visible content as
demonstrated above.
-MSK
Thanks for iteresting pointings.
_______________________________________________
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)
