Network Computingwww.networkcomputing.com

To identify indicators of intrusion, we'll discuss a basic attack methodology followed by a specific attack, which can be accomplished in a test environment where vital systems can be cost-effectively replicated.

Scope and Test Scenario:

The scope of this project was limited to assessing the possible risks (how vulnerable it is to external attacks) to a target system through its interface to the attack system. The attack system had Internet access; however, the target system did not. The scen ario focused on an attacker who had broken into the attack sys tem and was now searching for other systems to attack.

Objectives:

1. Identify which attack tools were successful and which were not.

2. Identify indications and warnings of the attacks.

3. Identify potential risks and countermeasures.

4. Determine attack capabilities required of an adversary.

5. Determine if the target system's front end is vulnerable to commonly known attacks.

Assumptions:

1. The attacker cannot penetrate the target system except through the attack system interface.

2. The attacker has successfully penetrated the attack system through dial-up or Internet capability.

3. The attacker is masquerading as an authorized attack system user, but not with target-system access.

4. The attacker has downloaded and collected various common attack software programs to use against the target system interface.

5. The attacker's goal is to penetrate the interface to subsequently collect target system information, leave a backdoor to re-enter the sys tem, and subsequently deny use of the target system through the interface.

Methodology and Expectations:

· Use an attack toolkit of software programs taken from Internet and other environments.

· Use the attack toolkit against vulnerabilities identified through research and interviews of information systems security specialists, hackers and government personnel.

· Expect the system to successfully defend against all attacks and document attacks through audit trail records.

· Gain access to a user's account and subsequently a "root" user's account. Note: Gaining root access gives the user control of the system and the ability to change and delete system and information files, to include modifying or deleting audit trails.

User Profiles Developed for the Attack Scenarios:

Manny: A user with single sign-on between two machines. This would be used by a power user, for example, somebody requiring access to more than o ne system, not necessarily root access . The user would require access several times a day to several systems, such as target system networked to attack system.

Moe: A user who must enter a password every time to switch between systems and who may have accounts on several systems but may not require access to each system each day.

Jack: A user who simulates traffic between the two machines.

The Attack Sequence, Results, Indications and Warnings, and Recommendations

Identify the system and its IP address:

· An Attack Sequence: Examine network configuration files. Run ISS.

· Results: Obtained a listing of accessible systems by IP address.

· Indications and Warnings: None

· Recommendations: Restrict access to network configuration files. Use firewall between attack system and target system. Firewall prevents most probings of IP addresses.

Identify Services and Well-Known Vulnerabilities on the System.

· An Attack Sequence: Run probe; Run SATAN.

· Results: Finds TCP ports and identifies which services are running on the systems; identifies versions of network software on target system. Tested for well-known vulnerabilities.

· Indications and Warnings: Running SATAN prompts warning notice to system security administrator. Running Probe results in excessive network traffic, well above normal.

· Recommendations: Periodic use of SATAN to check for common vulnerabilities. Periodic review of console messages. Periodic monitoring of network traffic levels.

Identify Users on the System

· An Attack Sequence: Run finger

· Results: Identifies which accounts are currently logged onto target system.

· Indications and Warnings: None.

· Recommendations: Disable "finger" daemon, if not essential.

