dpw@unisec.UUCP (Darryl Wagoner) (10/27/86)
Like many others, I attended the Unix Expo in New York City this week. At the Gould booth there was a large sign challenging Unix wizards to break into their "Secure Unix" system. The also gave out a flyer that stated the following: |--------------------------------------------------------------- | GOULD | | *** HACKER CHALLENGE *** | | UNIX EXPO 1986 | | OCTOBER 20,21,22 | |There is a text file on our 6040-I, UTX/32S - SECURE UNIX* |system. We challenge anyone to find out its contents. The file |pathname is: | | /usr/unixexpo/securefile | |RULES: | |1. You must access the system from one of two user | terminals. Login as "guest1" or "guest2". | |2. All winners who successfully break into the system will | be placed in a drawing for a grand prize winner | of a 19" color tv. | |3. In the event of any conflicts, the decision of the GOULD | show director will be final. | |*Unix is a trademark of AT&T | |---------------------------------------------------------------- The contents of the file was: "gould makes firebreathing,very high performance super mini machines." I will present the case history of how I broke it using the most classic of all hacker tricks. In addition I located other weaknesses in their system that would allow even the most novice hacker to break into UTX/32S. Having only limited time and a public account to do my hacking, I choose to use the Trojan horse attack. They willing revealed the environment that a user is put in is a restricted environment either much like or exactly like the chroot(2) system call of Unix. Which, to the best of my knowledge hasn't been defeated. Therefore, it would have been a waste of time to try to defeat the chroot. The Gould salesmen readily offered to show me their environment which reveled that PATH was set to ".:/bin:/usr/bin:..." The key being the current directory is at the beginning of the search path. I quickly created a 'ls' trojan horse and put it in the guest home directory. Then I asked if root could get to the guest directory and asked him to do so. He did a cd to the guest directory and did a 'ls' which fired off my trojan horse. I could have waited for him to fall into the trap. I was afraid that some one else would find my trojan horse and use my work. Before I got everything right, I had to enlist the unknowing support of root twice more, due to differences in Secure Unix. At this point, let me point out that in order for Gould to archive this level of security they had to strip out a lot of the things that makes Unix powerful (ex: suid bits) and isolated users into a chroot environment. UTX/32S also seems to have many cross checks with the different /etc/passwd and /etc/group files. The first attempt was to add my own "admin" account to the top level passwd file. This failed because the user id I chose wasn't in the group file. Another trojan later, I had my own group in the group file. Still the system complained about my group not being valid, but it did let me log in as an administrator. Then a very strange thing happened. I couldn't execute "cshsu(8)" (Gould's answer to su, but less secure). The real admin couldn't execute cshsu either. I returned the next day and asked if they had found out how I had broke in. With their audit file, I expected that they had. The answer was that I had broke something and they had to reboot; that caused the audit file to be removed. (note: if you ever want to cover your tracks on UTX/32S just crash the system.) Well, this gave me new hope that I could break it with another, better horse. With the next horse I copied the file in question to an area that I could read. (Besides making a copy of the file I could have also planted a worm or virus. Of course no one would do such a thing :-) ) Then I showed them the content of the file in question. Well they lost their cool to say the least. I was happy to explain how I did it. They informed me that I had not really broke the system but just tricked the system admin and that the method that I used was immoral. I tried to argue with him about fifteen minutes without success. In hope of reasoning with him I enlisted the help of a impartial third party. (Who I haven't ask if I could quote so I will withhold this persons' name). This person listened to both sides and concluded that I had broken the system with a classic hacker technique. The question I have for the net is: Is using a trojan horse a legit way to break into a system? What is your opinion? SUMMARY of Gould UTX/32S System I am not even sure that it can still be called Unix since SUID bits have been removed. After all that is what Dennis M. Ritchie patented as the Unix protection scheme. But as far as being secure, I will say that it is or could be as secure as any other unix system. It takes more forethought to break standard unix. It takes away one of the most powerful features of unix. The cshsu should have stripped out the current directory from the path like su(1) does. For that matter, the shells should have removed the current directory or at least put it at the end just for good system hygiene. The tty driver should have a kill character to allow login to be killed to prevent trojan horses. There is also another hole I will not going into at this point. -- Darryl Wagoner UniSecure Systems, Inc.; Newport, RI; (401)-849-0857 {allegra|gatech|linus|raybed2|ihnp4|cci632} !rayssd!unisec!dpw
avolio@decuac.DEC.COM (Frederick M. Avolio) (10/28/86)
In article <161@unisec.UUCP>, dpw@unisec.UUCP (Darryl Wagoner) writes: > The question I have for the net is: Is using a trojan horse a legit way > to break into a system? What is your opinion? This is silly. (I am *NOT* calling Darryl silly!) Asking if there is a legitimate way to break in to a system. Anything that works is "legitimate" if you can call something `devious' legitimate. Having the current directory in your superuser search path is always dangerous and kind of an obvious thing to avoid. In fact, you might argue that root should have a NULL path and have to expressly give full paths for every command to be sure. (I wouldn't argue this... but I have fat fingers.) I assume you didn't win the color TV. I hope you were included in the drawing. Saying "No fair!" when someone does something unanticipated is foul play. (Let us remember Kirk's solution to the Kobiashi Maru challenge. (And please no spelling corrections please. I couldn't care less.))
page@ulowell.UUCP (Bob Page) (10/28/86)
dpw@unisec.UUCP (Darryl Wagoner) wrote in article <161@unisec.UUCP>: > ... Is using a trojan horse a legit way to break into a system? Any method that does the job can be considered effective. Who cares about being legitimate? Would you pooh-pooh a system cracker that just destroyed your passwd file because she didn't use a 'legitimate' method? >Darryl Wagoner >UniSecure Systems, Inc.; Newport, RI; (401)-849-0857 Interesting. ..Bob -- UUCP: wanginst!ulowell!page Bob Page, U of Lowell CS Dept VOX: +1 617 452 5000 x2976 Lowell MA 01854 USA
wcs@ho95e.UUCP (#Bill.Stewart) (10/30/86)
In article <694@ulowell.UUCP> page@ulowell.UUCP (Bob Page) writes: >dpw@unisec.UUCP (Darryl Wagoner) wrote in article <161@unisec.UUCP>: >> ... Is using a trojan horse a legit way to break into a system? > >Any method that does the job can be considered effective. Who cares >about being legitimate? Would you pooh-pooh a system cracker that >just destroyed your passwd file because she didn't use a 'legitimate' >method? What Darryl did was perfectly legit. An alternative way to do it would be to send mail to root saying "My %s doesn't work when I'm in my home directory; can you take a look at it, and see if I goofed on something?" Obviously this has some limitations in a "break my trade-show system" environment, but it's the equivalent you'd use in real life. Some alternatives are "I got a new version of rogue! want to try it?" if you have a dumb system administrator. An equally legitimate approach, useful at tradeshows, is to see what kind of terminal the administrator has. Most CRTs have a block=transfer mode that can be exploited by a letter-bomb. Even if they get rid of setuid and give root a useful path, they probably didn't bomb-proof mail. -- # Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
ricker@bunker.UUCP (ricker) (10/30/86)
>dpw@unisec.UUCP (Darryl Wagoner) wrote in article <161@unisec.UUCP>: > ... Is using a trojan horse a legit way to break into a system? I think that Darryl's security-cracking technique just emphasized what any competent system administrator knows--that hardware and software technology alone are not the only components of a security and cannot be relied upon exclusively. He was smart enough to spot the weakest link in Gould's security--the people. They should have given him the prize!!! Ricker
page@ulowell.UUCP (Bob Page) (11/01/86)
wcs@ho95e.UUCP (Bill Stewart) wrote in article <1056@ho95e.UUCP>: > ... Most CRTs have a block=transfer mode that can be exploited > by a letter-bomb. Anybody who reads mail as root deserves to get a letter bomb! You should forward root's mail to non-priv'd accounts, and keep `mesg n' and `biff n' (a Berkeleyism) so people/daemons can't write to root's terminal. You can hack su(1) to do this for you, including catching the suspend/wakeup signals to restore biff/mesg as you bounce in and out of `su' state. Harder to deal with: If you log in as root on the console and somebody sends a message via syslog(3). Anybody found a resonable defense against this, other than ``don't use block-mode terminals for consoles'' (an academic question, we don't anyway) or ``don't log in to the console''? ..Bob -- UUCP: wanginst!ulowell!page Bob Page, U of Lowell CS Dept VOX: +1 617 452 5000 x2976 Lowell MA 01854 USA
stevesu@copper.UUCP (Steve Summit) (11/02/86)
In article <161@unisec.UUCP>, dpw@unisec.UUCP (Darryl Wagoner) writes: > > The question I have for the net is: Is using a trojan horse a legit way > to break into a system? What is your opinion? You know those stupid logic problems where you're on an island, and some of the natives always tell the truth, while some of them always lie, but you can't tell them apart, and you're supposed to ask an unknown native one question which will let you determine which of two paths leads to some village? Calling a trojan horse an "illegitimate" way of breaking into a system is like getting mad at a crafty native for giving you some kind of distruthfully honest answer which causes you to walk down the wrong path. What would Gould have considered a "legitimate" way of breaking in? What does a "legitimate way of breaking in" even mean? Steve Summit tektronix!copper!stevesu
dave@murphy.UUCP (H. Munster) (11/05/86)
(This is a specific disclaimer: the opinions expressed in the material
below are specifically mine. I do not claim to speak in any official
capacity for Gould or any department or division of Gould. PLEASE don't
fire me...please?)
Hmmm...the UTX people up in Urbana read unix-wizards too. I'm sure that
they've already seen Darryl's posting, and will fix the searchpath problem
sometime soon (but don't ask me when; I'm not associated with them).
Was the approach "legitimate"? Welllll... I'm not sure about the rules
of the contest, but in real life, anything that works is legitimate, and
obviously Darryl's approach worked.
However, it seems to me that Darryl took advantage of two security holes,
and only one of them was in the system. The security holes are:
(1) the faulty searchpath with the current directory first, and (2)
the naive system administrator, who consented to log in as superuser on the
user's behalf and poke around in the user's directory. In the real
world of government-classified computer installations (which is what
Secure UTX is targeted for), you probably would have not gotten such
cooperation from the system admin.
Any system, no matter how secure it is designed to be, is only as secure
as the people who run it make it. If the searchpath problem was fixed,
Darryl still have gotten in by creating a Trojan-horse program in his
directory and convincing the superuser to run it. (An old student
approach: "I'm getting a wierd error out of this homework program; could
you please run it and tell me what you think is wrong?"). This would
have worked just as well, and there is *no system on the market* that
can stop this type of attack...because the thing being taken advantage of
isn't the system, it's the system administrator.
This is not to knock Darryl's approach, which was clever and devestatingly
simple. But he could have broken the system just as easily by watching
the administrator type in the superuser password, and then logging in as
superuser himself. This is just to point out that a system is only as good
as its administrators.
(And you can bet that the next time we run such a contest, the person running
the machine will be more careful!)
---
It's been said by many a wise philosopher that when you die and your soul
goes to its final resting place, it has to make a connection in Atlanta.
Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
UUCP: ...{sun,pur-ee,brl-bmd}!gould!dcornutt
or ...!ucf-cs!novavax!houligan!dcornutt
ARPA: wait a minute, I've almost got it...
"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."avolio@decuac.DEC.COM (Frederick M. Avolio) (11/08/86)
In article <157@houligan.UUCP>, dave@murphy.UUCP (H. Munster) writes: > However, it seems to me that Darryl took advantage of two security holes, ... > (2) the naive system administrator, who consented to log in as superuser ... > ... In the real > world of government-classified computer installations (which is what > Secure UTX is targeted for), you probably would have not gotten such > cooperation from the system admin. [engage sarcasm drive, half-power] Ooohhhh. Yeah. That's for certain.... Couldn't imagine it in the "real world of government-classified computer installations." Nahhh. Never happen ...