参考的相关资料等:
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有值了。
在测试重新登录:
![](https://img2020.cnblogs.com/blog/1339563/202012/1339563-20201218150217547-1727735997.png)
等我把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('x8Dx5CxA3x27x36xAAxD3xA9x12xD9')
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'x8dxd1xbex3fx67xbfxf9x81x3ax46x43x82x38x1axb3x6b' # 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
加起来
Oracle 在 12c 中添加了 MD5 哈希和基于 PBKDF2 的 SHA512 哈希。
Oracle 12C验证器存在,通过抓包,可以通过暴力破解来获取Oracle的密码,有关抓包的信息请自行查找。
三.oracle密码的破解
首先,如果在生产上有权限做相关的操作,不太建议做这种不道德的事情,但是测试环境做一下是可以的
很多网上的破解工具:orabf-v0.7.6,ops_sse2(这个只能破解sys的)
ops_sse2下载地址:http://conus.info/utils/ops_SIMD/
我用的是orabf-v0.7.6
简单密码测试:
破解成功:oracle
稍微复杂的密码测试:
有特殊字符的密码测试:
如果稍微复杂的密码,orabf-v0.7.6破解也同样是遥遥无期(计算机性能好一点可能会稍微好一点)。
tar -xf ops_SIMD_linux86.tar
linux
yum -y install libstdc++.so.6
./ops_sse2
含特殊字符或者长度稍长一点的复杂密码试一下
当然我自己建的一个用户,密码9位,嗯,ops_sse2也是够呛了,也只能破解如oracle这种默认密码,说实话,我自己都可以猜测测试一下,这种的简单密码!
https://codeload.github.com/Seabreg/thc-orakelcrackert11g/zip/master