vulhub vulnerability series: analysis of activemq arbitrary file write vulnerability

*Strict statement: This article is limited to technical discussion and sharing, and is strictly forbidden to be used for illegal channels.

1、 About ActiveMQ:

Apache ActiveMQ is an open source message middleware developed by the Apache Software Foundation. Because ActiveMQ is a pure java program, it only needs the operating system to support Java virtual machine, and ActiveMQ can be executed.

2、 Vulnerability Description:

This vulnerability appears in the application of fileserver. The principle of vulnerability is very simple, that is, fileserver supports writing files (but does not parse JSPS), and supports moving files (move requests). Therefore, we only need to write one file, and then use move request to move it to any location, causing any file write vulnerability.

1. Its utilization rate is not high

2. File operation is vulnerable

Therefore, ActiveMQ has turned off the application of fileserver by default in 5.12. X ~ 5.13. X (you can turn it on in conf / jetty. XML); after 5.14.0, the application of fileserver has been completely removed. During testing, you can focus on the version of ActiveMQ to avoid detours.

3、 Principle of vulnerability:

Next, the source code of move method does not restrict the path of move

4、 Exploit:

There are several ways to use file writing: let's demonstrate uploading webshell here

1. Write webshell

2. Write files such as cron or SSH key

3. Write jar or jetty.xml and other libraries and configuration files

Webshell code

%
    if("023".equals(request.getParameter("pwd"))){
        java.io.InputStream in = Runtime.getRuntime().exec(request.getParameter("i")).getInputStream();
        int a = -1;
        byte[] b = new byte[2048];
        out.print("pre");
        while((a=in.read(b))!=-1){
            out.println(new String(b));
        }
        out.print("/pre");
    }
%

We use put method to upload any file

Next, we will visit the upload file to see if the upload is successful.

Because the uploaded text file cannot be parsed by the server, we will use the move method to move the uploaded webshell to the executable directory and change the suffix to JSP.

The paths to parse JSP files are:

1．/opt/activemq/webapps/api

2．/opt/activemq/webapps/admin

There is a pit here, which puzzled me for a long time. My method steps have no problem why the move method will always respond to the timeout and get no response content. After trying for a long time, I once suspected that there was a problem with my vulhub environment. I used the package I caught in burp to modify and execute the move method and got the response result very quickly. What's amazing is that I copied the package back to the repeater for execution and the response time-out result reappeared again. Obviously, it's two identical packets, which is puzzling. I can only attribute it to the move method here PS: that's what I've seen in other articles.

This is the response content after move succeeds.

Then we visit the mobile directory to see the results. But there is a weak point here, that is, to access our webshell, you must log in, because / API, / Admin these two paths must be log in before you can access them, but move to these two paths does not need to log in, OK, we enter the default weak password admin / Admin, after logging in, we see the webshell we are thinking about.

With webshell, although it's very weak, we still have to execute several orders to declare our results.

Let's briefly talk about other utilization methods, write crontab, and auto shell, which is a relatively stable method. First upload the cron configuration file (note that the line feed must be \ n, not be \ R \ n, otherwise crontab execution will fail). Then move it to / etc / cron.d/root. If both of the above requests return 204, the write is successful. Wait for the shell to bounce. This method requires ActiveMQ to run as root. Otherwise, it cannot write to the cron file. In theory, we can override jetty.xml, remove the login restrictions of admin and API, and then write to webshell. In some cases, the owner of jetty.xml and jar is the user of the web container, so the success rate of writing crontab is a little higher than that. Not yet tested.

5、 POC prepared by:

In this part, according to the principle of vulnerability, since the move method is unstable, we need to verify whether the put can be executed successfully. I used pocsuite in the POC writing part.

If I can, I want to write this into a series of articles. I hope you can encourage me.