Lotus Notes

Like Outlook, Lotus Notes is targeted at enterprise users. Combining a document database system and standard mail features, Notes relies on a proprietary infrastructure made up of Lotus Notes and Domino servers and Notes clients , generally operating in a hub-and-spoke topology. As is the case with Outlook and Exchange, data can reside on both the client and the server.

Note 

Notes does support POP3/IMAP/SMTP, but in practice most organizations deploy the whole package. Domino is the next generation of Lotus Notes released several years ago. When used here, Notes will refer to both Notes and Domino.

The Lotus Notes client is a free download from IBM, allowing examiners to utilize it for direct examination without the need for pre-existing lab infrastructure. The client opens Notes databases, which are in a proprietary NSF format. Both the client and server store their data in individual NSF files for a specific user . The ID files can be password protected and encrypted, making analysis more challenging.

Notes uses an unusual authentication method that complicates or simplifies forensic examination. Authentication is performed to a Notes client or server through the use of a private key. The key itself is stored in a Notes ID file, and is only viewable through the use of a password, which decrypted the actual private key using symmetrical encryption. When an NSF file is encrypted, only those individuals whose keys were added to the list of valid readers will be able to decrypt its contents, administrators included. To obtain access to these databases, the examiner needs two items:

  • A copy of one of the ID files authorized to view the database.

  • The password to that ID file.

Obtaining the ID file itself can be done by searching the suspect's computer for files with an .id extension (frequently found under Documents and Settings\profile name \Notesdata\). Failing that, the issuer of the ID can be contacted to see whether she retained a copy, or, if she distributed the file through email, whether the original message still exists.

If the ID file is found (and the key has not changed, which it generally does not due to the administrative difficulties in doing so), the password associated with that individual ID file must be obtained. Since the password decrypts the private key independently from any server or database, any version of the ID file can be used. If the initial passwords are recorded with the initial ID issuance, an original copy of the ID with the initial password can be used to decrypt the mail file. If the original does not exist and the password cannot be obtained through traditional means on the ID file available, dictionary guessing is possible using the Passware Suite.

image from book
CASE STUDY: ACCIDENTAL DISCLOSURE

Covert operations rely on secrecy . If a covert investigation is uncovered it may tip off a suspect prematurely and quickly become a salvage operation. This is a potentially difficult situation in computer forensics. A suspect that is aware that she is under investigation may temporarily cease activities of interest, use other systems, or delete evidence. This was the case in a mail investigation gone awry.

Based on the company's procedures, Lotus Notes mail file analysis was a bythe-book operation. Notes mail files would be replicated to the investigators system, the investigators system taken offline (and set to Island as a location), and the analysis performed. After the analysis was complete, any messages present in the mail.box file would be deleted and the system brought back online.

Because of return-receipt functionality, opening messages with a return message header would cause a read confirmation message to be sent to the original sender. In the case of Sent items, the sender could even be the subject themselves . Making matters worse , the message is sent from the investigator 's account, an almost immediate tip-off to the subject that he is under investigation.

One such investigation was underway on an individual suspected of collaborating with outside parties to commit fraud through email. The investigation was fairly standard: examine the user's email activity to look for any suspicious messages to or from external parties, or between the suspect and a group of recently terminated individuals. The suspect was placed under video surveillance, and the email analysis needed to occur without the suspect being made aware of it.

The initial acquisition of the mail file from a corporate Lotus Notes was flawless. A Notes account called Server Replicator was used to minimize the risk of the suspect noticing unusual log file activity, the acquisition was done after-hours, and the analysis machine freshly built from the investigation gold-build disk.

After acquisition, the file was hashed and backed up to DVD, and then analysis was begun on the working copy. The analysis machine was taken offline, and then the Notes client put into Island as a location. Taking the risk of accidentally generating a read receipt, the mail.box file was actually deleted to prevent accidental sending. Therein lay the mistake.

The mail file was indexed then searched, and numerous messages of interest both to and from the suspect were reviewed. No direct evidence of wrongdoing was obvious, but there were several cryptic messages which may have been veiled indication of the alleged abuse. Together with surveillance, a general ledger audit, and interviews with vendors the messages were expected to be of more value. Each message of interest was exported to its own Rich Text Format (RTF) file, saved to CD-R, and printed for inclusion in a hardcopy report.

After analyzing the mail file, a request was made the following day to determine if there were any new messages. The analysis machine was reconnected, and the replication re-enabled from the previous point. To save time transferring the multi-gigabyte file, the analyst simply replicated the changes onto a working copy of the previous mail file. The analysis was performed on the new content the same as it had the previous night.

