Re: Security flaw in how Outlook verifies digital signatures

From: Vanguard (use_ReplyTo_at_domain.invalid)
Date: 02/18/05 

Date: Thu, 17 Feb 2005 18:02:41 -0600

"Roberto Franceschetti" <roberto_remove_n.o.s.p.a.m_tag@logsat.com>
wrote in message news:iI7Rd.89419$qB6.15925@tornado.tampabay.rr.com...
> This report is also available graphically at
> http://www.logsat.com/Signatures
>
> On 10/21/2004 the following vulnerability was reported to Microsoft:
>
> Security Flaw with Digital signatures in Microsoft Outlook -
> Emails in Microsoft Outlook digitally signed with S/MIME using either
> a commercial personal certificate like Verisign or using a certificate
> issued by MS Certificate Server can be altered. Outlook will not show
> any warnings
> about the email being changed, the digital signature will still be
> reported valid even though the message content has been modified and
> parties involved in the signatures changed.
> This is an extremely serious flaw as I can change any digitally signed
> emails I want without Outlook ever noticing.
> After several emails with Microsoft and CERT during the months that
> followed, no fixes have been issued to correct this security flaw. It
> is only now that I am making this information public after all my
> attempts to have Microsoft resolve the problem have failed.
>
> The following are 3 digitally signed messages. The 1st one is a valid,
> unmodified email from Roberto Franceschetti (roberto at logsat.com) to
> support at logsat.com: (follow the hyperlinks for the email's source
> and screenshots)
>
> Screenshot at http://www.logsat.com/Signatures/Valid.gif
> Email's source at http://www.logsat.com/Signatures/Valid.msg
>
>
> The following one has been "hacked" so that the sender now appears to
> be "Hackers Franceschetti" (hackers@logsat.com). Note that Outlook
> states that the email is absolutely valid, and that the certificate is
> Valid and Trusted. This is most definitely not the case, as I've
> altered the original message to make it appear as a different person
> actually sent it. Imagine the scenario where a digital signature is
> supposed to unequivocally identify a sender, but now this email that
> appears to be sent by "hackers" appears legitimate, and a poor victim
> will trust it and send the hacker any confidential information he is
> asked for... (follow the hyperlinks for the email's source):
>
> Screenshot at http://www.logsat.com/Signatures/Hacked1.gif
> Email's source at http://www.logsat.com/Signatures/Hacked1.msg
>
>
> This 3rd email is yet another variation showing how a digitally signed
> email can further be forget without Outlook ever raising warning flags
> (follow the hyperlinks for the email's source):
>
> Screenshot at http://www.logsat.com/Signatures/Hacked2.gif
> Email's source at http://www.logsat.com/Signatures/Hacked2.msg
>
>
>
> The full emails with the conversations between myself, Microsoft and
> CERT can be found here (http://www.logsat.com/Signatures/emails.asp).
> I hope that by making this information public all the users who rely
> on digital signatures will be aware of this severe security flaw in
> Microsoft Outlook, and will take other precautions to ensure the
> identity of users in digitally signed emails they receive.
> Roberto Franceschetti
> LogSat Software
> roberto at sign logsat.com
>

Certificates are not used to digitally sign or encrypt the headers with
the body of the message. Why not? Because the headers will change with
each hop the mail takes to its destination. The body of the message
gets signed or encrypted, and it is the identity of the certificate that
is used to determine who signed or encrypted the *message* (NOT the
headers). Digitally signing a message or encrypting it does not prevent
spoofing the headers. You use the certificate details to determine to
whom the certificate was assigned that used it to sign or encrypt the
BODY of the message, not the headers.

If you had changed any portion of the BODY of the message then the
certificate would've been invalidated and you would have seen a warning
of such. The digital certificate does not identify the sender of the
message, only who signed or encrypted the BODY of the message. You
could, for example, sign a message and have it relayed from an anonymous
remailer. As long as that remailer never altered the BODY of the
message then its hash is still valid and unaltered and you, the one that
signed it, will still be correctly identified although the *header* show
that it came from the anonymous remailer instead of from your domain's
mail server.

When you encrypt a disk to ship to someone, do YOU actually have to
carry it to the recipient? No. You encrypt it and then hire some
shipper to deliver it, and obviously the shipper wasn't you but that
does not alter the fact that YOU were the one that encrypted the disk.
The certificate says who signed or encrypted the BODY of the message.
It does NOT qualify or validate the sender of that signed or encrypted
content. 

-- 
____________________________________________________________
Post your replies to the newsgroup.  Share with others.
E-mail reply: Remove "NIXTHIS" and add "#VS811" to Subject.
____________________________________________________________

Relevant Pages

  • RE: Security Flaw with Digital signatures in Microsoft Outlook
    ... Outlook shows the name of the sender from the email ... Security Flaw with Digital signatures in Microsoft Outlook ... personal certificate like Verisign or using a certificate issued by MS ...
    (Bugtraq)
  • RE: EFS File Share Help
    ... And your roaming profile cannot work properly. ... If user tries to encrypt a remote file/folder stored ... user, and subsequently requests, or generates a self-signed EFS ... The certificate and private key are loaded in a local profile ...
    (microsoft.public.windows.server.sbs)
  • Re: About EFS and local certificate that I want to export in SBS
    ... It's probably not a good practice to let users encrypt data otherwise, ... It's a two-second thing to install the CA - on the SBS ... I just have to do what you say if I have a certificate authority ...
    (microsoft.public.windows.server.sbs)
  • Re: Public Encryption Key
    ... encrypt the message with the recipient's public key (or ... the two can be combined by: first do a digital signature of the ... certificate, certifying the validity of the assertion (ex: ...
    (comp.security.misc)
  • Re: Public Encryption Key
    ... encrypt the message with the recipient's public key (or ... the two can be combined by: first do a digital signature of the ... certificate, certifying the validity of the assertion (ex: ...
    (sci.crypt)