Host Tables - By Database

### Security Auditor's Research Assistant (SARA) Professional (PRO) Report Writer

Green |  | 121

None |  | 80

Red |  | 7

Yellow |  | 1

Brown |  | 33

Figure 1 Host Summary by Color

Host Name | IP Address | Host Type | Green | Red | Yellow | Brown
255.252.132.1 | 255.252.132.1 | Router | 1 | 0 | 0 | 1
lsr-ftp.dummy.security-auditor.com | 255.252.132.70 | SunOS 5.7 | 5 | 3 | 0 | 1
lsr-net.dummy.security-auditor.com | 255.252.132.61 | unknown type | 4 | 0 | 0 | 2

Table 1 Hosts on Subnet 255.252.132

Host Name | IP Address | Host Type | Green | Red | Yellow | Brown
255.253.72.1 | 255.253.72.1 | Router | 1 | 0 | 0 | 1
255.253.72.17 | 255.253.72.17 | unknown type | 0 | 0 | 0 | 1

Table 2 Hosts on Subnet 255.253.72

Host Name | IP Address | Host Type | Green | Red | Yellow | Brown
10s221.dummy.security-auditor.com | 255.253.142.1 | Router | 1 | 0 | 0 | 1
tmagone.dummy.security-auditor.com | 255.253.142.5 | unknown type | 0 | 0 | 0 | 1

Table 3 Hosts on Subnet 255.253.142

Host Name | IP Address | Host Type | Green | Red | Yellow | Brown
255.254.18.1 | 255.254.18.1 | Router | 1 | 0 | 0 | 1
255.254.18.121 | 255.254.18.121 | unknown type | 0 | 0 | 0 | 1
255.254.18.122 | 255.254.18.122 | unknown type | 0 | 0 | 0 | 1
255.254.18.123 | 255.254.18.123 | unknown type | 0 | 0 | 0 | 1
255.254.18.55 | 255.254.18.55 | Windows | 1 | 7 | 0 | 0
dummybank.dummy.security-auditor.com | 255.254.18.146 | IRIX 6 | 6 | 0 | 0 | 2
mge2.dummy.security-auditor.com | 255.254.18.100 | IRIX 6 | 4 | 0 | 0 | 2

Table 4 Hosts on Subnet 255.254.18

Host Name | IP Address | Host Type | Green | Red | Yellow | Brown
255.254.66.1 | 255.254.66.1 | Router | 1 | 0 | 0 | 1
255.254.66.11 | 255.254.66.11 | unknown type | 0 | 0 | 0 | 1
255.254.66.121 | 255.254.66.121 | unknown type | 2 | 0 | 0 | 1
255.254.66.25 | 255.254.66.25 | SunOS 5.6 | 2 | 0 | 0 | 2
255.254.66.26 | 255.254.66.26 | SunOS 5.6 | 2 | 0 | 0 | 2
255.254.66.27 | 255.254.66.27 | SunOS 5.6 | 2 | 0 | 0 | 2
255.254.66.28 | 255.254.66.28 | SunOS 5.6 | 2 | 0 | 0 | 2
255.254.66.37 | 255.254.66.37 | IRIX 6 | 7 | 1 | 0 | 3
255.254.66.6 | 255.254.66.6 | unknown type | 0 | 0 | 0 | 1
255.254.66.7 | 255.254.66.7 | Windows | 3 | 3 | 0 | 0
intra1.dummy.security-auditor.com | 255.254.66.24 | SunOS 5.6 | 2 | 0 | 0 | 2
intratv.dummy.security-auditor.com | 255.254.66.31 | Windows | 1 | 0 | 1 | 0
lens.dummy.security-auditor.com | 255.254.66.30 | Digital UNIX 5 | 5 | 3 | 0 | 0
lsr10.dummy.security-auditor.com | 255.254.66.22 | unknown type | 2 | 2 | 0 | 2
pegasus.dummy.security-auditor.com | 255.254.66.4 | Windows | 5 | 2 | 0 | 2

Table 5 Hosts on Subnet 255.254.66

Host Name | IP Address | Host Type | Green | Red | Yellow | Brown
255.254.127.1 | 255.254.127.1 | Router | 1 | 0 | 0 | 1
255.254.127.2 | 255.254.127.2 | Router | 3 | 0 | 0 | 1

Table 6 Hosts on Subnet 255.254.127

Host Name | IP Address | Host Type | Green | Red | Yellow | Brown
255.255.16.1 | 255.255.16.1 | Router | 1 | 0 | 0 | 1

Table 7 Hosts on Subnet 255.255.16

# Host: 255.252.132.1

### General host information:

  - Host type: Router
  - Subnet 255.252.132
  - Telnet on port 2001 server (GREEN)

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)

# Host: lsr-ftp.dummy.security-auditor.com

### General host information:

  - Host type: SunOS 5.7
  - Subnet 255.252.132
  - FTP server (GREEN)
  - FTP (with Anonymous) server (GREEN)
  - SMTP server (GREEN)
  - Telnet server (GREEN)
  - X Windows server (GREEN)

### Vulnerability information:

  - tooltalk version may be vulnerable to buffer overflow (RED)
  - calendar manager version may be vulnerable to buffer overflow (RED)
  - sadmind version may be vulnerable to buffer overflow (RED)
  - Do you want snmp on Internet (BROWN)
  - rpc.statd is enabled and may be vulnerable (BROWN)

# Host: lsr-net.dummy.security-auditor.com

### General host information:

  - Host type: unknown type
  - Subnet 255.252.132
  - SMB server (GREEN)
  - SMTP server (GREEN)
  - Telnet server (GREEN)
  - WWW server (GREEN)

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)
  - DNS may be vulnerable (BROWN)

# Host: 255.253.72.1

### General host information:

  - Host type: Router
  - Subnet 255.253.72
  - Telnet on port 2001 server (GREEN)

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)

# Host: 255.253.72.17

### General host information:

  - Host type: unknown type
  - Subnet 255.253.72

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)
  - Do you want snmp on Internet (BROWN)

# Host: 10s221.dummy.security-auditor.com

### General host information:

  - Host type: Router
  - Subnet 255.253.142
  - Telnet on port 2001 server (GREEN)

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)

# Host: tmagone.dummy.security-auditor.com

### General host information:

  - Host type: unknown type
  - Subnet 255.253.142

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)
  - Do you want snmp on Internet (BROWN)

# Host: 255.254.18.1

### General host information:

  - Host type: Router
  - Subnet 255.254.18
  - Telnet on port 2001 server (GREEN)

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)

# Host: 255.254.18.121

### General host information:

  - Host type: unknown type
  - Subnet 255.254.18

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)
  - Do you want snmp on Internet (BROWN)

# Host: 255.254.18.122

### General host information:

  - Host type: unknown type
  - Subnet 255.254.18

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)
  - Do you want snmp on Internet (BROWN)

# Host: 255.254.18.123

### General host information:

  - Host type: unknown type
  - Subnet 255.254.18

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)
  - Do you want snmp on Internet (BROWN)

# Host: 255.254.18.55

### General host information:

  - Host type: Windows
  - Subnet 255.254.18
  - SMB MOE server (GREEN)

### Vulnerability information:

  - SMB: Open share at MOE/cd (RED)
  - SMB: Open share at MOE/eddy (RED)
  - SMB: Open share at MOE/letmein (RED)
  - SMB: Open share at MOE/print$ (RED)
  - SMB: Open share at MOE/prom$ (RED)
  - SMB: Open share at MOE/william (RED)
  - SMB: Open share at MOE/wills (RED)

# Host: dummybank.dummy.security-auditor.com

### General host information:

  - Host type: IRIX 6
  - Subnet 255.254.18
  - FTP server (GREEN)
  - NFS server (GREEN)
  - Telnet server (GREEN)
  - WWW server (GREEN)
  - WWW (2077:TCP) server (GREEN)
  - XDM (X login) server (GREEN)

### Vulnerability information:

  - SMTP may be a mail relay (BROWN)
  - rpc.statd is enabled and may be vulnerable (BROWN)

# Host: mge2.dummy.security-auditor.com

### General host information:

  - Host type: IRIX 6
  - Subnet 255.254.18
  - FTP server (GREEN)
  - NFS server (GREEN)
  - Telnet server (GREEN)
  - XDM (X login) server (GREEN)

### Vulnerability information:

  - SMTP may be a mail relay (BROWN)
  - rpc.statd is enabled and may be vulnerable (BROWN)

# Host: 255.254.66.1

