==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 (carriage return). Backspaces are displayed as "u". Within a few utilities, "EXIT" will take effect immediately after being typed (without a 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 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 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 (LOGGED IN), MP.0343 (LOGGED OFF), MP.0676 (EXCESSIVE LOGIN ATTEMPTS), MP.0002 (FILE NOT FOUND ON DISK), MP.0461 (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 the processor type. This is used to determine the ! search rules for the file. ! ! -input 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