The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 3 Issue 63

Wednesday, 24 September 1986

Contents

o NOTROJ (a Trojan Horse)
James H. Coombs via Martin Minow
o Massive UNIX breakins at Stanford
Scott Preece [two more messages!]
o Info on RISKS (comp.risks)

 

<minow%regent.DEC@decwrl.DEC.COM>
23-Sep-1986 1644
     (Martin Minow, DECtalk Engineering ML3-1/U47 223-9922)
To: risks@csl.sri.com
Subject: NOTROJ (a Trojan Horse)

Found on a local bboard:

Date:       Sat, 20 Sep 86 04:17:50 EDT
From:       "James H. Coombs"  <JAZBO%BROWNVM.BITNET@WISCVM.WISC.EDU>
Subject:    NOTROJ--it IS a trojan

Distribute far and wide!
(C)Nobodaddy, 1986

                       A Story of a Trojan Horse
            With Some Suggestions for Dismounting Gracefully

                                   by
                            James H. Coombs


NOTROJ.COM is a TROJAN HORSE (comes in NOTROJ.ARC--for now).

I first became aware of NOTROJ when a member of The BOSS BBS community
reported his belief that the program destroyed the directory of his hard
disk.  After two days of restoring his files, he concluded:

         This Trojan was written by a real Pro---he knows his ASM and
         uses it as a weapon---not a tool.  From lokkin' at the job he
         did on me, I tendto doubt that I would have found the bomb has I
         been smart enough to look. ---PLEASE!!!!!  Spread the word 'bout
         this one.  It's a Killer!

In the next couple of days, I saw a similar note on the Boston Computer
Society bulletin board.  This victim rather pathetically credits NOTROJ
with a "valiant" attempt at saving his data.

         The program in question is a time-bomb (about 10 minutes) and
         works by the "SOFTGUARD UNFORMAT" method of attack.  I'm not
         sure what it did, or how it did it, or even how I could have
         recovered the disk but the NOTROJ program I had in the
         background alerted me to the fact, and tried a valiant attempt
         to shut down the hard disk.  To no avail, though.

Since my hard disk was becoming fragmented anyway, I decided to test
NOTROJ.  Everything looked pretty reasonable from the start; in fact, the
program looks like a very useful tool (although I'm not in love with the
interface).  One loads NOTROJ resident and then accesses the options menu
through Alt-N.  The menu contains about fifteen items, some of them
annotated "DANGER", e.g., "Format track (DANGER!)".  For each parameter,
the user can select one of four responses: Proceed, Timeout, Reboot, or
Bad Command.  The menu also provides a fifth option--"Pause&Display"--
which provides the user with full information on the activity that the
currently active program is trying to perform and prompts for one of the
four primary actions, e.g, Proceed.

I selected "Pause&Display" for all of the DANGERous parameters.
Everything worked fine, although I found that iteratively selecting
"Timeout" in response to the "Write sectors" interrupt hung up the
machine.  I fooled around with a number of commands and finally
reproduced the disk crash.  At the time, I was running the DOS ERASE
command (I had been suspicious of that one for quite some time anyway).
I don't have the full message that the program displayed, but I did write
down this much "Softguard-style low-level disk format."  (Keep those
words in mind.)

In spite of the fact that I had prepared for a disk crash, it took me at
least an hour to get running again.  When I booted the machine, I was
thrown into BASIC and could not get back to the system.  I put a DOS
diskette in, and got an invalid drive error message when I tried to
access the hard disk.  Here is the recovery procedure for this and most
disk crashes:

1) Insert DOS system disk in drive A.
2) Reboot the machine.
3) Run FDISK and install a DOS partition on the hard disk.
4) Format the hard disk with the '/S' option.
5) Restore files from the most recent full-disk Bernoulli or tape
   backup.
6) Restore files modified since the most recent full-disk Bernoulli
   or tape backup.

Once I got a minimal system running, I decided to reproduce the crash to
ensure that this was not some quirk of bad programming.  What, ho!  I got
bored playing around with COPY and ERASE and a few other programs.  I
waited for a while, read a magazine--no signs of a simple timing
technique.  I began to think that NOTROJ might be more incompetent than
vicious.  Something about the documentation made it seem unlikely that
the author was a criminal.  It occurred to me, however, that the author
might have had some time to waste on this program.  Does he, perhaps,
check to see how full the hard disk is?  It would be reasonable to evade
detection immediately after a bomb by making it impossible to reproduce
the crash.  In addition, it would be much more painful for people if they
have restored all of their files or gradually rebuilt their hard disks
before they discover that this is a trojan horse.  So, I restored all of
my files.

This time, Norton's NU command turned out to be the great blackguard that
was trying to format my disk (according to NOTROJ--although it was only
reading the FAT).  So, I restored my hard disk.  All of the while,
however, I had the nagging feeling that the documentation did not reflect
the personality of someone vicious.  When I got running again, I took a
look into NOTROJ.COM.  Nowhere could I find the words from the message
"Softguard-style low-level disk format."  That convinced me.  I have
concealed passwords on mainframes by assembling strings dynamically
instead of storing them statically.  Our trojanette must have used the
same technique so that no one would spot the suspicious messages.  I had
counted on being able to get them directly from the program so that I
would not have to take the time to write the whole message down while my
system was being operated on.  I do recall NOTROJ patting itself on the
back, however, for preventing "further damage."

As I think back on it, the documentation contains something of a rant
against copy-protection schemes, including Softguard.  In addition, I had
always been troubled by the fact that the name NOTROJ is an acrostic for
TROJAN and also an assertion that the program is not itself a trojan.
The documentation is also very badly written.  One has to experiment to
make sense of it, although that is nothing new in software documentation.
Also, the style is something of a pidgin English, which seems consistent
with the fact that the author has an Oriental name (Ng, or is that for
"no good"?).  Well, since the author's name and address are listed in the
documentation, I decided to give him a call.  Mirabile dictu!  It's a
real name, and I got a real number--I just didn't get an answer, even at
2 a.m.  It doesn't make much difference anyway, there's nothing that he
can say to convince me that he had legitimate reasons for concealing
error messages and that his program is not a trojan horse.  There is also
the possibility that the person listed as author has nothing to do with
the program.  Could the pidgin style of the documentation be the work of
a clever linguist--an acrostic fan--a sick person who considers himself
to be the bozo that Sherlock Holmes was always after?  Who knows?  I have
to write a book.  No time to play with these fools.

So, be careful.  Note that sysops don't have the time to test every
program extensively.  If a program like NOTROJ requires that a disk be
more than 70% full, for example, a lot of people may never have any
problems with it.  What else can we do?  Does someone want to try to
prosecute the author of NOTROJ?  And how do we keep ourselves from
becoming paranoid about new noncommerical software?

Eventually, I think it will all shake out just fine.  Those of us who are
prepared for problems provide others with the testing and filtering.
Junk like NOTROJ just does not make it into my community.  Actually, I
find mediocre software much more of a problem.  I have spent a lot of
time and money sorting through megabytes of chaff to find but a few
grains of wheat.  I would like to see us find some way to constrict the
growth of chaff and worms both.  If we can't do this, many of us may
have to switch to commercial software.
                                                   --Jim
Replies may be made to:
BITNET:  JAZBO@BROWNVM
BBS:     The BOSS, BCS, Hal's, et passim
BIX:     jcoombs


Massive UNIX breakins at Stanford

"Scott E. Preece" <preece%ccvaxa@GSWD-VMS.ARPA>
Tue, 23 Sep 86 09:16:21 cdt
   [This was an addendum to Scott's contribution to RISKS-3.61.  PGN]

I went back and reviewed Brian Reid's initial posting and found myself more
in agreement than disagreement.  I agree that the Berkeley approach offers
the unwary added opportunities to shoot themselves in the foot and that
local administrators should be as careful of .rhosts files as they are of
files that are setuid root; they should be purged or justified regularly.

I also agree that it should be possible for the system administrator to turn
off the .rhosts capability entirely, which currently can only be done in the
source code and that it would be a good idea to support password checks (as
a configuration option) on rcp and all the other remote services.

scott preece, gould/csd - urbana, uucp: ihnp4!uiucdcs!ccvaxa!preece


Re: Massive UNIX breakins at Stanford

"Scott E. Preece" <preece%ccvaxa@GSWD-VMS.ARPA>
Tue, 23 Sep 86 08:41:29 cdt
  > From: Rob Austein <SRA@XX.LCS.MIT.EDU>

  > I have to take issue with Scott Preece's statement that "the fault lies
  > in allowing an uncontrolled machine to have full access to the network"...

I stand by what I said, with the important proviso that you notice the word
"full" in the quote.  I took the description in the initial note to mean
that the network granted trusted access to all machines on the net.  The
Berkeley networking code allows the system administrator for each machine to
specify what other hosts on the network are to be treated as trusted and
which are not.  The original posting spoke of people on another machine
masquerading as different users on other machines; that is only possible if
the (untrustworthy) machine is in your hosts.equiv file, so that UIDs are
equivalenced for connections from that machine.  If you allow trusted access
to a machine you don't control, you get what you deserve.

Also note that by "the network" I was speaking only of machines intimately
connected by ethernet or other networking using the Berkeley networking
code, not UUCP or telephone connections to which normal login and password
checks apply.

The description in the original note STILL sounds to me like failure of
administration rather than failure of the networking code.

scott preece

    [OK.  Enough on that.  The deeper issue is that most operating
     systems are so deeply flawed that you are ALWAYS at risk.  Some
     tentative reports of Trojan horses discovered in RACF/ACF2 systems
     in Europe are awaiting details and submission to RISKS.  But their
     existence should come as no surprise.  Any use of such a system in
     a hostile environment could be considered a failure of administration.
     But it is also a shortcoming of the system itself...  PGN]

Please report problems with the web pages to the maintainer

Top