Security flaw in how Outlook verifies digital signatures

[Roberto Franceschetti]

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" ([email protected]). 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

 

[Vanguard]

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" ([email protected]). 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.

 

[Roberto Franceschetti]

Let me clarify first that we're not talking about enrypting, but just
signing, two very different things. This said, of course the headers cannot
be considered as they will change. However digitally signing a document is
supposed to ensure that the document is not altered in any way. When
applying this to an email, this would mean that not only the body of the
email, but also the "From", the "To" and the "Subject" headers should be
tested to see if they are modified. Those will definetly not be changed by
servers when mail is being routed.

If you feel so strongly about the "From", how would you feel if the subject
of a digitally signed email would be hacked instead... What if the digitally
signed email now also had a forged subject line... Instead of saying
"Accepted" now says "Declined"? I've just "hacked" my original signed
message so that it shows "xxxx" instead of "test" in the subject line. The
URL is http://www.logsat.com/Signatures/Hacked3.msg... Outlook did not even
twich about the hack, it still thinks the email is unmodified.

What good does having digitally signed emails, which are to ensure the
integrity of such emails, if a hacker can *FREELY* modify the sender, the
recipient, and even the subject, without Outlook providing any warning?

....And let's not forget that Outlook is the *only* package that fails to
verify these very important headers. Other email clients, including Outlook
Express, work just fine.

To make matters worse, while with a "From" hack an computer-savvy person can
go deep down in the certificate to find the real identity of the sender,
there's "almost" nothing that can be done to check if the "Subject" line has
been modified, as I've just proved can be done in the sample above.

Roberto Franceschetti
LogSat Software

 

[Jeff Stephenson [MSFT]]

Let me clarify first that we're not talking about enrypting, but just
signing, two very different things. This said, of course the headers cannot
be considered as they will change. However digitally signing a document is
supposed to ensure that the document is not altered in any way. When
applying this to an email, this would mean that not only the body of the
email, but also the "From", the "To" and the "Subject" headers should be
tested to see if they are modified. Those will definetly not be changed by
servers when mail is being routed.

If you feel so strongly about the "From", how would you feel if the subject
of a digitally signed email would be hacked instead... What if the digitally
signed email now also had a forged subject line... Instead of saying
"Accepted" now says "Declined"? I've just "hacked" my original signed
message so that it shows "xxxx" instead of "test" in the subject line. The
URL is http://www.logsat.com/Signatures/Hacked3.msg... Outlook did not even
twich about the hack, it still thinks the email is unmodified.

What good does having digitally signed emails, which are to ensure the
integrity of such emails, if a hacker can *FREELY* modify the sender, the
recipient, and even the subject, without Outlook providing any warning?

...And let's not forget that Outlook is the *only* package that fails to
verify these very important headers. Other email clients, including Outlook
Express, work just fine.

To make matters worse, while with a "From" hack an computer-savvy person can
go deep down in the certificate to find the real identity of the sender,
there's "almost" nothing that can be done to check if the "Subject" line has
been modified, as I've just proved can be done in the sample above.