### General host information:

  - Host type: Router
  - Subnet 255.254.66
  - Telnet on port 2001 server (GREEN)

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)

# Host: 255.254.66.11

### General host information:

  - Host type: unknown type
  - Subnet 255.254.66

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)
  - Do you want snmp on Internet (BROWN)

# Host: 255.254.66.121

### General host information:

  - Host type: unknown type
  - Subnet 255.254.66
  - Telnet server (GREEN)
  - WWW server (GREEN)

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)
  - Do you want snmp on Internet (BROWN)

# Host: 255.254.66.25

### General host information:

  - Host type: SunOS 5.6
  - Subnet 255.254.66
  - FTP server (GREEN)
  - Telnet server (GREEN)

### Vulnerability information:

  - SMTP may be a mail relay (BROWN)
  - rpc.statd is enabled and may be vulnerable (BROWN)

# Host: 255.254.66.26

### General host information:

  - Host type: SunOS 5.6
  - Subnet 255.254.66
  - FTP server (GREEN)
  - Telnet server (GREEN)

### Vulnerability information:

  - SMTP may be a mail relay (BROWN)
  - rpc.statd is enabled and may be vulnerable (BROWN)

# Host: 255.254.66.27

### General host information:

  - Host type: SunOS 5.6
  - Subnet 255.254.66
  - FTP server (GREEN)
  - Telnet server (GREEN)

### Vulnerability information:

  - SMTP may be a mail relay (BROWN)
  - rpc.statd is enabled and may be vulnerable (BROWN)

# Host: 255.254.66.28

### General host information:

  - Host type: SunOS 5.6
  - Subnet 255.254.66
  - FTP server (GREEN)
  - Telnet server (GREEN)

### Vulnerability information:

  - SMTP may be a mail relay (BROWN)
  - rpc.statd is enabled and may be vulnerable (BROWN)

# Host: 255.254.66.37

### General host information:

  - Host type: IRIX 6
  - Subnet 255.254.66
  - FTP server (GREEN)
  - NFS server (GREEN)
  - SMTP server (GREEN)
  - Telnet server (GREEN)
  - WWW server (GREEN)
  - WWW (2077:TCP) server (GREEN)
  - XDM (X login) server (GREEN)

### Vulnerability information:

  - tooltalk version may be vulnerable to buffer overflow (RED)
  - Is your host a DoS threat? (BROWN)
  - Information from rstatd could help hacker (BROWN)
  - rpc.statd is enabled and may be vulnerable (BROWN)

# Host: 255.254.66.6

### General host information:

  - Host type: unknown type
  - Subnet 255.254.66

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)
  - Do you want snmp on Internet (BROWN)

# Host: 255.254.66.7

### General host information:

  - Host type: Windows
  - Subnet 255.254.66
  - SMB IS~NEIIIS server (GREEN)
  - WWW server (GREEN)
  - WWW (Secure) server (GREEN)

### Vulnerability information:

  - WWW: FrontPage is active & may be vulnerable (http) (RED)
  - WWW: IIS codebrws is active and & be vulnerable (RED)
  - WWW: RDS is active and & be vulnerable (RED)

# Host: intra1.dummy.security-auditor.com

### General host information:

  - Host type: SunOS 5.6
  - Subnet 255.254.66
  - FTP server (GREEN)
  - Telnet server (GREEN)

### Vulnerability information:

  - SMTP may be a mail relay (BROWN)
  - rpc.statd is enabled and may be vulnerable (BROWN)

# Host: intratv.dummy.security-auditor.com

### General host information:

  - Host type: Windows
  - Subnet 255.254.66
  - SMB INTRATV server (GREEN)

### Vulnerability information:

  - No X server access control (YELLOW)

# Host: lens.dummy.security-auditor.com

### General host information:

  - Host type: Digital UNIX 5
  - Subnet 255.254.66
  - FTP server (GREEN)
  - SMTP server (GREEN)
  - Telnet server (GREEN)
  - X Windows server (GREEN)
  - XDM (X login) server (GREEN)

### Vulnerability information:

  - tooltalk version may be vulnerable to buffer overflow (RED)
  - calendar manager version may be vulnerable to buffer overflow (RED)
  - sendmail version may be vulnerable to buffer overflow (RED)
  - Do you want snmp on Internet (BROWN)

# Host: lsr10.dummy.security-auditor.com

### General host information:

  - Host type: unknown type
  - NIS client
  - Subnet 255.254.66
  - NFS server (GREEN)
  - SMTP server (GREEN)

### Vulnerability information:

  - WUFtp pre 2.5 (RED)
  - DNS is vulnerable (RED)
  - Excessive finger information (BROWN)
  - rpc.statd is enabled and may be vulnerable (BROWN)

# Host: pegasus.dummy.security-auditor.com

### General host information:

  - Host type: Windows
  - Subnet 255.254.66
  - NNTP (Usenet news) server (GREEN)
  - SMB IS~PEGASUS server (GREEN)
  - SMTP server (GREEN)
  - WWW server (GREEN)
  - WWW (Secure) server (GREEN)

### Vulnerability information:

  - WWW: FrontPage is active & may be vulnerable (http) (RED)
  - WWW: IIS codebrws is active and & be vulnerable (RED)
  - Is your host a DoS threat? (BROWN)
  - Check nntp for vulnerabilities (BROWN)

# Host: 255.254.127.1

### General host information:

  - Host type: Router
  - Subnet 255.254.127
  - Telnet on port 2001 server (GREEN)

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)

# Host: 255.254.127.2

### General host information:

  - Host type: Router
  - Subnet 255.254.127
  - Telnet on port 2001 server (GREEN)
  - Telnet on port 6001 server (GREEN)
  - Telnet on port 9001 server (GREEN)

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)

# Host: 255.255.16.1

### General host information:

  - Host type: Router
  - Subnet 255.255.16
  - Telnet on port 2001 server (GREEN)

### Vulnerability information:

  - Is your host a DoS threat? (BROWN)

Tutorial - DNS Vulnerabilities

# DNS Vulnerabilities

### Impact

There are numerous vulnerabilities in Domain Name Servers (DNS) that are documented in the CERT Advisories. The two principal areas are:

- A remote intruder can gain root-level access to your name server.
- A remote intruder is able to disrupt normal operation of your name server.

### Problems

BIND 4.9 releases prior to BIND 4.9.7 and BIND 8 releases prior to 8.1.2 do not properly bounds check a memory copy when responding to an inverse query request. An improperly or maliciously formatted inverse query on a TCP stream can crash the server or allow an attacker to gain root privileges.

BIND 4.9 releases prior to BIND 4.9.7 and BIND 8 releases prior to 8.1.2 do not properly bounds check many memory references in the server and the resolver. An improperly or maliciously formatted DNS message can cause the server to read from invalid memory locations, yielding garbage record data or crashing the server. Many DNS utilities that process DNS messages (e.g., dig, nslookup) also fail to do proper bounds checking. BIND 4.9 releases and BIND 8 release prior to 8.2.2 Patch 3 have a variety of security issues. You can review them and BIND Security.

### Resolutions

To resolve these problems, upgrade to BIND 8.2.2. If this is not feasible, you can apply a patch, or use a workaround, described in the various CERT Advisories.

Tutorial - Common Gateway Interface (CGI) Access

# Common Gateway Interface Interface (CGI) Access

### Impact

Older Web server implementations contained CGI scripts that would allow the user to access files and execute commands on the server. However, these scripts did not adequately address security and are exploited to (1) download system and user files, (2) execute commands as the Web administrator and (3) contaminate Web pages.

Several problems with Microsoft Internet Information Servers (IIS) are also addressed here. Many FrontPage installations allow the malicious user to read, delete, and modify pages on an IIS (and other FrontPage supported) sites. Also, many IIS distributions have sample programs enabled that enable the hacker to read, delete, or modify web pages.

A recent (1999) exploit in ColdFusion extensions could enable the malicious user to alter web pages.

### Background

Security vulnerabilities have been reported in numerous CGI scripts, including webdist.cgi, handler.cgi, phf, htmlscript, view-source, and php.cgi. These scripts can provide the malicious user access to data and programs on the Web server host.

Similar vulnerabilities may be present with IIS servers (codebrws and FrontPage) as well as third part add-ons such as ColdFusion. In addition, Microsoft's RDS facility is often exploited through IIS.

### Resolution

Vendor and Web server patches and workarounds to protect against this vulnerability are available from Silicon Graphics Inc., the Apache Group, NCSA, Microsoft, and Allaire (ColdFusion) and should be applied as soon as possible. A workaround to this problem is to remove the execute permissions on the offending scripts to prevent their exploitation. If the scripts are not required, they should be removed from the system.

