2023年7月31日发(作者：)

1 SQL注入漏洞

SQL注入攻击（SQL Injection），简称注入攻击，SQL注入是web开发中最常见的一种安全漏洞。SQL注入漏洞可以用来从数据库获取敏感信息，或者利用数据库的特性执行添加用户，导出文件等一系列恶意操作，甚至有可能获取数据库乃至系统最高权限

SQL注入漏洞原理

由于程序没有过滤用户的输入，攻击者通过响服务器提交恶意的SQL查询语句，应用程序接收后错误的将攻击者的输入作为原始SQL查询语句的一部分执行，导致改变了程序原始的SQL查询逻辑，额外的执行了攻击者构造的SQL查询语句

SQL注入的位置

无论是内网环境还是外网环境（互联网），B/S架构的Web应用（以下指网站）都直接或者间接地受到各种类型的Web攻击的影响。

对于后台数据库来说，以SQL注入攻击危害最为普遍，由于网站服务端语言自身的缺陷与程序员编写代码的安全意识不足，攻击者可以将恶意SQL语句注入到正常的数据库操作指令中去，从而使该恶意SQL语句在后台数据库中被解析执行。在SQL注入攻击之前，首先要找到网站中各类与数据库形成交互的输入点。通常情况下，一个网站的输入点包括：

1. 表单提交，主要是POST请求，也包括GET请求。

2. URL参数提交，主要为GET请求参数。

3. Cookie参数提交。

4. HTTP请求头部的一些可修改的值，比如Referer、User_Agent等。

5. 一些边缘的输入点，比如.mp3文件的一些文件信息等。

服务端从客户端直接或间接获取数据的过程都是一次输入过程，无论直接或间接，默认情况下输入的数据都应该认为是不安全的。

上面列举的几类输入点，只要任何一点存在过滤不严，过滤缺陷等问题，都有可能发生SQL注入攻击。大多数情况下，SQL注入的过程都是由工具完成的，其中包括大批量注入工具的使用。

2 Heartbleed漏洞

漏洞描述

Heartbleed漏洞，这项严重缺陷(CVE-2014-0160)的产生是由于未能在memcpy()调用受害用户输入内容作为长度参数之前正确进行边界检查。攻击者可以追踪OpenSSL所分配的64KB缓存、将超出必要范围的字节信息复制到缓存当中再返回缓存内容，这样一来受害者的内存内容就会以每次64KB的速度进行泄露。

获取密码

2014年4月9日，Heartbleed（意为“心脏出血”）的重大安全漏洞被曝光，一位安全行业人士在知乎上透露，他在某著名电商网站上用这个漏洞尝试读取数据，在读取200次后，获得了40多个用户名、7个密码，用这些密码，他成功地登录了该网站。

入侵技术

SSL（安全套接层）协议是使用最为普遍网站加密技术，而OpenSSL则是开源的 SSL 套件，为全球成千上万的web服务器所使用。Web服务器正是通过它来将密钥发送给访客然后在双方的连接之间对信息进行加密。URL中使用 https打头的连接都采用了SSL加密技术。在线购物、网银等活动均采用SSL技术来防止窃密及避免中间人攻击。

Heartbleed漏洞之所以得名，是因为用于安全传输层协议（TLS）及数据包传输层安全协议（DTLS）的 Heartbeat扩展存在漏洞。Heartbeat扩展为TLS/DTLS提供了一种新的简便的连接保持方式，但由于OpenSSL 1.0.2-beta与OpenSSL 1.0.1在处理TLS heartbeat扩展时的边界错误，攻击者可以利用漏洞披露连接的客户端或服务器的存储器内容，导致攻击者不仅可以读取其中机密的加密数据，还能盗走用于加密的密钥。

3 密码重置漏洞

密码重置功能是一些常见漏洞的起因。例如用户名枚举漏洞(数据库中用户名不存在和密码错误显示不同的错误信息)，敏感信息泄露(把明文密码通过e-mail发送给用户)重置密码消息劫持(攻击会者接收到密码重置信息)这些都是在密码重置功能中比较常见的漏洞。

很多开发者都不能真正了解密码重置所能引发的危害，而这个博客文章告诉大家一些不遵守基本安全准则的开发人员所开发的密码重置功能会带来哪些危害。

举个例子，一个健壮的密码恢重置功能会生成一个令牌，并通过电子邮件发送一个包含令牌的重置密码连接给用户。

令牌应具有以下特征：

包含64个字符或者更多

唯一性

随机性

一次性

拥有较短寿命(比如在24小时内到期)

当用户点击该链接时，应用程序必须检查令牌是否有效。

如果令牌有效，应用程序必须注销这个令牌，以便它不能被重用，并允许用户更改自己的密码。

此外，如果用户试图第二次重置密码，在完成第一次重置过程之前，应用程序必须废止旧的密码重置请求并生成一个新的重置请求。

为了提高安全性，也可以使用双重的用户身份认证(但并不是必须使用)。

比如，要求用户回答之前填写的隐私问题(比如我的大姨妈的名字是神马)或确认发送到用户手机的验证码。

现在，让我们分析一个真实的并且设计的很糟糕的密码恢复系统，列举出所有相关的安全漏洞，并尝试编写POC

(1)用户名枚举

最明显的漏洞就是用户名枚举漏洞，用户提交一个邮箱地址，如果邮箱存在那么，系统会返回一条信息

"Your new password has been sent to: LanLan@"

如果该邮箱没有被人注册，那么系统将返回

"The provided e-mail is invalid"

(2)拒绝服务

第二个漏洞应该是拒绝服务

这个系统中有一个生成随机密码的函数，攻击者可以编写一个脚本来不断尝试重置密码过程(原文中给出15秒每次，怀疑频率是否有点低)

另外，如果配合用户名枚举漏洞的话，这个漏洞会产生更大的危害，可以用来更改任意用户的密码。(虽然你收不到该密码，但也可以给用户产生不小的麻烦)

(3)敏感信息泄露

第三个漏洞是敏感信息泄露，因为该系统使用明文把密码通过邮件发送给用户，并且没有在用户下次登录的时候

强制用户修改密码。如果攻击者获取了用户的邮件信息(其实这个也不算特别容易)，就可以通过邮件中的密码登录系统。 (4)SQL 注入

第四个注入漏洞也比较明显，用户提交的数据没有经过过滤直接代入查询语句，利用方式也有很多种。这样构造可以改掉所有用户的密码，也可以用来造成拒绝服务攻击。

Input: ’ or 1=1%23

First SQL becomes (Line 15): SELECT usr_, usr_, usr_,

usr_rd FROM usr_user WHERE usr_ = ’’ or 1=1#’ ORDER BY id DESC

Second SQL becomes (Line 26): UPDATE usr_user SET password = MD5(trim(‘xxxxxxxxxx’))

WHERE email like ’’ or 1=1#’

这个注入点还可以用来进行盲注来猜测一些敏感信息。

(5)跨站脚本漏洞

第五个漏洞也可以很明显的找到，用户输入的mail参数被带入到了邮件内容中(没有经过任何过滤)，这个漏洞的利用需要配合

SQL 注入漏洞来使用

User Input: ’ or 1=1%23

First SQL becomes (Line 15): SELECT usr_, usr_, usr_,

usr_rd FROM usr_user WHERE usr_ = ’’ or 1=1#‘ ORDER BY id DESC

Second SQL becomes (Line 26): UPDATE usr_user SET password = MD5(trim(‘xxxxxxxxxx’))

WHERE email like ’’ or 1=1#‘

Response Message (Line 47): Your new password was sent to: ’ or 1=1#

提交上述数据，系统首先会修改所有用户的密码，然后给所有用户发送包含恶意脚本的文件

(6)密码重置信息劫持

最后一个漏洞是密码重置信息劫持，也是危害比较严重的漏洞。产生原因是，用户提交数据mail(又是这货)被包含到了MIME头中，这个漏洞的利用同样需要配合SQL注入：

User Input: LanLan@%00’ or 1=1%23

First SQL becomes (Line 15): SELECT usr_, usr_, usr_,

usr_rd FROM usr_user WHERE usr_ = ’LanLan@*null byte char+’ or

1=1#’ ORDER BY id DESC

Second SQL becomes (Line 26): UPDATE usr_user SET password = MD5(trim(‘xxxxxxxxxx’))

WHERE email like ’LanLan@*null byte char+’ or 1=1#’

MIME Header becomes (Line 34): To: John Smith

执行上面的代码的结果就是所用用户密码被修改，修改后的邮件会被发送到LanLan@，这里[null byte char]会截断mini头中的信息。

4 FakeID签名漏洞

这个漏洞的Google Bug ID 是13678484，从AOSP上的修复代码可以发现问题出现在签名校验的JarVerifier类中。最关键的代码是在JarUtils中，添加了chainCheck的选项，可以对所有证书进行校验。

我们可以这么构造一个恶意证书：

开发机上生成一个根证书（记为CA），并用这个证书去颁发一个子证书（记为SIGN）

然后使用这个子证书为我们即将发布的apk签名，这时APK中的.Rsa文件将包含两个证书，一个是SIGN，一个是CA。并且APK所有的文件都是可以用这个RSA文件验证其合法性的

对这个RSA文件进行篡改，只修改CA证书的内容（替换后的CA记为FakeCA），不修改证书中的SignerInfo部分，不影响PackageManger在安装前使用tedDigest对APK包数据完整性进行校验

这个APK可以被成功安装，并且包含两个证书，一个是SIGN，一个是FakeCA

如果你之前像我一样不了解PKCS7签名文件格式，那么在尝试恶意修改rsa文件时将会遇到一些麻烦，我推荐使用开源项目pyASN1去修改RSA文件。因为这种格式本质上是使用DER编码，使用ASN1做了序列化，使用pyASN1能让我们快速熟悉这种文件格式，并且快速着手进行签名篡改。

我将文件修改代码放到了我的github上[5]，注意这不是一份自动篡改证书的工具，内部包含了一些路径和格式的硬编码，你如果想使用这份代码，需要理解代码的意思并做一些修改。

5 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。

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并且文件中增加D_LOGON_VERSION=12才有效。

正如CVE-2012-3137所描述Oracle为了防止第三方通过网络获取登录信息包。而对密码进行了加密处理。本部分只以oracle11.1密码如何破解为例进行说明。

在发起连接之后（oracle牵手完成），客户端和服务器经过协商确定要使用的验证协议。要完成这个任务，客户端首先向数据库发送一个包。包中包含客户端主要信息和所请求的加密方式。数据库确认加密方式有效后，发送一个确认服务包

在通过安全网络服务完成任何所要求的协议之后，数据库用户被O3logon（oracle验证方式）进行验证，这个协议执行一个序列来向数据库证明客户端拥有密码。为了避免网络第三方截获到密码。首先客户端发送用户名到数据库来表明用户身份。数据库端根据加密协议，其中96位的作为数据库端密钥，20位的作为偏移量，它对每个连接都是不同的。一个典型的数据库端发给客户端的密钥如下：

COCDD89FIGODKWASDF……………………

客户端根据加密算法向服务器端发送96位的客户端密钥和64位的密码密钥。服务器端计算客户端传入的密码密钥。如果计算后密码密文和数据库中存储的16位密码密文一致则验证通过。

根据这个过程可知上面TNS劫持包中取得的加密信息：AUTH_SESSKEY，AUTH_SESSKEY_CLIENT，AUTH_PASSWORD，AUTH_VFR_DATA这四个值是解密的关键。我们把他们按照SHA1,MD5，AES192进行一系列处理。最终通过数据字典碰撞得到密码明文。

2023年7月31日发(作者：)

1 SQL注入漏洞

SQL注入攻击（SQL Injection），简称注入攻击，SQL注入是web开发中最常见的一种安全漏洞。SQL注入漏洞可以用来从数据库获取敏感信息，或者利用数据库的特性执行添加用户，导出文件等一系列恶意操作，甚至有可能获取数据库乃至系统最高权限

SQL注入漏洞原理

由于程序没有过滤用户的输入，攻击者通过响服务器提交恶意的SQL查询语句，应用程序接收后错误的将攻击者的输入作为原始SQL查询语句的一部分执行，导致改变了程序原始的SQL查询逻辑，额外的执行了攻击者构造的SQL查询语句

SQL注入的位置

无论是内网环境还是外网环境（互联网），B/S架构的Web应用（以下指网站）都直接或者间接地受到各种类型的Web攻击的影响。

对于后台数据库来说，以SQL注入攻击危害最为普遍，由于网站服务端语言自身的缺陷与程序员编写代码的安全意识不足，攻击者可以将恶意SQL语句注入到正常的数据库操作指令中去，从而使该恶意SQL语句在后台数据库中被解析执行。在SQL注入攻击之前，首先要找到网站中各类与数据库形成交互的输入点。通常情况下，一个网站的输入点包括：

1. 表单提交，主要是POST请求，也包括GET请求。

2. URL参数提交，主要为GET请求参数。

3. Cookie参数提交。

4. HTTP请求头部的一些可修改的值，比如Referer、User_Agent等。

5. 一些边缘的输入点，比如.mp3文件的一些文件信息等。

服务端从客户端直接或间接获取数据的过程都是一次输入过程，无论直接或间接，默认情况下输入的数据都应该认为是不安全的。

上面列举的几类输入点，只要任何一点存在过滤不严，过滤缺陷等问题，都有可能发生SQL注入攻击。大多数情况下，SQL注入的过程都是由工具完成的，其中包括大批量注入工具的使用。

2 Heartbleed漏洞

漏洞描述

Heartbleed漏洞，这项严重缺陷(CVE-2014-0160)的产生是由于未能在memcpy()调用受害用户输入内容作为长度参数之前正确进行边界检查。攻击者可以追踪OpenSSL所分配的64KB缓存、将超出必要范围的字节信息复制到缓存当中再返回缓存内容，这样一来受害者的内存内容就会以每次64KB的速度进行泄露。

获取密码

2014年4月9日，Heartbleed（意为“心脏出血”）的重大安全漏洞被曝光，一位安全行业人士在知乎上透露，他在某著名电商网站上用这个漏洞尝试读取数据，在读取200次后，获得了40多个用户名、7个密码，用这些密码，他成功地登录了该网站。

入侵技术

SSL（安全套接层）协议是使用最为普遍网站加密技术，而OpenSSL则是开源的 SSL 套件，为全球成千上万的web服务器所使用。Web服务器正是通过它来将密钥发送给访客然后在双方的连接之间对信息进行加密。URL中使用 https打头的连接都采用了SSL加密技术。在线购物、网银等活动均采用SSL技术来防止窃密及避免中间人攻击。

Heartbleed漏洞之所以得名，是因为用于安全传输层协议（TLS）及数据包传输层安全协议（DTLS）的 Heartbeat扩展存在漏洞。Heartbeat扩展为TLS/DTLS提供了一种新的简便的连接保持方式，但由于OpenSSL 1.0.2-beta与OpenSSL 1.0.1在处理TLS heartbeat扩展时的边界错误，攻击者可以利用漏洞披露连接的客户端或服务器的存储器内容，导致攻击者不仅可以读取其中机密的加密数据，还能盗走用于加密的密钥。

3 密码重置漏洞

密码重置功能是一些常见漏洞的起因。例如用户名枚举漏洞(数据库中用户名不存在和密码错误显示不同的错误信息)，敏感信息泄露(把明文密码通过e-mail发送给用户)重置密码消息劫持(攻击会者接收到密码重置信息)这些都是在密码重置功能中比较常见的漏洞。

很多开发者都不能真正了解密码重置所能引发的危害，而这个博客文章告诉大家一些不遵守基本安全准则的开发人员所开发的密码重置功能会带来哪些危害。

举个例子，一个健壮的密码恢重置功能会生成一个令牌，并通过电子邮件发送一个包含令牌的重置密码连接给用户。

令牌应具有以下特征：

包含64个字符或者更多

唯一性

随机性

一次性

拥有较短寿命(比如在24小时内到期)

当用户点击该链接时，应用程序必须检查令牌是否有效。

如果令牌有效，应用程序必须注销这个令牌，以便它不能被重用，并允许用户更改自己的密码。

此外，如果用户试图第二次重置密码，在完成第一次重置过程之前，应用程序必须废止旧的密码重置请求并生成一个新的重置请求。

为了提高安全性，也可以使用双重的用户身份认证(但并不是必须使用)。

比如，要求用户回答之前填写的隐私问题(比如我的大姨妈的名字是神马)或确认发送到用户手机的验证码。

现在，让我们分析一个真实的并且设计的很糟糕的密码恢复系统，列举出所有相关的安全漏洞，并尝试编写POC

(1)用户名枚举

最明显的漏洞就是用户名枚举漏洞，用户提交一个邮箱地址，如果邮箱存在那么，系统会返回一条信息

"Your new password has been sent to: LanLan@"

如果该邮箱没有被人注册，那么系统将返回

"The provided e-mail is invalid"

(2)拒绝服务

第二个漏洞应该是拒绝服务

这个系统中有一个生成随机密码的函数，攻击者可以编写一个脚本来不断尝试重置密码过程(原文中给出15秒每次，怀疑频率是否有点低)

另外，如果配合用户名枚举漏洞的话，这个漏洞会产生更大的危害，可以用来更改任意用户的密码。(虽然你收不到该密码，但也可以给用户产生不小的麻烦)

(3)敏感信息泄露

第三个漏洞是敏感信息泄露，因为该系统使用明文把密码通过邮件发送给用户，并且没有在用户下次登录的时候

强制用户修改密码。如果攻击者获取了用户的邮件信息(其实这个也不算特别容易)，就可以通过邮件中的密码登录系统。 (4)SQL 注入

第四个注入漏洞也比较明显，用户提交的数据没有经过过滤直接代入查询语句，利用方式也有很多种。这样构造可以改掉所有用户的密码，也可以用来造成拒绝服务攻击。

Input: ’ or 1=1%23

First SQL becomes (Line 15): SELECT usr_, usr_, usr_,

usr_rd FROM usr_user WHERE usr_ = ’’ or 1=1#’ ORDER BY id DESC

Second SQL becomes (Line 26): UPDATE usr_user SET password = MD5(trim(‘xxxxxxxxxx’))

WHERE email like ’’ or 1=1#’

这个注入点还可以用来进行盲注来猜测一些敏感信息。

(5)跨站脚本漏洞

第五个漏洞也可以很明显的找到，用户输入的mail参数被带入到了邮件内容中(没有经过任何过滤)，这个漏洞的利用需要配合

SQL 注入漏洞来使用

User Input: ’ or 1=1%23

First SQL becomes (Line 15): SELECT usr_, usr_, usr_,

usr_rd FROM usr_user WHERE usr_ = ’’ or 1=1#‘ ORDER BY id DESC

Second SQL becomes (Line 26): UPDATE usr_user SET password = MD5(trim(‘xxxxxxxxxx’))

WHERE email like ’’ or 1=1#‘

Response Message (Line 47): Your new password was sent to: ’ or 1=1#

提交上述数据，系统首先会修改所有用户的密码，然后给所有用户发送包含恶意脚本的文件

(6)密码重置信息劫持