If you want to have different signing behavior, I suggest you involve
yourself in the standards work done in the Internet mail community, rather
than ranting about Outlook. Outlook signs its messages in accordance with
the Internet standard for doing so (http://www.ietf.org/rfc/rfc3851.txt).
Doing so in any other manner (for example including the From:, To:, and
Subject: in the signing) would break interoperability with other mail
clients, which would have no clue which fields were included in the
signature and which were not.

From the standard cited above:

S/MIME is used to secure MIME entities. A MIME entity can be a sub-
part, sub-parts of a message, or the whole message with all its sub-
parts. A MIME entity that is the whole message includes only the
MIME headers and MIME body, and does not include the RFC-822 headers.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Note that last phrase. If you want to change it, join the discussions in
the community and help develop a standard that can be used to sign headers.

 

[Roberto Franceschetti]

Jeff,

Please read the thorough discussion I've been having with your engineers.
We're not talking about the RFC which merely defines what S/MIME is and how
it operates. As you can read from my report with Microsoft, we all agree
that the S/MIME standard is used to ensure the *body* is not altered. What
we're talking about is how Outlook fails to use digital signatures in
verifying that the sender is who he is.

If you read thru those emails you'll see how Outlook's documentation clearly
states that digital signatures are also used to verify the sender. Let's
take another example. Let's look at Outlook Express' documentation:

***************************************
Sending secure messages

As more people send confidential information by e-mail, it is increasingly
important to be sure that documents sent in e-mail are not forged, and to be
certain that messages you send cannot be intercepted and read by anyone
other than your intended recipient.

By using digital IDs with Outlook Express, you can prove your identity in
electronic transactions in a way that is similar to showing your driver's
license when you cash a check.

***************************************

What do we have here...? Outlook Express will verify that the sender is
actually the same person as the one in the certificate! ...I thought you
said S/MIME and the RFCs did not account for that... This is exactly what
should be happening. Similar documentation is there in MS Office's help. All
email clients I know of perform this basic, simple check.

Microsoft Outlook does not...

Again, we're not talking about S/MIME and RFCs here, so please don't try to
pawn this off saying "this is done by design", because if it is it's very
poor design... And you ought to make it very clear in the documentation that
digital signatures will *not* behave like ink signatures identifying the
sender, but that they have a misleading name as the email is not digitally
signed, rather only the *body* of the email is, and that there should be a
disclaimer that Outlook will not, unlike all other email programs, verify
digital signatures against the sender's email address.

I do however have to stand corrected on a statement I made in my previous
post about the subject line. There is currently no way that email clients
can verify that the subject has been modified, Outlook is not the only one
that suffers from this. However this was not in my original report to
Microsoft, and I will retract on that issue as I've been making an incorrect
assumption. I will blame anger and disappointment onmy mistake.

Roberto Franceschetti
LogSat Software

 

[Roberto Franceschetti]

I forgot to add the link and contents of Outlook's help file...

Please look in particular at the words "This proves to the recipient that
the
message is from you and not from an imposter"

That is exactly what Outlook is *not* doing... and we're not talking about
RFCs and S/MIME there, because as you correctly state, they areused only as
guidelines on how to ensure the body is not changed. We're talking about
simple verification that the sender is actually who he says he is. That is
*not* defined by the RFC you mention. It's just common sense, and whoever
wrote Outlook's documentation thought so as well since they have the right
idea there. Too bad they did not convey the thought to the programmers...


From the Outlook help file on 10/21/2004 (the contents may have changed
now...):
(http://office.microsoft.com/assistance/hfws.aspx?AssetID=HP052423541033
&CTT=1&Origin=EC010230001033&QueryID=XUI66rUx90):

Digitally sign messages
Digitally signing a message applies your certificate (certificate: A
digital means of proving your identity. When you send a digitally signed
message you are sending your certificate and public key. Certificates
are issued by a certification authority, and like a driver's license,
can expire or be revoked.) (with the public key (public key: The key a
sender gives to a recipient so that the recipient can verify the
sender's signature and confirm that the message was not altered.
Recipients also use the public key to encrypt (lock) e-mail messages to
the sender.)) to the message. This proves to the recipient that the
message is from you and not from an imposter and that the message has
not been altered. Encrypting (encrypt: The process of converting plain,
readable text into cipher (scrambled) text. The sender uses the
recipient's public key to encrypt (lock) the e-mail message and
attachments.) a message is a separate process.

***************************************


Roberto Franceschetti

 

[Vanguard]

If you don't protect your private key for your certificate and anyone
gets it then they can purport to be you. The e-mail address specified
within the certificate is part of the identification you wish to use to
identify yourself but it need NOT be the delivery agent's e-mail
address. The certificate and its use in signing the *content* of a
message does not extend to verifying or authenticating the delivery
agent. When you buy a book from Prentice Hall or McGraw, do you really
think they were the author of the content within the book?

Don't expect different MUAs to behave the same regarding them comparing
the e-mail defined with the certificate used for signing the *content*
within a message and the From, Reply-To, Sender, or Return-Path headers
used to encapsulate the message in delivering it. If an MUA alerts you
that the sender envelope is different than the e-mail address specified
within the certificate then that's a feature of that MUA but it is not a
requirement of using S/MIME itself. Don't expect different MUAs even
from the same developer to behave the same. Stop confusing Outlook and
Outlook Express as though they share code, one is a lite version of the
other, or that they are even related products.

The public key portion of the certificate is deployed within the MIME
data (which is WITHIN the body of the message). It doesn't incorporate
anything of the headers which aren't even used in the delivery of the
message. Tell me, just how would you fix the problem so users could
still utilize a forwarding service or remailer which is then the sender
(i.e., delivery agent) of the digitally signed message and is obviously
not the e-mail address of the account used by the author that used their
certificate to sign their content?

If you can decipher the RFCs regarding S/MIME version 3, like
ftp://ftp.rfc-editor.org/in-notes/rfc3851.txt, then be my guest. I get
lost real quick in that muck. Section 3.1, says:

"S/MIME is used to secure MIME entities. A MIME entity can be a
sub-part, sub-parts of a message, or the whole message with all its
sub-parts. A MIME entity that is the whole message includes only the
MIME headers and MIME body, and does not include the RFC-822 headers."

Well, that pretty much says what I've said all along, that the headers
are NOT included in the digital signature. So an MUA that alerts you
that the e-mail address in the certificate differs from the sender
envelope information is optional but a nice feature nonetheless. After
all, Outlook Express doesn't alert you that the FollowUp-To header has
been used in a newsgroup post to which you reply (so your reply might
not go where you think it will). Some NNTP clients do alert you or you
can configure them to show up in the headers portion of the preview pane
so you know the FollowUp-To header got used. However, such an alert is
a feature of the program and NOT a requirement. The same for alerting
for a mismatch between the delivery agent (and whatever is its sender
envelope) and the e-mail address in the certificate used to sign an
e-mail. Nice to have but not mandatory to support S/MIME.

However, section 3.1 also says:

"Note that S/MIME can also be used to secure MIME entities used in
applications other than Internet mail. If protection of the RFC-822
headers is required, the use of the message/rfc822 MIME type is
explained later in this section."

The later explanation says:

"In order to protect outer, non-content related message headers (for
instance, the "Subject", "To", "From" and "CC" fields), the sending
client MAY wrap a full MIME message in a message/rfc822 wrapper in order
to apply S/MIME security services to these headers. It is up to the
receiving client to decide how to present these "inner" headers along
with the unprotected "outer" headers."

So look at your digitally signed messages to see if there is an outer
MIME part of type message/rfc822 that envelopes your inner MIME part
that carries the digital signature. So it is possible to include the
sender info in the signature but it is not required by the sender nor is
it required the receiving client support it. Do you know if Outlook
envelopes the S/MIME part for the signed content with another MIME part
of type message/rfc822? When you compile the same test messages in
Outlook Express using the same certificates, does OE wrap the S/MIME
content with another MIME part of type "message/rfc822"? I downloaded
your example message at http://www.logsat.com/Signatures/Valid.msg and
http://www.logsat.com/Signatures/Hacked1.msg (although they are a .msg
file instead of a text file). I did NOT see a MIME part with
"Content-Type: message/rfc822: ...". So whichever MUA you used to
generate this .msg file doesn't not include the RFC822 headers in the
signature. Having the receiving client *guess* by trying to compare the
e-mail address in the signature with the sender envelope info in the
headers is guaranteed to fail often. Since you MUA (Outlook?) did not
protect the headers, don't expect the receiving agent to authenticate
the headers.

This RFC 3851 was released in July 2004 and it takes awhile before MUAs
implement the changes (although they may implement the RFC before it
actually gets ratified). I did not see the "message/rfc822" content
type described in RFC 2311 to 2315 for S/MIME version 2, it wasn't
mentioned in RFCs 2630 to 2634 for S/MIME version 3.0, so it looks to be
something new to S/MIME (not that "message/rfc822" is a new content type
but of using it with S/MIME but which is still optional). I've seen
some RFCs over 6 years old that are still not implemented in some
clients. And then there is always the difference between the RFCs,
which are often a jumbled mess, and how they get implemented. But, in
my experience, the sender envelope has not been a part of any digitally
signed message that I have received. Apparently message/rfc822 wasn't
included in the test e-mails that you used, too.

 

[Jeff Stephenson [MSFT]]

First, let me start by saying that I'm *not* speaking for Microsoft but am
rather speaking as myself, with over a decade of writing email code.

Please read the thorough discussion I've been having with your engineers.
We're not talking about the RFC which merely defines what S/MIME is and how
it operates. As you can read from my report with Microsoft, we all agree
that the S/MIME standard is used to ensure the *body* is not altered. What
we're talking about is how Outlook fails to use digital signatures in
verifying that the sender is who he is.

But the digital signature tells you who signed the body - that's who's
responsible for the content, and thus is who the sender is, regardless of
the From:. While I don't have a copy of Outlook 11 handy that has signed
mail in it, my recollection is that it displays "Signed by: xxxxxx" or
something like that in the header. That tells you who signed the message -
i.e. who is responsible for the content.

If the signer of the message and the displayed "From:" differ, you can draw
your own conclusions. As you'll see in some of the correspondence on your
web site, there are a number of completely legitimate situations in which
those *don't* match, and apparently there was enough customer pushback
about false warnings about the sender not matching the signature that the
design was changed. I don't know - I wasn't involved.

What do we have here...? Outlook Express will verify that the sender is
actually the same person as the one in the certificate! ...I thought you
said S/MIME and the RFCs did not account for that... This is exactly what
should be happening.

That actually tells you precisely - nothing. I can, at this moment, send
an email message with your address as the From:. What I *can't* do is sign
the body of the message with your certificate. If I could, and wanted to
send a forgery, do you think I'd send it with my own address? No, I'd send
it with your address, and your "check the certificate address against the
From:" test would be very happy with the message - no warnings would be
raised.

It's the *certificate* that matters in these situations, and people need to
be aware of that. All that comparing the certificate address to the From
address does is raise false warnings in legitimate situations, as was
pointed out in your conversations with the Microsoft techs. It does *not*
prevent forgery - protection of your certificate is what does that, because
if someone else gets hold of it they can absolutely masquerade as you.

Again, we're not talking about S/MIME and RFCs here, so please don't try to
pawn this off saying "this is done by design", because if it is it's very
poor design... And you ought to make it very clear in the documentation that
digital signatures will *not* behave like ink signatures identifying the
sender...

What they behave like is *notarized* ink signatures. You've got Verisign
or some other certificate authority vouching for the legitimacy of the
signature, acting in a sense as notaries. Again, the signer of the body is
the person responsible for the message. As Vanguard asked, why do you care
that FedEx delivered it to you?

And given that anybody can *easily* send an email message as anybody else
(notice all the non-delivery reports you get for spam you never sent), I
just don't see how the check you propose prevents forgery, much less how
the lack of your check constitutes a security defect in Outlook.

 

[Jeff Stephenson [MSFT]]

Please look in particular at the words "This proves to the recipient that
the message is from you and not from an imposter"

And this is exactly what Outlook does, if you look at the actual
*signature* on the message instead of the (incredibly easily forged)
"From". As I said before, anybody that can actually sign the message with
your certificate isn't going to be stupid enough to send it with their
address; to see who the message is from, always check the signature, not
the From.

If you really care about the legitimacy of snail mail, do you check the
return address on the envelope, or compare the actual ink signature to a
known copy of the person's signature? Same thing in email - check the
signature. [Actually, given current image technology, digital signatures
are *much* better than ink signatures...]

 

[Vanguard]

Jeff,

Please read the thorough discussion I've been having with your
engineers. We're not talking about the RFC which merely defines what
S/MIME is and how it operates. As you can read from my report with
Microsoft, we all agree that the S/MIME standard is used to ensure the
*body* is not altered. What we're talking about is how Outlook fails
to use digital signatures in verifying that the sender is who he is.

So you are suggesting that Microsoft goes off on its own tangent that is
incompatible with other e-mail clients.

If you read thru those emails you'll see how Outlook's documentation
clearly states that digital signatures are also used to verify the
sender. Let's take another example. Let's look at Outlook Express'
documentation:

***************************************
Sending secure messages

As more people send confidential information by e-mail, it is
increasingly important to be sure that documents sent in e-mail are
not forged, and to be certain that messages you send cannot be
intercepted and read by anyone other than your intended recipient.

By using digital IDs with Outlook Express, you can prove your identity
in electronic transactions in a way that is similar to showing your
driver's license when you cash a check.

***************************************

If the documentation were as specified as the RFCs to which the software
complies then the users wouldn't understand what they were told. The
digital signature proves the identity of the author that composed the
CONTENT of the message, not of the delivery agent (unless, as noted in
my other article, the S/MIME part is wrapped by another parent MIME part
of content type "message/rfc822" that is supposed to include the sender
envelope information).

Note that the help does say, "it is increasingly important to be sure
that DOCUMENTS sent in e-mail are not forged". That's because the MIME
part is within the body of the message and doesn't involve or include
the headers. The delivery agent is not guaranteed. Only the author of
the document is identified.

What do we have here...? Outlook Express will verify that the sender
is actually the same person as the one in the certificate! ...I
thought you said S/MIME and the RFCs did not account for that... This
is exactly what should be happening. Similar documentation is there in
MS Office's help. All email clients I know of perform this basic,
simple check.

Matching the e-mail address in the certificate against the sender
envelope info in the headers is only a guess that the sender was also
the author. You could digitally sign a document that I could send but
spoof the From, Reply-To, Sender, and Return-Path headers so they looked
like you. The MUA sees that the spoofed headers being equal to the
e-mail identity in the digital signature. However, the sender was NOT
the author but just a spoofed sender.

Microsoft Outlook does not...

Does either Outlook or Outlook Express (which you claim works for sender
verification) use the MIME part of content type of "message/rfc822".
No? Then OE isn't working, either. Guessing guarantees any sender
could spoof the headers to match the e-mail address recorded in the
certificate. You still won't know the sender is really the author.

Again, we're not talking about S/MIME and RFCs here,

And yet I thought you were discussing how to digitally sign e-mails, so
S/MIME *is* involved in the discussion. How do YOU think digital
signatures are incorporated into an e-mail other than using MIME (or
maybe PGP)?

And you ought to make it very clear in the documentation that digital
signatures will *not* behave like ink signatures identifying the
sender, but that they have a misleading name as the email is not
digitally signed, rather only the *body* of the email is, and that
there should be a disclaimer that Outlook will not, unlike all other
email programs, verify digital signatures against the sender's email
address.

As is evident here, and with discussions with other users of ANY e-mail
client that incorporates x.509 certificates, they really don't know how
they work. So, yes, it probably would help to clarify to users that
only the *author* of the BODY of the e-mail gets identified by the
digital signature and nothing in that digital signature validates that
delivery agent originated from that author or an account owned by that
author. But then users don't know how SMTP works, either, so they don't
understand that the From header in the e-mail is just information as
provided as *data* by the sender (which can be spoofed) and it is the
RCPT-TO commands from the sender's MUA that dictates to where the
message gets delivered, and the RCPT-TO recipients need not match
anything listed in the From header that is just part of the sender's
*data* sent in the DATA command.

So Microsoft probably should updates its help documentation to let users
understand that the only part of their e-mail that is being digitally
signed is its content and nothing regarding the delivery agent is
encoded into that digital signature, especially since the delivery agent
actually has not even been used when the document got digitally signed.
After all, you are still composing the document within your e-mail
client and haven't even sent it yet so obviously the digital signature
cannot have any information within it showing the sender's origination.
The sender's mail server only got the e-mail after it was already
digitally signed!

I do however have to stand corrected on a statement I made in my
previous post about the subject line. There is currently no way that
email clients can verify that the subject has been modified, Outlook
is not the only one that suffers from this. However this was not in my
original report to Microsoft, and I will retract on that issue as I've
been making an incorrect assumption. I will blame anger and
disappointment onmy mistake.

According to RFC 3581, and only if the wrap-around MIME part of content
type "message/rfc822" is used, the Subject header can be included.
However, that content type appears to be new in its inclusion within
S/MIME about 7 months ago so it will take awhile before e-mail clients
incorporate version 3 of S/MIME.

However, I still don't see that preventing spoofing. The certificate
has an e-mail address. The e-mail hasn't yet been sent to the mail
server (it is still being composed and managed within the e-mail client)
so nothing of the sender's mail delivery agent could possibly be
incorporated into the digital signature. All the e-mail client can do
with the encapsulating MIME part of content type "message/rfc822" would
be to compare the e-mail address in the certificate against the e-mail
address specified within the account defined in that e-mail client. But
we all know that you can put any text you want in the Name and E-mail
Address fields within the e-mail account definition which go into the
From header. So the sender could still spoof by configuring an account
in their e-mail client that has the same e-mail address in the From
header as that specified in the certificate.

 

[Roberto Franceschetti]

Jeff,

Simple exploit. I use my own Verisign digital certificate to sign an email.
I then alter the from in the email to make it appear from Microsoft. I then
send the signed email to my competitor. He sees an email coming from
Microsoft, digitally signed, with a valid signature, but unfortunately he's
using Outlook which does not warn him that the sender does not match the
certificate (if he had only used Mozilla or Outlook Express he'd see flags
everywhere...). The email will talk about a new non-existent vulnerability,
and perhaps I will attach an infected attachment, with a copy of maybe Optix
Pro to get a backdoor into his system...

