[comp.os.vms] DCL DECnet command procedure

DEMAR@FNALE.BITNET (11/17/87)

    Last week there was an inquiry from BEN@VMSA.TECH.AC.IL about a DCL
command procedure that can be used to examine remote DECnet systems.  I want to
add a word of warning about the use of this type of program.  It works by
sending a copy of itself into the default account of the remote system, then
utilizing task-to-task communication between the two programs.  It is a primary
weapon of hackers; and, infact, is a form of hacking in its own right, since
the user is copying and executing a file on a the remote system without any
authorization to do so.  I happen to be quite involved in the daily network
management of the High Energy Physics DECnet network (HEPnet).  The HEPnet
network management considers any use of this type of program to constitute
hacking, and we agressively pursue people who use it, requesting the facility
involved to deal with the situation in a manner "that STRONGLY discourages any
future occurrances".  We are, infact, willing to involve the FBI and the
Justice Department, if necessary.  While I can only speak for HEPnet, I know
for a fact that the Space Physics Analysis Network (SPAN), another large DECnet
network, also aggressively pursues users of this type of program.  My advise
for anyone thinking about using this type of program across any wide-area
is to recognize this as a form of hacking, and to refrain from utilizing it.
Either that, or be prepared to have the wrath of the gods or the law descend
upon them.


                                                           -- Phil DeMar
                                                              DEMAR@FNAL.BITNET

rrk@byuvax.bitnet (11/24/87)

A system manager who knows anything about DECNet can disable such command
procedures.  If a system manager understands the security "hole" and does
nothing about it, he's stupid.  DECnet is, in my opinion, the biggest potential
security problem in a VMS environment, because unlike most VMS security,
it doesn't mostly take care of itself, so all the system managers who get
by in most other areas without really knowing much can open big holes in
a hurry.  Another thing people should watch for:

If you set your print devices spooled, anyone on or off the system can print
for free by copying to node::device:.

I know of NO reason for ever making a device spooled, but most system managers
do it anyway.

Another good idea is probably to enter a proxy for node::* to * so that
all local users cannot access the local system via the DECNet account.
(It is a very BAD idea to do such a wildcard proxy between two systems not
managed by the same person, as it allows "superusers" of one system to exploit
the other system by changing username).

I would disallow all access for the DECNET username except for mail (possibly).
Why allow remote users to see all your directorys, to execute com procedures,
print files, see who's on the system, etc.  If a manager doesn't worry about
his network--I won't go so far as to say that he deserves to have his security
compromised; noone deserves that--he can expect to have his security
compromised.

klb@philabs.Philips.Com (Ken Bourque) (11/24/87)

In article <8711231109.AA29035@ucbvax.Berkeley.EDU> DEMAR@FNALE.BITNET writes:
* 
*     Last week there was an inquiry from BEN@VMSA.TECH.AC.IL about a DCL
* command procedure that can be used to examine remote DECnet systems.  I want
* to add a word of warning about the use of this type of program.  It works by
* sending a copy of itself into the default account of the remote system, then
* utilizing task-to-task communication between the two programs.  It is a
* primary weapon of hackers; and, infact, is a form of hacking in its own right
* since the user is copying and executing a file on a the remote system without
* any authorization to do so.

For this and other reasons, I think that default DECnet access should be
enabled on an object-specific basis (and not for FAL if at all avoidable)
rather than on a system-wide basis.-- 
Ken Bourque    klb@philabs.philips.com    ...!{uunet,ihnp4,decvax}!philabs!klb

tedcrane@batcomputer.tn.cornell.edu (Ted Crane) (11/26/87)

In article <28rrk@byuvax.bitnet> rrk@byuvax.bitnet writes:
>If you set your print devices spooled, anyone on or off the system can print
>for free by copying to node::device:.

Only if there is a default DECnet account, proxy logins, or they supply
an explicit username/pswd string.  Once again, the default DECnet account
is the security hole...if a system manager provides it, they are inviting
others to use it!

>I know of NO reason for ever making a device spooled, but most system managers
>do it anyway.

Well, in most if not all of the examples they provide, DEC suggests that this
be done.  I agree with you--there isn't a whole lot of excuse to spool a device
(see caveat below), but you've got to argue with Dr.DEC as well as the
misguided system managers.  Caveat:  some applications have a bad habit of
printing by opening a file directly to the line printer device (or equivalent).
This is not a great idea, really, but is usually the result of ported, updated,
or just plain resurrected old code.  Sure, someone should rewrite the old code,
but who?  Until then, spooled devices *sure are handy*!

>Another good idea is probably to enter a proxy for node::* to * so that
>all local users cannot access the local system via the DECNet account.
>(It is a very BAD idea to do such a wildcard proxy between two systems not
>managed by the same person, as it allows "superusers" of one system to exploit
>the other system by changing username).

Sure, I agree.  But there are problems.  First, you should avoid (like the
plague) setting proxys to privileged accounts.  Do this by adding explicit
proxys to the list in addition to the one wildcard entry.  Second, this 
scheme requires that usernames be the same on all machines.  Not impossible,
but not real likely, either.  Clusters with a common SYSUAF help a lot here.
Third, *almost any* privileged user on any node can fake this system out.
Once again, we are relying on trustworthy users.

>I would disallow all access for the DECNET username except for mail (possibly).
>Why allow remote users to see all your directorys, to execute com procedures,
>print files, see who's on the system, etc.  If a manager doesn't worry about
>his network--I won't go so far as to say that he deserves to have his security
>compromised; noone deserves that--he can expect to have his security
>compromised.

The default DECnet account is a useful tool.  Yes, it opens up a real can of
worms.  This may be more than a security minded manaager can accept.  But the
functionality you lose by removing it is significant.  The manager should
provide replacement tools.  Has anyone considered something like this in the
SYS$SYLOGIN procedure:
	$ if <username> .eqs. <Default DECnet account> -
	  then set command/delete=<anything you consider unsafe>
Not totally effective, yet worth a try.