oracle 密码详解以及破解

参考的相关资料等：

https://docs.oracle.com/en/database/oracle/oracle-database/18/spmsu/finding-and-resetting-user-passwords-10g-password-version.html#GUID-D7B09DFE-F55D-449A-8F8A-174D89936304

http://marcel.vandewaters.nl/oracle/security/password-hashes

https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/changes-in-oracle-database-12c-password-hashes/

实验环境：

oracle:11.2.4环境升级到了19C

一.Oracle密码记录以及大小写敏感和优先级

在10G版本的时候，11g前建的用户密码是不区分大小写的，用户密码存在dba_users视图中，在11.1之前的版本,可以通过alter user identified by values password 来还原oracle 数据库历史密码(当年在电网运维做二级等保的时候，就发现了10g,11g重置密码不一样),但是在11g以及以上版本中出现一下特性：

1. dba_users中无password记录（值为空)，这个可以通过直接查询user$.password依然有记录。

2.通过修改USER$.SPARE4为空实现了屏蔽ORACLE 11g，12C以及以上版本密码大小写敏感（password_versions优先级大于sec_case_sensitive_logon）

如下：

col name for a20
col password for a40
col spare4 for a40
select name,password,SPARE4 from user$ WHERE name=\’SYSTEM\’;

SELECT a.username,a.password_versions FROM dba_users a WHERE a.username=\’SYSTEM\’;

该PASSWORD_VERSIONS列显示该帐户存在的密码版本的列表。10G指的是较早的不区分大小写的Oracle密码版本，11G指的是基于SHA-1的密码版本，并12C指的是基于SHA-2的SHA-512密码版本。

本次测试用户SYSTEM的SPARE4为空,从低版本(10g)导入到11g中的用户登录是不区分大小写,而11g本身创建的用户是区分大小写(默认sec_case_sensitive_logon为true,区分大小写),而他们的区别仅仅是在dba_users.password_versions为10G,USER$.SPARE4列为空(10g的该列为空)，说明sec_case_sensitive_logon 根本没有起到作用；

ALTER USER system PASSWORD EXPIRE;  --登陆提示修改密码或者直接执行修改密码(我是直接修改密码的)
alter user system identified by "oracle";

重置密码后，dba_users.password_versions变成10G 11G 12C了；SPARE4有值了。
在测试重新登录：

等我把SPARE4修改成空值后再试一下：

select name,password,SPARE4 from user$ WHERE name=\’SYSTEM\’;

UPDATE user$ a SET a.spare4=\’\’ WHERE name=\’SYSTEM\’;
COMMIT;
select name,password,SPARE4 from user$ WHERE name=\’SYSTEM\’;

alter system flush shared_pool;

综上所述，说明password_versions（变成了10g,11g,12C）的优先级大于sec_case_sensitive_logon这个参数，在sec_case_sensitive_logon下（还是为true），如果我修改了USER$.SPARE4(为空),可以实现不区分密码大小写的问题；

spare4 可以进行密码刷新：既可以用USER$中的PASSWORD，也可以用USER$中的SPARE4

12C:

SELECT \’ alter user \’ || NAME || \’ identified by values \’\’\’ ||B.SPARE4 || \’\’\’;\’ AS reset_password
FROM SYS.USER$ B
INNER JOIN DBA_USERS A
ON B.NAME = A.USERNAME
WHERE ACCOUNT_STATUS = \’OPEN\’
and a.username<>\’SYS\’
and b.spare4 is not null;

11g:

select \’ alter user \’ || name ||\’ identified by values \’\’\’||password ||\’\’\’;\’ from sys.user$
where name in (select username from dba_users
where ACCOUNT_STATUS<>\’LOCK\’ and ACCOUNT_STATUS not like \’EXPIRED%LOCKED\’);

但是通过测试values user$.spare4恢复以前密码后,user$.password列为空（SYS用户除外，其他用户为空，且由于12.2之后 ORACLE 口令文件，存放至ASM里面，因此无法再通过alter user sys identified by \’values\’重置SYS密码,登陆提示密码错误，如果用user$.password重置密码，那么spare4为空，且PASSWORD_VERSIONS版本会下降成10g,就不会区分大小写了）,但是密码依旧区分大小写。这里可以看出来，user$.password项以后可能取消掉,为了兼容性,因此Oracle在后续版本中依旧保留.

二.oracle用户密码的加密方法

10g中使用基于DES的版本,在11g中，它使用基于SHA1密码的版本，从11g第1版开始的区分大小写的密码，在12c中使用基于SHA-2的SHA-512密码版本，Oracle在Oracle Database 12c中对用户密码哈希进行了改进。通过使用基于PBKDF2的SHA512哈希算法，替代过去简单的SHA1哈希加密，使得密码哈希更安全。

2.1 10g哈希的过程

将用户名转换为用户名的大写版本（用户名sys变为SYS）
将密码转换为密码的大写版本（密码测试变为TEST）
缩写的用户名和密码（用户名SYS，密码TEST变为SYSTEST）
使用（永久-始终相同）密钥对（使用3DES算法的）隐式值进行加密
使用秘密密钥加密（使用3DES算法）隐含值（此密钥是第一次加密的最后8个字节）
实际的密码哈希值将是第二轮加密的最后8个字节，以这8个字节的可读十六进制表示形式存储-因此为16个字符）

2.2 11g哈希的过程

Oracle生成一个10字节的SALT（看起来是随机的）
密码（区分大小写）和SALT（10字节）的值变为无效
生成SHA1哈希值作为隐含值
11g密码哈希变为：“ S：”加< SHA1哈希-可读的十六进制表示形式>加< SALT-可读的十六进制表示形式，20个字符>

2.3 12C哈希的过程

Oracle 对 Oracle Database 12c 中的用户密码哈希进行了改进。通过使用基于 PBKDF2 的 SHA512 散列算法，而不是简单的 SHA1 散列，密码散列更加安全。对于 Oracle 数据库 11g，表列sys.user$中的spare4 存储用户密码哈希。

create user demo identified by epsilon;
select spare4 from sys.user$ where name = \'DEMO\';

select password from sys.user$ where name = \’DEMO\’;

spare4为：

S:50C53B964CACCA700E7B751778985731F605D97C8D5CA32736AAD3A912D9;T:A0A64DCB72163A1
81B123131B7FAE450628103507607E7EF4BEA88D7FA6762B238ABDA7027EFD1436F0AFAC2AFF8DB3
BB17CB0D0A85358D195CD619C84F3969894B02274CAF970584059A7C09565C1F0

sys.user$.password为：

2B7983437FE9FEB6（大写并连接用户名和密码，然后进行 3DES 散列计算）

该spare4 列的值有三个部分（“ S:‘‘ H:’和’ T:”）用分号隔开；然而，我在用19c测试的时候，已经没有H:部分了。只有S:和T:部分。

“ S:”部分长度为 60 个字符或 30 个字节：

50C53B964CACCA700E7B751778985731F605D97C8D5CA32736AAD3A912D9

在 Oracle 数据库 11g 中有“ S:”部分，它的创建方式如下：

password hash (20 bytes) = sha1(password + salt (10 bytes))

Oracle Database 12c 也是如此：下面的简单测试证明了这一点。

对于S 上述 ( 50C53B964CACCA700E7B751778985731F605D97C8D5CA32736AAD3A912D9) 中的值：

哈希是50C53B964CACCA700E7B751778985731F605D97C8D5CA32736AAD3A912D9

密码是“ epsilon”，所以计算 SHA1 哈希值\'epsilon\' + 8D5CA32736AAD3A912D9：

import hashlib
sha1 = hashlib.sha1()
sha1.update(“epsilon”)
sha1.update(\’\x8D\x5C\xA3\x27\x36\xAA\xD3\xA9\x12\xD9\’)
sha1.hexdigest().upper()

该计算产生：

\’ 50C53B964CACCA700E7B751778985731F605D97C8D5CA32736AAD3A912D9\’

这与 11g 算法相同。

” H:” 部分长度为 32 个字符或 16 个字节：（19c没有）

H部分

在查看下$ORACLE_HOME/rdbms/admin 一个SQL 文件时可以发现这一点：

create or replace view DBA_DIGEST_VERIFIERS
(USERNAME, HAS_DIGEST_VERIFIERS, DIGEST_TYPE) as
select u.name, \'YES\', \'MD5\' from user$ u where instr(spare4, \'H:\')>0
union
select u.name, \'NO\', NULL from user$ u where not(instr(spare4, \'H:\')>0) or spare4 is null
/

所以它似乎是一个 MD5 哈希。

请注意，下面有 SQL 代码$ORACLE_HOME/rdbms/admin 修改spare4 列的值以删除H: 降级。

