Special File/Database Access

Two other methods used to gain access to a system are through special files and
database access.These types of files, although different in structure and function,
exist on all systems and all platforms. From an NT system to a Sun Enterprise
15000 to a Unisys Mainframe, these files are common amongst all platforms.
Attacks against Special Files
The problem of attacks against special files becomes apparent when a user uses
the RunAs service of Windows 2000.When a user executes a program with the
RunAs function,Windows 2000 creates a named pipe on the system, storing the
credentials in clear text. If the RunAs service is stopped, an attacker may create a
named pipe of the same name.When the RunAs service is used again, the credentials
supplied to the process will be communicated to the attacker.This allows
an attacker to steal authentication credentials, and could allow the user to log in
as the RunAs user.Attackers can take advantage of similar problems in UNIX systems. One such
problem is the Solaris pseudo-terminal problems we mentioned previously.Red
Hat Linux distribution 7.1 has a vulnerability in the upgrade portion of the
package. A user upgrading a system and creating a swap file exposes herself to
having swap memory snooped through.This is due to the creation of the swap file
with world-readable permissions. An attacker on a system could arbitrarily create a
heavy load on system memory, causing the system to use the swap file. In doing
so, the attacker could make a number of copies of swap memory at different states,
which could later be picked through for passwords or other sensitive information.
Attacks against Databases
Databases present a world of opportunity to attackers. Fulfilling our human
needs to organize, categorize, and label things, we have built central locations of
www.syngress.com
Classes of Attack • Chapter 2 51
information.These central locations are filled with all sorts of goodies, such as
financial data, credit card information, payroll data, client lists, and so forth.The
thought of insecure database software is enough to keep a CEO awake at night,
let alone send a database administrator into a nervous breakdown. In these days of
post-dot-com crash, e-commerce is still alive and well.And where there is commerce,
there are databases.
Risky Business
Databases are forced to fight a two-front war.They are software, and are therefore
subject to the problems that all software must face, such as buffer overflows, race
conditions, denials of service, and the like. Additionally, databases are usually a
backend for something else, such as a Web interface, graphical user interface tool,
or otherwise. Databases are only as secure as the software they run and the interfaces
they communicate with.
Web interfaces tend to be a habitual problem for databases.The reasons for
this are that Web interfaces fail to filter special characters or that they are
designed poorly and allow unauthorized access, to name only two.This assertion
is backed by the fact that holes are found in drop-in e-commerce packages on a
regular basis.
Handling user-supplied input is risky business. A user can, and usually will,
supply anything to a Web front end. Sometimes this is ignorance on the part of
the user, while other times this is the user attempting to be malicious. Scripts
must be designed to filter out special characters such as the single quote (`), slash
(/), backslash (\), and double quote (“) characters, or this will quickly be taken
advantage of.A front-end permitting the passing of special characters to a
database will permit the execution of arbitrary commands, usually with the permission
of the database daemons.
Poorly designed front-ends are a different story. A poorly designed front-end
will permit a user to interact and manipulate the database in a number of ways.
This can allow an attacker to view arbitrary tables, perform SQL commands, or
even arbitrarily drop tables.These risks are nothing new, but the problems continue
to occur.
Database Software
Database software is an entirely different collection of problems. A database is
only as secure as the software it uses—oftentimes, that isn’t particularly reassuring.
www.syngress.com
52 Chapter 2 • Classes of Attack
For example,Oracle has database software available for several different platforms.
A vulnerability in the 8.1.5 through 8.1.7 versions of Oracle was discovered
by Nishad Herath and Brock Tellier of Network Associates COVERT Labs.
The problem they found was specifically in the TNS Listener program used with
Oracle.
For the unacquainted,TNS Listener manages and facilitates connections to
the database. It does so by listening on an arbitrary data port, 1521/TCP in
newer versions, and waiting for incoming connections. Once a connection is
received, it allows a person with the proper credentials to log into a database.
The vulnerability, exploited by sending a maliciously crafted Net8 packet to
the TNS Listener process, allows an attacker to execute arbitrary code and gain
local access on the system. For UNIX systems, this bug was severe, because it
allowed an attacker to gain local access with the permissions of the Oracle user.
For Windows systems, this bug was extremely severe, because it allowed an
attacker to gain local access with LocalSystem privileges, equivalent to administrative
access.We discuss code execution in the next section.
SECURITY ALERT!
Oracle is not the only company with the problem described in this section.
Browsing various exploit collections or the SecurityFocus vulnerability
database, one can discover vulnerabilities in any number of
database products, such as MySQL and Microsoft SQL. And although this
may lead to the knee-jerk reaction of drawing conclusions about which
product is more secure, do not be fooled. The numbers are deceptive,
because these are only the known vulnerabilities.
Database Permissions
Finally, we discuss database permissions.The majority of these databases can use
their own permission schemes separate from the operating system. For example,
version 6.5 and earlier versions of Microsoft’s SQL Server can be configured to
use standard security, which means they use their internal login validation process
and not the account validation provided with the operating system. SQL Server
ships with a default system administrator account named SA that has a default
null password.This account has administrator privileges over all databases on the
entire server. Database administrators must ensure that they apply a password to
the SA account as soon as they install the software to their server.
Databases on UNIX can also use their own permission schemes. For example,
MySQL maintains its own list of users separate from the list of users maintained
by UNIX. MySQL has an account named root (which is not to be confused with
the operating system’s root account) that, by default, does not have a password. If
you do not enter a password for MySQL’s root account, then anyone can connect
with full privileges by entering the following command:
mysql –u root
If an individual wanted to change items in the grant tables and root was not
passworded, she could simply connect as root using the following command:
mysql –u root mysql
Even if you assign a password to the MySQL root account, users can connect
as another user by simply substituting the other person’s database account name
in place of their own after the –u if you have not assigned a password to that particular
MySQL user account. For this reason, assigning passwords to all MySQL
users should be a standard practice in order to prevent unnecessary risk.

0 comments: