How to prevent the forge mail?
Alan S H Lam
Previously, I had posted the article: What does the "Apparently-To: " mean
on this news group. Then I received several useful mails from the netters.
Here I would like to express my gratitude to those who had send me e-mails.
I ask this question because I discoved that I can create some forge mail
by running `telnet host 25`. I can set the sender of the forge mail and
then fool somebody. Usually, this forge mail have the header line
"Apparently-To: ", so I wonder if this is the signature of forge mail.
However, as I received your mails, I know that I can change this
header line to the normal one "To: " by adding the "To: receiver" at
the beginning of the letter.
A forge mail may be as real as the real one. I want to know:
1) How can we distinguish forge mails from the real ones?
2) Can we cover this holes and prevent general users (including the
outsiders from running `telnet host 25`?
3) If we cannot cover this holes, can we trace back the
source of the computer outlaws.
If you have any solution for that, please send me e-mail. I will
very appreciate it. Thanks
--
====================================
Alan S. H. Lam
Department of Information Engineering, CUHK, Hong Kong
E-mail: sh...@eng.ie.cuhk.hk Tel: (852) 609 7975 Fax: (852) 603 5032
Frederick M. Avolio
No "Apparently-To:" is not a distinguisher of forged mail. All you have
to do is to put valid header lines after the DATA statement.
You cannot stop forged e-mail any more than you can stop forged postal mail.
While both are rare, you must educate your users to read all e-mail with
a grain of salt. That is to say if the mail seems unbelievable it probably
is. Always verify critical things. From a nuclear lauch order (yes, I'm
exaggerating.... Bush uses UNIX "talk" for that :-) ) to a note from
someone you've been dying to ask out indicating undying infatuation with
you. Check it out. Don't bother trying to find ways to prevent this.
It can't be done.
F
Christopher Davis
FMA> Check it out. Don't bother trying to find ways to prevent [forged
FMA> mail]. It can't be done.
Well, it can, sometimes. Installing an RFC931 server and a patched
sendmail (or other mailer) can often catch a mail (or news, if you patch
nntpd) forger. It's far from perfect, but will stop the ``K00L, MAN, I
CAN FORGE MAIL SO IT LOOKS LIKE IT CAME FROM BI...@BIT.NET!!!'' types.
Also, process accounting can sometimes be useful. Pointing out to
someone that they had a telnet running for the exact same duration as
the sendmail that the forged mail came through has had a salutary effect.
--
Christopher Davis * c...@eff.org * System Administrator, EFF * +1 617 864 0665
``The First Amendment is often inconvenient. But that is besides the
point. Inconvenience does not absolve the government of its obligation
to tolerate speech.'' --Justice Anthony Kennedy, in 91-155
Warner Losh
sh...@eng.ie.cuhk.hk (Alan S H Lam) writes:
>1) How can we distinguish forge mails from the real ones?
You can't. Not if it is good.
>2) Can we cover this holes and prevent general users (including the
> outsiders from running `telnet host 25`?
No. Well, you could hack telnet to not allow it, but people can still
write 'C' code to do it (or get some off the net).
>3) If we cannot cover this holes, can we trace back the
> source of the computer outlaws.
authd will help, but it too can be spoofed. It is usually good enough
for most purposes.
Warner
P.S. It can even be done from inside of emacs. It is easy to hack
rmail to use a "sendmail" program that just connects to port 25 and
does its thing.
--
Warner Losh i...@Solbourne.COM
"I think we'd get fewer weird bug reports if we stopped selling our
software off planet." sm at shorty's
Erik Naggum
All good advice, but for the last comment. You should probably look
into the Privacy-Enhanced Messaging (PEM) project and their RFC's
[1,2,3]. PEM provides for electronic signatures using public-key
encryption, and Message-Digest algorithms exist to provide "tamper
evident" mail [4,5,6].
Best regards,
</Erik>
References:
[1] RFC 1113 Linn, J. Privacy enhancement for Internet electronic mail:
Part I - message encipherment and authentication procedures [Draft].
1989 August; 34 p.
[2] RFC 1114 Kent, S.T.; Linn, J. Privacy enhancement for Internet
electronic mail: Part II - certificate-based key management [Draft].
1989 August; 25 p.
[3] RFC 1115 Linn, J. Privacy enhancement for Internet electronic mail:
Part III - algorithms, modes, and identifiers [Draft]. 1989 August;
8 p.
[4] RFC 1319 Kaliski, B. The MD2 Message-Digest Algorithm. 1992 April;
17 p.
[5] RFC 1320 Rivest, R. The MD4 Message-Digest Algorithm. 1992 April;
20 p.
[6] RFC 1321 Rivset, R. The MD5 Message-Digest Algorithm. 1992 April;
21 p.
--
Erik Naggum | ISO 8879 SGML |
| ISO 10744 HyTime |
+47-295-0313 | ISO 10646 UCS | Memento, terrigena.
<er...@naggum.no> | ISO 9899 C | Memento, vita brevis.
Christopher Davis
AL> == sh...@eng.ie.cuhk.hk (Alan S H Lam) writes:
AL> 2) Can we cover this holes and prevent general users (including the
AL> outsiders from running `telnet host 25`?
WA> Yes, but only if you want to shut off electronic mail entirely.
WA> There are ways of verifying hostnames, but you can not verify the
WA> sender's name.9
AL> 3) If we cannot cover this holes, can we trace back the
AL> source of the computer outlaws.
WA> Depends on how it was done.
Again, you can *sometimes* get a solid traceback by using RFC931-aware
mailers (or front-ends), and/or process accounting. No, it's not going
to stop everyone, but it *does* eliminate the nuisance types.
Joe Wells
>1) How can we distinguish forge mails from the real ones?
Look at the headers carefully and hope that the sender forgot something.
Alternately, set up some sort of public key encription so that you can
be sure that the person who says they sent something actually did.
Keep in mind that a public key authentication system has a serious
problem. A person whose private key was used to sign a letter but who
doesn't want to be held responsible can always claim "someone must have
stolen my private key". Also, private keys really can be stolen.
So e-mail forgery will not ever go away completely. We can only try to
discourage it in many different ways.
--
Joe Wells <j...@cs.bu.edu>
Member of the League for Programming Freedom --- send e-mail for details
Mike Macgirvin
>Actually, there are >simple< ways to do that. Just modify smail3 or
>sendmail to do a reverse DNS lookup on the IP number that is on the other
>end of the connection, and log that and the IP number. That at least tells
>you the machine the connection came from. Often that is enough.
Yeah, right. Do any of your systems have accounts? Like in the
hundreds or thousands or ten thousands? Or have rooms full of
networked workstations which can be used to forge from? Doesn't sound
like it...
mike
Barry Margolin
>Actually, there are >simple< ways to do that. Just modify smail3 or
>sendmail to do a reverse DNS lookup on the IP number that is on the other
>end of the connection, and log that and the IP number. That at least tells
>you the machine the connection came from. Often that is enough.
Most mailers already do this, and include the information in the Received
line in the envelope.
--
Barry Margolin
System Manager, Thinking Machines Corp.
bar...@think.com {uunet,harvard}!think!barmar
Mitch Wright
>wal...@cco.caltech.edu (Walker Aumann) writes:
>>sh...@eng.ie.cuhk.hk (Alan S H Lam) writes:
>>
>>>1) How can we distinguish forge mails from the real ones?
>You can't, unless you can authenticate the >contents< of the message (this
>means some form of encryption).
>>Yes, but only if you want to shut off electronic mail entirely. There
>>are ways of verifying hostnames, but you can not verify the sender's name.9
>Actually, there are >simple< ways to do that. Just modify smail3 or
>sendmail to do a reverse DNS lookup on the IP number that is on the other
>end of the connection, and log that and the IP number. That at least tells
>you the machine the connection came from. Often that is enough.
>
Oh come on, sure you have an IP address, so what. It is easy enough to toss
a PC on a network, configure it's IP to some unused IP on that net and let
loose an untraceable message.
Let's pretend you can't do that even... what about a multi-user system? Maybe
you can get the hostname right, but you had better have some serious system
accounting running if you want to even have a clue of *who* sent it. And
even then you would likely be taking an educated guess at best. Face it,
E-mail can ALWAYS be forged given sufficient resources by a potential forger.
What amazes me is that so many people think E-mail addresses are always
right and that forging mail is either impossible or too difficult for the
average user. Out of curiosity, does anyone know if E-mail can be used
as evidence in court? US-mail can at least be checked for handwriting and
alike...
Regards,
~mitch
Karl Denninger
That's not the point.
If someone telnet's to my gateway's machine on port 25, smail3 will log the
event along with the date, time, IP number, and reverse map (if available).
With that, and the >cooperation< of the admins at the other end, I have a
reasonable chance of catching the perpetrator, especially if they do this
kind of forging activity repeatedly.
This requires cooperation at both ends, yes. It's hardly foolproof. But
it's a damn sight better than NO information on who is telnetting to your
system's SMTP port.... and if the other end has process accounting enabled
at the time the telnet occurs, you've got a reasonable chance of catching
the person who initiated the telnet session.
Now if the perpetrator is smart, perhaps not. However, the patch also
allows me to selectively refuse SMTP inbound connects from known "bad"
hosts.
It's just another brick in the wall; no one claimed it was anything like
foolproof.
I have caught more than a half-dozen mail forgers this way in the last 6
months. You'd be surprised at how stupid most of these people are. I'm
quite aware that this is hardly "authentication" in the real sense of the
word, but its better than nothing!
--
Karl Denninger (ka...@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T
Request file: /u/public/sources/DIRECTORY/README for instructions
Christopher Davis
Mitch> Let's pretend you can't do that even... what about a multi-user
Mitch> system? Maybe you can get the hostname right, but you had
Mitch> better have some serious system accounting running if you want
Mitch> to even have a clue of *who* sent it. And even then you would
Mitch> likely be taking an educated guess at best.
This is where having a TAP/ident/RFC931 type server comes in handy--big
multiuser machines. Or even small multiuser machines. (Both
uxa.cso.uiuc.edu and eff.org, for example, are multiuser, but uxa is
much, much larger.)
Mitch> Face it, E-mail can ALWAYS be forged given sufficient resources
Mitch> by a potential forger.
True. But we can at least make it tougher for Joe Freshman to forge
email from BIFF to his advisor.
Mitch Wright
> Mitch> Let's pretend you can't do that even... what about a multi-user
> Mitch> system? Maybe you can get the hostname right, but you had
> Mitch> better have some serious system accounting running if you want
> Mitch> to even have a clue of *who* sent it. And even then you would
> Mitch> likely be taking an educated guess at best.
>This is where having a TAP/ident/RFC931 type server comes in handy--big
>multiuser machines. Or even small multiuser machines. (Both
>uxa.cso.uiuc.edu and eff.org, for example, are multiuser, but uxa is
>much, much larger.)
>
But things like RFC931 too can be fooled. And worse, people get a false
sense of security by running these things. Granted, they do cutdown on
the number of people that can forge mail, but the motivated forger will
get around this as well. Even worse, the poor sap that is having his
E-mail address forged (and is being logged via sendmail/RFC931/...) will
be stuck with the burden of proving his innocence because of these false
assumptions. I wouldn't want to be the one in front of the school's dean,
a district court, or whatever and try to explain that there are ump-teen
million mis-guided folks out there. I'm sure their reaction would be
"yeah, right -- off with his head". :-) Then again, fortunately we have
an organization like the EFF that helps with such matters.
> Mitch> Face it, E-mail can ALWAYS be forged given sufficient resources
> Mitch> by a potential forger.
>True. But we can at least make it tougher for Joe Freshman to forge
>email from BIFF to his advisor.
>
Agreed. I'm all for limiting the number of forgeries, but lets not people
be lulled into a false sense of security.
Regards,
~mitch
Valdis Kletnieks
>However, if Internet mail goes via more than one hop, and all hosts involved
>are directly connected, I'm immediately suspicious -- this is not normal
>behavior.
Hmm.. I dunno - I've seen mail take 10-12 bounces between "connected"
machines. Life gets interesting out among the .forward files and the
MX sites and the systems that NFS-mount spool areas and do weird things
with "mail hubs" and so on....
I once was discussing something concerning some E-mail extensions in
an IETF working group with Mark Crispin, and discovered that he, for
very good and reasonable reasons, had MX entries for his "preferred"
machine that pointed to other machines on 3 or 4 continents (I know
he had MX's pointing to the US, Japan, and Europe - I can't remember
offhand if Australia was in there too)...
The longer I do this stuff, the less convinced I am that I understand
what the net's "normal" behavior is. ;)
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
Karl Denninger
>
>It is also trivial to forge a message that has gone through several
>machines until it gets to the final destination. When you have 5
>Received-By lines, how do you know which ones are valid and which ones
>are forged?
>--
>Bruce Barnett <bar...@crd.ge.com> uunet!crdgw1!barnett
You don't.
However, if Internet mail goes via more than one hop, and all hosts involved
are directly connected, I'm immediately suspicious -- this is not normal
behavior.
I can easily forge mail so that it is undetectable, and appears to come from
someone else. However, if I do not take care to properly cover my tracks
(i.e. I just telnet to someone's SMTP port) it is not that difficult to
trace back, assuming that the admins on the machine I'm using are watching
me.
If, however, I do take some precautions, then I may give away the fact that
it is a forgery (or at least raise the suspicion), but not who I might
really be.
Bruce Barnett
Warner Losh
>But things like RFC931 too can be fooled. And worse, people get a false
>sense of security by running these things.
By far the easiest way to fool 931 servers is to simply run as that
user. There is nothing in 931 that says "Warner Losh made a
connection to machine fred from farmer." Instead it says "Someone
claiming to have the account name imp made a connection..." The two
phrases are different. It is quite easy to run as user fred if you
can break root, for example. Or via a password snooper on the net, or
just getting someone to distract fred while you send the mail via the
normal channels, or... Well, you get the idea.
It does, however, make it harder to do the telnet xxxx 25 trick.
Warner
--
Warner Losh i...@Solbourne.COM
Interview Horror Story #882: "It's pretty informal around here.
Thursdays are clothing optional.."
David Osborne
>If someone telnet's to my gateway's machine on port 25, smail3 will log the
>event along with the date, time, IP number, and reverse map (if available).
>With that, and the >cooperation< of the admins at the other end, I have a
>reasonable chance of catching the perpetrator, especially if they do this
>kind of forging activity repeatedly.
Do you log the SMTP transactions as well? I manage a couple of
fair-sized mailing lists and quite often use telnet xxx 25 as a tool
to check remote delivery addresses, expand remote redistribution lists
I send to, and so on. That's an example of genuine and harmless use
of the facility. I find it very useful and of great help in managing
lists of this size (one contains > 1000 addresses).
People using telnet to port 25 aren't all forgers or "perpetrators"!
--David Osborne (TeXhax Digest moderator)
--
--David Osborne
Cripps Computing Centre, University of Nottingham
Karl Denninger
>In article <1992Jul11....@ddsw1.mcs.com> ka...@ddsw1.mcs.com (Karl Denninger) writes:
>
>>If someone telnet's to my gateway's machine on port 25, smail3 will log the
>>event along with the date, time, IP number, and reverse map (if available).
>>With that, and the >cooperation< of the admins at the other end, I have a
>>reasonable chance of catching the perpetrator, especially if they do this
>>kind of forging activity repeatedly.
>
>Do you log the SMTP transactions as well?
You bet. If you're being reasonable then there's no problem.
Peter Eriksson
>In article <1992Jul12....@cirrus.com> mi...@cirrus.com (Mitch Wright) writes:
>>But things like RFC931 too can be fooled. And worse, people get a false
>>sense of security by running these things.
How anyone could get a sense of security from using RFC931-type servers I
don't understand. They are more or less only auditing tools. And of course
they are useless when the connection comes from a PC. But since one
(atleast one should) always stores the token returned together with the
address it originated from one can pretty easily see if it comes from a
well known big multiuser machine or a small PC (unless the PC cracker has
changed IP numbers and presuaded some routers to reroute packets that was
originally going to the big machine to the PC or something).
>By far the easiest way to fool 931 servers is to simply run as that
>user. There is nothing in 931 that says "Warner Losh made a
>connection to machine fred from farmer." Instead it says "Someone
>claiming to have the account name imp made a connection..." The two
>phrases are different. It is quite easy to run as user fred if you
>can break root, for example. Or via a password snooper on the net, or
>just getting someone to distract fred while you send the mail via the
>normal channels, or... Well, you get the idea.
>It does, however, make it harder to do the telnet xxxx 25 trick.
And I'm prepared to bet that 99.99% of all mail forgeries are produced
by doing just that. The RFC931-typ server can be used for more that
just making mail forgeries harder to. For example, one can when logging
failed logins with the help of a RFC931 server log not only the
site from where the "might-be" crack attempt came from but also a
"token" identifying the originator of the connection.
(I'm saying "token" since it could be an encrypted token if the site doesn't
want to give out real user id's).
/Peter
--
Peter Eriksson p...@lysator.liu.se
Lysator Academic Computer Society ...!uunet!lysator.liu.se!pen
University of Linkoping, Sweden I'm bored. Flame me.
Wes Morgan
>
>well really? do you use a patched smail? i use smail, but as far as i found
>only logs incoming and outgoing mails are logged. i find this absolutely
>ok, but logging *all* telnet's to the smtp port, or even logging all of the
>transactions themselves (well, actually more the latter) i personally find
>unethical. or even another argument against it: what would you want with
>all that rubbish?
>
Logging the actual transactions, i.e. the actual contents of each message,
would be both unethical and useless, IMHO.
HOWEVER.....
Logging the transaction data (the sender/recipient addresses) can be VERY
useful. For instance, I've used that information (extracted from syslog)
to fine-tune our routing from within sendmail.cf. If a particular "off
the beaten path" mail route sees extensive use, I'll route it directly
to the gateway machine (rather than route it all through our campus-wide
mail router, which is busy enough as it is).
I could also see where logging all *connections* to SMTP could be handy
in an oft-attacked site. I've noticed quite a few people downloading the
membership list of my mailing list.
>all of us should know that a mail send to you *could* be forged easily.
Most users do NOT recognize this fact. I've had several users attain
ballistic trajectory after receiving an obviously forged piece of mail.
I mention the untrustworthiness of email in every lecture I deliver, but
most users seem to forget about it.
>also all of us must know that the mail we send *can* and sometimes even
>*will* be read by others. with this in mind, we can use mail as we wish.
Again, not everyone is aware of this. You should see the widening eyes
when I give the "email is not necessarily private" portion of my lectures.
>as a postmaster, i often telnet to port 25 of machines too, to find out if
>any obscure errors can be reproduced. i wouldn't want to see who uses me
>system to test a mail connection to me or somewhere else. i couldn't see why
>anyone really finds this interesting, but ah well, if somebody gets a kick
>out of logfiles...
Of course, one may also find people attempting to handfeed mail
to /bin/sh......8)
--Wes
--
MORGAN@UKCC | Wes Morgan | ...!ukma!ukecc!morgan
mor...@ms.uky.edu | Engineering Computing | mor...@wuarchive.wustl.edu
mor...@engr.uky.edu | University of Kentucky | JWMo...@dockmaster.ncsc.mil
Mailing list for AT&T StarServer S/E - starserve...@engr.uky.edu
Peter Eriksson
>fe...@escape.vsse.in-berlin.de (Felix the double Helix) writes:
>>
>>[deleted]
>Logging the actual transactions, i.e. the actual contents of each message,
>would be both unethical and useless, IMHO.
>HOWEVER.....
>Logging the transaction data (the sender/recipient addresses) can be VERY
>useful. For instance, I've used that information (extracted from syslog)
To log even more information about who really sent a mail one can use
the RFC931/IDENT/TAP protocol. With this and if the machine the user
is connecting from is running an Ident server it is possible to retreive
the username of who Telnet:ed to your SMTP port and tried to send a
faked email. (Yes yes, it is possible to circumstance this, for example
by using a PC, or by being root on a machine, but most lusers faking
email is probably hiding behind the shelter of a multiuser machine with
many users...)
To add this capability to Sendmail, FTP to ftp.lysator.liu.se, cd to the
directory pub/ident/patches and get the file sendmail-5.65c-IDA1.4.4.1.patch
and apply that to the Sendmail-5.65c-IDA1.4.4.1 sources (the same patch
will probably also work on other versions of the same Sendmail, but one
might have to apply it by hand).
Then it's just a matter of changing the "Received: " format line to
something like:
HReceived: $?sfrom $s $.by $j $?r with $r$.
($v/$Z/Lysator-3.1) id $i; $b $?F
(rfc931-sender: $F@$S)$.
And all mails received by the Sendmail daemon will contain a line
something like: (rfc931-sender: p...@robin.lysator.liu.se) if
I telnet into it and robin is running a Pidentd server.
And the log lines in the syslog file will look something like:
Jul 29 06:39:51 lysator sendmail[8796]: AA08796: from=<f...@bar.xy>, size=491, class=0, received from p...@robin.lysator.liu.se (130.236.254.21)
Where the "from=<f...@bar.xy>" is the user supplied sender, which
can be anything and "received from p...@robin.lysator.liu.se (130.236.254.21)"
is the real sender.
Sorry, if all this is old info.