home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / security / misc / 1756 next >
Encoding:
Text File  |  1992-11-15  |  2.8 KB  |  59 lines
  1. Newsgroups: comp.security.misc
  2. Path: sparky!uunet!pmafire!mica.inel.gov!ux1!news.byu.edu!news.mtholyoke.edu!jbotz
  3. From: jbotz@mtholyoke.edu (Jurgen Botz)
  4. Subject: Mail forging
  5. Message-ID: <BxrJCL.9sC@mtholyoke.edu>
  6. Sender: news@mtholyoke.edu (USENET News System)
  7. Organization: Mount Holyoke College
  8. References: <1992Nov10.201503.6288@gw.wmich.edu> <BxJ80A.KAr@mtholyoke.edu> <4225@bcstec.ca.boeing.com>
  9. Date: Sun, 15 Nov 1992 15:07:32 GMT
  10. Lines: 47
  11.  
  12. In article <4225@bcstec.ca.boeing.com> vanzwol@bcstec.ca.boeing.com (Ted Van Zwol) writes:
  13. >OK, so if you won't say how to do it (possibly reasonable enough...)
  14. >Can you say how to prevent it?
  15.  
  16. With the current set of Internet standard protocols, there is no way of
  17. preventing forged mail.  The technology to do that exists with public-key
  18. crytography and electronic signatures, but since there are not yet any
  19. widely implemented standards for using this technology on the net, it is
  20. not practical for an individual to do so.
  21.  
  22. >Can you say how to detect it?
  23.  
  24. Detection is trick... if the message was a forgery of a "local" message on
  25. a Unix system, you can probably detect it from the sendmail logs; if they
  26. message were authentic it would not have passed through SMTP.  If the
  27. forgery was one where a user spoofed a user on a remote system, you might
  28. need cooperation of the sysops of other systems along the route for 
  29. reliable detection, making it practically very difficult if the forger
  30. was clever.
  31.  
  32. Note that the former covers the case Mr. caps-and-exclamation-marks was
  33. asking about; it is quite easy to detect the case where a user of a multi-
  34. user Unix system tries to spoof a message from "root" (however, detection
  35. will be from the logs, not the message itself.)
  36.  
  37. >Is it truly that trivial and foolproof?  Or does it just make the
  38. >header *look* like it came from someone else (read root) to the
  39. >non-attentive eye?
  40.  
  41. If done correctly, the header of a forged message will be *exactly* identical
  42. to the header of the message had it been authentic.  If there's any way of
  43. identifying the forgery in such a case it's via logs of network activity,
  44. not the message itself.  And yes, if you have a resonably good understanding
  45. of what a correct message header /should/ look like, it's quite trivial to
  46. execute such a forgery.
  47.  
  48. Note however that in many cases of actual forgeries the headers might
  49. provide a clue to the fact that the message is a forgery because a lot
  50. of the forgers do /not/ really understand what a correct message header
  51. looks like, or conversely, they produce a "correct" looking header but
  52. the real system would have produced different or less correct one.
  53. --
  54. Jurgen Botz                  |   Internet: JBotz@mtholyoke.edu
  55. Academic Systems Consultant  |     Bitnet: JBotz@mhc.bitnet
  56. Mount Holyoke College        |      Voice: (US) 413-538-2375 (daytime)
  57. South Hadley, MA, USA        | Snail Mail: J. Botz, 01075-0629
  58.  
  59.