--On 15 October 2010 14:06:16 +0100 Charles Lindsey
<chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk>
wrote:
8.14. Attacks Involving Addition of Header Fields
Many email implementations do not strictly enforce the message syntax
specified in [RFC5322]. One potentially exploitable consequence of this
is that an attacker who is capable of modifying a message in transit
could insert additional header fields that, if properly placed, could be
rendered to the recipient in preference to the originally signed header
fields.
I don't quite see what an attacker can usefully do by modifying messages
in transit. If they message was already signed (say by ebay), then the
attacker must somehow get ebay to sign a message with a useful (to him)
text in its body. So what is the benefit to him of making it appear From:
someone who is not Ebay (except maybe to ensure that replies get sent to
him - since I assume that MUAs that only display the first header will
also Reply-To that header)?
You've answered your own question here. Given that a successful phisher
would have access to my Sent Messages mailbox
So I think there is a wide range of possible attacks involving duplicated
headers, and the text needs to be general enough to cover them.
Here's a more interesting attack:
Compose an email apparently from eBay, and send it to yourself. Get a valid
DKIM signature, then add a From: header containing an eBay address, and use
the replay to send that message to third parties. Now, your email will be
displayed to (some) recipients as an authenticated email from eBay. Note,
the problem is that the MUA is saying the message is Authenticated, but the
user is doing reputation assignment based on the (incorrectly) displayed
eBay address.
Actually, I'm not sure this is different from just sending email with a
spoofed From: header, though the dual header attack might be more useful to
a phisher who has access to a system which, for example, won't sign spoofed
headers.
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html