### Where can I read more about this?

You may read more about this vulnerability in CERT Advisory 97.12. For those interested in reading more about general WWW security and secure CGI programming, visit the World Wide Web Security FAQ.

For a description of the IIS and ColdFusion exploits, go to Phrack Magazine. Information on Frontpage can be found at Microsoft and information on RDS can be found at RDS.

Tutorial - Unprivileged NFS access

# Unprivileged NFS access

### Summary

NFS server executes requests from unprivileged user programs.

### Impact

A malicious user can execute NFS file access requests on behalf of any user.

### Background

When an NFS client host wants to access a remote file or directory, its operating system sends a request to the NFS server. The request specifies, among others, a file identifier, the operation (read, write, change permission, etc.), and the identity of the user on whose behalf the operation is to be done.

By default, the user identity is specified with the UNIX numeric user and group ids. With this scheme, also called AUTH_UNIX, the server simply believes anything that the client sends it.

### The problem

An NFS request is nothing but a network message. Any user can run a program that generates arbitrary NFS requests. Such programs have been available for several years, and writing them does not require unusual programming skills.

When an NFS server accepts requests with AUTH_UNIX authentication from unprivileged user programs, a malicious user can execute file access requests on behalf of any user. Reason: with AUTH_UNIX authentication, the user identity is nothing but a few user and group ID numbers in a network message.

### Fix

The fix is to avoid AUTH_UNIX authentication and to use something that involves cryptography. For example, secure NFS with DES or Kerberos credentials. Unfortunately, many NFS implementations support AUTH_UNIX authentication only. Consult your system documentation.

A partial, but more common, solution is to configure the NFS server, and where possible, the mount daemon, to accept requests only from privileged system programs (such as UNIX kernels), and to reject NFS requests that are sent by unprivileged user programs.

- SunOS 4 administrators modify `/etc/rc.local`
  - `rpc.mountd` (no -n option)
  - `echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem`

- SunOS 5 administrators modify `/etc/system`
  - `set nfs:nfs_portmon = 1`

On other systems, the mountd command-line options differ, and the kernel variable may be called nfsportmon or something similar.

Note: rejecting NFS requests from unprivileged user programs does not protect your servers against malicious superusers or against malicious PC programs.

### Other tips

- Where practical, export file systems read-only.
- Consider blocking ports 2049 (nfs) and 111 (portmap) on your routers.

Tutorial - Portmapper exports

# Portmapper exports

### Summary

NFS file exports via the portmapper.

### Impact

NFS export restrictions can be bypassed.

### Background

In order to perform operations via the NFS network file system protocol, a client host sends NFS requests to the NFS server daemon with:

- an NFS file handle that specifies the target of the operation,
- the operation (lookup, read, write, change permissions),
- the user on whose behalf the request is sent.

When an NFS client host wants to access a remote file system for the first time, it first needs to obtain an NFS file handle. To this end, the client host sends an mount request to the server's mount daemon. The server's mount daemon verifies that the client host has permission to access the requested file system. When the mount daemon grants access, it sends a (directory) file handle back to the NFS client.

### The problem

For efficiency reasons, most NFS export restrictions are enforced by the mount daemon. Individual file access operations are handled by the NFS daemon, and the origin of such requests is examined only in special cases such as remote superuser access.

Instead of talking directly to the mount daemon, a malicious NFS client can ask the server's portmapper daemon to forward the request to the mount daemon. When the mount daemon receives the request from the portmapper, the mount daemon will believe that the request comes from the file server, and not from the malicious client.

When the file server exports file systems to itself (for example, because the server is a netgroup member) the mount daemon grants access and replies with a file handle. The portmapper forwards the handle to the malicious client. From now on, the client can talk directly to the server's NFS daemon to access the directory and all files below it.

### Fix

Run a portmapper (or rpcbind program in case of System V.4) that does not forward mount etc. requests. Consult your vendor's patch list. See also: Cert Advisory 94:15.

### Other tips

- Export file systems read-only where possible.
- Consider blocking ports 2049 (nfs) and 111 (portmap) on your routers.

Tutorial - NIS password file access

# NIS password file access

### Summary

NIS password file access by arbitrary hosts.

### Impact

Allows automated password guessing attacks.

### Background

The NIS (Network Information Service) implements network-wide access to administrative information. Examples of databases (also called NIS maps) that are shared via NIS:

- the password file that describes what users have access to the system,
- the table with names and addresses of hosts on the network,
- electronic mail aliases.

NIS databases are organized in domains. One NIS server can serve multiple NIS domains. In order to perform a query, a client sends a request to a NIS server and specifies

- a NIS domain name,
- the name of the database (NIS map) to be searched,
- a search key.

### The problem

Many NIS implementations provide no access control. Every host that asks for information will receive a reply. In order to perform a query, one needs to know the server's NIS domain name. Often, this name is easy to guess, or it can be obtained via the bootparam network service.

When the local network is accessible from other networks, a remote intruder can collect password file information and run a password guessing program. Many people (including Dan Klein) have demonstrated that people tend to choose passwords that are easy to guess.

### Fix

- Several vendors have added access control to their ypserv implementation. Check your system documentation or vendor patch list. The control file is sometimes called securenets.

### Workarounds

- Run a portmapper with access control.

### Other tips

- Consider blocking ports 111 (portmap) on your network gateway. This makes attacks on NIS and NFS mount daemons much harder.
- Enforce a policy for choosing passwords by installing an alternative passwd command, for example anlpasswd.
- See the Admin Guide to Cracking for an example of why this is a problem.

Tutorial - Possible DoS (fraggle) Problem

# Possible DoS (fraggle) Problem

### Impact

Your machine may be vulnerable to certain types of Denial of Service attacks (Fraggle, Smurf and Papasmurf). These DoS attacks affect Windows 95 and Windows NT 4.0 machines. These attacks will cause a loss of connectivity to the Internet and may slow network activity to a crawl.

### Background

The Fraggle attack, and other attacks of this type, such as Smurf and Papasmurf, is the most recent in the category of network-level attacks against hosts. Smurf, and Smurf type attacks, begin when a hacker sends a large amount of ICMP echo (ping) traffic to a subnet broadcast address ( say, for instance, xxx.xxx.xxx.255 - the 255 number marks this as a broadcast address). This traffic will have a spoofed return address. This spoofed address will be the address of the intended victim of the attack. When individual machines on the network receive the ICMP echo requests, they will reply with an echo reply. These replies will all go to the address spoofed in the original ICMP echo requests. On networks with a large number of systems, the traffic generated could be voluminous indeed. The system which is the victim of the attack (as indicated by the spoofed IP address) quickly becomes overwhelmed by incoming traffic, and will almost certainly lose connectivity to the Internet.

Actually, there are two victims of this type of attack when it is run: the network which is exploited to generate the ICMP traffic (called the intermediary, or "helper" network) and the system indicated by the spoofed IP address.

The Fraggle DoS attack is essentially based on the same concept as the Smurf attack (namely that generating huge amounts of network traffic will disable a machine or cause it to lose connectivity to the Internet), but uses UDP instead of ICMP. Although it is not as serious as some other attacks of this type, it will still generate a huge amount of network traffic. Here is how it works: a hacker is armed with a list of broadcast addresses, to which he/she sends spoofed UDP packets. Usually the packets are directed to port 7 on the target machines, which is the echo port. Other times, it is directed to the chargen port (a port that generates a number of characters when queried). Sometimes a hacker is able to set up a loop between the echo and chargen ports, generating all that much more network traffic (this attack generally works on NT boxes).

The result of this attack is, as stated earlier, a massive amount of traffic on the network. Whole networks may crawl to a stop and individual systems may lose connectivity to the Internet and/or, in some cases, crash.

### The Problem

The Fraggle attack, and its variations, may affect individual machines as well as entire networks. Affected networks and/or systems will become bogged down with large amounts of network traffic, and users on affected systems may lose connectivity to the Internet. The Smurf attack and its many variations have been known to last for a period of hours up to a day or more.

### Resolutions

The key to protecting against, and suppressing these types of attacks, is to ensure that your network will not be used as an intermediary. This may be done by configuring routers to not allow IP directed-broadcast transmissions (on Cisco routers, use the "no ip directed-broadcast" interface command). All routers which provide routing to large multi-access broadcast networks, in other words LANs with more than 5 to 10 devices, should be configured in this way. This resolution is indirect, but is, at this point, the surest method for eliminating these types of attacks.

