5

Scenario: Acme Corp. needs to collect evidence to support their side of a case in court. Part of this evidence may include e-mail messages. Certain employees who do not have administrative access to the e-mail server, but may have administrative access to their workstations, might have motive to alter this evidence.

Acme Corp. employees do not regularly make use of digital signatures in e-mail messages.

Acme Corp.'s e-mail is stored on an Exchange server which is regularly backed up, and employees download messages to Outlook on their workstations. Folder size limits are in place on the server, so employees commonly archive messages to PST files locally on their workstations.

Question 1: Given this scenario, how easy (on a scale of "Joe User" to "3l33t H4x0r") is it for suspect employees to alter un-signed e-mail evidence...

  • ...in their Inbox?
  • ...in their PST file?

Also, to what degree can this be done? (Subject/Body/Sender/Recipients/Timestamps)

Question 2: What kinds of tools might be used for modifying this un-signed e-mail evidence? (Or, can it be done easily without specialized tools?)

Question 3: How can Acme Corp. defend (or disprove) the validity of the un-signed e-mails?

Iszi
  • 26,997
  • 18
  • 98
  • 163

4 Answers4

7

Unless there is some special configuration I'm not familiar with:

  1. Joe user. There is an Edit function, hiding right there under Other Actions (in Outlook 2007, at least...). Note you can only see this when you open it in full message view, and not in the preview pane (as I usually read it...). Note also that this is not available via OWA.
    It may be possible to configure Exchange mailboxes to prevent that, but I'm not familiar with such a configuration (and no Exchange handy right now to check, sorry).
    Re edit: It's a good question, what parts can be modified - subject/body/attachments are easy. Recipients and timestamps are not enabled by the Outlook UI, so at least JoeUser won't be piddling with those fields so easily... However, I'm sure it is possible to modify these, using other tools (or directly editing the file), but I'm not familiar with that. Also note the addition on the next point...

  2. Outlook! :)
    On the other hand, I have not researched deeply into the file formats or forensics - it is possible that outlook tracks changes to received messages, inside the file.
    Also, note that I assume we're talking about received messages, not sent - it is trivial to fake any kind of claimed sent message, without actually sending it.
    Besides the previous, note that if the email is not signed it is simple to send yourself a fake email message, that claims to be from any other user you want. At that point, of course, you can forge any part of the email you want. (This does depend, however, on your Exchange configuration - by default, it is possible to send near-arbitrary SMTP messages, though this can of course be changed, as it should be).

  3. It cannot - in neither direction. Excepting, perhaps, a strict backup regime. 'Course, that would still be a steaming pile of work, to pull up the exact messages, and prove that it was the originally received message - this could probably only be done right if the backups were set correctly in the first place (i.e. backup the message as received, and not just what the user does in his inbox).
    Also, I am not including here any form of behavioral forensics...

But there is a reason that digital signatures are required.

