Unauthorized reading confirmation from Outlook
I've just got an interesting idea about how a malicious e-mail sender
could try to get a unseen by the recipient reading confirmation,
including the IP address of the recipient. I was working on S/MIME
messages and I thought about the signature validation process, where
some of the steps could require external information (like a CRL) to
be accessed. The interesting part of it is that the location of this
information can be included in the message itself, as the PKCS#7
package can also include the certificate used to generate the
signature.
I went into Microsoft documentation about the validation process from
Outlook, and found this:
(reference: http://technet.microsoft.com/en-us/library/bb457027.aspx#EKAA)
When the first certificate in the chain is validated, the following
process takes place.
1. The chaining engine will attempt to find the certificate of
the CA that issued the certificate being examined. The chaining engine
will inspect the local system certificate stores to find the parent CA
certificate. The local system stores include the CA store, the Root
store, and the Enterprise Trust store. If the parent CA certificate is
not found in the local system certificate stores, the parent CA
certificate is downloaded from one of the URLs available in the
inspected certificates AIA extensions. The paths are built without
signature validation at this time because the parent CA certificate is
required to verify the signature on a certificate issued by the parent
CA.
2. For all chains that end in a trusted root, all certificates in
the chain are validated. This involves the following steps.
* Verify that each certificate's signature is valid.
* Verify that the current date and time fall within
each certificate's validity period.
* Verify that each certificate is not corrupt or malformed.
3. Each certificate in the certificate chain is checked for
revocation status. The local cache is checked to see if a time valid
version of the issuing CA's base CRL is available in the cache. If the
base CRL is not available in the local cache, or the version in the
local cache has expired, the base CRL is downloaded from the URLs
available in the CDP extension of the evaluated certificate. If
available, it is confirmed that the certificate's serial number is not
included in the CA's base CRL.
As described, the recipient system will try to gather the CA
certificate from a URL that is specified on the signers' certificate,
that is embedded in the signed message. A specially crafted
certificate (not from a trusted CA) can be generated with an AIA
(Authority Information Access) extension containing an URL controlled
by the malicious sender. By doing that the sender will immediately
know when the message recipient read the message on Outloook. I
performed some tests that confirmed this scenario. Other e-mail
clients like Mozilla Thunderbird and Lotus Notes have not presented
the same behavior. It seems that only Outlook implements this part of
RFC2459. It's behaving in the right way, but I believe that the user
should have the ability to disable it.
Here is a sample of a web access from the recipient of a message
crafted like that. On this case, the AIA address included in the
certificate was poitining to the
"http://www.securitybalance.com/ca.html"; URI.
10.10.10.31 - - [12/May/2008:15:47:43 -0400] "GET /ca.html HTTP/1.1"
200 116 "-" "Microsoft-CryptoAPI/5.131.2600.3311"
(anonymized IP address)
Microsoft was notified about this issue last May.
Augusto Paes de Barros
http://www.securitybalance.com/