Am I stupid because I used my own certificate...? Not really, you see,
somebody stole my private key which I upladed onto my ISP's public ftp
server to make it easier for me to access it while traveling... in court my
lawyer would be having a field day proving my innocence as a victim of
fraud, and in the meantime I've caused irreparable harm to my competitor.
All because Outlook is the only email client that did not warn him about the
sender not being the one who signed the email...

....this is only one example of abuse of the exploit.

Yes, if you look deep down in the signature a *very* computer-savvy user
will eventually understand that the sender is not really the person who
signed the email. But I stress on the computer savvy words. Your average and
even above average computer user will have no idea that the email was not
from Microsoft, as the vast majosrity of users have no idea how these
certificates work. They just care about "the email is digitally signed" and
"my email program says it's valid".

Roberto Franceschetti
roberto at sign logsat.com

Please look in particular at the words "This proves to the recipient that
the message is from you and not from an imposter"

And this is exactly what Outlook does, if you look at the actual
*signature* on the message instead of the (incredibly easily forged)
"From". As I said before, anybody that can actually sign the message with
your certificate isn't going to be stupid enough to send it with their
address; to see who the message is from, always check the signature, not
the From.

If you really care about the legitimacy of snail mail, do you check the
return address on the envelope, or compare the actual ink signature to a
known copy of the person's signature? Same thing in email - check the
signature. [Actually, given current image technology, digital signatures
are *much* better than ink signatures...]

 

[Vanguard]

Jeff,

Simple exploit. I use my own Verisign digital certificate to sign an
email. I then alter the from in the email to make it appear from
Microsoft. I then send the signed email to my competitor. He sees an
email coming from Microsoft, digitally signed, with a valid signature,
but unfortunately he's using Outlook which does not warn him that the
sender does not match the certificate (if he had only used Mozilla or
Outlook Express he'd see flags everywhere...). The email will talk
about a new non-existent vulnerability, and perhaps I will attach an
infected attachment, with a copy of maybe Optix Pro to get a backdoor
into his system...

Am I stupid because I used my own certificate...? Not really, you see,
somebody stole my private key which I upladed onto my ISP's public ftp
server to make it easier for me to access it while traveling... in
court my lawyer would be having a field day proving my innocence as a
victim of fraud, and in the meantime I've caused irreparable harm to
my competitor. All because Outlook is the only email client that did
not warn him about the sender not being the one who signed the
email...

...this is only one example of abuse of the exploit.

Yes, if you look deep down in the signature a *very* computer-savvy
user will eventually understand that the sender is not really the
person who signed the email. But I stress on the computer savvy words.
Your average and even above average computer user will have no idea
that the email was not from Microsoft, as the vast majosrity of users
have no idea how these certificates work. They just care about "the
email is digitally signed" and "my email program says it's valid".

Roberto Franceschetti
roberto at sign logsat.com

Please look in particular at the words "This proves to the recipient
that
the message is from you and not from an imposter"

And this is exactly what Outlook does, if you look at the actual
*signature* on the message instead of the (incredibly easily forged)
"From". As I said before, anybody that can actually sign the message
with
your certificate isn't going to be stupid enough to send it with
their
address; to see who the message is from, always check the signature,
not
the From.

If you really care about the legitimacy of snail mail, do you check
the
return address on the envelope, or compare the actual ink signature
to a
known copy of the person's signature? Same thing in email - check
the
signature. [Actually, given current image technology, digital
signatures
are *much* better than ink signatures...]

--
Jeff Stephenson
Outlook Development
This posting is provided "AS IS" with no warranties, and confers no
rights

And why you need to PROTECT your private key at all times. If your key
is stolen, invalidate it. Then anyone getting digitally signed
documents from "you" will see that your certificate is no longer valid.

Whether your e-mail was signed or not, relying on a comparison against
the sender info in the headers, especially those headers that the
*sender* inserts in their own composed *data* within the DATA command,
is flawed in the first place. Since the sender-composed headers cannot
be used to determine the sender accurately, comparing them against the
digital signature is stupid. That's like having a con man show his ID
who you then verify with his buddy con man: you are using the WRONG
source to validate the digital signature.

In your example, you assume the recipient never ever bothered to
actually look at the credentials recorded within your certificate and
that they never ever bothered to check your certificate had not been
revoked. They got a digitally signed e-mail and only use the spoof-able
headers to determine who authored the content of the e-mail? Then why
bother going to the trouble to digitally sign in the first place? Just
spoof the headers as you were intending to do in the first place.
Digital signatures are worthless unless you actually look them up. The
identity and e-mail address are encoded in the security certificate.

 

[Jeff Stephenson [MSFT]]

Simple exploit. I use my own Verisign digital certificate to sign an email.
I then alter the from in the email to make it appear from Microsoft. I then
send the signed email to my competitor. He sees an email coming from
Microsoft, digitally signed, with a valid signature, but unfortunately he's
using Outlook which does not warn him that the sender does not match the
certificate (if he had only used Mozilla or Outlook Express he'd see flags
everywhere...)

And apparently your competitor also didn't bother reading the line in the
message that said "Signed by: Roberto Franceschetti".

You're totally ignoring the fact that there is more displayed than the fact
that the message is signed - *who* signed it is also displayed. So your
exploit won't work, except on the same people that are turning their bank
account numbers over to Nigerians to help them transfer money...

Yes, if you look deep down in the signature a *very* computer-savvy user
will eventually understand that the sender is not really the person who
signed the email. But I stress on the computer savvy words. Your average and
even above average computer user will have no idea that the email was not
from Microsoft, as the vast majosrity of users have no idea how these
certificates work. They just care about "the email is digitally signed" and
"my email program says it's valid".

You don't have to be particularly savvy to be able to read the line that
says "Signed by: Roberto Franceschetti". Outlook tells you that the
message was signed by a valid certificate and it tells you whose
certificate it is without any need to delve into the details. It's all
right there in plain view. What it *doesn't* do is start raising bogus red
flags about legitimately signed mail that is sent by someone other than the
person that signed it. Go back and read the mail posted on your site for
examples of such legitimate uses...

 

[Roberto Franceschetti]

Guys,

Apparently you focus too much on the particular scenarios I talk about and
the names they contain and assume all users have the same knowledge you do.
Ok then, I won't send the email to my competitor since they may know my
name. I'll send an email apparently from CERT to an administrator who posted
a very stupid question on a newsgroup - I have hundreds to chose from, no
offense, I'm saying this just as an example. This will tell me he's your
average user and not a super expert. In the email I'll have a fake CERT
article that invites him to either read an attached (infected) Word
document, or have him download the self-extracting Word document (since
Microsoft now really likes to make avail for download these self-extracting
Word docs...) from
http://download.microsoft.com.d-na.com/support/docs/Q435679/Q435679.exe. If
I make the document confusing enough, he won't notice the real d-na.com
website in there... And please don't get fixated on the "it's his fault, he
should be more careful on what he downloads, as I my whole point is that he
received a digitally signed email, which is *perfectly* valid according to
Outlook. And if he really does check the actual signature and sees Roberto
Franceschetti in there, so what??? HE does not know me, how in the world
does is he to know that I don't belong to CERT?? After all, he received an
email that comes from CERT, digitally signed, valid, and he's sure his
Outlook client, LIKE ALL OTHER CLIENTS, would notify if the sender was not
who signed the message.

My whole point is that now with a digitally signed email it will be 100
times easier to trick the guy in doing something I than without it. ***YOUR
AVERAGE USER WILL NOT GO IN THAT MUCH DETAIL TO VERIFY A DIGITAL
SIGNATURE***, they will rely on the fact that the documentation says what
all other clients *actually do*, and that is, among other things, to ensure
the identity of the *SENDER*, not just the identity of the person who simply
signed the email, please note the identity OF THE SENDER, not of the person
who signed the email.

....And Vanguard, apparently I was too subtle in my explanation of what
happened to my private key. I am a hacker, I send you an evil, infected,
false, however bad you like, email, digitally signed. I also place *on
purpose* my private key for download on a website and advertise it, so that
when your lawyer tries to sue me, I'll say it can be any of the 10,000
people who downloaded my private key that could have sent it. I hope now you
understand that talking about protecting my own key is futile, as I, the
hacker, all that interested me was to spend $10 to get a valid certificate
so I could cause harm using a digitally signed email, without being worried
that what you thing is a unique and absolutely identifiable digital
signature can be traced back to me. You see, I have the logs of the
thousands of IP address who downloaded my private key... any one of them,
especially the one from China and Korea, could have sent you the viruses...

 

[Vanguard]

...And Vanguard, apparently I was too subtle in my explanation of what
happened to my private key. I am a hacker, I send you an evil,
infected, false, however bad you like, email, digitally signed. I also
place *on purpose* my private key for download on a website and
advertise it, so that when your lawyer tries to sue me, I'll say it
can be any of the 10,000 people who downloaded my private key that
could have sent it. I hope now you understand that talking about
protecting my own key is futile, as I, the hacker, all that interested
me was to spend $10 to get a valid certificate so I could cause harm
using a digitally signed email, without being worried that what you
thing is a unique and absolutely identifiable digital signature can be
traced back to me. You see, I have the logs of the thousands of IP
address who downloaded my private key... any one of them, especially
the one from China and Korea, could have sent you the viruses...

Same with a fake driver's license. Same with a digital certificate.
Neither provide incontrovertible proof of your identity. Neither does
your birth certificate, your social security number, your school ID,
biometrics (can be faked if physical and signal security isn't provided
on the input device), and so on. Even your DNA could be spoofed: you
have an ID card with a copy of your DNA which is examined against your
living cell's DNA, yet the ID card is bogus because it is is a fake ID
that you created and implanted your own DNA, or you modified the lookup
database used to compare your tested DNA from your cells to what was
recorded in the database (akin to the scenario of when dental records
are replaced to make a body look like someone else). You were asking
for something equivalent to an ink signature, or maybe even better. As
I said, the 2004 revision of S/MIME to version 3 includes the ability to
include the sender information but I have yet to see any e-mail clients
that support it. Its use would also make impossible ever delivering any
of your e-mails except under very restrictive conditions because you
don't always send using the same mail server or even the same computer.
FedEx deliverying your signed documents doesn't change the fact the YOU
signed them, not FedEx.

What exists on this planet that is any more secure? Nothing you specify
cannot be faked and even perhaps more easily. In your scenario, you're
not even faking the certificate - but who said you couldn't fake your
identity when you got the certificate? One of the Windows Updates
itself includes copies of 2 certificates that were supposedly issued to
Microsoft but turned out to be someone else, so the certificates were
revoked but included in the updates so any lookup on those certs by
applications using them would show they had been revoked. Run the cert
manager (certmgr.msc) and check under Untrusted Certificates. There
they are. The update puts them on your computer to eliminate the need
to connect to the CA (certificate authority) to check them; otherwise,
you are expected to verify that they haven't been revoked (although the
client may do that for you automatically but obviously you need to be
online but, again just as obvious, you had to be online to yank the
e-mails, anyway).

Identity is not based on absolute certainty. It is based on a threshold
of [dis]belief. How much proof is proof? It is unimportant how you
arrived to the meeting to sign over the deed to your house. It is only
important that you provide *sufficient* proof of your identity once you
have arrived there to be granted to sign the papers. You make it sound
like there is some wonderful means of proving your identity that is
incontrovertible (i.e., that it could never be faked). And that would
be?

One of the reasons that certificates haven't caught on for reasonable
proof of identity (of content, not of delivery) is that users really
don't understand them. Just watch a user as they register and receives
a security certificate who then thinks they are going to use it to send
an encrypted e-mail to someone else, and then learns that they instead
need the public key from the recipient to get their certificate's public
key before the sender can encrypt the e-mail sent to that recipient.
You have yourself pointed out why users don't understand the purpose of
digital signatures. Security and ease-of-use are the antithesis of each
other.

Please explain how the sender information can be inserted into the
digital signature while *composing* the e-mail. You haven't sent it
yet. Even though the message/rfc822 information included in the
signature is supposed to include the sender information, that will only
be what is configured in the e-mail client and that is under control of
the user configuring that client. It is still NOT the information added
by the mail server or relay that sends the message. Identifying the
true sender is something in progress, but still that doesn't have to be
the same as the content author. Validating sender and validating author
are two separate tasks. Just because you and typical users confuse the
two doesn't alter what they are intended to be used for.

I can see that the documentation probably does need to be changed in
describing digital signatures. Users should be informed with a warning
that the use of a digital certificate only validates the author of the
content and NOT who or what sent it. As to your example of deliberate
misuse of a certificate, well, that applies equally to all other forms
of identification, too. While people have become accustomed to
differentiating a book publisher from the author of the work, apparently
they cannot fathom the same concept regarding e-mail delivery and
digital signatures. Telling users, in any e-mail client, that the
e-mail address in the certificate happens to match the e-mail for the
sender is not proof that the e-mail was not spoofed as to the sender nor
is it required that the sender be the author. You're comparing two
different identities and demanding they be the same. How could you ever
deliver any legal document if the same requirement were required for
postal mail?

Sender. Author. Different entities which might be the same but are not
required to be the same. Author has some threshold of proof of
identity. Sender [currently] has little or none. And you want the
client to equate these? That would be misleading. I wouldn't want any
e-mail client to equate these. If Outlook Express does it then THAT
client is in error. There is nothing wrong in provided a flag that says
they are the same but that does not equate one to the other nor does it
validate each other. It would be a "nice but not necessarily true"
flag, so it would be a worthless flag.

 

[Jeff Stephenson [MSFT]]

Apparently you focus too much on the particular scenarios I talk about and
the names they contain and assume all users have the same knowledge you do.
Ok then, I won't send the email to my competitor since they may know my
name.

I focus on the scenarios because they're where your claims meet reality.
In this case, it appears that you concede that your claim of an exploit
doesn't measure up...

I'll send an email apparently from CERT to an administrator who posted
a very stupid question on a newsgroup - I have hundreds to chose from, no
offense, I'm saying this just as an example. This will tell me he's your
average user and not a super expert. In the email I'll have a fake CERT
article that invites him to either read an attached (infected) Word
document, or have him download the self-extracting Word document (since
Microsoft now really likes to make avail for download these self-extracting
Word docs...) from
http://download.microsoft.com.d-na.com/support/docs/Q435679/Q435679.exe. If
I make the document confusing enough, he won't notice the real d-na.com
website in there... And please don't get fixated on the "it's his fault, he
should be more careful on what he downloads, as I my whole point is that he
received a digitally signed email, which is *perfectly* valid according to
Outlook. And if he really does check the actual signature and sees Roberto
Franceschetti in there, so what??? HE does not know me, how in the world
does is he to know that I don't belong to CERT?? After all, he received an
email that comes from CERT, digitally signed, valid, and he's sure his
Outlook client, LIKE ALL OTHER CLIENTS, would notify if the sender was not
who signed the message.

And what happens if someone from CERT signs a message with her personal key
but sends it from a generalized CERT address? (As Microsoft does, signing
with a Microsoft key, but sending from an address different from that in
the cert.) Your approach would raise a red-flag, but it's a perfectly
legitimate message.

You're continuing to evade discussing this very common usage of signatures
- sign a message to prove its legitimacy, then send it however you like,
because the signature shows that the signer produced the content and that
the content has not been altered. *That* is what signatures are for, and
the fact that you want them to mean something else doesn't change the
reality.

On the hacking side of things:

What if I preceed my little phishing message with "As you well know,
certificates can only be issued to individuals and not to organizations, so
you'll see a warning that the signer doesn't match the sender on this
message. That's expected." You're assuming an ignorant user, so *they*
don't know that the statement is false, and your "protection" has been
explained away. It's called "social engineering".

Or what if, as a hacker, I send the message signed with my certificate and
from an address of cert.d-na.com? At top of the message I place the CERT
logo and something like "Critical CERT Advisory". At the bottom of
message, I put my name and "Analyst, Network Security, CERT". My from
address contains "cert", and it matches my certificate. But everything is
bogus.

My whole point is that now with a digitally signed email it will be 100
times easier to trick the guy in doing something I than without it. ***YOUR
AVERAGE USER WILL NOT GO IN THAT MUCH DETAIL TO VERIFY A DIGITAL
SIGNATURE***, they will rely on the fact that the documentation says what
all other clients *actually do*, and that is, among other things, to ensure
the identity of the *SENDER*, not just the identity of the person who simply
signed the email, please note the identity OF THE SENDER, not of the person
who signed the email.

The average user doesn't need to go to any trouble at all to verify the
signature - Outlook does so, and displays the results right there in plain
sight. Your proposed "protection" does not add any actual extra
protection, and breaks a number of legitimate scenarios.

 

[Roberto Franceschetti]

Vanguard, Jeff,

I'll keep this one very simple with a very simple question then. If you two
are so right in your beliefs, then how come Outlook Express, Mozilla
Thunderbird and Netscape's mail client, all three work EXACTLY as I'm saying
Outlook should, and correctly warn the user if the sender of the email does
not match the signer of the certificate?

Is Microsoft Outlook right and *all* the others are wrong...? Even
Microsoft's own Outlook Express...? Please answer this simple question.
Again, is Outlook right and the other three are wrong?

Most likely you had business users who were trying to forward signed emails
with who know what rules, and that was causing (correctly) red warning flags
in the messages. Developers then relaxed security to make the paying
customers happy and gave up the extra security check. So much for
trustworthy computing...

Roberto Franceschetti
roberto at sign logsat.com

 

[Vanguard]

Vanguard, Jeff,

I'll keep this one very simple with a very simple question then. If
you two are so right in your beliefs, then how come Outlook Express,
Mozilla Thunderbird and Netscape's mail client, all three work EXACTLY
as I'm saying Outlook should, and correctly warn the user if the
sender of the email does not match the signer of the certificate?

Is Microsoft Outlook right and *all* the others are wrong...? Even
Microsoft's own Outlook Express...? Please answer this simple
question. Again, is Outlook right and the other three are wrong?

Except that Microsoft is both right and wrong (since they behave
differently in different e-mail clients). Equating the sender identity
to the content author identity is misleading. If it matches, you feel
secure that the sender and author are the same - but they don't have to
be. So an alert that tells you that they are different alarms the user
needlessly. However, it depends on the alert you get. If the alert
says the sender and content author are different but doesn't scare the
user but merely makes them investigate the sender identity then it's an
okay alert. However, I suspect the typical user is going to see it like
you see it: the sender and author don't match so they construe that it
is something very, very bad.

Do you know what the other clients say when they notify the user that
the sender and author do not match? I'll bring this up in the Mozilla
group, too. I trialed Thunderbird for just over a month but didn't test
how it handles x.509 certificates and the warning that you indicate.
I'd like to find out how scared they make the user when sender and
author don't match and their rationale for scaring the user.

*IF* the notification is a simple non-scary alert that lets the user
know that the sender and author are different (which can occur for very
legitimate reasons) then it is just another info or status message.
However, it seems very probable that this will mislead users into
thinking that these 2 different identities must be the same for the
e-mail to be considered safe. As you pointed out, the documentation
written for the typical user is misleading. An alert that says the
sender and author are different seems just as misleading.

It will take a bit of testing to see which e-mail clients support the
message/rfc822 MIME part to add sender info to the digitally signed
e-mail. However, even that encoded sender info doesn't have to be the
same as the delivery agent for the e-mail, so the MIME-encoded sender
info might not match the sender info in the headers.

 

[Peter D]

<examples deleted because they are insignificant and don't address the

actual problem - diversion or simple misunderstanding of the logical
fallacy? Dunno. Don't care>

As to your example of deliberate misuse of a certificate, well, that

applies equally to all other forms of identification, too.

But it doens't matter. Justifying the failure of one supposedly trusted
system by pointing out that other systems are as vunerable (a too wide
generalisaiton imho) does ZERO to address the failure of the first.
Certificates give the impression of trust and security. They aren't
trustworthy (as demonstrated). The solution -- excuse my naivety -- would
seem to be to actually fix the problem rather than defending the failure.
Either that or tell every single user to takes steps they haven't been
taught to prevent a problem they don't understand because a system they've
been taught to trust is incapable of handling a relatively easy hack.

 

[Roberto Franceschetti]

In Outlook Express the notice is pretty "scary", as the email is not
displayed, and is replaced with a "Security Warning" notice indicating
that the "The digital ID's e-mail address does not match sender's".

In both Netscape 7.2 client and Thunderbird there is a big red question
mark above the digital signature icon, and clicking on it brings the
warning "Although the digital signature is valid, it is unknown whether
the sender and the signer are the same person. The email address listed
in the signer's certificacte is different from the email address that
was used to send this message. Please look at the details of the
signature to learn who signed the message".

Both of these approaches are fine, it is up to the vendor how to notify
the user of the problem. ***As long s they are indeed notified that
something is potentially fishy***. Which Outlook is not doing at all...
Yes, there is a (remote in my opinion) possibility that the message is
legitimate, but the software should inform the user that they need to
triple-check. Outlook completely ignores the fact the there's a high
probability the message is fake and does not notify the user. I don't
know why Microsoft is so stuck up with this thing, seing how instead
there's all sorts of popup messages and security notices to prevent
users from doing/opening other things...

Roberto Franceschetti
roberto at sign logsat.com