3

There is a company that has problems with Phishing (try to defend against it). Using internal mails.

The big question: What security problems can occur when trying the following solution?:

All mails that are NOT signed and encrypted are NOT accepted/bounced.

If given user will never communicate with the outside word via e-mail then mails sent/received to/from the public internet need to be bounced back.

Of course only a valid users key is accepted, not *, so allowed keys are whitelisted.

Can this solution be tricked somehow?

  • We can only think of that a valid users machine would be hacked from outside and thus the attacker would have a valid keypair.

  • Or if trying with S/MIME, there could be a CA that would offer bogus certs.

3

Be careful that you don't bounce a bounce message. Otherwise, you can self-DDOS your mail server.

It may be safer, at least in the first few months of trialling this, that instead of bouncing emails, you'd accept them but deliver the message with a big warning that the email was not signed properly, and may have been an attempted phishing, and that the recipient must not act on the email unless they verify any information therein through other secure means.

If an attacker managed to obtain a user's private key, then they would have been deep enough in that person's machine that anything that person does would be suspect, whatever system you're using. So this is not an issue you need to worry about. Additionally, requiring signatures gives you the ability to identify the person who leaked their private keys and discipline/retrain that person. You can also revoke that key easily, while the attacker would have to look for someone else's system to break.

A CA aren't supposed to issue an email certificate unless they can prove the email address control. All public CA publishes their Certificate Practice Statement, which details how they validate someone's identity before signing a certificate for that person. You can choose a CA that have an acceptable CPS and limit your attack surface so your mail server would only trust that particular CA for mails within your domain. If you distrust any public CA, you can also run an internal CA so that you don't need to rely on a third party for your internal employee identification.

Of course only a valid users key is accepted, not *, so allowed keys are whitelisted.

Rather than whitelisting user keys directly, I'd suggest white listing trusted verifier (CA/Web of Trust) keys instead. Only servers whose public keys are certified by the verifier would be accepted by the mail server. This separates the responsibility between verifiers and mail server administrator, and allows you to add/remove people without mail server redeployment/reconfiguration. For example, you can train HR to become your identity verifier, and they'd be responsible for signing and revoking certificates as people come and leave the company.

1

It sounds like there are simpler things to consider before you go down that route.

If the company is receiving emails from their own domain, I would first check that you have SPF in place, and I would also consider using DKIM (which will in turn mean you can do DMARC, which may be of some use here).

I would also check how the mail servers are actually configured, to ensure they cannot/are not being abused due to weak verifications of sender details.

There isn't necessarily an issue with the setup you propose, but it does sound like there is a lot of potential to get things wrong, and cause important emails to get lost.

One other thing: it sounds like either users are not authenticating, or they are, and you still see these phishing emails - I would make some efforts to find out which of these is true, and see what could be done (personally, I only allow users to send mail via submission (with password and cert-based auth), and access to that port is via VPN only - meaning you can configure your public facing SMTP to prohibit emails where your domain is the sender.

tl;dr: the setup you propose can be circumvented by compromising your users, by the sound of it. That will always be a problem, but it does sound like you have other issues with your email setup that need looking into. You are talking about making sure the emails themselves are 'good', but before that, make sure you know that your servers and users are legitimate.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.