User Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20170929010941 Steps to reproduce: In the scope of academic research within the efail project, in cooperation with Ruhr-University Bochum and FH Münster, Germany we discovered a security issue in Thunderbird's handling of certificates which allows an attacker to completely replace the keys used for S/MIME encrypted communication. ************************************** S/MIME Certificate Replacement Attacks ************************************** Affected product: Thunderbird (52.5.2) /Attacker model/: Our attacker model is an active attacker who already has access to the victim's S/MIME encrypted emails because either she sits on the wire, she hacked the victim's IMAP account or maybe she even runs the mailserver. Yet she obviously cannot not decrypt the S/MIME end-to-end encrypted communication. This is a strong attacker model, but exactly what S/MIME is meant to protect from. /Goal of the attack/: Let's assume two communication partners -- Alice and Bob -- have already set up S/MIME encrypted communication to securely interchange sensitive emails. The attacker's goal is to change the keys used for encryption. /Attack description/: For enhanced usability, Thunderbird offers the ability to automatically (and without the user noticing) install certificates contained in S/MIME signed emails. At first glance this should not be a security concern as long as only valid certificates signed by a trusted certificate authority are imported. However, various companies (trusted CAs) offer the service of issuing free S/MIME certificates for a certain email address to anyone who can proof to open a link contained in a confirmation mail. This is completely in the scope of our attacker model: The attacker can apply for a certificate for the victim's email address, read his emails and click the confirmation link. This way, the attacker manages to gain a valid and trusted S/MIME certificate, e.g. for the user Bob. She is now able to replace the certificate linked to the user Bob simply by sending an email containing the new certificate to Alice. Further emails from Alice to Bob will be encrypted with the attackers public key. An active MitM attacker now can decrypt these messages, re-encrypt them with Bob's original public key and forward to the Bob. Also weaker attackers like someone who guessed the password for Bob's IMAP account are able to replace the emails. The security of S/MIME encrypted communication is reduced to anyone can read and manipulate a user's emails somewhere within the process of delivery. /Proof of concept/: We first sent an email signed by our university's certificate authority (trusted) and tested if Thunderbird would automatically import the entity's certificate (class 2 -- organization validated) and therefore be able to send encrypted emails to this entity. Secondly, we obtained a free S/MIME certificate (class 1 -- email/domain validated) from a different trusted CA (Comodo, WiseKey, etc.) for this entity and reproduced the steps above. Actual results: Thunderbird silently imported the new certificate without any user interaction required and uses it for any further encrypted communication with the entity. Digital signatures do not help because the attacker can simply decrypt, strip the signature and re-sign the mail using her own secret key. It must be noted that the attack can be easily detected if the user manually checks the certificate details and spots another CA issuer than usual. However, it can be assumed that only few users perform such checks every time before sending encrypted mail. We think that this attack is quite realistic because -- in comparison to most attacks on cryptographic key exchange -- the attacker is not bound a certain key for decrypting and re-encrypting. She can send the original certificate of Bob to Alice, the public keys are restored and the attacker is out of the loop without anyone noticing. Expected results: /Mitigation/: Before importing and replacing new S/MIME certificates, the user should be asked at least once (at least if the certificate is issued by a different CA or has a different trust level). Another option would be to auto-import silently but ask the user which certificate to choose for encryption if multiple certificates for the same email address had been imported.
Ben: can you take a stab at rating this and finding an appropriate owner?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hey Dan, sorry, but I don't read bugmail, including needinfos. So, I never saw your question, sorry. > various companies (trusted CAs) offer the service of issuing free S/MIME certificates for a certain email address to > anyone who can proof to open a link contained in a confirmation mail. This is completely in the scope of our > attacker model: The attacker can apply for a certificate for the victim's email address, read his emails and > click the confirmation link. Right. That goes to the core of SSL and S/MIME trust model: You rely on the CAs. And the CAs unfortunately rely on insecure measures to verify you. Which undermines the whole trust model. We can't really "pin" a certificate for a user either, nor even ping the CA for that user, because the SSL/S/MIME model has expiry and re-issue built into the very model, and the user can change CAs at any time. It's the CA's role to ensure that only the owner of the email address gets a cert, but they fail here. So, yes, it's valid, but it's inherent in S/MIME. PGP doesn't have that issue, because the user needs to manually confirm the validity of every cert. Unless it's signed by another trusted cert, which allows you to renew certs without the trust breaking. S/MIME can't do that.
I'm going to unhide this, because a) efail has been widely published in the media and the paper <https://efail.de> is out, too. b) the attack here is pretty obvious to anybody who has ever obtained a free S/MIME cert and who has a security mind that works c) we need ideas how to fix this
One obvious way would be to require CAs to more carefully verify the applicant of a new S/MIME certificate. How, what exactly to require, that's another question...
Passport? Like when you get a bank account. The banks are required to verify your identity, by passport or government-issued ID card.
Side note: we have not covered these issues in the efail paper (but we reported this `it's-by-design-but-i-kinda-feel-uncomfortable' issue to all affected vendors in February so I guess it's okay for this bug to be public). In the end it's a usability-security trade-off in S/MIME.
You need to log in before you can comment on or make changes to this bug.