0x00
前些日子，例行每天打开各大论坛，exploit-db进行遨游，发现了都在写joomla 3.4.6的RCE漏洞，也有说他是反序列漏洞。本来以为是跟几年前CVE-2015-8562的EXP公布了是同一个洞，再加上当时有任务就跳过没去测试。最近闲下来了，突然就想再试试，比较CVE-2015-8562这一个洞我当时没有成功利用过，拉了docker，用phpstudy搭了环境也都失败。结果，一看文章才发现虽然都需要用到反序列化构造POP链但是漏洞出现的地方并不一样。下面就讲一下这个洞的复现。
0x01
首先先下载对应版本号 joomla 3.4.6 https://downloads.joomla.org/it/cms/joomla3/3-4-6
然后取exploit-db上下载exp，这边就不放出来了。
接下来用phpstudy搭建好环境之后就能测试了，emmmm php版本我使用的是5.4.45 比较在复现CVE-2015-8562发现特定版本才能达到反序列化的作用。
接下来直接EXP利用：
可以看到利用成功之后会在configuration.php文件下生成一段随机密钥的一句话，拿你的菜刀或者蚁剑连接就行。
0x10
我们来看下EXP文件的简单构造。
攻击过程主要如下：
可以看到传入url以及构造的pop链然后对登录页面进行登录操作，我们可以看payload主要集中在pwd字段上，跟进到源码中，前文也提到该漏洞的利用是经过反序列化的，所以问题应该同样出现在session储存后以及取出时候出现的问题，我们先进入到joomla存放session会话数据的session表中，
通过这张表我们发现，session数据在序列化之后会储存到数据库中，并且登陆失败的用户也会被记录，这也是为什么该exp不需要身份验证吧。
回到joomla储存机制的本身，一开始我以为跟8562一样是对‘|’的过滤不充分导致的反序列化漏洞，看了下公布的文章和EXP，问题出在了read()和write()两个函数中，在储存和读取时候序列化问题导致能够绕过代码。
着重read()以及write()的str_replace函数中，mysql没法处理空字符，他就将chr(0)*chr(0)在存入的时候变成\0\0\0取出来之后在替换回chr(0)*chr(0)。那么这时候问题就来了 \0\0\0长度为6，序列化之后s:6而chr(0)*chr(0)序列化之后s:3,攻击者可以恶意构造输入\0\0\0输入导致反序列化时由于被程序替换,会将后面的3个字符当作一起使用。这时候第二段字符就逃逸成功了。然后通过构造恶意代码就能达成攻击。
那么我们应该如何构造pop攻击链呢
关于该漏洞的pop攻击链跟CVE-2015-8562是一样的JDatabaseDriverMysqli->__destruct->disconnect->call_user_func_array。通过控制参数值构成一个回调后门达到攻击。这里需要读者自行查阅了。
