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 < dmarc-discuss@dmarc.org> 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. 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. 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. 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 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. > 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. > > [...] > > 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). > 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? > 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. > 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. 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. > 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 signature on a message with an arbitrary From: field. If that's the case, doesn't that mean you're getting a 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. 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 signature, however. > 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. > 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. 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? > 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. > 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. -MSK
_______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org 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)
