漏洞cnnvd-03-350分析与复原

1、精品好资料学习推荐Harbin Institute of Technology at Weihai实验报告课程名称： 防火墙与入侵检测 院 系： 计算机科学与技术学院 班 级： 1304202 实 验 者：xxxxxxxx学 号：xxxxxxxxxxx指导教师：xxxxxxx实验时间：2016年6月 哈尔滨工业大学（威海）二零一六年六月25 / 26一、漏洞详情信息表漏洞名称：WordPress WPML插件SQL注入漏洞CNNVD编号：CNNVD-201503-350发布时间：2015-03-18更新时间：2015-03-18危害等级：高危漏洞类型：SQL注入威胁类型：远程CVE编号：CVE

2、-2015-2314漏洞简介WordPress是WordPress软件基金会的一套使用PHP语言开发的博客平台，该平台支持在PHP和MySQL的服务器上架设个人博客网站。WPML是其中的一个多语言插件。WordPress WPML插件3.1.9之前版本中存在SQL注入漏洞，该漏洞源于comments/feed URI没有充分过滤wp-link-ajax操作中的HTTP Referer头。远程攻击者可借助lang参数利用该漏洞执行任意SQL命令。二、系统和软件环境配置详情信息表系统配置表：环境配置表：三、漏洞还原详细步骤（需要包含每一步的截图）；(本次实验中，所有用到的密码均为12345678)

3、1.环境配置：配置apache服务器+MySql+PHP+在C:360安全浏览器下载中找到已下载好的appserv-win32-8.3.0.exe打开打开软件，进入安装界面，点击下一步选择安装路径，可自行选择选择下面要安装的服务，全选设置主机名以及邮箱，默认端口为80（安装完后可自行修改）设置数据库密码，一般都设置为root，不过可以自己随意设置，编码就选择UTF-8点击下一步在浏览器中输入localhost或者，若出现如下页面，则说明安装成功2.安装任意版本的WordPress在C:360安全浏览器下载中，找到已下载好的WordPress4.5.2版本解压将解压好的文件夹放

4、在C:AppServwww目录下，以便可以被apache识别打开浏览器，输入网址：http:/localhost/wordpress/wp-admin/install.php进入配置安装界面配置成功后，输入网址：http:/localhost/wordpress/wp-login.php进入登陆界面账号：密码：12345678登陆后进入主界面，此时已经成功安装3.安装WordPress多语言插件WPML在C:360安全浏览器下载中解压已经下载好的3.1.5版本的WPML插件在浏览器中输入网址：http:/localhost/wordpress/wp-admi

5、n/plugins.php打开插件配置界面点击“安装插件”将以下三个插件添加进去WPML Multilingual CMS WPML多语言CMS（核心插件，文件夹名称为sitepress-multilingual-cms）WPML String Translation WPML字符串翻译（Add-on插件）WPML Translation Management WPML翻译管理 （Add-on插件）添加好后返回插件主界面，点击启用以启用插件激活后，点击页面顶部的“No thanks, I will configure myself”按钮进入配置界面首先，选择网站默认语言，如果网站已经有内容，请

6、选择当前内容所使用的语言，点击Next按钮继续。接下来，选择要支持的其它语言。例如，我要做中英文网站，所以勾选Chinese (Simplified)，点击Next按钮继续。最后一步是一些基本设置：Language switcher widget 设置多语言切换按钮的样式以及显示位置，默认在sidebar中显示。Language switcher style的设置可以根据个人喜好来进行，我的设置偏好如下：至此，漏洞环境已经配置成功！四、漏洞测试或验证详细步骤测试步骤：1.首先当你开启了WP-Slimstat插件之后，每当你访问一个网页，系统都会通过ajax向/wp-admin/admin-aj

