al@gtx.com (0732) (12/04/87)
I just read a newspaper article by Clarence Peterson of the Chicago Tribune
in which "Jan Harold Brunvard, University of Utah Professor of folklore
and author of three books about urban legends" dismisses the "Trojan Horse"
computer program as an "Urban Myth". He says "I think there probably have been
some programs like that cooked up, but I can find no evidence that it's
actually been done, and it isn't as though it couldn't be detected and
destroyed."
It seems to me that the Professor is being quite naive. We all know
how easy it would be to create a Trojan Horse Program, and even, with a
little more difficulty, make it infect the user's system in subtle
ways. As for the question, "has anyone actually been hurt by one of
these?", I only know third-hand accounts. Can anyone relate a
first-hand account of damage done to his/her system by a malicious
Trojan Horse?
----------------------------------------------------------------------
| Alan Filipski, GTX Corp, 2501 W. Dunlap, Phoenix, Arizona 85021, USA |
| {ihnp4,cbosgd,decvax,hplabs,seismo}!sun!sunburn!gtx!al (602)870-1696 |
----------------------------------------------------------------------dave@spool.wisc.edu (12/06/87)
> Can anyone relate a > first-hand account of damage done to his/her system by a malicious > Trojan Horse? Well, that depends on what you consider "damage". A trojan horse which I dealt with many moons ago (not on a UNIX system) allowed the user, eventually, to get a complete list of logins and plaintext passwords for all logins on the system. Lesson: never keep plaintext passwords on line, they *will* be found out. This intrusion was not discovered for months. Another user of that same system used a trojan horse to replace the system message file (kinda equivalent to what perror() prints on a UNIX system) with the source for a BASIC program. That was pretty "interesting". The damage was temporary; when the machine rebooted, it was all better. More recently (only 3-4 years ago on a UNIX machine), some hackers caught root with '.' in its path, and got root (I have to admit, I was the root that got got) to run a bogus version of "write". Luckily, I was almost as fast as they were, and closed the hole quickly, within minutes (luckily also, they were too slow to do any serious damage in that time). Lesson: *never* *ever* put '.' in root's path. I still get into arguments about this. Is that first-hand enough? In my experience, a Trojan Horse is the simplest and most common form of system cracking. Anyone who thinks otherwise is setting themselves up for a fall. If I remember correctly, a year or two ago, Gould had a "break our secure system" contest. Someone broke in using a Trojan Horse. I'm sure someone at Gould can give details, if they want. Dave Cohrs +1 608 262-6617 UW-Madison Computer Sciences Department dave@cs.wisc.edu ...!{harvard,ihnp4,rutgers,ucbvax}!uwvax!dave
g-rh@cca.CCA.COM (Richard Harter) (12/06/87)
In article <459@gtx.com> al@gtx.UUCP (Al Filipski) writes: > >It seems to me that the Professor is being quite naive. We all know >how easy it would be to create a Trojan Horse Program, and even, with a >little more difficulty, make it infect the user's system in subtle >ways. As for the question, "has anyone actually been hurt by one of >these?", I only know third-hand accounts. Can anyone relate a >first-hand account of damage done to his/her system by a malicious >Trojan Horse? > Other than inconvenience and loss of disk space, I don't know of deliberate harm. I have seen a virus program on VM/CMS infect an entire system -- the systems people spent an entire weekend rooting it out. Does that count? Should one count the time spent playing 'wheel wars' which often involves subtle use of trojan horses. It might be interesting if some of our now reformed readers regaled us with some of the more amusing tricks they played on their compatriots. [I remember slipping someone a trojan horse that printed out "Your account is exactly as you left it -- now" when he logged in. And, of course, when he checked it, it was.] -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
rcj@clyde.UUCP (12/06/87)
In article <4810@spool.wisc.edu> dave@spool.wisc.edu (Dave Cohrs) writes: }> Can anyone relate a }> first-hand account of damage done to his/her system by a malicious }> Trojan Horse? Sure. If I wanted to get into someone's files to pull a prank, I would write a program to give me a shell, put it in an unprotected directory, and change ownership to the person whose files I wanted to get into. Then I would send them mail that had embedded in it commands to enter the necessary command to make my program setuid into the memory of their HP terminal and then send the entered sequence to Unix. Most of the time it wasn't even noticed if it was buried properly. Now all I had to do was run the setuid program and I was them. I was never malicious, but it was fun to do things like cpio all a person's files to a safe place and then put a clear screen command followed by an "rm -rf *" in their .profile and watch the fireworks... The MAD Programmer -- 201-386-6409 (Cornet 232) ^^^^ new extension alias: Curtis Jackson ...![ ihnp4 ulysses cbosgd allegra ]!moss!rcj ...![ ihnp4 cbosgd akgua watmath ]!clyde!rcj
ruiu@tic.UUCP (Dragos Ruiu) (12/06/87)
In article <459@gtx.com>, al@gtx.com (0732) writes: > It seems to me that the Professor is being quite naive. We all know > how easy it would be to create a Trojan Horse Program, and even, with a > little more difficulty, make it infect the user's system in subtle > ways. As for the question, "has anyone actually been hurt by one of > these?", I only know third-hand accounts. Can anyone relate a > first-hand account of damage done to his/her system by a malicious > Trojan Horse? > > | Alan Filipski, GTX Corp, 2501 W. Dunlap, Phoenix, Arizona 85021, USA | > | {ihnp4,cbosgd,decvax,hplabs,seismo}!sun!sunburn!gtx!al (602)870-1696 | Trojans shop up with alarming regularity about twice a year on public domain software distributed by BBS's. The only time I have ever been caught is when a friend gave me a reputedly 'new' version of ARC he had just downloaded. This was two and a half years ago. My friend lost his entire hard disk, luckily I tested it on floppy. (My friend just about had his backup disks framed :-) The ocurrence of disk-erasing trojans, viruses etc. has even spawned a de-fuser program called CHK4BOMB that lets you examine new programs and warns of questionable practices within them. It is standard fare on all IBM-PC BBS's but unfortunately I think it is nowhere near infallible and the user needs a lot of knowledge of system calls on a PC. I still use my copy on something too good to be true (When I use MS-Clunk :-). Now if we could only figure out what drives people to do things like this. I can see what would cause trojans on a timesharing system in a CS environment, but what would drive someone to spring nasty effects on some complete stranger? -- Dragos Ruiu Disclaimer: My opinons are my employer's, I'm unemployed! UUCP:{ubc-vision,mnetor,vax135,ihnp4}!alberta!edson!tic!dragos!work (403) 432-0090 #1705, 8515 112th Street, Edmonton, Alta. Canada T6G 1K7 Never play leapfrog with Unicorns...
jesup@pawl23.pawl.rpi.edu (Randell E. Jesup) (12/07/87)
In article <22190@cca.CCA.COM> g-rh@CCA.CCA.COM.UUCP (Richard Harter) writes: >Other than inconvenience and loss of disk space, I don't know of deliberate >harm. I have seen a virus program on VM/CMS infect an entire system -- the >systems people spent an entire weekend rooting it out. Does that count? There are viruses/Trojan horses in the micro world that do VERY nasty things, like reformat ones hard drives, or destroy games with custom boot code (by writing themselves over it). And on the local mainframe, one student once got peoples passwords and used their (funny, but hard to replace) money. // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// userb9zv@mts.rpi.edu MIGHT work (518) 272-2942 \/
rosalia@mozart.UUCP (Mark Galassi) (12/07/87)
In article <459@gtx.com> al@gtx.UUCP (Al Filipski) writes: > ... Can anyone relate a >first-hand account of damage done to his/her system by a malicious >Trojan Horse? On April 1st about 1 and 1/2 years ago, someone posted a "program" to net.sources in shar format. I think it was supposed to do something like "relink files" (absurd!). Once you unshared (or ran make, I don't remember), it would replace your .login with another one which said somehting funny, and save your old .login on a side. (.profile for non-csh). This person was harmless, but many people fell for it. Imagine if s/he had made it do rm -rf / &, or something weird as root. I'm sure that there are many fools that unshar things when logged in as root. -- Mark Galassi ...!mozart!rosalia { These opinions are mine and should be everybody else's :-) }
ewiles@netxcom.UUCP (Edwin Wiles) (12/07/87)
In article <459@gtx.com> al@gtx.UUCP (Al Filipski) writes: > >It seems to me that the Professor is being quite naive. We all know >how easy it would be to create a Trojan Horse Program, and even, with a >little more difficulty, make it infect the user's system in subtle >ways. As for the question, "has anyone actually been hurt by one of >these?", I only know third-hand accounts. Can anyone relate a >first-hand account of damage done to his/her system by a malicious >Trojan Horse? > See the last few issues of RISKS digest on this network. There is actually a message from a student who wrote a virus (admitedly designed NOT to do damage, but ended up doing it anyway). Additionally, there have been reports in the new 'misc.security' newsgroup of a virus that was DEFINITELY harmful, and caused serious damage. These reports were apparently made by a university prof. who got burned by it. They may not directly qualify as 'trojan horses', in that neither of them was designed to allow illicit access to the infected systems, but they easily could have been designed to do so. And their spread rate is incredible. -- ...!hadron\ "Who?... Me?... WHAT opinions?!?" | Edwin Wiles ...!sundc\ Schedule: (n.) An ever changing | NetExpress Comm., Inc. ...!pyrdc\ nightmare. | 1953 Gallows Rd. Suite 300 ...!uunet!netxcom!ewiles | Vienna, VA 22180
shane@pepe.cc.umich.edu (Shane Looker) (12/07/87)
In article <459@gtx.com> al@gtx.UUCP (Al Filipski) writes:
:I just read a newspaper article by Clarence Peterson of the Chicago Tribune
:in which "Jan Harold Brunvard, University of Utah Professor of folklore
:and author of three books about urban legends" dismisses the "Trojan Horse"
:computer program as an "Urban Myth". He says "I think there probably have been
:some programs like that cooked up, but I can find no evidence that it's
:actually been done, and it isn't as though it couldn't be detected and
:destroyed."
:
Obviously, this guy does not live with computers.
:
:It seems to me that the Professor is being quite naive. We all know
:how easy it would be to create a Trojan Horse Program, and even, with a
:little more difficulty, make it infect the user's system in subtle
:ways. As for the question, "has anyone actually been hurt by one of
:these?", I only know third-hand accounts. Can anyone relate a
:first-hand account of damage done to his/her system by a malicious
:Trojan Horse?
There was a posting to Risks last week about a virus which has be put into
COMMAND.COM files. This should qualify as a Trojan Horse. There is a
file sitting on some BBSs around the country called PACKIT2 (for the
Macintosh), which is supposed to be a Trojan horse.
I have a friend who wrote a Trojan horse login screen on a TOPS-20 system
(or was it a TOPS-10?) several years ago. A friend of his managed to collect
a large number of logins and passwords before they caught him.
:
: ----------------------------------------------------------------------
: | Alan Filipski, GTX Corp, 2501 W. Dunlap, Phoenix, Arizona 85021, USA |
: | {ihnp4,cbosgd,decvax,hplabs,seismo}!sun!sunburn!gtx!al (602)870-1696 |
: ----------------------------------------------------------------------
Shane Looker | "He's dead Jim,
shane@pepe.cc.umich.edu | you grab his tricorder,
uunet!umix!pepe.cc.umich.edu!shane | I'll get his wallet."
Looker@um.cc.umich.edukurt@tc.fluke.COM (Kurt Guntheroth) (12/07/87)
Comp.sys.amiga has recently contained an exposition of a trojan horse program, which they called a virus, that infects amiga boot disks. This one is harmless, but virulent varieties could easily be created. It is true that most specific trojan horse programs, once known, can be defeated. Their power, like the power of the original trojan horse, lies in their unexpected nature; that they are other than they seem. No myth. Fact. Reality.
rjd@occrsh.ATT.COM (12/08/87)
> Sure. If I wanted to get into someone's files to pull a prank, I would > write a program to give me a shell, put it in an unprotected directory, > and change ownership to the person whose files I wanted to get into. > > Then I would send them mail that had embedded in it commands to enter > the necessary command to make my program setuid into the memory of their > HP terminal and then send the entered sequence to Unix. Most of the time > it wasn't even noticed if it was buried properly. Now all I had to do > was run the setuid program and I was them. Yeah, when I was first getting into the security aspects of Unix, I was friends with an inexperienced administrator of a system that left his terminal with programmable and pollable function keys writable. Just check to see if a "who -u" shows him idle for a few minutes, send the escape sequences to program the keys, then poll them, and voila!! Once he caught on to that (as I said, he was a friend, and I was telling him most of what I did), I switched over to the mailing of the escape sequences. After that, I told him all the techniques that I had used and the defense (and also told him where ALL of the be-root programs were). I still got blamed for stuff that was not my fault, but them's the breaks. Moral: Either don't do it or be VERY careful because anything that goes wrong will be blamed on you. Also: Always forward root's mail to a user and then still read it through a filter such as "cat -v", and never have root's terminal writable. These escape sequence methods work between machines via uucp also. Randy
aglew@ccvaxa.UUCP (12/09/87)
Break-ins to Gould's Secure UNIX:
I'm not on Secure UNIX, but I believe that this is the real story -
at a trade show, the Gould exhibit made the break-in challenge.
Normally, of course, Secure UNIX administrators do not have . in their
path, but in this case root had just finished installing a 3rd party
software package that came complete with instructions to "Put . in your
path in order to run the installation script". Sigh. The penetrator
went up to the exhibitor, and asked him to help him out... try ls'ing
this directory... Sigh.
Now, the rules of the challenge expressly forbid Trojan Horses (since
there's not too much the OS can do about stupid system administrators),
but the penetrator got shirty, and the Gould exhibitor was probably nervous,
so they made a ruckus about it. Eventually it got back here (we heard about
it on the USEnet) and the penetrator got his prize.
---
Enough of the company product. A 100% personal, definitely not company
policy, widely disapproved of by my co-workers, opinion: the problem is
not "." in the path.
"." in the path is a great convenience. It lets you move around to
particular environments, and use commands special to that environment.
In fact, I have occasionally had a path that runs . ./bin ../bin ../../bin
../../../bin and so on - and it was *greatly* convenient. I would like
to have a shell that had a syntax {../}*bin, or similar - search up the
path until you get to the top.
The trouble is not the relative pathnames - the trouble is that they
relative pathnames are not *SECURE*. I mean, if /usr/bin is writable to the
world, then not having . in his path doesn't help root at all. Nor
(a more likely occurrence) does it help if root is installing a software
package, picks up some filespace in /tmp, and starts running a long
lasting installation procedure that uses scripts pulled from where he's
installing.
What is needed is a security predicate that prevents root from executing
non-secure code *wherever* it might be found. This might involve, on every
invocation, checking that the path to the / is non-writable, and so on.
If you have such predicates, then relative pathnames like . and ./bin
are as secure as any other.
Andy "Krazy" Glew. Gould CSD-Urbana. 1101 E. University, Urbana, IL 61801
aglew@mycroft.gould.com ihnp4!uiucdcs!ccvaxa!aglew aglew@gswd-vms.arpa
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.jfh@killer.UUCP (The Beach Bum) (12/10/87)
In article <459@gtx.com>, al@gtx.com (0732) writes: > I just read a newspaper article by Clarence Peterson of the Chicago Tribune > in which "Jan Harold Brunvard, University of Utah Professor of folklore > and author of three books about urban legends" dismisses the "Trojan Horse" > computer program as an "Urban Myth". He says "I think there probably have been > some programs like that cooked up, but I can find no evidence that it's > actually been done, and it isn't as though it couldn't be detected and > destroyed." > > > It seems to me that the Professor is being quite naive. We all know > how easy it would be to create a Trojan Horse Program, and even, with a > little more difficulty, make it infect the user's system in subtle > ways. As for the question, "has anyone actually been hurt by one of > these?", I only know third-hand accounts. Can anyone relate a > first-hand account of damage done to his/her system by a malicious > Trojan Horse? > > | Alan Filipski, GTX Corp, 2501 W. Dunlap, Phoenix, Arizona 85021, USA | First to say, Trojan Horses are much easier under Unix than other operating systems I have used, but this experience isn't from Unix, it's a Vax/VMS story. I was actually involved in this experience, although initially as a victim, and later whn I found out what was going on, I let my sophmorish attitudes (I was a sophmore, what more can I say ;-) get me in trouble. I write this because Trojan Horses are _EASY_ to write, and even easier to be fooled by. What I did was wrong. I am not advocating doing this to your local computer system. Please don't, it can wreak havoc. When The University of New Orleans bought it's first Vax-11/780, a guy from California was involved in the initial set-up. He had been a system manager on a Vax someplace else and had learned how to abuse VMS. At first he just had an account with operators privileges, and later he wrote a little program to act like login and steal passwords. (side note: The system had the Unix-like toolbox on it and this was blamed for the original security breach. This toolkit wasn't the problem, the guy that set up the system was. This is the true story, whether Sal Tillis (hi Sal) want's to believe it or not. The other things I did to their Vax are a whole different matter ;-) accept it or not ...) This guy wrote a little .COM file (that's .BAT to the DOS world) which displayed a faked logout message when he logged out. Then started the trojan horse part. It prompted for a login name with $ INQUIRE/NOPUNCTUATION 'Username: ' $username to read in the victims user name. This was followed by $ SET TERMINAL/NOECHO ( or something like that - it's been 6 or 7 years) $ INQUIRE/NOPUNCTUATION 'Password: ' $password The results were written into a file of his. He repeated the username/ password commands 3 times to insure the user typed the password correctly. After each prompt the system gave a real looking error message. When he was done, the set the baud rate on the terminal to something other than what it should be and logged out. This thing looked quite real. The only way to tell the difference was to type a ^Z at it and look at the error message. It trapped ^C and ^Y as it should, but ^Z was being handled by RMS, not the program, and RMS didn't give the same message LOGINOUT (or whatever) gave. He got several dozen user's account names and such and did cause some grief. After my homework was ruined by his little ploy (like I said in the beginning, I got bit) I got pissed off and managed to wreak a bit more havoc before the System Manager (hi Sal) got disgusted with the lot of us and pitched us from the machine. As I said earlier, don't go screwing with peoples computers. It isn't fun getting canned from your Universities system and trying to get a degree at the same time. It can really screw up getting your first few jobs also. And if you are a system manager, my best advice is pay attention to the wierd complaints you get about terminals and such acting strange. Anyone wanting more information can write myself or if you can find Sal Tillis hanging around the DECUS group, you can ask him. Professor What's-His-Face should keep his mouth shut and stick to teaching basket weaving for all the good he is doing. - John. -- John F. Haugh II SNAIL: HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 ...!ihnp4!killer!rpp386!jfh Dallas, TX. 75243 "Don't Have an Oil Well? Then Buy One!" (214) 231-0993
mikep@ism780c.UUCP (Michael A. Petonic) (12/10/87)
In article <405@tardis.cc.umich.edu> shane@pepe.cc.umich.edu (Shane Looker) writes: >I have a friend who wrote a Trojan horse login screen on a TOPS-20 system >(or was it a TOPS-10?) several years ago. A friend of his managed to collect >a large number of logins and passwords before they caught him. It's really simple to do. In fact, if you're using UNIX, it even easier to do than on a TWENEX system. I did the same thing when I was a summer hire for the at an Army post. It was on a VMS3.x system and got me SYSTEM priveledges. Also earned me a dubious reputation. On VMS, I had to kludge it, and say that the user typed in an incorrect password and then exit (silently, of course) and let the REAL login come out. This was the tattle tale of the technique. If you bombed out of the login when you KNOW you typed the password right. Oh yeah, it was all done with a command file, not in C or any other compiled language... Shows you how simple it was. I think the generic term for these devices are called "Password Snatchers". See, it's so easy to think of that there's even a generic name for it... -MikeP -------- Michael A. Petonic (213) 453-8649 x3247 INTERATIVE Systems Corporation "My opinions in no way influences 2401 Colorado Blvd. the price of tea in China." Santa Monica, CA. 90404 {sdcrdcf|attunix|microsoft|sfmin}!ism780c!mikep
barmar@think.COM (Barry Margolin) (12/11/87)
In article <30800002@ccvaxa> aglew@ccvaxa.UUCP writes: > What is needed is a security predicate that prevents root from executing >non-secure code *wherever* it might be found. This might involve, on every >invocation, checking that the path to the / is non-writable, and so on. >If you have such predicates, then relative pathnames like . and ./bin >are as secure as any other. There is research in this area. A (too-)simple solution would be to specify that root can only run things that are owned by root. This has the problem that root won't be able to run anything that is setuid to someone else; for example, I think uucp is setuid uucp. The general solution to this problem involves tagging executable files with an integrity level, and tagging processes with a trust level. A file is given an integrity level corresponding to the trust level of the process that last wrote it, and a process won't run a file whose integrity level is lower than his trust level. Root would normally run with a high trust level, and wouldn't be able to execute files written by ordinary users. --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar
clewis@spectrix.UUCP (Chris Lewis) (12/11/87)
In article <2393@killer.UUCP> jfh@killer.UUCP (The Beach Bum) writes: >In article <459@gtx.com>, al@gtx.com (0732) writes: >> I just read a newspaper article ... >> in which "Jan Harold Brunvard, University of Utah Professor of folklore >> and author of three books about urban legends" dismisses the "Trojan Horse" >> computer program as an "Urban Myth". He says "I think there probably have been >> some programs like that cooked up, but I can find no evidence that it's >> actually been done, and it isn't as though it couldn't be detected and >> destroyed." >> It seems to me that the Professor is being quite naive. We all know You're not kidding. >First to say, Trojan Horses are much easier under Unix than other operating >systems I have used, but this experience isn't from Unix, it's a Vax/VMS >story.... A minor quibble - have you ever used PC/MSDOS? It's very simple to break security on these machines because there ain't none. Many BBS's catering to this market have accidentally acquired Trojans and redistributed them to unsuspecting users. The problem has become so severe that the BBS sysops have to examine as much of the stuff as they can. There are programs written which will attempt to determine whether a program is a Trojan (by tracing system calls etc.) but they aren't fool-proof. I've seen many messages on PC BBS's saying "WARNING: if you've downloaded "X", purge it FAST!". At least in this world the person who gets stung *usually* explicitly knows he's importing code into his machine, and can usually point fingers in the right way after getting blown. MSDOS is particularly susceptable to Trojans because: there's no security, most programs that are traded are binaries rather than sources, and it's real easy to diddle hardware directly. Fortunately fewer people are affected. At least in UNIX the person triggering the Trojan (root) is likely to be able to know enough to recover. Another minor quibble: according to the definition of "Trojan horse" (a program "trusted" by a user which does something additional), I wouldn't call "password snatching" or hoping that root has "." in his path a "Trojan". They're "traps". In the MSDOS world, Trojans quite frequently take the form of a new program the user acquires from somewhere that purports to do something he wants. Then he finds that not only does it do that, but it does other things (eg: reformat hard disk). A couple of issues back in comp.risks (oops, we expire it faster'n I thought!) there is a personal account of a particularly hideous MSDOS trojan. Appears that somehow somebody munged a copy of DOS to: copy the modifications without the user knowing it to every DOS bootable floppy that the DOS comes in contact with, and after the fourth generation (not quite sure the precise semantics here), zap the hard disk so badly that no utility can recover). Started out as a Trojan and turned into a virus. And, it's apparently spreading... Could some UNIX fanatic be trying to kill off all MSDOS machines? (It's about time! ;-). Don't quote me on this, quote the article directly if you can find it. BTW: I've noticed a lot of comments from people encountering/making password snatchers making me think that it's a lot more prevalent than I thought. Then again, it's almost impossible for ANY interactive computer system that uses traditional "userid" and "password" protection to prevent. Trivial on almost any OS I've ever used (MVS/TSO, VM/CMS, VMS, UNIX, etc.) -- Chris Lewis, Spectrix Microsystems Inc, UUCP: {uunet!mnetor, utcsri!utzoo, lsuc}!spectrix!clewis [Also: lsuc!clewis in a pinch] Phone: (416)-474-1955
mjr@osiris.UUCP (Marcus J. Ranum) (12/11/87)
A trick I'd always thought would be nice would be to have a shell that could have an option set to show WHAT was being executed. If one was root, and typed "ls" with that option set, and it came back with "./ls" you would know you had a problem... Obviously, catching it BEFORE is the way to go, but catching it at all is a big deal for some. Another choice would be to have it say "exec ./ls (Y/N)?" :-) :-) :-) I haven't looked at sh source (all those gross preprocessor commands) for a while, but doesn't it just try to exec() the program in each part of the PATH ? That would need to be changed. I'm not suggesting adding more junk to the "real" shell, but I have often thought that a shell with "enhancements" for system admins might be useful. --mjr(); -- Once, there was NO fun... This was before MENU planning, FASHION statements or NAUTILUS equipment... Then, in 1985.. FUN was completely encoded in this tiny MICROCHIP... It contains 14,768 vaguely amusing SIT-COM pilots!!
marcos@caus-dp.UUCP (Marcos R. Della) (12/12/87)
Back around 1978 I think (I can't remember that far back too well) there was this kid in the Concord/Walnut Creek area of the Bay area who bought himself a 300 baud modem and a small terminal. He managed to get an account on one of the local machines and proceeded to learn as much about unix as he could. The following is what happened to him with this knowledge... He managed to start creating login shells that saved passwords and the like and then called the real shell with the information that he had learned. That way he could get the facts of if the person typed in the correct password and also the person would be logged on normally. He also wrote a package that duplicated this effort over the ARPA lines to other machines (Before arpa started putting better restrictions on these kinds of things) and his little bug started floating around the country, reporting passwords and the like back to him. He was finally caught because some unix hacker at stanford started noticing that it took 15-30 seconds longer than normal to log on the machine and was wondering what the system admins had done to the operating system to slow it down so much. In his words, he was going to fix it up for them and put some more speed in and turn it in as a project. Well, he found this bug and the people at stanford started a little search and started tracking down all these bugs and started tracing them around the country. Eventually they caught the kid. The FBI came in and confiscated his equipment and hauled him off.. The kid was 13 or 15 I think. Anyway, later that year after he went through all the wrist slapping and such, someone offered him a high paying job trying to break into machines and create fixes to prevent it. Something on the order of use a crook to catch a crook. -- ...!csustan ->!polyslo!caus-dp!marcos | Whatever I said doesn't ...!sdsu ---/ Marcos R. Della | mean diddly as I forgot ...!csun --/ Smail:PO Box 8104 SLO,CA 93403-8104 | it even before finishing ...!dmsd -/ Tele: (805) 544-4900 | typing it all out!!! :-)
mjr@osiris.UUCP (Marcus J. Ranum) (12/13/87)
The older versions of VAX/VMS4.XX had a serious bug in the access control lists. Initially it defaulted to no ACL would allow anyone to create one. It was then easy to put an ACL on the system logical name table with the user's name having write permission. The unscrupulous user could have then set SYSDEVICES SYSLOGIN to use something other than the "default" system LOGIN.COM, which could do just about anything. We never did that, however we notified our system admin, and when they didn't believe us, deassigned the whole table. The trick of making one's own SYSLOGIN.COM would, I suppose, be a sort of trojan horse. Another VAX virus I heard about was a friend of mine who had a system that would not boot normally no matter what. A disgruntled former employee had written a program that was spawned really quietly at boot time and would romp through the process table killing everything except itself as fast as it could. It wasn't hard to fix - (boot off of a spare pack) but it was a bit hard to initially diagnose, I gather. --mjr(); -- Once, there was NO fun... This was before MENU planning, FASHION statements or NAUTILUS equipment... Then, in 1985.. FUN was completely encoded in this tiny MICROCHIP... It contains 14,768 vaguely amusing SIT-COM pilots!!
hirai@swatsun (Eiji "A.G." Hirai) (12/14/87)
In article <166@tic.UUCP> ruiu@tic.UUCP (Dragos Ruiu) writes: > > The ocurrence of disk-erasing trojans, viruses etc. has even spawned a >de-fuser program called CHK4BOMB that lets you examine new programs and warns >of questionable practices within them. It is standard fare on all IBM-PC BBS's Is there any equivalent programs for unix systems? If there isn't, why, there should be one! Even if there isn't a program around, maybe we can all compile a list of common trojan horsies and methods to detect or counter them... >Dragos Ruiu -a.g. hirai -- Eiji "A.G." Hirai @ Swarthmore College, Swarthmore PA 19081 | Tel. 215-543-9855 UUCP: {rutgers, ihnp4, cbosgd}!bpa!swatsun!hirai | "All Cretans are liars." Bitnet: vu-vlsi!swatsun!hirai@psuvax1.bitnet | -Epimenides Internet: bpa!swatsun!hirai@rutgers.edu | of Cnossus, Crete
bruce@dolqci.UUCP (Bruce Limber) (12/14/87)
The following warning is excerpted from comp.risks:
Subj: VIRUS WARNING
Date: Mon, 23 Nov 87 08:05:57 EST
From: "Kenneth R. van Wyk" <@vms.cis.pittsburgh.edu:LUKEN@LEHIIBM1.BITNET>
>>>>>>>>>> VIRUS PROGRAM WARNING <<<<<<<<<<
Last week, some of our student consultants discovered a virus program
that's been spreading rapidly throughout Lehigh University. I thought
I'd take a few minutes and warn as many of you as possible about this
program since it has the chance of spreading much farther than just our
University. We have no idea where the virus started, but some users
have told me that other universities have recently had similar probems.
The virus: the virus itself is contained in the stack space of COMMAND.COM.
When a pc is booted from an infected disk, all a user need do to spread
the virus is to access another disk via TYPE, COPY, DIR, etc. If the
other disk contains COMMAND.COM, the virus code is copied to the other
disk. Then, a counter is incremented on the parent. When this counter
reaches a value of 4, any and every disk in the PC is erased thoroughly.
The boot tracks are nulled, as are the FAT tables, etc. All Norton's
horses couldn't put it back together again... :-) This affects both
floppy and hard disks. Meanwhile, the four children that were created go
on to tell four friends, and then they tell four friends, and so on, and
so on.
Detection: while this virus appears to be very well written, the author
did leave behind a couple footprints. First, the write date of the
command.com changes. Second, if there's a write protect tab on an
uninfected disk, you will get a WRITE PROTECT ERROR... So, boot up from
a suspected virus'd disk and access a write protected disk - if an
error comes up, then you're sure. Note that the length of command.com
does not get altered.
I urge anyone who comes in contact with publicly accessible (sp?) disks
to periodically check their own disks. Also, exercise safe computing -
always wear a write protect tab. :-)
This is not a joke. A large percentage of our public site disks have
been gonged by this virus in the last couple days.
Kenneth R. van Wyk, User Services Senior Consultant,
Lehigh University Computing Center (215)-758-4988
<LUKEN@LEHIIBM1.BITNET> <LUKEN@VAX1.CC.LEHIGH.EDU>
[end of quoted material.]
--
Bruce Limber (NEW ADDRESS: uunet!vrdxhq!dolqci!bruce) (202) 535-0640
He who slings mud, loses ground.dclaar@hpcupt1.HP.COM (Doug Claar) (12/15/87)
I believe that the "trojan horse" that the professor was discussing was
the infamous "cookie monster" program. (The program woke up every so
often, demanding "COOKIE." If you didn't type in "COOKIE," it destroyed
what you were doing). Although I've never seen that one, we had a case
where someone created a system process that periodically spewed out
valentine's day messages. The name of the process was only one character
different from a legitimate system process, so it was very difficult to
detect. It didn't hurt anything, and was rather cute. (Of course, we are
an OS lab, so it was fairly easy to do...)
Doug Claar
HP Information Technology Group
UUCP: { ihnp4 | mcvax!decvax }!hplabs!hpda!dclaar -or- ucbvax!hpda!dclaar
ARPA: hpda!dclaar@hplabs.HP.COMdave@lsuc.uucp (David Sherman) (12/15/87)
It's certainly not a myth. Back in my, um, pre-lawyer
days I did a number of things on UNIX systems along the
lines of setting up a fake login to grab passwords, modifying
the real login to grab passwords, etc. (People who
were around U of Toronto years ago may remember some of
my, um, exploits.) Of course, at the time such actions
weren't offences under the Criminal Code, as they are now.
One particular incident which got some people upset (it's
OK, Geoff, it's been long enough now, hasn't it?) was my
keeping a buried ".." directory with a setUID-root shell
on a system, using that to modify login to grab the password
of a sysadmin, confirming it was the same password on another,
"secure", system, and using his GID to modify a 664 crontab
and become root...
David Sherman (reformed now, honest!)
The Law Society of Upper Canada
Toronto
--
{ uunet!mnetor pyramid!utai decvax!utcsri ihnp4!utzoo } !lsuc!dave
Pronounce it ell-ess-you-see, please...csnjr@its63b.ed.ac.uk (Nick Rothwell) (12/16/87)
In article <1479@osiris.UUCP> mjr@osiris.UUCP (Marcus J. Ranum) writes: > Another VAX virus I heard about was a friend of mine who had a system >that would not boot normally no matter what. A disgruntled former employee had >written a program that was spawned really quietly at boot time and would romp >through the process table killing everything except itself as fast as it could. I heard of a similar case, but worse, on a network of SUNs running NFS and Yellow Pages. Someone wrote a program which looked up the names of the other hosts on the net, and then spawned off a "rsh <host> ..." to create a copy of itself on these other machines. It was stopped by powering down every single machine. You can't log in to fix it, of course, because the beast has filled the process tables on every machine... -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick%lfcs.ed.ac.uk@nss.cs.ucl.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ "Nothing's forgotten. Nothing is ever forgotten." - Herne
andrea@hp-sdd.HP.COM (Andrea K. Frankel) (12/17/87)
In article <6540001@hpcupt1.HP.COM> dclaar@hpcupt1.HP.COM (Doug Claar) writes: >I believe that the "trojan horse" that the professor was discussing was >the infamous "cookie monster" program. (The program woke up every so >often, demanding "COOKIE." I remember hearing about this one at Caltech in 1971 or 1972. I believe it was resident on one of the machines at the computer center, but can't vouch for it personally - I was allergic to computers in those days, and stayed far away from them ;@) Andrea Frankel, Hewlett-Packard (San Diego Division) (619) 592-4664 "...like a song that's born to soar the sky" ______________________________________________________________________________ UUCP : ...hplabs!hp-sdd!andrea from {ihnp4|cbosgd|allegra|decvax|gatech|sun|tektronix} or ...hp-sdd!andrea from {hp-pcd|hpfcla|hpda|noscvax|gould9|sdcsvax} Internet : andrea%hp-sdd@ {nosc.mil | sdcsvax.ucsd.edu | hplabs.HP.com} CSNET : andrea%hp-sdd@hplabs.csnet USnail : 16399 W. Bernardo Drive, San Diego CA 92127-1899 USA
ashley@utx1.UUCP (Ashley Oliver) (12/17/87)
In article <337@spectrix.UUCP>, clewis@spectrix.UUCP (Chris Lewis) writes: > > A minor quibble - have you ever used PC/MSDOS? It's very simple to > break security on these machines because there ain't none. Many BBS's Another minor quibble. It depends what you mean by 'break security' and I suspect Chris Lewis and I are thinking of different aspects, but I'd claim MS-DOS is a lot more secure than UNIX on the simple grounds that any single user/single tasking OS is inherently several orders of magnitude more secure than any multi user/multi tasking OS. Given that in both cases the user in question gives a dingo's kidneys about security ..... -- {allegra|codas}!novavax!utx1!ashley Ashley P Oliver (305) 476 6880 @ Racal-Milgo, Fort Lauderdale, Florida
bob@primerd.UUCP (12/22/87)
>>the infamous "cookie monster" program. (The program woke up every so >>often, demanding "COOKIE." If you didn't type in "COOKIE," it destroyed >>what you were doing). Although I've never seen that one, we had a case I can personally vouch for this one, except it didn't destroy what you were doing. It just wouldn't let you do anything else until you "gave it" a cookie. Then it would go away for a few minutes until it got hungry again. We had this running at CMU on the 20's when I was an undergrad. Kind of cute really. > %%MONSTER wants a cookie! > dir %% Monster wants a cookie! > cookie Thank You! Bob Pellegrino bob@bobsun.prime.com
clewis@spectrix.UUCP (Chris Lewis) (12/22/87)
In article <1931@utx1.UUCP> ashley@utx1.UUCP (Ashley Oliver) writes: >In article <337@spectrix.UUCP>, clewis@spectrix.UUCP (Chris Lewis) writes: >> >> A minor quibble - have you ever used PC/MSDOS? It's very simple to >> break security on these machines because there ain't none. Many BBS's > >Another minor quibble. It depends what you mean by 'break security' >and I suspect Chris Lewis and I are thinking of different aspects, Partially. >but I'd claim MS-DOS is a lot more secure than UNIX on the simple >grounds that any single user/single tasking OS is inherently several >orders of magnitude more secure than any multi user/multi tasking OS. Um, yes, MS-DOS is infinately more secure than UNIX w.r.t. one user leaving trojan horses around for another user. By definition - there aren't any other users.... On the other hand though, MS-DOS is considerably more vulnerable to trojans and viruses from any program obtained from the "outside". Neither the O/S or hardware is protected in any way. Once a program is running, there's nothing to stop it from doing anything it wants. A program can read or write anything (eg: diddle the O/S) or manipulate the hardware directly. Leading to DOS boot blocks containing viruses etc. This is made more tractible by the fact that in the MS-DOS world, sharing of binaries between users happens much more often than in UNIX. In the UNIX world, most of the binary programs come from (hopefully) reputable software vendors. In contrast, UNIX (as are most other Multi-user O/S's) are relatively safe from trojans or viruses of this type. Because the O/S is protected by an MMU (except on some brain-damaged hardware like PC's), user-level programs cannot access devices directly, user-level programs cannot diddle disks directly (unless the SA goofed and made the devices writable), most drastic things require super-user permissions, etc. I'm not saying that there aren't holes in UNIX - there are many (many of which apply to ANY multi-user system). But at least most of them can be plugged by a diligent SA. And almost all of the rest can be plugged by enhancements to the kernel or shell. Without making it "not UNIX". It's probably impossible to make MS-DOS significantly less vulnerable to viruses without changing quite a bit of the spec and breaking a LOT of existing "good" software. Why? Well, lots of the "good" programs do things to your hardware that's indistinquishable from what a "bad" program wants to do. Eg: many "good" programs bypass DOS disk drivers and talk directly to the controller for various reasons. So would a virus... -- Chris Lewis, Spectrix Microsystems Inc, UUCP: {uunet!mnetor, utcsri!utzoo, lsuc}!spectrix!clewis [Also: lsuc!clewis in a pinch] Phone: (416)-474-1955
msa@clinet.FI (Markku Savela) (12/23/87)
In article <1931@utx1.UUCP> ashley@utx1.UUCP (Ashley Oliver) writes: >In article <337@spectrix.UUCP>, clewis@spectrix.UUCP (Chris Lewis) writes: >> >> A minor quibble - have you ever used PC/MSDOS? It's very simple to >> break security on these machines because there ain't none. Many BBS's >.... >but I'd claim MS-DOS is a lot more secure than UNIX on the simple >grounds that any single user/single tasking OS is inherently several >orders of magnitude more secure than any multi user/multi tasking OS. Let's assume you get into hands a highly useful program in executable form for your favorite operating system/machine. The quetions is: under which operating systems you can run the program in standard environment and secure in knowledge, that it can do no harm? PC/MSDOS is surely not secure in this respect. You have no way of protecting anything in your machine. And even if you test it in a empty system, perhaps you should format the disks and power down the machine afterwards. Just to purge all possible hiding places for virus programs... On the other hand, under properly configured multiuser operating system a virus program has no chance to infect anything. Now, after the big VMS Security Hole has been plugged (?), I think VMS passes this "virus test" clearly. I don't know Unix enough to say anything about that. -- Markku Savela, UUCP: msa@clinet.fi
mike@arizona.edu (Mike Coffin) (12/25/87)
When I was at SDSM&T (about 1980) a student was caught collecting
passwords via the usual fake login. Apparently he had gotten the
passwords of several of his professors; he kept them in a file named
"passwords" or something equally obvious. He was kicked out of
school; I don't know what happened to him after that.
--
Mike Coffin mike@arizona.edu
Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2,ihnp4}!arizona!mike
Tucson, AZ 85721 (602)621-4252blgardne@esunix.UUCP (Blaine Gardner) (01/21/88)
in article <2432@sputnik.COM>, kurt@tc.fluke.COM (Kurt Guntheroth) says: > Comp.sys.amiga has recently contained an exposition of a trojan horse > program, which they called a virus, that infects amiga boot disks. This one > is harmless, but virulent varieties could easily be created. ^^^^^^^^ Not true, it will destroy many copy-protected programs! You know, the ones that you spend lots of your own money on. > It is true that most specific trojan horse programs, once known, can be > defeated. Their power, like the power of the original trojan horse, lies in > their unexpected nature; that they are other than they seem. > No myth. Fact. Reality. Unfortunatly, this one is a reality. And just when we thought it was under control, a new mutation of the virus reared it ugly head. But Commodore is taking active measures to stomp it out. -- Blaine Gardner @ Evans & Sutherland 540 Arapeen Drive, SLC, Utah 84108 UUCP Addresses: {ihnp4,ucbvax,allegra,decvax}!decwrl!esunix!blgardne ihnp4!utah-cs!esunix!blgardne usna!esunix!blgardne "I don't see no points on your ears boy, but you sound like a Vulcan!"