Although most users are aware that paper mail can be forged, many are blissfully unaware that email can also be forged. Forged mail can lead to a serious breach of security. Two points of vulnerability that require particular attention are the queue file and the SMTP interface of sendmail.
4.7.1 Forging with the Queue Directory
All versions of sendmail trust the files in the mail queue. They assume that only sendmail has placed files there. As a consequence, a poorly protected queue directory can allow the attacker to create mail that looks 100% authentic. This can be used to send forged mail, to append to system-critical files, or to run arbitrary programs as root or other users. Consider the following bogus qfl0NFMs3g016812 file for sending forged mail (qf files are described in §11.12 on page 445):
Thisqffile causes mail to be sent to george that appears in all ways to come from root. There is nothing in thisqffile to indicate to the recipient (or to sendmail) that the message is not authentic. Now further suppose that thedffile (the message body) contains the following text:
The system has been compromised. Change your password NOW! Your new password must be:
Fuzz7bal Thank you, --System Administration
Unfortunately, in any large organization there will be more than a few users who will obey a message such as this. They will gladly change their password to one assigned to them, thereby providing the attacker with easy access to their accounts.
The queue directory must be owned by and writable only by root or the user defined by theRunAsUseroption (§24.9.102 on page 1083). CERT recommends that the queue directory always be mode 0700.
The MSP queue of V8.12 and above (typically /var/spool/clientmqueue) must be owned by smmsp, with group smmsp, and should be mode 0770.
The queue files placed into the queue by sendmail must be well protected by defining narrow default permissions with theTempFileModeoption (§24.9.118 on page 1097 )prior to V8.12, or theQueueFileModeoption (§24.9.90 on page 1071) beginning with V8.12. A default of 0600 is best for the main queue, and a default of 0660 is recommended for the MSP queue.
4.7.2 Forging with SMTP
We won’t illustrate the SMTP interaction here. But note that anyone can connect to your local sendmail via telnet(1) at port 25 or run sendmail with the -bs command-line switch. Once connected, sendmail must, of necessity, believe everything it receives. The only exception is the hostname sent in the HELO or EHLO message.* In that case, the sendmail program looks up the real hostname based on the connection. If the stated hostname and the real hostname differ, the false name is used as the name of the sending host with the real name added in parentheses:
250 your.host Hello false.host (real.host), pleased to meet you
The real hostname is then used as the sending hostname in the construction of all headers. The result (the header and body received by the user) might look something like this:
From root@false.host Dec 14 14:36:40 2007 Received: from false.host (real.host [real.IP.address]) by your.host (8.14.1/8.14.1) id AA00998; Thu, 14 Dec 2007 14:36:38 -0700 Message-Id: <200712141257.l0NFSKNK016837@yourhost> From: root@false.host (System Administration) To: you@your.host Subject: Change your password now! Date: Thu, 14 Dec 2007 05:47:46 -0800
To improve security at our location you are requested to immediately change your password. The password you have been assigned is:
7Fuzzy1's
Thank you, --root
Fortunately, thisReceived: header contains the name of the real host (which is not always the case). An attentive user can tell that this is a forged message because the host in that header line differs from the false hostname used in the other header lines.
However, most mail-reading programs allow users to filter out (prevent your seeing) uninteresting header lines.† Typically, users choose to ignore headers such asReceived:andMessage-ID:. For such users, the task of detecting forged mail is much more difficult. Instead of seeing the earlier message with real hostnames, they might see the following with only false names:
From root@false.host Dec 14 14:36:40 2007 From: root@false.host (System Administration) To: you@your.host Subject: Change your password now! Date: Thu, 14 Dec 2007 14:36:38 -0800
To improve security at our location you are requested to immediately change your password. The password you have been assigned is:
7Fuzzy1's
Thank you, --root
Clearly, a user who sees only this much of the mail message will be more likely to believe that it is real. There are several ways you can educate your users that mail can be forged:
Teach users what to look for when they receive a message of questionable authenticity.
Rarely, if ever, send mail as root. Always communicate as yourself and always use a distinctive style of writing. If users never see mail from root, they will be more likely to question such mail when it arrives. Even if the forger pretends to be you, that forger will likely not be in a position to imitate your distinctive writing style.
Train users to never send (or ask to receive) clear-text passwords or other security-related information by email.
Train users to use digital signatures, such as PGP or S/MIME, to authenticate email contents.
