Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Recent Posts

  • Calendar

    December 2014
    S M T W T F S
    « Nov    
     123456
    78910111213
    14151617181920
    21222324252627
    28293031  
  • Email Subscription

  • About Us

    In a recently concluded discussion by the Domain Keys Identified Mail (DKIM) Working Group, a group created under the Internet Engineering Tasks Force (IETF), some of those involved have decided to disregard phishing-related threats common in today’s effective social engineering attacks. Rather than validating DKIM’s input and not relying upon specialized handling of DKIM results, some members deemed it a protocol layer violation to examine elements that may result in highly deceptive messages when accepted on the basis of DKIM signatures.

    The details are simple and the original goals were good. DKIM was intended to authenticate domain relationships with an email message bound at a minimum to that of the From header field. The relationship was to provide a basis for message acceptance but failed to offer the intended protections whenever a message contains invalid or fake elements still considered to offer a valid signature. While it would not be a protocol violation to declare such messages with invalid or fake elements to not have a valid signature, there are some who think otherwise.

    Here is how DKIM can be exploited:

    1. Obtain a free DKIM signed email account.
    2. Send yourself a message of a sensitive nature. Perhaps it could be about a job offer related to an online social network seeking the eventual recipient’s resume.
    3. Prepend any dummy From header field ignored by DKIM to mislead recipients with regard to the message’s origin. Certainly, the message may include a Web link offering additional details. This Web link may attempt some zero-day exploit or request additional personal details such as the recipient’s social networking page to escalate additional attacks.
    4. Exploiting DKIM’s replay insensitivity, a malefactor can then resend the message as a mailing list to their intended victims where it will have a valid signature with a From header purporting to being from any email address a malefactor desires.

    The overhead related to DKIM’s cryptographically based authentication dwarfs the effort of NOT ignoring the presence of multiple From header fields. While SMTP still permits RFC822-compliant messages, DKIM was based on RFC5322, which stipulates the legal number of specific header fields. DKIM should also ensure against the use of fake A-Labels when it changed from using RFC3490 to using RFC5890. RFC5890 defines an additional 3,329 code-points as being illegal and now allows the German esset and the Greek final sigma when string prep was removed. Unfortunately, DKIM makes no effort to ensure the legitimacy of critical header fields nor the domain used to reference the public key confirming the DKIM signature.

    The decision to ignore additional From header fields prepended to an email and yet still return a valid signature result (the only output of DKIM) makes this an EVIL protocol. Evil because once recipients think they can now trust From header fields being displayed but the protocol has decided to ignore or pass over multiple From header fields while checking the signature places recipients at even greater peril.





    Share this article
    Get the latest on malware protection from TrendLabs
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon




    • http://jeux.com azdine

      hhhhhhhhhhhhhh

    • http://blog.trendmicro.com Douglas Otis (Senior Threat Researcher)

      Dave,

      You are right, but we reached different conclusions. Indeed, the ABNF syntax presented in RFC822, when interpreted as a definitive ordered list, implies only one From header field is to be present. However, the text related to this syntax states:

      4.1. SYNTAX
      ,—
      Note: Due to an artifact of the notational conventions, the syn-
      tax indicates that, when present, some fields, must be in
      a particular order. Header fields are NOT required to
      occur in any particular order, except that the message
      body must occur AFTER the headers. It is recommended
      that, if present, headers be sent in the order "Return-
      Path", "Received", "Date", "From", "Subject", "Sender",
      "To", "cc", etc.

      This specification permits multiple occurrences of most
      fields. Except as noted, their interpretation is not
      specified here, and their use is discouraged.
      '—

      RFC2822 and RFC5322 clarified any possible confusion created by this note with explicit header field limits lacking in RFC822. Frankly back then, this issue really didn't matter much. Since you wrote this document, clearly the intent was to declare only one From header field be present. The end result however appears to be poorly enforced and/or interpreted message formats as illustrated in the RFC5321 specification:

      3.3. Mail Transactions
      []
      ,—
      When the RFC 822 format is being used, the mail data include
      the header fields such as those named Date, Subject, To, Cc,
      and From. Server SMTP systems SHOULD NOT reject messages based
      on perceived defects in the RFC 822 or MIME (RFC 2045) message
      header section or message body. …
      '—

      It would be wrong to suggest SMTP excludes header fields violating the intended limits imposed by RFC822 or specific limits set by RFC5322. The only immediate assurance from possible threats is to ensure requisite header field enforcement to ensure what people see aligns with what has been signed, verified, and accepted on that basis. Ironically, both you and Murray insist enforcing the number of From headers is not DKIM's burden. SMTP also indicates such enforcement is not its burden either. So updating an MTA or DKIM plug-in may not help.

      It also seems odd to describe checks for multiple header fields to be a burden when compared to what is required to hash the message, retrieve the public key, and verify the signature. It seems negligent not to make explicit header field checks a MUST when relying upon DKIM. Use of SHOULD in this case suggests there just might be valid reasons for allowing DKIM signed messages to contain multiple From, Subject, To, or Date header fields. Even Murray suggests ignoring this threat is okay, but it is hard to imagine a security protocol concluding that not validating input is alright.

      Justification for ignoring a pre-pended header threat is being based on a protocol layering principle where the requisite layer for making the check this is missing in action. Will there be a specification for the requisite boundary filter as described in RFC5598? Perhaps it could be called the M!A, for Mail Interjection Agent. :^)

      It becomes especially troublesome when developers of DKIM claim pre-pended header checks represent a protocol violation as adequate reason for ignoring potential threats. Is the goal to force a change in RFC5321 or to develop a new boundary filter protocol? If so, how long and how many victims will the email layer cake take to bake?

    • http://bbiw.net Dave Crocker

      Doug has basic facts wrong. They were pointed out to him in the DKIM working group discussion of this issue and they are being pointed out again during his current campaign:

      RFC 822 and the current RFC 5322 call for exactly one From: field. Not zero and not more than one.

      DKIM calla for a valid message that conforms to RFC 5322.

      It is the job of the software handing the message to the DKIM signing engine to make sure that the message satisfies this requirement.

      There are a number of other factual errors in Doug's articles. I and others have refuted them more extensively. Mine is at:

      <http://www.circleid.com/posts/searching_under_lampposts_with_dkim/&gt;

      and the comments to it include pointers to some other refutations of his article.

      d/

    • http://blog.trendmicro.com Douglas Otis (Senior Threat Researcher)

      Hi Martijn,

      Free email providers likely use DKIM to gain increased acceptance by taking advantage of their "too big to block" volumes. For these domains, their reputation is understood to offer little assurance of their overall integrity. By allowing a pre-pended From header field to not affect the validity of a DKIM signature according to the specification means the understood source of a message can NEVER be trusted.

      Those that phish by taking advantage of this flaw are unlikely to affect the acceptance of any exploited high volume domain. DKIM could have avoided offering false assurances by not ignoring illegal header fields per RFC5322 and defining such messages as resulting in invalid signatures.

      The general goal of DKIM as a trust basis for acceptance was to allow incremental deployment without requiring additional undefined filtering to be performed by mail transfer or mail user agents. When essential format checks are skipped, this deficiency allows acceptance based upon DKIM's potentially deceptive results to play an evil role that cannot be repaired through the use of reputation.

    • Pingback: Trend Micro Asia Pacific News Library - Possible Phishing with DKIM()

    • http://www.twitter.com/martijn_grooten Martijn Grooten

      If I were to build a spam filter, multiple From-headers would likely lead to an increased spam score. And if one of the domains used in a From-header would be that of a prime phishing-target, it should increase the score to above the threshold for spam. That's all regardless of DKIM.

      If I noticed spam/phishing messages were DKIM-signed by example.com I would decrease example.com's reputation. As a side-effect you would hope that either people would stop signing their legitimate messages using example.com or that example.com would start to run better checks on the messages it signs.



     

    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice