DBSecWorx: Base64 Exploit

Oracle Base64 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. Three of those techniques are the Base64, CAST TO RAW, and the NoSpaces exploits (links at page bottom).

Many of the more sophisticated security tools can now catch these three 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 do the same with the other two exploits. To secure your database you need to intentionally attempt these exploits as part of a sanctioned White Hat attack and see if your environment will alert you.

Exploit Demo

This demo consists of three attempts to execute the same SQL statement. The first is the statement written as it might be by a legitimate developer that wants to write clear, concise, and self-documenting code.

The second performs the exact same action but attempts to evade a security tool's ability to audit and evaluate its intent.

The third example demonstrates why the second example works.

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: / as sysdba

      

      Connected to:

      Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

      Version 19.3.0.0.0

      

      SQL> show user

      USER is "SYS"

      

      DECLARE

       r      RAW(32767);

       sqlStr VARCHAR2(60);

      BEGIN

        r := utl_raw.cast_to_raw('SELECT dummy FROM dual');

        dbms_output.put_line(r);

      

        r := utl_encode.base64_encode(r);

        dbms_output.put_line(r);

      

        execute immediate 
      utl_raw.cast_to_varchar2(utl_encode.base64_decode(r)) INTO sqlStr;

        dbms_output.put_line(sqlStr);

      END;

      /

      53454C4543542064756D6D792046524F4D206475616C

      5530564D52554E55494752316257313549455A53543030675A48566862413D3D

      X

      

      PL/SQL procedure successfully completed.

      
      

      

      DECLARE

       input_raw RAW(60) := '5530564D52554E55494752316257313549455A53543030675A48566862413D3D';

       retVal    VARCHAR2(20);

      BEGIN

        execute immediate utl_raw.cast_to_varchar2(utl_encode.base64_decode(input_raw)) INTO retVal;

        dbms_output.put_line(retVal);

      END;

      /

      X

      

      PL/SQL procedure successfully completed.

      

      

      DECLARE

       r      RAW(32767);

       sqlStr VARCHAR2(60);

      BEGIN

  dbms_output.put_line(r);

        r := utl_raw.cast_to_raw('SELECT dummy FROM dual');

        dbms_output.put_line(r);

      

        r := utl_encode.base64_encode(r);

        dbms_output.put_line(r);

      

        execute immediate 
      utl_raw.cast_to_varchar2(utl_encode.base64_decode(r)) INTO sqlStr;

        dbms_output.put_line(sqlStr);

      END;

      /

      SELECT dummy FROM dual

      53454C4543542064756D6D792046524F4D206475616C

      5530564D52554E55494752316257313549455A53543030675A48566862413D3D

      X

      

      PL/SQL procedure successfully completed.

      

      As easily demonstrated submitting the SQL statement Cast as Raw obscures the intent. At no place in the second example is the statement human readable in a trace or in a V$ dynamic performance view.

Conclusion

Casting strings to BASE64 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.