Oracle NoSpaces 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 two 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.
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"


-- the following SQL can be parsed by essentially all monitoring tools.

SQL> SELECT table_name, index_name FROM dba_indexes WHERE rownum < 11;

TABLE_NAME                     INDEX_NAME
------------------------------ ------------------------------
ACCESS$                        I_ACCESS1
ACLMV$                         I_ACLMV$_1
ACLMVREFSTAT$                  I_ACLMVREFSTAT$_1
ACLMVSUBTBL$                   I_ACLMVSUBTBL$_1
ADMINAUTH$                     I_ADMINAUTH1
ADO_IMPARAM$                   C_ADO_IMPARAM
ADO_IMSEGTASKDETAILS$          I_ADOIMSEGTD_ID
ADO_IMSEGTASKDETAILS$          I_ADOIMSEGTD_OBJ
ADO_IMTASKS$                   I_ADOIMTASKS_ID
ALERT_QT                       SYS_IL0000019765C00071$$

10 rows selected.

-- monitoring tools will have varying levels of success with this statement

SQL> SELECT/**/table_name,/**/index_name/**/FROM/**/dba_indexes/**/WHERE rownum<11;

TABLE_NAME                     INDEX_NAME
------------------------------ ------------------------------
ACCESS$                        I_ACCESS1
ACLMV$                         I_ACLMV$_1
ACLMVREFSTAT$                  I_ACLMVREFSTAT$_1
ACLMVSUBTBL$                   I_ACLMVSUBTBL$_1
ADMINAUTH$                     I_ADMINAUTH1
ADO_IMPARAM$                   C_ADO_IMPARAM
ADO_IMSEGTASKDETAILS$          I_ADOIMSEGTD_ID
ADO_IMSEGTASKDETAILS$          I_ADOIMSEGTD_OBJ
ADO_IMTASKS$                   I_ADOIMTASKS_ID
ALERT_QT                       SYS_IL0000019765C00071$$

10 rows selected.

-- as easily demonstrated the "slash-star" text "star=slash" comment notation is translated by SQL*Plus to a space.
-- the statement is syntactically valid and executes.
 
Conclusion
The Oracle Database interprets the comment tags /* and */ back-to-back as a single white space. It is far easier to trap for the keyword "SELECT" and "FROM" than it is to instring these words from the interior of a long string.

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.

Related Topics
Base64 Exploit
Cast To RAW Exploit