Security Auditor's Research Assistant (SARA) Professional (PRO)
Report Writer
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
Table 3 Hosts on Subnet 255.253.142
Table 4 Hosts on Subnet 255.254.18
Table 5 Hosts on Subnet 255.254.66
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
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.
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.
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.
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.
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.
NFS server executes requests from unprivileged user programs.
A malicious user can execute NFS file access requests on behalf of any user.
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.
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.
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.
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.
NFS file exports via the portmapper.
NFS export restrictions can be bypassed.
In order to perform operations via the NFS network file system
protocol, a client host sends NFS requests to the NFS server daemon
with:
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.
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.
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.
NIS password file access by arbitrary hosts.
Allows automated password guessing attacks.
The NIS (Network Information Service) implements network-wide access to
administrative information. Examples of databases (also called NIS maps)
that are shared via NIS:
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
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
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.
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.
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.
REXD remote access from arbitrary hosts.
A remote intruder can execute commands as any user.
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.
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.
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.
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
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.
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.
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.
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.
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.
Assorted sendmail vulnerabilities.
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.
Other tips
File access via the TFTP service.
Unauthorized remote access to system or user files.
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.
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.
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
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.
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.
You may read more about this vulnerability in
CERT Advisory 99.03.
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.
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.
POPis 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.
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.
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.
Several "trojan horses" have been introduced to the Microsoft Windows
environment including Back Oriffice, Netbus, and Netbus II.
These "Trojans" allow a malicious user to manipulate a Microsoft Windows
system without the knowledge of the legitimate user.
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.
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.
Certain finger servers, when queried, will release excess data about accounts
on the system including who is currently logged on.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
POPis 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.
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.
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.
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.
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.
After causing a buffer overflow, a remote intruder can use the
resulting condition to execute arbitrary code with root privileges.
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.
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.
No actual vulnerability was detected because SARA could not find SAMBA resources.
Where possible, NETBIOS services should be disabled. Where this is not possible, the
system administrator should confirm that there are no open SMB shares.
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.
This vulnerability allows hackers to access files that have been "shared"
to the world without the need of a password or special account.
Confirm that there are no open shares that allow universal access. This
is true for Microsoft Windows and Unix operating SAMBA.
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.
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.
POPis 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.
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.
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.
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.
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.
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.
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.
Under Construction.
Under Construction.
Under Construction.
Remote shell/remote login access from arbitrary hosts.
The machine can be taken over by any malicious (super)user on the network.
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.
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.
Remote shell/remote login access from arbitrary hosts.
The machine can be taken over by any malicious (super)user on the network.
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.
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.
Remote shell/remote login access from arbitrary hosts.
The machine can be taken over by any malicious (super)user on the network.
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.
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.
Remote shell/remote login access from arbitrary hosts.
The machine can be taken over by any malicious (super)user on the network.
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.
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.
rpc.cmsd: A desktop calendar manager program, rpc.cmsd can
be exploited through a buffer overflow attack. Possibly, some patched
versions are exploitable.
A remote intruder can execute commands as root if the buffer overflow
attack is successful.
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
These programs can provide the hacker with valuable information concerning
system activity and user population. Please refer to the
rstatd and
rusersd vulnerabilities.
rpc.statd: The NFS support program, rpc.statd can be exploited through
a buffer overflow attack.
A remote intruder can execute commands as root if the buffer overflow
attack is successful.
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
rstatd: This rpc process provides information on a coputer's performance.
A hacker could determine trends on system utilization to pre-plan his
attack.
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.
A live and potentially unrestricted modem has been detected.
A remote intruder can anonymously dial anywhere that the
phone can call.
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.
Anyone can use the modem to dial anywhere, enabling them to attack
random targets and incurring you a potentially large phone bill.
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.)
Server Message Block (SMB) files shares are world accessable.
This vulnerability allows hackers to access files that have been "shared"
to the world without the need of a password or special account.
Confirm that there are no open shares that allow universal access. This
is true for Microsoft Windows and Unix operating SAMBA.
FTP home directory is writable for anonymous users.
Remote command execution, remote file substitution.
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.