这是如何spare4.H 计算的：用户名是大写的，然后从中计算出 MD5 哈希值，并且 \’ XDB\’ 和密码用冒号分隔：

import hashlib
m = hashlib.md5()
m.update(\'DEMO:XDB:epsilon\')
m.hexdigest().upper()
\'DC9894A01797D91D92ECA1DA66242209\'

这使得可以使用预先计算的哈希值来攻击内置用户密码，这些哈希值以诸如“ SYSTEM:XDB:”之类的常量为前缀的字典单词。

该H 值似乎用于 XDB 中的摘要式身份验证。

“ T:”部分长度为 160 个字符或 80 个字节：

A0A64DCB72163A1
81B123131B7FAE450628103507607E7EF4BEA88D7FA6762B238ABDA7027EFD1436F0AFAC2AFF8DB3
BB17CB0D0A85358D195CD619C84F3969894B02274CAF970584059A7C09565C1F0

让我们仅通过更新sqlnet.ora 文件来启用 12c 密码哈希（假设客户端也来自 12.1.0.2 发行版）：

# sqlnet.ora
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 12a

drop user demo;

create user demo identified by epsilon;

select spare4 from sys.user$ where name = \’DEMO\’;

H:DC9894A01797D91D92ECA1DA66242209;T:E3243B98974159CC24FD2C9A8B30BA62E0E83B6CA2FC7C55177C3A7F82602E3BDD17CEB9B9091CF9DAD672B8BE961A9EAC4D344BDBA878EDC5DCB5899F689EBD8DD1BE3F67BFF9813A464382381AB36B

请注意，该spare4 值不再具有S: 部件，只有T: 组件在那里。

关于 12C 验证器

基于涉及 PBKDF2 和 SHA512 的去优化算法…

所以密码应该通过 PBKDF2 处理，然后是 SHA512 以生成T.

在身份验证期间，服务器向客户端发送所谓的AUTH_VFR_DATA （匹配值的最后 16 个字节spare4.T ）：

-- Server to client packet snippet
39 39 39 00 00 00 00 0D-00 00 00 0D 41 55 54 48 999.........AUTH
5F 56 46 52 5F 44 41 54-41 20 00 00 00 20 38 44 _VFR_DATA.....8D
44 31 42 45 33 46 36 37-42 46 46 39 38 31 33 41 D1BE3F67BFF9813A
34 36 34 33 38 32 33 38-31 41 42 33 36 42 15 48 464382381AB36B.H

所以我们可以将T 值分成两部分（前 64 个字节和AUTH_VFR_DATA）：

E3C3E63EFDC9CC837FBF7BFC2225B5E6CF0273C6B3C02BE0C7501A29E4A79FC0172132661D9135D79F2A514BD72028AF77157DEEB8983993EA93067771760FFF（前 128 个字符或 64 个字节）
2029784967FA795BBF7D3E1699D5F30F（后 32 个字符或 16 个字节 – AUTH_VFR_DATA）

让我们假设AUTH_VFR_DATA 密码是设置/重置时随机生成的。因此，生成前 64 个字节的 Python 代码T 是（需要PBKDF2 Python 模块）：

import pbkdf2, hashlib

AUTH_VFR_DATA = b\’\x8d\xd1\xbe\x3f\x67\xbf\xf9\x81\x3a\x46\x43\x82\x38\x1a\xb3\x6b\’ # This is received from the server once the latest protocol is negotiated

salt = AUTH_VFR_DATA + b\’AUTH_PBKDF2_SPEEDY_KEY\’

key = pbkdf2.PBKDF2(“epsilon”, salt, 4096, hashlib.sha512) # Password

key_64bytes = key.read(64) # This 64-byte derived key is encrypted by the client and sent to the server as AUTH_PBKDF2_SPEEDY_KEY

t = hashlib.sha512() # This happens on the server after they key is decrypted from the AUTH_PBKDF2_SPEEDY_KEY value

t.update(key_64bytes)

t.update(AUTH_VFR_DATA)

t.hexdigest().upper() # First 64 bytes of spare4.T: value if password is correct

运行结果：

E3243B98974159CC24FD2C9A8B30BA62E0E83B6CA2FC7C55177C3A7F82602E3BDD17CEB9B9091CF9DAD672B8BE961A9EAC4D344BDBA878EDC5DCB5899F689EBD