7、ax.php发送post请求，记录你当前访问网页的情况。发送的数据如下图所示：其中data是一段base64编码过的数据，经过解码之后是1 ci=YToyOntzOjEyOiJjb250ZW50X3R5cGUiO3M6NDoiaG9tZSI7czo4OiJjYXRlZ29yeSI7czowOiIiO30=.ae93e0c4e2f76695c4dd540456ab7945&ref=&res=aHR0cDovLzEwLjE4LjE4MC4zNy93b3JkcHJlc3Mv&sw=1920&sh=1080&cd=24&aa=1&sl=2004&pp=7267&pl=flash|2.直接到插件的文件中

8、去看如何处理这段数据的在wp-contentpluginswp-slimstatwp-slimstat.php文件的第86行我们可以看到，data经过base64解码之后传递给了$data_string。随后通过parse_str方法将其赋给了$data_js3.把$data_jsci分成了两部分，“.”后面的赋给了$nonce，前面的覆盖了原来的$data_jsci在105行，将$data_jsci的后面添加了一个秘钥，md5加密后和$nonce做对比，如果不相等将直接退出程序。也就是说，对数据包是否被篡改进行了校验，如果被篡改将直接退出程序4.如果数据没有被篡改，在第374行5.将$dat

9、a_jsci base64解码再反序列化之后赋给了$content_info，之后在417行6.$content_info进入了maybe_insert_row函数，跟进该函数，1036行可以看到数据被带入到了查询中，在第1044行我们看到，程序还是严谨的使用了wordpress自带的数据库查询函数对获取的数据进行了预处理，但是百密终有一疏，$a_key这个变量没有在预处理的行列中，而这个变量也是我们可控的，这也是这个漏洞的罪魁祸首。那么问题来了：我们该如何绕过校验呢，让程序认为数据没有被篡改过呢？7.从上面我们知道只有$nonce 和 md5(self:$data_jsci.self:$op

10、tionssecret)相等时才可以继续执行程序，现在我们可以控制的是$nonce和$data_jsci，只要再知道$optionssecret即可。我们看下$optionssecret是什么在1095行我们可以看到他是简单的系统当前时间被md5加密过后的值，time()函数返回的是Unix时间戳，是一个10位的纯数字，而且根据推测网站的建立时间，我们可以大大缩小猜测的范围，根据测试，大约3000万次即可猜出系统的secret秘钥，一旦我们猜出了秘钥，我们便可以篡改数据包，进行注入。验证步骤:1.拥有了秘钥之后我们开始注入，由于注入出在数组的键值上，所以我们在category后面添加一个单引号

11、。构造的payload如下：1 a:2:s:12:content_type;s:4:home;s:9:category;s:0:;将其base64编码然后加上秘钥md5加密，获得了13688da6b1bad69d677948ebed0fa19a的加密值，把他加入请求，对请求base64再次编码后得到了我们最终的payload：Y2k9WVRveU9udHpPakV5T2lKamIyNTBaVzUwWDNSNWNHVWlPM002TkRvaWFHOXRaU0k3Y3pvNU9pSmpZWFJsWjI5eWVTY2lPM002TURvaUlqdDkuMTM2ODhkYTZiMWJhZDY5ZDY3