AviD
  • 72,138
  • 22
  • 136
  • 218
  • Thanks for the info. I've edited my question to include one more factor - can you answer for that? – Iszi May 16 '11 at 19:56
  • @Iszi - added, and also added another point in 2. (though part of that might only apply to older versions of Outlook, I'm not sure if the defaults have been changed in the latest.) – AviD May 16 '11 at 21:11
  • "But there is a reason that digital signatures are required." +1 – Rakkhi May 17 '11 at 09:34
4

This setup does not provide non-repudiation. Non-repudiation is very challenging to achieve, and based on what I am hearing, you are nowhere near it.

Based on your description, you're not going to be able to prove the validity of the emails through technical arguments alone. You will have to use non-technical arguments. You might find other witnesses to testify to what is in the emails. You might argue that what is in the emails is consistent with other sources of evidence: ideally you could show a constellation of interlocking evidence that is so overwhelming, self-consistent, and diverse that there is no plausible other interpretation.

But the collection of email on the server does not prove a thing. It could have been modified, for all you know: at least, you can't reasonably rule it out, based upon the information you're giving us here.

D.W.
  • 98,420
  • 30
  • 267
  • 572
2

Firstly, I am interpreting your question to mean that end-users will not be using digital signatures. They can't be bothered, etc. I do answer this with the use of non-interactive signatures on the server that the end-user would never see or be affected by.

Question 1: ... how easy is it for suspect employees to alter un-signed e-mail evidence... in their Inbox? ...in their PST file?

As the user has control to edit anything on their local machine, and to delete or create items at will on the server, one must assume it is trivial.

Question 2: What kinds of tools might be used for modifying this un-signed e-mail evidence? (Or, can it be done easily without specialized tools?)

A text editor, a hex editor, or even Outlook itself may be options.

Question 3: How can Acme Corp. defend (or disprove) the validity of the un-signed e-mails?

Anything sent through Exchange should be sent by an authenticated client, or by SMTP. Your internal users should not be using SMTP. I would allow nothing claiming to be one of your users to be received or forwarded on your Exchange server via SMTP. I would log any emails that are sent from your company. If you sign emails sequentially with the signature of the last email included in the text that is signed for the next email, you can create a chain that proves at least the order that emails were sent. This can help to reliably show the time an email was sent and will prevent anybody from modifying or removing something in the past without it being detected in the chain.

If you take the step of saving and signing each email and you only permit sending email through the server by authenticated means, then any email sent through the server should be verifiable. You can also verify that no emails were later removed. Remaining likely attacks:

  • A user's credentials are compromised. Email appears to be legitimately from them.
  • Somebody sends email through another sever. Your client / customer / etc. doesn't realize this.
  • Somebody with control of the server sends an email and somehow removes it from the signing queue.
Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
  • I think he was asking retroactively... But a question, does Exchange support this signature signing? It sounds like a very interesting solution (though obviously not foolproof), didnt know Exchange has that mode. – AviD May 17 '11 at 20:00
  • I doubt it does that out of the box, but there are archival / compliance programs that will independently preserve messages. http://www.gfi.com/mailarchiver looks like one such tool. The ability to create plugins for Exchange certainly leaves room for this task. Also, one could sit a Linux machine in front of it with some mail filter scripts. – Jeff Ferland May 17 '11 at 20:54
0

Question 3 (Part 1):

If the message was sent between two companies, or between two SMTP relays that use DKIM (an anti-spam tool) there might be a secret digital signature that they may not be aware of.

Namely it can be proved that a message was not altered if the message has a DKIM signature and passes. This is a hidden signature that most people don't think of that is not related to SMIME and is often secretly included in messages. For example Yahoo and GMail DKIM sign all outbound messages unbeknownst to senders or recipients. Depending on your scenario, it's possible that the messages you are concerned about are DKIM signed, but the presence of this signature is unknown to you or your client.

Just know that a DKIM signature

  • ... is not SMIME (often called a digital signature)
  • ... won't be displayed in Web browsers / Outlook even if it exists
  • ... is a tool used in Anti-spam technologies
  • ... may not sign the whole message, or a portion therein (via the -l parameter, or by omitting key headers of the message)
  • ... Can fail if a intermediate SMTP server modifies the message (mailing lists, homebrew SMTP forwarders, etc)

Generally speaking a signed DKIM message will pass if it's not modified. If a DKIM message fails, there is a small chance that a skilled email engineer / developer could make the encryption "pass" if the failure is due solely to to infrastructure concerns.

TL;DR - A signed DKIM message that passes AND signs the from, to, subject, and body means the message was not modified. A failure of DKIM means nothing (mal-intent or otherwise).

(Part 2)

Outside of a DKIM pass, it's not possible to prove that the messages were not tampered with in this situation. However there might be a way to detect tampering looking at the MAPI properties of the message. For starters the "Header" property will contain the original subject if the subject line was edited.

If the message was modified there are various internal Date/Time stamps that may be updated, and depending on the Outlook version, the username who modified the message is stored in the message as well. When I last investigated this, there was a difference between which fields were updated during a message move (from one folder to another) vs right clicking and editing the message (or marking it as read).

The message body is stored in at least two locations in a MAPI message: the plain text version, a rich text version, and the original. It is possible that an edited version of the message would update one (but not all) instances of the message.

If the message resides on the Exchange server database, the message may reside in one or more "streams". These message streams exist for the exclusive usage of MAPI or OWA and sometimes go out of sync. This can happen if a message is modified, and "property promotion" might be able to shed light on a modified message.

Having said that, outside of DKIM or SMIME there is nothing to prove that a message was not modified, however there might be a way to prove it was altered.

The tool you need to investigate these low-level properties is called MFCMapi.

makerofthings7
  • 50,090
  • 54
  • 250
  • 536