Child pages
  • CERT Advisory CA-1990-09 VAX/VMS Break-ins

Pages in the Historical section of this site are provided for historical purposes, they are no longer maintained. Links may not work.

Skip to end of metadata
Go to start of metadata
Original issue date: November 8, 1990
Last revised: September 17, 1997
Attached copyright statement

A complete revision history is at the end of this file.

I. Description

Several VAX/VMS systems are presently being subjected to intrusions by a persistent intruder(s). The intruder utilizes DECnet, TCP/IP, and/or X25 access paths to gain unauthorized entry into accounts (privileged and non-privileged). Once a privileged account is breached, the intruder disables auditing & accounting and installs a trojan horse image on the system. In the most recent attacks, the intruder has installed the image VMSCRTL.EXE in SYS$LIBRARY. (Note that VMSCRTL.EXE is not a vendor-supplied filename.) The command procedure DECW$INSTALL_LAT.COM is placed in SYS$STARTUP and installs the image. Note that these images and command files are sufficiently camouflaged so as to appear to be valid VMS system files, even upon close inspection.

There is no evidence that the intruder is exploiting any system vulnerability to gain access to the affected systems. The intruder uses valid username/password combinations to gain access to accounts. The intruder most likely obtains these username/password combinations by systematically searching through text files on the user disks of penetrated systems for clear-text username/password pairs. These username/password combinations are often valid on remote systems, which allows the intruder to access them as well. Once a privileged account is accessed, the intruder will use the AUTHORIZE utility to detect and exploit dormant accounts (especially dormant privileged accounts). The intruder has also assigned privileges to dormant non-privileged accounts.

II. Impact

Unauthorized users who gain privileged and/or non-privileged system access might deliberately or inadvertently affect the integrity of system information and/or affect the integrity of the computing resource.

III. Solution

The following steps are recommended for detecting whether systems at your site have been compromised:

  2. (This can be done with the following DCL command: $ DIR device:[*...]/SINCE=date /MODIFIED). Note that to call the command procedure which installs the image, the intruder will utilize SYSMAN to modify SYS$STARTUP:VMS$LAYERED.DAT. Thus, there will be an unexplained modification to SYS$STARTUP:VMS$LAYERED.DAT. This may be the surest indication of an intrusion, since the intruder could easily change the names and locations of the trojan horse image and its accompanying command procedure.

  3. If you discover that auditing or accounting has been disabled for a period of time
  4. Go into AUTHORIZE and ensure that no password or other changes were made during that time. Password changes while auditing and accounting have been disabled may indicate unauthorized access into your system.

The following pre-emptive actions are suggested:

  1. DISUSER all dormant accounts, especially dormant privileged accounts.
  2. Advise all users of the security problems inherent in placing username/password combinations in text files. Consider searching your user disks for such occurrences.
  3. Change all vendor-supplied default passwords (e.g., MAILER, DECNET, SYSTEM) and make sure all passwords are difficult to guess.
  4. Make sure that all privileged users have only the minimum privileges that are REQUIRED to perform their current tasks.
  5. Closely monitor all relevant audit trails.

Copyright 1990 Carnegie Mellon University.

Revision History
September 17,1997 Attached copyright statement
  • No labels