12、Nzk0OGViZWQwZmExOWEmcmVmPSZyZXM9YUhSMGNEb3ZMekV3TGpFNExqRTRNQzR6Tnk5M2IzSmtjSEpsYzNNdiZzdz0xOTIwJnNoPTEwODAmY2Q9MjQmYWE9MSZzbD0yMDA0JnBwPTcyNjcmcGw9Zmxhc2h82.用burp发包3.从Mysql日志中可以看到单引号被带入了查询附：猜解秘钥程序：1136044800;$secret-) if($nonce=md5($ci.md5($secret) echo find the secret is .md5($secret); break; ?五、漏

13、洞危害分析；1）广泛性SQL注入攻击利用的是SQL语法，因此只要是利用SQL语法的Web应用程序如果未对输入的SQL语句做严格的处理都会存在SQL注入漏洞，目前以Active/JavaServerPages、ColdFusionManagement、PHP、Perl等技术与SQLServer、Oracle、DB2、Sybase等数据库相结合的Web应用程序均发现存在SQL注入漏洞。2）技术难度不高SQL注入技术公布后，网络上先后出现了多款SQL注入工具，例如教主的HDSI、NBSI、明小子的Domain等，利用这些工具软件可以轻易地对存在SQL注入的网站或者Web应用程序实施攻击，并最终获取其

14、计算器的控制权。3）危害性大SQL注入攻击成功后，轻者只是更改网站首页等数据，重者通过网络渗透等攻击技术，可以获取公司或者企业机密数据信息，产生重大经济损失。六、个人感悟。SQL注入攻击是你需要担心的事情，不管你用什么web编程技术，再说所有的web框架都需要担心这个的。你需要遵循几条非常基本的规则：1)在构造动态SQL语句时，一定要使用类安全(type-safe)的参数加码机制。大多数 的数据API，包括ADO和ADO. NET，有这样的支持，允许你指定所提供的参数的确切类型(譬如，字符串，整数，日期等)，可以保证这些参数被恰当地escaped/encoded了， 来避免黑客利用它们。一定要

15、从始到终地使用这些特性。例如，在ADO. NET里对动态SQL，你可以象下面这样重写上述的语句，使之安全：Dim SSN as String = Request.QueryString(SSN)Dim cmd As new SqlCommand(SELECT au_lname, au_fname FROM authors WHERE au_id = au_id)Dim param = new SqlParameter(au_id, SqlDbType.VarChar)param.Value = SSNcmd.Parameters.Add(param)这将防止有人试图偷偷注入另外的SQL表达式(

16、因为ADO. NET知道对au_id的字符串值进行加码)，以及避免其他数据问题(譬如不正确地转换数值类型等)。注意，VS 2005内置的TableAdapter/DataSet设计器自动使用这个机制，ASP. NET 2.0数据源控件也是如此。一个常见的错误知觉(misperception)是，假如你使用了存储过程或ORM，你就完全不受SQL注入攻击之害了。这是不正确的，你还是需要确定在给存储过程传递数据时你很谨慎，或在用ORM来定制一个查询时，你的做法是安全的。2) 在部署你的应用前，始终要做安全审评(security review)。建立一个正式的安全过程(formal security

17、process)，在每次你做更新时，对所有的编码做审评。后面一点特别重要。很多次我听说开发队伍在正式上线(going live)前会做很详细的安全审评，然后在几周或几个月之后他们做一些很小的更新时，他们会跳过安全审评这关，推说，“就是一个小小的更新，我们以后再做 编码审评好了”。请始终坚持做安全审评。3) 千万别把敏感性数据在数据库里以明文存放。我个人的意见是，密码应该总是在单向(one-way )hashed过后再存放，我甚至不喜欢将它们在加密后存放。在默认设置下，ASP. NET 2.0 Membership API 自动为你这么做，还同时实现了安全的SALT 随机化行为(SALT ran

18、domization behavior)。如果你决定建立自己的成员数据库，我建议你查看一下我们在这里发表的我们自己的Membership provider的源码。同时也确定对你的数据库里的信用卡和其他的私有数据进行了加密。这样即使你的数据库被人入侵(compromised)了的话， 起码你的客户的私有数据不会被人利用。4)确认你编写了自动化的单元测试，来特别校验你的数据访问层和应用程序不受SQL注入攻击。这么做是非常重要的，有助于捕捉住(catch)“就是一个小小的更新，所有不会有安全问题”的情形带来的疏忽，来提供额外的安全层以避免偶然地引进坏的安全缺陷到你的应用里去。5)锁定你的数据库的安全，只给访问数据库的web应用功能所需的最低的权限。如果web应用 不需要访问某些表，那么确认它没有访问这些表的权限。如果web应用只需要只读的权限从你的account payables表来生成报表，那么确认你禁止它对此表的 insert/update/delete 的权限。6)很多新手从网上下载SQL通用防注入系统的程序，在需要防范注入的页面头部用 来防止别人进行手动注入测试（可是