Early in the morning of the third day, the investigator received an email message from the suspect questioning the presence of return receipts in their mailbox. Why was the investigator reading his mail, and what was going on? Fortunately, the suspect appeared happy with a random audit response, but the investigation had been compromised and the quality of the forensic team called into question.

The analysis that followed revealed an undocumented feature of Lotus Notes had contributed to the compromise. When the investigator deleted the mail.box file, it was believed that the queuing of outgoing mail would not be possible. Instead, Notes assumed that the file deletion was accidental, recreated a new mail.box file, and saved the outgoing messages. When the machine was reconnected for a second replication, all return receipts were sent.

To prevent similar incident in the future, further precautions were built into the procedures. First, the analysis machine for mail was never connected to the corporate network. Working copies were transferred through sneakernet. Second, the ID used for the analysis was the same Server Replicator account used for replication. Third, the analysis machine was re- imaged prior to each replication as opposed to each investigation.

A further restriction was placed on how mail file content was distributed for analysis by legal, Human Resources, and other teams . Mail file content would only be made available in a raw, exported format or hardcopy. Original copies of mail files or the enclosed messages would not be provided. If the message itself was absolutely necessary, a new database containing the same fields as the mail database but not the code to transmit messages was created and messages copied into it for electronic distribution.

The unfortunate investigator mentioned in the preceding story was the author of this book. After completely revamping the company's incident response procedures and forensic SOPs, a screw-up was changed into a positive, but the lesson was well learned: Make sure that procedures are bulletproof, follow them to the letter, and understand what the consequences of deviating from them will be.

image from book
 

Acquisition

Mail files (.nsf files) found on a local machine can be copied as ordinary files using standard forensic practices. Mail files present on a server provide other difficulties. The server keeps the NSF files open for writing, and a race condition may occur if access to the file is not removed from a server standpoint before duplication. This results in a catch-22 situation, as the suspect may notice that her mail file becomes inaccessible, ruling out assured covert duplication (although at 2:00 A.M. the risk may be fairly low). A second technique is to obtain access to the mail file through an administrative account and using the Notes replication feature to create a new copy on the analysis machine for preservation and analysis. In this event, the examiner's ID file is provided read-only access to the account in question or the suspect's ID file is used (if encrypted), and a forensically sound duplication performed.

Tip 

The replication will appear in the server logs, so the forensic ID used should be called something innocuous . Help Desk or Backup or Server Replicator are reasonable names .

To replicate a database:

  1. Request (or assign) read-only rights to the database for the account that will perform the replication.

  2. Open a Notes client and switch User IDs (File Security Switch ID) to the examiner ID which will be assigned rights to the suspect's mail file.

  3. Select File Database Open and navigate to the server and user name of the suspect's mail file.

  4. Open the mail file but do not open any messages therein.

  5. Close the mail file by pressing the Escape key. An icon should now be present on in the bookmarks for that mail file.

  6. Select View Go To Databases.

  7. Highlight the suspect's mail file and select File Replication New replica.

  8. Choose a file name on the local machine and ensure that the Encrypt Local Replica and Copy Access Control List check boxes are cleared, and the Create Full Text Index for Searching and Create Immediately check boxes are selected.

  9. Click the More Settings button.

  10. Clear the Send Documents to Server checkbox.

  11. Click OK to create the new replica.

  12. After the replication and subsequent indexing have finished, obtain the MD5 hash for the newly replicated file and index (which will be in a subdirectory titled with the name of the replica and an .ft extension) and make a permanent copy (to DVD-R or tape).

  13. Create working copies of the replica as needed.

Note 

For court purposes, the replica can be considered an exact, logical copy of the mail file. The physical file may actually be larger and contain fragments of deleted data, a consideration when choosing a duplication method.

Access Control and Logging

Lotus Notes access control lists for a database can be obtained by right-clicking the database and selecting File Database Access Control on the file in question. Note that the Server and local copies may have different permissions. Any individuals or groups (including servers) with rights, including delegated rights, will be displayed. A sample Access Control List for a Notes database is shown in Figure 13-9.

image from book
Figure 13-9: Notes Access Control List

When an individual with access uses a Lotus Notes database, an entry is recorded in the User Log. The log can be viewed by selecting File Database Properties, clicking the Information tab (the "i") and clicking User Detail. The User Detail entry contains data on when the access occurred and whether Read or Write activities happened (and in what quantity). Unfortunately, it does not specify what documents were modified or how. Deletions will show up as Write actions, and replications as a large number of Read actions. Additionally, the number of read and write activities may not correspond to the number of documents. Design elements, views, and subforms may all register as independent accesses .

Warning 

Default logging in Notes is even worse than listed. The log is recorded when a user closes her Notes client. If a user disconnects from the network before closing Notes and never reconnects, her actions are never recorded at all. Use Notes logs with caution.