Unfortunately, there is no sure method for protecting against being the ultimate target for Smurf type attacks. For the Smurf attack, the surest and safest fix is to configure routers to turn away all incoming ICMP packets. Unfortunately, this will render several ICMP dependent services, such as ping and traceroute, unusable. Other router configuration methods do exist, and you may read about them in PSI's Filter Configuration page. Other methods, such as ICMP filtering and dropping excess packets at network border routers, are not foolproof but may help alleviate the symptoms of Smurf type attacks. These methods are described in WinPlanet's Smurf Exploit page, and also in InterNIC rfc2267. If you suspect that you have been the victim of a Smurf attack, you may want to download the Smurf Logger, which will allow you to log future Smurf attacks (and other information, such as the broadcast address being used as the intermediary).

As with the Smurf attack, the Fraggle attack is particularly hard to defend against. Some suggestions include blocking broadcast UDP at the router, and perhaps blocking UDP at all terminal servers as well (to prevent malicious network users from flooding out the network). Read the Smurf information above for more information on router configuration tips and border router packet filtering techniques that may prove useful in defending against these types of attacks.

### Where can I read more about this?

Visit Rootshell to read about the Fraggle and Papasmurf Denial of Service attacks.

You can read more about the Smurf attack at Rootshell's Smurf page. Another good source of information is Craig A. Huegen's Smurf Whitepaper. Be sure to also to read the Smurf information in CERT Advisory 98.01.

To keep abreast of existing and emerging Denial of Service attacks, and other security threats, visit the Microsoft Security Advisor, the Windows Central Bug Site, CERT, and/or ircHelp. If information on a specific attack is not located on these sites, keep checking back as they are updated frequently.

Tutorial - REXD access

# REXD access

### Summary

REXD remote access from arbitrary hosts.

### Impact

A remote intruder can execute commands as any user.

### Background

The rexd service and the on client program implement remote command execution via the network. To the extent that it is possible, the complete client environment, including working directory and environment variables, is made available on the remote system.

### The problem

A request for remote command execution contains, among others, the command to be executed, and a user and group id. By default, the rexd server believes everything that the client sends it. An intruder can exploit the service to execute commands as any user (except perhaps root). The typical rexd server has no protection against abuse: most implementations have no provision for access control, nor do they require that the client uses a privileged network port.

### Fix

- Disable the rexd service. Usually this is accomplished by editing the inetd.conf file, and by sending a HUP signal to the inetd process.
- Some rexd implementations can be configured to use a more secure protocol. Consult your manual pages for details.

### Other tips

- See the Admin Guide to Cracking for an example of why this is a problem.

Tutorial - Mail Relay Problem

# Mail Relay Problem

### Impact

Older versions of the sendmail program did not provide sufficient safeguards against mailcious users sending spam mail through a third party computer. Further, the spam mail will often have a forged source address.

### Background

Until 1999, most implementations of sendmail and its clones provided little checking of source and destination addresses. For example a user on host A could use the sendmail on Host B sending mail to a user on Host C with a source email address from Host D. In other words, A hacker on foo.bar.com would use the sendmail at host1.swip.se to send a message

### Resolution

Vendor and Web server patches and workarounds to protect against this vulnerability are available. If your vendor does not have an upgrade, current versions of sendmail from sendmail.org.

Tutorial - Simple Network Management Protocol (SNMP) Access

# Simple Network Management Protocol (SNMP) Access

### Impact

SNMP provides useful information to the hacker on the characteristics of the target host. In addition, several vendors have poorly protected "private" Management Information Blocks (MIBs) that can control the target.

### Resolution

Determine if your host requires SNMP. On many systems it is installed "out of the box". Unless your enterprise uses SNMP for system management, it may be prudent to simply "turn it off". Check with your vendor on the easiest method for dectivating SNMP.

If SNMP is required, check with your network management group to see if if access can be limited to the enterprise. Routers and firewalls provide this facility.

If SNMP must be available over the Internet, check with the CERT to determine if your configuration may be vulnerable.

SSH Vulnerabilities

# SSH Agent Vulnerabilities

### Impact

This document will detail a vulnerability in the `ssh` cryptographic login program. The vulnerability enables users to use RSA credentials belonging to other users who use the SSH-agent program. This vulnerability may allow a malicious user/hacker on the same local host to login to a remote server as the user utilizing `ssh`.

### Background

Secure Shell, or `ssh`, is a program used to log into another computer over a network, execute commands on a remote machine and move files from one machine to another. It provides strong authentication and secure communications over unsecure communication channels. `ssh` is intended as a replacement for `rlogin`, `rsh` and `rcp`. Additionally, `ssh` provides secure `X` connections and secure forwarding of arbitrary `TCP` connections. Traditional BSD "r" commands, such as `rsh`, `rlogin` and `rcp`, are vulnerable to a variety of different hacker attacks. A user with "root" access to certain machines on the network, or physical access to the network itself, may be able to gain unauthorized access to systems by exploiting various vulnerabilities found in the BSD "r" commands. Also, it may be possible for a malicious user to log all traffic to and from a target system, including keystrokes and passwords. The `X Window System` also has a number of vulnerabilities which may be exploited by hackers. The use of `ssh` helps to correct these vulnerabilities. Specifically, `ssh` protects against these attacks: IP spoofing (where the spoofer is on either a remote or local host), IP source routing, DNS spoofing, interception of cleartext passwords/data and attacks based on listening to `X` authentication data and spoofed connections to an `X11` server.

### The Problem

The `ssh` package includes a program called the `ssh-agent`. The `ssh-agent` manages the RSA keys for the `ssh` program, and is used primarily to help users avoid having to type in their pass phrase every time they wish to use `ssh`, `slogin` or `scp`. When invoked, the `ssh-agent` program creates a mode 700 directory in the /tmp directory, and then creates an AF_UNIX socket in that directory. Later, the user will run a program named `ssh-add`, which adds his or her provate key to the set of keys managed by the `ssh-agent` program. When a user wishes to utilize a program which requires RSA key authentication, the `ssh` client connects to the AF_UNIX socket and asks the `ssh-agent` program for the appropriate key.

The vulnerability lies in the fact that when the `ssh` client connects to the AF_UNIX socket, it is running as super-user, or root, and performs insufficient permissions checking. This makes it possible for users to trick their tt>ssh clients into using credentials belonging to other users. In other words, any users who utilize RSA authentication and use the `ssh-agent` program may have their credentials improperly used by a malicious user, who then may improperly access services or programs on a host machine.

This vulnerability effects the UNIX versions of `ssh` only. Specifically, `ssh` for UNIX versions 1.2.17 through 1.2.21 are vulnerable if installed with default permissions. Versions of `ssh` prior to 1.7.17 are subject to a different (but very similar) attack. Additionally, the F-Secure `ssh` programs, prior to version 1.3.3, are vulnerable to this attack. Version 1.1 of the Windows-based `ssh` client, sold by Data Fellows, Inc. under the F-Secure brand name, and versions 1.0/1.0a of the Macintosh `ssh` client are not vulnerable to this attack. If you are unsure of which version or brand of `ssh` you are running, type "ssh -v" at the command prompt and that information will be given to you by the system. If you are not sure if your version or brand of `ssh` is vulnerable to this type of attack, please contact the appropriate vendor.

### Resolutions

For those using the non-commercial versions of `ssh` for UNIX, this vulnerability may be easily fixed. Simply upgrade to SSH version 1.2.22 or later. For those using the F-Secure `ssh` program, version 1.3.3 fixes this security problem. For those using the Data Fellows `ssh` package, and who have a support contract, the fix for this vulnerability is to upgrade to version 1.3.3, which may be obtained from a local retailer. If you are using the Data Fellows `ssh` package, but do not have a support contract, there is a diff file which should fix this vulnerability. This diff file may be obtained from the Data Fellows SSH Web site.

If the above fixes are not practical, or if administrators wish to use a temporary fix until the above resolutions may be implemented, a workaround to this problem is available. The temporary workaround is for administrators to remove the setuid bit from the `ssh` binary. This will prevent the attack from working, but will also disable a form of authentication documented as rhosts-RSA. For example, if the `ssh` binary is in the /usr/local/bin directory, the following command will remove the setuid bit from the `ssh` binary: "chmod u-s /usr/local/bin/ssh".

### Where can I read more about this?

This vulnerability is outlined in Cert Advisory 93.08. For more information about the noncommercial UNIX versions of `ssh`, be sure to visit SSH Communications Security's SSH Web site. If you are using a commercial version of `ssh` and need more information, please visit Data Fellows, Inc.

SSH Vulnerabilities

# SSH Agent Vulnerabilities

### Impact

This document will detail a vulnerability in the `ssh` cryptographic login program. The vulnerability enables users to use RSA credentials belonging to other users who use the SSH-agent program. This vulnerability may allow a malicious user/hacker on the same local host to login to a remote server as the user utilizing `ssh`.

### Background

Secure Shell, or `ssh`, is a program used to log into another computer over a network, execute commands on a remote machine and move files from one machine to another. It provides strong authentication and secure communications over unsecure communication channels. `ssh` is intended as a replacement for `rlogin`, `rsh` and `rcp`. Additionally, `ssh` provides secure `X` connections and secure forwarding of arbitrary `TCP` connections. Traditional BSD "r" commands, such as `rsh`, `rlogin` and `rcp`, are vulnerable to a variety of different hacker attacks. A user with "root" access to certain machines on the network, or physical access to the network itself, may be able to gain unauthorized access to systems by exploiting various vulnerabilities found in the BSD "r" commands. Also, it may be possible for a malicious user to log all traffic to and from a target system, including keystrokes and passwords. The `X Window System` also has a number of vulnerabilities which may be exploited by hackers. The use of `ssh` helps to correct these vulnerabilities. Specifically, `ssh` protects against these attacks: IP spoofing (where the spoofer is on either a remote or local host), IP source routing, DNS spoofing, interception of cleartext passwords/data and attacks based on listening to `X` authentication data and spoofed connections to an `X11` server.

### The Problem

The `ssh` package includes a program called the `ssh-agent`. The `ssh-agent` manages the RSA keys for the `ssh` program, and is used primarily to help users avoid having to type in their pass phrase every time they wish to use `ssh`, `slogin` or `scp`. When invoked, the `ssh-agent` program creates a mode 700 directory in the /tmp directory, and then creates an AF_UNIX socket in that directory. Later, the user will run a program named `ssh-add`, which adds his or her provate key to the set of keys managed by the `ssh-agent` program. When a user wishes to utilize a program which requires RSA key authentication, the `ssh` client connects to the AF_UNIX socket and asks the `ssh-agent` program for the appropriate key.

The vulnerability lies in the fact that when the `ssh` client connects to the AF_UNIX socket, it is running as super-user, or root, and performs insufficient permissions checking. This makes it possible for users to trick their tt>ssh clients into using credentials belonging to other users. In other words, any users who utilize RSA authentication and use the `ssh-agent` program may have their credentials improperly used by a malicious user, who then may improperly access services or programs on a host machine.

This vulnerability effects the UNIX versions of `ssh` only. Specifically, `ssh` for UNIX versions 1.2.17 through 1.2.21 are vulnerable if installed with default permissions. Versions of `ssh` prior to 1.7.17 are subject to a different (but very similar) attack. Additionally, the F-Secure `ssh` programs, prior to version 1.3.3, are vulnerable to this attack. Version 1.1 of the Windows-based `ssh` client, sold by Data Fellows, Inc. under the F-Secure brand name, and versions 1.0/1.0a of the Macintosh `ssh` client are not vulnerable to this attack. If you are unsure of which version or brand of `ssh` you are running, type "ssh -v" at the command prompt and that information will be given to you by the system. If you are not sure if your version or brand of `ssh` is vulnerable to this type of attack, please contact the appropriate vendor.

### Resolutions

For those using the non-commercial versions of `ssh` for UNIX, this vulnerability may be easily fixed. Simply upgrade to SSH version 1.2.22 or later. For those using the F-Secure `ssh` program, version 1.3.3 fixes this security problem. For those using the Data Fellows `ssh` package, and who have a support contract, the fix for this vulnerability is to upgrade to version 1.3.3, which may be obtained from a local retailer. If you are using the Data Fellows `ssh` package, but do not have a support contract, there is a diff file which should fix this vulnerability. This diff file may be obtained from the Data Fellows SSH Web site.

If the above fixes are not practical, or if administrators wish to use a temporary fix until the above resolutions may be implemented, a workaround to this problem is available. The temporary workaround is for administrators to remove the setuid bit from the `ssh` binary. This will prevent the attack from working, but will also disable a form of authentication documented as rhosts-RSA. For example, if the `ssh` binary is in the /usr/local/bin directory, the following command will remove the setuid bit from the `ssh` binary: "chmod u-s /usr/local/bin/ssh".

### Where can I read more about this?

This vulnerability is outlined in Cert Advisory 93.08. For more information about the noncommercial UNIX versions of `ssh`, be sure to visit SSH Communications Security's SSH Web site. If you are using a commercial version of `ssh` and need more information, please visit Data Fellows, Inc.

Tutorial - Sendmail vulnerabilities

# Sendmail vulnerabilities

### Summary

Assorted sendmail vulnerabilities.

### The problems

With almost every sendmail version that was built before February 1998, a malicious user can gain unauthorized privileges by exploiting newlines in command-line arguments or in the process environment or in buffer overflow attacks. Intruders need to have access to an account on your system to exploit this problem.

### Fix

- Replace sendmail by a more recent version, for example from www.sendmail.org, or use a corrected version from your vendor.
- Follow vendor instructions in the numerous advisories from CERT

### Other tips

- See the Admin Guide to Cracking for an example of why this is a problem.

Tutorial - TFTP file access

# TFTP file access

### Summary

File access via the TFTP service.

### Impact

Unauthorized remote access to system or user files.

### Background

The TFTP (trivial file transfer protocol) service provides remote access to files, without asking for a password. It is typically used for the initialization of diskless computers, of X terminals, or of other dedicated hardware.

### The problem

When the TFTP daemon does not limit access to specific files or hosts, a remote intruder can use the service to obtain copies of the password file or of other system or user files, or to remotely overwrite files.

### Fix

- Restrict TFTP access to only limited subtree of the file system. Consult your tftpd manual pages for details.
- When no access restriction is possible, restrict TFTP access by using a tcp wrapper.

### Other tips

- See the Admin Guide to Cracking for an example of why this is a problem.

Tutorial - WUftpd Vulnerabilities

# Washington University FTP Vulnerabilities

### Impact

Any server running the versions prior to December 1998 of ProFTPD (1.2.0pre1) or of Wuarchive ftpd (2.4.2-academ[BETA-18]). wu-ftpd is installed and enabled by default on most Linux variants such as RedHat and Slackware Linux. ProFTPD is new software recently adopted by many

### Background

There is a general class of vulnerability that exists in several popular ftp servers. Due to insufficient bounds checking, it is possible to subvert an ftp server by corrupting its internal stack space. By supplying carefully designed commands to the ftp server, intruders can force the the server to execute arbitrary commands with root privilege. On most vulnerable systems, the ftpd software is installed and enabled by default.

### Resolution

Currently there are several ways to exploit the ftp servers in question. One temporary workaround against an anonymous attack is to disable any world writable directories the user may have access to by making them read only. This will prevent an attacker from building an unusually large path, which is required in order to execute these particular attacks. The permanent solution is to install a patch from your Vendor, or locate one provided by the Software's author or maintainer. See Appendices A and B for more specific information.

### Where can I read more about this?

You may read more about this vulnerability in CERT Advisory 99.03.

Tutorial - Vulnerable IMAP and POP Versions

# Vulnerable IMAP and POP Versions

### Impact

Remote users may root access on systems running a vulnerable `IMAP` or `POP` that is vulnerable to buffer overflow attacks. Access to an account on the system is not needed to exploit this vulnerability.

### Background

`IMAP` provides remote access to a user's mailbox. It maintains a list of unread as well as read messages so that a user gets the same "view" in a multiple mail client environment.

`POP`is similar to `IMAP` but all received mail is loaded to the mail client. That is, the client connects to the server to download mail that the server is holding for the client. The mail is deleted from the server and is handled offline (locally) on the client machine.

### The Problem

This vulnerability allows remote intruders to execute arbitrary commands under the privleges of the process running the vulnerable IMAP server. If the vulnerable IMAP server is running as root, remote intruders can gain root access.

### Resolution

Install a patch from your vendor or upgrade to the latest version of `IMAP`. If your `POP` server is based on the University of Washington `IMAP` server code, you should also upgrade to the latest version of `IMAP`.

Until you can take one of the above actions, temporarily disable the `POP` and `IMAP` services. On many systems, you will need to edit the `/etc/inetd.conf` file. However, you should check your vendor's documentation because systems vary in file location and the exact changes required (for example, sending the `inetd` process a HUP signal or killing and restarting the daemon).

### Where can I read more about this?

Read more about this vulnerability in CERT Advisory 97.09, CERT Advisory 98.08, and CERT Advisory 98.09.

Tutorial - Windows "Backdoor" Vulnerability

# Windows "Backdoor" Vulnerability

### Summary

Several "trojan horses" have been introduced to the Microsoft Windows environment including Back Oriffice, Netbus, and Netbus II.

### Impact

These "Trojans" allow a malicious user to manipulate a Microsoft Windows system without the knowledge of the legitimate user.

### Problem

Back Oriffice, Netbus, and Netbus II are "Trojan Horse" programs that resemble computer viruses in that they are inadevertantly installed by the user. Once installed, their presence is difficult to detect. These "backdoors" allow the hacker to manipulate the compromised host at will. Data can be compromised or modified.

### Resolution

SARA detects possible signtures of "backdoor" pressence. It is up to you, the user to confirm that the "backdoors" are really present. Refer to the Microsoft Site fro details in confirming the presence of the "backdoors.

Tutorial - Excessive Finger Information

# Excessive Finger Information

### Summary

Certain finger servers, when queried, will release excess data about accounts on the system including who is currently logged on.

### Impact

This excess information could be used as clues for guessing user passwords, determining when the system is idle, and providing indicators when to best attack the system. Many finger servers provide excessive information on users of the system. It may provide a list of users and associated personal information. It also indicates who is logged on. This information can provide the hacker with valuable data to (1) guess poor passwords and (2) determine the optimum time to hack.

### Resolution

There are several methods of limiting finger information. If you don't use finger by disabling it in inetd.conf (then restart the inet daemon). If you need finger for your enterprise, you can install tcp wrappers and limit access.

Tutorial - Hacker Program Found

# Hacker Program Found

### Impact

This advisory indicates that a hacker program has been detected on the scanned host. This advisory will only be generated when SARA is in the extreme attack mode.

### Background

This warning refers to a hacker program called `BNC`, which is a simple program designed to proxy IRC sessions. It is user configurable using the file bnc.conf to set incoming and outgooing ports, user ID, and password. Hackers use this program to prove to their community that they have hacked into the target computer.

### The Problem

This warning does not point out a vulnerability in and of itself. But, it does indicate that the target system may have been compromised, and that a vulnerability may exist on the system. In order to run the `bnc` program, a hacker must have interactive access to the target system.

### Resolution

The first step is to kill the `BNC` program. The next step is to search the system for evidence of a hacker's presence. After determining that a hacker is not currently accessing the system, run a full check of the system to determine how the hacker gained access and eliminate any existing vulnerabilities.

Tutorial - Common Gateway Interface (CGI) Access

# Common Gateway Interface Interface (CGI) Access

### Impact

Older Web server implementations contained CGI scripts that would allow the user to access files and execute commands on the server. However, these scripts did not adequately address security and are exploited to (1) download system and user files, (2) execute commands as the Web administrator and (3) contaminate Web pages.

Several problems with Microsoft Internet Information Servers (IIS) are also addressed here. Many FrontPage installations allow the malicious user to read, delete, and modify pages on an IIS (and other FrontPage supported) sites. Also, many IIS distributions have sample programs enabled that enable the hacker to read, delete, or modify web pages.

A recent (1999) exploit in ColdFusion extensions could enable the malicious user to alter web pages.

### Background

Security vulnerabilities have been reported in numerous CGI scripts, including webdist.cgi, handler.cgi, phf, htmlscript, view-source, and php.cgi. These scripts can provide the malicious user access to data and programs on the Web server host.

Similar vulnerabilities may be present with IIS servers (codebrws and FrontPage) as well as third part add-ons such as ColdFusion.

### Resolution

Vendor and Web server patches and workarounds to protect against this vulnerability are available from Silicon Graphics Inc., the Apache Group, NCSA, Microsoft, and Allaire (ColdFusion) and should be applied as soon as possible. A workaround to this problem is to remove the execute permissions on the offending scripts to prevent their exploitation. If the scripts are not required, they should be removed from the system.

### Where can I read more about this?

You may read more about this vulnerability in CERT Advisory 97.12. For those interested in reading more about general WWW security and secure CGI programming, visit the World Wide Web Security FAQ.

For a description of the IIS and ColdFusion exploits, go to Phrack Magazine.

Tutorial - Vulnerable IMAP and POP Versions

# Vulnerable IMAP and POP Versions

### Impact

Remote users may root access on systems running a vulnerable `IMAP` or `POP` that is vulnerable to buffer overflow attacks. Access to an account on the system is not needed to exploit this vulnerability.

### Background

`IMAP` provides remote access to a user's mailbox. It maintains a list of unread as well as read messages so that a user gets the same "view" in a multiple mail client environment.

`POP`is similar to `IMAP` but all received mail is loaded to the mail client. That is, the client connects to the server to download mail that the server is holding for the client. The mail is deleted from the server and is handled offline (locally) on the client machine.

### The Problem

This vulnerability allows remote intruders to execute arbitrary commands under the privleges of the process running the vulnerable IMAP server. If the vulnerable IMAP server is running as root, remote intruders can gain root access.

### Resolution

Install a patch from your vendor or upgrade to the latest version of `IMAP`. If your `POP` server is based on the University of Washington `IMAP` server code, you should also upgrade to the latest version of `IMAP`.

Until you can take one of the above actions, temporarily disable the `POP` and `IMAP` services. On many systems, you will need to edit the `/etc/inetd.conf` file. However, you should check your vendor's documentation because systems vary in file location and the exact changes required (for example, sending the `inetd` process a HUP signal or killing and restarting the daemon).

### Where can I read more about this?

Read more about this vulnerability in CERT Advisory 97.09, CERT Advisory 98.08, and CERT Advisory 98.09.

Mountd Vulnerabilities

# Mountd Exploit

### Overview:

NFS is a distributed file system in which clients make use of file systems provided by servers. There is a vulnerability in some implementations of the software that NFS servers use to log requests to use file systems.

When a client makes a request to use a file system and subsequently makes that file system available as a local resource, the client is said to "mount" the file system. The vulnerability lies in the software on the NFS server that handles requests to mount file systems. This software is usually called "mountd" or "rpc.mountd."

Intruders who exploit the vulnerability are able to gain administrative access to the vulnerable NFS file server. That is, they can do anything the system administrator can do. This vulnerability can be exploited remotely and does not require an account on the target machine.

On some vulnerable systems, the mountd software is installed and enabled by default.

## Description

NFS is used to share files among different computers over the network using a client/server paradigm. When an NFS client computer wishes to access files on an NFS server, the client must first make a request to mount the file system. There is a vulnerability in some implementations of the software that handles NFS mount requests (the mountd program). Specifically, it is possible for an intruder to overflow a buffer in the area of code responsible for logging NFS activity.

We have received reports indicating that intruders are actively using this vulnerability to compromise systems and are engaging in large-scale scans to locate vulnerable systems.

On some systems, the vulnerable NFS server is enabled by default.

## Impact

After causing a buffer overflow, a remote intruder can use the resulting condition to execute arbitrary code with root privileges.

## Solution

Install a vendor patch.

Consider disabling NFS until you are able to install the patch. In particular, since some systems have vulnerable versions of mountd installed and enabled by default, we recommend you disable mountd on those systems unless you are actively using those systems as NFS servers.

Tutorial - NetBIOS Over the Internet

# NetBIOS over the Internet

### Impact

NETBIOS services were detected by the SARA scan. However, the SAMBA module was not loaded and an active scan of the SMB shares was not possible. This advisory is applicable to both UNIX and Microsoft Windows products.

### The Problem

No actual vulnerability was detected because SARA could not find SAMBA resources.

### Resolution

Where possible, NETBIOS services should be disabled. Where this is not possible, the system administrator should confirm that there are no open SMB shares.

Tutorial - Unrestricted SMB Access

# Unrestricted SMB Access

### Summary

Server Message Block (SMB) files shares are world accessable. SARA could access an SMB share. SARA could do a directory listing of the indicated share. No attempt was made to read or write to the contents of the directories.

### Impact

### The Problem

This vulnerability allows hackers to access files that have been "shared" to the world without the need of a password or special account.

### Fix

Confirm that there are no open shares that allow universal access. This is true for Microsoft Windows and Unix operating SAMBA.

Tutorial - Vulnerable IMAP and POP Versions

# Vulnerable IMAP and POP Versions

### Impact

Remote users may root access on systems running a vulnerable `IMAP` or `POP` that is vulnerable to buffer overflow attacks. Access to an account on the system is not needed to exploit this vulnerability.

