Trojans - Implementing Database Security and Auditing - page 278

appear in its entirety so that you may preempt any Trojans injected into the
database by a developer.

9.6 Monitor creation of traces and event monitors

Every database has features for creating monitors and trace events that
occur in the system. Some of these features are part of the database auditing
features, and some are additional features that you can use in an audit ini-
tiative but that are also used for other purposes—e.g., performance tuning
and functional enhancements to existing applications. These monitors and
events are powerful and, as such, can also be used by the wrong people to
do things you may not expect. Therefore, you should take extra precautions
and monitor the creation of monitor events and traces.
Some of the worst Trojans in the history of Windows have been Trojans
that captured keyboard events and communicated them to an attacker. In
the same way, database event monitors and traces (if injected correctly) can
continuously tell an attacker many things about the database, including
usernames, terminal information, application information, and even pass-
words in some cases. In fact, on some platforms these event monitors and
traces can be used to spy on any activity inside the database. Therefore, you
should monitor and audit any creation and modification of these traces.

9.6.1 Anatomy of the vulnerability: Setting up an

event monitor or a trace

Let's start with a DB2 UDB example, in which an attacker can use the
event monitor function to collect information about user sign-on activities.
All the attacker needs is to be able to run a CREATE EVENT MONITOR
command that takes the following form:

CREATE EVENT MONITOR trojan
FOR CONNECTIONS WRITE TO TABLE CONNHEADER
(TABLE CONNHEADER_trojan,
INCLUDES (AGENT_ID,
APPL_ID,
APPL_NAME,
AUTH_ID,
CLIENT_DB_ALIAS,
CLIENT_NNAME,
CLIENT_PID,
CLIENT_PLATFORM,
CLIENT_PRDID,