The Hacker's Encyclopedia 1998/hackers_encyclopedia.iso/zines/n_z/phun3.003

Text File | 2003-06-11 | 12.0 KB | 264 lines

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=                 P/HUN Issue #3, Volume 2: Phile #3 of 11                    =
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

                          VAX/VMS System Security
                          =======================
                Written for P/HUN Inc.,P/HUN Online Magazine
                --------------------------------------------
                             By  Lawrence Xavier
                               January, 1989


VAX/VMS may be the worlds best operating system. It certainly beats the
pants off each and every IBM OS, and wins over Unix hands down. Native
VAX/VMS security is rated higher (by the U.S. Government) than all IBM
mainframe OSs, even after such security packages as RACF and Top Secret
are added to them.

VMS is not without its foibles and kludges, however. For one thing,
enabling all the security features of VMS is guaranteed to crash the
system! For another, many of VMS's security features are  annoying to
set up, encouraging lazy system managers to put off doing so indefinitely.

VMS got a bad reputation when young hackers were able to routinely break
into many systems by using default accounts and passwords such as username
SYSTEM with password MANAGER. This has all changed with VMS 4.7: in the
upgrade procedure the installer is required to change passwords on these
accounts or eliminate them entirely.

Let's go over some of the basic features of VMS security, then look at some
common problems and loopholes. Once you know what the loopholes are you can
take steps to close them on systems you manage and increase security.


VMS Security Features
=====================

Logging In:
-----------
VAX/VMS systems have several types of protection that can be set up on
logins. Logins can be restricted by time of day, day of the week, and by
terminal ID. Logins can also be restricted by where they come from: Local,
Remote, Dialup, etc.

     Local    are logins on direct connect ports or DECservers.
     Remote   are logins across DECnet.
     Dialup   are logins across X.25 or on ports set with the DIALUP
              characteristic.

Usually VMS will present a
     Username:
prompt after it sees one or two <CR> characters (which are used by VMS to
set the Baud rate, if AutoBaud is enabled).

If a System Password has been set on the port, VMS will BEEP after the
first <CR>, and will then seem to be dead. Only after the correct System
Password has been entered will the Username: prompt be given.

VMS gives no indication of whether a correct username has been entered: it
always asks for a Password:. VMS passwords can be like any other passwords,
or they may be generated nonsense words. The /GENERATE_PASSWORD qualifier
may be placed on user accounts by the system manager, forcing them to
select from lists of supposedly easy to remember but nonsensical
passwords.

The system manager may also enforce a minimum password length and can even
impose dual passwords on accounts. If a Username with dual passwords is
entered, the system will prompt for Password: twice in a row. Automatic
Password expiration dates can be set, forcing users to change their
passwords every so often: from once a day to once a year or never.

After the Username and Password have been entered, the system will either
log the user in, or will print the familiar message,

     User Authorization Failure

and will hang up after a settable number of failures (the default is 3) if
the port characteristics include DIALUP and HANGUP.


Breakin Detection:
-----------------
If a hacker were trying to get into the system he could just continue to
dialup and try again. But VMS has some features to discourage this too.

If breakin detection and evasion is enabled, VMS will start to get cagey.
If the count of login failures from a specific source gets high enough, the
system assumes a break-in is in progress. Only login failures caused by
invalid Passwords are counted, NOT invalid usernames. And the attempts must
be coming from one of these three sources:

     .    A specific valid Username, and (if setup this way, A specific
          terminal.
     .    A specific remote DECnet node and remote Username.
     .    The Username of the creator of a detached process.

By default, VMS allows five failed login attempts from any one source
within the time period specified. But it's not as simple as that!

Each time a failure occurs, time is added to the time period in which a
certain number of failures can occur. To take an example from DEC:

     Assume the default values are in effect. LGI_BRK_LIM specifies no
     more than five login failures from one source. LGI_BRK_TMO is set
     for five minutes. Assume that an outsider starts sending user
     names and passwords to the system. When the first password fails,
     the clock starts to run and the user has four more tries in the
     next five minutes. When the second attempt fails about 30 seconds
     later, the user has three tries left that will be counted over
     the next 9.5 minutes. When the third attempt fails 30 seconds
     later, the login failure observation time has reached 22.5
     minutes. As a result, the next login failure from that source
     within 22.4 minutes will trigger evasive action. The system
     tolerates an average rate of login failures that is the
     reciprocal of the parameter LGI_BRK_TMO...


When breakin evasion is triggered, the system will give a:
     User Authorization Failure
message even when a valid Username and Password are entered, giving no
indication of what it is doing. Note that ONLY the Username(s) in question
are treated this way: other Usernames can still log in from the same
terminal even if terminal-specific breakin detection is enabled.

The length of time VMS will hide in this way is controlled by the sysgen
parameter LGI_HID_TIM. But VMS doesn't hide for exactly this time. Rather,
it will hide for a length of time determined by the following equation:

     Evasion time = LGI_HID_TIM * (random number between 1 and 1.5)

The parameter LGI_BRK_DISUSER can be set, and will tell VMS to permanently
disable accounts rather than just hiding for a time. The system manager
then has to re-enable them manually. This is a dangerous parameter to set,
however, because malicious individuals could deliberately disable accounts
then! If the SYSTEM account is disabled this way, it will only be allowed
to login on the VAX system console.


Security Alarms:
----------------
Although breakin attempts to different Usernames don't activate VMS Breakin
detection, they can trigger Security Alarms. Security Alarms can also be
triggered by different types of access to specific files or memory areas.
Security Alarms cause messages to be displayed on the system console, on
the terminals of any user enabled as Security Operator, and in the Operator
Log file.

As DEC says,
     Because security auditing affects system performance, enable
     security alarms only for the most important events.
Damn right! If all security alarms are enabled the system will hang! It
starts writing alarms about the fact it is writing alarms, ad infinitum....

Security alarms can be triggered on multiple login failures, on breakin, on
successful login from given ports, on failed attempts to access files, on
successful attempts to access files, etc. So even if you get privilege to
override protection or to defeat it a security alarm may still be
triggered.

Security alarms typically might be enabled on the AUTHORIZE program, which
adds and modifies user accounts, on SYSUAF.DAT, the authorization database,
on RIGHTSLIST.DAT, the access rights database, etc. and on critical
database files. But many sites don't bother with them because of their
inconvenience.

Accounting:
----------
Besides Security Alarms, Accounting can be enabled. Accounting can show
successful logins, login failures, how much resources are consumed by
processes, what programs are executed, etc. Not all sites enable
accounting, and not all sites enable the same amount of it. Accounting
records show login failures but only show the username that attempted to
login if it is a valid username.



File and Device Protection:
==========================

UIC:
----
The primary access protection mechanism is the UIC. This consists of a
Group and a User code, numerically represented as [nnn,nnn]. It is an Octal
number. Since VMS 4.x versions the UIC can also be expressed as [name] or
[name,name], but internally this is translated back to the old format.

Users, processes, files, devices, memory sections, etc. all have UICs.
Files, devices, memory sections, etc. can have access by System, Owner,
Group and World, any combination of Read, Write, Execute, Delete for each
category.
     System    are the system accounts.
     Owner     is the account(s) who's UIC is the same as that on the
               object (file, device, etc.).
     Group     are accounts with the same first UIC number.
     World     is everyone.

So a process with UIC [23,7] could access an object with UIC [23,4] if that
object allowed access by Group or World. The process could access an object
with UIC [25,3] only if World access was allowed, and could access objects
with UIC [23,7] if Owner, Group, or World was allowed.

ACL:
----
Also, there's a protection mechanism called the ACL or Access Control List.
This is in addition to, and can override UIC protection. With ACLs an
Identifier is created, like MODEM for one or more modem ports. An ACL is
created on the port(s) desired, and in the ACL are multiple Access Control
Entries (ACEs). If one of them is:
     (Identifier=MODEM, Access=Read+Write)
for example, user who has been Granted the identifier MODEM can access
those ports. These access privileges, like UICs apply to processes in
general. Granting and managing Identifiers is done in the AUTHORIZE
program.



Loopholes, Ways of  put at $1 billion per
switching system some years ago by the then Philips chief executive Dr. Wisse
Dekker, with ongoing development costing around $200 million a year (Mr.
Kuznik) -- is one of the main factors of limiting the number of future
participants.  Its globality is stressed in the strongest terms by Mr.
Philippe Gluntz, executive vice-president and chief operation officer of
Alcatel NV:  "We are one of the few manufactures able to offer the whole range
of telecommunications equipment: digital switches, all kinds of transmission
products from copper cables and fiber optics to satellite communications; all
types of business systems from digital PABXs to microcomputers or electronics
sub-sets, word processors, etc."

Resources in terms of funds and range of products are vital for the
prospective telecommunications survivors:  but so is teh technology of the
21st century.

TABLES:


TABLE I
World public switching equipment sales of leading manufactures
_____________________________________
Company               Sales of public
                      switching equip
                      in $ million
___________________________________
AT&T (US)                    1350
Northern Telecom (Canada)    1000
NEC/Fujitsu/Hitachi (Japan)  1000
Siemens (West Germany)        950
ITT (US *1)                   850
Ericsson (Sweden)             750
Alcatel/Thomson (France)      700
GTE (US)                      350
Plessey (UK *2)               260
GEC (UK)                      260
Italtel (Italy)               180
Philips (Netherlands *3)      130
Stromberg-Carlson (US *4)      70
Others (inc. Nokia, Finland)  120
                             ----
                             7970
___________________________________
*
1) Now Alcatel NV through merging Alcatel/ITT telecommunications intrests
2) Involved in talks on merging certain System X functions
3) Set up APT to cater for world telecommunications sales outside US
4) Subsidiary of Plessey, mainly for US switch