18.6 Usenet Forgery and Tracking

Usenet is made up of news servers all over the world that communicate using the Network News Transport Protocol (NNTP). Each server subscribes to a selection of newsgroups and stores a copy of each Usenet newsgroup it subscribes to. There is no centralized server that coordinates Usenet - it is a cooperative network.

More, specifically, when a message is posted to a newsgroup, it is initially stored on only one news server. At a prearranged time, this news server automatically sends the message - along with all of the other new messages that it has - to a prearranged set of neighboring servers. These servers add their names to the message header and pass the messages on to other servers, and so on. In this way, messages are eventually passed along to all of the other people who participate, to create the global Usenet network. Like e-mail, the path a Usenet message takes can often be traced back to the computer used to send it. To better understand Usenet messages, it is helpful to have a basic understanding of NNTP.

The NNTP command commands that news server servers use to exchange messages are defined in RFC 977. For instance, the group command tells the server which newsgroup the message is intended for. The post command indicates the beginning of the actual message. Take a moment to read the description of the post command in this RFC:

If posting is allowed, response code 340 is returned to indicate that the article to be posted should be sent. Response code 440 indicates that posting is prohibited for some installation-dependent reason.

If posting is permitted, the article should be presented in the format specified by RFC850, and should include all required header lines. After the article's header and body have been completely sent by the client to the server, a further response code will be returned to indicate success or failure of the posting attempt.

Note that the server allows any header lines to be entered, allowing individuals to forge Usenet messages. However, the message header will often contain the originating IP address. For example, the following shows a forged Usenet message being created by connecting to port 119 on a news server and entering NNTP commands.

    % telnet news.sending.com: 119    200 news.sending.com NNRP server INN 1.4unoff4 05-Mar-96 ready    (posting ok).    group alt.test    211 1280 633804 635463 alt.test    post    340 Ok    Subject: Usenet forgery    Path: none!nada    From: forger@forgery.com    Newsgroups: alt.test    This is a forged Usenet message.    .    240 Article posted    quit    205

This resulted in the following message - the header contains the IP address of the originating computer (192.168.10.4).

Path: news.ycc.corpX.com!pln-

e!extra.newsguy.com!lotsanews.com! howland.erols.net!

newsfeed.concentric.net!news.sending.com!none!nada

From: forger@forgery.com

Newsgroups: alt.test

Subject: Usenet forgery

Date: 27 Sep 1998 17:37:13 GMT

Message-ID: <6ult49$fha@news.sending.com>

NNTP-Posting-Host: 192.168.10.4

This is a forged Usenet message.

The following section describes how to interpret the header information in a Usenet message and determine the origin.

18.6.1 Interpreting Usenet Headers

A standard Usenet message consists of several header lines, each consisting of a keyword followed by a colon and some additional information. The required header lines in a Usenet message are "From," "Date," "Newsgroups," "Subject," "Message-ID," and "Path." Other optional header lines such as "NNTP-Posting-Host" and "X-Trace" are often added to help determine the origin of the message. One of the most useful lines for tracking messages is the Path line. As stated in RFC 1036:

2.1.6. Path

This line shows the path the message took to reach the current system. When a system forwards the message, it should add its own name to the list of systems in the "Path" line. The names may be separated by any punctuation character or characters (except "." which is considered part of the hostname). Thus, the following are valid entries:

cbosgd!mhuxj!mhuxt

cbosgd, mhuxj, mhuxt

@cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.COM

teklabs, zehntel, sri-unix@cca!decvax

(The latter path indicates a message that passed through decvax, cca, sri-unix, zehntel, and teklabs, in that order.) Additional names should be added from the left. For example, the most recently added name in the fourth example was teklabs. Letters, digits, periods and hyphens are considered part of host names; other punctuation, including blanks, are considered separators.

Normally, the rightmost name will be the name of the originating system. However, it is also permissible to include an extra entry on the right, which is the name of the sender. This is for upward compatibility with older systems.

The "Path" line is not used for replies, and should not be taken as a mailing address. It is intended to show the route the message traveled to reach the local host.

However, some part of the Path header may be a forgery. Copies of the message from multiple sources will show which portions are forged - the forged portion of the path will remain constant while the true path will vary depending on which servers the message passed through. Another useful header for tracking is the Message-ID. As with e-mail, the Message-ID is usually added by the first news server that receives the message but can be forged. The NNTP-Posting-Host and X-Trace headers often show the actual source, but this can be forged as well. NNTP-Posting-Host is an extension not mentioned in the original RFC but described in RFC 2980 as follows:

3.4.1 NNTP-Posting-Host

This line is added to the header of a posted article by the server. The contents of the header is either the IP address or the fully qualified domain name of the client host posting the article. The fully qualified domain name should be

determined by doing a reverse lookup in the DNS on the IP address of the client. If the client article contains this line, it is removed by the server before acceptance of the article by the Usenet transport system.

This header provides some idea of the actual host posting the article as opposed to information in the Sender or From lines that may be present in the article. This is not a fool-proof methodology since reverse lookups in the DNS are vulnerable to certain types of spoofing, but such discussions are outside the scope of this document.

Not all servers include the optional "NNTP-Posting-Host" or "X-Trace" lines, making it more difficult to determine the source of a message. In such cases, it may be necessary to look for "rough edges" in the message that can be used to search for related information on the Internet. A rough edge is any aspect of a message that may be repeated in other messages from the same individual. A rough edge might be an unusual misspelling of a word, a choice of online nickname, or the way an individual signs a message. In one case, each message that an individual posted to Usenet contained the following line at the bottom of the text.

Get paid to read email: http://www.sendmoreinfo.com/SubMakeCookie.cfm?

Extract-69381

The Extract-ID is a unique number assigned to each individual who uses the Sendmoreinfo.com service. Searching for other messages containing this Extract-ID led to the identity of the sender.