- A+
摘要
一般性的数据库漏洞,都是在成功连接或登录数据库后实现入侵;本文介绍两个在2012年暴露的Oracle漏洞,通过这两种漏洞的结合,可以在不掌握用户名/密码的情况下入侵Oracle,从而完成对数据的窃取或者破坏。这两个漏洞就是CVE-2012-1675和CVE-2012-3137。
引言
国内外很多重要的系统都采用Oracle作为数据存储的数据库;在Oracle中存储着企业或政府大量敏感的信息,在金钱或政治的诱导下,内外部黑客会想法利用管理、网络、主机或数据库的自身漏洞尝试入侵到数据库中,以达到自身的目的。
本文的作者通过对Oracle俩种漏洞的组合研究,设计了一套在不掌握用户名/密码的方式入侵到Oracle中;这种方法,比传统的需要登录到数据库中的入侵方法,具有更大的安全隐患和破坏性。
本文希望通过对这两个漏洞和攻击方法的介绍,能够引起相关人员的重视,完善对数据库安全的措施。
1、概要介绍
本文提供的方法是基于漏洞CVE-2012-1675和CVE-2012-3137对oracle数据库的攻击测试的方法。
CVE-2012-1675漏洞是Oracle允许攻击者在不提供用户名/密码的情况下,向远程“TNS Listener”组件处理的数据投毒的漏洞。攻击者可利用此漏洞将数据库服务器的合法“TNS Listener”组件中的数据转向到攻击者控制的系统,导致控制远程组件的数据库实例,造成组件和合法数据库之间的中间人攻击、会话劫持或拒绝服务攻击。
CVE-2012-3137漏洞是Oracle Database 10g/11g身份验证协议实现中存在一个设计缺陷,攻击者无需认证即可远程获取数据库用户密码哈希相关数据,从而可以离线暴力破解用户密码,进一步控制数据库系统。
我们通过如下的步骤和过程可以实现对Oracle的入侵:
(1)利用CVE-2012-1675进行TNS劫持,在监听下利用远程注册,注册同名数据库实例; (2)新登陆的用户,在TNS的负载均衡策略下,有可能流量登录到伪造的监听服务上; (3)该监听服务对用户的登陆过程进行监控,并将相关数据流量转发到真实的数据库上; (4)利用CVE-2012-3137获得通讯过程中的认证相关信息; (5)对认证相关信息进行离线的暴力破解,获得登陆的密码; (6)试用破解的用户名/密码登陆Oracle,完成对Oracle中数据的访问;
2、通过CVE-2012-1675进行TNS劫持
该漏洞存在于Oracle的所有版本,并且Oracle至今仅是发布了警告性通知,并未提供解决方案。
要想利用CVE-2012-1675漏洞做TNS劫持,首先需要了解TNS机制。如下图所示oracle 通过在本地解析网络服务名到目标主机IP地址,服务端口号,目标数据库名,把这些信息发送到oracle服务器端监听程序,最后再由监听程序递送DBMS。
其中关键点在于监听会按照目标数据库名递送到名称正确的数据库。那么如果一个监听下有2个同名数据库。监听将自动按照负载均衡把这次访问发送到负载低的数据库上,进行连接访问。数据库注册到监听的方法就决定了,能否同时注册同名数据库在同一个监听下。注册方式分为本地注册和远程注册,通过修改参数可以调整为远程注册。
下面是一段可用的TNS劫持的过程:
1.在劫持机上创建一个和目标数据库实例同名的数据库实例。
2.在劫持机上修改 tnsnames.ora 文件
添加 listener_name= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=目标机器IP)(PORT=目标机器端口)))
3.在劫持机上用SQL*Plus 顺序执行下面步骤。
1.$ sqlplus / as sysdba 2. SQL> ALTER SYSTEM SETREMOTE_LISTENER='LISTENER_NAME'; 3. SQL> ALTER SYSTEM REGISTER;
4.多个客户端,向数据库发起登录。会劫持到一部分客户端的登录信息。
最终达到效果如下图所示:
按照猜想同一个监听下有2个同名实例。客户端访问监听,监听按照客户端中的数据库名信息分配数据库,由于监听下有2个同名数据库,客户端链接很可能会被分配到劫持者的数据库实例下,再通过配置劫持者的本地监听把客户端请求指回原数据库。结构图如下:
测试客户端链接196次。目标数据库实例获得113次,劫持数据库实例获得83次基本满足负载均衡的假设。(注上面实例是local server 下面实例是 remote server)
通过以上方式我们可以截获约一半左右客户端发送到服务器的合法链接。其中获得了服务器IP、端口号、数据库位置、实例名、登录用户名等一系列明文信息和4组密文信息(AUTH_SESSKEY,AUTH_SESSKEY_CLIENT,AUTH_PASSWORD,AUTH_VFR_DATA)。
3、通过CVE-2012-3137进行密码破解
CVE-2012-3137受影响的数据库版本有11.2.0.3,11.2.0.2,11.1.0.7,有使用了SHA-1加密算法的10.2.0.5和10.2.0.4,还有使用了SHA-1的10.2.0.3(运行在z/OS下)版本。
虽然这个漏洞在11.2.0.3中已经解决,但是仅仅数据库客户端和服务器都升级到11.2.0.3并且sqlnet.ora文件中增加SQLNET.ALLOWED_LOGON_VERSION=12才有效。
正如CVE-2012-3137所描述Oracle为了防止第三方通过网络获取登录信息包。而对密码进行了加密处理。本部分只以oracle11.1密码如何破解为例进行说明。
在发起连接之后(oracle牵手完成),客户端和服务器经过协商确定要使用的验证协议。要完成这个任务,客户端首先向数据库发送一个包。包中包含客户端主要信息和所请求的加密方式。数据库确认加密方式有效后,发送一个确认服务包如下图所示:
在通过安全网络服务完成任何所要求的协议之后,数据库用户被O3logon(oracle验证方式) 进行验证,这个协议执行一个序列来向数据库证明客户端拥有密码。为了避免网络第三方截获到密码。首先客户端发送用户名到数据库来表明用户身份。数据库端根据加密协议,其中96位的作为数据库端密钥,20位的作为偏移量,它对每个连接都是不同的。一个典型的数据库端发给客户端的密钥如下:
AUTH_SESSKEY.....COCDD89FIGODKWASDF……………………
客户端根据加密算法向服务器端发送96位的客户端密钥和64位的密码密钥。服务器端计算客户端传入的密码密钥。如果计算后密码密文和数据库中存储的16位密码密文一致则验证通过。
根据这个过程可知上面TNS劫持包中取得的加密信息:AUTH_SESSKEY,AUTH_SESSKEY_CLIENT,AUTH_PASSWORD,AUTH_VFR_DATA这四个值是解密的关键。我们把他们按照SHA1,MD5,AES192进行一系列处理。最终通过数据字典碰撞得到密码明文。
下面这段网上公布的一段示例代码,这段代码与笔者的思路不完全相同,但也能大概地说明这个漏洞的攻击过程:
import hashlib from Crypto.Cipher import AES def decrypt(session,salt,password): pass_hash= hashlib.sha1(password+salt) key =pass_hash.digest() + '\x00\x00\x00\x00' decryptor= AES.new(key,AES.MODE_CBC) plain =decryptor.decrypt(session) returnplain session_hex ='EA2043CB8B46E3864311C68BDC161F8CA170363C1E6F57F3EBC6435F541A8239B6DBA16EAAB5422553A7598143E78767' salt_hex = 'A7193E546377EC56639E' passwords = ['test','password',''oracle','demo'] for password in passwords: session_id= decrypt(session_hex.decode('hex'),salt_hex.decode('hex'),password) print'Decrypted session_id for password "%s" is %s' %(password,session_id.encode('hex')) ifsession_id[40:] == '\x08\x08\x08\x08\x08\x08\x08\x08': print'PASSWORD IS "%s"' % password break
4、建议的预防措施
根据以上两段分析,我们可以有如下的预防措施:
(1)在条件许可的情况下,对Oracle进行补丁升级,对Oracle打cpuoct2012-1515893补丁;注意对于cpuoct2012-1515893补丁要求服务器端和应用服务器端同时升级,否则应用系统将无法访问Oracle; (2)若无法对Oracle升级,要购买或安装具备虚拟补丁功能的数据库安全产品,防止对CVE-2012-3137和CVE-2012-1675的利用; (3)建立足够强健的口令,不要使用8位以下密码,或者字典库中的口令。
[作者/安华金和(企业账号),转载须注明来自FreeBuf黑客与极客(FreeBuf.COM)]
转载者说明:
Oracle官方提供的漏洞说明及处理办法如下:
http://www.oracle.com/technetwork/topics/security/alert-cve-2012-1675-1608180.html
My Oracle Support Note 1340831.1 for Oracle Database deployments that use Oracle Real Application Clusters (RAC).
My Oracle Support Note 1453883.1 for Oracle Database deployments that do not use RAC.
另外,还可以通过11.2.0.4及12c中新提供的VNCR来规避该问题:http://blog.csdn.net/smasegain/article/details/46640345
对于官方提供的使用COST(class of secure transports,单实例使用SECURE_REGISTER_listener_name参数RAC需要涉及到wallet)来控制远程注册这一块我还是有一些疑问的:
1).单实例防止远程数据库通过TCP协议注册的方式通过官方文档的解释怎么看都应该是只允许使用TCP协议的数据库注册而不应该有远程本地之分,反倒是不打补丁;12880299 时远程TCP协议数据库可以注册过来更加正常;
2).对于IPC协议当然没有什么好说的,毕竟IPC限定了只在本机才使用。
2).
http://blog.csdn.net/smasegain/article/details/46642395
- 我的微信
- 这是我的微信扫一扫
- 我的微信公众号
- 我的微信公众号扫一扫