最后一个漏洞是密码重置信息劫持，也是危害比较严重的漏洞。产生原因是，用户提交数据mail(又是这货)被包含到了MIME头中，这个漏洞的利用同样需要配合SQL注入：

User Input: LanLan@%00’ or 1=1%23

First SQL becomes (Line 15): SELECT usr_, usr_, usr_,

usr_rd FROM usr_user WHERE usr_ = ’LanLan@*null byte char+’ or

1=1#’ ORDER BY id DESC

Second SQL becomes (Line 26): UPDATE usr_user SET password = MD5(trim(‘xxxxxxxxxx’))

WHERE email like ’LanLan@*null byte char+’ or 1=1#’

MIME Header becomes (Line 34): To: John Smith

执行上面的代码的结果就是所用用户密码被修改，修改后的邮件会被发送到LanLan@，这里[null byte char]会截断mini头中的信息。

4 FakeID签名漏洞

这个漏洞的Google Bug ID 是13678484，从AOSP上的修复代码可以发现问题出现在签名校验的JarVerifier类中。最关键的代码是在JarUtils中，添加了chainCheck的选项，可以对所有证书进行校验。

我们可以这么构造一个恶意证书：

开发机上生成一个根证书（记为CA），并用这个证书去颁发一个子证书（记为SIGN）

然后使用这个子证书为我们即将发布的apk签名，这时APK中的.Rsa文件将包含两个证书，一个是SIGN，一个是CA。并且APK所有的文件都是可以用这个RSA文件验证其合法性的

对这个RSA文件进行篡改，只修改CA证书的内容（替换后的CA记为FakeCA），不修改证书中的SignerInfo部分，不影响PackageManger在安装前使用tedDigest对APK包数据完整性进行校验

这个APK可以被成功安装，并且包含两个证书，一个是SIGN，一个是FakeCA

如果你之前像我一样不了解PKCS7签名文件格式，那么在尝试恶意修改rsa文件时将会遇到一些麻烦，我推荐使用开源项目pyASN1去修改RSA文件。因为这种格式本质上是使用DER编码，使用ASN1做了序列化，使用pyASN1能让我们快速熟悉这种文件格式，并且快速着手进行签名篡改。

我将文件修改代码放到了我的github上[5]，注意这不是一份自动篡改证书的工具，内部包含了一些路径和格式的硬编码，你如果想使用这份代码，需要理解代码的意思并做一些修改。

5 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。

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并且文件中增加D_LOGON_VERSION=12才有效。

正如CVE-2012-3137所描述Oracle为了防止第三方通过网络获取登录信息包。而对密码进行了加密处理。本部分只以oracle11.1密码如何破解为例进行说明。

在发起连接之后（oracle牵手完成），客户端和服务器经过协商确定要使用的验证协议。要完成这个任务，客户端首先向数据库发送一个包。包中包含客户端主要信息和所请求的加密方式。数据库确认加密方式有效后，发送一个确认服务包

在通过安全网络服务完成任何所要求的协议之后，数据库用户被O3logon（oracle验证方式）进行验证，这个协议执行一个序列来向数据库证明客户端拥有密码。为了避免网络第三方截获到密码。首先客户端发送用户名到数据库来表明用户身份。数据库端根据加密协议，其中96位的作为数据库端密钥，20位的作为偏移量，它对每个连接都是不同的。一个典型的数据库端发给客户端的密钥如下：

COCDD89FIGODKWASDF……………………

客户端根据加密算法向服务器端发送96位的客户端密钥和64位的密码密钥。服务器端计算客户端传入的密码密钥。如果计算后密码密文和数据库中存储的16位密码密文一致则验证通过。

根据这个过程可知上面TNS劫持包中取得的加密信息：AUTH_SESSKEY，AUTH_SESSKEY_CLIENT，AUTH_PASSWORD，AUTH_VFR_DATA这四个值是解密的关键。我们把他们按照SHA1,MD5，AES192进行一系列处理。最终通过数据字典碰撞得到密码明文。