### Background

`IMAP` provides remote access to a user's mailbox. It maintains a list of unread as well as read messages so that a user gets the same "view" in a multiple mail client environment.

`POP`is similar to `IMAP` but all received mail is loaded to the mail client. That is, the client connects to the server to download mail that the server is holding for the client. The mail is deleted from the server and is handled offline (locally) on the client machine.

### The Problem

This vulnerability allows remote intruders to execute arbitrary commands under the privleges of the process running the vulnerable IMAP server. If the vulnerable IMAP server is running as root, remote intruders can gain root access.

### Resolution

Install a patch from your vendor or upgrade to the latest version of `IMAP`. If your `POP` server is based on the University of Washington `IMAP` server code, you should also upgrade to the latest version of `IMAP`.

Until you can take one of the above actions, temporarily disable the `POP` and `IMAP` services. On many systems, you will need to edit the `/etc/inetd.conf` file. However, you should check your vendor's documentation because systems vary in file location and the exact changes required (for example, sending the `inetd` process a HUP signal or killing and restarting the daemon).

### Where can I read more about this?

Read more about this vulnerability in CERT Advisory 97.09, CERT Advisory 98.08, and CERT Advisory 98.09.

Tutorial - Common Gateway Interface (CGI) Access

# Common Gateway Interface Interface (CGI) Access

### Impact

Older Web server implementations contained CGI scripts that would allow the user to access files and execute commands on the server. However, these scripts did not adequately address security and are exploited to (1) download system and user files, (2) execute commands as the Web administrator and (3) contaminate Web pages.

Several problems with Microsoft Internet Information Servers (IIS) are also addressed here. Many FrontPage installations allow the malicious user to read, delete, and modify pages on an IIS (and other FrontPage supported) sites. Also, many IIS distributions have sample programs enabled that enable the hacker to read, delete, or modify web pages.

A recent (1999) exploit in ColdFusion extensions could enable the malicious user to alter web pages.

### Background

Security vulnerabilities have been reported in numerous CGI scripts, including webdist.cgi, handler.cgi, phf, htmlscript, view-source, and php.cgi. These scripts can provide the malicious user access to data and programs on the Web server host.

Similar vulnerabilities may be present with IIS servers (codebrws and FrontPage) as well as third part add-ons such as ColdFusion.

### Resolution

Vendor and Web server patches and workarounds to protect against this vulnerability are available from Silicon Graphics Inc., the Apache Group, NCSA, Microsoft, and Allaire (ColdFusion) and should be applied as soon as possible. A workaround to this problem is to remove the execute permissions on the offending scripts to prevent their exploitation. If the scripts are not required, they should be removed from the system.

### Where can I read more about this?

You may read more about this vulnerability in CERT Advisory 97.12. For those interested in reading more about general WWW security and secure CGI programming, visit the World Wide Web Security FAQ.

For a description of the IIS and ColdFusion exploits, go to Phrack Magazine.

Tutorial - FTP Bounce Problem

# FTP Relay Problem

### Impact

Under Construction.

### Background

Under Construction.

### Resolution

Under Construction.

Tutorial - remote shell access

# Remote shell access

### Summary

Remote shell/remote login access from arbitrary hosts.

### Impact

The machine can be taken over by any malicious (super)user on the network.

### The problem

When the remote login/remote shell service trusts every host on the network, a malicious superuser on an arbitrary host can gain access as any user (except perhaps root). Once inside, the intruder can replace system programs or configuration files (such as the password file) and take over the machine.

In addition, there are guest or administrative accounts that might not have passwords protecting the account, which allows anyone to remotely login as that user and gain access to the host.

### Fix

Remove the wildcard (+) from the /etc/hosts.equiv file. Be careful with incorrect implementations.

Delete or disable any accounts without a password from the system or NIS password file.

### Other tips

- Give system accounts such as bin and daemon a non-functional shell (such as /bin/false) and put them in the /etc/ftpusers file so they cannot use ftp.
- See the Admin Guide to Cracking for an example of why this is a problem.

Tutorial - remote shell access

# Remote shell access

### Summary

Remote shell/remote login access from arbitrary hosts.

### Impact

The machine can be taken over by any malicious (super)user on the network.

### The problem

When the remote login/remote shell service trusts every host on the network, a malicious superuser on an arbitrary host can gain access as any user (except perhaps root). Once inside, the intruder can replace system programs or configuration files (such as the password file) and take over the machine.

In addition, there are guest or administrative accounts that might not have passwords protecting the account, which allows anyone to remotely login as that user and gain access to the host.

### Fix

Remove the wildcard (+) from the /etc/hosts.equiv file. Be careful with incorrect implementations.

Delete or disable any accounts without a password from the system or NIS password file.

### Other tips

- Give system accounts such as bin and daemon a non-functional shell (such as /bin/false) and put them in the /etc/ftpusers file so they cannot use ftp.
- See the Admin Guide to Cracking for an example of why this is a problem.

Tutorial - remote shell access

# Remote shell access

### Summary

Remote shell/remote login access from arbitrary hosts.

### Impact

The machine can be taken over by any malicious (super)user on the network.

### The problem

When the remote login/remote shell service trusts every host on the network, a malicious superuser on an arbitrary host can gain access as any user (except perhaps root). Once inside, the intruder can replace system programs or configuration files (such as the password file) and take over the machine.

In addition, there are guest or administrative accounts that might not have passwords protecting the account, which allows anyone to remotely login as that user and gain access to the host.

### Fix

Remove the wildcard (+) from the /etc/hosts.equiv file. Be careful with incorrect implementations.

Delete or disable any accounts without a password from the system or NIS password file.

### Other tips

- Give system accounts such as bin and daemon a non-functional shell (such as /bin/false) and put them in the /etc/ftpusers file so they cannot use ftp.
- See the Admin Guide to Cracking for an example of why this is a problem.

Tutorial - remote shell access

# Remote shell access

### Summary

Remote shell/remote login access from arbitrary hosts.

### Impact

The machine can be taken over by any malicious (super)user on the network.

### The problem

When the remote login/remote shell service trusts every host on the network, a malicious superuser on an arbitrary host can gain access as any user (except perhaps root). Once inside, the intruder can replace system programs or configuration files (such as the password file) and take over the machine.

In addition, there are guest or administrative accounts that might not have passwords protecting the account, which allows anyone to remotely login as that user and gain access to the host.

### Fix

Remove the wildcard (+) from the /etc/hosts.equiv file. Be careful with incorrect implementations.

Delete or disable any accounts without a password from the system or NIS password file.

### Other tips

- Give system accounts such as bin and daemon a non-functional shell (such as /bin/false) and put them in the /etc/ftpusers file so they cannot use ftp.
- See the Admin Guide to Cracking for an example of why this is a problem.

Tutorial - Calendar Manager Version

# Calendar Manager Version

### Summary

rpc.cmsd: A desktop calendar manager program, rpc.cmsd can be exploited through a buffer overflow attack. Possibly, some patched versions are exploitable.

### Impact

A remote intruder can execute commands as root if the buffer overflow attack is successful.

### The problem

The rpc.cmsd program (especially Solaris 2.5.x and 2.6, and IRIX 6.x) is exploitable for remote root access. Versions are vulnerable to a buffer overflow attack where a well crafted pattern could execute arbitrary commands as the root user

### Fix

- Where possible, disable rpc.cmsd in the inetd.conf file.
- Otherwise, patch the system to a version that is not vulnerable to the buffer overflow attack. However, there are reports that even patched versions may be vulnerable.

### Other tips

This vulnerability has not been reported to the public by any of the CERT organizations (as of 07/08/99).

Tutorial - Rusersd/Rstatd Vulnerability

# Rusersd/Rstatd Vulnerability

### Impact

These programs can provide the hacker with valuable information concerning system activity and user population. Please refer to the rstatd and rusersd vulnerabilities.

Tutorial - RPC.STATD access

# rpc.statd access

### Summary

rpc.statd: The NFS support program, rpc.statd can be exploited through a buffer overflow attack.

### Impact

A remote intruder can execute commands as root if the buffer overflow attack is successful.

### The problem

The rpc.statd program is a support program to NFS which supports file locking when requested. Older versions of statd are vulnerable to a buffer overflow attack where a well crafted pattern could execute arbitrary commands as the root user

### Fix

- Where possible (i.e., not using NFS), disable rpc.statd in either the inetd.conf or in one of the rc.d "S" files.
- Otherwise, patch the system to a version that is not vulnerable to the buffer overflow attack.

### Other tips

