Database Reference
In-Depth Information
not as an automated method to verify the effectiveness of break-glass access for internal employees. Pre-cloud
consolidation has increased the business value of verifying internal integrity.
In the author's experience it is relatively rare for an external attack to result in a rootkit being installed. However, it is
very common for internal DBAs to have their own informal backdoor to access the systems they work on so as to ensure
that they will not be locked out accidentally, or purposely, by others. This backdoor can preserve availability, but can also
represent a security risk in large networks where multiple administrators move around over time, especially when an
organization's management wishes to exert control over that workforce and the resources they administer. Additionally,
these informal backdoors may be discovered by an attacker. Rootkits have evolved through a number of forms.
Detecting First-Generation Rootkits
First-generation rootkits consist of modifications of structures within the logical structure of the database itself,
typically views and tables—which enable the hiding of a backdoor account—or by the tampering with of procedure
code to grant DBA privilege to an unauthorized account. Traditionally, such rootkits are detected by carrying out a
state check of the SYS schema, as this is where the dictionary tables containing information about user privileges live,
and also where the code that can run as SYS is stored.
An important addition to the SYS schema is the SYSTEM schema, which might not be part of the dictionary but
is able to pass on the DBA role through definer's rights procedures to the invokers of SYSTEM-owned procedures.
SYSTEM is not protected by
07_dictionary_accessibility
and therefore represents a potential escalation path of
similar concern to that of SYS. SYSTEM's DBA role has the
ALTER USER
system privilege and can therefore change the
password for SYS. Thus, we need to state check SYSTEM's objects as well.
A state-checker can either verify only the high-sensitivity objects within the database or do a holistic schema
check. The following query quickly checks for just the state of dbms_assert (used for preventing SQL injection):
SQL> SELECT AVG(dbms_utility.get_hash_value(text,1000000000,power(2,30))) FROM DBA_SOURCE WHERE
OWNER='SYS' and name='DBMS_ASSERT';
AVG(DBMS_UTILITY.GET_HASH_VALUE(TEXT,1000000000,POWER(2,30)))
-------------------------------------------------------------
1576433293
Note that we are using
dbms_utility
because it allows for compatibility on all Oracle versions and is faster for
large state checks.
DBMS_UTILITY.GET_HASH_VALUE
is available on Oracle versions 7, 8, 9, 10, 11, and 12; it is fast but
has different implementation on v7 (different checksum). Hopefully you're not still using Oracle v7 DB, though it was
a vintage year.
DBMS_OBFUSCATION.MD5
is good on 9 and above (not 8) and is cryptographically stronger than
DBMS_UTILITY,
but
it is slower due to the more complex computation.
DBMS_CRYPTO.HASH
is available on 10 and above—now allowing
SHA-2
on 12c
,
as seen below. Great work, Oracle!
What follows is an example of using SHA-2 with a 512-bit hash, which produces a very unique checksum:
SYS@orcl3>select DBMS_CRYPTO.hash(utl_raw.cast_to_raw('Foo'), 5) FROM dual;
DBMS_CRYPTO.HASH(UTL_RAW.CAST_TO_RAW('FOO'),5)
--------------------------------------------------------------------------------
06EF0629ADCC64A6174DC1C40DA26C0E08F384DB24EDCC0B81AE60DEFD376EC640A26ADE24A33AD6
E4CCA794C57DC789
The reason for using stronger checksum algorithms like SHA-2 is due to the malicious creation of
colliding checksums. The notion that an attacker could provide different plaintext that has the same
checksum is well known. See confoo.pl by Dan Kaminsky as a proof of concept for MD5 web pages
:
s3.amazonaws.com/dmk/confoo.pl
Table
15-1
lists the hash functions available in 12c.