Lotus Notes keeps a local log of user activity also on the suspect's workstation if the feature is enabled (it is not by default). A file named Log.nsf contains user-specific activity information, including database connections and times and mail routing activity. Unfortunately, the information is kept at a similar level of detail as that in the preceding User Detail log and is of limited value in most cases.

Analysis

Analyzing a Notes mail file is straightforward and follows the same analysis guidelines as other mail files. The Notes database can be examined on a local machine using a standard Notes client or a tool like Paraben Forensics' Network Email Examiner. The primary advantages of the Paraben tool is fourfold: the data is read in a read-only format, the presentation is more suited to forensic examination, reporting features are included, and deleted documents present in the NSF file are automatically recovered. For these reasons, I recommend that organizations that have chosen Notes as their strategic email platform purchase this tool for forensic use.

The mail file itself is made up of several folders, and additional views into those same folders. The default folders of interest are:

  • Inbox. Contains messages that are received before being filed elsewhere.

  • Drafts. Stores emails that have been drafted but not sent yet.

  • Sent. Contains copies of messages that have been sent by the suspect.

  • Trash. Stores deleted messages until it is emptied.

Unlike Outlook and Outlook Express, Notes does not have an Outbox folder. Outgoing messages are queued in the file mail.box on the local system until a server connection is successfully made.

The other major views of Forensic value are the Calendar, To-Do, and All Documents views. The Calendar view contains scheduling information, including details of meetings, for the suspect. The To-Do view is the To-Do list of the individual user. The All Documents view is the most important view. It is a sortable list of all the documents (including email messages, calendar entries, and to-do items) present in the other views. This is generally the view from which analysis occurs.

Searching in Lotus Notes requires prior indexing to be effective (although slower searches can be performed without indexing). The Notes indexing function is relatively powerful with respect to other email software. Notes indexes the contents of messages, but also their respective attachments (for known, registered file types). To perform indexing in Notes for searching:

  • Select View Search This View.

  • Click the More button.

  • Click the Create Index button.

  • Click the Index attached files check box and select Using conversion filters.

  • Select the Index encrypted fields, Index sentence and paragraph breaks, and Enable case-sensitive searches check boxes.

  • Click Ok to begin indexing.

When the indexing is completed, the actual contents of the mail file, including Calendar and To-Do items, can be searched for keywords, senders, and receivers. The search allows for fuzzy searching (for close matches and misspellings of names, very useful for an investigator) as well as field-level searching. One caveat on searching: the standard search does not review attachment names. When searching for a particular document, sorting by size is sometimes more effective. In Figure 13-10, a search for any messages sent to users at http://www.foo.com is run. The SendTo field has two messages that match.

image from book
Figure 13-10: Notes message search

Address Book

Unlike the Outlook/Outlook Express model, Lotus Notes stores addresses in a separate address book database. The Personal Address Book database template, which comes with Notes, contains similar contact management features to those present in other programs. Individual users are likely to have a copy of a personal address book and a company address book present.

The personal address book, like other Notes databases, can be searched by first indexing then using keyword searches as noted previously. The address book itself contains basic contact information (names, addresses, and phone numbers ) and details on Lotus Notes certificates and connections. Of particular use to investigators is the Locations tab, which contains all valid locations and will provide potential pointers to servers used by a particular user. Figure 13-11 shows a sample address book.

image from book
Figure 13-11: Lotus Notes address book
image from book
EMAIL HEADERS

To understand how to track an email's source, the analyst must have a basic understanding of how SMTP, the Internet's mail delivery protocol, functions. SMTP is a relay-based protocol for the transmission of email. When a user sends an email, his mail client (that is, Outlook or Notes) connects to an SMTP server that allows that user to send messages. The message is then relayed from the user-configured local SMTP server to the destination server of the recipient. In practice, most organizations do little Internet-based relaying of messages, the exceptions being Internet-based Antivirus and Antispam services which do act as SMTP relays for legitimate reasons to subscribing companies. The MX record of the organization on their DNS server points directly to a corporate mail gateway, which receives mail directly from senders.

The SMTP protocol works fine as long as everyone validates the original sender is authorized to send the message they are requesting transmission of. This can include validating an IP address, machine name, or email address (account name) and password. Poorly configured servers (and servers intentionally configured to do so) do not perform any authentication. They allow anyone to connect without validating identity and then send messages with that invalid identity. To see an example in action, I will spoof a message and examine the results. Note that the following interchange has been edited to change IPs and names:

 C:\>telnet www.chadsteel.com 25 220 cmssweb Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at  Fri, 8 Apr 2005 14:16:27 -0400 helo foo.com 250 cmssweb Hello [12.101.177.126] mail from: administrator@foo.com 250 2.1.0 administrator@foo.com....Sender OK rcpt to: csteel@yahoo.com 250 2.1.5 csteel@yahoo.com data 354 Please start mail input. To: ceo@foo.com cc: cfo@foo.com Subject:  You're fired (not This is a test of a Spam message. . 250 Mail queued for delivery. quit 221 Closing connection. Good bye. 

Taking the preceding example and analyzing it, five SMTP commands are typed, and the rest is message data.

First, the spoofer telnets to port 25 on any SMTP server on the Internet that accepts connections without authentication as an open relay. The commands typed then are:

  • helo http://www.foo.com. The helo statement establishes the connector's domain. I have intimated that I am saying hello from the http://www.foo.com domain, when in reality I am connecting from an IP address assigned to a completely different domain name.

  • mail from: administrator@foo.com. With mail from: I have established that this message is coming from the account administrator@foo.com. I could have placed any incoming address in this field.

  • rcpt to: csteel@yahoo.com. The rcpt to: command indicates the recipient of the message. In this case, csteel@yahoo.com. There are two things that the server has done improperly (without violating any SMTP rules at this point): It has accepted a message from http://www.foo.com (which it should not act as a sender for) to csteel@yahoo.com (acting as a relay, since it controls only the http://www.chadsteel.com domain), and it has not verified that I am from http://www.foo.com (which I am not) or that I am from an authorized IP range for http://www.chadsteel.com (which I am not).

  • data. The data command establishes that anything following will be considered the body of the message, until two line breaks and a period are encountered . Note that I type the names of frequently confused headers in here: To, cc, and Subject. These will be displayed as gospel by most mail clients, when in reality they are just part of my text and not validated at all (the To and cc lines likewise do not ensure that the message is sent to the named individuals).

  • quit. When the message is complete, the quit command releases the session and disconnects.

The message as received is shown in the following figure. Without looking at the headers, it appears that the message was sent to ceo@foo.com (which it was notremember the To: text in the body of the previous message) and cc:'d to the cfo@foo.com (which it also was not neither of these parties received this email, nor did the http://www.foo.com server even see it). The From: field contains the forged administrator@foo.com address.

image from book

Actual Yahoo! message received

Given the preceding, how can a forensic investigator accurately examine a message? One specific header field cannot be forged as the mail server adds automatically. This is the Received From header, although spammers will frequently add fake Received From headers to the message. At least two Received From headers in any SMTP message will be legitimate: the first and last servers the message goes through. The last server will be one's SMTP server, which should be easy enough to validate. The first server is generally the last line listed unless additional Received From headers have been passed on. In that case, the original sender can still be determined by reviewing Received From headers. All other headers, including X-headers, can be completely ignored.

The relevant pieces of information in the format of a typical Received From header are as follows:

 Received From IP. Received From Domain Name. Received By Machine Name. Datestamp. 

Legitimate, successive Received From headers will have a few things in common:

  • The dates are generally in order and make sense although datestamps on a particular machine may be awry. Any large jumps in date and time may indicate a header falsification with one or both of the headers.

  • The Received From/Received By headers agree. In the previous figure, the first server (cmssweb) receives the message, and the next header up shows that it was relayed by the same server (cmssweb), indicating that those headers are internally consistent.

  • The IP addresses are valid. Although the beginning and end IP addresses may be from private networks, seeing a private, non-routable IP address in the middle of two valid public IP addresses is unusual. Similarly, reserved address space should not appear, nor multicast addresses.

  • The IP addresses resolve properly. If the domain name of a server is given and resolution is possible, the domain name should resolve to the listed IP address in most cases, although load balancing can affect this. Ideally, there is a reverse DNS entry for the IP address which resolves to the domain name in either case.

  • There are no unusual, additional headers between Received From headers. The presence of additional From or To headers between Received From headers may indicate a cut-and-paste point. There can be valid headers inserted by anti-spam or anti-virus software on the gateways though.

A standard methodology is to start at the known good header (one's server) and work backward until an inconsistency arises. The last good header is likely the sourcing machine, and the IP address that machine received the message from is likely the IP address of the sending machine.

image from book
 
Warning 

Because the IP address is associated with a suspect does not always mean that the suspect willingly sent the message. Machines can be compromised by spambot worms. IP addresses can change so the owner at any one time may not be the present owner, and computers can be hacked and used to launch missives. Less frequent but still possible are anonymizing mail relay networks, which will remove the source IP. However, the last anonymous server in the chain will still have its IP listed.



Windows Forensics. The Field Guide for Corporate Computer Investigations
Windows Forensics: The Field Guide for Corporate Computer Investigations
ISBN: 0470038624
EAN: 2147483647
Year: 2006
Pages: 71
Authors: Chad Steel

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net