Refer to the CIAC Bulletin for details.

Tutorial - Rstatd vulnerability

# Rstatd Vulnerability

### Summary

rstatd: This rpc process provides information on a coputer's performance.

### Impact

A hacker could determine trends on system utilization to pre-plan his attack.

### Problem

The rstatd replies to a query with information about the computer'sperformance. By default, this function is available to all network users regardless of access privilege. It provides the hacker with an excellant tool to detrmine the best (i.e., least busy) time to do his work.

### Resolution

- If possible, disable rstatd in inetd.conf or in one of the rc.d S* files. This may be problematic in SUN environments where the permeter is used. Perfmeter requires rstatd, even if the performance monitoring is local.

- If disabling is an issues, configure the portmapper to allow only requests from "friendly sites".

Tutorial - Rusersd Vulnerability

# Rusersd Vulnerability

### Summary

The rusersd process provides a list of users logged on to the computer in a format similar to the local "w" command. This information may be valuable to the hacker since it gives hime positive evidence of user activity. Normally, the hacker would wait until everyone is looged off before we "goes to work".

### Impact

The rusersd program can be a valuable tool since it informs him when "nobody is around".

### The Problem

The rusersd program provides useful information to the hacker in the form of

- when activity is at a low point where the chances of being caught are minimized

- providing information on valid user names

- getting information while minimizing the chances of getting caught.

### Resolution

This vulnerability can be eliminated by:

- Eliminating this service by modifying the inetd configuration file or

- removing a standalone daemon by editing the appropriate /etc/rc.d/S* file.

Tutorial - Sadmind Version

# Sadmind Version

### Summary

sadmind: A Solstice administrator support program, sadmind can be exploited through a buffer overflow attack. Possibly, some patched versions are exploitable.

### Impact

A remote intruder can execute commands as root if the buffer overflow attack is successful.

### The problem

The sadmind program (especially Solaris 2.4, 2.5.x and 2.6) is exploitable for remote root access. Versions are vulnerable to a buffer overflow attack where a well crafted pattern could execute arbitrary commands as the root user.

### Fix

- Where possible, disable sadmind in the inetd.conf file.
- Otherwise, patch the system to a version that is not vulnerable to the buffer overflow attack. However, there are reports that even patched versions may be vulnerable.

### Other tips

To date, there are no bulletins on this exploit.

Tutorial - Sendmail vulnerabilities

# Sendmail vulnerabilities

### Summary

Assorted sendmail vulnerabilities.

### The problems

With almost every sendmail version that was built before February 1998, a malicious user can gain unauthorized privileges by exploiting newlines in command-line arguments or in the process environment or in buffer overflow attacks. Intruders need to have access to an account on your system to exploit this problem.

### Fix

- Replace sendmail by a more recent version, for example from www.sendmail.org, or use a corrected version from your vendor.
- Follow vendor instructions in the numerous advisories from CERT

### Other tips

- See the Admin Guide to Cracking for an example of why this is a problem.

Tutorial - Tooltalk Version

# Tooltalk Version

### Summary

rpc.ttdbserverd: A desktop manager support program, rpc.ttdbserverd can be exploited through a buffer overflow attack. Possibly, some patched versions are exploitable.

### Impact

A remote intruder can execute commands as root if the buffer overflow attack is successful.

### The problem

The rpc.ttdbserverd program (especially Solaris 2.5.x and 2.6, and IRIX 6.x) is exploitable for remote root access. Versions are vulnerable to a buffer overflow attack where a well crafted pattern could execute arbitrary commands as the root user

### Fix

- Where possible, disable rpc.ttdbserverd in the inetd.conf file.
- Otherwise, patch the system to a version that is not vulnerable to the buffer overflow attack. However, there are reports that even patched versions may be vulnerable.

### Other tips

Refer to the CIAC Bulletin for details.

Tutorial - Unprotected account

# Unprotected Account

### Summary

Accounts with simple or no passwords.

### Impact

A unauthorized user could gain access to the system.

### Problem

Some system accounts such as sync, lp, or guest may not have passwords. The hacker can gain access to the system if he exploits one of these accounts. Further, once inside, the hacker may gain root access by employing a local exploit.

### Fix

- Remove the account from the system and/or passwd file.
- Disable these accounts by (1) disabling login, (2) setting the home directory to /dev/null, or (3) setting the default shell to /bin/false.

Tutorial - Unrestricted NFS export

# Unrestricted NFS export

### Summary

File systems exported via NFS to arbitrary hosts.

### Impact

Unauthorized remote access to system and/or user files.

### The problem

When a file system is exported without restriction, an intruder can remotely compromise user or system files, and then take over the machine. Examples:

- An intruder can remotely replace a system program or configuration file.

UNIX-specific examples:

- An intruder can remotely install a .rhosts file to obtain interactive access.
- An intruder can remotely install a .forward file to obtain non-interactive access.

### Fix

- Make sure all file exports specify an explicit list of clients or netgroups.
- Export file systems read-only where possible.

### Other tips

- Some versions of the NFS mount daemon cannot expand large netgroups and will export to the world anyway; see also Cert advisory CA-94:02. Check your vendor patch list.
- In NIS netgroup members, empty host fields are treated as wildcards and cause the mount daemon to grant access to any host.
- Consider blocking ports 2049 (nfs) and 111 (portmap) on your routers.
- See the Admin Guide to Cracking for an example of why this is a problem.

Tutorial - X server access

# X server access

### Summary

X server access from arbitrary hosts.

### Impact

A remote intruder can control the keyboard, mouse and screen.

### Background

The X Window system implements an environment where applications use the network to interact with a user workstation's display, keyboard and mouse. There are two classes of programs:

- The X server: the program that manages the user's workstation display and input devices.
- X clients: the applications that run on the user's workstation or elsewhere in the network.

### The problem

When the X server permits access from arbitrary hosts on the network, a remote intruder can connect to the X server and:

- Read the user's keyboard, including any passwords that the user types,
- Read everything that is sent to the screen,
- Write arbitrary information to the screen,
- Start or terminate arbitrary applications,
- Take control of the user's session.

### Fix

Remove all instances of the xhost + command from the system-wide Xsession file, from user .xsession files, and from any application programs or shell scripts that use the X window system.

### Other tips

- Use the X magic cookie mechanism or equivalent. With logins under control of xdm, you turn on authentication by editing the xdm-config file and setting the DisplayManager*authorize attribute to true.
- When granting access to the screen from another machine, use the xauth command in preference to the xhost command.
- See the Admin Guide to Cracking for an example of why this is a problem.

Tutorial - Unrestricted Modem on the Internet

# Unrestricted Modem on the Internet

### Summary

A live and potentially unrestricted modem has been detected.

### Impact

A remote intruder can anonymously dial anywhere that the phone can call.

### Background

In the past, dialout modems were often placed unprotected on one of a UN*X host's TCP ports to facilitate their use. With the advent of special purpose hardware with built-in protection facilities, as well as extra authentication methods such as S/Key and digital tokens, there is little reason to do this.

### The problem

Anyone can use the modem to dial anywhere, enabling them to attack random targets and incurring you a potentially large phone bill.

### Fix

Disallow unprotected Internet access of the modem by placing it behind a firewall or putting password or other extra authentication methods on it (such as S/Key or digital tokens.)

Tutorial - Unrestricted SMB Access

# Unrestricted SMB Access

### Summary

Server Message Block (SMB) files shares are world accessable.

### Impact

### The Problem

This vulnerability allows hackers to access files that have been "shared" to the world without the need of a password or special account.

### Fix

Confirm that there are no open shares that allow universal access. This is true for Microsoft Windows and Unix operating SAMBA.

Tutorial - writable FTP home directory

# Writable FTP home directory

### Summary

FTP home directory is writable for anonymous users.

### Impact

Remote command execution, remote file substitution.

### The problem

When the FTP home directory of a UNIX host is writable, a remote intruder can upload a .rhosts or .forward file to gain access to the system, or may be able to replace files.

When a PC (DOS or MAC) permits anonymous users write access to its file system, a remote intruder may be able replace arbitrary programs or configuration files, or corrupt the file system by filling it up.

### Fix (UNIX)

- Make sure that the FTP home directory, and all system files and directories below it, are owned by root.
- Make sure that they are not writable by anonymous users. As a rule, no file or directory should be owned by the FTP account.

### Other tips (UNIX)

- Change the login shell of the ftp account to `/bin/false`.
- See the Admin Guide to Cracking for an example of why this is a problem.
- CERT/CC Anomymous FTP configuration guidelines.