Database Reference
In-Depth Information
This checksum has been tested to ensure it will be constant on multiple installs and will change if the code to
dbms_utility is changed, which is what we want (remember the new dbms_utility will move up the data file, and
pcregrep will move down the file). The above is an excellent check to add to our cron-based rootkit checker.
Of course, the checksum approach will not work on encrypted data files such as those produced by Oracle's TDE
option. TDE is useful for protecting the DB data from modification from the OS directly and for securing backups
of those data files. In this case, the interesting point is that by encrypting a data file we have actually made it more
difficult to check the integrity of that data file. The compromise between secrecy and integrity harks back to BLP and
BIBA data security hierarchies discussed earlier.
Further Work
We could cope with TDE by making this rootkit checker more advanced by specifically locating the exact object within
the data file, achieved by reverse engineering the structure of the data file. In preparing to do that, keep in mind that
Oracle data files have the following logical structure:
Tablespace > Segment > Extent > Block
Think in terms of “BEST” backwards—B for block, E for Extent, and so forth.
If we have the block size of the data files then we can use the information in dba_segments and dba_extents
to predict the position of objects such as dbms_utility . Note the object name is in the segment_name column of
dba_segments and dba_extents. Segment_name joins those two relations. This excellent article gives an example of
the process: http://kamranagayev.com/2011/10/31/ .
Additionally, we could run the data file through the split command and then state check each portion of the data
file to see which blocks change when a package is updated. This gives us a heuristic mapping of change within the
data file. Lastly, we could use the encryption key to encrypt the data file and then use strings as before. If you are
interested in a TDE version of rootkit checker then you are welcome to contact the author directly.
Separate from encryption, other considerations are:
Editions - These allow different versions of the same PL package.
Dependencies - Consider state-checking the dependencies called from a package, e.g.,
what procedures does DBMS_UTILITY call within its code? DBA_DEPENDENCIES view can be
used to find these dependencies, but for high-level security a source-code review of the
actual PL would be preferable.
Unfortunately, the source code to built-in packages like DBMS_UTILITY is actually wrapped so that it cannot be
read. This is another example of where secrecy makes a system less safe. However, it is now relatively easy to unwrap
procedures for 10g, 11g, and 12c as they use the same, slightly simpler, algorithm than 9i. In fact, the following website
is known for allowing folks to do this online: http://www.codecrete.net/UnwrapIt/ . Using this site is handy for code
review or for recovering lost source code. Don't use it for helping yourself to someone else's intellectual property, and
remember that the way in which Oracle does its wrapping is the intellectual property of Oracle Corp.
If you need to wrap PL/SQL more securely than Oracle provides for, Pete Finnigan sells a tool named PFCL
Obfuscate that protects PL: http://www.pfclobfuscate.com/ . This tool is not currently downloadable, nor is it open
source or GPL, which implies a lack of confidence in its ability to protect against reverse engineering. However, I
have seen it demonstrated, and in this niche I believe it to be the best product available. PFCL Obfuscate can protect
against an attacker unwrapping the crypto key for credit cards—though in-memory attacks will still be an issue, as
previously discussed.
 
Search WWH ::




Custom Search