🚀 go-pugleaf

sherer@lub001.lamar.edu writes:
>My question is, is there a way to masquerade as someone else in e-mail?

It's easy.  If your machine is going to believe my machine when it says that
it's forwarding mail from x@y, then anyone who controls my machine can forge
mail to you from x@y.  This is an intrinsic problem which can only be solved by
cryptographic techniques.

However, it's worse than it might be because your system may very well make it
easy for users to forge mail to each other on the same machine.  I know mine
does; I can telnet to the smtp port and tell it I'm whoever I want.

sherer@lub001.lamar.edu writes:
>My question is, is there a way to masquerade as someone else in
>e-mail?

Its trivial; see the RFC for SMTP; all you have to do is pretend to be
another SMTP daemon; there is no authentication mechanism. Its all
ASCII; you can even do it yourself without writing any software by
connecting to the mailer daemon's port ant typing away.

>If so, is there anything I can do to prevent this from happening?

Not really, no. Eventually, everyone will be using public key
cryptography to sign their mail, but for the moment, there is no way
to really authenticate SMTP.

--
Perry Metzger		pmetzger@shearson.com
--
		  Just say "NO!" to death and taxes.
			 Extropian and Proud.

In article <1992Aug12.151404.1424@lub001.lamar.edu> , sherer@lub001.lamar.edu
writes:
>My question is, is there a way to masquerade as someone else in e-mail?

Any user can connect to the SMTP daemon, and feed it any data he or she sees
fit.  No root permissions are necessary:  it's simply a matter of knowing how. 
Someone at your site with more knowledge than respect has obviously discovered
the 'how'.  

I have observed that some mailer daemons are able to detect certain fraudulent
transcations, and while accepting the "From:" information in the incoming
message, will also include an "Apparently-From:" line in the message header. 
Most mailers that I have played with believe the "From:" information fed to
them without a murmur of doubt.  

Alt.security had a discussion a couple of months ago regarding this very
problem, and a new protocol that could be implemented to assist in closing this
hole.  You might try  posting there, and asking someone to forward the results
of that discussion to you.  
--
Jim Barrett                Lockheed Engineering & Sciences Co., Houston, TX
Barrett_Jim@ial3.jsc.nasa.gov                                  713-333-6103

In article <1992Aug13.164814.11389@aio.jsc.nasa.gov>
Barrett_Jim@ial3.jsc.nasa.gov (Jim Barrett) writes:

> I have observed that some mailer daemons are able to detect certain fraudulent
> transcations, and while accepting the "From:" information in the incoming
> message, will also include an "Apparently-From:" line in the message header. 
> Most mailers that I have played with believe the "From:" information fed to
> them without a murmur of doubt.  

If I remember correctly, an "Apparently-From:" or "Apparently-To:"
header is only inserted when there is no "From:" respectively "To:"
header in the "DATA" part of the mail.

SunOS' sendmail (4.1) only inserts an "Apparently-To:" header in this
case.

--
Juergen Nickelsen

nickel@cs.tu-berlin.de (Juergen Nickelsen) writes:

>In article <1992Aug13.164814.11389@aio.jsc.nasa.gov>
>Barrett_Jim@ial3.jsc.nasa.gov (Jim Barrett) writes:

>> I have observed that some mailer daemons are able to detect certain fraudulent
>> transcations, and while accepting the "From:" information in the incoming
>> message, will also include an "Apparently-From:" line in the message header. 
>> Most mailers that I have played with believe the "From:" information fed to
>> them without a murmur of doubt.  

If one applies the Sendmail patch in pub/ident/patches at ftp.lysator.liu.se
or pub/networking/ident/patches at ftp.uu.net, then all mail that are received
via the SMTP TCP/IP port will, if the sending host is running an IDENT server,
have a line "(rfc931-sender: realuserid@realhostid)" added to the "Received: "
line in the message header. (Where "realuserid" is the user name of the luser
at "realhostid" who initiated the connection to the SMTP port).

Servers that implement the IDENT (the successor to RFC931) protocol can also
be FTP'd from ftp.lysator.liu.se (in pub/ident/servers) or from ftp.uu.net
(in pub/networking/ident/servers). There are servers for various Unixes and
even a server for DEC TOPS-20. The latest version of the stuff is always
at ftp.lysator.liu.se.

/Peter
--
Peter Eriksson                                              pen@lysator.liu.se
Lysator Academic Computer Society                 ...!uunet!lysator.liu.se!pen
University of Linkoping, Sweden                           I'm bored. Flame me.

In article <1992Aug12.151404.1424@lub001.lamar.edu> sherer@lub001.lamar.edu writes:

<apparently fake mail headers>

This happened by accident on a GEC SysV unix I used some years ago - you
would send mail, log out immediately, and someone else would log in pretty
sharply behind you on the same line.  The mail you sent out appeared to
come from the person who had just logged in.  Looked like the mail program
got your terminal id first, then looked up who was logged on that terminal
to guarantee it found the 'real' user.  Strange but true.

Graham
-- 

