2

This is a scenario I have at work.

We're receiving emails with .p7s attached files from a single user of a company(hence the company domain for eg. abc.com) our users interact with via mail. We use IBM Lotus Notes for our email.

There are other users of the same domain who also send our users emails but in those emails we do not see a p7s file.

Also since we use a attachment filtration policy on our email gateway, the gw quarantines the email because of the file extension. The attachment filtration policy specifically contains p7s, p7m, pif, scr file formats, which were put there by some previous fella before. Which just raises another question about whether we should block this filetype at the email gateway?

Also we asked the same user to send us a simple plain text email for testing to our gmail accounts and the .p7s file wasn't attached to this email.

I read up on smime.p7s usage, but cannot understand why is it that only that one particular user's incoming email shows this file while others do not.

Also I guess I can just whitelist the .p7s extension and the emails won't be quarantined by the gw, would that be a security risk of some sort?

Improve this question
4
  • You asked the sender to send a plain text, but did you ask him/her to dig up what (s)he sent that has the attachments?
    – user13695
    Commented Jul 25, 2016 at 14:45
  • @JanDoggen I think you referring to the part where the user emailed our gmail account. He just sent an email with basic text and then he did the same to our company domain, and the p7s attachment was not seen on gmail but appears on our email client - lotus notes.
    – allwynmasc
    Commented Jul 25, 2016 at 15:08
  • Can you test these? --> What happens when your user sends email using other email software? What happens if another user from that same company sends you mail using the same software as your 'problem user'? What software are they using anyway?
    – user13695
    Commented Jul 25, 2016 at 15:21
  • @JanDoggen well we only use lotus notes and im afraid i cant do that test, but the issue isn't our client, it's that our email gw blocks this person's email because it violates the attachment extension policy and that the attachment is visible only from this one user from the other side. I will have to find out what client they use at their end though, will update the post then.
    – allwynmasc
    Commented Jul 25, 2016 at 15:41

3 Answers 3

Reset to default
1

I would suggest changing the policy to not quarantine "bad" mails, instead, use the policy word "DISCARD". But for p7s I would suggest stripping the attachment out, as these are signatures. However, they can contain S/MIME encrypted mails causing viruses to leak through. Stripping the attachment out and letting the rest through is safe.

For p7m, pif, scr, its better to DISCARD the whole mail silently without notifying either sender or receivr, without quaratine.

Improve this answer
8
  • 1
    can you explain this "However, they can contain S/MIME encrypted mails causing viruses to leak through" a bit more. When do they actually leak viruses? And we have a policy to basically quarantine everything so nothing important is ever just deleted without manual intervention. So stripping the p7s sig is totally safe, also why do you say discard the p7m etc. attachments?
    – allwynmasc
    Commented Jul 25, 2016 at 15:47
  • @allwynmasc As they are encrypted, it means that a mail containing a malicious file, can leak through your perimeter detection, as only the end user has the private key to decrypt it. Note that many E-mail program has mimesniff functions, which means it might detect that the p7s file is actually a p7m file, and "correct" it internally. Stripping the sig is totally safe, either it was a signature and then nothing would happen, or it was a malicious encrypted file and then it got removed.
    – sebastian nielsen
    Commented Jul 26, 2016 at 0:00
  • In many cases, its the only attachments that is the problem, not the mail itself, and thus its a bad idea to quarantine mails because it contains a "inpermissible" attachment. Thats why its better to have 3 security levels: 1: Good attachments - let through. 2: Risky attachments, not neccessarly bad - strip the attachment and let the rest through. 3: Known bad attachments, like .scr (screensaver, never legitimate to send in mail at all), .p7m (encrypted mail, attempt to bypass filters etc), then you simply toss the mail in /dev/null without notifying anyone.
    – sebastian nielsen
    Commented Jul 26, 2016 at 0:04
  • The problem with quarantining "bad" attachments is that you cannot know if they are safe. Take a encrypted mail for example, you cannot know if the attachment contains a virus, you either have the choice of deleting it or releasing it through. So quarantining only wastes space and encourages unsafe decisions. You can, as I said, usually decide with automatic tools if the file is worth keeping, and thus pass it on, or just discard the attach (for example, deleting office files containing macros, or deleting .scr). And in some cases, you can know from the attachment that the mail is abusive.
    – sebastian nielsen
    Commented Jul 26, 2016 at 0:09
  • well it's going to be very hard to change overall policies because of "how things are done here". So right now we just never delete anything! We have never received any p7m attachment files yet. And as i mentioned we get these p7s files from just one guy from the other side while his colleagues can mail us just fine. Could this then be a misconfig with his email client or a worm acting out on his pc? I still dont have the info on what client they use, i'll update that asap, mostly its got be outlook is my guess.
    – allwynmasc
    Commented Jul 26, 2016 at 5:56
1

The .p7s file is a detached digital signature of email letter (the whole .eml file). It can't make any harm but adds an additional level of security. See I video tutorial about it How to Get a Verified Email Badge (Extremely Rare). Users can just ignore the file if they see it but modern email clients are just hidding it to avoid confusion.

The digital signature contains a certificate with a public key of a sender. A mail client (e.g. Thunderbird) will remember it and when next time you will send a letter to the contact it will show to you a button Encrypt message. In future the email clients may start always encrypt messages without asking a user.

The encrypted S/MIME message will be sent with the smime.p7m attachment and only your contact's email client can decrypt it. But if a corporate firewall will remove the p7m files then a receiver won't be able to see the letter at all.

The encrypted message may contain attachments with trojan programs and viruses or they can be a plain fishing. So they do have some security risk. This should be handled properly by an email client itself and by antiviruses on the user's computer.

Also please note that your S/MIME certificate is not published in internet and you can receive an encrypted mail only if you previously sent a letter to the contact. Or some contact shared or resent the certificate with an attacker. So the attack vector here is initially smaller.

Many email clients like Thunderbird got a support of the AutoCrypt.org which is another "silent" level of a simpler end-to-end encryption. So a firewall may already miss encrypted mails unless it will start to remove the Autocrypt headers.

Improve this answer
1

There is nothing wrong with smime.p7s attachments. They are merely the digital certificate of the sender. The receiver will need that in order to send back encrypted emails, which will be the smime.p7m attachment. You should never filter out smime.p7s attachments, they aren't bad. You don't need to filter out smime.p7m attachments either, those should get scanned by the email client after decryption. Restricting users from getting/sending them is the same mentality as preventing them from using a VPN.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .