020.txt

黑客培训教程

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

Internet Email, How it Works: Check Your Privacy and Security at the Door
By:
David Hesprich
CS230.10
April 30, 1996

--------------------------------------------------------------------------------

Abstract



Most e-mail isn't truly private. It can be intercepted en route; read by any person with root privileges or your account privileges; read from the mailqueue on outgoing, intermediate, or in going systems; redistributed by the recipient; or simply accidently sent to the wrong person by a malformed address. Consequently, e-mail should never be considered a secure medium. Users should make themselves aware of the mail system. System administrators should be aware that most security problems with sendmail are related to the complexity and flexibility of the configuration file. Although it can be possible to use electronic mail as a secure means of communication. Digital signatures and strong encryption can help authenticate the source of messages and protect content. However, the Internet mail system has no provisions for tight integration with such enhancements and they are often awkward and difficult to use. Point to point IP encryption can protect system passwords and communications between hosts. But this type of encryption only works between the encryption gateways. Until security packages become more reliable, cheaper, and accessible to the end user, it is doubtful they will see widespread use.


--------------------------------------------------------------------------------

Index:
SMTP 
Mail headers 
sendmail 
Security 
Probes 
The sendmail Configuration File 
File Permissions 
Packet Sniffing 
Forged Mail 
Mailbombing 
Intellectual Property 
Appendix: Information Resources 
CERT Advisories 
Request for Comments 
Other Information Resources 
Other Security References 
Bibliography 

--------------------------------------------------------------------------------

The Simple Mail Transport Protocol (SMTP)
(Adapted from RFC 821)
There are three steps to SMTP mail transactions. The transaction is started with a MAIL command which gives the sender identification. A series of one or more RCPT commands follows giving the receiver information. Then a DATA command gives the mail data. And finally, the end of mail data indicator confirms the transaction.

The first step in the procedure is the MAIL command. The <reverse-path> contains the source mailbox.

MAIL FROM:<reverse-path><CRLF>
This command tells the SMTP-receiver that a new mail transaction is starting and to reset all its state tables and buffers, including any recipients or mail data. It gives the reverse-path which can be used to report errors. If accepted, the receiver-SMTP returns a 250 OK reply.

The <reverse-path> can contain more than just a mailbox. The <reverse-path> is a reverse source routing list of hosts and source mailbox. The first host in the <reverse-path> should be the host sending this command.

The second step in the procedure is the RCPT command.

RCPT TO:<forward-path><CRLF>
This command gives a forward-path identifying one recipient. If accepted, the receiver-SMTP returns a 250 OK reply, and stores the forward-path. If the recipient is unknown the receiver-SMTP returns a 550 Failure reply. This second step of the procedure can be repeated any number of times.

The <forward-path> can contain more than just a mailbox. The <forward-path> is a source routing list of hosts and the destination mailbox. The first host in the <forward-path> should be the host receiving this command.

The third step in the procedure is the DATA command.

DATA<CRLF>
If accepted, the receiver-SMTP returns a 354 Intermediate reply and considers all succeeding lines to be the message text. When the end of text is received and stored the SMTP-receiver sends a 250 OK reply. Since the mail data is sent on the transmission channel the end of the mail data must be indicated so that the command and reply dialog can be resumed. SMTP indicates the end of the mail data by sending a line containing only a period. A transparency procedure is used to prevent this from interfering with the user's text.

Please note that the mail data includes the memo header items such as Date:, Subject:, To:, Cc:, and From:.

The end of mail data indicator also confirms the mail transaction and tells the receiver-SMTP to now process the stored recipients and mail data. If accepted, the receiver-SMTP returns a 250 OK reply. The DATA command should fail only if the mail transaction was incomplete (for example, no recipients), or if resources are not available.

Example of the SMTP Procedure
This SMTP example shows mail sent by John.Doe at host Alpha.ARPA, to Jones, Smith, Lee, Green, and Brown at host Beta.ARPA. Here we assume that host Alpha contacts host Beta directly.




220 Alpha.ARPA Simple Mail Transfer Service Ready
HELO Beta.ARPA
250 Alpha.ARPA
MAIL FROM:<[e-mail]>
250 OK
RCPT TO:<[e-mail]>
250 OK
RCPT TO:<[e-mail]>
251 User not local; will forward to <[e-mail]>
RCPT TO:<[e-mail]>
551 User not local; please try <[e-mail]>
RCPT TO:<[e-mail]>
550 No such user here
RCPT TO:<[e-mail]>
250 OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
Message headers and body...
<CRLF>.<CRLF>
250 OK
QUIT
221 Beta.ARPA Service closing transmission channel 




The mail has now been accepted for Jones and Brown.

In the case of Smith, the 251 User not local reply indicates that the receiver-SMTP knows the user's mailbox is on another host and indicates the correct forward-path to use in the future. Note that either the host or user or both may be different. The receiver (in this case Beta) takes responsibility for delivering the message.

For Lee, the 551 User not local indicates that the receiver-SMTP knows the user's mailbox is on another host and indicates the correct forward-path to use. Again, note that either the host or user or both may be different. The receiver (Beta) refuses to accept mail for this user, and the sender (Alpha) must either redirect the mail according to the information provided or return an error response to the originating user.

Green did not have a mailbox at host Beta.

RFC 821 has more information on the Simple Mail Transfer Protocol, as well as the SMTP commands.





Mail Headers
Every mail message is composed of two parts: a header and a body. The header is composed of all lines from the first until a blank line. The body consists of all lines after the first blank line. The first blank line acts as a separator and belongs to neither the header nor the footer. Although there are many header lines that can appear in a mail message, some are required, some are optional, and some lines may appear more than once.

From: not required for some programs (like mh), it is only required by some programs (like /bin/mail), it is added by the program that performed the actual delivery. 
Delivery-Date: is the date and time the message was delivered into the recipient's system mailbox. This line is usually added by the program that performs final delivery (usually /bin/mail). 
Return-Path: contains the address the recipient can use to reply to the sender. It should only be added by the system that performs final delivery (sendmail). 
Received: this line is added for every machine that handled the message moving it from the sender to the recipient. Each line represents a hop. If a message goes through too many hops, the message will bounce (fail) and be returned to the sender as a failed message. Note that this actually two lines, the indented line following it is a continuation of the preceding Received: line. 
Date: the date and time the message was originally sent. 
From: the email address and full name of the sender. The order of the two may be reversed and still be syntactically correct. 
Message-Id: a unique identification string constructed from the date, time, a unique filename, and the originating machine. 
To: a list of one or more recipients, separated by commas. 
The header used by sendmail is defined by RFC822, with some additional explanation found in RFC1123. Several other RFCs define additional headers.





sendmail
Sendmail is a mail transport agent (MTA). Like other MTA's such as MMDF, Smail, and Zmailer, sendmail is a program which handles the delivery of mail for many users and the forwarding of email between machines or networks. Consequently, sendmail needs to be able to route mail between various types of networks (local, UUCP, Internet, BITNET), which sendmail does through the use of a very flexible (and complicated) configuration file and supporting programs, files, tables, and services.





Security
The sendmail program can be a potential doorway to system abuse since sendmail is typically configured to run as an setuid root process. This means that sendmail has all the powers and privileges of the root user. Incorrect file permissions can be used to trick sendmail into giving root privilege away. For instance, forcing sendmail to run the following shell script will create a setuid shell:

#!/bin/sh







cp /bin/sh /tmp/.shell







chmod u+s /tmp/.shell
Since sendmail runs most of the time as root, any user which runs /tmp/.shell will then have root access privileges. The Morris Worm used a flaw in old versions of sendmail to gain access to thousands of machines.




Probes 
One method of attack upon a system is to probe it in order to either force it to give up information about itself which may make it more susceptible to attack, or to look for security loopholes or system software bugs.

SMTP debug and showq
A probe attempting to exploit an unfixed bug can use the SMTP debug and showq commands. The debug command allows the local sendmail to be placed in debugging mode (as the -d command-line switch) from any other machine attached to the network. The showq allows other machines to request a list of the contents of the mail queue (like the command mailq on the local machine).

If during compilation of sendmail the SMTPDEBUG macro is defined, the SMTP commands debug and showq are enabled. SMTPDEBUG should never be defined in a official release of sendmail. This can be checked in the following manner:




# telnet somehost.domain.com 25
Trying 198.76.10.2 ...
Connected to somehost.domain.com.
Escape character is '^]'.
220 somehost.domain.com ESMTP Sendmail 8.7.4/8.6.12 ready at Wed, 20 Mar 1996 13:42:43 -0500 (EST)
debug
500 Command unrecognized
quit
221 somehost.domain.com closing connection
Connection closed by foreign host.