Barrett_Jim@ial3.jsc.nasa.gov (Jim Barrett) writes:

>I have observed that some mailer daemons are able to detect certain fraudulent
>transcations, and while accepting the "From:" information in the incoming
>message, will also include an "Apparently-From:" line in the message header. 
>Most mailers that I have played with believe the "From:" information fed to
>them without a murmur of doubt.  

The Apparently To: field is generated if you fail to put a Mail header in
the mail body and it has to be salvaged from the envelope information.
Similarly the Apparently From: field is probably placed in the mail if the
envelope information must be used to generate it and can probably be
circumvented by including the information in the Body of the message as
well as the SMTP envelope information.

Craig
--
Craig Richmond.  Computer Officer -  Dept of Economics (morning) 380 3860
  University of Western Australia    Dept of Education (afternoon)
craig@ecel.uwa.edu.au                              Dvorak Keyboards RULE!
     "Only users are allowed to make messes on their computers"  I.M.VI

In <1513@lysator.liu.se> pen@lysator.liu.se (Peter Eriksson) writes:
>[sendmail patch at ftp.lysator.liu.se to add
> "(rfc931-sender: realuserid@realhostid)" lines to the mail header]

 I would like to be able to track things like this:

From daemon Fri Aug 14 14:09:25 1992
Return-Path: <Mailer-Daemon>
Received: by phys.ksu.edu (4.1/SMI-4.1)
        id AB18747; Fri, 14 Aug 92 14:09:16 CDT
Date: Fri, 14 Aug 92 14:09:16 CDT
From: Mailer-Daemon (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Message-Id: <9208141909.AB18747@phys.ksu.edu>
To: Postmaster

   ----- Transcript of session follows -----
<<< vrfy rjj
550 rjj... User unknown
<<< quit

  ----- No message was collected -----

 I know some of these are innocent checks, I do it all of the time myself,
but about a month ago I had about a dozen of these in one day, and several
the next day. How can I tell where they came from? Do any of the public
sendmails provide better information? Anyway to log the VRFY's that succeed
too?

--
|                                                                Rob Quinn |
|                                                         rjq@phys.ksu.edu |
|                                                    QuinnBob@KSUVM.BITNET |

rjq@phys.ksu.edu (Rob Quinn) writes:

>   ----- Transcript of session follows -----
><<< vrfy rjj
>550 rjj... User unknown
><<< quit

> I know some of these are innocent checks, I do it all of the time myself,
>but about a month ago I had about a dozen of these in one day, and several
>the next day. How can I tell where they came from? Do any of the public
>sendmails provide better information? Anyway to log the VRFY's that succeed
>too?

I believe that the 'netfind' program does this as well as fingers to
find e-mail addresses.  For more info, you can ftp to
bruno.cs.colorado.edu, or telnet there and login as 'netfind'.

I also believe that the tcp_wrapper package will do logging on smtp
daemon connections to log where they came from (and from whom, if
the remote site is running an authd - RFC931 daemon).  I know it
does this for telnetd and rlogind and so on, I think it said it had
support for sendmail, too.  You can ftp it from
cert.sei.cmu.edu in the /pub/tools directory.
-- 
David Lemson                                                 (217) 244-1205
University of Illinois NeXT Campus Consultant  / CCSO NeXT Lab System Admin
Internet : lemson@uiuc.edu                 UUCP :...!uiucuxc!uiucux1!lemson 
NeXTMail accepted                                   BITNET : LEMSON@UIUCVMD

From article <1992Aug12.151404.1424@lub001.lamar.edu>, by sherer@lub001.lamar.edu:
> This is the first time I've posted to News, so please be kind.
> 
> I have been informed of a suspected problem in Internet mail by one of my
> operators. He received some mail from some valid users at our site, and he
> responded to those messages. The people that supposedly sent the messages
> claimed they never sent them. Then he (the operator) received e-mail from
> himself on a VMS node to his account on our ULTRIX node. He did not send the
> mail himself, and he checked the last login time on the account on the VMS
>+ node
> and found that no one had logged in on that account in quite a while, so he
>+ did
> not believe anyone figured out his password.

 Most of the replies have been w.r.t. SMTP mail tricking. Since this is 
 between two DEC machines, the mail could also have been sent by DECnet
 mail (Mail 11) which is also easily tricked by any user with extra time
 to waste. If you have copies of the mail headers, you can track down
 which scheme was used, but not much else.

Ian.
----------------------------------------------------------------------------
Ian MacPhedran, Engineering Computer Centre, University of Saskatchewan.
2B13 Engineering Building, U. of S. Campus, Saskatoon, Sask., CANADA S7N 0W0
macphed@dvinci.USask.CA  macphedran@sask.USask.CA
-- 
----------------------------------------------------------------------------
Ian MacPhedran, Engineering Computer Centre, University of Saskatchewan.
2B13 Engineering Building, U. of S. Campus, Saskatoon, Sask., CANADA S7N 0W0
macphed@dvinci.USask.CA  macphedran@sask.USask.CA