Capture a packet coming from the target system (target system's front end) to the attack system, which contains user passwords.

· An Attack Sequence: Run sniffer in an attempt to capture a user log on sequence.

· Results: Obtained general user password.

· Indications and Warnings: None

· Recommendations: Use an authentication mechanism that does not require the transmission of plain-text passwords.

Obtain the encrypted root password residing on the target system; gain root access encrypted password.

· An Attack Sequence: Access the FTP daemon on target system. Cause an ABEND. Recover core dump file.

· Results: Encrypted password for target system root access obtained.

· Indications and Warnings: Extra core dump files laying around the file system.

· Recommendations: Contact vendor and apply necessary patches. Periodic scans for core dump files as an indication that an attack may have occurred.

Decrypt root access password; by using root access, gain control of the system.

· An Attack Sequence: Run FBRUTE

· Results: Encrypted root password from target system decrypted.

· Indications and Warnings: None

· Recommendations: Vendor can change "salt" value used in crypt(2) routine from zero (standard value) to something else. This will confuse standard password-cracking tools that expect a zero-salt value.

An Attacker Profile-Attack Knowledge Required

It was determined that the skills needed by the successful attacker are minimal. The skills needed are those of any of today's computer-literate teen-ager. Such an attacker's knowledge, hardware and software can be limited to the following:

· A computer with network capability (modem installed).

· Ability to obtain hacker programs from friends or from Internet.

· If from Internet, must be able to do a search command. In most cases, this means to click on the search button offered on all Internet service provider systems and type a word such as "hacker," "SATAN", or "computer security." This will eventually lead the attacker to software that can be used to attack a system/network. All tools and vulnerability information used in this risk assessment were found using simple searches via Yahoo!

· Must be able to download the software. This is generally an easy task if attacker simply clicks on the download icon.

· Must be able to locate a system to attack. This can be easily accomplished by downloading "war dialer" software from the Internet. This software calls telephone numbers and documents numbers that are identified as a computer system. An alternative would be to search Internet for systems connected to Internet.

· Must know how to use the software downloaded from Internet or received from a friend. Most of the tools come with documentation.

· Must have working knowledge of how to erase audit trails to cover attack tracks, leave a back door to get back into the system, and modify information stored in a database. To deny service, an attacker must know how to change, delete and/or modify system and database configurations, or spam the system (send the system more information than it c an process, thus tying up the system and making it unavailable to others).

Analysis and Countermeasures

Design Errors:

This deals mostly with situations in which software is used in ways that were never thought of by the original programmers.

In the Unix operating system, when a process abnormally terminates, the memory image of the terminating process, called a "core file, is written to disk. The core file can then be used to determine the reason for the abnormal termination.

Unfortunately, when a privileged process abnormally terminates, the resulting core file may contain images of information that are normally not available to unprivileged users or processes. In most secure Unix systems, the security of the encrypted passwords, against dictionary attacks, is dependent upon the use of a "shadow password" file. Privileged server processes, called daemons, often access the shadow password file to validate access to system resources.

Under Solaris 2.5.1, the Unix used by target system, it is possibl e to access a memory image of the shadow password file by causing the FTP daemon to abnormally terminate. The resulting core file not only contains an image of the shadow password file, but it is readable to all users. An ASCII dump of the core file is sufficient to reveal the image of the shadow password file.

Countermeasures to this vulnerability are to ensure that core files are only readable by users and processes at the same privilege level as the abnormally terminated process, or that core files do not contain images of privileged objects.

Attacks based on other well-known design vulnerabilities were tried, such as the sendmail debug attack, with no obvious success. In fact, a console message was displayed when the sendmail attack was attempted.

Logic Errors:

These errors include coding errors and error handling. The ability to cause the FTP daemon, under Solaris 2.5.1, to abnormally terminate is the result of insufficient error handling.

The "PASV" command is not supported by the Solaris FTP daemon. After returning an "Unsupported Feature" error, the FTP daemon abnormally terminates, causing Solaris to produce a core file. If the FTP daemon had previously accessed the shadow password file, the resulting core file would contain an image of the shadow password file.

The countermeasure for this FTP daemon vulnerability is to ensure that error handling is appropriately processed. If it is necessary for the FTP daemon to terminate, it should do so gracefully.

Compilation Errors:

Vulnerabilities in this category are caused by flaws in the tools used to compile source code, that otherwise is free from any vulnerabilities. Countermeasures to this type of vulnerability are to ensure that compiler tools are free from defect and to include compiler tool versions as part of any software development configuration methodology. No obvious compilation error vulnerabilities were discovered.

Boundary Violations:

Boundary violations occur mostly a s the result of an internal buffer or array overflow. Vulnerabilities of this type depend on the ability to overflow buffers and arrays with executable instructions, in the hope that the instructions will overwrite valid program code. Countermeasures to this kind of vulnerability require the use of boundary checking routines at the time the source code is compiled. Usually, these routines are not used, because they incur a performance penalty at run-time. Because boundary violations based attacks usually occur against privileged processes, perhaps it is possible to limit the use of boundary checking routines to those programs likely to come under attack.

No obvious vulnerabilities of this type were discovered.

Other Countermeasures and Recommendations

Software tools such as SATAN and other software applications that identify system vulnerabilities should be run periodically and after there are any changes to the hardware and software configurations.

Disallow use of the "noauto" option o f X Windows. This will prevent other users from running unauthorized clients on your X Windows server.

Use Data Encryption Standard (DES) authentication to prevent spoofing of users authorized to launch X Windows clients.

Create a zero-length .rhosts file in the user's home directory to prevent a user from creating single sign on access from other systems. Set up a job to create script to check for it, copy it to a secure location, and recreate zero-length file.

Remove development tools such as compilers and linkers from production systems.

Create a network traffic monitoring center. The center can be used to monitor performance of the network and also look for signs of intrusion.

Use Solaris Security report recommendations when installing and configuring the system.

Follow the Computer Emergency Response Team's (CERT) recommendations and install and configure the system with the security vulnerabilities patched.

Test the system for vulnerabilities prior to placing it in operationa l mode.

Use the information contained in the report to train the target system security administrators prior to allowing them to administer system security tasks.